From 63deea73fdf91ad3a76276ed9f8577fc7a2d5636 Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Wed, 1 Jan 2025 04:44:45 +0000 Subject: [PATCH 1/3] chore: import translations for hu --- .../hu/04) Exploring/nft/index.md | 114 ++ .../hu/05) Use Ethereum Pages/dao/index.md | 166 ++ .../hu/06) Use Cases/defi/index.md | 361 ++++ .../hu/06) Use Cases/smart-contracts/index.md | 82 + .../hu/06) Use Cases/web3/index.md | 157 ++ .../hu/07) Staking Pages/staking/dvt/index.md | 91 + .../07) Staking Pages/staking/pools/index.md | 86 + .../07) Staking Pages/staking/saas/index.md | 95 + .../07) Staking Pages/staking/solo/index.md | 206 ++ .../staking/withdrawals/index.md | 218 ++ .../decentralized-identity/index.md | 191 ++ .../hu/08) Use cases 2/desci/index.md | 138 ++ .../hu/08) Use cases 2/refi/index.md | 81 + .../08) Use cases 2/social-networks/index.md | 106 + .../hu/09) Learn Pages/bridges/index.md | 137 ++ .../energy-consumption/index.md | 82 + .../hu/09) Learn Pages/governance/index.md | 182 ++ .../hu/09) Learn Pages/security/index.md | 295 +++ .../zero-knowledge-proofs/index.md | 214 ++ .../index.md | 73 + .../guides/how-to-id-scam-tokens/index.md | 97 + .../how-to-revoke-token-access/index.md | 73 + .../guides/how-to-swap-tokens/index.md | 67 + .../guides/how-to-use-a-bridge/index.md | 70 + .../guides/how-to-use-a-wallet/index.md | 88 + .../hu/10) Guides and Quizzes/guides/index.md | 27 + .../translations/hu/11) Roadmap/eips/index.md | 79 + .../11) Roadmap/roadmap/beacon-chain/index.md | 75 + .../roadmap/future-proofing/index.md | 38 + .../hu/11) Roadmap/roadmap/index.md | 119 ++ .../hu/11) Roadmap/roadmap/merge/index.md | 229 +++ .../roadmap/merge/issuance/index.md | 134 ++ .../hu/11) Roadmap/roadmap/scaling/index.md | 51 + .../hu/11) Roadmap/roadmap/security/index.md | 48 + .../roadmap/user-experience/index.md | 36 + .../roadmap/account-abstraction/index.md | 126 ++ .../roadmap/danksharding/index.md | 95 + .../hu/12) Roadmap 2/roadmap/dencun/index.md | 120 ++ .../hu/12) Roadmap 2/roadmap/pbs/index.md | 51 + .../roadmap/secret-leader-election/index.md | 44 + .../roadmap/single-slot-finality/index.md | 66 + .../roadmap/statelessness/index.md | 103 + .../roadmap/verkle-trees/index.md | 66 + .../developers/docs/accounts/index.md | 136 ++ .../developers/docs/blocks/index.md | 152 ++ .../developers/docs/dapps/index.md | 96 + .../developers/docs/evm/index.md | 78 + .../developers/docs/evm/opcodes/index.md | 174 ++ .../developers/docs/gas/index.md | 140 ++ .../developers/docs/index.md | 25 + .../developers/docs/intro-to-ether/index.md | 78 + .../docs/intro-to-ethereum/index.md | 116 ++ .../developers/docs/networks/index.md | 149 ++ .../developers/docs/transactions/index.md | 221 ++ .../developers/docs/web2-vs-web3/index.md | 62 + .../developers/docs/wrapped-eth/index.md | 65 + .../community/code-of-conduct/index.md | 77 + .../community/events/index.md | 24 + .../community/get-involved/index.md | 135 ++ .../community/grants/index.md | 47 + .../community/language-resources/index.md | 153 ++ .../community/online/index.md | 75 + .../community/research/index.md | 399 ++++ .../community/support/index.md | 105 + .../nodes-and-clients/archive-nodes/index.md" | 80 + .../nodes-and-clients/bootnodes/index.md" | 31 + .../client-diversity/index.md" | 109 + .../docs/nodes-and-clients/index.md" | 315 +++ .../nodes-and-clients/light-clients/index.md" | 61 + .../node-architecture/index.md" | 57 + .../nodes-as-a-service/index.md" | 419 ++++ .../nodes-and-clients/run-a-node/index.md" | 480 +++++ .../docs/consensus-mechanisms/index.md" | 92 + .../pos/attack-and-defense/index.md" | 89 + .../pos/attestations/index.md" | 92 + .../pos/block-proposal/index.md" | 69 + .../consensus-mechanisms/pos/faqs/index.md" | 172 ++ .../consensus-mechanisms/pos/gasper/index.md" | 52 + .../docs/consensus-mechanisms/pos/index.md" | 99 + .../consensus-mechanisms/pos/keys/index.md" | 96 + .../pos/pos-vs-pow/index.md" | 69 + .../pos/rewards-and-penalties/index.md" | 90 + .../pos/weak-subjectivity/index.md" | 39 + .../docs/consensus-mechanisms/poa/index.md" | 79 + .../docs/consensus-mechanisms/pow/index.md" | 109 + .../consensus-mechanisms/pow/mining/index.md" | 81 + .../dagger-hashimoto/index.md" | 334 ++++ .../mining/mining-algorithms/ethash/index.md" | 1014 ++++++++++ .../pow/mining/mining-algorithms/index.md" | 37 + .../developers/docs/apis/backend/index.md" | 207 ++ .../developers/docs/apis/javascript/index.md" | 295 +++ .../developers/docs/apis/json-rpc/index.md" | 1773 +++++++++++++++++ .../block-explorers/index.md" | 258 +++ .../docs/data-and-analytics/index.md" | 55 + .../docs/development-networks/index.md" | 73 + .../developers/docs/ethereum-stack/index.md" | 61 + .../developers/docs/frameworks/index.md" | 149 ++ .../developers/docs/ides/index.md" | 64 + .../docs/programming-languages/dart/index.md" | 28 + .../programming-languages/delphi/index.md" | 56 + .../programming-languages/dot-net/index.md" | 86 + .../programming-languages/elixir/index.md" | 55 + .../programming-languages/golang/index.md" | 84 + .../docs/programming-languages/index.md" | 30 + .../docs/programming-languages/java/index.md" | 65 + .../javascript/index.md" | 73 + .../programming-languages/python/index.md" | 90 + .../docs/programming-languages/ruby/index.md" | 61 + .../docs/programming-languages/rust/index.md" | 63 + .../developers/docs/storage/index.md" | 216 ++ .../hu/19) Learn Pages 2/glossary/index.md | 499 +++++ .../hu/19) Learn Pages 2/history/index.md | 623 ++++++ .../docs/smart-contracts/anatomy/index.md" | 658 ++++++ .../docs/smart-contracts/compiling/index.md" | 282 +++ .../docs/smart-contracts/deploying/index.md" | 81 + .../developers/docs/smart-contracts/index.md" | 112 ++ .../docs/smart-contracts/languages/index.md" | 326 +++ .../docs/smart-contracts/libraries/index.md" | 117 ++ .../docs/smart-contracts/security/index.md" | 580 ++++++ .../smart-contracts/composability/index.md" | 76 + .../formal-verification/index.md" | 283 +++ .../docs/smart-contracts/testing/index.md" | 308 +++ .../docs/smart-contracts/upgrading/index.md" | 165 ++ .../docs/smart-contracts/verifying/index.md" | 107 + .../hu/21) Whitepaper/whitepaper/index.md | 517 +++++ .../developers/docs/bridges/index.md | 135 ++ .../index.md | 118 ++ .../docs/data-availability/index.md | 84 + .../dex-design-best-practice/index.md | 220 ++ .../heuristics-for-web3/index.md | 138 ++ .../developers/docs/design-and-ux/index.md | 92 + .../developers/docs/mev/index.md | 221 ++ .../developers/docs/oracles/index.md | 433 ++++ .../developers/docs/standards/index.md | 59 + .../docs/standards/tokens/erc-1155/index.md | 146 ++ .../docs/standards/tokens/erc-20/index.md | 172 ++ .../docs/standards/tokens/erc-223/index.md | 197 ++ .../docs/standards/tokens/erc-4626/index.md | 211 ++ .../docs/standards/tokens/erc-721/index.md | 244 +++ .../docs/standards/tokens/erc-777/index.md | 77 + .../developers/docs/standards/tokens/index.md | 39 + .../developers/docs/scaling/index.md" | 114 ++ .../docs/scaling/optimistic-rollups/index.md" | 269 +++ .../developers/docs/scaling/plasma/index.md" | 175 ++ .../docs/scaling/sidechains/index.md" | 73 + .../docs/scaling/state-channels/index.md" | 67 + .../docs/scaling/validium/index.md" | 165 ++ .../docs/scaling/zk-rollups/index.md" | 259 +++ .../data-structures-and-encoding/index.md | 32 + .../patricia-merkle-trie/index.md | 263 +++ .../data-structures-and-encoding/rlp/index.md | 163 ++ .../data-structures-and-encoding/ssz/index.md | 149 ++ .../web3-secret-storage-definition/index.md | 189 ++ .../developers/docs/networking-layer/index.md | 155 ++ .../network-addresses/index.md | 38 + .../networking-layer/portal-network/index.md | 89 + .../hu/26) Miscellaneous/about/index.md | 129 ++ .../hu/26) Miscellaneous/enterprise/index.md | 161 ++ .../hu/26) Miscellaneous/foundation/index.md | 40 + .../contributing/design-principles/index.md | 93 + .../contributing/design/index.md | 77 + .../hu/27) Contributing/contributing/index.md | 117 ++ .../translation-program/faq/index.md | 119 ++ .../how-to-translate/index.md | 89 + .../contributing/translation-program/index.md | 90 + .../mission-and-vision/index.md | 25 + .../translation-program/resources/index.md | 45 + .../translators-guide/index.md | 293 +++ .../adding-desci-projects/index.md | 44 + .../adding-developer-tools/index.md | 61 + .../contributing/adding-exchanges/index.md | 40 + .../adding-glossary-terms/index.md | 26 + .../contributing/adding-layer-2s/index.md | 97 + .../contributing/adding-products/index.md | 100 + .../adding-staking-products/index.md | 176 ++ .../contributing/adding-wallets/index.md | 80 + .../contributing/content-resources/index.md | 32 + .../design/adding-design-resources/index.md | 69 + .../contributing/quizzes/index.md | 62 + public/content/translations/hu/about/index.md | 2 + .../content/translations/hu/bridges/index.md | 9 + .../translations/hu/community/online/index.md | 25 + .../hu/community/support/index.md | 3 +- .../hu/contributing/adding-exchanges/index.md | 2 +- .../adding-glossary-terms/index.md | 2 +- .../adding-staking-products/index.md | 2 +- .../hu/contributing/design/index.md | 10 +- .../translations/hu/contributing/index.md | 2 +- .../how-to-translate/index.md | 2 +- public/content/translations/hu/dao/index.md | 14 +- public/content/translations/hu/defi/index.md | 4 + public/content/translations/hu/desci/index.md | 2 + .../pos/attack-and-defense/index.md | 172 +- .../docs/consensus-mechanisms/pos/index.md | 2 +- .../heuristics-for-web3/index.md | 2 +- .../hu/developers/docs/design-and-ux/index.md | 7 + .../hu/developers/docs/gas/index.md | 1 + .../developers/docs/intro-to-ether/index.md | 2 +- .../hu/developers/docs/mev/index.md | 8 +- .../networking-layer/portal-network/index.md | 10 +- .../hu/developers/docs/networks/index.md | 2 +- .../client-diversity/index.md | 2 +- .../docs/nodes-and-clients/index.md | 8 + .../nodes-and-clients/light-clients/index.md | 2 +- .../docs/scaling/optimistic-rollups/index.md | 6 + .../docs/scaling/state-channels/index.md | 67 + .../docs/scaling/zk-rollups/index.md | 6 + .../docs/standards/tokens/erc-777/index.md | 77 + .../translations/hu/governance/index.md | 2 +- public/content/translations/hu/nft/index.md | 2 +- .../hu/roadmap/verkle-trees/index.md | 4 +- .../content/translations/hu/security/index.md | 2 + .../translations/hu/staking/solo/index.md | 32 +- src/intl/hu/glossary-tooltip.json | 2 +- src/intl/hu/glossary.json | 2 +- src/intl/hu/learn-quizzes.json | 92 +- src/intl/hu/page-bug-bounty.json | 8 +- src/intl/hu/page-community.json | 9 +- src/intl/hu/page-dapps.json | 6 +- src/intl/hu/page-developers-docs.json | 1 + .../hu/page-developers-learning-tools.json | 8 +- src/intl/hu/page-layer-2.json | 139 ++ src/intl/hu/page-staking.json | 27 +- src/intl/hu/page-wallets-find-wallet.json | 2 + 224 files changed, 27670 insertions(+), 197 deletions(-) create mode 100644 public/content/translations/hu/04) Exploring/nft/index.md create mode 100644 public/content/translations/hu/05) Use Ethereum Pages/dao/index.md create mode 100644 public/content/translations/hu/06) Use Cases/defi/index.md create mode 100644 public/content/translations/hu/06) Use Cases/smart-contracts/index.md create mode 100644 public/content/translations/hu/06) Use Cases/web3/index.md create mode 100644 public/content/translations/hu/07) Staking Pages/staking/dvt/index.md create mode 100644 public/content/translations/hu/07) Staking Pages/staking/pools/index.md create mode 100644 public/content/translations/hu/07) Staking Pages/staking/saas/index.md create mode 100644 public/content/translations/hu/07) Staking Pages/staking/solo/index.md create mode 100644 public/content/translations/hu/07) Staking Pages/staking/withdrawals/index.md create mode 100644 public/content/translations/hu/08) Use cases 2/decentralized-identity/index.md create mode 100644 public/content/translations/hu/08) Use cases 2/desci/index.md create mode 100644 public/content/translations/hu/08) Use cases 2/refi/index.md create mode 100644 public/content/translations/hu/08) Use cases 2/social-networks/index.md create mode 100644 public/content/translations/hu/09) Learn Pages/bridges/index.md create mode 100644 public/content/translations/hu/09) Learn Pages/energy-consumption/index.md create mode 100644 public/content/translations/hu/09) Learn Pages/governance/index.md create mode 100644 public/content/translations/hu/09) Learn Pages/security/index.md create mode 100644 public/content/translations/hu/09) Learn Pages/zero-knowledge-proofs/index.md create mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md create mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md create mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md create mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md create mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md create mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md create mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/index.md create mode 100644 public/content/translations/hu/11) Roadmap/eips/index.md create mode 100644 public/content/translations/hu/11) Roadmap/roadmap/beacon-chain/index.md create mode 100644 public/content/translations/hu/11) Roadmap/roadmap/future-proofing/index.md create mode 100644 public/content/translations/hu/11) Roadmap/roadmap/index.md create mode 100644 public/content/translations/hu/11) Roadmap/roadmap/merge/index.md create mode 100644 public/content/translations/hu/11) Roadmap/roadmap/merge/issuance/index.md create mode 100644 public/content/translations/hu/11) Roadmap/roadmap/scaling/index.md create mode 100644 public/content/translations/hu/11) Roadmap/roadmap/security/index.md create mode 100644 public/content/translations/hu/11) Roadmap/roadmap/user-experience/index.md create mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/account-abstraction/index.md create mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/danksharding/index.md create mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/dencun/index.md create mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/pbs/index.md create mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/secret-leader-election/index.md create mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/single-slot-finality/index.md create mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/statelessness/index.md create mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/verkle-trees/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/accounts/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/blocks/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/dapps/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/evm/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/evm/opcodes/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/gas/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ether/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/networks/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/transactions/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/web2-vs-web3/index.md create mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/wrapped-eth/index.md create mode 100644 public/content/translations/hu/14) Community Pages/community/code-of-conduct/index.md create mode 100644 public/content/translations/hu/14) Community Pages/community/events/index.md create mode 100644 public/content/translations/hu/14) Community Pages/community/get-involved/index.md create mode 100644 public/content/translations/hu/14) Community Pages/community/grants/index.md create mode 100644 public/content/translations/hu/14) Community Pages/community/language-resources/index.md create mode 100644 public/content/translations/hu/14) Community Pages/community/online/index.md create mode 100644 public/content/translations/hu/14) Community Pages/community/research/index.md create mode 100644 public/content/translations/hu/14) Community Pages/community/support/index.md create mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" create mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" create mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" create mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" create mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" create mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" create mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" create mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" create mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" create mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" create mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" create mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" create mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" create mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" create mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/elixir/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" create mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" create mode 100644 public/content/translations/hu/19) Learn Pages 2/glossary/index.md create mode 100644 public/content/translations/hu/19) Learn Pages 2/history/index.md create mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" create mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" create mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" create mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" create mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" create mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" create mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" create mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" create mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" create mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" create mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" create mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" create mode 100644 public/content/translations/hu/21) Whitepaper/whitepaper/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/bridges/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/mev/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/oracles/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md create mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/index.md create mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" create mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" create mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" create mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" create mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" create mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" create mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" create mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md create mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md create mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md create mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md create mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md create mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/index.md create mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md create mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md create mode 100644 public/content/translations/hu/26) Miscellaneous/about/index.md create mode 100644 public/content/translations/hu/26) Miscellaneous/enterprise/index.md create mode 100644 public/content/translations/hu/26) Miscellaneous/foundation/index.md create mode 100644 public/content/translations/hu/27) Contributing/contributing/design-principles/index.md create mode 100644 public/content/translations/hu/27) Contributing/contributing/design/index.md create mode 100644 public/content/translations/hu/27) Contributing/contributing/index.md create mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/faq/index.md create mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/how-to-translate/index.md create mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/index.md create mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/mission-and-vision/index.md create mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/resources/index.md create mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/translators-guide/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-desci-projects/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-developer-tools/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-exchanges/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-glossary-terms/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-layer-2s/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-products/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-staking-products/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-wallets/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/content-resources/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/design/adding-design-resources/index.md create mode 100644 public/content/translations/hu/28) Contributing 2/contributing/quizzes/index.md create mode 100644 public/content/translations/hu/developers/docs/scaling/state-channels/index.md create mode 100644 public/content/translations/hu/developers/docs/standards/tokens/erc-777/index.md create mode 100644 src/intl/hu/page-layer-2.json diff --git a/public/content/translations/hu/04) Exploring/nft/index.md b/public/content/translations/hu/04) Exploring/nft/index.md new file mode 100644 index 00000000000..9784c538761 --- /dev/null +++ b/public/content/translations/hu/04) Exploring/nft/index.md @@ -0,0 +1,114 @@ +--- +title: Nem helyettesíthető tokenek (NFT-k) +description: Az NFT-k áttekintése az Ethereum hálózaton +lang: hu +template: use-cases +emoji: ":frame_with_picture:" +sidebarDepth: 2 +image: /images/infrastructure_transparent.png +alt: Egy Eth logó, amely hologram segítségével jelenik meg. +summaryPoint1: Egy módszer arra, hogy egyedi dolgokat Ethereum alapú javakként jelenítsünk meg. +summaryPoint2: Az NFT-k minden korábbinál nagyobb hatalmat adnak a tartalomgyártók kezébe. +summaryPoint3: Az Ethereum blokklánc okosszerződései által működtetve. +--- + +## Mik azok a nem helyettesíthető tokenek (NFT)? {#what-are-nfts} + +Az NFT-k olyan tokenek, amelyek **egyedileg egyediek**. Minden egyes NFT más jellemzőkkel bír (nem helyettesíthető) és bizonyítottan véges. Ez eltér az olyan tokenektől, mint például az [ETH](/glossary/#ether) vagy más Ethereum alapú tokenek, például az USDC, ahol minden token azonos és ugyanazokkal a tulajdonságokkal rendelkezik („cserélhető”). Nem számít, hogy az ember pénztárcájában konkrétan amelyik bankjegy (vagy ETH) található, mert mindegyik azonos és ugyanolyan értékű. Az azonban _valóban_ számít, hogy Ön melyik NFT-t birtokolja, mert egyedi jellemzőik megkülönböztetik azokat egymástól (nem helyettesíthető). + +Az NFT-k egyedisége révén akár műtárgyak, gyűjthető tárgyak vagy ingatlanok is tokenné alakíthatók. Ekkor egy adott egyedi NFT egy specifikus, egyedi, valós vagy digitális tárgyat képvisel. Egy eszköz tulajdonjoga nyilvánosan ellenőrizhető az Ethereum [blokkláncán](/glossary/#blockchain). + + + +## Az eszközök internete {#internet-of-assets} + +Az NFT-k és az Ethereum megoldást jelent néhány, napjainkban az interneten jelen lévő problémára. Ahogy minden egyre digitálisabbá válik, egyre inkább szükség van a fizikai tárgyak bizonyos tulajdonságainak replikálására, mint például a ritkaság, az egyediség és a tulajdonjog bizonyítása úgy, hogy azt nem egy központi szervezet irányítja. Az NFT-kkel például bárki birtokolhat egy mp3-formátumú zeneszámot egyszerre minden Ethereum-alapú alkalmazásban, és nincs hozzákötve egy adott vállalat zenei alkalmazásához, mint amilyen a Spotify vagy az Apple Music. Ön birtokolhat egy közösségi média fogantyút, amelyet eladhat vagy cserélhet, de **nem veheti el önkényesen** egy platformszolgáltató. + +Így néz ki az NFT-k internete ahhoz az internethez képest, amelyet a többségünk minden nap használ... + +### Összehasonlítás {#nft-comparison} + +| Az NFT-k internete | Az internet ma | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Ön birtokolja eszközeit!** Csak Ön adhatja el vagy cserélheti el azokat. | **Ön kikölcsönöz egy eszközt** valamely szervezettől, és azt el is vehetik Öntől. | +| Az NFT-k **digitálisan egyediek**, nincs két egyforma NFT. | **A másolat gyakran nem különböztethető meg** az eredetitől. | +| Az NFT tulajdonjogát a blokklánc tárolja, hogy bárki **nyilvánosan ellenőrizhesse**. | A digitális tételek tulajdonjogi nyilvántartásához való hozzáférést **intézmények ellenőrzik** – azaz szót kell fogadnia. | +| Az NFT-k [okosszerződések](/glossary/#smart-contract) az Ethereumon. Ez azt jelenti, hogy **így könnyen fel lehet azokat használni más okosszerződésekben** és alkalmazásokban az Ethereumon! | A digitális cikkekkel foglalkozó cégek általában **saját „falazott kerti” infrastruktúrát igényelnek**. | +| A tartalom **alkotói bárhol eladhatják munkáikat**, és hozzáférhetnek a globális piachoz. | Az alkotók csak annak a felületnek a hálózatára és disztribúciójára támaszkodhatnak, amelyet használnak. Ezekre gyakran használati feltételek és **földrajzi korlátozások** vonatkoznak. | +| Az NFT alkotói **megtarthatják a tulajdonjogot** saját munkáik felett, és a jogdíjakat közvetlenül az NFT-szerződésbe írhatják be. | A platformok, például a zenei **streaming szolgáltatások, megtartják az értékesítésből származó nyereség nagy részét**. | + +## Mire használják az NFT-ket? {#nft-use-cases} + +Az NFT-ket számtalan esetben használják, ilyen például: + +- egy eseményen való részvétel igazolása +- egy elvégzett képzés bizonyítványa +- a játékokban birtokolható dolgok +- digitális művészet +- valós tárgyak tokenizálása +- online személyazonosság bizonyítása +- hozzáférés bizonyos tartalmakhoz +- jegyek +- decentralizált internetes domainnevek +- biztosíték a [decentralizált finanszírozásban](/glossary/#defi) + +Tegyük fel, hogy Ön egy művész, aki szeretné NFT-ként megosztani az alkotását, anélkül hogy elveszítené az ellenőrzést felette és közvetítőkre áldozná a profitját. Létrehozhat egy új szerződést, amelyben megadja az NFT-k számát, jellemzőiket, és hozzákapcsolja az adott műalkotást. Művészként **beprogramozhatja az intelligens szerződésbe a fizetendő jogdíjakat** (pl. az eladási ár 5%-át utalja át a szerződés tulajdonosának minden alkalommal, amikor NFT-t utalnak át). Azt is mindig bizonyíthatja, hogy Ön hozta létre az NFT-ket, mert Ön a [pénztárca](/glossary/#wallet) tulajdonosa, amely a szerződést telepítette. Vásárlói könnyen igazolhatják, hogy egy **hiteles NFT-vel** rendelkeznek az Ön gyűjteményéből, mert pénztárcájuk [címe](/glossary/#address) az intelligens szerződésben szereplő tokenhez van társítva. Az egész Ethereum-ökoszisztémában használhatják az NFT-t, teljes bizonyossággal az eredetiségét illetően. + + +
Fedezzen fel, vásároljon vagy készítsen saját NFT-műalkotásokat/gyűjthető tárgyakat...
+ + Fedezzen fel NFT-műalkotásokat + + + +Vagy vegyünk például egy sporteseményre szóló jegyet. Ahogy egy **egy esemény szervezője kiválaszthatja, hogy hány jegyet adjon el**, az NFT létrehozója eldöntheti, hogy hány replika létezik. Néha ezek pontos másolatok, mint például 5000 darab nem helyre szóló belépőjegy. Néha több olyan jegyet is kiállítanak, amelyek nagyon hasonlóak, de mindegyik kissé különbözik, mint például kijelölt ülőhelyekre szóló jegyek. Ezeket vehetik és adhatják egymás között (peer-to-peer módon) anélkül, hogy fizetni kellene a jegyárusoknak, a vevő pedig a szerződés címét ellenőrizve mindig meggyőződhet a jegyek eredetiségéről. + +Az ethereum.org webhelyen az **NFT-k segítségével demonstrálják, hogy az emberek érdemben hozzájárultak** a Github-tárhelyünkhöz (programozták a webhelyet, írtak vagy módosítottak egy cikket...), lefordították tartalmainkat vagy részt vettek közösségi felhívásainkon, és még saját NFT domain nevünk is van. Ha hozzájárul az ethereum.org oldalhoz, igényelhet [POAP](/glossary/#poap) NFT-t. Bizonyos kriptotalálkozók POAP-ot (részvételt tanúsító protokollt) használnak jegy gyanánt. [Tudjon meg többet a hozzájárulásról](/contributing/#poap). + +![ethereum.org POAP](./poap.png) + +Ez a weboldal egy alternatív, NFT-k által működtetett domainnévvel is rendelkezik: **ethereum.eth**. Az `.org` címünket központilag egy domainnévrendszer (DNS) szolgáltató kezeli, míg az ethereum`.eth` cím az Ethereum Name Service (ENS) szolgáltatáson keresztül van regisztrálva az Ethereumra. Ezt a mi tulajdonunkban van, és mi kezeljük. [Tekintse meg az ENS-adatainkat](https://app.ens.domains/name/ethereum.eth) + +[Bővebben az ENS-ről](https://app.ens.domains) + + + +## Hogyan működnek az NFT-k? {#how-nfts-work} + +Az NFT-k, ahogy az Ethereum-blokklánc többi digitális eszköze, egy speciális, Ethereum-alapú számítógépes program révén keletkeznek, amelyet okosszerződésnek neveznek. Ezek a szerződések bizonyos szabályokat követnek, például az [ERC-721](/glossary/#erc-721) vagy az [ERC-1155](/glossary/#erc-1155) szabványt, amelyek meghatározzák, hogy a szerződés mire képes. + +Az NFT-okosszerződésekkel számos fontos dolog végrehajtható: + +- **NFT-k létrehozása:** Új NFT-ket lehet alkotni. +- **Tulajdonjog meghatározása:** Követi, hogy amely NFT-nek ki a birtokosa azáltal, hogy azokat meghatározott Ethereum-címekhez köti. +- **Minden NFT-hez azonosítót rendel:** Az NFT-k egy egyedi számmal is el vannak látva. Emellett általában más információkat (metaadatokat) is hozzákapcsolnak az NFT-khez, amellyel feltárják, hogy mit is képviselnek. + +Amikor valaki létrehoz vagy „mintel” egy NFT-t, akkor gyakorlatilag arra kéri az okosszerződést, hogy adjon neki tulajdonjogot egy bizonyos NFT felett. Ez az információ biztos módon és nyilvánosan van tárolva a blokkláncon. + +Ezenkívül a szerződés létrehozója más szabályokat is megadhat. Meghatározhatja, hogy egy adott NFT-ből mennyit lehet létrehozni vagy megadhatja, hogy amikor az NFT tulajdonost vált, akkor egy kis összegű jogdíj járjon neki. + +### Az NFT-k biztonsága {#nft-security} + +Az Ethereum biztonsága a [tét igazolásából](/glossary/#pos) származik. A rendszert úgy tervezték, hogy gazdaságilag visszatartson a rosszindulatú cselekedetektől, így az Ethereum hamisíthatatlan. Ennek köszönhetően létezhetnek az NFT-k. Miután az NFT-tranzakciót tartalmazó [blokk](/glossary/#block) [végleges lesz](/glossary/#finality), a támadónak több millió ETH-jába kerülne annak megváltoztatása. Bárki, aki Ethereum-szoftvert futtat, azonnal képes lenne észlelni az NFT tisztességtelen manipulálását, és a csalárd szereplőt gazdaságilag megbüntetnék és kizárnák. + +Az NFT-kkel kapcsolatos biztonsági problémák leggyakrabban adathalász csalásokhoz, az okosszerződések sebezhetőségéhez vagy felhasználói hibákhoz (például a privát kulcsok véletlen felfedéséhez) kapcsolódnak, így a megfelelő tárcabiztonság kritikus fontosságú az NFT-tulajdonosok számára. + + + Bővebben a biztonságról + + +## További olvasnivaló {#further-reading} + +- [Útmutató az NFT-kről kezdőknek](https://linda.mirror.xyz/df649d61efb92c910464a4e74ae213c4cab150b9cbcc4b7fb6090fc77881a95d) – _Linda Xie, 2020. január _ +- [EtherscanNFT trekker](https://etherscan.io/nft-top-contracts) +- [ERC-721 tokenszabvány](/developers/docs/standards/tokens/erc-721/) +- [ERC-1155 tokenszabvány](/developers/docs/standards/tokens/erc-1155/) +- [Népszerű NFT-applikációk és -eszközök](https://www.ethereum-ecosystem.com/blockchains/ethereum/nfts) + +## Egyéb források {#other-resources} + +- [NFTScan](https://nftscan.com/) + + + + diff --git a/public/content/translations/hu/05) Use Ethereum Pages/dao/index.md b/public/content/translations/hu/05) Use Ethereum Pages/dao/index.md new file mode 100644 index 00000000000..24808b91146 --- /dev/null +++ b/public/content/translations/hu/05) Use Ethereum Pages/dao/index.md @@ -0,0 +1,166 @@ +--- +title: Decentralizált autonóm szervezetek (DAO-k) +description: Az Ethereumon működő DAO-k áttekintése +lang: hu +template: use-cases +emoji: ":handshake:" +sidebarDepth: 2 +image: /images/use-cases/dao-2.png +alt: Egy javaslatra történő DAO-szavazat ábrázolása. +summaryPoint1: Tagtulajdonú közösségek központi vezetők nélkül. +summaryPoint2: Biztonságos módja az interneten történő, ismeretlenekkel való együttműködésnek. +summaryPoint3: Egy biztonságos hely, ahol pénzét adott célokra fordíthatja. +--- + +## Mik azok a DAO-k? {#what-are-daos} + +A DAO egy közös tulajdonú szervezet, amely egy közös küldetésért dolgozik. + +A DAO-k lehetőséget biztosítanak számunkra, hogy hozzánk hasonló elhivatottságú emberekkel dolgozzunk a világ minden tájáról anélkül, hogy egy központi vezetőre bíznánk a pénzügyi és operatív működtetést. Nincs olyan vezérigazgató, aki a kedve szerint költhetné el az alapokat, vagy olyan pénzügyi vezető, aki manipulálhatná a könyvelést. Helyette a kódba épített, blokkláncon alapuló szabályok határozzák meg, hogyan működik a szervezet és kerülnek elköltésre az alapok. + +Beépített pénztárakkal rendelkeznek, amelyekhez a csoport jóváhagyása nélkül senkinek sincs jogosultsága hozzáférni. A döntéseket a javaslatok és a szavazás szabályozzák, így biztosítva, hogy a szervezetben mindenki megszólaljon, és minden átláthatóan, [láncon belül](/glossary/#on-chain) történjen. + +## Miért van szükségünk DAO-kra? {#why-dao} + +Egy pénzügyi forrásokat és pénzt igénylő szervezet indítása nagyon sok bizalmat igényel azon emberek vonatkozásában, akikkel együtt dolgozunk. Azonban nehéz megbízni valakiben, akivel csak az interneten keresztül léptünk kapcsolatba. A DAO-k esetében nem kell megbíznia a csoport többi tagjában, kizárólag a DAO kódjában, mely 100%-ban átlátható és bárki által ellenőrizhető. + +Ennek köszönhetően rengeteg lehetőség nyílik meg a globális együttműködésre és koordinációra. + +### Összehasonlítás {#dao-comparison} + +| DAO | Egy hagyományos szervezet | +| --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | +| Általában lapos és teljesen demokratizált. | Rendszerint hierarchikus. | +| Bármely változtatás végrehajtásához a tagok szavazata szükséges. | A felépítésen alapszik, egyetlen tagtól is követelhető változás, vagy szavazásra is bocsátható a kérdés. | +| A szavazatokat összeszámolják, a szavazás eredményét pedig automatikusan végrehajtják egy megbízott közvetítő nélkül. | Ha megengedett a szavazás, akkor a szavazatokat a szervezeten belül összeszámolják, a szavazás eredményét pedig manuálisan végrehajtják. | +| A szolgáltatásokat automatikusan, decentralizált módon kezelik (például a humanitárius források elosztása). | Emberi közbenjárást igényel, vagy egy központilag irányított automata mechanizmus működteti, mely visszaélésre adhat lehetőséget. | +| Minden tevékenység átlátható és teljesen nyilvános. | A tevékenység jellemzően nem nyilvános, így korlátozott betekintést ad a nyilvánosság számára. | + +### Példák a DAO-ra {#dao-examples} + +Annak érdekében, hogy még érthetőbbé tegyük a DAO-k működését, az alábbiakban néhány példán keresztül bemutatjuk, mire is használhatók: + +- **Egy jótékonysági szervezet** – adományokat fogadhat el a világon bárkitől, és szavazhat arról, hogy mely célokat finanszírozza. +- **Közös tulajdonjog** – vásárolhat fizikai vagy digitális eszközöket, és a tagok szavazhatnak a használatukról. +- **Kockázati tőke és támogatás** – létrehozhat egy kockázatitőke-alapot, mely befektetési tőkét gyűjt, és szavazással válaszhatók ki a támogatandó vállalkozások. A visszaérkező összegeket pedig később szétoszthatják a DAO tagjai között. + + + +## Hogyan működnek a DAO-k? {#how-daos-work} + +A DAO gerincét az [intelligens szerződés](/glossary/#smart-contract) adja, amely meghatározza a szervezet szabályait és birtokolja a csoport pénztárát. Amint a szerződés életbe lép az Ethereumon, csakis szavazás útján lehet módosítani a szabályokat. Ha valaki olyat próbál tenni, ami nem szerepel a szabályokban és a programlogikában, az meghiúsul. Mivel a társaság pénzügyeit is az okosszerződés határozza meg, ezért a csoport jóváhagyása nélkül senki sem költheti el a pénzösszegeket. Tehát a DAO-nak nincs szüksége központi hatóságra. Ehelyett a csoport közösen hoz döntéseket, a kifizetések pedig automatikusan jóváhagyásra kerülnek a szavazás eredményeként. + +Mindez azért lehetséges, mert az okosszerződést nem lehet önkényesen megváltoztatni vagy meghamisítani, amikor már életbe lépett az Ethereumon. Senki sem tudja módosítani a programkódot (a DAO szabályait) anélkül, hogy mások azt észre ne vennék, mivel minden nyilvános. + +## Az Ethereum és a DAO-k {#ethereum-and-daos} + +Az Ethereum tökéletes alapot szolgáltat a DAO-knak számtalan okból kifolyólag: + +- Az Ethereum saját konszenzusa decentralizált és eléggé megalapozott ahhoz, hogy a szervezetek megbízhassanak a hálózatban. +- Az okosszerződés tartalmát nem lehet módosítani, miután életbe lépett, még a tulajdonosok sem módosíthatják azt. Ennek következtében a DAO a meghatározott szabályok alapján fog működni. +- Az okosszerződések képesek pénzeszközöket küldeni és fogadni. Enélkül szükség lenne egy megbízható közvetítőre, aki a csoport eszközeit kezelné. +- Az Ethereum közössége bizonyítottan együttműködő, nem versenyszellemű, így a bevált gyakorlatok és a támogatórendszerek gyorsan kialakulnak. + +## A DAO irányítása {#dao-governance} + +A DAO irányításakor számtalan szempontot figyelembe kell venni, mint például a szavazás menete és a javaslatok kezelése. + +### Delegáció {#governance-delegation} + +A delegáció vagy felhatalmazás a DAO verziója a képviselőalapú demokráciának. A tokenek birtokosai átadják szavazati jogaikat olyan felhasználóknak, akik vállalják, hogy felügyelik a protokollt és tájékozódnak az ügyeket illetően. + +#### Egy híres példa {#governance-example} + +[ENS](https://claim.ens.domains/delegate-ranking) – Az ENS-tulajdonosok átruházhatják szavazataikat a közösség elkötelezett tagjaira, hogy képviseljék őket. + +### Automatikus tranzakciókon alapuló irányítás {#governance-example} + +Számos DAO-nál a tranzakciók automatikusan végrehajtódnak, ha a tagok határozatképes létszámban megszavazzák azt. + +#### Egy híres példa {#governance-example} + +[Főnevek](https://nouns.wtf) – A Nouns DAO-ban a tranzakció automatikusan végrehajtásra kerül, ha a szavazatok határozatképessége teljesül, és a többség igennel szavaz, mindaddig, amíg az alapítók nem vétózzák meg. + +### Több aláírásos irányítás {#governance-example} + +Míg a DAO-k több ezer szavazati joggal rendelkező taggal rendelkezhetnek, az alapok egy [pénztárcában](/glossary/#wallet) élhetnek, amelyen 5-20 aktív közösségtag osztozik, akikben megbíznak és általában doxxelnek (a közösség által ismert nyilvános identitások). Szavazás után a [multisig](/glossary/#multisig) aláírók végrehajtják a közösség akaratát. + +## A DAO törvényei {#dao-laws} + +1977-ben Wyoming megalkotta a korlátolt felelősségű társasági formát, mely megvédi a vállalkozót és behatárolja a felelősségi körüket. Nemrég elsőként hozták létre a DAO-kra vonatkozó törvényt, mely jogi státuszt ad a DAO-knak. Jelenleg Wyoming, Vermont és a Virgin-szigetek rendelkeznek DAO-törvénnyel valamilyen formában. + +### Egy híres példa {#law-example} + +[CityDAO](https://citydao.io) – A CityDAO 40 hektár földet vett a Yellowstone Nemzeti Park közelében Wyoming DAO-törvényével élve. + +## DAO-tagság {#dao-membership} + +A DAO-tagságra különféle modellek léteznek. A tagság meghatározza a szavazás menetét, illetve a DAO más kulcsfontosságú részleteit. + +### Tokenalapú tagság {#token-based-membership} + +Általában teljesen [engedély nélküli](/glossary/#permissionless), a használt tokentől függően. Ezekkel az irányítási tokenekkel többnyire engedély nélkül lehet kereskedni [decentralizált tőzsdén](/glossary/#dex). Más tokenek megszerzéséhez likviditást kell biztosítani vagy más munkaigazolás (proof-of-work) szükséges. Bármelyik módon is jut hozzá, a token maga biztosítja a szavazati jogot. + +_Főleg arra használják, hogy kiterjedt, decentralizált protokollokat és/vagy magukat a tokeneket irányítsák ezáltal._ + +#### Egy híres példa {#token-example} + +[MakerDAO](https://makerdao.com) – A MakerDAO tokenje, az MKR, széles körben elérhető a decentralizált tőzsdéken, s bárki beszerezheti azokat, hogy szavazati jogot nyerjen a Maker protokoll jövőjére vonatkozóan. + +### Részesedésalapú tagság {#share-based-membership} + +A részesedésalapú DAO-k sokkal inkább engedélyhez kötöttek, de még mindig elég nyitottak. Bármelyik leendő tag beadhat egy csatlakozási kérvényt, melyben általában felajánl valamilyen értéket tokenek vagy elvégzendő munka (például számítási kapacitás) formájában. A részesedés közvetlen szavazati és tulajdonjogot jelent. A tagok bármikor kiléphetnek az arányos részesedésükkel együtt. + +_Főleg a szorosabb szerveződésű, emberközpontú szervezetek használják, mint az adománygyűjtők, munkaközösségek és befektetési klubok. Ezt is használhatják protokollok és tokenek irányítására._ + +#### Egy híres példa {#share-example} + +[MolochDAO](http://molochdao.com/) – A MolochDAO az Ethereum projektek finanszírozására összpontosít. A tagságot kérvényezni kell, melynek alapján a csoport eldönti, vajon az új tag rendelkezik a szükséges szakértelemmel és tőkével, hogy megfelelő döntést tudjon hozni a lehetséges támogatottakról. Nem lehetséges megvásárolni a DAO-tagságot a piacon. + +### Reputációalapú tagság {#reputation-based-membership} + +A reputáció a részvételt igazolja és szavazati jogot biztosít a DAO-ban. A token- és részesedésalapú tagsággal ellentétben a reputációalapú DAO nem ad tulajdonjogot a közreműködőknek. A reputációt nem lehet megvenni, átadni vagy delegálni; a DAO tagok a részvételükkel nyerik el azt. A láncon belüli szavazás nem engedélyhez kötött, a leendő tagok szabadon kérvényezhetik a DAO-hoz való csatlakozást, illetve azt, hogy a közreműködésükért cserébe reputációt és tokent kapjanak. + +_Jellemzően protokollok és [dapp-ok](/glossary/#dapp) decentralizált fejlesztésére és irányítására használják, de kiválóan alkalmas különféle szervezetek, például jótékonysági szervezetek, munkavállalói kollektívák, befektetési klubok stb. számára is_ + +#### Egy híres példa {#reputation-example} + +[DXdao](https://DXdao.eth.limo) – A DXdao egy független globális csoportosulás, amely 2019 óta épít és irányít decentralizált protokollokat és alkalmazásokat. A hírnév alapú kormányzást és a [holografikus konszenzust](/glossary/#holographic-consensus) használja az alapok koordinálásához és kezeléséhez, ami azt jelenti, hogy senki sem vásárolhatja meg a tagságot a szervezet jövőjének vagy irányításának befolyásolása céljából. + +## Csatlakozás DAO-hoz / DAO indítása {#join-start-a-dao} + +### Csatlakozzon egy DAO-hoz {#join-a-dao} + +- [Az Ethereum-közösséghez tartozó DAO-k](/community/get-involved/#decentralized-autonomous-organizations-daos) +- [DAOHaus által listázott DAO-k](https://app.daohaus.club/explore) +- [Tally.xyz által listázott DAO-k](https://www.tally.xyz) + +### DAO indítása {#start-a-dao} + +- [Indítson DAO-t a DAOHaus-szal](https://app.daohaus.club/summon) +- [Indítson irányító DAO-t a Tally-vel](https://www.tally.xyz/add-a-dao) +- [Hozzon létre egy Aragon által működtetett DAO-t](https://aragon.org/product) +- [Hozzon létre csoportot a Colony-val](https://colony.io/) +- [Indítson DAO-t a DAOstack által biztosított holografikus konszenzussal](https://alchemy.daostack.io/daos/create) + +## További információ {#further-reading} + +### DAO-ról szóló cikkek {#dao-articles} + +- [Mi az a DAO?](https://aragon.org/dao) – [Aragon](https://aragon.org/) +- [DAO-k háza](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/) +- [Mi az a DAO és mire jó?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/) +- [Hogyan lehet létrehozni egy DAO által működtetett digitális közösséget](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/) +- [Mi az a DAO?](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com) +- [Mi az a holografikus konszenzus?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) – [DAOstack](https://daostack.io/) +- [A DAO-k nem vállalatok: hol van a legnagyobb jelentősége a decentralizációnak az autonóm szervezetekben – Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html) +- [DAO, DAC, DA és mások: egy nem teljes terminológiai útmutató](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) – [Ethereum Blog](https://blog.ethereum.org) + +### Videók {#videos} + +- [Mit jelent a DAO a kripto világában?](https://youtu.be/KHm0uUPqmVE) +- [Felépíthet egy várost egy DAO?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/) + + + + diff --git a/public/content/translations/hu/06) Use Cases/defi/index.md b/public/content/translations/hu/06) Use Cases/defi/index.md new file mode 100644 index 00000000000..c800034cc64 --- /dev/null +++ b/public/content/translations/hu/06) Use Cases/defi/index.md @@ -0,0 +1,361 @@ +--- +title: Decentralizált pénzügy (DeFi) +description: Az Ethereumon működő decentralizált pénzügyek (DeFi) áttekintése +lang: hu +template: use-cases +emoji: ":money_with_wings:" +image: /images/use-cases/defi.png +alt: Egy LEGO építőkockákból készült Ethereum-logó. +sidebarDepth: 2 +summaryPoint1: Egy globális és nyitott alternatívája a jelenlegi pénzügyi rendszernek. +summaryPoint2: Olyan termékek, melyek révén kölcsönözhet, megtakaríthat, befektethet, kereskedhet és ez még nem minden. +summaryPoint3: Nyíltforráskódú technológián alapszik, melyre bárki fejleszthet megoldásokat. +--- + +A decentralizált pénzügyek (DeFi) egy nyílt és globális pénzügyi rendszer, mely az internet korához igazodik – alternatívája annak, ami alig átlátható, szorosan kontrollált és sok évtizedes infrastruktúrák és folyamatok tartják össze. A DeFi kontrollt és átláthatóságot biztosít a pénzeszközök felett. Lehetőséget ad arra, hogy a globális piacokon működjön és alternatívát biztosít a helyi valuták vagy bankolási lehetőségek helyett. A DeFi termékek mindenki számára elérhetővé teszik a pénzügyi szolgáltatásokat, aki internetkapcsolattal rendelkezik, és nagy arányban maguk a felhasználók tulajdonolják és kezelik ezeket. Eddig több tízmilliárd dollárnyi kripto áramlott keresztül a DeFi alkalmazásokon, és ez minden egyes nappal növekszik. + +## Mi az a DeFi? {#what-is-defi} + +A DeFi egy gyűjtőfogalom azokra a pénzügyi termékekre és szolgáltatásokra vonatkozóan, melyek mindenki számára elérhetők az Ethereum hálózatát használva – bárkinek, aki rendelkezik internetkapcsolattal. A DeFi révén a piacok állandóan nyitva vannak és nincs olyan központi hatóság, amely megakadályozhatna egy kifizetést vagy megtilthatná a hozzáférést valamilyen termékhez. Azok a szolgáltatások, melyek korábban lassúak voltak és az emberi hiba kockázatát hordozták magukban, most automatikusak és biztonságokat, mivel egy olyan programkód üzemelteti azokat, melyet bárki megvizsgálhat. + +Egy gyorsan fejlődő kriptogazdaság található itt, ahol Ön is adhat és vehet fel kölcsönt, kereskedhet long/short pozíciókkal, kamatoztathat stb. A kriptóhoz értő argentinok arra használták a DeFi-t, hogy kilépjenek a bénító inflációs helyzetből. Bizonyos vállalatok elkezdték a munkavállalóik fizetést valós időben átutalni (streaming). Néhány személy több millió dollárt érő hitelt vett fel és fizetett vissza anélkül, hogy bármilyen módon igazolnia kellett volna a személyazonosságát. + + + +## A DeFi és a hagyományos pénzügyek összehasonlítása {#defi-vs-tradfi} + +A DeFi-ban rejlő lehetőségeket talán úgy lehet legjobban megragadni, ha megértjük a jelenlegi problémákat. + +- Az emberek egy bizonyos rétege nem nyithat bankszámlát vagy használhat pénzügyi szolgáltatásokat. +- Ha valaki nem fér hozzá a pénzügyi szolgáltatásokhoz, akkor nem is tud munkát vállalni. +- A pénzügyi szolgáltatások megakadályozhatják, hogy Ön hozzáférjen a pénzeszközeihez. +- A pénzügyi szolgáltatások egyik rejtett ára, hogy hozzáférnek a személyes adataihoz. +- A kormányok és központi hatóságok bármikor lezárhatják a pénzügyi piacokat. +- A kereskedés időszaka gyakran egy adott időzónában meghatározott munkaidőre korlátozódik. +- Az átutalások több napig is eltarthatnak a közbenső, manuális folyamatok miatt. +- A pénzügyi szolgáltatásokért extra díjat kell fizetni, mert a közvetítő intézmények is kiveszik a részüket. + +### Összehasonlítás {#defi-comparison} + +| DeFi | Hagyományos pénzügyek | +| ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | +| Ön rendelkezik a saját pénzeszközei felett. | Az Ön pénze a vállalatok kezében van. | +| Ön dönti el, hogy a pénzét hol tartja és mire költi el. | Meg kell bíznia a vállalatokban, hogy nem élnek vissza a pénzeszközeivel, például nem adják kölcsön azokat kockázatos ügyfeleknek. | +| A pénzeszközök átutalása perceken belül megtörténik. | Az átutalás napokig is eltarthat a manuális lépések miatt. | +| A tranzakciók nem közvetlen módon köthetők a személyazonossághoz. | A pénzügyi tevékenységek szorosan kapcsolódnak az identitáshoz. | +| A DeFi mindenki előtt nyitva áll. | A pénzügyi szolgáltatásokat igényelni kell. | +| A pénzpiacok mindig nyitva vannak. | A pénzpiacok bezárnak, mert az alkalmazottaknak pihenésre van szükségük. | +| Az átláthatóságra épül – bárki megtekintheti az adott termék adatait és megvizsgálhatja, hogyan működik a rendszer. | A pénzügyi intézmények zárt könyvek számunkra: nem kérheti el senki a hitelezési feljegyzéseiket, az eszközeik leltárát stb. | + + + Fedezze fel a DeFi alkalmazásokat + + +## Minden a Bitcoinnal kezdődött... {#bitcoin} + +A Bitcoin több szempontból is az első DeFi alkalmazás volt. A Bitcoin lehetővé tette, hogy a felhasználó valóban birtokolja és kontrollálja az értéket, és elküldje azt a világon bárhova. Ehhez pedig egy olyan módszert adott egy nagy létszámú, egymásban nem bízó csoport kezébe, amellyel közvetítő megbízása nélkül egyezhetnek meg a számlafőkönyv tartalmán. A Bitcoin mindenki számára nyitott és senki sem tudja megváltoztatni a szabályait. A szabályai, ahogy a végessége és a nyitottsága is bele van kódolva a technológiába. Ez teljesen eltér a hagyományos pénzügyektől, ahol a kormány pénzt nyomtathat, mely csökkenti a megtakarítások értékét, a cégek pedig lezárhatják a pénzügyi piacokat. + +Az Ethereum is erre épít. A Bitcoinhoz hasonlóan a szabályokat nem változtathatja meg senki, és mindenkinek van hozzáférése. Ezen felül a digitális pénzt programozhatóvá teszi az [okosszerződések](/glossary/#smart-contract) által, így az értékek tárolásán és küldésén kívül sok másra is alkalmas. + + + +## Programozható pénz {#programmable-money} + +Ez furcsán hangzik... „miért akarnám programozni a pénzemet”? Ez azonban több, mint az Ethereum tokenjeinek alaptulajdonsága. Bárki programozhat valamilyen logikát a kifizetések kezelésébe. Így rendelkezhet a Bitcoin által nyújtott kontrollal és biztonsággal, a pénzügyi intézmények által nyújtott szolgáltatásokkal kombinálva azt. Lehetővé válik, hogy a kriptovalutával olyan műveleteket is véghezvigyen a felhasználó, amit a Bitcoin nem támogat, mint például kölcsön adás és kölcsön vétel, időzített kifizetések, indexalapokba való befektetés stb. + + +
Tekintse át azokat a DeFi alkalmazásokat, melyeket kipróbálásra javaslunk, amennyiben Ön most ismerkedik az Ethereummal.
+ + Fedezze fel a DeFi alkalmazásokat + + + +## Mit lehet csinálni a DeFi-ban? {#defi-use-cases} + +A legtöbb pénzügyi szolgáltatásnak létezik decentralizált alternatívája. Az Ethereum emellett olyan lehetőségeket teremt, hogy teljesen új pénzügyi termékek is létrejöhessenek. Ez egy folyamatosan bővülő lista. + +- [Pénzküldés a világ bármelyik pontjára](#send-money) +- [Pénzáramoltatás (streaming) a világon bárhova](#stream-money) +- [Stabil pénznemek használata](#stablecoins) +- [Kölcsönfelvétel fedezettel](#lending) +- [Kölcsönfelvétel fedezet nélkül](#flash-loans) +- [Megtakarítás kriptóval](#saving) +- [Kereskedés tokenekkel](#swaps) +- [Portfóliófejlesztés](#investing) +- [Közösségi elképzelések finanszírozása](#crowdfunding) +- [Biztosítás vásárlása](#insurance) +- [Portfóliókezelés](#aggregators) + + + +### Azonnali pénzküldés a világ bármelyik pontjára {#send-money} + +Az Ethereum-blokklánc úgy van kialakítva, hogy biztonságosan és globálisan kezeljen tranzakciókat. A Bitcoinhoz hasonlóan az Ethereumon is olyan könnyen lehet pénzt utalni, akár egy e-mailt elküldeni. Csak írja be a fogadó fél [ENS-nevét](/glossary/#ens) (például bob.eth) vagy számlacímét a tárcájában, és az utalás közvetlenül megérkezik hozzá általában percek alatt. Az utalások küldéséhez vagy fogadásához szükség van egy [tárcára](/wallets/). + + + Tovább a fizetési dappokhoz + + +#### Pénzáramoltatás (streaming) a világon bárhova... {#stream-money} + +Az Ethereumon pénzáramoltatásra is lehetőség van. Ez lehetővé teszi, hogy valós időben kapja meg valaki a fizetését, így a pénzeszközei mindig rendelkezésre állnak. Vagy kölcsönözhet is valamit addig, amíg azt használja, mint egy tárolóhely vagy elektromos robogó. + +Ha pedig nem akar [ETH-t](/glossary/#ether) küldeni vagy áramoltatni, mert annak változhat az értéke, akkor alternatív valuták is rendelkezésre állnak az Ethereumon: ezek a [stabil érmék](/glossary/#stablecoin). + + + +### Stabil pénznemek használata {#stablecoins} + +A kriptovaluta változékonysága számos pénzügyi termék és általános költés esetén problémát okoz. A DeFi közösség ezt a stabil érmékkel oldotta meg. Ezek értéke hozzá van kötve egy másik eszközhöz, általában egy népszerű valutához, mint amilyen a dollár. + +Az olyan érmék értéke, mint a Dai vagy a USDC, csak néhány centtel változik. Ezért tökéletesen megfelelnek a munkabér kifizetésre vagy a kiskereskedelem számára. Dél-Amerikában számtalan ember használt stabil érméket, hogy megvédje a megtakarításait, amikor a kormányzat által kibocsátott valuták bizonytalan helyzetbe kerültek. + + + Bővebben a stabil érmékről + + + + +### Kölcsönfelvétel {#lending} + +A kölcsönfelvétel a decentralizált szolgáltatóktól kétféle módon valósulhat meg. + +- Peer-to-peer (P2P), amikor a kölcsön felvevője közvetlenül egy meghatározott kölcsönadótól kap pénzt. +- Gyűjtőszámlás (pool), amikor a kölcsönadó pénzeszközt biztosít (likviditás) a gyűjtőszámlának, amelytől a kölcsönvevők pénzt tudnak szerezni. + + + Tovább a kölcsönfelvételi dappokhoz + + +Számos előnye van annak, ha decentralizált kölcsönadót használunk... + +#### A kölcsönfelvétel magán jellegének megőrzése {#borrowing-privacy} + +Manapság a pénz kölcsönadása és -vétele az abban résztvevő egyének köré rendeződik. A bank tudni akarja, hogy vissza fogja-e fizetni a kölcsönt annak igénylője, mielőtt odaítélné neki. + +A decentralizált kölcsönzésnél a feleknek nem kell azonosítaniuk magukat. Ehelyett a kölcsönvevő fedezetet ad, melyet a kölcsönadó automatikusan megkap, ha a kölcsönt nem fizeti vissza. Néhány kölcsönadó [NFT-ket](/glossary/#nft) is elfogad fedezet gyanánt. Az NFT-k olyan okiratok, melyek egy egyedi eszközhöz kapcsolódnak, mint például egy festmény. [Bővebben az NFT-kről](/nft/) + +Így anélkül lehet pénzt kölcsönözni, hogy hitelellenőrzést kellene végezni vagy személyes információkat átadni. + +#### Globális alapokhoz való hozzáférés {#access-global-funds} + +Amikor valaki decentralizált kölcsönadóhoz fordul, akkor az egész világon letétbe helyezett alapok válnak számára elérhetővé, nem csak azok az eszközök, melyeket a kiválasztott bankban vagy intézményben elhelyeztek. Ez sokkal elérhetőbbé teszi a kölcsönt és jobb kamatozást is biztosít. + +#### Adóhatékonyság {#tax-efficiencies} + +A kölcsönfelvétel révén hozzáférhet a szükséges eszközökhöz, így nem kell eladnia a rendelkezésére álló ETH-t (melynek adóvonzata van). Ehelyett használhatja az ETH-t fedezetként egy stabilérme-kölcsönhöz. Így a szükséges pénz is rendelkezésére áll, és az ETH-t is megtarthatja. A stabil érmék olyan tokenek, melyek előnyösebbek, ha készpénzre van szüksége, mert az értékük nem változik annyira, mint az ETH esetében. [Bővebben a stabil érmékről](#stablecoins) + +#### Villámkölcsönök {#flash-loans} + +A villámkölcsön a decentralizált kölcsönzés kísérleti jellegű formája, amikor fedezet nélkül, illetve bármiféle személyes adat átadása nélkül tud valaki kölcsönt felvenni. + +Ezek jelenleg nem érhetők el kiterjedt körben a nem technikai felhasználók között, de arrafelé mutatnak, ami a jövőben mindenki számára rendelkezésre fog állni. + +Azon az alapon működik, hogy a kölcsönt ugyanabban a tranzakcióban veszik fel és fizetik vissza. Ha nem tudják visszafizetni, akkor a tranzakció visszafordul, mintha nem is történt volna semmi. + +A kölcsönzéshez használt pénzeszközök likviditási gyűjtőszámlákon találhatók (nagy mennyiségű pénzeszközök kölcsönzési célra). Ha egy adott pillanatban nem használják azokat, akkor egy személynek lehetősége van kölcsönvenni az eszközöket, üzletet hajtani végre azokkal, és egyszerre visszafizetni azokat, szinte a kölcsönzéssel azonos időben. + +Ily módon rengeteg logikát kell belefoglalni egy ilyen magáért beszélő tranzakcióba. Erre egy egyszerű példa az lehet, hogy valaki arra használja a villámkölcsönt, hogy egy adott eszközből a lehető legtöbbet beszerezze egy adott áron, és eladja azt egy másik tőzsdén, ahol az ár magasabb. + +Így egyetlen tranzakcióban a következők történnek: + +- X összegű $asset-et kölcsönöz 1,00 $ értéken az A tőzsdén +- Az X összegű $asset-et eladja 1,10 $ értéken a B tőzsdén +- Visszafizeti a kölcsönt az A tőzsdének +- A profit mínusz a tranzakciós költség az Ön nyeresége + +Ha a B tőzsdén lévő kínálat hirtelen lezuhan, és a felhasználó nem tudott eleget vásárolni ahhoz, hogy lefedje az eredeti kölcsönt, akkor a tranzakció egyszerűen visszafordul. + +Ha a hagyományos pénzügyi világban szeretne ugyanilyen ügyletet végrehajtani, akkor hatalmas pénzösszegre van szüksége. Ezek a pénzkereső stratégiák csak azoknak elérhetők, akik már most is vagyonosak. A villámkölcsön egy olyan jövőt fest elénk, melyben a pénzcsinálásnak nem előfeltétele az, hogy az ember vagyonos legyen. + + + Bővebben a villámkölcsönökről + + + + +### Kezdjen el pénzt megtakarítani a kriptóval {#saving} + +#### Kölcsönadás {#lending} + +A rendelkezésére álló kriptovaluta kölcsönadásával kamatot kaphat, így pénzeszközei folyamatosan növekednek. Jelenleg a kamatráták sokkal magasabbak, mint a helyi bankokban (ha egyáltalán van elérhető bank a közelében). Itt egy példa: + +- Kölcsönadja a rendelkezésére álló 100 Dai-t, ami egy [stabil érme](/stablecoins/), egy olyan termékért, mint az Aave. +- Kap 100 Aave Dai-t (aDai), mely egy token, és a kölcsönadott Dai-t reprezentálja. +- Az aDai növekedni fog a kamatráta alapján, így Ön láthatja, ahogy az egyenlege növekszik a tárcájában. Az [éves ráta (APR)](/glossary/#apr) függvényében az Ön tárcaegyenlege akár néhány napon vagy órán belül már 100,1234 összeget mutathat! +- Bármikor visszavonhat bármekkora Dai összeget, ami megegyezik az Ön aDai egyenlegével. + + + Tovább a kölcsönadási dappokhoz + + +#### Veszteség nélküli lottó {#no-loss-lotteries} + +A veszteség nélküli lottók, mint a PoolTogether, szórakoztató és innovatív módszerek a megtakarításokra. + +- Vásárol 100 jegyet 100 Dai tokenért. +- Kap 100 plDai-t, ami a 100 jegyet reprezentálja. +- Ha valamelyik jegyét kisorsolják, a plDai egyenlege megnövekszik a nyeremény összegével. +- Ha nem nyer, akkor a 100 plDai átgördül a következő heti sorsolásra. +- Bármikor visszavonhat bármekkora Dai összeget, ami megegyezik az Ön plDai egyenlegével. + +A rendelkezésre álló nyeremény abból a kamatból keletkezik, amit a jegyvásárláson összegyűjtött összeg kölcsönadásából szereznek, ahogy azt a fenti példa is mutatja. + + + Próbálja ki a PoolTogether lehetőséget + + + + +### Kereskedés a tokenekkel {#swaps} + +Az Ethereumon ezernyi token elérhető. A decentralizált tőzsdék (DEX) lehetővé teszik, hogy a felhasználók a különféle tokenekkel bármikor kereskedjenek. Eközben az eszközök feletti kontroll végig megmarad. Olyan, mint amikor az ember egy másik országba utazik és valutaváltót használ. Ugyanakkor a DeFi sosem zár be. A pénzpiacok folyamatosan nyitva vannak (az év 365 napján, napi 24 órában), a technológia pedig garantálja, hogy mindig van, aki elfogadja az ügyletet. + +Például, ha Ön szeretné használni a veszteség nélküli lottózást, a PoolTogether-t (ahogy fentebb írtuk), szüksége lesz Dai vagy USDC tokenre. A decentralizált tőzsdén átválthatja a kívánt ETH-összeget ezekre a tokenekre, majd vissza, amikor végzett az ügylettel. + + + Tovább a tokenes tőzsdékre + + + + +### Haladó szintű kereskedés {#trading} + +Haladóbb lehetőségek is rendelkezésre állnak azoknak a kereskedőknek, akik több kontrollt szeretnének. Lehetségesek a meghatározott áron történő vételi/eladási megbízások (limit order), határidős ügyletek, tőkeáttétes kereskedések és még sok más. A decentralizált kereskedés során Ön hozzáfér a globális likviditáshoz, a piac sosem zár be, az eszközök feletti kontroll pedig mindig az Ön kezében van. + +A centralizált tőzsdéken ehhez képest letétbe kell helyezni az eszközöket a kereskedés előtt, és meg kell bízni bennük, hogy azt megfelelően kezelik. Miközben az eszköz letétben van náluk, nincs biztonságban, mert a centralizált tőzsdék a hackerek kedvelt célpontjai. + + + Tovább a kereskedő dappokhoz + + + + +### Portfóliófejlesztés {#investing} + +Az Ethereumon találhatók olyan alapkezelő termékek, melyek az Ön által választott stratégia mentén megpróbálják megnövelni portfóliója értékét. Mindez automata, mindenki számára nyitott, és nem igényel kezelőt, aki a profitból levenné a saját részét. + +Egy jó példa erre a [DeFi Pulse Index fund (DPI)](https://defipulse.com/blog/defi-pulse-index/). Ez az alap automatikusan kiigazítja az Ön portfólióját, hogy az állandóan a legjobb DeFi-tokeneket tartalmazza az aktuális piaci értékük alapján. Önnek nem kell foglalkoznia a részletekkel, és bármikor visszavonhatja pénzeszközeit az alapból. + + + Tovább a befektetési dappokhoz + + + + +### Közösségi elképzelések finanszírozása {#crowdfunding} + +Az Ethereum egy tökéletes platform arra, hogy a közösség segítségével finanszírozzon bizonyos elképzeléseket: + +- A lehetséges finanszírozók bárhonnan jöhetnek – az Ethereum és a tokenjei mindenkinek elérhetők, a világon bárhol. +- Átlátható, így az adománygyűjtők igazolni tudják, hogy mennyi pénz jött össze. Azt is nyomon lehet követni, hogy a pénz hogyan lett elköltve. +- Az adománygyűjtők automatikus visszatérítést is be tudnak állítani, például ha egy adott határidőre nem jön össze a minimális összeg. + + + Tovább a közösségi finanszírozás dappokhoz + + +#### Kvadratikus finanszírozás {#quadratic-funding} + +Az Ethereum egy nyílt forráskódú program, és az eddigi fejlesztések nagy részét a közösség finanszírozta. Ez vezetett el egy érdekes és új modellhez: a kvadratikus finanszírozáshoz. Ennek lehetősége van azt a módot továbbfejleszteni, ahogy a közjavak finanszírozását kezelhetjük. + +A kvadratikus finanszírozás gondoskodik arról, hogy azok a projektek kapják a finanszírozást, amelyre tényleg a legnagyobb az igény. Tehát azokat támogatjuk, amelyek a leginkább magasabb szintre emelik az emberek életét. Így működik: + +1. Az adományozott pénzösszegek egy alapba (matching pool) kerülnek. +2. Megkezdődik a nyilvános adománygyűjtés. +3. Az emberek úgy jelezhetik, hogy számukra fontos egy adott projekt, hogy pénzt adományoznak rá. +4. Az adománygyűjtés lezártával az alapot szétosztják a projektek között. Ebből az alapból az a projekt kapja a legmagasabb összeget, amelyre a leginkább igényt tartanak az adományozók. + +Eszerint az A projekt, mely 100 adományt kapott, egyenként 1 $ értékben, több finanszírozást kaphat az alapból, mint a B projekt, mely egyetlen adományt kapott 10 000 $ értékben (a kapott összeg az alap méretén múlik). + + + Bővebben a kvadratikus finanszírozásról + + + + +### Biztosítások {#insurance} + +A decentralizált biztosítások célja, hogy azok olcsóbbak, sokkal átláthatóbbak legyenek, és gyorsabb legyen a kifizetés. Az automatizálásnak köszönhetően a biztosítás általi lefedettség megfizethetőbb, a kifizetések pedig gyorsabbak. Az igénybejelentéshez használt adatok teljesen transzparensek. + +Az Ethereum termékei, mint bármelyik szoftver, tartalmazhatnak hibákat és sebezhető pontokat. Emiatt jelenleg sok biztosítási megoldás a felhasználók eszközeinek elvesztése ellen ad védelmet. Ugyanakkor vannak olyan projektek, melyek elkezdtek kialakítani az élet többi eseményére vonatkozóan is biztosításokat. Egy jó példa erre az Etherisc's Crop biztosítása, melynek célja [a kisméretű, kenyai gazdálkodók védelme az aszály és az árvíz ellen](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc). A decentralizált biztosítás olcsóbb megoldást tud kínálni a gazdálkodóknak, akiknek a hagyományos biztosítók általában megfizethetetlenek. + + + Tovább a biztosítási dappokhoz + + + + +### Gyűjtőhelyek és portfóliókezelők {#aggregators} + +Amikor ennyi minden zajlik, Önnek is szüksége lehet egy olyan megoldásra, mellyel a befektetéseit, kölcsöneit és kereskedéseit figyelemmel követheti. Rengeteg olyan termék elérhető, melyekkel egyetlen helyről tudja az összes DeFi tevékenységét koordinálni. Ez a DeFi nyílt architektúrájának szépsége. A csapatok olyan interface-eket építenek, melyekkel nemcsak az összes termék kapcsán láthatja az egyenlegét, hanem használhatja azok tulajdonságait is. Amint Ön is jobban elmélyül a DeFi világában, hasznosnak fogja ezt találni. + + + Tovább a portfóliós dappokhoz + + + + +## Hogyan működik a DeFi? {#how-defi-works} + +A decentralizált pénzügyek (DeFi) kriptovalutákat és okosszerződéseket használnak ahhoz, hogy közvetítő nélküli szolgáltatásokat adjanak. A mai pénzügyi világban a pénzintézetek garantálják a tranzakciókat. Ez nagy hatalmat ad az intézményeknek, mert a pénz rajtuk áramlik keresztül. Emellett emberek milliárdjai világszerte még bankszámlát sem tudnak nyitni maguknak. + +A DeFi-ban az okosszerződés helyettesíti a pénzintézetet a tranzakció során. Az okosszerződés egy olyan Ethereum-számla, mely pénzeszközöket tartalmaz és azokat elküldheti vagy visszaveheti bizonyos feltételek mentén. Miután az okosszerződés életbe lépett, már senki sem változtathatja meg – úgy fog működni, ahogy le lett programozva. + +Egy olyan szerződést, melynek lényege, hogy támogatást vagy zsebpénzt küldjön, le lehet programozni úgy, hogy A számláról B számlára rakjon pénzt minden pénteken. Ezt addig fogja csinálni, amíg az A számlán elegendő összeg található. Senki sem tudja megváltoztatni a szerződést úgy, hogy hozzáadja a C számlát és ellopja az összeget. + +A szerződések emellett teljesen nyilvánosak és bárki megvizsgálhatja azokat. Eszerint a rossz szerződések elég hamar a közösség vizsgálódása alá kerülnek. + +Ez valójában azt jelenti, hogy jelenleg az Ethereum-közösség technikailag képzettebb tagjaiban bízunk, akik el tudják olvasni a programkódot. A nyílt forráskódon alapuló közösség segít a fejlesztőket ellenőrzés alatt tartani, ami idővel szükségtelenné fog válni, ahogy az okosszerződéseket könnyebb lesz átlátni, és a programkód megbízhatóságára más igazolási módok is születnek. + +## Az Ethereum és a DeFi {#ethereum-and-defi} + +Az Ethereum tökéletes alapot biztosít a decentralizált pénzügyek (DeFi) számára: + +- Az Ethereumot és az azon működő okosszerződéseket senki sem birtokolja – tehát bárki használhatja a DeFi-t. Ebből adódik, hogy senki sem változtathatja meg a szabályokat. +- A DeFi termékek a háttérben ugyanazon a nyelven szólnak, ami az Ethereum. Emiatt a termékek nagy része zökkenőmentesen képes együttműködni. Az egyik platformon kölcsönadhat tokeneket, és kereskedhet a kamatozó tokenekkel egy teljesen másik piacon, teljesen másik alkalmazással. Ez olyan, mintha a bankjában a hűségpontokat készpénzre váltaná. +- A tokenek és kriptovaluták az Ethereum részei, mely egy megosztott főkönyv – fő jellemzője a tranzakciók és a tulajdonlás követhetősége. +- Az Ethereum tökéletes pénzügyi szabadságot ad – a legtöbb termék sosem fog felügyeletet gyakorolni az Ön eszközei felett, így a kontroll Önnél marad. + +A DeFi-t a következő rétegek szerint értelmezheti: + +1. A blokklánc – az Ethereum tartalmazza az összes tranzakciót és a számlák státuszát. +2. Az eszközök – [ETH](/eth/) és a többi token (valuták). +3. A protokollok – az [okosszerződések](/glossary/#smart-contract), melyek a műveleteket biztosítják, mint amilyen például egy szolgáltatás az eszközök decentralizált kölcsönadására. +4. [Az alkalmazások](/dapps/) – azok a termékek, melyek révén kezeljük és elérjük a protokollokat. + +Megjegyzés: a legtöbb DeFi alkalmazás az [ERC-20 szabványt](/glossary/#erc-20) használja. A DeFi alkalmazások beburkolják az ETH-t és így becsomagolt ethert (WETH) használnak. [Bővebben a becsomagolt etherről](/wrapped-eth). + +## Építse Ön is a DeFi-t {#build-defi} + +A DeFi egy nyílt forráskódú kezdeményezés. A kapcsolódó protokollok és alkalmazások mind nyitottak az Ön számára, hogy megvizsgálja azokat, elágazásokat készítsen azokból vagy továbbfejlessze azokat. A rétegezett struktúra következtében (melynek részei ugyanarra az alap blokkláncra épülnek és ugyanazokat az eszközöket használják) a protokollokat össze lehet kötni, hogy egyedi lehetőségeket aknázzunk ki. + + + Bővebben a dappok építéséről + + +## További olvasnivaló {#further-reading} + +### DeFi adatok {#defi-data} + +- [DeFi Prime](https://defiprime.com/) +- [DeFi Llama](https://defillama.com/) + +### Cikkek a DeFi-ról {#defi-articles} + +- [Útmutató kezdőknek a DeFi-ról](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 2020. január 6._ + +### Videók {#videos} + +- [Finematics – decentralizált pénzügyi oktatás](https://finematics.com/) – _Videók a DeFi-ról_ +- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) – _A DeFi alapjai: minden, amit tudnia kell, hogy elboldoguljon ebben a néha rejtélyes világban._ +- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _Mi az a DeFi?_ + +### Közösségek {#communities} + +- [DeFi Llama Discord-szerver](https://discord.defillama.com/) +- [DeFi Pulse Discord-szerver](https://discord.gg/Gx4TCTk) + + + + \ No newline at end of file diff --git a/public/content/translations/hu/06) Use Cases/smart-contracts/index.md b/public/content/translations/hu/06) Use Cases/smart-contracts/index.md new file mode 100644 index 00000000000..b899e0b3968 --- /dev/null +++ b/public/content/translations/hu/06) Use Cases/smart-contracts/index.md @@ -0,0 +1,82 @@ +--- +title: Okosszerződések +description: Egy nem technikai bevezetés az okosszerződésekbe +lang: hu +--- + +# Bevezetés az okosszerződésekbe {#introduction-to-smart-contracts} + +Az okosszerződések az Ethereum alkalmazási rétegének alapvető építőkockái. Ezek olyan számítógépes programok, melyek a [blokkláncon](/glossary/#blockchain) találhatók, feltételeket követve működnek (ha ez van, akkor ezt csinálom), és garantáltan a programkódja által definiált szabályok alapján végez műveleteket. E szabályokat nem lehet megváltoztatni, miután a szerződés életbe lépett. + +Az okosszerződés kifejezést Nick Szabo alkotta meg. 1994-ben írt egy cikket a [a koncepció lényegéről](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html), majd 1996-ban tovább taglalta, hogy [mire képes az okosszerződés](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html). + +Szabo egy olyan digitális piacteret képzelt el, ahol automatikus, [kriptográfiailag biztosított](/glossary/#cryptography) folyamatok lehetővé teszik tranzakciók és üzleti funkciók működését megbízott közvetítők nélkül. Az okosszerződések ezt a víziót valósítják meg az Ethereumon. + +Nézze meg a videót, melyben a Finematics elmagyarázza az okosszerződések lényegét: + + + +## Bizalom a hagyományos szerződésekben {#trust-and-contracts} + +A hagyományos szerződéssel az a legnagyobb gond, hogy meg kell bízni a résztvevőkben, hogy végrehajtják a szerződés tartalmát. + +Következzen egy példa: + +Alice és Bob kerékpáron versenyeznek. Tegyük fel, Alice arra fogad Bobbal 10 $-ban, hogy ő maga fog nyerni. Bob magabiztos a saját nyerését illetően, ezért belemegy a fogadásba. Végül Alice sokkal hamarabb ér célba Bobhoz képest, egyértelműen ő a győztes. Bob azonban nem fizeti ki a fogadás összegét, mert szerinte Alice csalt. + +Ez az egyszerű példa a „nem okos” megegyezések problémáját illusztrálja. Még a megegyezés feltételei teljesülnek is (tehát Ön a verseny győztese), még mindig meg kell bíznia egy másik személyben, hogy teljesítse a megállapodást (azaz kifizesse a fogadás összegét). + +## Egy digitális ételautomata {#vending-machine} + +Az okosszerződésre egy egyszerű metafora lehet az ételautomata működése, melynél bizonyos beviteli értékek előre meghatározott eredménnyel járnak. + +- Ön kiválaszt egy terméket +- Az ételautomata kiírja az árat +- Ön kifizeti az árát +- Az ételautomata ellenőrzi, hogy a megfelelő összeget kapta meg +- Majd az automata kiadja a kért árut + +Az ételautomata csak az Ön által kért terméket adja oda, miután a feltételek teljesültek. Ha Ön nem választ ki terméket vagy nem dob be elég pénzt, akkor az automata nem adja ki a terméket. + +## Automatikus végrehajtás {#automation} + +Az okosszerződés legfontosabb előnye, hogy bizonyos feltételek fennállásakor egyértelműen végrehajt egy meghatározott programkódot. Nem kell várni az emberi beavatkozásra, hogy értelmezze vagy kitalálja az eredményt. Így nincs szükség megbízott közvetítőkre. + +Például írhat egy olyan okosszerződést, mely letétben tart pénzeszközt egy gyermek számára, melyet egy bizonyos dátum után kaphat meg. Ha hamarabb akarná megkapni, akkor az okosszerződés nem hajtaná azt végre. Vagy olyan okosszerződést is írhat, mely automatikusan biztosítja egy autó forgalmi engedélyének digitális verzióját, amint Ön kifizeti azt a kereskedőnek. + +## Előre meghatározott kimenetel {#predictability} + +A hagyományos szerződések nem egyértelműek, mert emberek értelmezik és hajtják végre azokat. Például két bíró teljesen másképpen is értelmezhet egy szerződést, mely eltérő döntésekhez és egyenlőtlen kimenetelhez vezethet. Az okosszerződések kizárják ezt a lehetőséget. Ehelyett az okosszerződések a szerződés kódjában megadott feltétek mentén pontosan végrehajtásra kerülnek. A pontosság azt is jelenti, hogy ugyanolyan körülmények között az adott okosszerződés ugyanazt az eredményt adja. + +## Nyilvános dokumentálás {#public-record} + +Az okosszerződéseket könnyedén lehet auditálni és követni. Mivel az Ethereum okosszerződései egy nyilvános blokkláncon találhatók, ezért bárki azonnal megnézheti az eszközök mozgását és a kapcsolódó információkat. Például Ön megnézheti, hogy valaki pénzt utalt az Ön címére. + +## Adatvédelem {#privacy-protection} + +Az okosszerződések védik az Ön adatait. Mivel az Ethereum egy olyan hálózat, ahol a tranzakciók nem közvetlen módon köthetők az identitáshoz (nyilvánosan egy egyedi kriptográfiai címhez tartoznak), így Ön is megőrizheti valódi kilétét mások előtt. + +## Látható feltételek {#visible-terms} + +Végül a hagyományos szerződéshez hasonlóan Ön ellenőrizheti az okosszerződés tartalmát, mielőtt aláírná azt (vagy valamilyen interakcióba lépne azzal). Az okosszerződés transzparens volta biztosítja, hogy bárki megvizsgálhatja annak részleteit. + +## Az okosszerződés alkalmazási területei {#use-cases} + +Az okosszerződések lényegében mindent végre tudnak hajtani, amit egy számítógépes program tud. + +Többek között képesek számításokat végezni, valutát létrehozni, adatot tárolni, [NFT-ket](/glossary/#nft) kreálni (minting), üzeneteket küldeni és még ábrát vagy grafikont is tudnak készíteni. Következzen néhány népszerű példa a való életből: + +- [Stablecoin-ok](/stablecoins/) +- [Egyedi digitális eszközök létrehozása és szétosztása](/nft/) +- [Automatikus, nyílt valutaátváltás](/get-eth/#dex) +- [Decentralizált játékok](/dapps/?category=gaming#explore) +- [Biztosítási szerződés, mely automatikus kifizetést alkalmaz](https://etherisc.com/) +- [Szabvány, melyet alapul véve az emberek egyéni, interoperábilis valutákat hoznak létre](/developers/docs/standards/tokens/) + +## További olvasnivaló {#further-reading} + +- [Hogyan fogják az okosszerződések megváltoztatni a világot](https://www.youtube.com/watch?v=pA6CGuXEKtQ) +- [Okosszerződések: a blokklánc-technológia, mely leváltja az ügyvédeket](https://blockgeeks.com/guides/smart-contracts/) +- [Okosszerződések fejlesztőknek](/developers/docs/smart-contracts/) +- [Tanulja meg, hogyan kell okosszerződéseket írni](/developers/learning-tools/) +- [Ismerje meg Ethereumot – Mi az az okosszerződés?](https://github.com/ethereumbook/ethereumbook/blob/develop/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract) diff --git a/public/content/translations/hu/06) Use Cases/web3/index.md b/public/content/translations/hu/06) Use Cases/web3/index.md new file mode 100644 index 00000000000..383332ec940 --- /dev/null +++ b/public/content/translations/hu/06) Use Cases/web3/index.md @@ -0,0 +1,157 @@ +--- +title: Mi az a Web3 és miért fontos? +description: Bevezetés a web3 világába, vagyis az internet következő evolúciójába, és abba, hogy miért is olyan fontos. +lang: hu +--- + +# Bevezetés a Web3 világába {#introduction} + +A centralizáció segített abban, hogy emberek milliárdjai használják az internetet, és megalapozta annak stabil, robosztus infrastruktúráját. Eközben néhány centralizált entitás tartja a kezében az internet nagy részét, és egyoldalúan eldönti, hogy mit szabad és mit nem. + +A Web3 a válasz erre a dilemmára. Ahelyett, hogy a web nagy technológiai cégek monopóliuma lenne, a web3 lényege a decentralizáció, így a felhasználók építik, működtetik és birtokolják. A Web3 az egyének kezébe helyezi a hatalmat a cégek helyett. Mielőtt mélyebben elmerülünk a Web3 világában, nézzük meg, hogyan jutottunk el idáig. + + + +## A web korai változatai {#early-internet} + +A legtöbben azt képzelik, hogy az internet egy folyamatos pillére a modern életnek – feltalálták és azóta létezik. Azonban a jelenlegi formája eléggé más, mint amit korábban elképzeltek. A web rövid történetében különböztessünk meg két időszakot: web 1.0 és web 2.0. + +### Web 1.0: csak olvasás (1990–2004) {#web1} + +1989-ben Genovában a CERN intézetében Tim Berners-Lee olyan protokollokon dolgozott, amelyek a web alapjaivá váltak. Mi volt az ő ötlete? Nyitott, decentralizált protokollok, melyek a világ egészén lehetővé teszik az információmegosztást. + +Berners-Lee alkotásának kezdeti értelmezése, melyet most web 1.0-ként ismerünk, nagyjából 1990 és 2004 között készült. A web 1.0 főleg statikus weboldalakból állt, melyeket cégek birtokoltak, szinte semmi interakció a felhasználók között – néha készítettek tartalmat –, ezért úgy ismert mint a „csak olvasási” időszak. + +![A web 1.0-t képviselő kliensszerver-architektúra](./web1.png) + +### Web 2.0: olvasás-írás (2004 – mostanáig) {#web2} + +A web 2.0 periódus 2004-ben indult, amikor megjelentek a közösségimédia-oldalak. A csak olvasás helyett kialakul az olvasás-írás kultúrája. Ahelyett, hogy a cégek adnának a felhasználónak tartalmat, olyan platformok keletkeztek, ahol a felhasználók adnak tartalmat és egymással lépnek interakcióba. Ahogy egyre több ember kezdte el használni, a cégek egy maroknyi csoportja aránytalanul nagy részét kezdte el kontrollálni a forgalomnak és a keletkező értéknek. A web 2.0 révén megszületett a reklámalapú bevételi modell. Miközben a felhasználók tartalmat készítenek, az nincs az ő birtokukban és nem is részesednek annak bevételéből. + +![A web 2.0-t képviselő kliensszerver-architektúra](./web2.png) + + + +## Web 3.0: olvasás-írás-tulajdonlás {#web3} + +A web3 kifejezést az [Ethereum](/what-is-ethereum/) társalapítója, Gavin Wood találta ki, röviddel az Ethereum 2014-es elindítása után. Gavin megfogalmazta azt a problémát, amit számos korai kriptobevezető érzett: a web túl sok bizalmat követel. Tehát a mai internet azon alapszik, hogy a felhasználó néhány vállalatra bízza, hogy azok a közösség érdeke szerint működjenek. + +![A Web3-at képviselő, decentralizált csomópont-architektúra](./web3.png) + +### Mi az a Web3? {#what-is-web3} + +A Web3 egy magával ragadó szóvá vált, amelyet minden olyanra értünk, ami újjá és jobbá teszi az internetet. A Web3 blokkláncokat, kriptovalutákat és nem helyettesíthető tokeneket (NFT) használ, hogy visszaadja a felhasználónak a tulajdonjogot. [Egy 2020-as Twitter-bejegyzés](https://twitter.com/himgajria/status/1266415636789334016) foglalta össze a legjobban: a web1 csak olvasás volt, a web2-nél az olvasásé és írásé a főszerep, a web3 az olvasás-írás-tulajdonlás világa lesz. + +#### A Web3 központi elképzelései {#core-ideas} + +Habár nehéz lenne egy pontos definíciót adni a Web3-ról, néhány központi elv irányítja a megalkotását. + +- **A Web3 decentralizált:** ahelyett, hogy nagy részét központi entitások uralnák és birtokolnák, a tulajdonlást elosztja az építői és felhasználói között. +- **A Web3 engedélymentes:** mindenkinek azonos joga van részt venni benne és senkit sem zárnak ki. +- **A Web3 saját fizetési móddal bír:** kriptovalutát használ a költésre és az online pénzküldésre ahelyett, hogy a bankok és fizetési szolgáltatások idejétmúlt infrastruktúráját használná. +- **A Web3 nem igényel bizalmat:** ösztönzők és gazdasági mechanizmusok révén működik, nem pedig megbízott harmadik feleken alapul. + +### Miért fontos a Web3? {#why-is-web3-important} + +Habár a Web3 lenyűgöző vonásai nem különülnek el ennyire és nem is tömörülnek egyértelmű kategóriákba, az egyszerűség kedvéért megpróbáljuk azokat külön bemutatni. + +#### Tulajdonlás {#ownership} + +A Web3 sosem látott módon ad a felhasználóknak képességet arra, hogy digitális eszközeiket saját maguk birtokolják. Tegyük fel, hogy Ön egy web2-es játékot játszik. Ha egy játékon belüli tételt megvásárol, akkor az közvetlenül a profiljához kapcsolódik. De ha a játék készítői törlik ezt a profilt, akkor elveszíti azokat a tételeket. Ha pedig nem játszik tovább, akkor elveszíti az értéket, amit azokba a tételekbe fektetett. + +A Web3 közvetlen tulajdonjogot ad [nem helyettesíthető tokenek (NFT)](/glossary/#nft) révén. Senki, még a játék készítői sem tudják elvenni ezt a jogot. Ha abbahagyja a játékot, akkor el tudja adni, kereskedni tud azokkal a nyitott piacokon és visszaszerezni az értékét. + + +
Tudjon meg többet az NFT-kről
+ + Bővebben az NFT-kről + + + +#### Cenzúraálló kialakítás {#censorship-resistance} + +A platformok és a tartalomkészítők közötti hatalmi dinamika rettentő egyensúlytalan. + +Az OnlyFans oldal felnőtt tartalmat gyárt több mint 1 millió tartalomkészítővel, akik ebből szerzik jövedelmüket. 2021-ben a vezetés megtiltotta a túlzottan nyílt tartalmakat. Az alkotók felháborodtak, hogy az általuk felfutatott platform megfosztja őket a jövedelmüktől. Emiatt a döntést visszavonták. Ez is megmutatja a web2 fő problémáját: ha egy platformot el kell hagyjon egy alkotó, akkor elveszíti a reputációját és a követőit, amelyeket összegyűjtött. + +A Web3-ban az adat a blokkláncon él. Amikor valaki elhagyja a platformot, magával viheti a reputációját, akár egy másik felületre is, ami jobban megfelel az értékeinek. + +A web2-nél az alkotóknak meg kell bízni a platformban, hogy nem változtatja meg a szabályokat, ugyanakkor a Web3 alapvonása a cenzúrának való ellenállás. + +#### Decentralizált autonóm szervezetek (DAO-k) {#daos} + +Az adatok feletti tulajdonjog mellett a web3 a platformot is birtokolni lehet, mint egy gyűjthető dolgot, olyan tokenek révén, melyek egy cégben való részesedésként működnek. A DAO segít koordinálni a platform decentralizált tulajdonlását és döntéseket hozni a jövőt illetően. + +A DAO-kat technikailag úgy határozzák meg, mint megállapodás szerinti [intelligens szerződéseket](/glossary/#smart-contract), amelyek automatizálják a decentralizált döntéshozatalt egy erőforráskészlet (token) felett. A tokennel rendelkező felhasználók szavaznak, hogy hogyan költsék el a forrásokat, a programkód pedig automatikusan végrehajtja azt. + +Ugyanakkor számos Web3-közösséget is DAO-ként definiálnak. Ezek a közösségek más-más szintű decentralizációval és automatizációval rendelkeznek. Jelenleg még vizsgáljuk, hogy mi is az a DAO és hova fejlődik a jövőben. + + +
Tudjon meg többet a DAO-król
+ + További információk a DAO-król + + + +### Identitás {#identity} + +Hagyományos módon minden platformra egy külön profilt kell létrehozni. Például Ön külön Twitter-, YouTube- és Reddit-profillal is rendelkezik. Meg szeretné változtatni a nevét vagy a képét? Minden egyes eszközön meg kell tennie. Használhat közösségimédia-alapú azonosítást néhány esetben, ez viszont visszamutat a korábbi témára, a cenzúrára. Ezek a platformok egyetlen kattintással kizárhatják Önt a teljes közösségi életéből. Ami még rosszabb, hogy ezek a platformok személyes azonosítókat kérnek el a profil létrehozásához. + +A Web3 megoldja ezeket a problémákat azáltal, hogy lehetővé teszi digitális személyazonosságának vezérlését Ethereum-címmel és [Ethereum névszolgáltatás (ENS)](/glossary/#ens) profillal. Az Ethereum-cím használata egyszerre biztosít hozzáférést az összes platformhoz, ami biztonságos, ellenáll a cenzúrának és anonim. + +### Saját fizetési rendszer {#native-payments} + +A web2 fizetési infrastruktúra a bankokra és fizetési szolgáltatókra támaszkodik, kizárva azokat, akik nem rendelkeznek bankszámlával, vagy éppen nem olyan országban élnek. A Web3 tokeneket használ, mint amilyen az [ETH](/glossary/#ether), hogy közvetlen módon tudjon pénzt küldeni, és nem kell hozzá harmadik fél. + + + Többet az ETH-ről + + +## Web3 korlátok {#web3-limitations} + +A Web3 számos előnye mellett még mindig vannak korlátok, amit az ökoszisztémának kezelnie kell, hogy virágozni tudjon. + +### Hozzáférhetőség {#accessibility} + +Az olyan fontos Web3-funkciók, mint a bejelentkezés az Ethereummal, már mindenki számára elérhetők ingyenesen. A tranzakciók költsége viszont még mindig sokakat kizár. A Web3-at a magas tranzakciós díjai miatt kevésbé tudják a szegényebb, fejlődő országok használni. Az Ethereumon ezeket a kihívásokat [az ütemterv](/roadmap/) és a [2. rétegbeli skálázási megoldások](/glossary/#layer-2) oldják meg. A technológia készen áll, az L2-n még magasabb felhasználási számot kell elérni ahhoz, hogy mindenkinek elérhető legyen a Web3. + +### Felhasználói tapasztalat {#user-experience} + +A Web3 használatának jelenleg túl nagy a technikai akadálya. A felhasználóknak meg kell érteni a biztonsági konszerneket, komplex technikai dokumentációkat, illetve nehézkes felhasználó felületeken kell navigálniuk. [A tárcaszolgáltatók](/wallets/find-wallet/) egyértelműen dolgoznak ennek megoldásán, de még ennél is több fejlesztésre van szükség a Web3 tömeges használatához. + +### Oktatás {#education} + +A Web3 új paradigmákat vezet be, melynek következtében más mentális modelleket kell elsajátítani, mint a web2 esetében. A web1 idején hasonló oktatás vette kezdetét az 1990-es években; a támogatók új oktatási technikákat használtak a nagy közönség tájékoztatására az egyszerű metaforák használatától (információs sztráda, böngészés, szörfölés) kezdve a [tévés programokig](https://www.youtube.com/watch?v=SzQLI7BxfYI). A Web3 nem bonyolultabb ennél, csak más. A web2-felhasználók tájékoztatása ezekről a Web3-as paradigmákról elengedhetetlen a sikerhez. + +Az Ethereum.org a [Fordítói program](/contributing/translation-program/) révén járul hozzá a Web3-oktatáshoz, hogy az Ethereum főbb tartalmai minél több nyelven elérhetők legyenek. + +### Centralizált infrastruktúra {#centralized-infrastructure} + +A Web3-ökoszisztéma fiatal és gyorsan fejlődik. Ennek következtében főleg centralizált infrastruktúrákon alapszik (GitHub, Twitter, Discord, etc.). Számos Web3-vállalat dolgozik azon, hogy ezt a hiányt betöltse, de a minőségi, megbízható infrastruktúra kiépítése időbe telik. + +## Egy decentralizált jövő {#decentralized-future} + +A Web3 egy fiatal és gyorsan fejlődő ökoszisztéma. Gavin Wood 2014-ben alkotta ezt a nevet, de számtalan elképzelés csak mostanában tudott valósággá válni. Jelentős növekedés tapasztalható a kriptovaluta, az L2 skálázási megoldások, az új irányítási formák és a digitális személyazonosság forradalmi újításainak világában. + +Ez még csak a kezdete annak, hogy az internet jobbá váljon a Web3-mal, és ahogy az alapot nyújtó infrastruktúra fejlődik, a web jövője igen bíztatónak tűnik. + +## Hogyan lehet részt venni {#get-involved} + +- [Tárca szerzése](/wallets/) +- [Találjon egy közösséget](/community/) +- [Fedezze fel a Web3-alkalmazásokat](/dapps/) +- [DAO-hoz csatlakozás](/dao/) +- [Építsen a Web3-ra](/developers/) + +## További olvasnivaló {#further-reading} + +A Web3 nincs szigorúan definiálva. A közösségek különböző résztvevői más-más perspektívával bírnak. Néhány ezek közül: + +- [Mi az a Web3? Áttekintés a jövő decentralizált internetéről](https://www.freecodecamp.org/news/what-is-web3/) – _Nader Dabit_ +- [A Web3 értelmezése](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) – _Josh Stark_ +- [Miért számít a Web3](https://future.a16z.com/why-web3-matters/) — _Chris Dixon_ +- [Miért fontos a decentralizáció](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) – _Chris Dixon_ +- [A Web3 világa](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) – _a16z_ +- [A Web3 vita](https://www.notboring.co/p/the-web3-debate?s=r) – _Packy McCormick_ + + diff --git a/public/content/translations/hu/07) Staking Pages/staking/dvt/index.md b/public/content/translations/hu/07) Staking Pages/staking/dvt/index.md new file mode 100644 index 00000000000..f9552e76140 --- /dev/null +++ b/public/content/translations/hu/07) Staking Pages/staking/dvt/index.md @@ -0,0 +1,91 @@ +--- +title: Elosztott validátor technológia +description: Az elosztott validátor technológia lehetővé teszi, hogy több entitás elosztva üzemeltessen egy Ethereum-validátort. +lang: hu +--- + +# Elosztott validátor technológia {#distributed-validator-technology} + +Az elosztott validátor technológia (DVT) a validátor biztonságát akarja megerősíteni, ezért több entitásra osztja fel a kulcsok kezelését és az aláírási jogosultságokat, így kizárja az egyetlen meghibásodási pont kockázatát, a rugalmasság pedig nő. + +Ennek érdekében **felosztja a validátort biztosító privát kulcsot** **több számítógépre**, melyeket klaszterbe rendez. Mivel a kulcs nem egyben van letárolva egyetlen gépen, ezért a támadóknak igen nehéz megszerezni azt. Még néhány csomópont is leállhat, a szükséges aláírás akkor is megtörténik a klaszterekben lévő gépek kisebb halmaza által. Ez lecsökkenti az egyetlen meghibásodási pont kockázatát a hálózatban, a validátorkészlet pedig megbízhatóbbá válik. + +![Az ábra azt mutatja, hogy a validátorkulcsot szétosztják kulcsrészekre és több csomópontnak elosztják, melyek különféle komponensekből állnak.](./dvt-cluster.png) + +## Miért van szükség az elosztott validátor technológiára (DVT)? {#why-do-we-need-dvt} + +### Biztonság {#security} + +A validátorok két nyilvános privát kulcspárt hoznak létre: a validátorkulcsot a konszenzusban való részvételhez, a visszavonási kulcsot ahhoz, hogy elérjék a pénzeszközöket. Miközben a visszavonási kulcsot tarthatja a validátor olyan helyen is, ahol lassabban éri el (cold storage), addig a privát kulcsnak folyamatosan online kell lennie (24/7). Ha a validátor privát kulcsa veszélybe kerül, akkor egy támadó átveheti felette a kontrollt, ami súlyos büntetéssel egybekötött kizáráshoz (slashing), illetve a letétbe helyezett ETH elvesztéséhez vezethet. A DVT segít ezt a kockázatot csökkenteni. A működése: + +A DVT használatával a letétbe helyező (staker) részt vehet a letétbe helyezésben, miközben a validátor privát kulcsát cold storage-ban tartja. Ehhez az eredeti, teljes validátorkulcsot titkosítják és azután darabokra osztják. A kulcs darabjai online vannak és több csomópont megkapja azokat, így a validátor működése elosztódik ezek között. Ez azért lehetséges, mert az Ethereum-validátorok BLS aláírást használnak, ami összeadódik, tehát a teljes kulcsot bármikor összerakják a részekből. Tehát a letétbe helyező a teljes, eredeti validátorkulcsát biztonságban tarthatja offline. + +### Nincs egyetlen meghibásodási pont sem {#no-single-point-of-failure} + +Amikor a validátor több operátorra és több gépre van elosztva, akkor lesz offline, ha az egyedi hardverek vagy szoftverek leállnak. A leállás kockázatát azzal is lehet csökkenteni, hogy a klaszterbe tartozó csatlakozási pontoknak eltérő hardver- és szoftverkonfigurációkat állítanak össze. A rugalmasság nem kézzelfogható az egyetlen csatlakozási pontot használó validátorkonfigurációnál – ez a DVT megoldásból származik. + +Ha a klaszter egyik gépének valamelyik komponense leáll (például a klaszter négy operátorából az egyik olyan klienst használ, amelyen hiba van), akkor a többiek biztosítják, hogy a validátor ugyanúgy működjön tovább. + +### Decentralizáció {#decentralization} + +Az Ethereum számára az az ideális szcenárió, ha annyi függetlenül üzemeltetett validátora van, amennyi csak lehetséges. Ugyanakkor néhány letétszolgáltató igen népszerű lett és a teljes letétbe helyezett ETH lényeges részét tudhatja magáénak a hálózaton. A DVT révén lehetséges ilyen operátorok működése, miközben a letétbe helyezett ETH megőrzi decentralizáltságát. Mivel a validátor kulcsai el vannak osztva több számítógépen, és a visszaéléshez sokkal komolyabb összejátszásra lenne szükség. + +A DVT nélkül a letétszolgáltatóknak könnyebb csak egy-két klienskonfigurációt támogatni az összes validátorra, ami megnöveli a kliensből eredő hibák hatását. A DVT-vel ez a kockázat elosztható több klienskonfigurációra és különböző hardverekre, így sokrétűség rugalmasságot teremt. + +**A DVT a következő előnyökkel jár az Ethereum számára:** + +1. **Decentralizálja** az Ethereum proof-of-stake (PoS) konszenzusát +2. Biztosítja a hálózat **aktív, élő állapotát (liveness)** +3. A validátor **toleránssá válik a hibákra** +4. **Minimalizált bizalomigény** jellemzi a validátor működését +5. **Minimalizált büntetéssel egybekötött kizárás (slashing)** és leállási kockázat +6. **Javítja a diverzitást** (kliens, adatközpont, hely, szabályozás stb.) +7. **Nagyobb biztonság** a validátorkulcs kezelését illetően + +## Hogyan működik a DVT? {#how-does-dvt-work} + +A DVT megoldás a következő komponensekből áll: + +- **[Shamir-féle titokmegosztás ](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** – A validátorok [BLS-kulcsokat](https://en.wikipedia.org/wiki/BLS_digital_signature) használnak. Az egyéni BLS-kulcsrészeket össze lehet kapcsolni egy aggregált kulccsá (aláírás). A DVT esetén a validátor privát kulcsa a klaszter operátorainak összekapcsolt BLS-aláírása. +- **[Aláírási küszöb séma](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** – Meghatározza az egyéni kulcsrészek számát, melyekkel az aláírás meg tud történni, pl. 4-ből 3. +- **[Elosztottkulcs-generálás (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** – Egy kriptográfiai folyamat, ami létrehozza a kulcsrészeket és elosztja egy létező vagy új validátorkulcs részeit a klaszterben található csomópontoknak. +- **[Több résztvevős számítás (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** – A teljes validátorkulcs titokban készül el a több résztvevős számítás révén. Egyetlen operátor sem ismeri a teljes kulcsot, ők csak a saját részüket ismerik. +- **Konszenzusprotokoll** – A konszenzusprotokoll kiválaszt egy csomópontot, hogy az javasoljon blokkot. Az megosztja a blokkot a klaszter többi csomópontjával, amelyek hozzáteszik a kulcsrészeiket az aggregált aláíráshoz. Amikor a kellő mennyiségű kulcsrészlet összeáll, megtörténhet a blokk előterjesztése az Ethereumon. + +Az elosztott validátorok ellenállóbbak a hibákkal szemben, és akkor is képesek működni, ha az egyéni csomópontok közül néhány leáll. A klaszter tehát ellenálló, még ha a benne lévő csomópontokról ki is derül, hogy ártalmasak vagy lusták. + +## A DVT alkalmazási területei {#dvt-use-cases} + +A DVT jelentős hatást gyakorol a kiterjedtebb letétszolgáltató iparágban: + +### Önálló letétesek {#solo-stakers} + +A DVT lehetővé teszi a nem felügyelt letétbe helyezést is, mivel a validátorkulcsot távoli csomópontok között is el lehet osztani, miközben a teljes kulcsot offline tárolják. Tehát az otthoni letéteseknek nem feltétlenül kell, hogy hardverre költsenek, mivel a kulcsrészek elosztása megerősítheti őket a lehetséges támadások ellen. + +### Letétbe helyezés mint szolgáltatás (SaaS) {#saas} + +Az operátorok (mint letéti alapok és intézményi letétesek), akik sok validátort kezelnek, a DVT révén csökkenthetik kockázatukat. Az infrastruktúra elosztásával a működésükhöz redundanciát (extra kapacitást) tudnak adni és diverzifikálják a hardvertípusok használatát is. + +A DVT megosztja a kulcskezelés felelősségét számod csomóponton keresztül, így az üzemeltetési költség is megosztható. A DVT csökkenti a letétszolgáltatók üzemeltetési kockázatát és biztosítási költségeit. + +### Letéti alapok {#staking-pools} + +A standard validátorbeállítás következtében a letéti alapok és a likvid letétbe helyezők kénytelenek egy operátorral működő validátorban változó szinten megbízni, mivel a nyereségek és a veszteségek az egész alapot érintik. Emellett bízniuk kell az operátorokban, hogy biztonságban tartják az aláírási kulcsokat, mert korábban nem volt erre másik megoldás. + +Habár hagyományos módon tettek erőfeszítéseket, hogy elosszák a kockázatot azáltal, hogy több operátor között elosztják a letétet, de az operátorok még így is jelentős letétet kezelnek független módon. Nagy kockázatot jelent, amikor egyetlen operátorra támaszkodik a folyamat, ha az alulteljesít, leáll, kompromittálódik vagy ártó módon cselekszik. + +A DVT kihasználásával az operátoroknak nem kell másban bízniuk. **Az alapok megengedik az operátoroknak, hogy letétet kezeljenek anélkül, hogy a validátorkulcsot felügyelet alá kellene helyezniük** (mivel csak a kulcsrészeket használják). A kezelt letéteket is több operátor között tudják elosztani (pl. egyetlen operátor helyett, aki 1000 validátort kezel, a DVT-vel ezeket a validátorokat több operátor együtt tudja működtetni). A különféle operátorkonfigurációk biztosítják, hogy az egyik operátor leállásával a többiek még mindig el tudják végezni a tanúsítást. Ennek eredményeként redundancia (extra kapacitás) és diverzifikáció jön létre, ami jobb teljesítményt és rugalmasságot hoz, miközben maximalizálja a nyereséget. + +Az egyoperátoros bizalom minimalizálása következtében a letéti alapok nyitottabb és külön engedélyhez nem kötött operátorrészvételt engedhetnek meg. A szolgáltatóknak így kevesebb kockázattal kell számolniuk, támogatja az Ethereum decentralizációt azáltal, hogy válogatott és külön engedély nélküli operátorcsoportokat is használ, például összepárosítva az otthoni vagy kisebb letéteseket a nagyobbakkal. + +## A DVT lehetséges hátrányai {#potential-drawbacks-of-using-dvt} + +- **Még egy komponens** – DVT-csomópont hozzáadásával még egy összetevő lehet hibás vagy sebezhető. Ennek minimalizálásához arra kell törekedni, hogy a DVT csomópontot többféle beállítással, vagyis több DVT-klienssel kell használni (ahogy a konszenzus és végrehajtási rétegre is többféle kliens létezik). +- **Működési költségek** – mivel a DVT elosztja a validátort több entitás között, ezért (egy helyett) több csomópontra van szükség a működéshez, ami nagyobb költséggel jár. +- **A késedelem lehetséges növekedése** – mivel a DVT konszenzusprotokollt használ ahhoz, hogy megegyezést érjen el a több csomópont között, melyek a validátort működtetik, ezért a késedelem megnövekedhet. + +## További olvasnivaló {#further-reading} + +- [Az Ethereum elosztott validátorának specifikációja (átfogó)](https://github.com/ethereum/distributed-validator-specs) +- [Az Ethereum elosztott validátorának technikai specifikációi](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec) +- [Shamir titokmegosztási bemutató alkalmazás](https://iancoleman.io/shamir/) diff --git a/public/content/translations/hu/07) Staking Pages/staking/pools/index.md b/public/content/translations/hu/07) Staking Pages/staking/pools/index.md new file mode 100644 index 00000000000..42389afe957 --- /dev/null +++ b/public/content/translations/hu/07) Staking Pages/staking/pools/index.md @@ -0,0 +1,86 @@ +--- +title: Pooled staking +description: Áttekintés a letéti alapok használatáról +lang: hu +template: staking +emoji: ":money_with_wings:" +image: /images/staking/leslie-pool.png +alt: Leslie, a rinocérosz a medencében fürdik. +sidebarDepth: 2 +summaryPoints: + - Helyezzen letétbe bármennyi ETH-t és szerezzen jutalmakat másokkal együtt + - Hagyja a nehézségeket és bízza a validátor működtetését harmadik félre + - Tartsa a letétbe helyezett összegnek megfelelő tokeneket a saját tárcájában +--- + +## Mik azok a letéti alapok (staking pool)? {#what-are-staking-pools} + +A letéti alap egy olyan kollaboratív megközelítés, mely lehetővé teszi, hogy sok kis összegű ETH révén elérjék a 32 ETH küszöbértéket, ahol már fel tudnak állítani validátort. A letéti alap nem a protokoll része, más megoldások épültek ki, hogy ezt az igényt kielégítsék. + +Néhány letéti alap okosszerződéseket használ, ahol a pénzeszközöket a szerződésbe helyezik letétbe, így bizalomigény nélkül kezeli és követi a letét alakulását, és egy tokent ad, mely a letét értékét képviseli. Más alapok nem használnak okosszerződést, hanem a láncon kívül közvetítenek. + +## Miért jó a letéti alap használata? {#why-stake-with-a-pool} + +A [bevezetés a letétbe helyezésbe](/staking/) során elhangzott előnyök mellett a letéti alapok számos haszonnal járnak. + + + + + + + + + +## Mit kell figyelembe venni {#what-to-consider} + +A letéti alap vagy a delegáción alapuló letétbe helyezés nem része az Ethereum-protokollnak. Ugyanakkor a felhasználók igénye mentén, hogy 32 ETH-nál kisebb összeget adjanak letétbe, egyre több megoldás épül ki. + +Minden egyes alapot és az általuk használt eszközöket vagy okosszerződéseket különböző csapatok fejlesztik, így mind rendelkezik előnyökkel és kockázatokkal. Az alap lehetővé teszi, hogy a felhasználó egy tokent kapjon, ami a letétbe helyezett ETH-t reprezentálja. A token azért hasznos, mert a felhasználó bármennyi ETH-t átválthat egy azonos összegű, jövedelmet generáló tokenre, ami a háttérben lévő ETH letétbe helyezési jutalmaiból ad bevételt (és fordítva) a decentralizált tőzsdéken, még akkor is, ha az aktuális ETH a konszenzusrétegen van letétben. Eszerint a jövedelmet generáló, letétbe helyezett ETH-termék és az eredeti, nyers ETH között gyors és könnyű oda-vissza váltás lehetséges, és nem csak 32 ETH többszöröse érhető el. + +Ugyanakkor ezek a letétbe helyezett ETH tokenek kartellszerű viselkedésre hajlamosítanak, amikor ebből nagyobb összegek kevés centralizált szervezet kontrollja alá kerülnek, ahelyett hogy számtalan egyén között oszlanának el. Ez cenzúrára vagy értéklefölözésre ad lehetőséget. A letétbe helyezés aranyszabálya az, hogy egyének futtatják a validátorokat a saját hardverjükön. + +[A letétbe helyezést képviselő tokenek további kockázatairól](https://notes.ethereum.org/@djrtwo/risks-of-lsd). + +Alább különböző jellemzők mentén mutatjuk be a jelentős erősségeket vagy gyengeségeket, melyekkel a listázott letéti alapok rendelkezhetnek. Ez alapján Ön is megértheti, hogy e jellemzőket hogyan határoztuk meg, és így könnyebben választhat a letéti alapokból. + + + +## Fedezze fel a letéti alapokat {#explore-staking-pools} + +Számos olyan opció érhető el, amely biztosan kielégíti minden igényét. A fenti jellemzőket használva megértheti az alábbi eszközökben rejlő lehetőségeket. + + + + + +Olyan szolgáltatást válasszon, amely komolyan veszi a [kliensek diverzitását](/developers/docs/nodes-and-clients/client-diversity/), mert ez egyszerre javítja a hálózat biztonságát, és csökkenti az Ön kockázatát. Azok a szolgáltatók, akik korlátozzák a többségi klienseket használatát, a következő jellemzők alapján szűrhetők ki: végrehajtási kliens sokrétűsége és konszenzusos kliens sokrétűgése + +Hiányolja valamelyik letétbe helyezési eszközt? Ha a [terméklistázó szabályzat](/contributing/adding-staking-products/) alapján úgy véli, hogy egy adott eszköz illeszkedne ide, akkor jelezze felénk. + +## Gyakran ismételt kérdések {#faq} + + +A letétbe helyezők ERC-20 letéti tokeneket kapnak, és ezeket a letétbe adott ETH-t képviselik, megnövelve azt a jutalmakkal. A különféle alapok a letéti jutalmakat különböző módon adják át a felhasználóknak, a folyamat lényege ugyanakkor közös. + + + +Most azonnal! A Shanghai/Capella-hálózatfrissítés 2023. áprilisban végbement, mely elérhetővé tette a letétek visszavonását. A letéti alapokhoz tartozó validátorszámlák ki tudnak lépni a letétbe helyezésből és vissza tudják vonni az ETH-t a megadott visszavonási címükre. Ez lehetővé teszi, hogy visszavegye a letétrészt a mögöttes ETH-ért cserébe. Ellenőrizze, hogy az adott szolgáltató hogyan támogatja ezt a funkcionalitást. + +Alternatívaként a letéti alapok ERC-20 letéti tokeneket használnak, hogy a felhasználó kereskedni tudjon azokkal a nyitott piacon. Ezzel eladhatja a letéti helyzetét, visszavonva a letétet anélkül, hogy a letéti szerződésben lévő ETH bárhova is átkerülne. + +Bővebben a letétbe helyezés visszavonásáról + + + +Számos hasonló vonás van a letéti alapok opciói és a centralizált tőzsdék között, mivel kis összeggel is részt lehet venni, melyek együtt hoznak létre egy validátort. + +A centralizált tőzsdékhez képes számos letéti alap használ okosszerződést és/vagy letéti tokeneket, olyan ERC-20 tokeneket, melyeket a felhasználó a tárcájában tarthat, és bármikor vehet vagy adhat el azokból. Ez függetlenséget és biztonságot jelent, mivel a felhasználó kontrollálja a tokenjeit, de még mindig nem tudja irányítani a validátorklienst, ami az ő nevében készít tanúsítást a háttérben. + +Néhány letéti alap sokkal decentralizáltabb, amikor az általuk használt csomópontokról van szó. A hálózat egészséges állapota és decentralizációja érdekében a letétbe helyezők olyan letéti alapokat válasszanak, amelyek engedélymentes, decentralizált csomópont-operátorokkal működnek. + + +## További olvasnivaló {#further-reading} + +- [Ethereum letétbe helyezési jegyzék](https://www.staking.directory/) – _Eridian és Spacesider_ +- [Letétbe helyezés a Rocket Poollal – Áttekintés](https://docs.rocketpool.net/guides/staking/overview.html) – _RocketPool docs_ +- [Letétbe helyezés az Ethereumon a Lidoval](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) - _Lido help docs_ diff --git a/public/content/translations/hu/07) Staking Pages/staking/saas/index.md b/public/content/translations/hu/07) Staking Pages/staking/saas/index.md new file mode 100644 index 00000000000..c09a8e6c419 --- /dev/null +++ b/public/content/translations/hu/07) Staking Pages/staking/saas/index.md @@ -0,0 +1,95 @@ +--- +title: Staking, mint szolgáltatás +description: Egy áttekintő a pooled ETH staking elkezdéséről +lang: hu +template: staking +emoji: ":money_with_wings:" +image: /images/staking/leslie-saas.png +alt: Leslie, a rinocérosz a felhőkön lebeg. +sidebarDepth: 2 +summaryPoints: + - Az Ön validátorkliensét harmadik fél működteti csomópontok kezelésével + - Kiváló lehetőség bárkinek, aki rendelkezik 32 ETH összeggel, de nem szívesen bajlódna a csomópont technikai komplexitásával + - A bizalomigénye kevesebb, a visszavonási kulcsok az Ön saját felügyelete alatt állnak +--- + +## Mi az a letétbe helyezés mint szolgáltatás? {#what-is-staking-as-a-service} + +A letétbe helyezés, mint szolgáltatás (SaaS) egy olyan lehetőség, amikor a felhasználó letétbe teszi a saját 32 ETH összegét, hogy validátort működtessen, de a csomópont üzemeltetését egy harmadik félre bízza. E folyamat során a felhasználót végigvezetik a kezdeti beállításokon, beleértve a kulcs létrehozását, a letét elhelyezését, majd az aláíró kulcsok feltöltését az operátornak. A szolgáltatás így a felhasználó nevében működteti a validátort, általában egy havi díjért cserébe. + +## Miért jó a letéti szolgáltatás használata? {#why-stake-with-a-service} + +Az Ethereum-protokoll eredendően nem támogatja a letétbe helyezés delegálását, így ezek a szolgáltatások képesek ellátni ezt az igényt. Ha Ön letétbe helyezne 32 ETH-t, de nem szeretne a hardveres részével foglalkozni, az SaaS lehetővé teszi, hogy ezt a részét átadja másnak, miközben részesül a blokkjutalmakból. + + + + + + + + + +## Mit kell figyelembe venni {#what-to-consider} + +Az SaaS szolgáltatók száma egyre növekszik, ugyanakkor mind saját előnnyel és kockázattal bír. Az önálló stakinghez képest ezek az opciók mind extra bizalmat igényelnek. Az SaaS opciók rendelkezhetnek olyan hozzáadott programkóddal, melybe az Ethereum-klienst csomagolják, ami nem nyilvános vagy auditálható. Emellett negatív hatást gyakorolnak a hálózat decentralizálására. A beállítások függvényében Ön talán nem is bír kontrollal a validátora felett – az operátor rosszhiszeműen is eljárhat az Ön ETH-ját használva fel. + +Alább különböző jellemzők mentén mutatjuk be a jelentős erősségeket vagy gyengeségeket, melyekkel a listázott SaaS szolgáltatók rendelkezhetnek. Ez alapján Ön is megértheti, hogy e jellemzőket hogyan határoztuk meg, és így könnyebben választhat a szolgáltatók közül. + + + +## Fedezze fel, hogy kik nyújtanak letétbe helyezési szolgáltatást {#saas-providers} + +Néhány elérhető SaaS-szolgáltatót soroltunk fel alább. A fenti jellemzőket használva megértheti az alábbi szolgáltatásokban rejlő lehetőségeket + + + +### SaaS-szolgáltatók + + + +Olyan szolgáltatót válasszon, aki támogatja a [kisebbségi klienseket](/developers/docs/nodes-and-clients/client-diversity/), mert ez egyszerre javítja a hálózat biztonságát, és csökkenti az Ön kockázatát. Azok a szolgáltatók, akik korlátozzák a többségi klienseket használatát, a következő jellemzők alapján szűrhetők ki: végrehajtási kliens sokrétűsége és konszenzusos kliens sokrétűgése + +### Kulcsgenerátorok + + + +Javasolna olyan SaaS-szolgáltatót, akit nem lát felsorolva? Ha a [terméklistázó szabályzat](/contributing/adding-staking-products/) alapján úgy véli, hogy egy adott eszköz illeszkedne ide, akkor jelezze felénk. + +## Gyakran ismételt kérdések {#faq} + + +Minden szolgáltatónál más elrendezés lehetséges, de általában végigvezetik a felhasználót az aláíró kulcsok létrehozásán (minden 32 ETH esetén egy kulcs), és feltöltik ezeket a szolgáltatónak, hogy a felhasználó nevében validáljon. Az aláíró kulcsok magukban nem teszik lehetővé, hogy a pénzeszközöket visszavonják, átutalják vagy elköltsék. Ugyanakkor lehetőséget adnak arra, hogy a konszenzust elősegítsék szavazással, amit ha nem végeznek megfelelően, akkor az kisebb büntetést vagy súlyos büntetéssel egybekötött kizárást von maga után. + + + +Igen. Minden számla tartalmaz BLS aláírási kulcsokat és BLS visszavonási kulcsokat. Annak érdekében, hogy egy validátor tanúsítani tudja a lánc státuszát, részt vehessen a szinkronizációs bizottságokban és blokkot javasoljon, az aláíró kulcsokat elérhetővé kell tenni a validátorkliensben. Valamilyen formában az internethez kell kapcsolódnia, ezért ezeket „forró” kulcsoknak tekinthetjük (online elérhetők). A validátor csak így tud tanúsításokat készíteni, ezért biztonsági okokból az a kulcs külön áll, amelyikkel a pénzeszközöket lehet átutalni vagy visszavonni. + +A BLS visszavonási kulcsok arra valók, hogy egy egyszeri üzenetet írjanak alá, melyik végrehajtási számlára kerüljön a letéti jutalom és a visszavont pénzeszköz. Amint ez az üzenet érvénybe lép, a BLS visszavonási kulcsokra többé nincs szükség. A kulcsok helyett a megadott cím gyakorol kontrollt a visszavont eszközök felett. Még ha valaki más is kontrollálja az aláíró kulcsokat, a visszavonási cím biztonságban van a felhasználó offline tárhelyén (cold storage), ami minimalizálja a validátor-pénzeszközök elvesztését. + +A visszavonási adatok megadása szükséges ahhoz, hogy a visszavonás lehetséges legyen\*. Ehhez létre kell hozni a visszavonási kulcsokat a felhasználó mnemonikus kulcsmondata segítségével. + +Ezt a kulcsmondatot mindig tartsa biztonságban, különben nem lesz képes létrehozni a visszavonási kulcsokat, amikor szükség lenne azokra. + +\*Azoknak a letéteseknek, akik már megadták a visszavonási címüket a folyamat kezdetén, nem kell ezt beállítani. Ellenőrizze az SaaS-szolgáltatójával, hogy hogyan kell a validátort beállítani. + + + +A letétek visszavonása a Shanghai/Capella frissítéssel vált elérhetővé 2023. áprilisban. A letéteseknek meg kell adniuk egy visszavonási címet (ha nem adták meg azt a letét kezdetekor), és a jutalmak automatikusan kiküldésre kerülnek néhány naponta. + +A validátorok ki is léphetnek a funkciójukból, ami felszabadítja a fennálló ETH-összeget a visszavonáshoz. Azok a számlák, amelyek megadták a visszavonási címet és teljesítették a kilépési folyamatot, a teljes egyenleget megkapják az adott címre a következő validátor-ellenőrzésnél. + +Bővebben a letétbe helyezés visszavonásáról + + + +Az SaaS-szolgáltatóval a felhasználó másra bízza a csomópontok üzemeltetését. Ez magába foglalja a gyenge csomópont-teljesítmény kockázatát, mivel az nem a felhasználó irányítása alá esik. Ha a validátor súlyos büntetést kap (slashing), akkor a validátor egyenlegéből elvonnak és kizárják a validálásból. + +A büntetés végrehajtása után a megmaradt pénzeszközök a validátor visszavonási címére kerülnek. Ehhez szükség van egy visszavonási címre. Előfordulhat, hogy ezt a letétbe helyezéskor már megadta. Ha nem, akkor a validátor-visszavonási kulcsokkal lehet aláírni egy üzenetet, amely közli a visszavonási címet. A pénzeszközök zárolva maradnak addig, amíg a visszavonási cím nem elérhető. + +Kérdezze meg az SaaS-szolgáltatóját a lehetséges garanciákról vagy biztosításokról, illetve arról, hogyan lehet a visszavonási címet megadni. Ha Ön szeretné teljes mértékben kontrollálni a validátor-beállításokat, akkor ismerje meg az önálló letétbe helyezést. + + +## További olvasnivaló {#further-reading} + +- [Ethereum letétbe helyezési jegyzék](https://www.staking.directory/) – _Eridian és Spacesider_ +- [A letétbe helyezési szolgáltatások értékelése](https://www.attestant.io/posts/evaluating-staking-services/) – _Jim McDonald 2020._ diff --git a/public/content/translations/hu/07) Staking Pages/staking/solo/index.md b/public/content/translations/hu/07) Staking Pages/staking/solo/index.md new file mode 100644 index 00000000000..d011301a23b --- /dev/null +++ b/public/content/translations/hu/07) Staking Pages/staking/solo/index.md @@ -0,0 +1,206 @@ +--- +title: Egyéni letétbe helyezés +description: Az egyéni letétbe helyezés áttekintése +lang: hu +template: staking +emoji: ":money_with_wings:" +image: /images/staking/leslie-solo.png +alt: Leslie, a rinocérosz a saját számítógépes chipjén. +sidebarDepth: 2 +summaryPoints: + - Szerezzen maximális jutalmat közvetlenül a protokolltól azért, hogy a validátorát megfelelően működteti és az folyamatosan online + - Működtessen az otthonából hardvert és támogassa személyesen az Ethereum hálózatának biztonságát és decentralizálását + - Nem kell másban megbíznia, és az eszközeihez tartozó kulcsok mindig az Ön kontrollja alatt állnak +--- + +## Mi az az egyéni letétbe helyezés? {#what-is-solo-staking} + +Az egyéni letétbe helyezés során a felhasználó egy [Ethereum-csomópontot működtet](/run-a-node/) az internethez csatlakozva, letétbe helyez 32 ETH-t, hogy aktiváljon egy [validátort](#faq), így közvetlenül részt tud venni a hálózat konszenzusfolyamatában. + +**Az egyéni letétbe helyezés növeli az Ethereum hálózatának decentralizációját**, így az ellenállóbb lesz a cenzúrával és a támadásokkal szemben. A többi letétbe helyezési módszer nem feltétlen segíti a hálózatot ugyanilyen módon. Az egyéni letétbe helyezés a legjobb letéti opció az Ethereum biztosítására. + +Az Ethereum-csomópontot egy végrehajtási réteg (EL) klienst és egy konszenzus réteg (CL) klienst tartalmaz. Ezek a kliensek olyan szoftverek, amelyek együtt dolgoznak egy érvényes aláírókulcs-készlettel együtt, hogy érvényesítsék a tranzakciókat és a blokkokat, tanúsítsák a lánc státuszát, aggregálják a tanúsítványokat és blokkokat javasoljanak. + +Az egyéni letétbe helyezők azért felelnek, hogy a kliensek futásához szükséges hardvert működtetik. Azt javasoljuk, hogy erre egy dedikált gépet használjanak, melyet otthonról üzemeltetnek, mert ez rendkívül hasznos a hálózat egészsége szempontjából. + +Az egyéni letétbe helyező közvetlenül a protokolltól kap jutalmakat azért, hogy a validátora megfelelően működik és online van. + +## Miért legyek egyéni letétbe helyező? {#why-stake-solo} + +Az egyéni letétbe helyezés több felelősséggel jár, de teljes kontrollt biztosít a pénzeszközök és a staking felállítás felett. + + + + + + + +## Megfontolandó dolgok, mielőtt belevágna az egyéni letétbe helyezésbe {#considerations-before-staking-solo} + +Bármennyire is szeretnénk, hogy az egyéni letétbe helyezés elérhető és kockázatmentes legyen mindenkinek, ez nem lehet elérni. Mielőtt belevágna, komoly gyakorlati megfontolásokkal kell szembenéznie. + + + +Saját csomópont működtetéséhez meg kell tanulni a választott szoftver használatát. El kell olvasni a rendelkezésre álló dokumentációt és ráhangolni a fejlesztői csapatok kommunikációs csatornáira. + +Minél többet tud a választott szoftverről és a proof-of-stake működéséről, annál kevésbé kockázatos a letétbe helyezés, illetve a felmerülő problémák kezelése a csomópont-operátor szerepében. + + + +A csomópont beállításához egy bizonyos szintű számítógépes gyakorlat szükséges, habár az új eszközök egyre inkább megkönnyítik ezt a feladatot is. A parancssoros felhasználói felület (command-line interface) ismerete hasznos, de nem elengedhetetlen. + +Alapvető hardverösszeállításra, illetve a javasolt minimális specifikáció megértésére van szükség. + + + +Ahogy a privát kulcs biztosítja az Ethereum-címet, úgy a validátorhoz is létre kell hozni kulcsokat. Tudnia kell, hogyan tartsa a kulcsmondatokat vagy privát kulcsokat biztos helyen.{' '} + +Ethereum biztonság és csalásmegelőzés + + + +A hardver néha leáll, a hálózati kapcsolat hibára fut, a kliensszoftvert néha frissíteni kell. A csomópont karbantartása elkerülhetetlen, ezzel foglalkozni kell. Muszáj naprakésznek lennie minden várható hálózati frissítésről vagy más kritikus kliensfrissítésről. + + + +A jutalmazás annak arányában történik, hogy a validátor mennyi időt van online és megfelelő módon végzi-e a tanúsítást. A leállás miatti büntetések annak függvényében vannak megállapítva, hogy ugyanakkor hány validátor volt még offline, ez azonban nem von maga után súlyos büntetést és kizárást (slashing). A sávszélesség is számít, mert a tanúsításért járó jutalmak csökkenek, ha azok nem érkeznek meg időben. A szükséges paraméterek változhatnak, de érdemes legalább 10 Mb/s fel- és letöltési sebességgel számolni. + + + +Az inaktív állapot miatti büntetéstől különbözik a súlyos büntetéssel egybekötött kizárás (slashing), ami rosszhiszemű vétségekért jár. Ha kisebbségi klienst használ és a kulcsokat csak egy gépre tölti fel, akkor a slashing kockázata minimális. Ettől függetlenül minden letétbe helyezőnek szembe kell néznie a slashing kockázatával. + +Bővebben a slashingről és a validátor életciklusáról + + + + + +## Hogyan működik {#how-it-works} + + + +Mialatt Ön aktív, ETH jutalmakat kap, melyeket rendszeresen elhelyeznek a visszavonási számlán. + +Bármikor kiléphet a validátor szerepéből, így nem kell online lennie, és leállnak a jutalmak. Ekkor a maradék egyenlege visszatér a visszavonási címre, melyet a felállításnál adott meg. + +[Bővebben a letétbe helyezés visszavonásáról](/staking/withdrawals/) + +## Induljon el a Staking Launchpad segítségével {#get-started-on-the-staking-launchpad} + +A Staking Launchpad egy nyílt forráskódú alkalmazás, ami segít a letétbe helyezés folyamatában. Végigvezeti Önt a szükséges lépéseken, mint a kliensek kiválasztása, a kulcsok létrehozása és az ETH letétbe helyezése a letéti szerződésbe. Egy ellenőrzőlistán is végigveheti, hogy minden a rendelkezésre áll, hogy biztonsággal működjön a validátora. + + + +## Mit kell figyelembe venni a csomópont- és kliensbeállító eszközöknél {#node-tool-considerations} + +Az egyéni letétbe helyezést segítő eszközök és szolgáltatások száma egyre növekszik, de mindnél áll fenn kockázat, ugyanúgy mind előnyökkel is jár. + +Alább különböző jellemzők mentén mutatjuk be a jelentős erősségeket vagy gyengeségeket, melyekkel a listázott letéti eszközök rendelkezhetnek. Ez alapján Ön is megértheti, hogy e jellemzőket hogyan határoztuk meg, és így könnyebben választhat a szükséges eszközök közül. + + + +## Fedezze fel a csomópont- és kliensbeállító eszközöket {#node-and-client-tools} + +Számos olyan opció érhető el, amely biztosan kielégíti minden igényét. A fenti jellemzőket használva megértheti az alábbi eszközökben rejlő lehetőségeket. + + + +### Csomóponteszközök + + + +Olyan szolgáltatót válasszon, aki komolyan veszi a [kliensek diverzitását](/developers/docs/nodes-and-clients/client-diversity/), mert ez egyszerre javítja a hálózat biztonságát, és csökkenti az Ön kockázatát. Azok az eszközök, amelyek a kisebbségi kliens beállítást támogatják, a többklienses jellemzővel vannak jelölve + +### Kulcsgenerátorok + +Ezek alternatív eszközök a [Staking Deposit CLI](https://github.com/ethereum/staking-deposit-cli/) mellett, hogy a kulcsok le legyenek generálva. + + + +Hiányolja valamelyik letétbe helyezési eszközt? Ha a [terméklistázó szabályzat](/contributing/adding-staking-products/) alapján úgy véli, hogy egy adott eszköz illeszkedne ide, akkor jelezze felénk. + +## Nézze meg az egyéni letétbe helyezésre vonatkozó útmutatókat {#staking-guides} + + + +## Gyakran ismételt kérdések {#faq} + +Ezek a leggyakrabban felmerülő kérdések a letétbe helyezés kapcsán, melyről érdemes Önnek is tudnia. + + + +A validátor egy virtuális entitás, ami az Ethereumon működik és a protokoll konszenzusfolyamatában vesz részt. A validátort az egyenleg, a nyilvános kulcs és más tulajdonságok jellemzik. A validátorkliens az a szoftver, ami a validátor nevében működik, tárolva és felhasználva annak privát kulcsát. Egy validátorkliens több kulcspárt is tárolhat, így több validátort is üzemelhet. + + + + +A validátorhoz tartozó kulcspár pontosan 32 ETH összeget igényel ahhoz, hogy aktívvá váljon. Ha a kulcsokhoz több ETH kerül letétbe, az nem növeli meg a jutalmak lehetőségét, mert a validátor érvényes egyenlege 32 ETH. Tehát a letétbe helyezés 32 ETH összegenként történik, melyekhez saját kulcs és egyenleg tartozik. + +Egy validátorhoz ne kössön le többet, mint 32 ETH. Ez nem hoz több nyereséget. A validátor-ellenőrzés során a 32 ETH feletti rész automatikusan átkerül a visszavonási címre, ha az be van állítva a validátorhoz. + +Ha az egyéni letétbe helyezés túl nagy erőfeszítést igényelne Öntől, akkor nézze meg a letétbe helyezés, mint szolgáltatás opcióit, vagy ha kevesebb mint 32 ETH összegről van szó, akkor fontolja meg a letéti alapok szolgáltatást. + + + +Nem vezet súlyos büntetéshez és kizáráshoz (slashing) az, ha a validátor offline, de a hálózat állapota megfelelő. Kis mértékű inaktivitási büntetések várhatók, ha a validátor nem elérhető a tanúsításhoz egy adott korszakban (mely 6,4 perc hosszú), ez azonban különbözik a súlyos büntetéssel járó kizárástól (slashing). A kis büntetések kicsit kevesebbek, mint az a jutalom, amit a validátor a tanúsításért kapott volna, az elvesztett pénzt pedig vissza lehet nyerni ugyanannyi online töltött idővel. + +Az inaktivitási büntetés mértéke függ attól, hogy ugyanabban az időben mennyi validátor van offline. Ha a hálózat nagy része mind egyszerre lesz offline, akkor a büntetés sokkal nagyobb ezen validátorok esetében, mintha csak egy validátor lenne elérhetetlen. + +Szélsőséges esetben, ha a hálózat nem tud állapotot frissíteni, mert a validátorok harmada offline van, akkor ezek a felhasználók a kvadratikus inaktivitási elszivárgást szenvedik el, vagyis a validátorszámlákról exponenciálisan kiáramlik az ETH. Ezzel a rendszer végül képes helyrebillenteni magát azáltal, hogy az inaktív validátorok ETH-jét elégeti, amíg az egyenlegük 16 ETH lesz és ezzel automatikusan kilökődnek a validátorok közül. A megmaradó online validátorok végül teljesítik a több mint 2/3 arányt, kielégítve a túlnyomó többség elvét, hogy a lánc állapota megint frissítve legyen. + + + +Röviden, bár nem lehet garantálni, de a slahing kockázata szinte nulla, hogy ha jóhiszeműen jár el, kisebbségi klienst használ, az aláíró kulcsokat pedig csak egy gépen tartja. + +Néhány specifikus eset van, amikor a validátor súlyos büntetést kap és kilökik a hálózatból. A korábbi eseteknél kizárólag redundáns hardver volt beállítva, és az aláíró kulcsokat két különböző gépen tárolták egyszerre. Ez akaratlanul is dupla szavazást eredményezhet a kulcsokkal, ami súlyos vétség. + +Egy többségi kliens használatával (amit a hálózat 2/3 használ) is nő a slashing kockázata, hogyha a kliensben hiba áll fenn, és emiatt egy láncelágazás jön létre. Hibás elágazást okozhat, ami a lánc állapotaként rögzítésre kerül. Ahhoz, hogy visszatérjen a valódi lánc állapotához, egy „surround” szavazatot kell leadni egy véglegesített blokk visszaállításával. Ez is egy súlyos vétség, és elkerülhető a kisebbségi kliensek használatával. + +A kisebbségi kliensben lévő hiba nem fog végleges állapotot eredményezni, így nem vezet ahhoz, hogy két különböző állapotra szavazzanak helyenként (surround szavazat), és egyszerű inaktivitási büntetéssel jár, nem slashinggel. + + + + + +Az egyéni kliensek esetében kicsit különböző a teljesítmény, a felhasználói felület, mivel mindet különböző csapatok fejlesztik, különböző programozási nyelveken. Így nincsen „legjobb” kliens. Az összes működő kliens kiváló szoftver, melyek működési elve azonos, hogy szinkronizáljanak és kapcsolódjanak a blokklánchoz. + +Mivel az összes kliens ugyanazokat az alapvető funkcionalitásokat kínálja, így fontos, hogy Ön egy kisebbségi klienst válasszon, tehát nem azokat, amelyeket a validátorok többsége használ. Ez talán ellentmond a logikus gondolkodásnak, de a többségi vagy szupertöbbségi kliensek használata miatt megnő a slaghing kockázata, ha a kliensben valamilyen hiba van. Ezt a kockázatot jelentősen lecsökkenti egy kisebbségi kliens használata. + +Tudjon meg többet arról, hogy kliensdiverzitás miért kritikus fontosságú + + + +Habár a virtuális privát szerver (VPS) használható az otthoni hardver helyett, a validátorkliens fizikai elérhetősége és helye igenis számít. A centralizált felhőszolgáltatások, mint az Amazon Web Services vagy a Digital Ocean, lehetővé teszik, hogy nem kell hardvert venni és működtetni, de ez hatással van a hálózat centralizáltságára. + +Minél több validátorkliens működik ugyanazon a centralizált felhőszolgáltatón, annál veszélyesebbé válik a felhasználóknak. Ha ezek a szolgáltatók bármilyen esemény miatt elérhetetlenné válnak, legyen akár támadás, szabályozási kötelezettség, áram- vagy internetleállás, az összes validátorkliens ugyanakkor lesz offline. + +Az offline büntetések arányosak azzal, hogy hány validátor van még offline ugyanakkor. A VPS használata megnöveli az offline büntetés várható mértékét, a kvadratikus elszivárgás vagy akár a slashing kockázatát is, ha a kimaradás kellően nagy mértékű. A saját és a hálózat kockázatát minimalizálandó a felhasználó jobban jár, ha saját hardvert szerez és üzemeltet. + + + + +A Beacon-láncról való visszavonáshoz be kell állítani a visszavonási adatokat. + +Az új letétesek ezt megtették a kulcsgenerálás és a letétbe helyezés során. A meglévő letétesek, akik még nem állították ezt be, frissíthetik a kulcsaikat ezzel a funkcióval. + +Amint a visszavonási adatok be vannak állítva, a jutalmak (a 32 ETH-en felüli rész) rendszeresen és automatikusan átkerülnek a visszavonási címre. + +A teljes egyenleg visszavonásához végig kell menni a validátorkiléptetési folyamaton. + +Bővebben a letétbe helyezés visszavonásáról + + +## További olvasnivaló {#further-reading} + +- [Ethereum letétbe helyezési jegyzék](https://www.staking.directory/) – _Eridian és Spacesider_ +- [Az Ethereum-kliens diverzitásának problémája](https://hackernoon.com/ethereums-client-diversity-problem) – _@emmanuelawosika 2022._ +- [A kliensdiverzitás támogatása](https://www.attestant.io/posts/helping-client-diversity/) – _Jim McDonald 2022._ +- [Kliensdiverzitás az Ethereum konszenzus rétegén](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) – _jmcook.eth 2022._ +- [Hogyan kell: Ethereum validátorhardver vásárlása](https://www.youtube.com/watch?v=C2wwu1IlhDc) – _EthStaker 2022._ +- [Lépésről lépésre: hogyan kell csatlakozni az Ethereum 2.0 teszthálózathoz](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) – _Butta_ +- [Eth2 Slashing elkerülési tippek](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) – _Raul Jordan 2020._ + + diff --git a/public/content/translations/hu/07) Staking Pages/staking/withdrawals/index.md b/public/content/translations/hu/07) Staking Pages/staking/withdrawals/index.md new file mode 100644 index 00000000000..85c19d15b1d --- /dev/null +++ b/public/content/translations/hu/07) Staking Pages/staking/withdrawals/index.md @@ -0,0 +1,218 @@ +--- +title: A letétbe helyezés visszavonása +description: A letétvisszavonás működésének és a jutalmak megszerzésének áttekintése +lang: hu +template: staking +image: /images/staking/leslie-withdrawal.png +alt: Leslie, a rinocérosz a letétbe helyezésből származó jutalmaival +sidebarDepth: 2 +summaryPoints: + - A Shanghai/Capella frissítés lehetővé tette a letétek visszavonását az Ethereumon + - A validátor operátorainak meg kell adni ehhez egy visszavonási címet + - A jutalmakat néhány naponta automatikusan átkerülnek + - A validátorok, akik teljesen kiszállnak a letétből, a maradék egyenleget visszakapják +--- + + +A letétek visszavonását a 2023. április 12-i Shanghai/Capella frissítés tette lehetővé. Bővebben a Shanghai/Capella frissítésről + + +**A letétek visszavonása** azt jelenti, hogy a validátorszámla ETH-egyenlege, ami az Ethereum konszenzusrétegén található (Beacon-lánc), áthelyezésre kerül a végrehajtási rétegre, ahol fel lehet használni. + +**A jutalmak kifizetése** 32 ETH felett automatikusan és rendszeresen megtörténik az egyes validátorokhoz tartozó visszavonási címre, ahogy azt a felhasználó beállította. A felhasználó **teljesen kiszállhat a letétbe helyezésből**, felszabadítva a teljes validátoregyenleget. + +## A letétbe helyezésből eredő jutalmak {#staking-rewards} + +Az aktív validátorszámlákra a jutalmak kifizetése automatikusan megtörténik, és maximum 32 ETH egyenleg marad azokon. + +A 32 ETH feletti összeg nem adódik hozzá az alaphoz, nem növeli a validátor súlyát a hálózaton, így automatikusan visszavonásra kerül jutalomként néhány naponta. A visszavonási címet rögzíteni kell, de ezen kívül a validátor működtetőjének nincs több teendője. Ez a konszenzusrétegen zajlik, ezért nincs gáz/tranzakciós díj vonzata egyik lépésnél sem. + +### Hogyan jutottunk el idáig? {#how-did-we-get-here} + +Az elmúlt években az Ethereum számos hálózati fejlesztésen esett át, hogy a hálózatot az ETH biztosítsa, és ne az erőforrás-igényes bányászás (mining). A konszenzusban való részvétel az Ethereumon a letétbe helyezés (staking), mivel a tagok önként lekötötték az ETH-t, hogy a hálózatban részt tudjanak venni. A szabályokat követő felhasználók jutalmakat nyernek, a visszaélést pedig bünteti a rendszer. + +A letétbe helyezési szerződés létrehozásával (2020. november) néhány bátor Ethereum-úttörő önként zárolta a pénzeszközeit, hogy validátorokként működjenek – ezek olyan különleges számlák, melyek hivatalosan tanúsíthatnak és javasolhatnak blokkot a hálózat szabályait követve. + +A Shanghai/Capella frissítés előtt nem lehetett használni vagy elérni ezt a lekötött ETH-t. Most azonban automatikusan áthelyeződnek a jutalmak a kiválasztott számlára, és a lekötést is bármikor fel lehet oldani. + +### Hogyan tudok erre felkészülni? {#how-do-i-prepare} + + + +### Fontos figyelmeztetések {#important-notices} + +A visszavonási cím megadása szükséges ahhoz, hogy a validátorszámla egyenlegéből ETH visszavonás történjen. + + + Minden validátorszámlához egyszer, egyetlen visszavonási cím adható meg. Amint ezt a címet kiválasztották és elküldték a konszenzus rétegnek, nem lehet visszahívni vagy megváltoztatni. Ellenőrizze le a cím tulajdonosát és pontosságát, mielőtt elküldi azt. + + +Eközben a pénzeszközöket nem fenyegeti veszély, ha nem adja meg a címet, feltéve, hogy a mnemonikus/kulcsmondat biztonságban van offline, és nincs kitéve veszélynek. Amíg nem tudja megadni a visszavonási adatokat, addig az ETH egyszerűen a validátorszámlán marad. + +## A letétbe helyezés felbontása {#exiting-staking-entirely} + +A visszavonási számlára van szükség ahhoz, _bármilyen_ pénzeszközt ki lehessen utalni a validátorszámla egyenlegéből. + +Azoknak a felhasználóknak, akik teljesen ki akarnak lépni a letétbe helyezéből és a teljes egyenleget vissza akarják vonni, a validátorkulcsokkal alá kell írniuk és ki kell adniuk egy önként kiszállok üzenetet, ezzel elindul a lezárás folyamata. Ezt a validátorkliens végzi és a konszenzus csomópontjára küldi el, így nem kell hozzá gáz/díj. + +A kilépés változó ideig tart, attól függően, hogy hányan akarnak ugyanakkor kiszállni. Amint végbemegy, ez a számla már nem végez validátori feladatokat, nem jár neki ezért jutalom, és a kapcsolódó ETH nincs letétbe helyezve. Ekkora a számla teljesen „visszavonhatóként” lesz megjelölve. + +Ha a visszavonható jelölés megtörtént és a visszavonási adatok meg lettek adva, akkor nincs több teendő. A blokkot javaslók automatikusan és folyamatosan ellenőrzik, mondhatni söprik a számlákat a kilépő pénzeszközöket vizsgálva, így a számla egyenlege teljes mértékben átvezetésre kerül a következő söprésnél. + +## Mikortól elérhető a letétek visszavonása? {#when} + +A letétek visszavonása elérhető! A funkcionalitást a Shanghai/Capella frissítés tette elérhetővé 2023. április 12-én. + +Ennek következtében a korábban letétbe helyezett ETH-t vissza lehet vonni a normális Ethereum-számlákra. Ez lezárta a letétek likviditásának témáját, és az Ethereumot egy lépéssel közelebb vitte a céljához, ami egy fenntartható, skálázható, biztonságot, decentralizált ökoszisztéma. + +- [Bővebben az Ethereum történetéről](/history/) +- [Bővebben az Ethereum fejlesztési terveiről](/roadmap/) + +## Hogyan működik a visszavonási kifizetés? {#how-do-withdrawals-work} + +A validátorszámla státusza mondja meg, hogy egy validátor jogosult-e a visszavonásra vagy sem. Nincs szükség a felhasználó közreműködésére, hogy a számla visszavonásra kerül-e vagy sem – a teljes folyamat automatikusan üzemel a konszenzus réteg által, egy állandóan működő ciklusban. + +### Ön inkább vizuális típus? {#visual-learner} + +Nézze meg az Ethereum letétvisszavonásról szóló magyarázatát a Finematics-tól: + + + +### Validátor-ellenőrzés vagy söprés {#validator-sweeping} + +Amikor egy adott validátor be van ütemezve, hogy a következő blokkot ő fogja javasolni, akkor készítenie kell egy 16 tételből álló visszavonási listát. Kezdve a 0 validátorindexel, meghatározza, hogy az adott számla a protokoll szabályai szerint visszavonásra jogosult-e, és ha igen, akkor beteszi a listába. A validátorcsoport ott száll be, ahol az előző abbahagyta és a végtelenségig folytatja. + + +Képzeljen el egy analóg módon működő órát. Az óramutató egy irányba halad és sorban végigmegy minden számon, majd miután elérte az utolsó számot, visszaér a kezdőpontra.

+Tegyük fel 1–12 helyett 0-n található (ahol n a validátor számlák teljes száma, amelyek a konszenzus rétegen regisztrálva lettek; több mint 500 000 2023. januárjában).

+Az óramutató a következő validátorra mutat, hogy leellenőrizze azt visszavonás szempontjából. A 0-nál kezdi és végigmegy az összes számlán. Amikor eléri az utolsó validátort, akkor a ciklus újra elindul. + + +#### A számlák ellenőrzése visszavonási szempontból {#checking-an-account-for-withdrawals} + +Miközben a blokk javaslója a validátorokat ellenőrzi a lehetséges visszavonások miatt, minden validátornál néhány kérdéssel ellenőrzi, hogy kell-e visszavonást indítani, és mennyi ETH-t érint ez. + +1. **Van visszavonási cím megadva?** Ha nincs, akkor kihagyja a számlát, és nem lehet visszavonást kezdeményezni. +2. **A validátor kiszállt és visszavonható a számlája?** Ha a validátor kiszállt, és a számlája „visszavonhatóvá” vált, akkor egy teljes visszavonás történik. A teljes egyenlege átkerül a visszavonási címre. +3. **Az érvényes egyenleg 32 ETH?** Ha a számla rendelkezik visszavonási adatokkal, nem lépett ki a letétbe helyezésből, de jutalmak vannak a 32 ETH összegen túl, akkor egy részleges visszavonás indul, ami a 32 ETH feletti jutalmakat áthelyezi a visszavonási címre. + +Csak két döntés vagy cselekvés van, amit a validátor üzemeltetője meglép a validátor életciklusa során, és ezt a folyamatot közvetlenül befolyásolja: + +- A visszavonási adatok biztosítása, hogy bármit át lehessen vezetni +- A hálózatból való kilépés, ami egy teljes visszavonást indít el + +### Gáz/díjmentes {#gas-free} + +A letétek visszavonása anélkül zajlik, hogy a letétesnek tranzakciót kellene indítania, amiben adott mennyiségű ETH-t von ki. Ezért **nincs gáz/tranzakciós díj**, a visszavonások pedig nem versenyeznek, hogy bekerüljenek a végrehajtási réteg blokkjába. + +### Milyen gyakran kapom meg a letéti jutalmakat? {#how-soon} + +Egy blokkban maximum 16 visszavonást lehet végrehajtani. Ez alapján 115 200 validátor-visszavonást lehet egy nap alatt teljesíteni (ha minden slot eredményes). A visszavonásra nem jogosult validátárokat átugorják, ezért a teljes ellenőrzés kevesebb ideig tart. + +Ezt a kalkulációt kiterjesztve megbecsülhetjük, hogy egy adott számú visszavonást mennyi idő alatt lehet teljesíteni: + + + +| Visszavonások száma | Időszükséglet | +| :-------------------: | :--------------: | +| 400 000 | 3,5 nap | +| 500 000 | 4,3 nap | +| 600 000 | 5,2 nap | +| 700 000 | 6,1 nap | +| 800 000 | 7,0 nap | + + + +Ahogy látható, a feldolgozás lelassul, ahogy egyre több validátor van a hálózaton. A kihagyott slotok száma arányosan le tudja lassítani a folyamatot, de ez a lassabb verzióját mutatja a lehetséges kimenetnek. + +## Gyakran ismételt kérdések {#faq} + + +Nem, a visszavonási adatok megadása egyszeri, nem lehet változtatni azokon. + + + +A végrehajtási réteg visszavonási cím megadásával a validátor visszavonási adatai örökre megváltoztak. A korábbi adatok már nem működnek, az újak pedig a végrehajtási réteg számlájára mutatnak. + +A visszavonási cím lehet okosszerződés (melyet a programkódja irányít) vagy egy külső tulajdonú számla (EOA, melyet a privát kulcsa kontrollál). Ezek a számlák jelenleg nem tudnak üzenetet küldeni a konszenzusrétegnek, amely megváltoztatná a validátor hitelesítő adatait, ez a funkció pedig egy szükségtelen komplexitást adna a protokollhoz. + +Egy másik megoldás az adott validátorhoz tartozó visszavonási cím módosítására, ha a felhasználók okosszerződést választanak visszavonási címként, amely tudja kezelni a kulcsok rotálását, mint amilyen a Safe. Azok a felhasználók, akik a saját EOA számlájukra tették a pénzeszközöket, végezhetnek teljes kilépést, visszavonva az összes lekötött eszközt, majd újra letétbe helyezhetik az új hitelesítő adatokat használatával. + + + + +Ha Ön letéti alapokat vagy letéti tokeneket használ, ellenőrizze a szolgáltatójával, hogy hogyan kezelik a letétvisszavonást, mivel minden szolgáltatás másképp működik. + +Általánosságban a felhasználók szabadon visszavehetik a letétbe helyezett ETH-t vagy lecserélhetik a letéti szolgáltatójukat. Ha egy adott letéti alap túl nagy méretű lesz, akkor a pénzeszközöket ki lehet venni belőle és újra le lehet kötni egy kisebb szolgáltatóval. Ha pedig elég ETH gyűlt össze, akkor Önotthonról is végezhet letétbe helyezést. + + + + +Igen, ha a validátora megadta a visszavonási címet. Ezt egyszer kell megtenni, hogy a visszavonások teljesíthetők legyenek, utána a jutalmak automatikusan átkerülnek néhány naponta a validátorok ellenőrzésénél. + + + + +Nem, ha a validátor aktív a hálózaton, akkor a teljes visszavonás nem történik meg automatikusan. Az önkéntes kilépést manuálisan kell kezdeményezni. + +Amint a validátor végigvitte a kilépési folyamatot, a számlán pedig ott vannak a visszavonási adatok, akkor a maradék egyenleget átteszi a következő validátor-ellenőrzés. + + + + +A visszavonásokat úgy tervezték meg, hogy automatikusan minden olyan összeget áthelyezzenek, ami aktívan nem járul hozzá a letéthez. Ez érvényes a kilépő számlák teljes egyenlegére. + +Nem lehetséges manuálisan kérvényezni bizonyos mennyiségű ETH kivételét. + + + + +Javasoljuk, hogy a validátorműködtetők látogassanak el a Staking Launchpad Withdrawals oldalra, ahol további információkat találhatnak a letét kivonásához kapcsolódó felkészülésről, az események időzítéséről és arról, hogyan működik ez a kivonási funkció. + +Próbálja ki először a beállításait egy teszthálózaton, látogasson el a Holesky-teszthálózat Staking Launchpad oldalára. + + + + +Nem. Miután egy validátor kilépett, és a teljes egyenlegét kivette, az adott validátorra letétbe helyezett további összegek automatikusan átutalásra kerülnek a következő validátor-ellenőrzés során a visszavonási címre. Az ETH újbóli letétbe helyezéséhez egy új validátort kell aktiválni. + + +## További olvasnivaló {#further-reading} + +- [Staking Launchpad visszavonások](https://launchpad.ethereum.org/withdrawals) +- [EIP-4895: Beacon-lánc operációs műveletként intézi a visszavonásokat](https://eips.ethereum.org/EIPS/eip-4895) +- [Ethereum Cat Herders – Shanghai](https://www.ethereumcatherders.com/shanghai_upgrade/index.html) +- [PEEPanEIP #94: A letétbe helyezett ETH visszavonása (tesztelés) – Potuz & Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE) +- [PEEPanEIP#68: EIP-4895: Beacon lánc operációs műveletként intézi a visszavonásokat – Alex Stokes](https://www.youtube.com/watch?v=CcL9RJBljUs) +- [A validátor valós egyenlegének megértése](https://www.attestant.io/posts/understanding-validator-effective-balance/) diff --git a/public/content/translations/hu/08) Use cases 2/decentralized-identity/index.md b/public/content/translations/hu/08) Use cases 2/decentralized-identity/index.md new file mode 100644 index 00000000000..3b3d473c38d --- /dev/null +++ b/public/content/translations/hu/08) Use cases 2/decentralized-identity/index.md @@ -0,0 +1,191 @@ +--- +title: Nem központilag kibocsájtott identitás +description: Mi az a nem központilag kibocsátott identitás, és miért fontos? +lang: hu +template: use-cases +emoji: ":id:" +sidebarDepth: 2 +image: /images/eth-gif-cat.png +summaryPoint1: A hagyományos identitásrendszerek központosították az azonosítók kiadását, karbantartását és ellenőrzését. +summaryPoint2: A decentralizált identitás megszünteti a centralizált harmadik felektől való függőséget. +summaryPoint3: A kriptónak köszönhetően, a felhasználóknak újra van eszközük, hogy tárolják és kezeljék a saját azonosítójukat és tanúsítványaikat. +--- + +A virtuális identitás az életünk minden részét meghatározza napjainkban. Online szolgáltatások használata, bankszámla nyitás, szavazás a választásokon, ingatlan vásárlása, munkavállalás – mindegyikhez az identitás igazolása szükséges. + +Azonban a hagyományos azonosításkezelési rendszerek hosszú ideje központosított szereplőkre támaszkodtak, akik kibocsátják, tárolják és kezelik az azonosítóinkat és [tanúsítványainkat](/glossary/#attestation). Ez azt jelenti, hogy nem tudjuk irányítani az azonosítással kapcsolatos információinkat, és nem dönthetünk arról, hogy ki férhet hozzá a személyazonosító információinkhoz (PII), valamint hogy ezek a felek milyen mértékű hozzáférést kapnak. + +Ezen problémák megoldására decentralizált azonosítási rendszerek állnak rendelkezésre, amelyeket nyilvános blokkláncokon, például az Ethereumon, építettek. A decentralizált azonosítás lehetővé teszi az egyének számára, hogy kezeljék az azonosítással kapcsolatos információikat. A decentralizált azonosítási megoldásokkal _Ön is_ létrehozhat azonosítókat, illetve anélkül igényelhet és tárolhat tanúsítványokat, hogy központi hatóságokra, mint például szolgáltatók vagy kormányok, támaszkodna. + +## Mi az az identitás? {#what-is-identity} + +Az identitás az egyén önmagához való viszonyának értelmezése, egyedi jellemzők által meghatározva. Az identitás az _egyént_ jelenti, azaz egy különálló emberi entitást. Jelenthet még nem emberi entitást is, mint például egy szervezetet vagy hatóságot is. + + + +## Mik az azonosítók? {#what-are-identifiers} + +Az azonosító egy olyan információ, mely sajátos identitásra vagy identitásokra mutat rá. A hétköznapi azonosítók többek között: + +- Név +- Társadalombiztosítási szám / adószám +- Mobilszám +- Születési idő és hely +- Digitális azonosítók, mint e-mail-cím, felhasználói név, avatár + +Ezeket a hagyományos azonosítókat központi hatóságok bocsátják ki, tárolják és kontrollálják. Engedélyre van szükség a kormánytól ahhoz, hogy valaki megváltoztassa a nevét, vagy a közösségi média platformtól arra, hogy megváltoztassa a profilját. + +## A decentralizált identitás előnyei {#benefits-of-decentralized-identity} + +1. A decentralizált identitás növeli az egyénnek a saját azonosítói feletti kontrollját. A decentralizált azonosítók és tanúsítások anélkül igazolhatók, hogy egy központi hatóságra vagy egy harmadik fél által nyújtott szolgáltatásra kellene támaszkodni. + +2. A decentralizáltidentitás-megoldások úgy képesek igazolni és kezelni egy felhasználó identitását, hogy nem kell megbízni egy másik félben, zökkenőmentes és védi a magán jellegű információkat. + +3. A decentralizált identitás a blokklánc-technológiát felhasználva teremt bizalmat a különböző felek között és a tanúsítások érvényességét igazolva nyújt kriptográfiai garanciát. + +4. A decentralizált identitás átvihetővé, hordozhatóvá teszi a identitáshoz kapcsolódó adatokat. A felhasználók a mobil tárcájukban tárolják a tanúsításokat és azonosítókat, és eldönthetik, hogy kivel osztják meg azokat. A decentralizált azonosítók és tanúsítások nem az azokat kibocsátó szervezet adatbázisába vannak zárva. + +5. A decentralizált identitás jól illeszkedik a most kialakuló [nulla tudású (zero-knowledge)](/glossary/#zk-proof) technológiákhoz, mellyel az egyének anélkül tudják igazolni tulajdonukat vagy eredményeiket, hogy feltárnák, mi is az pontosan. Ez egy hatásos módja annak, hogy a bizalmat és a magán jelleget kombinálják olyan felhasználási módoknál, mint amilyen például a szavazás. + +6. A decentralizált identitás lehetővé teszi az [anti-Sybil](/glossary/#anti-sybil) mechanizmust, feltárva azt, amikor egyetlen ember több személynek adja ki magát egy adott játékban vagy azért, hogy teleszemetelje (spam) a rendszert. + +## A decentralizált identitás alkalmazásai {#decentralized-identity-use-cases} + +A decentralizált identitás számtalan esetben alkalmazható: + +### 1. Univerzális bejelentkezés (login) {#universal-dapp-logins} + +A decentralizált identitás segíthet, hogy a jelszóalapú bejelentkezésk helyett decentralizált hitelesítés legyen. A szolgáltatók tanúsításokat bocsáthatnak ki a felhasználóknak, amelyet az Ethereum-tárcájukban tárolnak. Például egy olyan tanúsítvány, ami egy [NFT](/glossary/#nft), és hozzáférést biztosít egy online közösséghez. + +Az [Ethereumba való bejelentkezés](https://login.xyz/) funkció ekkor lehető tenné a szervereknek, hogy megerősítsék a felhasználó Ethereum-számláját és lekérdezzék az ehhez szükséges tanúsításokat a számlacímükről. Ezáltal a felhasználónak nem kell hosszú jelszavakat megjegyeznie ahhoz, hogy különböző platformokat és weboldalakat érjen el, és így jobb felhasználói élményben lehet része. + +### 2. Ügyfél-azonosítás (KYC) {#kyc-authentication} + +Az online szolgáltatások használatakor a felhasználóknak tanúsításokat és hitelesítő adatokat kell megadniuk, mint például vezetői engedély vagy útlevél. Ez azonban aggodalomra adhat okot, mivel a magánjellegű információkkal visszaélhetnek, a szolgáltatók pedig nem tudják ellenőrizni a tanúsítások hitelességét. + +A decentralizált identitás révén a cégek elhagyhatják a hagyományos [ügyfél-azonosítást (KYC)](https://en.wikipedia.org/wiki/Know_your_customer), és ehelyett az ügyfelek identitását az igazolható bizonyítványok (VC) révén ellenőrizhetik. Ez csökkenti az azonosítások kezelésének költségét, és kivédi a hamis iratok használatát is. + +### 3. Szavazás és online közösségek {#voting-and-online-communities} + +Az online szavazás és a közösségi média két új alkalmazási területe a decentralizált identitásnak. Az online szavazások ki vannak téve a manipulációnak, főleg ha a rosszindulatú szereplők hamis identitásokat hoznak létre, hogy azokkal szavazzanak. A szavazás folyamatának integritását nagy mértékben növelné, ha az egyének a láncon belüli tanúsításokkal igazolnák magukat. + +A decentralizált identitás segít olyan online közösségek létrehozásában, melyek mentesek a hamis profiloktól. Például minden felhasználónak igazolnia kell a kilétét egy láncon belüli azonosítási rendszerrel, mint amilyen az Ethereum Névszolgáltatás (ENS), és így kizárhatók a nem emberi résztvevők (bot). + +### 4. Anti-Sybil védelem {#sybil-protection} + +A támogatást adó alkalmazások, melyek [kvadratikus szavazást](/glossary/#quadratic-voting) használnak, sebezhetők a [Sybil-támadásokkal](/glossary/#sybil-attack) szemben, mert a támogatás összege növekszik, ha több szavazat érkezik rá. Ez pedig arra ösztönzi a résztvevőket, hogy több identitással vegyenek részt a folyamatban. A decentralizált identitás megakadályozza ezt, mivel a résztvevők könnyedén igazolhatják, hogy valódi emberek, és nem kell hozzá specifikus, magán jellegű információkat feltárniuk magukról. + +## Mi az a tanúsítás? {#what-are-attestations} + +A tanúsítás egy olyan állítás, melyet az egyik entitás ad a másikról. Az Amerikai Egyesült Államokban a vezetői engedélyt a Gépjárművekkel foglalkozó hivatal (egyik entitás) bocsátja ki, mellyel tanúsítja, hogy az illető személy (másik entitás) autót vezethet. + +A tanúsítás nem azonos az azonosítókkal. A tanúsításhoz _szükség van_ azonosítókra, hogy egy sajátos identitásra hivatkozzanak, és az ehhez tartozó valamilyen jellemzőről adjanak egy állítást. Tehát a jogosítvány tartalmaz azonosítókat (név, születési idő, cím), ugyanakkor tanúsítja az autóvezetési jogosultságot. + +### Mik azok a decentralizált azonosítók? {#what-are-decentralized-identifiers} + +A hagyományos azonosítók, mint a hivatalos név vagy e-mail-cím, harmadik személyen múlnak – a kormányokon és az e-mail-szolgáltatókon. A decentralizált azonosítók (DID) különböznek ezektől – ezeket nem egy központi hatóság állítja ki, kezeli vagy kontrollálja. + +A decentralizált azonosítókat az egyének állítják ki, kezelik és kontrollálják. Az [Ethereum-számla](/glossary/#account) is egy decentralizált azonosító. A felhasználó annyi számlát hozhat létre, amennyit csak akar, anélkül hogy bárki engedélyére szükség lenne vagy egy központ nyilvántartásban kellene tárolni azokat. + +A decentralizált azonosítókat elosztott főkönyveken ([blokklánc](/glossary/#blockchain)) vagy [peer-to-peer hálózatokon](/glossary/#peer-to-peer-network) tárolják. Ennek okán a DID-ekre az jellemző, hogy [globálisan egyediek, sokrétűen felhasználhatók és kriptográfiával ellenőrizhetők](https://w3c-ccg.github.io/did-primer/). A decentralizált azonosító különféle entitásokhoz kapcsolódhat, mint emberek, szervezetek vagy kormányzati szervek. + +## Mi teszi lehetővé a decentralizált azonosítók használatát? {#what-makes-decentralized-identifiers-possible} + +### 1. Nyilvánoskulcs-kriptográfia {#public-key-cryptography} + +A nyilvánoskulcs-kriptográfia egy olyan információbiztonsági lépés, amely az entitás számára egy [nyilvános kulcsot](/glossary/#public-key) és egy [privát kulcsot](/glossary/#private-key) hoz létre. A nyilvános kulcson alapuló [kriptográfiát](/glossary/#cryptography) a blokklánchálózatok arra használják, hogy igazolják a felhasználók identitását és a digitális eszközök tulajdonjogát. + +Néhány decentralizált azonosító, mint amilyen az Ethereum-számla, egyaránt rendelkezik nyilvános és privát kulccsal. A nyilvános kulcs meghatározza a számla birtokosát, miközben a privát kulcs aláírhatja az adott számlához tartozó üzeneteket, illetve feloldhatja azok titkosítását. A nyilvánoskulcs-kriptográfia igazolja az entitások identitását, megakadályozza, hogy valaki más felöltse azt vagy hamisat használjon – mindezt a [kriptográfiai aláírás](https://andersbrownworth.com/blockchain/public-private-keys/) révén, amely minden állítást igazol. + +### 2. Decentralizált adattárolók {#decentralized-datastores} + +A blokklánc egy igazolható adatnyilvántartásként működik: az információk nyilvános, decentralizált tárhelye, melynek használatakor nem kell megbízni egy központi szereplő (jóhiszemű) magatartásában. A nyilvános blokkláncok létezése miatt nincs többé szükség arra, hogy az azonosítókat központi nyilvántartásokban tárolják. + +Ha valaki szeretné egy decentralizált azonosító érvényességét ellenőrizni, akkor a blokkláncon megkeresheti a hozzá tartozó nyilvános kulcsot. Ez különbözik a hagyományos azonosítóktól, ahol harmadik entitás tudja csak igazolni azt. + +## A decentralizált azonosítók és a tanúsítás hogyan teszi lehetővé a decentralizált identitást? {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity} + +A decentralizált identitás az az elképzelés, hogy az identitáshoz kapcsolódó információkat mindenki maga kontrollálja, azok privátak és hordozhatók, átvihetők, melynek az elsődleges építőkövei a decentralizált azonosítók és a tanúsítások. + +A decentralizált identitás kontextusában a tanúsítások (más néven [Igazolható bizonyítványok vagy hitelesítő adatok / VC](https://www.w3.org/TR/vc-data-model/)) olyan hamisításmentes, kriptográfiailag igazolható állítások, melyeket a kibocsátó készít. Minden tanúsítás vagy igazolható bizonyítvány, amit egy entitás (például egy szervezet) kiállít, az kapcsolódik az ő decentralizált azonosítójukhoz (DID). + +Mivel a DID-ek a blokkláncon vannak tárolva, ezért bárki ellenőrizni tudja a tanúsítás érvényességét azáltal, hogy megnézi az Ethereumon a kiállító DID-jét. Lényegében az Ethereum-blokklánc olyan, mint egy globális könyvtár, ahol az adott entitásokhoz kapcsolódó decentralizált azonosítókat igazolni lehet. + +A decentralizált azonosítók teszik lehetővé, hogy a tanúsításokat a kiállító maga kontrollálja és azok igazolhatók legyenek. Ha a kiállító már nem is létezik, a tanúsítást kapó entitás mindig rendelkezik annak eredetének és érvényességének bizonyítékával. + +A decentralizált azonosítók elengedhetetlenek abban is, hogy megvédjék a személyes adatok magán jellegét a decentralizált identitás révén. Például, ha egy egyén beadja egy tanúsítás bizonyítékát (egy vezetői engedélyt), akkor az azt igazoló félnek nem kell ellenőrizni a bizonyítékban található adatok érvényességét. Ehelyett az ellenőrző félnek csak a tanúsítás eredetiségének kriptográfiai garanciáira, valamint a kiállító szervezet identitására van szükség ahhoz, hogy a bizonyíték érvényességét megállapítsa. + +## A tanúsítások típusai a decentralizált identitás esetében {#types-of-attestations-in-decentralized-identity} + +A tanúsítások tárolása és visszakeresése az Ethereumon alapuló, identitáshoz kötődő ökoszisztémában eltérően működik, mint a hagyományos identitáskezelés. Különféle megközelítések léteznek, hogyan állítják ki, tárolják és igazolják a tanúsításokat a decentralizált identitást biztosító rendszerekben: + +### Blokkláncon kívüli tanúsítások {#off-chain-attestations} + +A blokkláncon való tanúsítástárolással kapcsolatban felmerül az a konszern, hogy olyan információkat tartalmazhat, melyeket az egyének privát módon szeretnének kezelni. Az ilyen tanúsítások tárolása az Ethereum-blokkláncon, annak nyilvános természete miatt nem előnyös. + +Erre az a megoldás, hogy a kiállított tanúsításokat a felhasználók láncon kívül tartják digitális tárcákban, de azok alá vannak írva a kiállító decentralizált azonosítójával (DID), mely a láncon belül elérhető. Ezeket a tanúsításokat [JSON Web Tokenként](https://en.wikipedia.org/wiki/JSON_Web_Token) kódolják, és tartalmazzák a kiállító digitális aláírását – így a láncon kívüli azonosítási igényeket könnyedén igazolni tudja. + +A következő példa elmagyarázza a láncon kívüli tanúsításokat: + +1. Egy egyetem (kiállító) létrehoz egy tanúsítást (egy digitális egyetemi diplomát), aláírja azt a kulcsaival, és átadja Bobnak (az identitás tulajdonosának). + +2. Bob egy állásra jelentkezik és igazolni akarja iskolai tanulmányait a munkaadónak, ezért megosztja vele a tanúsítást a mobil tárcájából. A vállalat (ellenőrző) ekkor megbizonyosodhat a tanúsítás érvényességéről azáltal, hogy megnézi a kiállító DID-jét (pl. az Ethereumon lévő nyilvános kulcsát). + +### Blokkláncon kívüli tanúsítások állandó eléréssel {#offchain-attestations-with-persistent-access} + +Ebben az elrendezésben a tanúsításokat átalakítják JSON file-okká és a láncon kívül tárolják (ideálisan egy [decentralizált felhőben](/developers/docs/storage/), mint a IPFS vagy a Swarm). Azonban a JSON-fájl [hash-kódja](/glossary/#hash) a láncon van eltárolva és egy DID-hez kapcsolódik egy láncon belüli nyilvántartáson keresztül. A kapcsolódó DID lehet a tanúsítás kiállítójáé vagy azé, aki azt kapta. + +Ez a megközelítés lehetővé teszi, hogy a tanúsítások állandóan elérhetők legyenek a blokkláncon, miközben a kapcsolódó információk titkosítottak és igazolhatók. Mivel a privát kulcs tulajdonosa titkosítani tudja az információt, ezért képes szelektív módon nyilvánossá tenni azt. + +### Blokkláncon belüli tanúsítások {#onchain-attestations} + +A blokkláncon belüli tanúsítások [okosszerződésekben](/glossary/#smart-contract) vannak tárolva az Ethereum-blokkláncon. Az okosszerződés (ami nyilvántartásként működik) hozzáköti a tanúsítást egy kapcsolódó, láncon belüli decentralizált azonosítóhoz (egy nyilvános kulcshoz). + +A következő példa bemutatja, hogyan működik a láncon belüli tanúsítás a gyakorlatban: + +1. Egy cég (XYZ vállalat) azt tervezi, hogy egy okosszerződésen keresztül tulajdonosi részvényeket ad el, de csak olyan vásárlókat fogad el, akiknek a háttere ellenőrizve lett. + +2. XYZ vállalat a háttérellenőrzéssel megbízott cégtől láncon belüli tanúsításokat kap az Ethereumon. Ez a tanúsítás igazolja, hogy az egyén megfelelt az ellenőrzés során, de nem tárja fel semmilyen személyes adatát. + +3. A részvényeket eladó okosszerződés meg tudja nézni az átvilágított vevőkre vonatkozó nyilvántartási szerződést, így meghatározhatja, hogy kik vásárolhatnak részvényt. + +### Egyénhez kötött tokenek és identitás {#soulbound} + +Az [egyénhez kötött tokeneket](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([nem átadható NFT-k](/glossary/#nft)) arra lehet használni, hogy egy adott tárcához tartozó egyedi információkat gyűjtsenek. Ez gyakorlatilag létrehoz egy egyedi, láncon belüli identitást, amely egy adott Ethereum-címhez kötődik, és eredményeket (mint egy online tanfolyam elvégzése vagy egy játékban elért szint) vagy közösségi részvételt jelentő tokeneket foglal magába. + +## Használjon decentralizált identitást {#use-decentralized-identity} + +Számtalan ambiciózus projekt használja az Ethereumot a decentralizált identitási megoldások alapjaként: + +- **[Ethereum Névszolgáltatás (ENS)](https://ens.domains/)** – _Egy decentralizált névadó rendszer a láncon belüli, gép által kiolvasható azonosítókra, mint amilyenek az Ethereum-tárcacímek, a tartalomra vonatkozó hash-kódok és a metaadatok._ +- **[SpruceID](https://www.spruceid.com/)** – _Egy decentralizált identitási projekt, mely lehetővé teszi, hogy a felhasználók a digitális identitásukat Ethereum-számlákkal és ENS-profilokkal kontrollálják ahelyett, hogy harmadik személyre támaszkodnának._ +- **[Ethereum tanúsítási szolgáltatás (EAS)](https://attest.sh/)** – _Egy decentralizált főkönyv/protokoll láncon belüli vagy láncon kívüli tanúsítások készítésére._ +- **[Proof of Humanity](https://www.proofofhumanity.id)** – _Az emberség igazolása (PoH) egy közösségi identitás igazolására készült rendszer, mely az Ethereumra épül._ +- **[BrightID](https://www.brightid.org/)** – _Egy decentralizált, nyílt forráskódú, közösségi identitási hálózat, amely új módot keres az azonosításra egy közösségi gráf megalkotásával és elemzésével._ +- **[walt.id](https://walt.id)** – _Nyílt forráskódú, decentralizált identitás- és tárcainfrastruktúra, amely lehetővé teszi a fejlesztőknek és szervezeteknek, hogy kihasználják a szuverén identitást, valamint az NFT-ket/SBT-ket._ +- **[Veramo](https://veramo.io/)** – _Egy JavaScript keretrendszer, amellyel bárki könnyedén tud kriptográfiailag ellenőrizhető adatot használni az alkalmazásaiban._ + +## További olvasnivaló {#further-reading} + +### Cikkek {#articles} + +- [Blokklánc esettanulmányok: blokklánc a digitális identitás területén](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_ +- [Mi az az Ethereum ERC725? Független identitáskezelés a blokkláncon](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_ +- [Hogyan tudja a blokklánc megoldani a digitális identitás problémáját](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Chow_ +- [Mi az a decentralizált identitás és miért érdemes figyelembe venni?](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_ +- [Bevezetés a decentralizált identitás világába](https://walt.id/white-paper/digital-identity) – _Dominik Beron_ + +### Videók {#videos} + +- [Decentralizált identitás (Bonus Livestream Session)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Kiváló magyarázó videó a decentralizált identitásról Andreas Antonopoloustól_ +- [Az Ethereumba való bejelentkezés és a decentralizált identitás témája a Ceramic, IDX, React és 3ID Connect használatával](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _YouTube útmutató a személyazonosítási rendszer kiépítéséről, mely az Ethereum-tárca alapján létrehozza, kiolvassa és frissíti a felhasználó profilját – Nader Dabit_ +- [BrightID – Decentralizált identitás az Ethereumon](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _Bankless podcast epizód a BrightID-ról, ami egy decentralizált identitási megoldás az Ethereumon_ +- [A láncon kívüli internet: decentralizált identitás és igazolható bizonyítványok (VC)](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — EthDenver 2022 Evin McMullen prezentációja +- [A hitelesítő adatok bemutatása](https://www.youtube.com/watch?v=ce1IdSr-Kig) – YouTube magyarázó videó példával Tamino Baumanntól + +### Közösségek {#communities} + +- [ERC-725 szövetség a GitHubon](https://github.com/erc725alliance) — _Az ERC725 szabvány támogatói, mely az Ethereum-blokkláncon való identitáskezelést célozza_ +- [SpruceID Discord-szerver](https://discord.com/invite/Sf9tSFzrnt) — _Rajongók és fejlesztők közössége, akik az Ethereumba való bejelentkezés funkcióján dolgoznak_ +- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _Fejlesztői közösség, melynek célja az alkalmazásokhoz szükséges igazolható adatok keretrendszerének kidolgozása_ +- [walt.id](https://discord.com/invite/AW8AgqJthZ) – _Fejlesztők és építők közössége, akik a decentralizált identitás számtalan iparágban való felhasználási területeivel foglalkoznak_ diff --git a/public/content/translations/hu/08) Use cases 2/desci/index.md b/public/content/translations/hu/08) Use cases 2/desci/index.md new file mode 100644 index 00000000000..026acb08c2a --- /dev/null +++ b/public/content/translations/hu/08) Use cases 2/desci/index.md @@ -0,0 +1,138 @@ +--- +title: Nem központosított kutatás (DeSci) +description: A decentralizált tudomány áttekintése az Ethereumon +lang: hu +template: use-cases +emoji: ":microscope:" +sidebarDepth: 2 +image: /images/future_transparent.png +alt: "" +summaryPoint1: Egy globális és nyitott alternatívája a jelenlegi tudományos rendszernek. +summaryPoint2: Olyan technológia, mely lehetővé teszi a tudósok számára, hogy finanszírozási alapot gyűjtsenek, kísérleteket végezzenek, megosszák az adatokat, kommunikálják elképzeléseiket stb. +summaryPoint3: A nyitott tudomány mozgalomra épül. +--- + +## Mi az a decentralizált tudomány (DeSci)? {#what-is-desci} + +A decentralizált tudomány (DeSci) egy olyan mozgalom, melynek célja a nyilvános infrastruktúra létrehozása a tudományos eredmények korrekt és egyenlő finanszírozása, létrehozása, véleményezése, hitelesítése, tárolása és terjesztése érdekében a [web3](/glossary/#web3)-technológiára alapozva. + +A DeSci egy olyan ökoszisztémát akar megalkotni, ahol a tudósok ösztönözve vannak a kutatásaik nyilvános megosztására, munkájukért javadalmazásban részesülnek, miközben megengedik, hogy bárki könnyedén elérje és hozzájáruljon a kutatásukhoz. A DeSci azt az elképzelést váltja valósággá, hogy a tudományos ismeretek mindenkinek elérhetők, a tudományos kutatások pedig transzparensek legyenek. A DeSci egy decentralizáltabb és jobban elosztott tudományos kutatási modellt hoz létre, mely ellenállóbb a cenzúrával és a központi hatóságok irányításával szemben. A DeSci reményeink szerint egy olyan környezetet teremt, ahol az új és szokatlan elképzelések virágozni fognak azáltal, hogy a finanszírozáshoz, a tudományos eszközökhöz és a kommunikációs csatornákhoz való hozzáférést decentralizáljuk. + +A decentralizált tudomány sokrétűbb finanszírozási forrásokat (a [DAO-októl](/glossary/#dao) kezdve, [a kvadratikus adományozáson](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) keresztül a közösség általi finanszírozásig és még tovább), sokkal elérhetőbb adatokat és módszereket tesz lehetővé, miközben ösztönzi a reprodukálhatóságot is. + +### Juan Benet – A DeSci mozgalom + + + +## Hogyan fejleszti a DeSci a tudományt {#desci-improves-science} + +Következzen egy hozzávetőleges felsorolás a tudomány területén tapasztalt fő problémákról, és arról, hogy a decentralizált tudomány hogyan segíthet ezeken + +| **Decentralizált tudomány** | **Hagyományos tudomány** | +| ------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | +| A finanszírozási alapok elosztását a **nyilvánosság határozza meg** olyan módszerek alapján, mint a kvadratikus adományozás vagy a DAO-k. | Kicsi, zárt, **központosított csoportok** irányítják a finanszírozási források elosztását. | +| A tudósok dinamikus csapatokat alkotnak társaikkal, akik a **világ bármelyik pontján** lehetnek. | A finanszírozási alapok és a helyi intézmények **behatárolják** a kollaborációt. | +| A finanszírozási döntések online történnek és **transzparensek**. Új finanszírozási mechanizmusokat térképeznek fel. | A finanszírozási döntéseket hosszú átfutási idővel hozzák meg és **korlátolt transzparencia** jellemzi azokat. Kevés finanszírozási mechanizmus létezik. | +| A megosztott laboratóriumi szolgáltatások könnyebbek és átláthatóbbak a [web3](/glossary/#web3)-technológia révén. | A megosztott laboratóriumi erőforrások gyakran **lassúak és kevéssé átláthatók**. | +| A **publikálás új modelljei** alakíthatók ki, amelyek a web3-alapokat használják a bizalom, átláthatóság és univerzális hozzáférés biztosítására. | Ön a meglévő publikációs utakat használja, melyekről gyakran mondják, hogy **nem hatékonyak, elfogultak és kizsákmányolók**. | +| **Tokeneket és reputációt lehet szerezni a tudományos eredmények szakértői értékeléséért**. | A **szakértői értékelést nem fizetik meg**, csak a profitorientált kiadók javát szolgálja. | +| **A tudós birtokolja a szellemi tulajdont (IP)**, melyet ő hoz létre és transzparens feltételek szerint osztja meg azt. | **Az intézmény birtokolja a szellemi tulajdont**, amit a tudós létrehoz. Az ahhoz való hozzáférés nem egyértelmű. | +| **A kutatás teljes egészét megosztják**, beleértve a sikertelen erőfeszítések adatait is, mivel minden lépés a blokkláncon található. | **A publikációk részrehajlók**, mivel a kutatók nagyobb valószínűséggel osztják meg a sikeres eredményeket hozó kísérleteket. | + +## Az Ethereum és a DeSci {#ethereum-and-desci} + +A decentralizált tudományt kiszolgáló rendszer robosztus biztonságot, minimális pénzügyi és tranzakciós költséget, és az alkalmazásfejlesztést támogató gazdag ökoszisztémát igényel. Az Ethereum mindent megad ahhoz, hogy kialakuljon a decentralizált tudomány technológiája. + +## A DeSci alkalmazási területei {#use-cases} + +A DeSci egy olyan tudományos eszköztárat épít, amely be tudja vezetni a tradicionális akadémikus világát a digitális világba. Következzen néhány alkalmazási terület, amit a web3 ajánl a tudományos közösségnek. + +### Publikálás {#publishing} + +A tudományos publikálás közismerten problémás, mivel olyan kiadókon alapszik, amelyek a tudósok, szakértők és szerkesztők nem megfizetett munkájára építenek, hogy megszülessen a kézirat, utána pedig elképesztő kiadási díjakat számolnak fel érte. A nyilvánosság, aki általában közvetett módon fizet ezért a munkáért és a kiadási költségeiért az adózáson keresztül, sokszor nem éri el ugyanezt a munkát, csak ha a kiadónak újra fizet érte. Az egyéni tudományos munkák megjelentetésének teljes költsége sokszor öt számjegyű összeg (USD-ben kifejezve), amely aláássa a tudományos ismeret alapvető eszméjét, mint [közjó](/glossary/#public-goods), miközben hatalmas profitot generál a kiadók kis csoportjának. + +Ingyenes és nyílt hozzáférésű platformok állnak rendelkezésre pre-print szerverek (online könyvtárak) formájában, [mint amilyen az ArXiv is](https://arxiv.org/). Ugyanakkor ezek a platformok nem üzemeltetnek minőségi ellenőrzést, [anti-sybil mechanizmust](/glossary/#anti-sybil), és nem trekkelik a cikkszintű mérőszámokat, tehát csak valamilyen formában nyilvánosságra hozzák azt, amit utána átadnak a hagyományos kiadóknak. A SciHub a kiadott munkákat ingyen elérhetővé teszi, ugyanakkor nem legális módon, és csak azután, hogy a kiadók megkapták érte a fizetségüket és az adott munkát szigorú szerzői jogi szabályozásba csomagolják. Ez egy kritikus hiányosság az elérhető tudományos munkák és adatok terén, melyet egy beágyazott törvényességi mechanizmus és ösztönzési modell támaszt alá. Az ilyen rendszer megépítéséhez szükséges eszközök elérhetők a web3-ban. + +### Megismételhetőség és újbóli előállíthatóság {#reproducibility-and-replicability} + +A megismételhetőség és újbóli előállíthatóság a minőségi tudományos felfedezések alapkövei. + +- A megismételhető eredmények lényege, hogy egymás után többször elérhető ugyanaz az eredmény adott csapat által, adott módszertant használva. +- Az újbóli előállíthatóság lényege, hogy egy másik csapat is azonos eredményre jut ugyanazokat a kísérleti tényezőket használva. + +Az új web3 saját eszközei biztosítani tudják, hogy a megismételhetőség és újbóli előállíthatóság a felfedezés alapjaiként szolgálnak. Beleszőhetjük a minőségi tudományt az akadémikus világ technológiai szövetébe. A web3 képes minden egyes elemzési komponens esetében [tanúsítást](/glossary/#attestation) kreálni: a nyers adat, a számítási motor és az alkalmazás eredményei esetében. A konszenzuson alapuló rendszerek szépsége az, hogy amikor egy megbízható hálózat (trusted network) tartalmazza ezeket az összetevőket, akkor a hálózat minden egyes tagja felelős lehet azért, hogy újból előállítsa a számítást és validálja az eredményeket. + +### Finanszírozás {#funding} + +A jelenlegi elterjedt modell a tudományos tevékenységek finanszírozására az, hogy a tudósok egyénileg vagy csoportban írásos jelentkezést adnak be egy finanszírozással foglalkozó ügynökségnek. A megbízottak egy kis bizottsága pontozza a jelentkezéseket és interjút folytat a jelentkezőkkel, mielőtt finanszírozást biztosítana a jelentkezők egy kis részének. Amellett, hogy ez az eljárás szűk keresztmetszetet hoz létre, hiszen néha **évekig is várni kell** a jelentkezés és a támogatás elnyerése között, a módszer nagy mértékben **sebezhető a részrehajlás, az önérdek és a bizottság politikai beállítottsága miatt**. + +Az elemzések kimutatták, hogy ezek a bizottságok kvázi alkalmatlanok arra, hogy kiválasszák a jó minőségű jelentkezéseket, mivel ugyanazt a jelentkezést más-más bizottságok teljesen másképpen ítélik meg. Mivel a finanszírozási keretek szűkösek, ezért a tudományos tevékenység az idősebb kutatók kis csoportjára szűkül le, akik konzervatívabb projekteken dolgoznak. Ennek következtében egy szélsőségesen versenyző finanszírozási helyzet alakult ki, mely torz ösztönzésekkel és fullasztó innovációkkal jár. + +A web3 képes arra, hogy megbontsa ezt a megtört, torz finanszírozási modellt azáltal, hogy különféle ösztönzési módszereket tud alkalmazni, melyeket a DAO-k és a web3 résztvevők már széles körben alkalmaznak. [Retroaktív közjavak finanszírozása](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c), [kvadratikus finanszírozás](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531), [DAO-irányítás](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) és [tokenizált ösztönző struktúrák](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) – néhány olyan Web3-eszköz, amely forradalmasíthatja a tudomány finanszírozását. + +### A szellemi tulajdon (IP) birtoklása és fejlesztése {#ip-ownership} + +A szellemi tulajdon (IP) nagy probléma a hagyományos tudomány területén: onnantól kezdve, hogy az beragad az egyetemekre vagy nem használják a biotechnológiai tevékenységben, odáig, hogy hírhedten nehéz meghatározni annak értékét. Ugyanakkor a digitális eszközök tulajdonlására (mint amilyenek a tudományos adatok vagy cikkek) a web3 rendkívül jól használja a [nem helyettesíthető tokeneket (NFT)](/glossary/#nft). + +Ugyanazon a módon, ahogy az NFT-k képesek a jövőbeli tranzakciók után is fizetni az eredeti alkotónak, lehetséges transzparens értékteremtő láncokat meghatározni arra, hogy a kutatókat, az irányító szerveket (mint a DAO) vagy akár a kutatási adatokat biztosító személyeket díjazzák. + +[Az IP-NFT-k](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) arra is használhatók, hogy a kutatási kísérletek decentralizált adattárháza jöjjön létre, és bekerüljön az NFT- és [DeFi](/glossary/#defi)-alapú finanszírozásba (a töredékes forrásoktól a kölcsönalapok és az értékfelmérés felé mozdulva). Az eredetileg is láncon belül létező entitások, mint a DAO-k, például a [VitaDAO](https://www.vitadao.com/), végezhet kutatást közvetlenül a láncon. A nem átadható, [egyénhez kötött (soulbound) tokenek](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) kifejlődése szintén fontos lehet a DeSci számára, hogy a decentralizált tudomány résztvevői az Ethereum-címükhöz kapcsoltan bizonyítani tudják munkásságukat és hitelesítő adataikat. + +### Adattárolás, adatelérés és architektúra {#data-storage} + +A tudományos adatok sokkal hozzáférhetőbbek a web3-sémák használatával, a megosztott tárolás révén pedig a kutatások nem tudnak megsemmisülni a különféle kataklizmaesemények esetén. + +A kiindulópont egy olyan rendszer, melyet bármelyik decentralizált identitás elér, aki a szükséges igazolható bizonyítványokkal (VC) rendelkezik. Ennek következtében az bizalmas adatokat biztonságos módon tudják a megbízott felek replikálni, ellenállóbbak a duplikációval és a cenzúrával szemben, lehetséges az eredmények újbóli előállítása, ráadásul több résztvevő is kollaborálhat és új adatokat adhat a meglévőkhöz. A bizalmas adatokat kezelő számítástechnikai módszerek, mint a [compute-to-data](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol), alternatív hozzáférési lehetőséget biztosítanak a nyers adatok replikálására, illetve megbízható kutatási környezetet (TRE) alakítanak ki a legbizalmasabb adatok számára. A megbízható kutatási környezetekre (TRE) [az Országos Egészségügyi Szolgálat (NHS)](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb) úgy hivatkozik, mint az adatok titkosságát figyelembe vevő és együttműködést támogató, innovatív megoldás, mivel egy olyan ökoszisztémát hoz létre, ahol a kutatók biztonságos módon dolgozhatnak az adatokkal helyben, és közben megoszthatják a programkódjaikat és gyakorlataikat. + +A rugalmas web3-adatkezelési megoldások támogatják ezeket a szcenáriókat, és egy valóban nyitott és nyilvános tudomány alapjait biztosítják, ahol a kutatók közjót hoznak létre, és nem kell hozzáférési engedélyeket vagy díjakat fizetniük. A web3 nyilvános adatmegoldásai, mint a IPFS, Arweave és Filecoin a decentralizációra vannak optimalizálva. A dClimate például univerzális hozzáférést biztosít a klíma- és időjárási adatokhoz, beleértve az időjárási állomásokat és a klíma-előrejelző modelleket. + +## Kapcsolódjon be {#get-involved} + +Fedezze fel a projekteket és csatlakozzon a DeSci közösségéhez. + +- [DeSci.Global: globális események és találkozók](https://desci.global) +- [Blockchain for Science Telegram](https://t.me/BlockchainForScience) +- [Molecule: Finanszírozás biztosítása és elnyerése a kutatási projektjére](https://www.molecule.xyz/) +- [VitaDAO: hosszútávú kutatások finanszírozása a szponzorált kutatási megállapodások alapján](https://www.vitadao.com/) +- [ResearchHub: tudományos eredmények publikálása és azok megvitatása munkatársaival](https://www.researchhub.com/) +- [LabDAO: fehérjék számítógépes szimulációja](https://alphafodl.vercel.app/) +- [dClimate API: keresés a decentralizált közösség által gyűjtött klímaadatokban](https://api.dclimate.net/) +- [DeSci Foundation: DeSci publikációs eszközfejlesztés](https://descifoundation.org/) +- [DeSci.World: itt minden megtudható a decentralizált tudományról](https://desci.world) +- [OceanDAO: az adattal kapcsolatos tudományok DAO által irányított finanszírozása](https://oceanprotocol.com/) +- [Opscientia: nyílt, decentralizált, tudományos munkafolyamatok](https://opsci.io/research/) +- [Bio.xyz: finanszírozás szerzése a biotechnológiai DAO-jához vagy decentralizált tudományos projektjéhez](https://www.bio.xyz/) +- [Fleming Protocol: nyílt forráskódú adatgazdaság, amely fűti a kollaboratív orvosbiológiai felfedezéseket](http://flemingprotocol.io/) +- [Active Inference Institute](https://www.activeinference.org/) +- [IdeaMarkets: decentralizált tudomány hitelességének támogatása](https://ideamarket.io/) +- [DeSci Labs](https://www.desci.com/) +- [ValleyDAO: egy nyitott, globális közösség, mely pénzügyi forrásokat és fordítási támogatást kínál a szintetikus biológiai kutatáshoz](https://www.valleydao.bio) +- [Cerebrum DAO: pénzügyi támogatást és gondoskodást kínál olyan megoldásoknak, melyek fejlesztik az agyi egészséget és megakadályozzák az idegsorvadást](https://www.cerebrumdao.com/) +- [CryoDAO: támogatást adnak a mélyhűtés területén működő innovatív kutatásoknak](https://www.cryodao.org) + +Örömmel vesszük, ha bárki új projektet javasol – kérjük, tekintsék meg a [listázási szabályzatot](/contributing/adding-desci-projects/)! + +## További olvasnivaló {#further-reading} + +- [DeSci Wiki Jocelynn Pearl és UltraRare által](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#) +- [Útmutató a decentralizált biotechnológiához – Jocelynn Pearl (a16z future)](https://future.a16z.com/a-guide-to-decentralized-biotech/) +- [A DeSci ügye](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/) +- [Útmutató a DeSci-hez](https://future.com/what-is-decentralized-science-aka-desci/) +- [A decentralizált tudomány forrásai](https://www.vincentweisser.com/decentralized-science) +- [Molecule Biopharma IP-NFT-k – technikai leírás](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description) +- [Bizalom nélküli rendszer építése a tudomány számára – Jon Starr](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673) +- [Paul Kohlhaas – DeSci: a decentralizált tudomány jövője (podcast)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a) +- [Active Inference Ontology a decentralizált tudomány számára (a Situated Sensemaking-től az Epistemic Commons-ig)](https://zenodo.org/record/6320575) +- [DeSci: a kutatás jövője – Samuel Akinosho](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec) +- [A tudomány finanszírozása (Epilógus: a DeSci és az új kriptoalapok) – Nadia](https://nadia.xyz/science-funding) +- [A decentralizáció megbontja a gyógyszerfejlesztést](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f) +- [Mi az a DeSci, azaz a decentralizált tudomány?](​https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/) + +### Videók {#videos} + +- [Mi az a decentralizált tudomány?](https://www.youtube.com/watch?v=-DeMklVWNdA) +- [Beszélgetés Vitalik Buterin és a tudós Aubrey de Grey között a hosszútávú kutatás és a kripto találkozási pontjáról](https://www.youtube.com/watch?v=x9TSJK1widA) +- [A tudományos publikálás szét van szakítva. A web3 meg tudja vajon javítani?](https://www.youtube.com/watch?v=WkvzYgCvWj8) +- [Juan Benet – DeSci, független laboratóriumok és a nagy adat tudománya](https://www.youtube.com/watch?v=zkXM9H90g_E) +- [Sebastian Brunemeier – Hogyan tudja a DeSci átalakítani az orvosbiológiai kutatást és a kockázati tőkét](https://www.youtube.com/watch?v=qB4Tc3FcVbM) +- [Paige Donner - A nyitott tudomány eszközökkel való ellátása a web3 & a blokklánc révén](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s) diff --git a/public/content/translations/hu/08) Use cases 2/refi/index.md b/public/content/translations/hu/08) Use cases 2/refi/index.md new file mode 100644 index 00000000000..28319b4667d --- /dev/null +++ b/public/content/translations/hu/08) Use cases 2/refi/index.md @@ -0,0 +1,81 @@ +--- +title: Regeneratív pénzügyek (ReFi) +description: A regeneratív pénzügyek (ReFi) áttekintése és jelenlegi használata. +lang: hu +template: use-cases +emoji: ":recycle:" +sidebarDepth: 2 +image: /images/future_transparent.png +alt: "" +summaryPoint1: Egy alternatív gazdasági rendszer, mely regeneratív elvekre épül +summaryPoint2: Az Ethereum kiaknázása a globális koordinációs krízisek megoldására, mint amilyen a klímaváltozás is +summaryPoint3: Az ökológiailag hasznos eszközök drasztikus skálázási lehetősége, mint amilyen az igazolt karbonkredit is +--- + +## Mik azok a regeneratív pénzügyek (ReFi)? {#what-is-refi} + +**A regeneratív pénzügyek (ReFi)** olyan [blokkláncra](/glossary/#blockchain) épülő eszközök és eszmék összessége, melyek célja a regeneratív gazdaságok kialakítása a kitermelési vagy kizsákmányolási helyett. A kizsákmányoláson alapuló rendszerek végül felélik a rendelkezésre álló erőforrásokat és összeomlanak; a regeneratív mechanizmusok nélkül nem bírnak kellő rugalmassággal. A ReFi azon a feltételezésen alapszik, hogy a pénzügyi érték létrehozását el kell választani a bolygó és a közösségek erőforrásainak nem fenntartható kizsákmányolásától. + +Ehelyett a ReFi arra törekszik, hogy regeneratív ciklusok létrehozásával környezeti, közösségi és szociális problémákat oldjon meg. Ezek a rendszerek egyszerre teremtenek értéket a résztvevőknek, valamint az ökoszisztéma és a közösségek javait szolgálják. + +A ReFi egyik alapköve a regeneratív gazdaság koncepciója, amelyet John Fullerton fogalmazott meg a Capital Institute intézettől. Az ő javaslata [nyolc egymással összefüggő elv,](https://capitalinstitute.org/8-principles-regenerative-economy/) amelyet egy rendszerszintű egészségi állapot támaszt alá: + +![A nyolc összefüggő elv](refi-regenerative-economy-diagram.png) + +A ReFi projektek ezeket az elveket valósítják meg az [okosszerződések](/glossary/#smart-contract) és [a decentralizált pénzügyek (DeFi)](/glossary/#defi) alkalmazásainak segítségével, hogy ösztönözzék a regeneratív viselkedéseket, mint amilyen a lepusztult ökoszisztémák visszaállítása, illetve a nagy léptékű együttműködés elősegítése olyan globális problémák esetén, mint a klímaváltozás és a biodiverzitás-csökkenés. + +A ReFi egyúttal átfedésben van a [decentralizált tudomány (DeSci)](/desci/) mozgalommal, mely az Ethereumot használja platformként a tudományos ismeretek finanszírozása, létrehozása, értékelése, hitelesítése, tárolása és terjesztése céljából. A DeSci eszközök hasznosak lehetnek ahhoz, hogy a regeneratív tevékenységek (faültetés, a műanyagok összegyűjtése az óceánból, lepusztult ökoszisztémák visszaállítása) bevezetését és monitorozását igazolható szabványokkal és gyakorlatokkal támasszák alá. + + + +## A karbonkreditek tokenizálása {#tokenization-of-carbon-credits} + +Az **[önkéntes karbonpiac (VCM)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)** olyan projektek finanszírozási mechanizmusa, melyek igazolhatóan pozitív hatást gyakorolnak a szén-dioxid kibocsátásra, akár az aktuális kibocsátás csökkentésével vagy a más kibocsátott üvegházhatású gázok lekötésével. Ezek a projektek egy karbonkreditnek nevezett eszközt kapnak az igazolási eljárás után, melyet olyan egyéneknek és szervezeteknek adhatnak el, akik támogatni szeretnék a klímára ható intézkedéseket. + +Az önkéntes karbonpiac (VCM) mellett számos kormányzat által kötelezővé tett karbonpiac is létezik, hogy törvényekkel vagy szabályozásokkal egy adott joghatóságon belül (pl. ország vagy régió) bevezessenek egy olyan karbonárat, mellyel kontrollálnák a kiadott karbonkibocsátási engedélyeket. Ezek a kötelező karbonpiacok arra ösztönzik a kibocsátókat az adott joghatóságon belül, hogy csökkentsék kibocsátásukat, de a már kibocsátott üvegházhatású gázok lekötésére nincs ráhatásuk. + +Az elmúlt évtizedek fejlődése ellenére a VCM továbbra is számtalan problémával küzd: + +1. A likviditás, vagyis az elérhető pénzeszközök nagyon szétdaraboltak +2. A tranzakciók működése nem átlátható +3. Magas díjak +4. A kereskedési sebesség nagyon lassú +5. A skálázhatóság nem megoldott + +A VCM átvitele az új, blokkláncalapú **digitális karbonpiacra (DCM)** egy jó lehetőség arra, hogy továbbfejlesszük a karbonkreditek validálásának, adásvételének és felhasználásának meglévő technológiáját. A blokkláncok lehetővé teszik a nyilvánosan igazolható adatokat, hozzáférést biztosítanak a felhasználók széles körének és nagyobb likviditást tudnak adni. + +A ReFi-projektek blokklánc technológiát használnak arra, hogy a hagyományos piac problémáit enyhítsék: + +- **A likviditás néhány alapban koncentrálódik,** amelyekkel bárki szabadon kereskedhet. A nagy szervezetek és az egyéni felhasználók ugyanúgy hasznosíthatják ezeket az alapokat, és nem kell hozzá kereskedőt fogadniuk, részvételi díjat fizetniük vagy regisztrálniuk. +- **Az összes tranzakció nyilvános blokkláncokon kerül rögzítésre**. Minden egyes karbonkredit mozgása nyomon követhető onnantól kezdve, hogy a DCM-en elérhetővé válik. +- **A tranzakciósebesség szinte azonnali**. A hagyományos piacokon napokig vagy hetekig tartana nagyobb mennyiségű karbonkredit beszerzése, amit a DCM-en pillanatok alatt el lehet érni. +- **A kereskedés közvetítők nélkül zajlik**, akik nagy díjakat számolnának fel ezért. A digitális karbonkreditek jelentős költségcsökkentést jelentenek a hagyományos kreditekhez képest. +- **A DCM skálázható** és képes egyaránt kielégíteni az egyének és a multinacionális vállalatok igényeit. + +### A digitális karbonpiac (DCM) fő komponensei {#key-components-dcm} + +A DCM jelenlegi struktúrája négy fő elemből áll: + +1. Nyilvántartások, mint a [Verra](https://verra.org/project/vcs-program/registry-system/) és a [Gold Standard](https://www.goldstandard.org/), biztosítják, hogy a projektek karbonkreditjei hitelesek legyenek. Emellett üzemeltetik az adatbázist, melyben a digitális karbonkreditek létrejönnek, és ezek átadhatók és felhasználhatók. + +A blokkláncra épülő, innovatív projektek egy újabb hulláma próbálja megbontani, újraalkotni a szektor hivatalnoki funkcióit is. + +2. Karbonhidak, vagyis tokenizálók, akik a hagyományos nyilvántartásokban tárolt karbonkrediteket megjelenítik vagy áttranszferálják a DCM-re. Ismert példa többek között a [Toucan Protocol](https://toucan.earth/), a [C3](https://c3.app/) és a [Moss.Earth](https://moss.earth/). +3. Integrált szolgáltatások, melyek karbonelkerülési és/vagy -eltávolítási krediteket ajánlanak a végfelhasználóknak, így nyilvánvaló a környezetre gyakorolt jótékony hatásuk és megoszthatják a világgal azt, hogy támogatják a klímával kapcsolatos intézkedéseket. + +Néhányan, mint amilyen a [Klima Infinity](https://www.klimadao.finance/infinity) és a [Senken](https://senken.io/), a projektek széles választékát kínálják, melyeket harmadik fél készített és olyan szabványok mentén bocsátott ki, mint a Verra. Mások, mint amilyen a [Nori](https://nori.com/) is, csak specifikus projekteket fejlesztenek a saját karbonkredit-szabványuk alapján, melyet ők bocsátanak ki és saját, erre specializált piacterükön kezelik. + +4. Infrastruktúra, amely lehetővé teszi a karbonpiac teljes ellátási láncának skálázhatóságát hatás és hatékonyság szempontjából. A [KlimaDAO](http://klimadao.finance/) likviditást biztosít közjó gyanánt (bárki vehet vagy adhat karbonkreditet transzparens áron), ösztönzi a karbonpiacok tranzakcióátvitelének növekedését és a karbonkreditek felhasználását, továbbá felhasználóbarát és interoperábilis eszközrendszert biztosít, hogy a tokenizált karbonkreditek széles választékáról elérhetők legyenek az adatok, illetve beszerzi és felhasználja azokat. + +## ReFi a karbonpiacokon túl {#refi-beyond} + +Bár jelenleg nagy hangsúlyt a karbonpiacokra általánosságban, valamint a VCM transzferálásáról a DCM-re, ugyanakkor a regeneratív pénzügyek (ReFi) nem korlátozódnak erre a területre. Más környezeti eszközöket is létre lehet hozni és tokenizálni, hogy újabb negatív externáliákat is be lehessen árazni a jövő gazdasági rendszerének részeként. Emellett e gazdasági modell regeneratív aspektusát fel lehet használni más területeken is, mint a közjavak finanszírozása kvadratikus finanszírozási platformokon, amilyen a [Gitcoin](https://gitcoin.co/) is. Azok a szervezetek, melyek a nyitott részvétel és az erőforrások egyenlő elosztásának eszméjére épültek, lehetővé teszik, hogy az emberek nyílt forráskódú szoftverprojekteknek, valamint oktatási, környezeti és közösség által irányított projekteknek juttassanak pénzt. + +Azzal, hogy a tőkét átirányítják a kizsákmányoló gyakorlatokból a regeneratív kezdeményezésekbe, elindulhatnak olyan projektek és cégek, melyek szociális, környezeti és közösségi előnyöket adnak – és valószínűleg a hagyományos pénzügyi rendszerben nem jutnának pénzhez –, így gyorsan és könnyedén pozitív externáliákat hozhatnak létre a társadalom számára. A finanszírozás ezen modelljére való átállás lehetőséget ad a sokkal befogadóbb gazdasági rendszerek számára, melyekben mindenféle demográfiai jellemzővel bíró ember aktív résztvevő lehet, nem csak passzív szemlélő. A ReFi az Ethereum vízióját kínálja arra vonatkozólag, hogy miként lehet összehangoltan cselekedni a lét kihívásait illetően, mely az emberi fajt és a bolygó minden élőlényét érinti – egy új gazdasági paradigma alaprétege, mely befogadóbb és fenntarthatóbb jövőt teremt. + +## További cikkek a ReFi-ról + +- [A karbonvaluták áttekintése és helyük a gazdaságban](https://www.klimadao.finance/blog/the-vision-of-a-carbon-currency) +- [A Jövő Minisztériuma, egy regény a karbonalapú valuta szerepéről a klímaváltozás elleni harcban](https://en.wikipedia.org/wiki/The_Ministry_for_the_Future) +- [Részletes jelentés az önkéntes karbonpiacok skálázását megcélzó munkacsoporttól (TSVCM)](https://www.iif.com/Portals/1/Files/TSVCM_Report.pdf) +- [Kevin Owocki és Evan Miyazono CoinMarketCap glosszáriumbejegyzése a ReFi-ről](https://coinmarketcap.com/alexandria/glossary/regenerative-finance-refi) diff --git a/public/content/translations/hu/08) Use cases 2/social-networks/index.md b/public/content/translations/hu/08) Use cases 2/social-networks/index.md new file mode 100644 index 00000000000..67fa29ce2f2 --- /dev/null +++ b/public/content/translations/hu/08) Use cases 2/social-networks/index.md @@ -0,0 +1,106 @@ +--- +title: Nem központosított közösségi hálózatok +description: A decentralizált közösségi hálózatok áttekintése az Ethereumon +lang: hu +template: use-cases +emoji: ":mega:" +sidebarDepth: 2 +image: /images/ethereum-learn.png +summaryPoint1: Blokkláncalapú platformok a közösségi kapcsolódás, tartalom-létrehozás és -terjesztés céljából. +summaryPoint2: A decentralizált közösségimédia-hálózatok megvédik a felhasználók privát adatait és növelik az adatbiztonságot. +summaryPoint3: A tokenek és NFT-k új lehetősége adnak a tartalom fizetőeszközzé alakításához. +--- + +A közösségi hálózatok komoly szerepet töltenek be a napi kommunikációban és kapcsolódásban. Ugyanakkor ezen platformok centralizált irányítása számos problémát teremtett: adatlopás, szerverleállás, kizárás a platformról, cenzúra és a magán jelleg megsértése csak néhány kompromisszum, amit a közösségi média gyakran elszenved. E problémák megoldása érdekében a fejlesztők az Ethereumon építenek közösségi hálózatokat. A decentralizált közösségi hálózatok a hagyományos platformok számtalan problémájára megoldást nyújtanak, ás javítják a felhasználói élményt is. + +## Mik azok a decentralizált közösségi hálózatok? {#what-are-decentralized-social-networks} + +A decentralizált közösségi hálózatok olyan [blokkláncalapú](/glossary/#blockchain) platformok, melyeken a felhasználók kommunikálnak egymással, illetve tartalmat publikálnak és terjesztenek. Mivel ezek az alkalmazások a blokkláncon működnek, ezért képesek decentralizáltan üzemelni, ellenállnak a cenzúrának és a jogtalan kontrollnak. + +Számos decentralizált közösségi hálózat létezik az olyan közösségimédia-szolgáltatások alternatívájaként, mint a Facebook, LinkedIn, Twitter és Medium. Ugyanakkor a blokkláncon működtetett közösségi hálózatok olyan jellemzőkkel is bírnak, melyek a hagyományos platformok fölé helyezik őket. + + + +### Hogyan működnek a decentralizált közösségi hálózatok? {#decentralized-social-networks-overview} + +A decentralizált közösségi hálózatok valójában [decentralizált alkalmazások (dapp)](/dapps/), melyeket a blokkláncon létrehozott [okosszerződések](/glossary/#smart-contract) működtetnek. A szerződés programkódja adja ezen alkalmazások hátterét és meghatározza azok üzleti logikáját. + +A hagyományos közösségimédia-platformok adatbázisokon alapulnak, melyek tárolják a felhasználói információkat, a programkódot és egyéb adatokat. Ez azonban bármilyen leállás esetén egy sebezhető pontot jelent és komoly kockázatot hordoz magában. Tavaly például a Facebook szerverei [órákra leálltak](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact), és elvágták a felhasználókat a platformtól. + +A decentralizált közösségi hálózatok egy [peer-to-peer (P2P) hálózaton](/glossary/#peer-to-peer-network) működnek, mely ezernyi csomópontot (node) tartalmaz szerte az egész világon. Ha néhány csomópont le is áll, a hálózat zavartalanul működik tovább, így az alkalmazásokat nem érintik a leállások és kimaradások. + +A decentralizált tárhelyek használatával, mint amilyen az [InterPlanetary File System (IPFS)](https://ipfs.io/), az Ethereumra épített decentralizált közösségi hálózatok képesek megvédeni a felhasználók adatait azok kihasználása és rosszindulatú felhasználása ellen. Senki sem tudja eladni a felhasználók személyes adatait a reklámcégeknek, és a hackerek sem tudják ellopni a bizalmas információkat. + +Számos blokkláncalapú közösségi platform rendelkezik saját tokenekkel, hogy a reklámbevétel helyett ezzel biztosítsa a pénzforrások létrehozását. A felhasználók megvehetik ezeket a tokeneket, hogy bizonyos funkciókat használhassanak, vásárolhassanak az alkalmazáson belül, vagy akár ezzel díjazzák a kedvenc tartalomkészítőiket. + +## A decentralizált közösségi hálózatok előnyei {#benefits} + +1. A decentralizált közösségi hálózatok ellenállnak a cenzúrának és bárki számára elérhetők. Tehát a **felhasználókat nem lehet letiltani**, kizárni a platformról vagy önkényesen korlátozni. + +2. A decentralizált közösségi hálózatok **nyílt forráskódú elképzelésekre** épülnek, az alkalmazások programkódját bárki megvizsgálhatja. A hagyományos közösségi médiára jellemző, nem átlátható algoritmusokat kizárva a blokkláncalapú közösségi hálózatok képesek összehangolni a felhasználók igényeit és a platform működtetőit. + +3. A decentralizált közösségi hálózatokban nincs szükség közvetítőre. **A tartalomkészítők közvetlen tulajdonjoggal bírnak a tartalom felett**, és közvetlenül kapcsolódnak a követőkkel, rajongókkal, vevőkkel és más résztvevőkkel, csupán egy okosszerződés van közöttük. + +4. Mivel a decentralizált alkalmazások (dapp) az Ethereum hálózatán működnek, melyet a csomópontok egy globális, peer-to-peer hálózata tart fenn, így a decentralizált közösségi hálózatok **kevésbé vannak kitéve a szerverleállásnak** vagy bármilyen kiesésnek. + +5. A decentralizált közösségi platformok egy **fejlett bevételszerzési** keretrendszert kínálnak a tartalomkészítőknek a [nem helyettesíthető tokenek (NFT)](/glossary/#nft), az alkalmazáson belüli kriptofizetés és más eszközök révén. + +6. A decentralizált közösségi hálózatok **magas fokú adatbiztonságot és anonimitást** kínálnak a felhasználóknak. Például egy személy bejelentkezhet az Ethereumon alapuló közösségi hálózatra az [ENS](/glossary/#ens)-profilja vagy a [tárcája](/glossary/#wallet) révén – anélkül, hogy bármilyen személyazonosításra alkalmas információt (PII) megosztana, mint a neve, e-mail-címe stb. + +7. A decentralizált közösségi hálózatok decentralizált adattároláson alapulnak, nem centralizált adatbázisokon, így jobban meg tudják védeni a felhasználók adatait. + +## A decentralizált közösségi hálózatok az Ethereumon {#ethereum-social-networks} + +Az Ethereum-hálózat lett a decentralizált közösségi média fejlesztőinek kedvelt helye, mivel népszerű tokenekkel és masszív felhasználói bázissal rendelkezik. Néhány Ethereumon alapuló közösségi hálózat: + +### Mirror {#mirror} + +A [Mirror](https://mirror.xyz/) egy web3-alapú, decentralizált és a felhasználók által üzemeltetett íróplatform. A felhasználók ingyen olvashatnak és írhatnak azáltal, hogy a saját tárcáikkal kapcsolódnak. Emellett gyűjthetnek írásokat és feliratkozhatnak a kedvenc íróikra is. + +Az itt publikált írások állandóan elérhetők az Arweave révén, ami egy decentralizált tárhely, és gyűjthető [NFT (nem helyettesíthető token)](/nft/) készíthető belőlük, más néven szöveg NFT. A szöveg NFT-t az írók teljesen ingyen hozhatják létre, a gyűjtés pedig az Ethereumra épülő [második blokkláncrétegen (L2)](/glossary/#layer-2) történik, így a tranzakciók olcsók, gyorsak és környezetbarátak. + +### MINDS {#minds} + +A [MINDS](https://www.minds.com/) az egyik legnépszerűbb decentralizált közösségi hálózat. A Facebookhoz hasonlóan működik, és milliónyi felhasználója van. + +A felhasználók a platform saját [ERC-20](/glossary/#erc-20) tokenjével $MIND fizetnek a dolgokért. A felhasználók szerezhetnek azáltal is $MIND tokent, hogy népszerű tartalmat publikálnak, hozzájárulnak az ökoszisztémához és ajánlják a platformot másoknak. + +## A decentralizált közösségi hálózatok használata {#use-decentralized-social-networks} + +- **[Status.im](https://status.im/)** – _A Status egy biztonságos üzenetküldő alkalmazás, mely nyílt forráskódú, peer-to-peer protokollt használ, és elejétől a végéig titkosítva van, hogy megvédje az üzeneteket._ +- **[Mirror.xyz](https://mirror.xyz/)** – _A Mirror egy decentralizált, felhasználók által működtetett publikáló platform az Ethereumon, hogy a felhasználók finanszírozást gyűjtsenek az ötleteiknek, bevételt kapjanak a tartalom után és értékes közösségeket építsenek._ +- **[Lens Protocol](https://lens.xyz/)** – _A Lens Protocol egy decentralizált közösségi gráf, ahol a tartalomkészítők tulajdonolják az általuk létrehozott tartalmat a decentralizált internet teljes hosszában._ +- **[Farcaster](https://farcaster.xyz/)** – _A Farcaster egy kellően decentralizált közösségi hálózat. Egy nyitott protokoll, amely több klienst is támogat, mint például az e-mail-funkció._ + +## Web2 közösségi hálózatok az Ethereumon {#web2-social-networks-and-ethereum} + +Nem csak a [web3](/glossary/#web3) közösségi platformok használják a blokklánc-technológiát a közösségi médiához. Számos centralizált platform is integrálni szeretné az Ethereumot a saját infrastruktúrájába: + +### Reddit {#reddit} + +A Reddit [közösségi pontokat](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users) hirdetett meg, amelyek olyan ERC-20 tokenek, amelyeket a felhasználók minőségi tartalmak közzétételével és az online közösségekhez (subredditekhez) való hozzájárulással szerezhetnek. Ezeket a tokeneket a felhasználó egy subreddit fórumon belül be tudja váltani, hogy különleges jogokat vagy bevételt szerezzen. A Reddit az Arbitrummal működik együtt, amely egy [második blokkláncréteg (L2)](/glossary/#layer-2) megoldás az Ethereum-tranzakciók skálázására. + +A program már elérhető, az r/CryptoCurrency subreddit [a „Moons”-nak nevezett közösségi pontokkal üzemel](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki). A hivatalos leírás szerint a Moons „a posztok készítőit, kommentálóit és a moderátorokat díjazza a subreddithez való hozzájárulásukért”. Mivel ezek a tokenek a blokkláncon vannak (a felhasználók tárcákba kapják azokat), ezért függetlenek a Reddittől, és nem lehet azokat elvenni. + +A felhasználók nemcsak különleges funkciókra használhatják pontjaikat, hanem eladhatják azokat hagyományos valutáért is a tőzsdéken. Emellett az adott felhasználó közösségi pontjainak összege meghatározza, hogy a közösségen belül milyen mértékben vehetnek részt a döntésekben. + +## További olvasnivaló {#further-reading} + +### Cikkek {#articles} + +- [A decentralizált közösségi média: útmutató a web3 közösségi alkalmazásokhoz](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) - _Coinbase Ventures_ +- [A közösségi hálózatok világa a következő nagy decentralizálási lehetőség](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) — _Ben Goertzel_ +- [A web3 megtartja ígéretét a decentralizált, közösség által működtetett közösségi hálózatokról](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Sumit Ghosh_ +- [A blokklánc közösségi média alkalmazásainak áttekintése](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — _Gemini Cryptopedia_ +- [Hogyan tudja a blokklánc megoldani a közösségi médiához kapcsolódó adatvédelmet](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Prableen Bajpai_ +- [Elégséges decentralizáció a közösségi hálózatok számára](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Varun Srinivasan_ + +### Videók {#videos} + +- [A decentralizált közösségi média bemutatása](https://www.youtube.com/watch?v=UdT2lpcGvcQ) — _Coinmarketcap_ +- [DeSo a blokklánc decentralizálja a közösségi médiát](https://www.youtube.com/watch?v=SG2HUiVp0rE) — _Bloomberg Technology_ +- [A decentralizált közösségi média jövője – Balaji Srinivasan, Vitalik Buterin, Juan Benet](https://www.youtube.com/watch?v=DTxE9KV3YrE) — _ETHGlobal_ + +### Közösségek {#communities} + +- [r/CryptoCurrency subreddit](https://www.reddit.com/r/CryptoCurrency/) diff --git a/public/content/translations/hu/09) Learn Pages/bridges/index.md b/public/content/translations/hu/09) Learn Pages/bridges/index.md new file mode 100644 index 00000000000..4882abb8401 --- /dev/null +++ b/public/content/translations/hu/09) Learn Pages/bridges/index.md @@ -0,0 +1,137 @@ +--- +title: Bevezetés a blokklánchidak működésébe +description: A hidak segítségével a felhasználók különböző blokkláncok között tudnak eszközöket mozgatni +lang: hu +--- + +# Blokkláncösszekötők {#prerequisites} + +_A Web3 egy olyan ökoszisztémává fejlődött, ahol L1 blokkláncok és L2 skálázási megoldások találhatók, mind egyedi képességekkel és kompromisszumokkal. Ahogy növekszik a blokkláncprotokollok száma, úgy nő a kereslet is, hogy az eszközöket láncok között lehessen mozgatni. Az igény kielégítéséhez összekötőkre vagy hidakra van szükségünk._ + + + +## Mik azok az összekötők vagy hidak? {#what-are-bridges} + +A blokklánchidak épp olyanok, mint a fizikai világban. A fizikai híd két helyet köt össze, a blokklánchíd két blokklánc-ökoszisztémát. **A hidak kommunikációs lehetőséget teremtenek a blokkláncok között az információk és eszközök transzferálásával**. + +Vegyünk egy példát: + +Ön az Amerikai Egyesült Államokból való és Európába utazik. Amerikai dollárral (USD) rendelkezik, de az utazáson euróra (EUR) van szüksége. Az átváltáshoz használhat egy valutaváltót egy kis díj ellenében. + +De mit csináljunk, ha egy ilyen átváltást két különböző [blokkláncon](/glossary/#blockchain) akarunk véghezvinni? Tegyük fel, hogy Ön az Ethereum-főhálózatán lévő [ETH-t](/glossary/#ether) akarja váltani az  [Arbitrumon](https://arbitrum.io/) lévő ETH-re. Ahogy a fenti példában EUR-t váltottunk, szükség van egy olyan mechanizmusra, mely az ETH összegünket átviszi az Ethereumról az Arbitrumra. A hidak teszik lehetővé az ilyen tranzakciókat. Ebben az esetben az [Arbitrum rendelkezik egy saját híddal](https://bridge.arbitrum.io/), ami átviszi az ETH-t a főhálózatról az Arbitrumra. + +## Miért van szükség hidakra? {#why-do-we-need-bridges} + +Minden blokkláncnak megvannak a maga korlátai. Az Ethereum skálázásához és hogy ki bírja szolgálni a keresletet, [tranzakcióösszegzőkre (rollup)](/glossary/#rollups) van szüksége. Más L1 blokkláncok, mint a Solana és az Avalanche, másképpen vannak összerakva, így magasabb tranzakcióátvitelt bírnak, de a decentralizációt áldozzák fel cserébe. + +Ugyanakkor minden blokkláncot elkülönült környezetben fejlesztenek, más szabályok és más [konszenzusmechanizmus](/glossary/#consensus) alapján. Emiatt maguktól nem tudnak egymással kommunikálni, a tokeneket pedig nem lehet szabadon átvinni az egyikről a másikra. + +A hidak kötik össze a blokkláncokat, lehetővé téve az információ és a tokenek áramlását közöttük. + +**A hidak lehetővé teszik**: + +- az eszközök és az információk a láncok között mozogjanak. +- a [decentralizált alkalmazások (dapp)](/glossary/#dapp) hozzáférjenek a különféle blokkláncok erősségeihez – így azok képességeit fejleszteni tudják (mivel a protokollok esetében manapság több tér van az innovációra). +- a felhasználók új platformokat érjenek el és hasznosítsák a különböző láncok előnyeit. +- a fejlesztők a különböző blokklánc-ökoszisztémákon együttműködjenek és új platformokat építsenek a felhasználók számára. + +[Hogyan lehet áthelyezni a tokeneket a második blokkláncrétegbe (L2)](/guides/how-to-use-a-bridge/) + + + +## A hidak alkalmazási területei {#bridge-use-cases} + +A következő szcenáriók esetében lehet hidat használni: + +### Alacsonyabb tranzakciós költségek {#transaction-fees} + +Tegyük fel, hogy Ön rendelkezik ETH-szel az Ethereum főhálózatán, de olcsóbb tranzakciós díjat szeretne, hogy különféle alkalmazásokat tudjon használni. Ha a főhálózatról az ETH-t áthelyezi egy L2 rollupmegoldásra, akkor alacsonyabb díjakat élvezhet. + +### Decentralizált alkalmazások (dapp) más blokkláncokon {#dapps-other-chains} + +Tegyük fel, hogy Ön az Aave alkalmazást használja az Ethereum főhálózatán arra, hogy USDT-t kölcsönözzön, de a Polygonon ugyanez az alkalmazás magasabb kamatot ad. + +### A blokklánc-ökoszisztémák felfedezése {#explore-ecosystems} + +Ha Ön ETH összeggel rendelkezik az Ethereum-főhálózaton, de fel szeretne fedezni egy alternatív L1 hálózatot, hogy kipróbálja annak alkalmazásait. A hídon keresztül átviheti az ETH-t a kiválasztott L1-re. + +### Saját kriptoeszközök {#own-native} + +Amennyiben Ön szeretne bitcoint (BTC) birtokolni, de a pénzeszközei az Ethereum főhálózatán vannak. Az Ethereumon becsomagolt formában szerezhet bitcoint (WBTC). Ugyanakkor a WBTC egy [ERC-20](/glossary/#erc-20) token az Ethereum hálózatán, tehát egy Ethereum verziójú bitcoin, és nem az eredeti eszköz a Bitcoin-blokkláncon. Az eredeti BTC megszerzéséhez egy hídon keresztül át kell vinnie a pénzeszközeit a Bitcoin hálózatára. Ezzel áthelyezi a WBTC-t és átváltja BTC-re. Másik irányból, ha Ön rendelkezik BTC-vel, de azt az Ethereum [decentralizált pénzügyi (DeFi)](/glossary/#defi) protokolljában akarja használni. Ekkor a hídon a másik irányba mozgatja az eszközeit, BTC-ről WBTC-re váltja, majd azt áthelyezi az Ethereumra. + + + Mindezt megteheti egy centralizált tőzsde segítségével is. Ha azonban az eszközei már a tőzsdén vannak, akkor több lépést kell végrehajtani, és akkor már egyszerűbb a hidat használni. + + + + +## A hidak típusai {#types-of-bridge} + +A hidak többféle kialakításúak és összetettségűek. Általánosságban kétféle lehet: bizalmat igénylő és bizalomigénytől mentes. + +| Bizalmat igénylő (trusted) hidak | Bizalomigénytől mentes (trustless) hidak | +| ------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | +| A bizalmat igénylő hidak működése egy központi entitáson vagy rendszeren múlik. | A bizalomigénytől mentes hidak működését okosszerződések és algoritmusok vezérlik. | +| A pénzeszközök felügyelete és a híd biztonsága terén bizalmi feltételezések vannak. A felhasználó a híd működtetőjének reputációjára támaszkodik. | A bizalommentessége azt jelenti, hogy a híd biztonsága megegyezik a mögötte álló blokkláncéval. | +| A felhasználónak át kell engednie a kriptoeszközök feletti kontrollját. | Az [okosszerződések](/glossary/#smart-contract) révén a felhasználók kontrollja alatt maradnak az eszközök. | + +Röviden, a bizalmat igénylő hidaknál bizalmi feltételezésekkel kell élnünk, míg a bizalomigénytől mentes hidaknál ez minimális és nem merül fel más, mint a mögöttes blokklánc kapcsán. Ezeket a kifejezéseket a következőképpen kell érteni: + +- **Bizalomigénytől mentes (trustless)**: a mögötte található rendszerrel megegyező biztonsági szintje van. Olvassa el [Arjun Bhuptani erről szóló cikkét.](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17) +- **Bizalmat igénylő (trusted)**: a mögöttes rendszer biztonságától eltávolodik azzal, hogy külső igazolókat von be a rendszerbe, így kriptogazdasági szempontból kevésbé biztonságos. + +A két megkülönböztetés fő különbségeinek jobb megértése érdekben vegyünk egy példát: + +Tegyük fel, hogy Ön a reptéren a check-in előtt áll. Kétféle ellenőrzés van: + +1. Manuális chek-in – ahol a hivatalnokok manuálisan ellenőrzik a jegyét és a személyazonosságát, mielőtt a belépőkártyát átadnák. +2. Self check-In – ahol egy gép ellenőrzi ezeket és adja ki a belépőkártyát, ha mindent rendben talál. + +A manuális ellenőrzés hasonló a bizalmat igénylő modellhez, mert egy harmadik félen múlik a működése, például a hivatalnokokon. Felhasználóként abban bízunk, hogy a hivatalnokok a megfelelő döntést hozzák és helyesen kezelik a privát információkat. + +A self check-in hasonlít a bizalomigénytől mentes modellhez, mivel kiveszi az operátor szerepét, és a technológia működteti. A felhasználónak mindvégig megmarad a kontroll az adatai felett, és nem kell azokat egy harmadik félre bíznia. + +Számos hidat biztosító megoldás e két modell közötti módszert alakít ki változó bizalmi fokozattal. + + + +## Híd használata {#use-bridge} + +A hidak segítségével a felhasználók különböző blokkláncok között tudnak eszközöket mozgatni. Íme néhány forrás, amelyek hasznosak lehetnek a hidak megtalálásához és használatához: + +- **[L2BEAT hidakról szóló összefoglaló](https://l2beat.com/bridges/summary) & [L2BEAT hidak kockázati elemzése](https://l2beat.com/bridges/risk)**: Egy átfogó tanulmány a különféle hidakról, beleértve azok piaci részesedését, típusát és azokat a blokkláncokat, melyekkel összeköttetést biztosítanak. Az L2BEAT kockázati elemzést is készített a hidakról, hogy a felhasználók megfelelően tudjanak választani azok közül. +- **[DefiLlama hidakról szóló összefoglaló](https://defillama.com/bridges/Ethereum)**: Az Ethereum hálózatok közötti hidak forgalmi adatainak összefoglalója. + + + +## A hidak használatának kockázata {#bridge-risk} + +A hidak fejlesztése még a korai stádiumban van. Nagy valószínűséggel az optimális kialakítás még nem született meg. A hidakkal való interakció a következő kockázatokkal jár: + +- **Okosszerződéses kockázat —** a programkódban lévő hiba miatt a felhasználó pénzeszközei elveszhetnek +- **Technológiai kockázat —** szoftverhiba, hibás kód, emberi hiba, spam és rosszindulatú támadás valószínűleg megakaszthatja a működést + +Emellett, mivel a bizalmat igénylő (trusted) hidak még több bizalmi feltételt jelentenek, ezért több kockázatot is hordoznak magukban: + +- **Cenzúra kockázata —** a hidak működtetői elméletileg meg tudják akadályozni a felhasználót az eszközeinek áthelyezésében +- **Felügyeleti kockázat —** a hidak működtetői összefoghatnak abban, hogy ellopják a felhasználók eszközeit + +A felhasználó eszközei veszélyben vannak, ha: + +- hiba van az okosszerződésben +- a felhasználó hibázik +- a mögöttes blokkláncot megtámadják +- a híd kezelői a bizalmat igénylő (trusted) hidak esetében rosszhiszeműek +- a hidat megtámadják + +Az egyik korábbi, Solana Wormhole híd elleni támadásnál [ 120k wETH-t (325 millió USD) lopott el a támadó](https://rekt.news/wormhole-rekt/). A [blokkláncok elleni legnagyobb támadások hidakat is érintenek](https://rekt.news/leaderboard/). + +A hidak elengedhetetlenek az Ethereum L2 használatához, illetve ha a felhasználók más ökoszisztémákat is fel szeretnének fedezni. Ugyanakkor az ebben rejlő kockázatok miatt meg kell érteni a hidak által hozott kompromisszumokat. Íme néhány [stratégia a láncok közötti biztonság](https://blog.debridge.finance/10-strategies-for-cross-chain-security-8ed5f5879946) témájában. + + + +## További olvasnivaló {#further-reading} + +- [EIP-5164: Láncok közötti műveletek végrehajtása](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658) _2022. június 18. – Brendan Asselstine_ +- [L2 hidak kockázati keretrendszere](https://gov.l2beat.com/t/l2bridge-risk-framework/31) _2022. július 5. – Bartek Kiepuszewski_ +- [A jövő miért inkább többláncú, mint láncok közötti](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) _2022. január 8. – Vitalik Buterin_ diff --git a/public/content/translations/hu/09) Learn Pages/energy-consumption/index.md b/public/content/translations/hu/09) Learn Pages/energy-consumption/index.md new file mode 100644 index 00000000000..133be2fd013 --- /dev/null +++ b/public/content/translations/hu/09) Learn Pages/energy-consumption/index.md @@ -0,0 +1,82 @@ +--- +title: Az Ethereum energiafogyasztása +description: Alapvető információk az Ethereum energiafogyasztásának megértéséhez. +lang: hu +--- + +# Az Ethereum energiafogyasztása {#proof-of-stake-energy} + +Az Ethereum egy környezetbarát blokklánc. Az Ethereum [proof-of-stake](/developers/docs/consensus-mechanisms/pos) konszenzus mechanizmusa ETH-t használ [az energia helyett, hogy biztosítsa a hálózatot](/developers/docs/consensus-mechanisms/pow). Az Ethereum energiafogyasztása [~0,0026 TWh/év](https://carbon-ratings.com/eth-report-2022) a teljes globális hálózaton. + +Az Ethereum energiafogyasztásának becsült adata egy [CCRI (Crypto Carbon Ratings Institute)](https://carbon-ratings.com) tanulmányból származik. Ez egy lentről felfelé építkező becslés az Ethereum-hálózat áramfogyasztásáról és karbonlábnyomáról ([nézze meg a reportot](https://carbon-ratings.com/eth-report-2022)). A különféle csomópontok áramfogyasztását mérték, melyek különböző hardverekkel és kliensszoftverekkel működnek. A becsült **2601 MWh** (0,0026 TWh), mint a hálózat teljes éves áramfogyasztása, megfelel **870 tonna CO2e** szén-dioxid kibocsátásnak, regionális tényezőket figyelembe véve. Ez az érték változik, ahogy a csomópontok belépnek a hálózatra és kilépnek a hálózatról – Ön is ellenőrizheti egy gördülő 7 napos átlagbecsléssel: [Cambridge-blokklánchálózat fenntarthatósági indexe](https://ccaf.io/cbnsi/ethereum) (a módszer kicsit más, nézze meg a részleteket az oldalukon). + +Az Ethereum energiafogyasztását összevethetjük más termékek és iparágak éves becsléseivel, hogy kontextusban lássuk azt. Így jobban megértjük, hogy Ethereum fogyasztása magas vagy alacsony. + + + +Az ábra az Ethereum becsült fogyasztását mutatja TWh/év formájában, más termékekkel és iparágakkal összevetve. A becslések nyilvános adatokból származnak 2023. júliusából, a forrásokat megtalálja a táblázat alatt. + +| | Éves energiafogyasztás (TWh) | Összevetve a PoS Ethereummal | Forrás | +|:--------------------------- |:----------------------------:|:----------------------------:|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| +| Globális adatközpontok | 190 | 73 000x | [forrás](https://www.iea.org/commentaries/data-centres-and-energy-from-global-headlines-to-local-headaches) | +| Bitcoin | 149 | 53 000x | [forrás](https://ccaf.io/cbnsi/cbeci/comparisons) | +| Aranybányászat | 131 | 50 000x | [forrás](https://ccaf.io/cbnsi/cbeci/comparisons) | +| Számítógépes játékok (USA)* | 34 | 13 000x | [forrás](https://www.researchgate.net/publication/336909520_Toward_Greener_Gaming_Estimating_National_Energy_Use_and_Energy_Efficiency_Potential) | +| PoW Ethereum | 21 | 8100x | [forrás](https://ccaf.io/cbnsi/ethereum/1) | +| Google | 19 | 7300x | [forrás](https://www.gstatic.com/gumdrop/sustainability/google-2022-environmental-report.pdf) | +| Netflix | 0,457 | 176x | [forrás](https://assets.ctfassets.net/4cd45et68cgf/7B2bKCqkXDfHLadrjrNWD8/e44583e5b288bdf61e8bf3d7f8562884/2021_US_EN_Netflix_EnvironmentalSocialGovernanceReport-2021_Final.pdf) | +| PayPal | 0,26 | 100x | [forrás](https://s202.q4cdn.com/805890769/files/doc_downloads/global-impact/CDP_Climate_Change_PayPal-(1).pdf) | +| AirBnB | 0,02 | 8x | [forrás](https://s26.q4cdn.com/656283129/files/doc_downloads/governance_doc_updated/Airbnb-ESG-Factsheet-(Final).pdf) | +| **PoS Ethereum** | **0,0026** | **1x** | [forrás](https://carbon-ratings.com/eth-report-2022) | + +\*Beleértve a felhasználói eszközök fogyasztását, mint asztali számítógépek, laptopok és játékkonzolok. + +Bonyolult pontos becsléseket készíteni az energiafogyasztásról, főleg ha a vizsgált entitás összetett ellátási lánccal bír, ami befolyásolja a hatékonyságát. A Netflix és a Google esetében például a fogyasztás becslése attól függően változik, hogy a rendszer fenntartását és a tartalomnak a felhasználóhoz való eljutását nézik (_közvetlen fogyasztás_), vagy beleveszik azt is, amit a tartalom előállítása, irodák fenntartása, reklámozás stb. jelent (_közvetett fogyasztás_). A közvetett fogyasztásba az is beleszámíthat, hogy mennyi energiát vesz igénybe elfogyasztani a kínált tartalma a felhasználó oldalán, a tévék, számítógépek és mobilok használata során. + +A fenti becslések nem tökéletes összehasonlítások. A közvetett fogyasztás mennyisége, amivel számolnak, különbözik a források szerint és ritkán tartalmazza a felhasználók eszközeit is. Minden mögöttes információforrás több részletet közöl arról, hogy pontosan mit mérnek. + +Az összehasonlítás a Bitcoint és a proof-of-work Ethereumot feltünteti. Fontos megérteni, hogy a proof-of-work hálózatok fogyasztása nem statikus, és napról napra változik. A becslések nagy mértékben eltérhetnek a források szerint is. A téma árnyalt [vitát](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/) generál, nemcsak a felhasznált energia mennyiségéről, hanem annak forrásáról és etikájáról is. Az energiafogyasztás nem feltétlenül pontosan kapcsolódik a környezeti hatásokhoz, mert különböző projektek különféle energiaforrásokat használnak, beleértve a kisebb vagy nagyobb arányú megújuló forrásokat is. Például a [Cambridge Bitcoin elektromosáram-fogyasztási index](https://ccaf.io/cbnsi/cbeci/comparisons) azt mutatja, hogy a Bitcoin hálózati igénye elméletileg kielégíthető lenne abból a gázból vagy áramból, ami a szállítás során amúgy is elveszne. Az Ethereum a fenntarthatóság miatt cserélte le a rendszer energiaéhes részét egy környezetbarát alternatívára. + +Számtalan iparág energiafogyasztását és szén-dioxid-kibocsátását megtekintheti a [Cambridge-blokklánchálózat fenntarthatósági index oldalán](https://ccaf.io/cbnsi/ethereum). + +## Tranzakciónkénti becslés {#per-transaction-estimates} + +Számos cikk tranzakciónkénti becslésről beszél a blokkláncok esetén. Ez félrevezető, mert a blokkjavaslat és validálás független a benne található tranzakciók számától. A tranzakciónkénti felhasználás azt jelentené, hogy kevesebb tranzakció kevesebb energiát fogyaszt és fordítva, de ez nem igaz. Emellett a tranzakciónkénti becslés érzékeny arra, hogy a blokklánc tranzakcióátvitelét hogyan definiálják, amelynek megcsavarásával látszólag nagyobb vagy kisebb érték jön ki. + +Az Ethereumon például a tranzakcióátvitel nemcsak az alapréteget tartalmazza, hanem a [második blokkláncréteg (L2)](/layer-2/) összevont tranzakcióit is. Az L2 általában nincs benne a kalkulációkban, de ha hozzávennénk a szekvenszer általi fogyasztást (kevés) és a kezelt tranzakciókat (sok), akkor jelentősen lecsökkenne a tranzakciónkénti becslés. Ez az egyik oka annak, hogy a platformok tranzakciónkénti energiafogyasztásának összehasonlítása félrevezető lehet. + +## Az Ethereum karbonadóssága {#carbon-debt} + +Az Ethereum energiafelhasználása igen alacsony, de nem mindig volt így. Az Ethereum eredetileg a proof-of-work mechanizmust használta, ami nagyobb környezeti költségekkel járt, mint a jelenlegi proof-of-stake. + +Az Ethereum eleve a proof-of-stake-alapú konszenzusmechanizmust tervezte, anélkül hogy feláldozná a biztonságot vagy a decentralizáltságot, ezért többéves fókuszált kutatás és fejlesztés kellett hozzá. Emiatt a hálózat felállításához a proof-of-work mechanizmusra volt szükség. Ennél a bányászok a számítógépeiket használják az érték kiszámolására, energiát fogyasztva eközben. + +![Az Ethereum energiafogyasztásának összehasonlítása a Beolvadás előtt és után, ahol az Eiffel torony (330 méter magas) a bal oldalon jelenti a korábbi állapotot, vagyis a nagy energiafogyasztást, a jelentős csökkenést pedig a 4 cm-es LEGO-figura képviseli](energy_consumption_pre_post_merge.png) + +A CCRI becslése szerint a Beolvadás több mint **99,988%-kal** lecsökkentette az Ethereum éves áramfogyasztását. Ugyanígy az Ethereum karbonlábnyoma is csökkent **99,992%-kal** (11 016 000 tonna helyett 870 tonna CO2e lett). Ez a változás olyan, mint az Eiffel torony magaságáról egy kis bábu méretére csökkent fogyasztás, ahogy az ábra illusztrálja. Ennek következtében a hálózat biztosításának környezeti költsége drasztikusan lecsökkent. A hálózat biztonsága pedig növekedett. + +## Környezetbarát alkalmazási réteg {#green-applications} + +Miközben az Ethereum energiafogyasztása nagyon alacsony, egy jelentős, fejlődő és igen aktív [**regeneratív pénzügyi (ReFi)**](/refi/) közösség épült a hálózaton. A ReFi alkalmazások a decentralizált pénzügyek (DeFi) komponenseit használják, hogy olyan pénzügyi alkalmazásokat építsenek, amelyek pozitív externáliákat teremtenek. A ReFi része egy kiterjedtebb[„solarpunk”](https://en.wikipedia.org/wiki/Solarpunk) mozgalomnak, ami szorosan kötődik az Ethereumhoz, és a technológiai fejlődést a környezetről való gondoskodással párosítja. Az Ethereum decentralizált, engedélymentes és egymásra építhető jellege miatt ideális alap a ReFi és a solarpunk közösségeknek. + +A web3 közjó-finanszírozási platformjai, mint a [Gitcoin](https://gitcoin.co) klímaköröket működtetnek, hogy elősegítsék az Ethereum alkalmazási rétegének környezettudatos építését. Ezen kezdeményezések (és mások, mint a [decentralizált tudomány / DeSci](/desci/)) kialakulása által az Ethereum egy környezeti és közösségi szempontból pozitív technológia. + + + Ha szeretne az oldallal kapcsolatban fejlesztést javasolni, akkor naplózzon egy kérést (issue) vagy PR-t. A statisztikák nyilvánosan elérhető adatokból készült becslések, nem hivatalos állítások vagy ígéretek az ethereum.org csapat vagy az Ethereum Alapítvány részéről. + + +## További olvasnivaló {#further-reading} + +- [Cambridge-blokklánchálózat fenntarthatósági indexe](https://ccaf.io/cbnsi/ethereum) +- [Fehérházi jelentése a proof-of-work alapú blokkláncokról](https://www.whitehouse.gov/wp-content/uploads/2022/09/09-2022-Crypto-Assets-and-Climate-Report.pdf) +- [Ethereum-kibocsátás: egy alulról építkező becslés](https://kylemcdonald.github.io/ethereum-emissions/) – _Kyle McDonald_ +- [Ethereum energiafelhasználási index](https://digiconomist.net/ethereum-energy-consumption/) – _Digiconomist_ +- [ETHMerge.com](https://ethmerge.com/) – _[@InsideTheSim](https://twitter.com/InsideTheSim)_ +- [Az egyesítés (The Merge) – az Ethereum-hálózat áramfogyasztására és karbonlábnyomára gyakorolt hatása](https://carbon-ratings.com/eth-report-2022) – _CCRI_ +- [Az Ethereum energiafogyasztása](https://mirror.xyz/jmcook.eth/ODpCLtO4Kq7SCVFbU4He8o8kXs418ZZDTj0lpYlZkR8) + +## Kapcsolódó témák {#related-topics} + +- [Az Ethereum jövőképe](/roadmap/vision/) +- [A Beacon Chain](/roadmap/beacon-chain) +- [Az egyesítés](/roadmap/merge/) diff --git a/public/content/translations/hu/09) Learn Pages/governance/index.md b/public/content/translations/hu/09) Learn Pages/governance/index.md new file mode 100644 index 00000000000..dc047fa5bf4 --- /dev/null +++ b/public/content/translations/hu/09) Learn Pages/governance/index.md @@ -0,0 +1,182 @@ +--- +title: Az Ethereum irányítása +description: Annak bemutatása, hogy az Ethereummal kapcsolatos döntések hogyan születnek meg. +lang: hu +--- + +# Bevezetés az Ethereum irányításába {#introduction} + +_Ha senki sem birtokolja az Ethereumot, akkor a döntéseket hogyan hozzák meg az Ethereum kapcsán? Az Ethereum irányítása (governance) egy olyan folyamat, mely lehetővé teszi a döntések meghozatalát._ + + + +## Mi az az irányítás (governance)? {#what-is-governance} + +Az irányítás az a rendszer, amely lehetővé teszi a döntéshozást. Egy tipikus szervezeti struktúrában a végrehajtó csapat vagy az igazgatótanács szava az utolsó a döntéshozásban. Vagy talán a részvényesek szavaznak a javaslatokra, hogy változást indítsanak el. A politikai rendszerben a választott hivatalnokok olyan törvényt hoznak, ami a választóik javát szolgálja. + +## Decentralizált irányítás {#decentralized-governance} + +Az Ethereum protokollt nem birtokolja vagy kontrollálja senki, ugyanakkor a változásokról dönteni kell, hogy a hálózat hosszú életét és prosperitását a leginkább biztosítsák. A tulajdonlás hiánya miatt a hagyományos szervezeti irányítás nem működő megoldás. + +## Ethereum-felügyelet {#ethereum-governance} + +Az Ethereum irányítása (governance) az a folyamat, amely által a protokoll megváltoztatható. Fontos kiemelni, hogy ez nem kapcsolódik ahhoz, hogy az emberek és az alkalmazások hogyan használják a protokollt, mert az Ethereum egy engedélymentes hálózat. A világon bárki bárhonnan részt vehet a láncon zajló tevékenységekben. Nincsenek olyan szabályok, hogy ki csinálhat vagy nem csinálhat alkalmazást vagy indíthat tranzakciókat. Ugyanakkor van egy folyamat, mellyel változásokat lehet kezdeményezni a protokollban, amelyre a decentralizált alkalmazások épülnek. Mivel sok ember függ az Ethereum stabilitásától, ezért a kulcsváltozások koordinációs küszöbe nagyon magas, beleértve a közösségi és technikai folyamatokét is, hogy az Ethereum módosítása biztonságos és a közösség által széles körben támogatott legyen. + +### A láncon belüli és kívüli irányítás összehasonlítása {#on-chain-vs-off-chain} + +A blokklánc-technológiával új irányítási képességek jelentek meg, mint amilyen a láncon belüli irányítás is. A láncon belüli irányítás az, amikor a javasolt protokollváltoztatásokat az érdekeltek megszavazzák, általában egy irányítási token birtokában, a szavazás pedig a láncon zajlik. A láncon belüli irányítás néhány esetében a javasolt változások már bele vannak írva a kódba és automatikusan végrehajtásra kerülnek, ha az érdekeltek jóváhagyják azt, aláírva a tranzakciót. + +A másik megközelítés, a láncon kívüli irányítás az, amikor a protokoll változtatásait egy közösségi megvitatás informális folyamata vezérli, amit ha jóváhagynak, akkor teszik bele a kódba. + +**Az Ethereum-irányítás láncon kívül történik** az érdekeltek széles körét bevonva. + +_Miközben a protokollszintű Ethereum-irányítás láncon kívül zajlik, addig számos alkalmazási területe van a láncon belüli irányításnak, mint például a decentralizált autonóm szervezetek (DAO) működése._ + + + Bővebben a DAO-król + + + + +## Ki vesz részt ebben? {#who-is-involved} + +Az [Ethereum-közösségben](/community/) számos érdekelt fél van, akik szerepet játszanak az irányítási folyamatban. A protokolltól távolabb lévőktől kezdve így néz ki az érdekeltek köre: + +- **Ether-használók**: olyan emberek, akik egy tetszőleges összegű ETH-t birtokolnak. [Bővebben az ETH-ről](/eth/). +- **Az alkalmazások felhasználói**: akik az Ethereum blokkláncán lévő alkalmazásokat használják. +- **Alkalmazások/eszközök fejlesztői**: akik alkalmazásokat írnak az Ethereum blokkláncra (pl. DeFi, NFT-k stb.), vagy eszközöket építenek, amelyek az Ethereummal lépnek interakcióba (pl. tárcák, tesztcsomagok stb.). [Bővebben a dapp-okról](/dapps/). +- **Csomópont-operátorok**: akik csomópontokat működtetnek, amelyek blokkokat és tranzakciókat javasolnak, illetve elutasítják az érvénytelen tranzakciókat vagy blokkokat. [Bővebben a csomópontokról](/developers/docs/nodes-and-clients/). +- **EIP-szerzők**: ők javasolnak változásokat az Ethereum-protokollt illetően Ethereum fejlesztési javaslatok (EIP) formájában. [Bővebben az EIP-ekről](/eips/). +- **Validátorok**: ők olyan csomópontokat futtatnak, melyek új blokkokat tudnak adni az Ethereum-blokklánchoz. +- **Protokollfejlesztők** (azaz „Magfejlesztők” ): ők kezelik a különféle Ethereum-implementációkat (pl. go-ethereum, Nethermind, Besu, Erigon, Reth a végrehajtási rétegen; Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandine a konszenzusrétegen). [Bővebben az Ethereum-kliensekről](/developers/docs/nodes-and-clients/). + +_Megjegyzés: bárki lehet több csoport tagja is (pl. a protokollfejlesztő lehet EIP-bajnok is, futtathat Beaconlánc-validátort és használhat DeFi-alkalmazásokat). A koncepcionális egyértelműség miatt könnyebb, ha megkülönböztetjük őket._ + + + +## Mi az az Ethereum fejlesztési javaslat (EIP)? {#what-is-an-eip} + +Az egyik fontos Ethereum-irányítási eszköz az **Ethereum fejlesztési javaslatok (EIP)** kezelése. Az EIP olyan szabvány, amely egy lehetséges új funkciót vagy folyamatot specifikál az Ethereum számára. Az Ethereum-közösség bármelyik tagja létrehozhat EIP-t. Ha Önt érdekli az EIP írása, értékelése vagy irányítása, akkor: + + + Bővebben az EIP-kről + + + + +## A hivatalos folyamat {#formal-process} + +Az Ethereum-protokollt érintő változásokat a következő módon lehet kezdeményezni: + +1. **Javasoljon egy alapvető (core) EIP-et**: ahogy az [EIP-1](https://eips.ethereum.org/EIPS/eip-1#core-eips) részletezi, az első lépés egy Ethereum változtatáshoz az, hogy egy alapvető EIP-ben kidolgozzák azt. Ez lesz a hivatalos specifikációja egy EIP-nek, amit a protokollfejlesztők implementálnak, ha elfogadásra kerül. + +2. **Mutassa be az EIP-et a protokollfejlesztőknek**: amint egy alapvető EIP-vel rendelkezik, amelyhez közösségi adatokat is gyűjtött, mutassa be azt a fejlesztőknek. Ehhez javasolja, hogy vitassák azt meg egy [AllCoreDevs konferenciabeszélgetésen](https://github.com/ethereum/execution-specs/tree/master/network-upgrades#getting-the-considered-for-inclusion-cfi-status). Valószínűleg valamilyen beszélgetés már történt róla az [Ethereum Magician fórumon](https://ethereum-magicians.org/) vagy az [Ethereum R&D Discord csatornán](https://discord.gg/mncqtgVSVw). + +> E fázis lehetséges kimenetelei: + +> - Az EIP megfontolásra kerül egy következő hálózati fejlesztésnél +> - Technikai változásokat kérhetnek +> - Elutasításra kerülhet, ha nem prioritás vagy a fejlődés nem elég nagy a fejlesztési erőfeszítéshez képest + +3. **A javaslat iteratív további fejlesztése a végső verzió felé:** a releváns érdekeltektől jövő visszajelzések alapján valószínűleg változásokat kell eszközölni a kezdeti javaslaton, hogy biztonságosabb legyen vagy a felhasználók igényeit jobban kielégítse. Amint ezek a változások megvalósultak, újra be kell mutatni azt a protokollfejlesztőknek. Ekkor vagy tovább lehet lépni, vagy új kérdések merülnek fel, így tovább kell dolgozni a javaslaton. + +4. **Az EIP bekerül a hálózati frissítésbe**: feltéve, hogy a javaslat addigra átesik a jóváhagyáson, tesztelésen és bevezetésen, bele fog kerülni a következő rendszerfrissítésbe. Mivel ezeknek elég komoly a koordinációs költsége (mindenkinek egyszerre kell frissíteni), ezért az EIP-k csomagba kerülnek. + +5. **A hálózati frissítés aktiválása**: az aktiválás után az EIP élesedik az Ethereum hálózaton. _Megjegyzés: a hálózati frissítéseket általában a teszthálózaton aktiválják, mielőtt az Ethereum-főhálózatra kerülnének._ + +Ez az egyszerűsített folyamat betekintést ad a protokollváltoztatások főbb állomásaiba. Most nézzük meg az informális tényezőket, melyek mindezt befolyásolják. + +## Az informális folyamat {#informal-process} + +### A korábbi munkák megértése {#prior-work} + +Az EIP-bajnokoknak ismerni kell a korábbi munkákat és javaslatokat, mielőtt egy újat készítenek, hogy azt komolyan megfontolják egy Ethereum-fejlesztéseként. Így az EIP javaslat újdonságot hozhat, nem pedig egy korábban már elutasított dolgot. Három fő helyen kell átnézni az anyagokat: [EIP-könyvtár](https://github.com/ethereum/EIPs), [Ethereum Magicians](https://ethereum-magicians.org/) és [ethresear.ch](https://ethresear.ch/). + +### Munkacsoportok {#working-groups} + +Az EIP kezdeti javaslata változtatások nélkül nem valószínű, hogy végigmegy a bevezetésig. Általában az EIP-bajnokok a protokollfejlesztők egy kis csoportjával dolgoznak együtt, hogy specifikálják, létrehozzák, teszteljék és véglegesítsék a javaslatot. Korábban ezek a munkacsoportok számos hónapot (néha éveket) dolgoztak a javaslatokon. Az EIP-bajnokok emellett be kell vonják a releváns alkalmazás- vagy eszközfejlesztőket, hogy a felhasználóktól is tudjanak visszajelzést kapni, illetve csökkentsék a megvalósítás kockázatát. + +### Közösségi konszenzus {#community-consensus} + +Miközben néhány EIP egyértelmű technikai fejlesztés, addig mások komplexek és olyan kompromisszumokat kívánnak meg, melyek a különféle érdekeltek másképpen érintik. Tehát néhány javaslat több vitát vált ki. + +Nincs egyértelmű kézikönyv, hogy a vitás javaslatokat hogyan kezeljék. Az Ethereum decentralizált dizájnjának eredménye, hogy egyetlen érdekcsoport sem nyomhat el egy másikat: a protokollfejlesztők dönthetnek úgy, hogy nem fejlesztenek le egy kódváltoztatást; a csomópont-operátorok nem használják a legújabb Ethereum-klienst; az alkalmazásokat készítő csoportok és felhasználók pedig nem használják a hálózatot. Mivel a protokollfejlesztők nem tudják kényszeríteni az embereket a hálózati frissítések használatára, ezért általában elkerülik azokat a javaslatokat, ahol a vitatottság nagyobb, mint a nyilvánvaló előnyök. + +Az EIP-bajnokoknak minden releváns érdekelttől visszajelzést kell kérniük. Ha egy vitatottabb EIP-ről van szó, akkor meg kell próbálni az ellenvetéseket sorban átbeszélni, hogy konszenzus tudjon kialakulni. Az Ethereum-közösség méretét és diverzitását tekintve nincs egy mértéke a közösség konszenzusának, ezért a fejlesztési javaslatot a körülményekhez igazítva kell kezelni. + +Az Ethereum-hálózat biztonságán túl rendkívül fontos az, hogy miként vélekednek a protokollfejlesztők, az alkalmazás-/eszközfejlesztők és az alkalmazások felhasználói, mert az ő közreműködésük és munkájuk teszi vonzóvá ezt az ökoszisztémát. Emellett az EIP-ket az összes kliensen végig kell vezetni, amit különböző csapatok végeznek. Tehát meg kell győzni a protokollfejlesztők számos csapatát, hogy az adott változás értékes, segíti a felhasználókat vagy biztonsági problémát old meg. + + + +## A nézeteltérések kezelése {#disagreements} + +Mivel ennyiféle érdekelt van különböző motivációkkal és hitekkel, ezért a nézeteltérés nem ritka. + +Általában a nézeteltéréseket hosszú egyeztetéseken kezelik nyilvános fórumokon, hogy a probléma gyökerét megtalálják és azt mindenki meg tudja fontolni. Általában az egyik fél engedményt tesz vagy egy örömteli középutat találnak. Ha az egyik csoport egy adott változást áterőltet a rendszeren, akkor a lánc kettéválhat. Amikor az érdekeltek egy része kifogásol egy változást, így a protokollnak egy eltérő, nem kompatibilis verziói működnek, melyekből két blokklánc emelkedik ki. + +### A DAO elágazás {#dao-fork} + +Az elágazások akkor jönnek létre, amikor komoly technikai változások történnek a hálózaton és megváltoztatják a protokoll szabályait. Az [Ethereum-klienseknek](/developers/docs/nodes-and-clients/) frissíteni kell a szoftverjét, hogy az új elágazási szabályokat életbe léptessék. + +A DAO-elágazás volt a válasz egy [2016-os DAO-támadásra](https://www.coindesk.com/understanding-dao-hack-journalists), amikor egy sebezhető [DAO](/glossary/#dao) szerződésből 3,6 millió ETH-t ürítettek le a támadás során. Az elágazás a pénzeszközöket a hibás szerződésből egy újba tette át, hogy a támadás során károsultak kaphassanak belőle. + +Ennek az akciónak a kezelését megszavazták az Ethereum közösségen belül. Bármely ETH tulajdonos szavazhatott egy tranzakción keresztül [egy szavazási platformon](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/). Az elágazás mellett több mint a szavazók 85%-a voksolt. + +Fontos megjegyezni, hogy miközben a protokoll tényleg elágazott, hogy visszafordítsa a támadást, a szavazás súlya megkérdőjelezhető: + +- A szavazók száma rendkívül alacsony volt +- A legtöbben nem tudták, hogy szavazás történt +- A szavazást csak ETH-val rendelkezők végezték, a rendszer többi résztvevője nem vett részt + +A közösség ezen része elutasította az elágazást, főleg, mert az incidenst nem a protokollnak tulajdonították. Ők ezután létrehozták az [Ethereum Classicot](https://ethereumclassic.org/). + +Ma az Ethereum közössége a beavatkozásmentesség szabályát követi a hibás szerződések vagy elveszett pénzek esetén, hogy megtartsák a rendszer hihető semlegességét. + +Bővebben a DAO-támadásról: + + + + + +### Az elágazás hasznossága {#forking-utility} + +Az Ethereum/Ethereum Classic elágazás egy kiváló példája az egészséges elágazásnak. A két csoport elég nagy mértékben nem értett egyet egymással az alapvető értékek tekintetében, hogy megérte a kockázatot, hogy a saját útjukat kövessék. + +Az elágazás lehetősége a jelentős politikai, filozófiai vagy gazdasági különbségek esetén az Ethereum-irányítás sikerének fontos része. Az elágazás lehetősége nélkül az alternatívák folyamatosan ütköztek, részvételre kényszerítve a vonakodókat, akik később végül létrehozták az Ethereum Classicot, és egy teljesen más vízióval rendelkeztek arról, hogy az Ethereum sikere miben áll. + + + +## Beacon-lánc irányítása {#beacon-chain} + +Az Ethereum-irányítási folyamat gyakran a gyorsaság és a hatékonyság rovására a nyitottságot és a bevonódást hangsúlyozza. A Beacon-lánc fejlesztésének meggyorsítása érdekében ezt a proof-of-work Ethereum-hálózattól külön hozták létre, és a maga irányítási gyakorlatát követte. + +Miközben a specifikáció és a fejlesztés teljesen nyitott volt, a hivatalos fejlesztési folyamat nem követte a fenti lépéseket. Így a kutatók és a fejlesztők gyorsabban meg tudtak egyezni a specifikus változtatásokon. + +Amikor a Beacon-lánc egyesült az Ethereum végrehajtási réteggel 2022. szeptember 15-én, a Merge teljesült a [Paris hálózati frissítés](/history/#paris) részeként. Az [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) javaslat státusza véglegesre változott befejezve az átállást a proof-of-stake mechanizmusra. + + + A beolvadásról bővebben + + + + +## Hogyan lehet részt venni? {#get-involved} + +- [Javasoljon egy EIP-t](/eips/#participate) +- [Vitassa meg a jelenlegi javaslatokat](https://ethereum-magicians.org/) +- [Vegyen részt az R&D beszélgetéseken](https://ethresear.ch/) +- [Csatlakozzon az Ethereum R&D Discord csatornához](https://discord.gg/mncqtgVSVw) +- [Csomópont futtatása](/developers/docs/nodes-and-clients/run-a-node/) +- [Vegyen részt a kliensfejlesztésekben](/developers/docs/nodes-and-clients/#execution-clients) +- [Protokollfejlesztő gyakornoki program](https://blog.ethereum.org/2021/09/06/core-dev-apprenticeship-second-cohort/) + +## További olvasnivaló {#further-reading} + +Az Ethereumban az irányítás nincs szigorúan definiálva. A közösség különféle tagjainak eltérő perspektívái vannak ezzel kapcsolatban. Néhány ezek közül: + +- [Megjegyzések a blokkláncirányításról](https://vitalik.eth.limo/general/2017/12/17/voting.html) – _Vitalik Buterin_ +- [Hogyan működik az Ethereum irányítása?](https://cryptotesters.com/blog/ethereum-governance) – _Cryptotesters_ +- [Hogyan működik az Ethereum irányítása](https://medium.com/coinmonks/how-ethereum-governance-works-71856426b63a) – _Micah Zoltu_ +- [Kik az az Ethereum protokollfejlesztői?](https://hudsonjameson.com/2020-06-22-what-is-an-ethereum-core-developer/) – _Hudson Jameson_ +- [Irányítás, 2. rész: A plutokrácia még mindig rossz](https://vitalik.eth.limo/general/2018/03/28/plutocracy.html) – _Vitalik Buterin_ +- [Túl az érmealapú szavazásra épülő irányításon](https://vitalik.eth.limo/general/2021/08/16/voting3.html) – _Vitalik Buterin_ diff --git a/public/content/translations/hu/09) Learn Pages/security/index.md b/public/content/translations/hu/09) Learn Pages/security/index.md new file mode 100644 index 00000000000..d339da19853 --- /dev/null +++ b/public/content/translations/hu/09) Learn Pages/security/index.md @@ -0,0 +1,295 @@ +--- +title: Ethereum-biztonság és átverés elleni védelem +description: Biztonságban az Ethereumon +lang: hu +--- + +# Ethereum-biztonság és átverés elleni védelem {#introduction} + +A kriptopénzek iránti növekvő érdeklődés egyre nagyobb kockázatot jelent a csalók és a hackerek részéről. Ez a cikk néhány bevált gyakorlatot mutat be e kockázatok mérséklésére. + +**Ne feledje: Az ethereum.org sosem lép Önnel kapcsolatba. Ne válaszoljon azokra az e-mailekre, amelyek azt állítják, hogy az Ethereum hivatalos támogatói csapatától érkeznek.** + + + +## Kriptobiztonság 101 {#crypto-security} + +### Növelje tudását {#level-up-your-knowledge} + +A kriptográfia működésével kapcsolatos félreértések költséges hibákhoz vezethetnek. Ha például valaki ügyfélszolgálati ügynöknek adja ki magát, aki a privát kulcsokért cserébe vissza tudja adni az elveszett ETH-t, akkor kihasználja azokat az embereket, akik nem értik, hogy az Ethereum egy decentralizált hálózat, amelyből hiányzik ez a fajta funkció. Az Ethereum működésének megértése megéri a befektetést. + + + Mi az Ethereum? + + + + Mi az ether? + + + +## Tárcabiztonság {#wallet-security} + +### Sose ossza meg privát kulcsait {#protect-private-keys} + +**Soha, semmilyen okból se ossza meg a privát kulcsait!** + +A tárca privát kulcsa az Ethereum-tárca jelszava. Ez az egyetlen dolog, aminek a hiányában valaki nem viszi el az összes eszközt a tárcájából, ha ismeri annak a címét! + + + Mi az az Ethereum tárca? + + +#### Sose készítsen képernyőképet a kulcsmondatról/privát kulcsokról {#screenshot-private-keys} + +A képernyőkép készítésével azt kockáztatja, hogy az szinkronizálódik a felhőbe és így elérhetővé válik a támadók számára. A privát kulcsok megszerzése a felhőből egy tipikus támadási forma. + +### Használjon hardveres tárcát {#use-hardware-wallet} + +A hardveres tárca offline módon tárolja a privát kulcsokat. Ez a legbiztonságosabb tárca a privát kulcsok tárolására: a kulcs sosem kapcsolódik az internethez és teljesen helyben marad az eszközén. + +A privát kulcsok offline tartása komoly szinten csökkenti a támadás kockázatát, még ha egy támadó hozzá is fér a számítógépéhez. + +#### Próbálja ki a hardveres tárcát: {#try-hardware-wallet} + +- [Ledger](https://www.ledger.com/) +- [Trezor](https://trezor.io/) + +### Ellenőrizze kétszer a tranzakciókat küldés előtt {#double-check-transactions} + +A rossz tárcába küldött kripto egy tipikus hiba. **Az Ethereumon küldött tranzakció visszafordíthatatlan.** Hacsak nem ismeri a cím tulajdonosát és nem tudja meggyőzni arról, hogy visszaküldje, különben nem tudja visszaszerezni azt. + +Mindig győződjön meg arról, hogy cím pontosan egyezik a kívánt címmel, mielőtt elküldi a tranzakciót. Az okosszerződésekkel való interakciónál is mindig olvassa el a tranzakcióüzenetet, mielőtt aláírja azt. + +### Állítson be költségkeretet az okosszerződéshez {#spend-limits} + +Az okosszerződéseknél ne engedjen korlátlan költési keretet. A korlátlan költés megengedi az okosszerződésnek, hogy kiürítse az Ön tárcáját. Ehelyett állítsa be pontosan azt az összeget, ami a tranzakcióhoz szükséges. + +Számos Ethereum-tárca kínál védelmet keretek beállításával, hogy ne lehessen kiüríteni a tárcát. + +[Hogyan vonható vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez](/guides/how-to-revoke-token-access/) + + + +## Gyakori csalások {#common-scams} + +Nem lehet őket teljesen megállítani, de elérhetjük, hogy kevésbé hassanak ránk, ha ismerjük a legjellemzőbb fogásaikat. Ezeknek a csalásoknak számos variációja van, de általánosságban egy mintát követnek. Emlékezzen rá: + +- mindig legyen szkeptikus +- senki sem ad Önnek ETH-t ingyen vagy olcsón +- senkinek se adja meg a privát kulcsait vagy a személyes információit + +### Twitter-hirdetéses adathalászat {#ad-phishing} + +![Twitter-hivatkozásos adathalászat](./twitterPhishingScam.png) + +Van egy módszer a Twitter (vagyis X) hivatkozás előnézeti funkciójának (kibontása) meghamisítására, amellyel potenciálisan megtéveszthetik a felhasználókat, hogy azt higgyék, egy legitim webhelyet látogatnak meg. Ez a technika a Twitter mechanizmusát használja ki a tweetekben megosztott URL-ek előnézetének létrehozására, és például azt mutathatja, hogy az az _ethereum.org_-tól származik (ahogy a fenti képen), miközben egy rosszindulatú webhelyre irányítja át. + +Mindig ellenőrizze, hogy a megfelelő oldalon van-e, különösen egy hivatkozásra kattintás után. + +[További információk itt](https://harrydenley.com/faking-twitter-unfurling). + +### Ajándékozási csalás {#giveaway} + +Az egyik legtipikusabb csalás a kriptovalutákkal az ajándékozás. Számos formában előfordulhat, de a lényege az, hogy ha Ön ETH-t küld a megadott tárcacímre, akkor duplán kapja vissza az ETH-t. *Emiatt 2-t 1-ért csalásnak is nevezik.* + +Ez az ajánlat csak limitált időre szól, hogy a sürgetés érzését keltse. + +### Közösségimédia-csalások {#social-media-hacks} + +Ennek nagy horderejű esete például 2020. júliusában volt, amikor híres emberek és szervezetek Twitterjét támadták meg. A támadó bitcoin-ajándékozást hirdetett ezeken a számlákon. Habár a megtévesztő üzeneteket gyorsan észrevették és törölték, a támadók még így is szereztek 11 bitcoint (ami 500 000 USD-nek felel meg a 2021. szeptemberi árfolyamon). + +![Csalás a Twitteren](./appleTwitterScam.png) + +### Hírességek ajándékoznak {#celebrity-giveaway} + +A hírességek által kommunikált ajándékozás is tipikus. A csalók egy videóinterjút vagy konferenciabeszélgetést úgy tesznek fel a YouTube-ra, mintha élőben menne, és ennek részeként a híresség egy kriptovaluta-ajándékozást hirdet meg. + +Vitalik Buterint és a kriptóban érintett más személyeket (pl. Elon Musk vagy Charles Hoskinson) gyakran használnak így. Ez adja a csalás valódiságának látszatát (furcsa, de ha Vitalik mondja, akkor biztos úgy van!). + +**Az ajándékozások mindig csalások. Ha bármilyen pénzt küld ezekre a felhívásokra, azt elveszíti.** + +![Csalás a YouTube-on](./youtubeScam.png) + +### Támogatási csalások {#support-scams} + +A kriptovaluta egy viszonylag fiatal és félreértett technológia. Ezt használja ki az a csalás, amikor ügyfélszolgálatosnak adják ki magukat a népszerű tárcák, tőzsdék vagy blokkláncok kapcsán. + +Az interakciók többsége Discordon történik. A támogatást színlelő csalók ezeken a csatornákon keresik azokat, akiknek kérdésük van, majd privát üzenetet küldenek nekik, hogy felajánlják segítségüket. Ráveszik a felhasználót, hogy bízzon meg bennük, majd megszerzik a privát kulcsaikat vagy pénzt küldenek a saját tárcájukba. + +![Támogatást ajánló csalás a Discordon](./discordScam.png) + +Általános szabály, hogy senki sem kommunikál Önnel privát, nem hivatalos csatornákon. Ezeket tartsa észben, ha támogatásról van szó: + +- Sose adja meg a privát kulcsait, kulcsmondatát vagy jelszavait +- Sose engedje, hogy bárki távolról hozzáférjen a gépéhez +- Sose kommunikáljon senkivel a szervezet dedikált csatornáin kívül + + +
+ Legyen tudatában: hogy a támogatást ajánló csalók gyakran a Discordon jelennek meg, de bármilyen kommunikációs formában ott lehetnek, legyen az chat vagy email. +
+ + +### „ETH2” hamis token {#eth2-token-scam} + +[Az egyesítés (The Merge)](/roadmap/merge/) közeledtével a csalók kihasználták a zavart az „ETH2” kifejezés körül és próbálták rávenni a felhasználókat, hogy váltsák át az ETH-t „ETH2”-re. Nem létezik ETH2, és a Merge sem vezetett be semmilyen tokent. A Merge előtt és után pontosan ugyanaz az ETH létezik. **Az ETH-val kapcsolatban semmit se kellett tenni a felhasználóknak, amikor a rendszer proof-of-work helyett proof-of-stake mechanizmusra állt át**. + +A csalók ügyfélszolgálatosként jelennek meg, hogy rávegyék Önt, adja át az ETH-t és „ETH2”-t kap helyette. Nincs [hivatalos Ethereum-ügyfélszolgálat](/community/support/), és nincs új token. Sose ossza meg a tárcához kapcsolódó kulcsmondatot senkivel. + +_Megjegyzés: Vannak olyan származékos tokenek, amelyek letétbe helyezett ETH-t képviselnek (pl. rETH a Rocket Pooltól, stETH a Lidotól, ETH2 a Coinbase-től), de ezekre nem kell átállnia._ + +### Adathalász csalások {#phishing-scams} + +Az adathalász csalások is egyre gyakoribbak, hogy a csalók ellopják a tárcák tartalmát. + +Néhány ilyen e-mail arra kéri a felhasználót, hogy bizonyos hivatkozásra kattintva lépjen egy weboldalra, adja meg a kulcsmondatát, kérjen új jelszót vagy küldjön ETH-t. Mások olyan rosszindulatú programokat telepítenek a gépére, amivel a csalók hozzáférnek a fájljaihoz. + +Ha egy ismeretlen küldőtől kap üzenetet, akkor: + +- Sose nyisson meg hivatkozást vagy csatolmányt ismeretlen feladótól +- Sose árulja el személyes adatait vagy jelszavait senkinek +- Törölje az ismeretlen feladóktól érkező e-maileket + +[Bővebben az adathalász csalások elkerüléséről](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico) + +### Kriptobrókeres csalás {#broker-scams} + +A kriptobrókeres csalók szakembereknek adják ki magukat, akik elkérik az Ön pénzét, hogy befektessék az Ön nevében. Miután megkapták az összeget, lehetséges, hogy még többet kérnek valamilyen különleges lehetőségre, vagy akár el is tűnnek azonnal. + +Ezek a csalók hamis profilokat használnak a YouTube-on, ahol látszólag semleges beszélgetéseket folytatnak. Ezek a beszélgetések nagyon jó értékeléssel rendelkeznek, de ezt mind programok (bot) szavazzák meg nekik, hogy így hitelesebbnek tűnjenek. + +**Sose bízzon meg idegeneket az interneten, hogy befektessék a pénzét. El fogja veszíteni a kriptóját.** + +![Brókeres csalás a YouTube-on](./brokerScam.png) + +### Kriptobányászati csalások {#mining-pool-scams} + +2022. szeptembere óta nincs az Ethereumon bányászás. A csalások mégis tovább folytatódnak. A kriptobányászási csalásoknál arra próbálják rávenni az embereket, hogy csatlakozzanak az Ethereum-bányászathoz, ami nagy jövedelmeket hoz. A csaló kapcsolatban marad Önnel egész végig. Valójában meggyőzi Önt arról, hogy ha csatlakozik a bányászáshoz, akkor az ETH egyenlege még több ETH-t hoz létre. Ezután látni fogja, hogy a kriptovalutája kis hozamot termel. De ez csak azért van, hogy még többet fektessen be. Végül az összes pénzeszközét egy ismeretlen címre küldik, és a csaló eltűnik, vagy akár kapcsolatban is maradhat áldozatával. + +Tartózkodjon azoktól, akik a közösségi médiában be akarják Önt vonni a bányászatba. Ha elveszíti a kriptóját, az többé nem kerül vissza. + +Ne feledje: + +- Legyen óvatos, ha bárki még több pénzt akar csinálni a kriptójából +- Nézze meg a lehetőségeket a letétbe helyezés, likviditási alapok és más befektetések kapcsán +- Az ilyen ajánlatok szinte sose valósak. Ha azok lennének, akkor mindenki ezt követné és ezért már hallott volna róla. + +[Egy ember 200 000 USD-t vesztett egy kriptobányászási csalásban](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/) + +### Tokenkiosztási (airdrop) csalások {#airdrop-scams} + +A tokenkiosztási (airdrop) csalások során egy hamis projekt eszközt (NFT, token) dob az Ön tárcájába és egy hamis weboldalra küldi, hogy kérvényezze azokat. Így be kell jelentkeznie az Ethereum-tárcájába és jóváhagynia a tranzakciót. Ez a tranzakció veszélybe sodorja a számláját, mivel a nyilvános és privát kulcsait átadja a csalónak. Az is lehet, hogy egy olyan tranzakciót ír alá, ami a csalónak küldi az Ön pénzeszközeit. + +[Bővebben a tokenkiosztási (airdrop) csalásokról](https://www.youtube.com/watch?v=LLL_nQp1lGk) + + + +## Webbiztonság 101 {#web-security} + +### Használjon erős jelszavakat {#use-strong-passwords} + +[A számlatámadások 80%-a a gyenge vagy ellopott jelszavakból ered](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). Egy hosszú, betűkből, számokból és szimbólumokból álló sorozat segíthet abban, hogy a számlája biztonságban legyen. + +Gyakori hiba, hogy néhány gyakori, összefüggő szó kombinációját használjuk. Az ehhez hasonló jelszavak nem biztonságosak, mert hajlamosak egy hackelési technikára, amelyet szótáralapú támadásnak hívnak. + +```md +Gyenge jelszó például: AranyosBolyhosCicák! + +Erős jelszó például: ymv\*azu.EAC8eyp8umf +``` + +A másik általános hiba az, amikor a [közösségi média alapján kitalálható](https://wikipedia.org/wiki/Social_engineering_(security)) jelszót találnak ki. Az édesanyja leánykori neve, a gyerekek vagy háziállatok nevei, a születési időpontok használata növeli a támadás kockázatát. + +#### A jó jelszóhoz: {#good-password-practices} + +- Olyan hosszú jelszót válasszon, amit jelszógenerátor készít vagy megenged az adott rendszer +- Használjon nagybetűt, kisbetűt, számokat és jeleket +- Ne használjon személyes adatokat, mint családi nevek +- Kerülje a gyakori, általános szavakat + +[Bővebben az erős jelszó létrehozásáról](https://terranovasecurity.com/how-to-create-a-strong-password-in-7-easy-steps/) + +### Használjon egyedi jelszót mindenre {#use-unique-passwords} + +Egy erős jelszó, amely egy adatvédelmi incidens során nyilvánossá vált, már nem számít erős jelszónak. A [Have I Been Pwned](https://haveibeenpwned.com) weblap megmutatja, hogy a számláját érintette-e bármilyen nyilvános adatvédelmi incidens. Ha igen, akkor **azonnal cserélje le a jelszavait**. Az egyedi jelszavak használata csökkenti annak kockázatát, hogy a támadó mindenhez hozzáfér, ha egy jelszót feltör. + +### Használjon jelszókezelőt {#use-password-manager} + + +
+ A jelszókezelő erős, egyedi jelszavakat hoz létre és meg is jegyzi azokat! Erősen ajánljuk, hogy használjon ilyet, és a legtöbb ingyen van! +
+ + +Az erős, egyedi jelszavakat nem túl ideális megjegyezni az összes számlához. A jelszókezelő egy biztonságos, titkosított tárhelyet biztosít az összes jelszónak, amit egy erős mesterjelszóval tud elérni. Az új szolgáltatásokra való bejelentkezéseknél is erős jelszavakat ajánl, így Önnek nem kell kitalálnia azt. Számos jelszókezelő azt is megmondja, hogy Ön érintett-e adatszivárgásban, így lecserélheti a jelszavait, mielőtt támadás érné. + +![Példa a jelszókezelő használatára](./passwordManager.png) + +#### Próbáljon ki egy jelszókezelőt: {#try-password-manager} + +- [Bitwarden](https://bitwarden.com/) +- [KeePass](https://keepass.info/) +- [1Password](https://1password.com/) +- Emellett más [javasolt jelszókezelőket](https://www.privacytools.io/secure-password-manager) is megtekinthet + +### Használjon kéttényezős azonosítást {#two-factor-authentication} + +Előfordulhat, hogy arra kérik Önt, hogy egyedi igazolásokkal hitelesítse személyazonosságát. Ezeket nevezzük **tényezőknek**. A három fő tényező a következő: + +- Valami, amit tud (mint egy jelszó vagy biztonsági kérdés) +- Valami, ami Öntől származik (mint egy ujjlenyomat vagy írisz-/arcszkenner) +- Valami, ami az Ön birtokában van (biztonsági kulcs vagy azonosítási alkalmazás a telefonján) + +A **kétfaktoros hitelesítés (2FA)** használata további *biztonsági tényezőt* biztosít online számlái számára. A 2FA biztosítja, hogy a számlához való hozzáféréshez nem elegendő pusztán a jelszó megléte. Általában a második tényező egy véletlenszerű hatjegyű kód, ami egy **időzített egyszeri jelszó (TOTP)**, amit egy azonosítási alkalmazással ér el, mint a Google Authenticator vagy Authy. Ez az a tényező, ami az Ön birtokában van, mert a kódot adó mag az Ön eszközén található. + + +
+ Megjegyzés: az SMS-alapú 2FA azonosítás ki van téve a SIM jacking támadásnak, ezért nem biztonságos. A legmagasabb fokú biztonság érdekében használjon olyan szolgáltatást, mint a Google Authenticator vagy az Authy. +
+ + +#### Biztonsági kulcsok {#security-keys} + +A biztonsági kulcs a 2FA egy fejlettebb és biztonságosabb típusa. A biztonsági kulcsok fizikai, hardveralapú hitelesítési eszközök, melyek az azonosítási alkalmazásokként működnek. A biztonsági kulcs használata a legbiztonságosabb mód a 2FA eléréséhez. A kulcsok nagyrésze a FIDO egyetemes második tényező (U2F) szabványt használja. [Ismerje meg a FIDO U2F-t](https://www.yubico.com/authentication-standards/fido-u2f/). + +Tudjon meg többet a 2FA-ról: + + + +### Böngészőbővítmények eltávolítása {#uninstall-browser-extensions} + +A böngészőbővítmények (mint a Chrome-bővítmények vagy Firefox kiegészítő modulok) hasznos funkciókkal egészítik ki a böngészőket, de kockázattal is járnak. A legtöbb ilyen bővítmény kéri, hogy beolvashassa és megváltoztathassa az adatokat, így bármit meg tudnak tenni az eszközön. A Chrome bővítményei automatikusan frissülnek, ezért a korábban ártalmatlan kód később talán rosszindulatú részeket is tartalmazhat. A legtöbb böngészőbővítmény nem próbál meg adatot lopni, de attól még képes rá. + +#### Maradjon biztonságban: {#browser-extension-safety} + +- Csak megbízható forrásból telepítsen bővítményeket +- Szedje le azokat, amelyeket nem használja +- Telepítse a bővítményt lokálisan, így nem fog magától frissülni + +[Bővebben a böngészőbővítmények kockázatáról](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/) + + + +## További olvasnivaló {#further-reading} + +### Webbiztonság {#reading-web-security} + +- [3 millió eszközt érintenek a rosszindulatú Chrome- és Edge-bővítmények](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) – _Dan Goodin_ +- [Hogyan hozzon létre erős jelszót – amit nem felejt el](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) – _AVG_ +- [Mi az a biztonsági kulcs?](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) – _Coinbase_ + +### Kriptobiztonság {#reading-crypto-security} + +- [Védje magát és a pénzeszközeit](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) – _MyCrypto_ +- [Biztonsági problémák az általános kriptokommunikációs szoftverben](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) – _Salus_ +- [Biztonsági útmutató kezdőknek és haladóknak](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) – _MyCrypto_ +- [Kriptobiztonság: jelszavak és azonosítás](https://www.youtube.com/watch?v=m8jlnZuV1i4) – _Andreas M. Antonopoulos_ + +### Csalásfelismerés {#reading-scam-education} + +- [Útmutató: hogyan azonosítsa be a hamis tokeneket](/guides/how-to-id-scam-tokens/) +- [Maradjon biztonságban: általános csalások](https://support.mycrypto.com/staying-safe/common-scams) – _MyCrypto_ +- [A csalások elkerülése](https://bitcoin.org/en/scams) – _Bitcoin.org_ +- [Twitter-beszélgetés a tipikus kripto-adathalász e-mailekről és üzenetekről](https://twitter.com/tayvano_/status/1516225457640787969) – _Taylor Monahan_ + + diff --git a/public/content/translations/hu/09) Learn Pages/zero-knowledge-proofs/index.md b/public/content/translations/hu/09) Learn Pages/zero-knowledge-proofs/index.md new file mode 100644 index 00000000000..3d620f82a68 --- /dev/null +++ b/public/content/translations/hu/09) Learn Pages/zero-knowledge-proofs/index.md @@ -0,0 +1,214 @@ +--- +title: Felfedés nélküli bizonyítás +description: A zero-knowledge bizonyítékok nem technikai bemutatása kezdők számára. +lang: hu +--- + +# Mik azok a zero-knowledge (nullaismeret-alapú) bizonyítékok? {#what-are-zk-proofs} + +A zero-knowledge bizonyíték annak módja, hogy egy állítás érvényességét úgy igazoljuk, hogy magát az állítást nem fedjük fel. A bizonyító próbálja az állítást elfogadtatni, miközben az ellenőrző felelős annak validálásáért. + +A zero-knowledge bizonyíték először egy 1985-ös, „[Az interaktív bizonyítási rendszerek ismereti komplexitása](http://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf)” című tanulmányban jelent meg, mely a zero-knowledge bizonyítékok ma is használt definícióját adja: + +> A nulla tudás protokoll egy olyan módszer, amellyel az egyik fél (a bizonyító) **bizonyíthatja** egy másik félnek (az ellenőrző), **hogy valami igaz, anélkül, hogy bármilyen információt felfedne** az a tény, hogy ez a konkrét állítás igaz. + +A zero-knowledge bizonyítékok az elmúlt években tovább fejlődtek, és ma már számos valódi alkalmazásban használjuk ezeket. + + + +## Miért kellenek a zero-knowledge bizonyítékok? {#why-zero-knowledge-proofs-are-important} + +A zero-knowledge bizonyítékok az alkalmazott kriptográfia egyik áttörése, mivel az egyének számára jobb információbiztonságot ígérnek. Gondoljon bele, hogyan bizonyít egy állítást (pl. „X ország állampolgára vagyok”) egy másik félnek (pl. egy szolgáltatásnyújtónak). Bizonyítékot kell adnia ahhoz, hogy az állítását alátámassza, mint az útlevelét vagy a vezetői engedélyét. + +Ennél azonban jelentős adatvédelmi kockázat áll fenn. A személyazonosításra alkalmas információk (PII), melyeket egy harmadik félnek ad át, központi adatbázisokban vannak tárolva, melyek sebezhetők a támadókkal szemben. Mivel a személyazonosság ellopása kritikus problémává válik, komolyabb adatvédelmi intézkedésekre van szükség a bizalmas információk megosztásánál. + +A nulla tudásalapú bizonyítások megoldják ezt a problémát azáltal, hogy **kiküszöböli az állítások érvényességének bizonyításához szükséges információk felfedését**. A zero-knowledge protokoll az állítást (amit tanúnak nevez) használja bemenetként, hogy egy tömör bizonyítványt állítson ki az érvényességéről. Ez a bizonyíték egy erős garanciát ad, hogy az állítás igaz, de nem tár fel semmit abból, amit ehhez felhasznált. + +A korábbi példánál maradva a nemzetiséget egyedül a zero-knowledge bizonyítékkal kell igazolnia. Az ellenőrző csak azt nézi meg, hogy a bizonyíték bizonyos jellemzői igazak, hogy meggyőződjön az állítás igaz voltáról. + +## A zero-knowledge bizonyítékok alkalmazási területei {#use-cases-for-zero-knowledge-proofs} + +### Anonim fizetések {#anonymous-payments} + +A bankkártyafizetések sokszor láthatók több fél számára is, beleértve a fizetési szolgáltatót, a bankokat és más érdekelteket (pl. kormányzati hatóságok). Míg a pénzügyi felügyeletnek vannak előnyei az illegális tevékenységek feltárásában, közben aláássa a hétköznapi emberek magánéletét. + +A kriptovalutákat arra szánták, hogy a felhasználók privát, egymás közötti (peer-to-peer) tranzakciókat hajthassanak végre. Ugyanakkor a legtöbb kriptovalutás tranzakció nyíltan látható a nyilvános blokkláncokon. A felhasználók személyazonosságai gyakran közvetettek és vagy direkt kapcsolódnak valós azonosságukhoz (pl. a Twitter vagy GitHub profil tartalmazza az ETH címüket), vagy összekapcsolhatók alapvető láncon belüli és kívüli adatok elemzésével. + +Vannak bizonyos privát tokenek, hogy teljesen anonim tranzakciókat lehessen végrehajtani. A privát jelleget védő blokkláncok, mint a Zcash és Monero, elfedik a tranzakciók adatait, mint a küldő/fogadó címe, az eszköz típusa, a mennyiség, az időpont. + +A nulla tudástechnológiát a protokollba beépítve az adatvédelemre fókuszáló [blokklánc](/glossary/#blockchain) hálózatok lehetővé teszik a [csomópontok](/glossary/#node) számára a tranzakciók érvényesítését anélkül, hogy hozzá kellene férniük a tranzakciós adatokhoz. + +**A nulla tudásalapú igazolásokat a nyilvános blokkláncokon folyó tranzakciók anonimizálására is alkalmazzák**. Erre a Tornado Cash a példa, ami egy decentralizált, nem felügyelt szolgáltatás, ami privát tranzakciókat tesz lehetővé az Ethereumon. Ez a megoldás zero-knowledge bizonyítékokat használ, hogy elfedje a tranzakció adatait és pénzügyi titoktartást garantál. Sajnos, mivel ezek tetszőlegesen választható adatvédő eszközök, ezért rögtön illegális tevékenységet sejtetnek. Ennek megoldására a privát jellegű adatok védelme végül alapvetővé kell váljon a nyilvános blokkláncokon. + +### A személyazonosság védelme {#identity-protection} + +A jelenlegi személyazonosságot kezelő rendszerek veszélyeztetik a személyes információkat. A zero-knowledge bizonyítékok segíthetnek az egyéneknek azonosítani magukat, miközben megvédik az adataikat. + +Ezek kiemelten fontosak a [decentralizált személyazonosság](/decentralized-identity/) kontextusában. A decentralizált személyazonosság (vagy független személyazonosság) lehetővé teszi, hogy az egyén kontrollálja a személyes azonosítóihoz való hozzáférést. Az állampolgárság igazolása adóazonosító vagy útlevéladatok felfedése nélkül egy jó példa arra, hogy a zero-knowledge technológia hogyan teszi lehetővé a decentralizált személyazonosság-ellenőrzést. + +### Hitelesítés {#authentication} + +Az online szolgáltatások használatához igazolni kell a személyazonosságot és a hozzáférési jogot az adott platformhoz. Ez gyakran az olyan személyes adatok megadásával történik, mint név, e-mail-cím, születési dátum stb. Emellett hosszú jelszavakat kell megjegyezni, de a hozzáférés akár el is veszhet. + +A zero-knowledge bizonyítékok ugyanakkor leegyszerűsíthetik az azonosítást a platformok és a felhasználók számára is. Amint a ZK-bizonyíték elkészült a nyilvános inputok (pl. a platformtagságot tanúsító adat) és privát inputok (pl. a személy adatai) használatával, akkor a felhasználó egyszerűen azzal igazolja magát, amikor a szolgáltatást használni akarja. Ez javítja a felhasználói tapasztalatot, illetve mentesíti a szervezeteket, hogy nagy adag személyes információt tároljanak. + +### Igazolható kalkuláció {#verifiable-computation} + +Az igazolható kalkuláció egy másik alkalmazása a ZK technológiának, hogy fejlessze a blokklánc kialakítását. Az igazolható kalkuláció által a kalkulációt másik entitás is végezheti, miközben az igazolható eredményeket fenntartjuk. A másik fél átadja az eredményeket a bizonyítékkal együtt, ami igazolja, hogy a program megfelelően futott. + +Az ellenőrizhető számítások **kritikusak a blokkláncok feldolgozási sebességének javításához** a biztonság csökkentése nélkül. Ennek megértéséhez ismerni kell az Ethereum skálázási megoldásai közötti eltéréseket. + +[A láncon belüli skálázási megoldások](/developers/docs/scaling/#on-chain-scaling), mint amilyen a párhuzamos futtatás (sharding), nagy mértékű módosítást igényelnek a blokklánc alaprétegén. Ez a megközelítés ugyanakkor nagyon komplex, az bevezetés hibái pedig alááshatják az Ethereum biztonsági modelljét. + +[A láncon kívüli skálázási megoldásokhoz](/developers/docs/scaling/#off-chain-scaling) nem kell az Ethereum protokollt újratervezni. Ehelyett egy kiszervezett kalkulációs modellre támaszkodnak, hogy fejlesszék a tranzakcióátvitelt az Ethereum alaprétegen. + +Ez a gyakorlatban a következőképpen működik: + +- Az Ethereum nem dolgozza fel a tranzakciókat egyesével, hanem kirakja a végrehajtást egy másik láncra. + +- A tranzakciók feldolgozása után a másik lánc visszaküldi az eredményt, ami az Ethereum-státusz része lesz. + +Az Ethereumnak tehát nem kell feldolgozni semmit, csak az eredményeket kell beilleszteni. Ez csökkenti a hálózat leterheltségét és fejleszti a tranzakciós sebességet (a láncon kívüli protokoll gyorsabb végrehajtásra van optimalizálva). + +A láncnak szüksége van arra, hogy validálni tudja a láncon kívüli tranzakciókat anélkül, hogy újra feldolgozná azokat, különben a külső feldolgozás értéke elveszik. + +Itt jön a képbe az igazolható kalkuláció. Amikor egy csomópont feldolgoz egy tranzakciót az Ethereumon kívül, akkor egy zero-knowledge bizonyítékot ad, hogy bizonyítsa a láncon kívüli végrehajtás helyességét. Ez a bizonyíték ([érvényességi bizonyíték](/glossary/#validity-proof)) garantálja, hogy a tranzakció érvényes, így az Ethereum hozzáadhatja a lánc státuszához – anélkül, hogy bárki kifogásolhatná azt. + +[A zero-knowledge rollupok](/developers/docs/scaling/zk-rollups) és [a validiumok](/developers/docs/scaling/validium/) két olyan láncon kívüli, skálázási megoldás, amely érvényességi bizonyítékot ad, hogy a skálázás biztonságos legyen. Ezek a protokollok ezernyi tranzakciót dolgoznak fel láncon kívül és bizonyítékot adnak az Ethereumnak ellenőrzési célból. Amint a bizonyíték ellenőrzésre kerül, az eredményeket azonnal be lehet tenni a láncba, így az Ethereum több tranzakciót tud kezelni anélkül, hogy az alapréteg számítási kapacitását növelni kellene. + +### A vesztegetés és összejátszás lehetőségének csökkentése a láncon belüli szavazásnál {#secure-blockchain-voting} + +A blokklánc szavazási sémái számos kedvező vonással bírnak: teljesen auditálható, nem támadható, ellenáll a cenzúrának és nem kötik földrajzi megszorítások. De még ezek sem immunisak az **összejátszás** problémájára. + +Az összejátszás definíciója a nyílt verseny redukálása megtévesztéssel, csalással és félrevezetéssel, ami felöltheti a vesztegetés formáját, mellyel egy rosszhiszemű szereplő befolyásolni akar egy szavazást. Például Alice kaphat egy összeget Bobtól azért, hogy szavazzon a `B opcióra` egy titkos szavazáson, miközben ő maga az `A opciót` preferálja. + +A vesztegetés és összejátszás behatárolja a hatékonyságát azoknak a folyamatoknak, melyek a szavazást használják jelzőmechanizmusra (főleg amikor a felhasználók bizonyítani tudják, hogyan szavaztak). Ennek komoly következményei vannak, főleg ahol véges erőforrást allokálnak a szavazás révén. + +Például a [kvadratikus finanszírozási mechanizmus](https://www.radicalxchange.org/concepts/plural-funding/) adományokon alapszik, hogy mérje bizonyos opciók támogatottságát a különféle közjóra törekvő projektek között. Minden adomány szavazatként működik egy adott projektre, ahol a több szavazattal bíró projektek nagyobb részt kapnak a finanszírozási alapból. + +A láncon belüli szavazás kiteszi a kvadratikus finanszírozást az összejátszás kockázatának: a blokklánctranzakciók nyilvánosak, így a vesztegetők meg tudják nézni, hogy a megvesztegetett hogyan szavazott. Így a kvadratikus finanszírozás nem lesz hatékony módja a forráselosztásnak a közösség aggregált preferenciái alapján. + +Szerencsére újabb megoldások, mint amilyen a MACI (Minimum összejátszás-ellenes infrastruktúra/Minimum Anti-Collusion Infrastructure), zero-knowledge bizonyítékokat használ, hogy a láncon belüli szavazás ellenálló legyen a vesztegetéssel és összejátszással szemben. A MACI okosszerződésekből és szkriptekből áll, és lehetővé teszi egy központi adminisztrátor (a koordinátor) számára, hogy aggregálja a szavazatokat és kiszámolja az eredményeket, _anélkül_, hogy felfedné az egyéni szavazatok tartalmát. Még így is bizonyítani lehet, hogy a szavazatokat megfelelően számolták össze, illetve egy adott illető részt vette-e a szavazáson. + +#### Hogyan működik a MACI a zero-knowledge bizonyítékokkal? {#how-maci-works-with-zk-proofs} + +Először a koordinátor aktiválja a MACI szerződést az Ethereumon, majd a felhasználók jelentkezhetnek a szavazásra (regisztrálják a nyilvános kulcsukat az okosszerződésben). A felhasználók úgy szavaznak, hogy a nyilvános kulcsukkal titkosított üzenetet küldenek az okosszerződésnek (az érvényes szavazatot a legfrissebb nyilvános kulccsal kell aláírni, egyéb kritériumok mellett). Majd a koordinátor feldolgozza az összes üzenetet a szavazás lezárultával, megszámlálja azokat, és igazolja az eredményt a láncon. + +A MACI-ban a zero-knowledge bizonyítékok biztosítják a kalkuláció helyességét, így a koordinátor nem tudja azokat helytelenül feldolgozni és összesíteni. Ehhez a koordinátornak ZK-SNARK bizonyítékokat kell generálnia, hogy igazolja a) minden üzenetet megfelelően feldolgozott; b) a végső eredmény egyezik a _valid_ szavazatok számával. + +Így a MACI még a szavazatok felhasználónkénti megosztása nélkül is garantálja a számlálási folyamat során kiszámított eredmények integritását. Ez csökkenti az alapvető összejátszási sémák hatékonyságát. Megvizsgálhatjuk ezt a lehetőséget, ha felhasználjuk az előző példát, amikor Bob megvesztegette Alice-t, hogy egy opció mellett szavazzon: + +- Alice szavazásra jelentkezik, elküldve a nyilvános kulcsát az okosszerződésnek. +- Alice beleegyezik, hogy a `B opcióra` szavaz, és ezért Bob fizetni fog neki. +- Alice a `B opcióra` szavaz. +- Alice titokban küld egy titkosított tranzakciót, hogy megváltoztassa a személyazonosságához tartozó nyilvános kulcsot. +- Alice küld egy másik titkosított üzenetet az okosszerződésnek, hogy az `A opcióra` szavaz, az új nyilvános kulcsot használva. +- Alice megmutatja Bobnak a tranzakciót, melyben a `B opcióra` szavazott (ami érvénytelen, mert az a nyilvános kulcs már nem kapcsolódik Alice személyazonosságához a rendszerben) +- Miközben az üzeneteket dolgozza fel a koordinátor, kihagyja Alice szavazatát a `B opcióra` és beleszámolja azt, amit az `A opcióra` adott le. Így Bob próbálkozása, hogy összejátsszon Alice-szel és manipulálja a láncon belüli szavazást, kudarcot vallott. + +A MACI használatához ugyanakkor _muszáj_ megbízni a koordinátorban, hogy nem játszik össze másokkal vagy vesztegeti meg a szavazókat. A koordinátor képes feloldani az üzenetek titkosítását (ez kell a bizonyíték előállításához), így be tudja azonosítani, hogy ki hogyan szavazott. + +Ha a koordinátor jóhiszeműen jár el, akkor a MACI egy kiváló eszköz arra, hogy garantálja a láncon belüli szavazás szentesítését. Ez megmagyarázza a népszerűségét a kvadratikus finanszírozási alkalmazásokban (mint amilyen a [clr.fund](https://clr.fund/#/about/maci)), ami nagy mértékben függ az egyének szavazásának integritásától. + +[Bővebben a MACI-ról](https://privacy-scaling-explorations.github.io/maci/). + +## Hogyan működik a zero-knowledge bizonyíték? {#how-do-zero-knowledge-proofs-work} + +A zero-knowledge bizonyíték által úgy igazolódik egy állítás igazsága, hogy abból bármi kiderülne vagy abból a módból, ahogy az igazolva lett. Ehhez a zero-knowledge protokollok olyan algoritmusokat használnak, melyek adatokat dolgoznak fel és válaszként igaz vagy hamis eredményt adnak. + +A zero-knowledge protokollnak a következő kritériumoknak kell megfelelniük: + +1. **Teljesség**: ha az input érvényes, akkor a zero-knowledge protokoll válasza mindig az, hogy „igaz”. Tehát ha az állítás igaz, a bizonyító és az ellenőrző jóhiszeműen viselkedik, akkor a bizonyítékot el lehet fogadni. + +2. **Megbízhatóság**: ha az input érvénytelen, akkor elméletileg lehetetlen átverni a zero-knowledge protokollt, hogy azt „igaznak” vegye. Így a rosszhiszemű bizonyító nem tudja átverni a jóhiszemű ellenőrzőt, hogy elhiggye az érvénytelen állításról, hogy az érvényes (csak egy nagyon kicsi valószínűséggel). + +3. **Zero-knowledge**: Az ellenőrző semmit sem tud meg az állításról, csak azt, hogy érvényes vagy érvénytelen-e (nulla ismerete lesz az állításról). Ez megakadályozza, hogy az ellenőrző kinyerje az eredeti inputot (az állítás tartalmát) a bizonyítékból. + +Alapformájában a zero-knowledge bizonyíték három elemből áll: **tanú**, **kihívás** és **válasz**. + +- **Tanú**: A zero-knowledge bizonyítékkal a bizonyító valamilyen titkos információ ismeretét akarja bizonyítani. A titkos információ a bizonyíték „tanúja”, és az a tény, hogy a bizonyítónak feltételezett módon ismerete van erről a tanúról, egy sor kérdést generál, melyet csak az tud megválaszolni, aki ismeri az információt. A bizonyító a bizonyítási eljárást azzal kezdi, hogy véletlenszerűen választ egy kérdést, kikalkulálja a választ és elküldi az ellenőrzőnek. + +- **Kihívás**: Az ellenőrző véletlenszerűen választ egy kérdést a sorozatból, és megkéri a bizonyítót, hogy feleljen rá. + +- **Válasz**: A bizonyító elfogadja a kérdést, kikalkulálja a választ, és elküldi az ellenőrzőnek. A bizonyító válasza lehetővé teszi, hogy az ellenőrző meggyőződjön arról, az előbbi tényleg hozzáfér a tanúhoz. Ahhoz, hogy meggyőződjön arról, a bizonyító nem csak vakon tippel és véletlenül adta meg a jó választ, még több kérdést tesz fel. Ezt a folyamatot ismételve annak a valószínűsége, hogy a bizonyítónak nincs is ismerete a tanúról, szignifikánsan lecsökken, míg az ellenőrző elégedetté válik. + +A fenti egy interaktív zero-knowledge bizonyítékstruktúrát ír le. A korai zero-knowledge protokollok interaktív igazolást használtak, ami oda-vissza kommunikációt igényelt a bizonyító és az ellenőrző között. + +Ennek illusztrálására egy jó példa Jean-Jacques Quisquater híres [Ali Baba barlangtörténete](https://en.wikipedia.org/wiki/Zero-knowledge_proof#The_Ali_Baba_cave). A történetben Peggy (a bizonyító) bizonyítani akarja Victornak (az ellenőrzőnek), hogy tudja a titkos jelszót, ami kinyitja a varázsajtót, de nem akarja elárulni, mi az. + +### Nem interaktív zero-knowledge bizonyítékok {#non-interactive-zero-knowledge-proofs} + +Miközben forradalmi, az interaktív bizonyítás hasznossága behatárolt, mert a két félnek elérhetőnek kell lennie és többször kell kapcsolatba lépniük. Még akkor is, ha az ellenőrző meggyőződött a bizonyító őszinteségéről, a bizonyíték ekkor még nem lesz elérhető a független ellenőrzésre (egy új bizonyítékot kell küldeni, ami egy újabb üzenetváltás). + +Ennek megoldására Manuel Blum, Paul Feldman és Silvio Micali az első [nem interaktív zero-knowledge bizonyítékot](https://dl.acm.org/doi/10.1145/62212.62222) javasolta, ahol a bizonyító és az ellenőrző egy megosztott kulccsal rendelkezik. Ez lehetővé teszi a bizonyítónak, hogy az információ (a tanú) ismeretét úgy bizonyítsa, hogy nem adja ki azt. + +Az interaktívhoz képest itt csak egy kommunikáció történik a felek (bizonyító és ellenőrző) között. A bizonyító a titkos információt átadja egy speciális algoritmusnak, hogy az kikalkulálja a zero-knowledge bizonyítékot. Ezt elküldi az ellenőrzőnek, aki egy másik algoritmussal ellenőrzi azt, hogy a bizonyító tényleg ismeri a titkot. + +A nem interaktív bizonyítás lecsökkenti a szükséges kommunikációt, így a ZK-bizonyíték sokkal hatékonyabb. Sőt, a bizonyíték létrehozásával az mindenkinek elérhetővé válik (akinek van megosztott kulcsa és ellenőrző algoritmusa) ellenőrzésre. + +A nem interaktív bizonyítékok áttörést hoztak a ZK technológiának és a ma létező bizonyítórendszerek fejlesztését hozták el. Az alábbiakban áttekintjük ezeket a bizonyítéktípusokat: + +### A zero-knowledge bizonyítékok típusai {#types-of-zero-knowledge-proofs} + +#### ZK-SNARK-ok {#zk-snarks} + +ZK-SNARK a rövidítés a **zero-knowledge tömörített nem interaktív érv ismeretre (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge)**. A ZK-SNARK protokoll a következő jellemzőkkel bír: + +- **Zero-knowledge**: Az ellenőrző az állítás integritását úgy tudja ellenőrizni, hogy nem tud róla semmit. Csak arról van tudomása, hogy az állítás igaz vagy hamis. + +- **Tömörített**: A zero-knowledge bizonyíték kisebb a tanúnál és gyorsan ellenőrizhető. + +- **Nem interaktív**: A bizonyító és az ellenőrző csak egyszer kommunikál, miközben az interaktív bizonyítéknál több körben is egyeztetnek. + +- **Érv**: A bizonyíték kielégíti a megbízhatósági követelményt, így a csalás rendkívül valószínűtlen. + +- **Ismeret**: A bizonyíték nem rakható össze a titkos információ (tanú) ismerete nélkül. Nehéz vagy egyenesen lehetetlen egy bizonyító számára kikalkulálni egy érvényes ZK-bizonyítékot, ha nem ismeri a tanút. + +A korábban említett megosztott kulcs nyilvános paraméterekre hivatkozik, amelyekben a bizonyító és az ellenőrző megegyezik, hogy ezeket használja a bizonyíték létrehozásában és ellenőrzésében. A nyilvános paraméterek létrehozása (Common Reference String/CRS) egy kényes művelet, mivel a protokoll biztonsága múlik rajta. Ha a CRS-t létrehozó entrópia/véletlenszerűség egy rosszhiszemű bizonyító kezébe kerül, akkor hamis bizonyítékokat tud kalkulálni vele. + +[A többrésztvevős kalkuláció (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation) ezt a kockázatot csökkenti a nyilvános paraméterek létrehozása kapcsán. Több résztvevő van jelen egy [bizalmat igénylő összetételi ceremónián](https://zkproof.org/2021/06/30/setup-ceremonies/amp/), ahol mindenki hozzátesz véletlenszerű értékeket a CRS létrehozásához. Amíg egy jóhiszemű fél megsemmisíti az entrópia saját részét (így nem lehet teljesen összeállítani a sorozatot), addig a ZK-SNARK protokoll megőrzi a kalkulációs megbízhatóságát. + +A bizalmat igénylő összetétel esetén a felhasználónak bíznia kell a résztvevőkben, amikor azok létrehozzák a paramétereket. Ugyanakkor a ZK-STARK-ok kifejlesztése lehetővé tette a bizonyító protokolloknak, hogy bizalomigénytől mentes felállásban is működjenek. + +#### ZK-STARK-ok {#zk-starks} + +ZK-STARK a rövidítés a **zero-knowledge skálázható transzparens érv ismeretre (Zero-Knowledge Scalable Transparent Argument of Knowledge)**. A ZK-STARK-ok hasonlítanak a ZK-SNARK-okra, kivéve, hogy: + +- **Skálázható**: ZK-STARK gyorsabb, mint a ZK-SNARK a bizonyíték létrehozásában és ellenőrzésében, amikor a tanú nagyobb méretű. A STARK bizonyítékoknál a bizonyítás és az ellenőrzés ideje csak enyhén növekszik, ahogy a tanú mérete nő (míg a SNARK esetén a növekedés lineáris). + +- **Transzparens**: ZK-STARK nyilvánosan ellenőrizhető véletlenszerűségre támaszkodik, hogy létrehozza a nyilvános paramétereket a bizonyításhoz és az ellenőrzéshez, nem egy bizalmat igénylő összetételre. Ezért sokkal átláthatóbbak a ZK-SNARK-okhoz képest. + +ZK-STARK-ok nagyobb bizonyítékokat készítenek, mint a ZK-SNARK-ok, ezért magasabb az ellenőrzési költség. Ugyanakkor bizonyos esetekben (mint nagy adathalmazok bizonyítása) a ZK-STARK-ok mégis költséghatékonyabbak a ZK-SNARK-okhoz képest. + +## A zero-knowledge bizonyítékok hátulütői {#drawbacks-of-using-zero-knowledge-proofs} + +### Hardverköltségek {#hardware-costs} + +A zero-knowledge bizonyítékok generálása nagyon összetett kalkulációt igényel, amit specializált gépeken lehet a legjobban elvégezni. Mivel ezek drágák, ezért nem elérhetők a hétköznapi emberek számára. Emellett a technológiát használó alkalmazásoknak ezt a költséget bele kell kalkulálniuk az áraikba, így megnövelik a felhasználók költségeit is. + +### A bizonyíték ellenőrzésének költsége {#proof-verification-costs} + +A bizonyítékok ellenőrzése is összetett kalkulációt igényel és megnöveli a technológia bevezetésének költségét az alkalmazásokban. Ez a költség még inkább releváns a bizonyítási kalkuláció kontextusában. Például a ZK-rollupok kb. 500 000 gázt fizetnek, hogy egyetlen ZK-SNARK bizonyítékot ellenőrizzenek az Ethereumon, a ZK-STARK-ok pedig még ennél is többe kerülnek. + +### Bizalmi feltételezések {#trust-assumptions} + +A ZK-SNARK-ban a CRS (nyilvános paraméterek) egyszer kerül létrehozásra és azt újrahasználhatják a felek, akik részt akarnak venni a zero-knowledge protokollban. A nyilvános paramétereket egy bizalmat igénylő összetételi ceremónia révén hozzák létre, ahol a résztvevőkről feltételezzük, hogy jóhiszeműek. + +A felhasználók azonban nem tudják ellenőrizni a résztvevők jóhiszeműségét, meg kell bízniuk a fejlesztőkben. A ZK-STARK-ok mentesek az ilyen bizalomigénytől, mivel a véletlenszerűség nyilvánosan igazolható. Eközben a kutatók dolgoznak a ZK-SNARK-ok bizalomigénynélküli verzióján, hogy növeljék a bizonyítási mechanizmus biztonságát. + +### A kvantumszámítógép fenyegetései {#quantum-computing-threats} + +A ZK-SNARK elliptikus görbe kriptográfiát használ a titkosításhoz. Míg az elliptikus görbe diszkrét logaritmus problémája egyelőre megfejthetetlennek tekinthető, a kvantumszámítógépek fejlődése a jövőben megtörheti ezt a biztonsági modellt. + +A ZK-STARK immunis a kvantumszámítógépek fenyegetésére, mert csak ütközésálló hash-függvényeket használ a biztonsága érdekében. Ezt az algoritmust nehezebb feltörni a kvantumszámítógépnek, nem úgy, mint a nyilvános-privát kulcs párosát, melyet az elliptikusgörbe-alapú kriptográfia használ. + +## További olvasnivaló {#further-reading} + +- [A zero-knowledge bizonyítékok alkalmazási területeinek áttekintése](https://pse.dev/projects) — _Privacy and Scaling Explorations Team_ +- [A SNARK-ok, a STARK-ok és a rekurzív SNARK-ok összehasonlítása](https://www.alchemy.com/overviews/snarks-vs-starks) — _Alchemy Overviews_ +- [Zero-Knowledge bizonyíték: az adatbiztonság javítása a blokkláncon](https://www.altoros.com/blog/zero-knowledge-proof-improving-privacy-for-a-blockchain/) — _Dmitry Lavrenov_ +- [zk-SNARK-ok — Egy valós zero-knowledge példa és mélyebb elemzése](https://medium.com/coinmonks/zk-snarks-a-realistic-zero-knowledge-example-and-deep-dive-c5e6eaa7131c) — _Adam Luciano_ +- [ZK-STARK-ok — Igazolható bizalom létrehozása, még a kvantumszámítógépekkel szemben is](https://medium.com/coinmonks/zk-starks-create-verifiable-trust-even-against-quantum-computers-dd9c6a2bb13d) — _Adam Luciano_ +- [Egy hozzávetőleges áttekintés, hogyan lehetségesek a zk-SNARK-ok](https://vitalik.eth.limo/general/2021/01/26/snarks.html) — _Vitalik Buterin_ +- [A Zero-knowledge bizonyítékok (ZKP) megváltoztatják a szuverén identitás területét](https://frankiefab.hashnode.dev/why-zero-knowledge-proofs-zkps-is-a-game-changer-for-self-sovereign-identity) — _Franklin Ohaegbulam_ + diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md new file mode 100644 index 00000000000..de9e1a61daf --- /dev/null +++ b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md @@ -0,0 +1,73 @@ +--- +title: Hogyan lehet Ethereum számlát „létrehozni” +description: Részletes útmutató az Ethereum-számla létrehozásától egy tárca segítségével. +lang: hu +--- + +# Hogyan lehet Ethereum számlát létrehozni + +**Bárki nyithat Ethereum-számlát, bármikor és ingyenesen.** Ehhez csak egy kriptotárca alkalmazást kell telepítenie. A tárca egy olyan alkalmazás, amely létrehozza és kezeli az Ethereum-számlát. Tranzakciókat tud küldeni, megnézheti az egyenlegeket és kapcsolódhat a többi alkalmazással, melyek az Ethereumra épültek. + +A tárcával azonnal részt vehet tokenátváltásban, játékban és [NFT](/glossary/#nft)-piactereken is megjelenthet. Nincs szükség arra, hogy egyesével regisztráljon ezekre, mert egy számlával használhatja az összes Ethereumra épített alkalmazást. + +## 1. lépés: A tárca kiválasztása + +A tárca egy olyan alkalmazás, amely segíti az Ethereum-számla kezelését. Tucatnyi különböző tárca közül választhat: mobil-, asztali alkalmazásokkal vagy akár böngészőbővítményekkel működő tárcák is léteznek. + + + + A tárcák listája + + +Ha Ön most ismerkedik ezzel a területtel, akkor választhatja a „Kezdő a kripto világában” szűrőt a „Tárca keresése” oldalon, hogy olyan termékek közül választhasson, amelyek kifejezetten a kezdők számára fontos funkciókat kínálni. + +![Szűrési lehetőségek a „Tárca keresése” oldalon](./wallet-box.png) + +Egyéb profilszűrők is elérhetők, hogy saját igényeire szabhassa a keresést. Íme néhány példa a leggyakrabban használt tárcák közül – mindig vizsgálja meg Ön is az adott szolgáltatást, mielőtt bármilyen szoftvert kiválaszt. + +## 2. lépés: A tárcaalkalmazás letöltése és telepítése + +Miután kiválasztotta a tárcát, a hivatalos webhelyéről vagy az alkalmazás-áruházból töltse le és telepítse azt. Mindegyiknek ingyenesnek kell lennie. + +## 3. lépés: Nyissa meg az alkalmazást, és hozza létre Ethereum-fiókját + +A tárca első megnyitásakor a rendszer megkérdezheti, hogy egy új számlát kíván létrehozni vagy egy meglévőt szeretne importálni. Válassza az új számla létrehozása lehetőséget. **Ennél a lépésnél állítja fel a tárcaszoftver az Ön Ethereum számláját.** + +## 4. lépés: Visszaállítási kulcsmondat eltárolása + +Néhány alkalmazás arra kéri Önt, hogy tároljon el egy titkos kulcsmondatot („kulcskifejezés” vagy „mnemonika”). Rendkívül fontos, hogy ezt a kulcsmondatot biztonságban tartsa! A kulcsmondat hozza létre az Ethereum-számlát és tranzakciók végrehajtására használható. + +**Aki a kulcsmondatot birtokolja, az rendelkezik kontrollal a pénzeszközei felett.** Soha ne ossza meg senkivel! A kulcsmondat 12–24 véletlenszerűen kiválasztott szót tartalmaz (melyek sorrendje fontos). + +
+ +
A tárca elkészült?
Tanulja meg használni azt.
+ + Hogyan használja a tárcát + + +
+ +Érdeklik további útmutatók? Tekintse meg a [Részletes útmutatókat](/guides/) + +## Gyakran ismételt kérdések + +### A tárcám és az Ethereum számlám ugyanaz? + +Nem. A tárca egy olyan eszköz, amely segít kezelni a számlát. Egy tárca több számlához is hozzáférést biztosíthat, és egy számlát több tárcából is el lehet érni. A kulcsmondat révén lehet számlákat létrehozni és felhatalmazást adni a tárcaalkalmazásnak, hogy az kezelje a pénzeszközöket. + +### Tudok küldeni Bitcoint Ethereum-számlára, vagy ethert Bitcoin-címre? + +Nem, ez nem lehetséges. A Bitcoin és az ether két teljesen elkülönült hálózaton létezik (azaz különálló blokkláncok), saját könyveléssel és címformátummal. Számos kezdeményezés volt, amellyel megpróbálták áthidalni e két hálózatot, melyek közül jelenleg a legaktívabb a [becsomagolt bitcoin vagy WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). Mivel a WBTC egy felügyeleti megoldást (egy csoport irányít bizonyos kritikus funkciókat), ezért itt csak információs céllal szerepel. + +### Ha rendelkezek ETH-címmel, akkor ugyanazt a címet más blokkláncokon is használhatom? + +Ugyanazt a [címet](/glossary/#address) használhatja minden olyan blokkláncon, amely az Ethereumhoz hasonló mögöttes szoftvert használ („EVM-kompatibilis”). Ez a [lista](https://chainlist.org/) megmutatja, hogy melyik blokkláncokon működik ugyanaz a cím. Néhány blokklánc, mint a Bitcoin, teljesen más hálózati szabályok alapján üzemel, ezért ott egy másik címre van szükség, amely más formátummal is bír. Ha okosszerződéses tárcával rendelkezik, akkor a terméktájékoztatóból kiderül, hogy melyik blokkláncokat támogatja, mivel ezek korlátozottabb, de biztonságosabb területen működnek. + +### A tárcám biztonságosabb, mint a pénzeszközeimet a tőzsdén tartani? + +A saját tárca azt jelenti, hogy Ön felelősséget vállal a pénzeszközeinek biztonságáért. Sajnos számtalan esetben omlott már össze tőzsde, elveszítve a vevők pénzét. A saját tárca (a kulcsmondattal együtt) csökkenti annak kockázatát, hogy egy másik entitásra kell bízni az eszközök felügyeletét. Ugyanakkor Önnek biztonságba kell helyeznie a kulcsait, elkerülni a csalásokat, nem szabad véletlenül jóváhagynia tranzakciót vagy feltárni a kulcsokat valaki előtt, hamis weboldalakat használni vagy hasonló kockázatot vállalni. A kockázatok és hasznok különböznek. + +### Ha elvesztettem a mobil/hardver tárcámat, akkor ugyanazt a tárcaalkalmazást használjam, hogy visszaszerezzem a pénzeszközeimet? + +Nem feltétlen, más tárcát is használhat. Amíg tudja a kulcsmondatot, bármelyik tárcába beteheti azt és visszaállítja a számláját. Ügyeljen arra, hogy ne kapcsolódjon az internethez, amikor visszaállítja a tárcáját, nehogy véletlenül kiszivárogjon a kulcsmondata. Az elveszett pénzeszközöket gyakran nem lehet visszaszerezni a kulcsmondat nélkül. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md new file mode 100644 index 00000000000..bd0c1958301 --- /dev/null +++ b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md @@ -0,0 +1,97 @@ +--- +title: Hogyan lehet felismerni a valótlan tokeneket +description: A valótlan tokenek felismerése, hogyan tűnnek legitimnek, és hogyan lehet elkerülni őket. +lang: hu +--- + +# Hogyan lehet felismerni a valótlan tokeneket {#identify-scam-tokens} + +Az Ethereum egyik leggyakoribb felhasználási módja, hogy egy csoport létrehoz egy kereskedhető tokent, bizonyos értelemben saját valutát. Ezek a tokenek jellemzően a [ERC-20](/developers/docs/standards/tokens/erc-20/)-szabványt követik. Ahol legitim alkalmazási területek vannak, melyek értéket teremtenek, mindig megjelennek a csalók is, hogy ezt az értéket megszerezzék maguknak. + +Kétféle módon próbálhatják Önt megtéveszteni: + +- **Egy valótlan tokent adnak el**, ami hasonlít az eredetire, melyet meg szeretne vásárolni, de a csalók állították ki és nem ér semmit sem. +- **Ráveszik Önt, hogy rossz tranzakciókat írjon alá**, általában úgy, hogy a saját felhasználói felületükre vezetik át Önt. Megpróbálhatják rávenni, hogy a szerződésüknek adjon hozzáférést az ERC-20 tokenjeihez, bizalmas információkat feltárva, amelyekkel elérik az Ön eszközeit stb. Ezek a hamis honlapok szinte tökéletes másai az eredetinek, de rejtett trükkökkel. + +A hamis tokenek illusztrálása végett, és hogyan lehet beazonosítani azokat, megnézünk egy példát: [`wARB`](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82). Ez a token megpróbál úgy kinézni, mint a valós [`ARB`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1) token. + + + +Az Arbitrum egy olyan szervezet, mely optimista rollupokat fejleszt és kezel. Kezdetben az Arbitrum egy profitorientált vállalatként működött, de aztán decentralizálta magát. Ennek részeként kibocsátott egy irányítási tokent, amivel kereskedni lehet. + + + + + +Az Ethereumon létezik egy konvenció, hogy a nem ERC-20-szabványnak megfelelő tokeneknek egy becsomagolt (wrapped) verziót készítenek, melynek a neve w-vel kezdőik. Például itt van a wBTC a bitcoinhoz és a wETH az etherhez. + +Nincs értelme egy olyan ERC-20 token becsomagolt változatát létrehozni, ami már az Ethereumon van, de a csalók a kinézetre hagyatkoznak, nem a mögöttes valóságra. + + + +## Hogyan működnek a hamis tokenek? {#how-do-scam-tokens-work} + +Az Ethereum lényege a decentralizáció. Emiatt nincs központi hatóság, amely elkobozná bárki eszközeit vagy megakadályozná, hogy egy okosszerződést hozzon létre. De ez azt is jelenti, hogy a csalók is képesek bármilyen okosszerződést létrehozni. + + + +Az okosszerződések olyan programok, amelyek az Ethereum-blokkláncon futnak. Minden ERC-20 token egy okosszerződéként van létrehozva. + + + +Specifikusan, az Arbitrum készített egy szerződést, amely az `ARB` szimbólumot használja. De ez nem akadályozza meg a többi embert, hogy egy szerződést készítsenek ugyanezzel a szimbólummal vagy egy hasonlóval. Aki ezt a szerződést megírja, be kell állítsa, hogy az mit fog csinálni. + +## Valósnak tűnnek {#appearing-legitimate} + +Számos trükk van, amit a hamis tokenek létrehozói képesek megtenni, hogy valósnak tüntessék azt fel. + +- **A valós nevet és szimbólumot használják**. Az ERC-20 szerződések viselhetik ugyanazt a szimbólumot és nevet, mint más ERC-20 szerződések. Ezekre az információkra nem lehet a biztonságot alapozni. + +- **A valós kibocsátókat használják**. A hamis tokenek gyakran jelentős összegeket dobnak be olyan címekre, amelyek nagy valószínűséggel az eredeti token valódi kibocsátói. + + Térjünk vissza a `wARB` példájához. [Nagyjából a tokenek 16%-a](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82?a=0x1c8db745abe3c8162119b9ef2c13864cd1fdd72f) egy olyan címen található, melynek nyilvános neve [Arbitrum Foundation: Deployer](https://etherscan.io/address/0x1c8db745abe3c8162119b9ef2c13864cd1fdd72f). Ez _nem_ egy hamis cím, ez tényleg az a cím, amely [bevezette a valódi ARB-szerződést az Ethereum főhálózatán](https://etherscan.io/tx/0x242b50ab4fe9896cb0439cfe6e2321d23feede7eeceb31aa2dbb46fc06ed2670). + + Mivel egy cím ERC-20-egyenlege része az ERC-20-szerződés tárhelyének, ezért az meghatározható a szerződés alapján, attól függően, hogy a szerződés fejlesztője mit kíván. A szerződés megakadályozhatja a további átadást is, ezért a valós felhasználók nem tudnak megszabadulni ezektől a hamis tokenektől. + +- **A valós átutalást használják**. _A valós kibocsátók nem fizetnének egy hamis token átküldéséért, ezért ezek a transzferek valósak, ugye?_ **Nem**. `A transzfer` is az ERC-20-szerződés szerint megy. A csalók könnyedén le tudják programozni, hogy így viselkedjen. + +## Hamis weboldalak {#websites} + +A csalók nagyon meggyőző weboldalakat is készíthetnek, amelyek néha az eredeti pontos másai, azonos kinézettel, de mégis apró trükkökkel. Például a valósnak tűnő hivatkozások, amelyek elirányítják a felhasználót hamis oldalakra, vagy valótlan információk, amelyek elkérik a felhasználók kulcsait vagy a támadók címére küldetnek pénzeszközöket. + +A legjobb, ha mindig megvizsgálja a weboldal címét, illetve a hiteles oldalakat elmenti a könyvjelzők közé. Így a valódi oldalra lép be anélkül, hogy félreírná azt vagy külső hivatkozásra támaszkodna. + +## Hogyan tudja Ön is megvédeni magát? {#protect-yourself} + +1. **Ellenőrizze a szerződés címét**. A valódi tokenek valódi szervezetektől érkeznek, amelyek címét meg lehet találni a szervezet honlapján. Például [az `ARB` esetében itt találja a valódi címeket](https://docs.arbitrum.foundation/deployment-addresses#token). + +2. **A valódi tokenek likviditással bírnak**. A likviditási alap méretét meg tudja nézni a [Uniswap](https://uniswap.org/) oldalán, ami az egyik legelterjedtebb tokenváltó protokoll. Ez a protokoll úgy működik, hogy likviditási alapokat hoz létre, amelybe minden befektető letétbe helyezi a tokenjeit a kereskedési díjakból származó jövedelemért cserébe. + +A hamis tokeneknek általában kicsi likviditási alapjuk van, ha egyáltalán van ilyen, mivel a csalók nem akarnak valódi eszközöket kockáztatni. Például az `ARB`/`ETH` Uniswap alap körülbelül egy millió dollárt tartalmaz ([nézze meg a jelenlegi összeget](https://info.uniswap.org/#/pools/0x755e5a186f0469583bd2e80d1216e02ab88ec6ca)), és kis összegek adás-vétele nem fogja változtatni az árát: + +![Valódi token vásárlása](./uniswap-real.png) + +De amikor megpróbálja megvenni a hamis tokent, a `wARB`-t, akkor minden vásárlás 90%-kal változtatja az árat: + +![Hamis token vásárlása](./uniswap-scam.png) + +Ez is azt mutatja, hogy a `wARB` nem lehet valódi. + +3. **Nézze meg az Etherscan alkalmazásban**. Számos hamis tokent már beazonosított és jelentett a közösség. Ezek meg vannak [jelölve az Etherscanben](https://info.etherscan.com/etherscan-token-reputation/). Miközben az Etherscan nem egy irányadó igazságforrás (mivel a decentralizált hálózatoknál ez nem lehetséges), mégis az Etherscan által beazonosított tokenek nagy valószínűséggel hamisak. + + ![Hamis token az Etherscanben](./etherscan-scam.png) + +## Következtetés {#conclusion} + +Amíg érték van a világon, addig csalók is lesznek, akik meg akarják azt szerezni, és egy decentralizált világban senki sem fogja megvédeni Önt, kivéve önmaga. Reméljük, hogy az alábbi jellemzők alapján Ön is könnyedén megkülönbözteti a valódi tokent a hamistól: + +- A hamis tokenek valódiakat személyesítenek meg, felhasználva annak nevét, szimbólumát stb. +- A hamis tokenek _nem_ használhatják ugyanazt a szerződési címet. +- A valódi token címét a kibocsátó szervezettől lehet megtudni. +- Ha ez nem sikerül, akkor olyan népszerű, megbízható alkalmazásokat használhat, mint a [Uniswap](https://app.uniswap.org/#/swap) és az[Etherscan](https://etherscan.io/). diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md new file mode 100644 index 00000000000..01ddb6967b8 --- /dev/null +++ b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md @@ -0,0 +1,73 @@ +--- +title: Hogyan vonható vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez +description: Útmutató arról, hogyan vonhatja vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez +lang: hu +--- + +# Hogyan vonható vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez + +Ez az útmutató megtanítja Önnek, hogyan tekintheti meg az összes [intelligens szerződés](/glossary/#smart-contract) listáját, amelyhez hozzáférést biztosított, és hogyan mondhatja fel azokat. + +Néha a rosszhiszemű fejlesztők olyan kiskapukat építenek az okosszerződésekbe, melyek hozzáférést biztosítanak a gyanútlan felhasználók eszközeihez, akik azzal a szerződéssel interakcióba lépnek. Gyakran előfordul, hogy az ilyen platformok engedélyt kérnek a felhasználótól **korlátlan számú token** elköltésére, hogy a jövőben kis mennyiségű [gázt](/glossary/#gas) spóroljanak meg, de ez az megnövekedett kockázat. + +Miután egy platform korlátlan hozzáférési jogokkal rendelkezik egy tokenhez a [pénztárcájában](/glossary/#wallet), akkor is elköltheti ezeket a tokeneket, még akkor is, ha Ön kivette a pénzt a platformjáról a pénztárcájába. A rosszindulatú szereplők még így is hozzáférhetnek az Ön pénzéhez, amit a saját tárcájukba lehívnak, és Ön ezt már nem fogja tudni visszaszerezni. + +Ezt úgy tudja elkerülni, hogy tartózkodik a nem tesztelt új projektek használatától, csak azt hagyja jóvá, amire valóban szüksége van és rendszeresen visszavonja a hozzáféréseket. Tehát hogyan is kell ezt csinálni? + +## 1. lépés: Hozzáférés-visszavonási eszközök használata + +Számos weboldal lehetővé teszi, hogy láthassa és visszavonhassa a címéhez kapcsolódó okosszerződéseket. Látogasson el a weboldalra és kapcsolja azt össze a tárcájával: + +- [Ethallowance](https://ethallowance.com/) (Ethereum) +- [Etherscan](https://etherscan.io/tokenapprovalchecker) (Ethereum) +- [Cointool](https://cointool.app/approve/eth) (több hálózat) +- [Revoke](https://revoke.cash/) (több hálózat) +- [Unrekt](https://app.unrekt.net/) (több hálózat) +- [EverRevoke](https://everrise.com/everrevoke/) (több hálózat) + +## 2. lépés: Összekapcsolás a tárcával + +A weboldalon kattintson a „Tárcához kapcsolás” funkcióra. A weboldalon megjelenik egy, a tárcához kapcsolódásról szóló üzenet. + +Használja ugyanazt a hálózatot a tárcán és a weboldalon. Csak azokat az okosszerződéseket fogja látni, melyek ehhez a hálózathoz kötődnek. Például, az Ethereum-főhálózathoz kapcsolódva csak az Ethereum-szerződéseket látja, a más láncokról (pl. Polygon) származó szerződéseket nem. + +## 3. lépés: A visszavonni kívánt okosszerződés kiválasztása + +Itt az összes szerződést látnia kell, amely hozzáfér az Ön tokenjeihez, illetve azok költési keretének is meg kell jelennie. Válassza ki azt, amelyet le kívánja zárni. + +Ha nem tudja, hogy melyik az, akkor az összeset leválaszthatja. Ez nem okoz problémát, a következő alkalommal, amikor ezekkel a szerződésekkel interakcióba lép, új engedélyt kell adnia azoknak. + +## 4. lépés: Az eszközeihez való hozzáférés lezárása + +A lezárásra kattintva egy új tranzakció jelentik meg a tárcájában. Ez várható jelenség. A lezárás sikeres elvégzéséhez ki kell fizetnie a díjat. A hálózattól függően ez akár néhány percig is eltarthat. + +Javasoljuk, hogy néhány perc múlva frissítse a visszavonási eszközt, és nézze meg a tárcájában, hogy valóban eltűnt-e a törölt kapcsolat a listáról. + +Sose adjon a projekteknek korlátlan hozzáférést a tokenjeihez, valamint törölje rendszeresen a hozzáféréseket. A tokenekhez való hozzáférés leállítása nem jár eszközvesztéssel, ha a fenti eszközöket használja. + +
+ + +
Szeretne többet megtudni?
+ + Tekintse meg a további útmutatóinkat + + + +## Gyakran ismételt kérdések + +### A tokenekhez való hozzáférés leállítása a letétbe helyezést, letéti alapokat, kölcsönzést stb. is felfüggeszti? + +Nem, ez nem befolyásolja egyik [DeFi](/glossary/#defi) stratégiáját sem. A helyzete változatlan marad, és tovább kapja a jutalmakat stb. + +### A projektről leválasztani a tárcát ugyanazzal az eredménnyel jár, mintha visszavonnám az engedélyt, hogy hozzáférjen az eszközeimhez? + +Nem, mert a tárca leválasztása után, ha Ön engedélyt adott a tokenek használatára, akkor a projekt továbbra is használni tudja a tokeneket. Az engedélyt kell visszavonnia. + +### A szerződés engedélye mikor jár le? + +A szerződés engedélyeinek nincs lejárati ideje. Ha engedélyt adott, akkor az akár évekkel később is érvényes lehet. + +### A projektek miért állítanak be korlátlan tokenhasználatot? + +A projektek gyakran így akarják minimalizálni a kérvények számát, mert ilyenkor a felhasználónak csak egyszer kell jóváhagynia és a tranzakciós díjat is csak egyszer kell kifizetnie. Bár ez kényelmes megoldás lehet, ugyanolyan veszélyt is rejt azokra a felhasználókra nézve, akik idővel vagy audittal még nem igazolt oldalak hagynak jóvá ilyet. Néhány tárcánál lehetséges manuálisan beállítani a tokenek felhasználható mennyiségét, hogy csökkentsék a kockázatot. További információkért forduljon tárcaszolgáltatójához. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md new file mode 100644 index 00000000000..d3e53b119b4 --- /dev/null +++ b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md @@ -0,0 +1,67 @@ +--- +title: Hogyan lehet átváltani a tokeneket +description: Útmutató a tokenek átváltásához az Ethereumon. +lang: hu +--- + +# Hogyan lehet átváltani a tokeneket + +Elege van abból, hogy olyan tőzsdét keres, amely kedvenc tokenjeivel kereskedik? A legtöbb token felcserélhető [decentralizált cserékkel](/glossary/#dex). + +A tokencsere az Ethereum hálózaton található két különböző eszköz cseréjét foglalja magában, például az ETH cseréjét DAI-ra (egy [ERC-20](/glossary/#erc-20) token). Ez egy gyors és olcsó tranzakció. Szüksége lesz egy kriptotárcára a tokenek váltásához. + +**Feltételek:** + +- Ha van [kriptopénztárcája](/glossary/#wallet), kövesse ezt az oktatóanyagot: [Hogyan: "Regisztráljon" egy Ethereum-fiókot](/guides/how-to-create-an-ethereum-account/) +- lennie kell pénzeszközöknek a tárcájában + +## 1. Kapcsolja a tárcáját egy kiválasztott decentralizált tőzsdéhez (DEX) + +Néhány ismert példa: + +- [Uniswap](https://app.uniswap.org/#/swap) +- [Sushiswap](https://www.sushi.com/swap) +- [1Inch](https://app.1inch.io/#/1/unified/swap/ETH/DAI) +- [Curve](https://curve.fi/#/ethereum/swap) + +Érdekesnek találja? Tudjon meg többet arról, hogy mi a [decentralizált pénzügy (DeFi)](/defi/) és hogyan működnek ezek az újfajta tőzsdék. + +## 2. Válassza ki a két token, amelyeket át szeretne váltani + +Például ETH és DAI. Győződjön meg arról, hogy az egyik tokenből rendelkezik elegendő pénzeszközzel. ![Általános felület az átváltáshoz](./swap1.png) + +## 3. Írja be az eladásra szánt token összegét és nyomja meg az átváltás (swap) gombot + +A tőzsde automatikusan kiszámolja, hogy Ön mennyi tokent fog kapni. + +![Általános felület az átváltáshoz](./swap2.png) + +## 4. Erősítse meg a tranzakciót + +Tekintse át a tranzakció részleteit. Vessen egy pillantást az átváltási rátára és más díjakra, hogy később ne érje kellemetlen meglepetés. + +![Általános felület a tranzakciók megtekintéséhez](./swap3.png) + +## 5. Várja meg, amíg a tranzakciót feldolgozzák + +Bármelyik blokkláncböngészővel megtekintheti a tranzakció állapotát. Ez legfeljebb 10 percen belül megtörténik. + +A tranzakció végrehajtása után automatikusan megkapja a tárcájába a beszerzett tokent. +
+ + +
Szeretne többet megtudni?
+ + Tekintse meg a további útmutatóinkat + + + +## Gyakran ismételt kérdések + +### Át tudok váltani ETH-t BTC-re a tárcámban? + +Nem, csak olyan tokeneket tud váltani, melyek az Ethereum hálózatán működnek, mint az ETH, az ERC-20-as tokenek vagy NFT-k. A Bitcoinnak az Ethereumon megtalálható, „becsomagolt” formáival tud kereskedni. + +### Mi az a csúszás (slippage)? + +A várható átváltási ráta és az aktuális ráta közötti különbség. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md new file mode 100644 index 00000000000..40bdafec991 --- /dev/null +++ b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md @@ -0,0 +1,70 @@ +--- +title: Hogyan lehet áthelyezni a tokeneket a második blokkláncrétegbe (L2) +description: Útmutató, hogyan tudja az Ethereumon lévő tokeneket L2-re áthelyezni híd használatával. +lang: hu +--- + +# Hogyan lehet áthelyezni a tokeneket a második blokkláncrétegbe (L2) + +Ha sok tranzakció fut egyszerre az Ethereumon, akkor drágább a hálózatot használni. Erre az egyik megoldás az, hogy új rétegeket hoznak létre, tehát más hálózatokat, melyek az Ethereumhoz hasonlóan működnek. Ezek a második blokkláncrétegek (L2) csökkenthetik a tranzakciók mennyiségét és azok költségét is az Ethereumon azáltal, hogy sok tranzakciót kezelnek alacsonyabb díjért és ezeknek csak az eredményét tárolják az Ethereumon. Így az L2 megoldások gyorsabban működnek és kevesebb költséggel járnak. Számos népszerű kriptoprojekt az L2-re épít annak előnyei miatt. A legegyszerűbb módja a tokenek Ethereumról második blokkláncra (L2) való áthelyezésének a híd használata. + +**Feltételek:** + +- rendelkeznie kell egy kriptotárcával – ehhez kövesse a következő útmutatót: [Hogyan lehet létrehozni Ethereum-számlát](/guides/how-to-create-an-ethereum-account/) +- lennie kell pénzeszközöknek a tárcájában + +## 1. Határozza meg, hogy melyik L2 hálózatot szeretné használni + +További információkat a projektekről és a fontos hivatkozásokról a [második blokkláncréteg (L2) oldalon](/layer-2/) is szerezhet. + +## 2. Lépjen a kiválasztott hídra + +Néhány népszerű L2: + +- [Arbitrum-híd](https://bridge.arbitrum.io/?l2ChainId=42161) +- [Optimism-híd](https://app.optimism.io/bridge/deposit) +- [Boba-hálózat hídja](https://gateway.boba.network/) + +## 3. Kapcsolódjon a hídhoz a tárcájával + +Győződjön meg arról, hogy tárcája az Ethereum-főhálózathoz kapcsolódik. Ha nem, akkor a weboldal automatikusan felhozza a hálózatváltási lehetőséget. + +![Általános felület a tokenek áthelyezéséhez](./bridge1.png) + +## 4. Határozza meg az összeget és helyezze át + +Tekintse át az összeget, amit az L2-n kapni fog és a kapcsolódó díjakat, hogy ne érjék kellemetlen meglepetések. + +![Általános felület a tokenek áthelyezéséhez](./bridge2.png) + +## 5. Hagyja jóvá a tranzakciót a tárcájában + +A tranzakcióért ETH formájában kell fizetnie. + +![Általános felület a tokenek áthelyezéséhez](./bridge3.png) + +## 6. Várja meg, amíg az eszközei átkerülnek + +Ennek 10 perc alatt meg kell történnie. + +## 7. Adja hozzá a kiválasztott L2 hálózatot a tárcájához (opcionális) + +A [chainlist.org](http://chainlist.org) segít az adott hálózat RPC-adatait megtalálni. Amint a hálózat hozzáadásra kerül és a tranzakció végbemegy, a tokenek megjelennek a tárcájában. +
+ + +
Szeretne többet megtudni?
+ + Tekintse meg a további útmutatóinkat + + + +## Gyakran ismételt kérdések + +### Mi van akkor, ha tőzsdén vannak eszközeim? + +Bizonyos tőzsdékről lehetséges közvetlenül L2-re áthelyezni az eszközöket. Nézze meg az „Áthelyezés a második blokkláncrétegre (L2)” című részt az [L2 oldalon](/layer-2/) a további információkért. + +### Visszavihetem a tokenjeimet az Ethereum-főhálózatra, miután áthelyeztem azokat az L2-re? + +Igen, mindig visszaviheti az eszközeit a főhálózatra ugyanazon a hídon keresztül. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md new file mode 100644 index 00000000000..c23c6200ee2 --- /dev/null +++ b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md @@ -0,0 +1,88 @@ +--- +title: Hogyan használja a tárcát +description: Útmutató a tokenek küldéséről és fogadásáról, valamint a web3-projektekhez való kapcsolódásról. +lang: hu +--- + +# Hogyan használja a tárcát + +Ismerje meg, hogyan működnek a tárca alapvető funkciói. Ha még nem rendelkezik tárcával, akkor tekintse meg a [Hogyan lehet Ethereum-számlát létrehozni](/guides/how-to-create-an-ethereum-account/) című útmutatót. + +## Nyissa ki tárcáját + +Egy irányítópult jelenik meg, amelyen az egyenlege, valamint a tokenek küldésére és fogadására vonatkozó gombok láthatók. + +## Kriptovaluta fogadása + +Szeretne kriptovalutát fogadni a tárcájába? + +Minden Ethereum-számla rendelkezik saját fogadócímmel, amely egy egyedi, számokat és betűket tartalmazó sor. A cím úgy működik, akár egy bankszámlaszám. Az Ethereum-címek mindig „0x” kezdetűek. Ezt a címet bárkivel megoszthatja: ez biztonságos. + +A cím olyan, mint a lakhelyének a címe: elmondja az embernek, hogy odataláljanak Önhöz. Ez azért is biztonságos, mert be tudja zárni az ajtót egy másik kulccsal, amivel csak Ön rendelkezik, így nem tudnak bejutni, hiába tudják a címét. + +Ha valaki pénzt akar küldeni Önnek, akkor meg kell adnia a nyilvános címét. Számos tárca megengedi, hogy kimásolja azt vagy QR-kódként megossza, hogy könnyebb legyen a használata. Ne gépelje be manuálisan. Ez könnyen hibákhoz és a pénzeszköz elvesztéséhez vezethet. + +Előfordulhat, hogy a különböző alkalmazások eltérnek egymástól vagy más nyelvet használnak, de hasonló folyamaton vezetik végig, ha eszközöket kíván mozgatni. + +1. Nyissa meg a tárcaalkalmazást. +2. Kattintson a „Fogadás” (vagy hasonló nevű) gombra. +3. Másolja Ethereum-címét a vágólapra. +4. Adja meg a küldőnek a fogadó Ethereum-címét. + +## Kriptovaluta küldése + +Szeretne ETH-t küldeni egy másik tárcába? + +1. Nyissa meg a tárcaalkalmazást. +2. Kérje el a fogadó címét, és győződjön meg arról, hogy ugyanahhoz a hálózathoz kapcsolódik, mint a fogadó fél. +3. Másolja be a címet vagy szkennelje be a QR-kódot a kamerával, így nem kell manuálisan megadnia. +4. Kattintson a Küldés (vagy hasonló nevű) gombra a tárcájában. + +![A kriptoszámla küldő mezője](./send.png) +
+ +5. Számos eszköz, mint a DAI vagy USDC, egyszerre több hálózaton is létezik. Amikor kriptotokeneket küld, győződjön meg arról, hogy a fogadó fél is ugyanazt a hálózatot használja, mert ezek nem átjárhatók. +6. Biztosítsa, hogy a tárcája elegendő ETH-t tartalmaz, hogy lefedje a tranzakciós díjat is, amely a hálózati feltételek miatt változó összeg. A legtöbb tárca automatikusan hozzáadja a tranzakcióhoz a javasolt díjat, amit Ön jóváhagy. +7. Amint a tranzakció végbement, a kripto összege megjelenik a fogadó fél számláján. Ez a hálózat használóinak számától függően néhány pillanatig vagy percig is eltarthat. + +## Kapcsolódás projektekhez + +Az Ön címe minden Ethereum-projekt esetében azonos. Nem kell regisztrálnia külön sehol. A tárcával bármilyen más információ megadása nélkül kapcsolódni tud az Ethereum-projektekhez. Nincs szükség e-mail-címre vagy egyéb személyes adatokra. + +1. Látogasson el bármelyik projekt oldalára. +2. Ha a projekt oldala csak egy tájékoztató leírás, akkor kattintson az Alkalmazás megnyitása gombra a menüben, ami elvezeti Önt a valódi alkalmazáshoz. +3. Az alkalmazáson belül kattintson a „Kapcsolódás” gombra. + +![Gomb a felhasználó számára, melynek segítségével tárcájával a weboldalhoz kapcsolódhat](./connect1.png) + +4. Válassza ki a tárcáját a megadott opciók listájából. Ha nem látja a tárcáját, akkor nézze meg a „WalletConnect” lehetőség alatt. + +![Kiválasztás a tárcák listájából a kapcsolódáshoz](./connect2.png) + +5. Erősítse meg az aláírási kérést a tárcájában ahhoz, hogy a kapcsolat létrejöjjön. **Az üzenet aláírása nem kerül ETH-pénzeszközbe**. +6. Készen is van! Kezdje el használni az alkalmazást. Számos érdekes projektet találhat a [dapp oldalunkon](/dapps/#explore).
+ + +
Szeretne többet megtudni?
+ + Tekintse meg a további útmutatóinkat + + + +## Gyakran ismételt kérdések + +### Ha rendelkezek ETH-címmel, akkor ugyanazt a címet más blokkláncokon is használhatom? + +Ugyanazt a címet használhatja minden EVM-kompatibilis blokkláncon (ha az Ön tárcájához tartozik visszaállítási kulcsmondat). Ez a [lista](https://chainlist.org/) megmutatja, hogy melyik blokkláncokon működik ugyanaz a cím. Néhány blokklánc, mint a Bitcoin, teljesen más hálózati szabályok alapján üzemel, ezért ott egy másik címre van szükség, amely más formátummal is bír. Ha okosszerződéses tárcával rendelkezik, akkor a terméktájékoztatóból kiderül, hogy melyik blokkláncokat támogatja. + +### Használhatom ugyanazt a címet több eszközön? + +Igen, több eszközön is lehet ugyanazt a címet használni. A tárca valójában csak egy felület, hogy Ön láthassa az egyenlegét és tranzakciókat indítson, a számla nem a tárcán belül található, hanem a blokkláncon. + +### Nem kaptam meg a kriptót, hol tudom a tranzakció státuszát ellenőrizni? + +Használhatja a [blokkfelfedezőket](/developers/docs/data-and-analytics/block-explorers/), hogy valós időben követni tudja a tranzakció státuszát. Ehhez csak a tárca címére vagy a tranzakció azonosítójára kell rákeresnie. + +### A tranzakciókat le tudom állítani vagy visszafordítani? + +Nem, a jóváhagyás után nem lehet leállítani. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/index.md new file mode 100644 index 00000000000..e9cc9e97537 --- /dev/null +++ b/public/content/translations/hu/10) Guides and Quizzes/guides/index.md @@ -0,0 +1,27 @@ +--- +title: Az Ethereum útmutatói +description: Gyakorlati útmutatók gyűjteménye az Ethereum használatának alapjairól kezdők számára. +lang: hu +--- + +# Az Ethereum útmutatói + +Ön is belevág az utazásba az Ethereum világában? A gyakorlati útmutatók részletesen végigvezetik Önt a kezdeti lépéseken, és megkönnyítik az új technológiában való tájékozódást. + +## Első lépések + +1. [Hogyan lehet Ethereum számlát létrehozni](/guides/how-to-create-an-ethereum-account/) – Bárki csinálhat magának tárcát ingyen. Ez az útmutató segít abban, hogyan fogjon bele. + +2. [Hogyan használja a tárcát](/guides/how-to-use-a-wallet/) – Ismerje meg a tokenek küldését és fogadását a tárcájába, valamint a tárca projektekhez való kapcsolását. + +## Biztonsági alapok + +1. [Hogyan vonható vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez](/guides/how-to-revoke-token-access/) – Ha hirtelen azt látja, hogy olyan tranzakció van a tárcájában, melyet nem Ön indított el, akkor ez az útmutató segít abban, hogy ne történjen meg újra. + +2. [Hogyan azonosíthatók a valótlan tokenek](/guides/how-to-id-scam-tokens/) – Mik azok a valótlan tokenek, hogy tűntetik fel magukat valódiként, hogyan azonosíthatók ezek és kerülhető el a csalás. + +## Az Ethereum használata + +1. [Hogyan lehet áthelyezni a tokeneket a második blokkláncrétegbe (L2)](/guides/how-to-use-a-bridge/) – Túl sokba kerülnek az Ethereum-tranzakciók? Fontolja meg, hogy áttér az Ethereum L2-nek nevezett skálázási megoldásaira. + +2. [Hogyan lehet átváltani a tokeneket](/guides/how-to-swap-tokens/) – Át akarja váltani a tokenjét egy másikra? Ez az egyszerű leírás segít abban, hogyan tudja megtenni. diff --git a/public/content/translations/hu/11) Roadmap/eips/index.md b/public/content/translations/hu/11) Roadmap/eips/index.md new file mode 100644 index 00000000000..3801e413ed1 --- /dev/null +++ b/public/content/translations/hu/11) Roadmap/eips/index.md @@ -0,0 +1,79 @@ +--- +title: Ethereum Fejlesztési Javaslatok (EIP-k) +description: Az EIP megértéséhez szükséges alapinformációk +lang: hu +--- + +# Bevezetés az Ethereum Fejlesztési Javaslatokba (EIP-k) {#introduction-to-ethereum-improvement-proposals} + +## Mik azok az EIP-k? {#what-are-eips} + +[Az Ethereum Fejlesztési Javaslatok (EIP-k)](https://eips.ethereum.org/) olyan sztenderdek, melyek potenciális új funkciókat és folyamatokat specifikálnak az Ethereumra. Az EIP-k tartalmazzák a javasolt változtatások műszaki előírásait, és a közösség „igazságforrásaként” működnek. Az Ethereum hálózati frissítéseit és alkalmazási szabványait az EIP folyamaton keresztül tárgyalják és fejlesztik. + +Az Ethereum közösségben bárki létrehozhat egy EIP-t. Az EIP-írás irányelveit az [EIP-1](https://eips.ethereum.org/EIPS/eip-1) tartalmazza. Egy EIP elsődleges célja, hogy tömör technikai specifikációt nyújtson némi motivációval együtt. Az EIP szerzője felelős a közösségen belüli konszenzus kialakításáért, valamint az eltérő vélemények dokumentálásáért. A jól kidolgozott EIP benyújtásának magas szakmai követelményei miatt a legtöbb EIP-szerző általában alkalmazás- vagy protokollfejlesztő. + +## Miért fontosak az EIP-k? {#why-do-eips-matter} + +Az EIP-k központi szerepet játszanak abban, hogy a változások hogyan történnek és dokumentálódnak az Ethereumon. Így lehet az embereknek javaslatot tenni, vitatkozni és elfogadni a változásokat. Különböző [EIP-típusok léteznek](https://eips.ethereum.org/EIPS/eip-1#eip-types), például alapvető (core) EIP-k az alacsony szintű protokollmódosításokhoz, amelyek a konszenzust érintik és hálózatfrissítést igényelnek, mint az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), valamint az alkalmazásstandardokat érintő ERC-k, például az [EIP-20](https://eips.ethereum.org/EIPS/eip-20) és az [EIP-721](https://eips.ethereum.org/EIPS/eip-721). + +Minden hálózati frissítés EIP-kből áll, melyeket a hálózaton működő összes [Ethereum-kliensnek](/learn/#clients-and-nodes) implementálnia kell. Ez azt jelenti, hogy az Ethereum-főhálózat többi kliensével való konszenzus fenntartása érdekében a kliensfejlesztőknek meg kell győződniük arról, hogy mindannyian implementálták a szükséges EIP-ket. + +A változások technikai specifikációjával együtt az EIP-k egy olyan egységet képeznek, amely körül az irányítás történik az Ethereumban: bárki szabadon javasolhat egyet, ezután a közösség különböző érdekeltjei megvitatják, hogy ezt szabványként kell-e elfogadni, vagy egy hálózati frissítés legyen-e belőle. Mivel a nem alapvető (non-core) EIP-ket nem kell minden alkalmazásnak bevezetnie (például készíthető egy helyettesíthető token, amely nem használja az EIP-20 szabványt), de az alapvető (core) EIP-ket széleskörűen be kell vezetni (mivel minden csomópontot frissíteni kell, hogy ugyanahhoz a hálózathoz tartozzanak), az alapvető EIP-k szélesebb konszenzust igényelnek a közösségen belül, mint a nem alapvető EIP-k. + +## EIP-k története {#history-of-eips} + +Az [Ethereum Improvement Proposals (EIPs) Github gyűjteményt](https://github.com/ethereum/EIPs) 2015 októberében hozták létre. Az EIP folyamat a [Bitcoin Improvement Proposals (BIPs)](https://github.com/bitcoin/bips) folyamaton alapul, ami pedig a [Python Enhancement Proposals (PEPs)](https://www.python.org/dev/peps/) folyamaton alapul. + +Az EIP-szerkesztők feladata a technikai stabilitás és a formázási kérdések vizsgálata, valamint a helyesírás/nyelvtan és a kódstílus ellenőrzése. Többek között Martin Becze, Vitalik Buterin és Gavin Wood voltak az eredeti EIP szerkesztők 2015-től 2016 végéig. + +Jelenlegi EIP-szerkesztők: + +- Alex Beregszaszi (@axic) +- Gavin John (@Pandapip1) +- Greg Colvin (@gcolvin) +- Matt Garnett (@lightclient) +- Sam Wilson (@SamWilsn) + +Tiszteletbeli EIP-szerkesztők: + +- Casey Detrio (@cdetrio) +- Hudson Jameson (@Souptacular) +- Martin Becze (@wanderer) +- Micah Zoltu (@MicahZoltu) +- Nick Johnson (@arachnid) +- Nick Savers (@nicksavers) +- Vitalik Buterin (@vbuterin) + +Ha ön is szeretne EIP-szerkesztő lenni, akkor tekintse meg az [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069) frissítést. + +Az EIP-szerkesztők döntik el, hogy egy javaslat mikor áll készen arra, hogy EIP váljon belőle, és segítenek az EIP-szerzőknek kidolgozni javaslataikat. Az [Ethereum macskapásztorok (Cat Herder)](https://www.ethereumcatherders.com/) segítenek az EIP-szerkesztők és a közösség találkozóinak szervezésében (lásd még [EIPIP](https://github.com/ethereum-cat-herders/EIPIP)). + +A teljes szabványosítási folyamat diagrammal együtt megtalálható az [EIP-1](https://eips.ethereum.org/EIPS/eip-1) frissítésben. + +## Bővebben {#learn-more} + +Ha szeretne többet olvasni az EIP-kről, akkor tekintse meg az [EIP-k weboldalát](https://eips.ethereum.org/) és az [EIP-1](https://eips.ethereum.org/EIPS/eip-1) frissítést. További hasznos linkek: + +- [Az összes Ethereum-fejlesztési javaslat (EIP) listája](https://eips.ethereum.org/all) +- [Az összes EIP-típus leírása](https://eips.ethereum.org/EIPS/eip-1#eip-types) +- [Az összes EIP-állapot leírása](https://eips.ethereum.org/EIPS/eip-1#eip-process) + +### Közösségi oktatási projektek {#community-projects} + +- [PEEPanEIP](https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F) — *PEEPanEIP egy oktatási videosorozat, amely megtárgyalja az Ethereum-fejlesztési javaslatokat (EIP) és a következő frissítések főbb jellemzőit.* +- [EIPs For Nerds](https://ethereum2077.substack.com/t/eip-research) — *Az EIPs For Nerds átfogó, egyszerűen megfogalmazott áttekintést nyújt az Ethereum-fejlesztési javaslatokról (EIP), beleértve a főbb javaslatokat, az alkalmazás-/infrastruktúra-rétegre vonatkozókat (ERC), hogy tájékoztatást nyújtson és konszenzust teremtsen a Ethereum-protokoll javasolt változásai kapcsán.* +- [EIPs.wtf](https://www.eips.wtf/) — *Az EIPs.wtf további információkat ad az Ethereum-fejlesztési javaslatokról (EIP), beleértve azok státuszát, bevezetési részleteit, a kapcsolódó pull request-eket (PR) és a közösség visszajelzéseit.* +- [EIP.Fun](https://eipfun.substack.com/) — *Az EIP.Fun az Ethereum-fejlesztési javaslatokról (EIP) ad friss híreket, a kapcsolódó EIP megbeszélésekről és más dolgokról tudósít.* +- [EIPs Insight](https://eipsinsight.com/) — *Az EIPs Insight az Ethereum-fejlesztési javaslatok (EIP) státuszáról ad folyamatjellegű és statisztikai adatokat különböző forrásokból.* + +## Részvétel {#participate} + +Bárki létrehozhat EIP-t. A javaslat beküldése előtt el kell olvasni az [EIP-1](https://eips.ethereum.org/EIPS/eip-1) frissítést, amely leírja az EIP-folyamatot és az EIP megírásának módját, továbbá visszajelzést kell kérni az [Ethereum Mágusok](https://ethereum-magicians.org/) weboldalán, ahol a tervezet benyújtása előtt a közösséggel együtt megvitatják a javaslatokat. + +## Hivatkozások {#references} + + + +Az oldal tartalmát részben az [Ethereum Protocol Development Governance and Network Upgrade Coordination](https://hudsonjameson.com/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) szolgáltatta Hudson Jameson által + + diff --git a/public/content/translations/hu/11) Roadmap/roadmap/beacon-chain/index.md b/public/content/translations/hu/11) Roadmap/roadmap/beacon-chain/index.md new file mode 100644 index 00000000000..c1f0b5751b4 --- /dev/null +++ b/public/content/translations/hu/11) Roadmap/roadmap/beacon-chain/index.md @@ -0,0 +1,75 @@ +--- +title: A Beacon Chain +description: Tudjon meg többet Beacon a láncról – arról a frissítésről, amely behozta a proof-of-stake mechanizmust az Ethereum hálózatára. +lang: hu +template: upgrade +image: /images/upgrades/core.png +alt: +summaryPoint1: A Beacon lánc vezette be a proof-of-stake konszenzust az Ethereum-ökoszisztémába. +summaryPoint2: Az eredeti proof-of-work Ethereum-lánccal 2022 szeptemberében egyesült. +summaryPoint3: A Beacon lánc vezette be az Ethereumot ma biztosító konszenzuslogikát és block gossip (blokkpletyka) protokollt. +--- + + + A Beacon lánc 2020. december 1-jén jelent meg, és 2022 szeptember 15-én a beolvadás frissítéssel hivatalosan is az Ethereum konszenzusmechanizmusává tette a proof-of-stake módszert. + + +## Mi az a Beacon lánc? {#what-is-the-beacon-chain} + +A Beacon lánc az eredeti proof-of-stake blokklánc neve, amit 2020-ban vezettek be. Azért hozták létre, hogy meggyőződjenek a proof-of-stake konszenzuslogika stabilitásáról és fenntarthatóságáról, mielőtt az Ethereum fő hálózatára is bevezetnék azt. Éppen ezért az eredeti proof-of-work Ethereum-lánccal párhuzamosan futtatták. A Beacon lánc egy üres blokkokból álló lánc volt, de a proof-of-work leváltásával és a proof-of-stake mechanizmusra való átállásával az Ethereum megkövetelte, hogy a Beacon lánc fogadja a végrehajtói kliensek tranzakcióit, ezután blokkokba, majd egy proof-of-stake alapú konszenzusmechanizmus felhasználásával blokkláncba rendezze azokat. Ugyanebben a pillanatban az eredeti Ethereum-kliensek leállították a bányászatot, a blokk-előterjesztési és konszenzuslogikát, és mindent átadtak a Beacon láncnak. Ez volt az az esemény, amely [A Beolvadás](/roadmap/merge/) nevet kapta. A Beolvadás után nem volt többé két blokklánc. Csak egy proof-of-stake-alapú Ethereum, ami most két különböző klienst igényel minden csomóponthoz. A Beacon lánc most a konszenzusréteg, a konszenzuskliensek peer-to-peer hálózata, amely a blokkpletykát és a konszenzuslogikát kezeli, miközben az eredeti kliensek alkotják a végrehajtási réteget, amely a pletykálásért és a tranzakciók végrehajtásáért felel, illetve az Ethereum státuszát kezeli. A két réteg az Engine API révén kommunikál egymással. + +## Mire szolgál a Beacon lánc? {#what-does-the-beacon-chain-do} + +Beacon lánc a neve annak a számlafőkönyvek, amely az Ethereum-[letétesek](/staking/) hálózatát működtette és koordinálta, mielőtt ezek a letétesek megkezdték a valódi Ethereum-tranzakciók validálását. Nem kezel tranzakciókat vagy okosszerződés-interakciókat, mert ezt a végrehajtási réteg végzi. A Beacon lánc felel a blokk és tanúsítás kezeléséért, az elágazásválasztás algoritmusát futtatja, valamint a jutalmakat és büntetéseket adja. Bővebben a [csomópont-architektúra oldalon](/developers/docs/nodes-and-clients/node-architecture/#node-comparison). + +## A Beacon lánc hatása {#beacon-chain-features} + +### Letétbe helyezés bevezetése {#introducing-staking} + +A Beacon lánc vezette be a [proof-of-stake-et](/developers/docs/consensus-mechanisms/pos/) az Ethereum rendszerébe. Ez tartja fent az Ethereum biztonságát, és a folyamat során a validátorokat több ETH-hoz juttatja. A gyakorlatban a letétbe helyezés úgy néz ki, hogy ETH-t helyez letétbe a validátorszoftver aktiválásához. Letétesként futtatja a szoftvert, amely új blokkokat hoz létre és validál a láncon. + +A letétbe helyezés hasonló célt szolgál, mint korábban a [bányászat](/developers/docs/consensus-mechanisms/pow/mining/), de számos tekintetben különbözik attól. A bányászat nagy összegű kezdeti kiadásokkal járt, nagy teljesítményű hardverek beszerzésével és nagy energiafogyasztással, ami a tehetősebbeknek kedvezett, és elősegítette a centralizációt. Emellett a bányászat nem követelte meg a fedezetként szolgáló eszközök zárolását, ezzel korlátozta a protokoll képességét a rosszindulatú szereplők megbüntetésére egy támadás után. + +A proof-of-stake mechanizmusra való áttérés jelentősen fokozta az Ethereum biztonságát és decentralizációját a proof-of-work rendszerhez képest. Minél több ember vesz részt a hálózatban, annál decentralizáltabb és védettebb lesz a támadásokkal szemben. + +A proof-of-stake használata, mint konszenzusmechanizmus, egy alapvető komponens [a ma használt biztonságos, környezetbarát és skálázható Ethereum számára](/roadmap/vision/). + + + Ha Ön szeretne validátorrá válni és segítene az Ethereum biztosításában, akkor tudjon meg többet a letétbe helyezésről. + + +### Felkészülés a szilánkolásra {#setting-up-for-sharding} + +Amióta a Beacon lánc egybeolvadt az eredeti Ethereum-főhálózattal, az Ethereum közössége elkezdte keresni a lehetőséget a hálózat méretezésére. + +A proof-of-stake-nek megvan az az előnye, hogy naprakész nyilvántartása van az összes jóváhagyott blokkelőállítókról, akik mind rendelkeznek ETH-letéttel. Ez a nyilvántartás a konkrét hálózati felelősségi körök megbízható felosztása mellett megalapozza az „oszd meg és uralkodj” ideát. + +Ez a felelősség ellentétben áll a proof-of-work rendszerével, ahol a bányászoknak semmilyen kötelezettségük nem volt a hálózat felé, és bármikor, mindenféle következmény nélkül felhagyhattak a bányászattal, végleg lekapcsolva a csomópontszoftvert. Ebben a rendszerben nyilvántartás sincs az ismert blokkelőterjesztőkről, és nincs megbízható módja a hálózati felelősségi körök biztonságos felosztásának. + +[A szilánkolásról bővebben](/roadmap/danksharding/) + +## A frissítések közötti kapcsolat {#relationship-between-upgrades} + +Az Ethereum-frissítések némileg összefüggnek egymással. Foglaljuk össze, hogyan hat a Beacon lánc a többi frissítésre. + +### A Beacon lánc és a beolvadás {#merge-and-beacon-chain} + +A Beacon lánc először az Ethereum fő hálózatától különállóan létezett, de 2022-ben egybeolvadtak. + + + A beolvadás + + +### Szilánkok és a Beacon lánc {#shards-and-beacon-chain} + +A láncszilánkokat csak működő proof-of-stake konszenzusmechanizmussal lehet biztonságosan bevezetni az Ethereum-ökoszisztémába. A Beacon lánc bevezette a letétbe helyezést, ami „egybeolvadt” a fő hálózattal, egyengetve az utat a szilánkolás előtt, amellyel tovább méretezhető az Ethereum. + + + Láncszilánkok + + +## További olvasnivaló + +- [Az Ethereum jövőbeni frissítéseiről bővebben](/roadmap/vision) +- [Bővebben a csomópont-architektúráról](/developers/docs/nodes-and-clients/node-architecture) +- [Bővebben a proof-of-stake-ről](/developers/docs/consensus-mechanisms/pos) diff --git a/public/content/translations/hu/11) Roadmap/roadmap/future-proofing/index.md b/public/content/translations/hu/11) Roadmap/roadmap/future-proofing/index.md new file mode 100644 index 00000000000..673f160d696 --- /dev/null +++ b/public/content/translations/hu/11) Roadmap/roadmap/future-proofing/index.md @@ -0,0 +1,38 @@ +--- +title: Jövőálló Ethereum +description: Ezek a fejlesztések az Ethereumot ellenálló, decentralizált alapréteggé teszik a jövő számára, bármit is hozzon az. +lang: hu +image: /images/roadmap/roadmap-future.png +alt: "Ethereum-ütemterv" +template: roadmap +--- + +Az ütemterv néhány eleme nem feltétlenül a skálázáshoz vagy a biztonsághoz tartozik, hanem stabilizálja és a jövőben is megbízhatóvá teszi az Ethereumot. + +## A kvantumnak való ellenállóság {#quantum-resistance} + +A jelenlegi Ethereumot biztosító [kriptográfia](/glossary/#cryptography) egy része veszélybe kerül, amikor a kvantumszámítás valósággá válik. Habár a kvantum számítógépek valószínűleg évtizedekre vannak attól, hogy valódi veszélyt jelentsenek a modern kriptográfiának, az Ethereumot úgy építik, hogy évszázadokig működjön. Tehát az [Ethereumot ellenállóvá kell tenni a kvantummal](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/) szemben, amilyen gyorsan csak lehet. + +Az Ethereum fejlesztői előtt álló kihívás az, hogy a jelenlegi [proof-of-stake](/glossary/#pos) protokoll egy nagyon hatékony aláírási rendszerre, a BLS-re támaszkodik az érvényes [blokkok](/glossary/#block) szavazatainak összesítésére. Ezt az aláírási sémát a kvantum számítógép fel tudja törni, de a kvantumnak ellenálló verziók nem olyan hatékonyak. + +A [KZG elköteleződési sémák](/roadmap/danksharding/#what-is-kzg) számos helyen megtalálhatók az Ethereumban, hogy kriptográfiai titkokat állítsanak elő, és ezek sebezhetők a kvantummal szemben. Jelenleg ezt úgy kerülik meg, hogy bizalmat igénylő összeállítást használnak, tehát több entitás állítja elő a véletlenszerűséget, amit nem tud a kvantum számítógép visszakövetni. Azonban az ideális megoldás a kvantumbiztos kriptográfia lenne. Két vezető megközelítés létezik, amely képes lenne a BLS-sémát helyettesíteni: a [STARK-alapú](https://hackmd.io/@vbuterin/stark_aggregation) és a [háló alapú](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175) aláírás. **Ezek kutatása és prototípusa még folyamatban van**. + + Tudjon meg többet a KZG-ről és a bizalmat igénylő összeállításról + +## Egyszerűbb és hatékonyabb Ethereum {#simpler-more-efficient-ethereum} + +A komplexitás teret ad a hibáknak vagy a sebezhetőségnek, amit a támadók ki tudnak használni. Ezért a ütemtervnek része az Ethereum leegyszerűsítése, valamint az olyan kódok eltávolítása, amelyek szükségtelenek vagy amelyeket már most tovább lehet fejleszteni. A jól átlátható, egyszerű kódbázis könnyebb fenntarthatóságot tesz lehetővé a fejlesztők számára. + +Számos fejlesztést fognak eszközölni az [Ethereum Virtuális Géppel (EVM)](/developers/docs/evm) kapcsolatban, hogy egyszerűbb és hatékonyabb legyen. Ezek között megtalálható a [ SELFDESTRUCT operációskód eltávolítása](https://hackmd.io/@vbuterin/selfdestruct) – egy ritkán használt utasítás, amelyre már nincs szükség, és még veszélyes is lehet, főleg más várható fejlesztéseket illetően az Ethereum-tárolási modelljét tekintve. Az [Ethereum-kliensek](/glossary/#consensus-client) továbbra is támogatnak néhány régi tranzakciótípust, amelyek most már teljesen eltávolíthatók. A [gáz](/glossary/#gas) számítási módja is javítható, és hatékonyabb módszerek alkalmazhatók egyes kriptográfiai műveletek aritmetikai alátámasztására. + +Hasonlóan, az Ethereum-kliensek más részeit is frissíteni lehet. Például a végrehajtási és konszenzusos kliensek más adattömörítést használnak. Könnyebb és intuitívabb a kliensek közötti adatmegosztás, ha a sémák egységesek az egész hálózaton keresztül. + +## Jelenlegi helyzet {#current-progress} + +Az Ethereum jövőbiztosságának biztosításához szükséges frissítések többsége **még a kutatási fázisban van, és több év múlva is lehet** a megvalósítás. Az olyan frissítések, mint a SELFDESTRUCT eltávolítása, valamint a végrehajtási és konszenzusos kliensben lévő tömörítési séma egységesítése valószínűleg hamarabb megtörténik, mint a kvantumnak ellenálló kriptográfia megvalósítása. + +**További olvasnivaló** + +- [Gáz](/developers/docs/gas) +- [EVM](/developers/docs/evm) +- [Adatstruktúrák](/developers/docs/data-structures-and-encoding) diff --git a/public/content/translations/hu/11) Roadmap/roadmap/index.md b/public/content/translations/hu/11) Roadmap/roadmap/index.md new file mode 100644 index 00000000000..6bf75328c3b --- /dev/null +++ b/public/content/translations/hu/11) Roadmap/roadmap/index.md @@ -0,0 +1,119 @@ +--- +title: Ethereum-ütemterv +description: Az út, amely az Ethereum jobb skálázhatóságához, biztonságához és fenntarthatóságához vezet. +lang: hu +template: roadmap +image: /images/heroes/roadmap-hub-hero.jpg +alt: "Ethereum-ütemterv" +summaryPoints: +buttons: + - + content: Várható fejlesztések + toId: what-changes-are-coming + - + content: Korábbi fejlesztések + href: /history/ + variant: vázlat +--- + +Az Ethereum jelenleg is a globális koordináció erőteljes platformja, de még mindig szükség van további fejlesztésekre. Az ambiciózus fejlesztéseknek köszönhetően a jelenlegi forma helyett egy teljesen skálázható és maximálisan rugalmas Ethereum-platform fog kibontakozni. Ezeket a fejlesztéseket az Ethereum ütemterve ismerteti. + +**A korábbi Ethereum-fejlesztéseket [Az Ethereum története](/history/) oldalon láthatja** + +## Milyen változások várhatók az Ethereumon? {#what-changes-are-coming} + +Az Ethereum ütemterve a jövőbeli, protokollt érintő, specifikus fejlesztéseket vázolja fel. Összességében ez az ütemterv a következő előnyöket hozza el az Ethereum felhasználói számára: + + + + + + + + +## Miért van szüksége az Ethereumnak egy ütemtervre? {#why-does-ethereum-need-a-roadmap} + +Az Ethereumot folyamatosan fejlesztik, hogy javítsák a skálázhatóságot, a biztonságot vagy a fenntarthatóságot. Az Ethereum egyik fő erőssége az, hogy képes a kutatás és fejlesztés során felmerült új ötleteket bevezetni. Ez az alkalmazkodóképesség adja az Ethereum rugalmasságát, hogy kezelni tudja a felmerülő kihívásokat és lépést tudjon tartani a legfejlettebb technológiai áttörésekkel. + + + +Az ütemterv a kutatók és fejlesztők több évnyi munkájának eredménye, mivel a protokoll maga nagyon technikai, de emellett bárki, aki elég elkötelezett, részt vehet benne. Az ötletek általában beszélgetés formájában kezdődnek a fórumokon, mint amilyen az ethresear.ch (https://ethresear.ch/), az Ethereum Magicians (https://ethereum-magicians.org/) vagy az Eth R&D discord szerver. <0>A teljes hontalanság még a kutatási fázisban van, és valószínűleg több év múlva kerül végrehajtásra. Miután ezeket az ötleteket kellőképpen körüljárták, javaslatot készíthetnek belőlük: [Ethereum-fejlesztési javaslatok (EIP)](https://eips.ethereum.org/). Ez az egész folyamat nyilvános, így a közösség bármelyik tagja mérlegelheti a javaslatokat. + +[Bővebben az Ethereum irányításáról](/governance/) + + + + +

Mi volt az ETH2?

+ +

Az „Eth2” kifejezéssel az Ethereum jövőjére hivatkoztak, mielőtt még áttért volna a proof-of-stake mechanizmusra, de elhagyták ezt a kifejezést, hogy sokkal pontosabb terminológiát használjanak helyette. Eredetileg az átállás előtti és utáni állapot megkülönböztetésére használták, vagy néha a különböző Ethereum-kliensekre (a végrehajtási kliensek néha ETH1-kliensként, a konszenzuskliensek pedig ETH2-kliensként jelentek meg).

+ + + +## Fog változni az Ethereum ütemterve? {#will-ethereums-roadmap-change-over-time} + +**Igen, szinte biztosan**. Az ütemterv az Ethereum jelenlegi fejlesztési tervezete, amely rövid- és hosszútávú újításokat is magában foglal. Az ütemterv várhatóan változni fog, amikor új információk és technológiák válnak elérhetővé. + +Az ütemterv olyan, mint a fejlesztési szándékok készlete, vagyis a kutatók és a fejlesztők által feltételezett legoptimálisabb út az Ethereum számára. + +## Mikor vezetik be az ütemterv összes fejlesztését? {#when-will-the-roadmap-be-finished} + +Egyes frissítések alacsonyabb prioritásúak, és valószínűleg csak a következő 5–10 évben valósulnak meg (pl. a kvantumellenálláshoz kapcsolódók). **A fejlesztésekhez nehéz lenne pontos időpontot hozzárendelni**, mivel az ütemterv számos elemének kifejlesztése párhuzamosan folyik és különböző sebességgel valósulnak meg. Egy adott fejlesztés prioritása külső tényezők miatt (pl. a kvantumszámítógépek teljesítményének és elérhetőségének hirtelen fejlődése fontosabbá teszi az ezeknek ellenálló kriptográfiát) is változhat. + +Az Ethereum fejlesztésre úgy is tekinthetünk, mint a biológiai fejlődésre. Az a hálózat sokkal sikeresebb lehet, amelyik alkalmazkodik az új kihívásokhoz és fenntartja fittségét, mint az, amely ellenáll a változásnak, ugyanakkor a jó teljesítmény, skálázhatóság és biztonság elérése után egyre kevesebb protokollváltoztatásra lesz szükség. + +## Van-e bármi teendője a felhasználóknak a fejlesztések bevezetésekor? {#do-i-have-to-do-anything-when-there-is-an-upgrade} + +A fejlesztések általában nem érintik a felhasználókat, kivéve, hogy jobb felhasználói élményt, biztonságosabb protokollt és több opciót biztosítanak az Ethereummal való kapcsolódásra. **A rendszeres felhasználóknak nem kell aktívan részt venniük a frissítésben, és semmit sem kell tenniük** eszközeik biztonsága érdekében. A [csomópont](/glossary/#node)-operátoroknak frissíteniük kell klienseiket, hogy felkészüljenek a frissítésre. Néhány fejlesztés az alkalmazásfejlesztők számára is változást jelent. Például az olyan fejlesztések esetében, amelyek a korábbi adatok elérhetőségét érintik, az alkalmazásfejlesztőknek máshonnan kell beszerezniük az előzményadatokat. + +## Mi a helyzet a Verge, Splurge stb. fejlesztésekkel? {#what-about-the-verge-splurge-etc} + +[Vitalik Buterin egy elképzelést javasolt az Ethereum ütemtervéhez](https://twitter.com/VitalikButerin/status/1741190491578810445), amelyet az Ethereum architektúrára gyakorolt hatásai alapján több kategóriába soroltak. Ennek részei: + +- **Az összevonás**: a [munkaigazolásról](/glossary/#pow) a [tét igazolására](/glossary/#pos) való átállással kapcsolatos frissítések +- **The Surge**: a méretezhetőséghez kapcsolódó frissítések [összegzésekkel](/glossary/#rollups) és adatfelosztással +- **A csapás**: a [MEV](/glossary/#mev) cenzúraellenállásával, decentralizációjával és protokollkockázataival kapcsolatos frissítések +- **The Verge**: a [blokkok](/glossary/#block) egyszerűbb ellenőrzéséhez kapcsolódó frissítések +- **A tisztítás**: a csomópontok futtatásának számítási költségeinek csökkentésével és a protokoll egyszerűsítésével kapcsolatos frissítések +- **The Splurge**: egyéb frissítések, amelyek nem illeszkednek jól az előző kategóriákba. + +Ezen terminológia helyett inkább egyszerűbb és felhasználóközpontú modellt használunk. Ennek ellenére a vízió ugyanaz, amit Vitalik javasolt, csak egyszerűbb szavakkal hivatkozunk rá. + +## Mi a helyzet a shardinggal? {#what-about-sharding} + +A megosztás felosztja az Ethereum blokkláncot, így az [ellenőrzők](/glossary/#validator) részhalmazai csak a teljes adat töredékéért felelősek. Ez volt az eredeti elképzelés az Ethereum skálázhatóságára vonatkozóan. A [2. rétegű](/glossary/#layer-2) összesítések azonban a vártnál sokkal gyorsabban fejlődtek, és már sok skálázást biztosítottak, és sokkal többet fognak nyújtani a Proto-Danksharding megvalósítása után. Tehát a shard-láncokra nincs többé szükség, ez a fejlesztés már nem része az ütemtervnek. + +## Specifikus technikai fejlesztéseket keres? {#looking-for-specific-technical-upgrades} + +- [Danksharding](/roadmap/danksharding) – A Danksharding lehetővé teszi, hogy az L2 összevont tranzakciói sokkal olcsóbbak legyenek, mivel adatblobokat illeszt az Ethereum-blokkokhoz. +- [Letétek kivonása](/staking/withdrawals) – A Shanghai/Capella-frissítésnél jelent meg az Ethereumon a letétek kivonásának lehetősége, így bárki felszabadíthatja a letétbe helyezett ETH-egyenlegét. +- [Egy sloton belüli véglegesítés](/roadmap/single-slot-finality) – Ahelyett, hogy egy blokk javaslásához tizenöt perc kellene, azt ugyanabban a slotban lehessen javasolni és véglegesíteni. Ez kényelmesebb megoldást jelentene az alkalmazások számára, és nehezebb lenne megtámadni. +- [Javaslattevő-építő szétválasztás (PBS)](/roadmap/pbs) – A blokk építésének és előterjesztésének feladata több validátor között oszlik meg, így az Ethereum konszenzus tisztább, cenzúramentesebb és hatékonyabb lesz. +- [Titkos vezetőválasztás](/roadmap/secret-leader-election) – Okos kriptográfia biztosítaná, hogy az aktuális blokkelőterjesztő személye nem kerül nyilvánosságra, így védve lesznek bizonyos támadásoktól. +- [Számlaabsztrakció](/roadmap/account-abstraction) – A számlaabsztrakció a fejlesztések azon csoportja, amely az Ethereum részeként, nem pedig egy összetett közvetítő használatával támogatja az okosszerződéses tárcákat. +- [Verkle-fák](/roadmap/verkle-trees) – A Verkle-fák olyan adatstruktúrák, amelyek lehetővé teszik a státusztalan kliensek használatát az Ethereumon. Ezek a kliensek csak kis tárhelyet igényelnek, de képesek az új blokkok validálására. +- [Státusztalanság](/roadmap/statelessness) – A státusztalan kliensek képesek validálni az új blokkokat anélkül, hogy nagy adatmennyiségeket kellene tárolniuk. Ezzel a csomópontok a mai költség töredékéért működtethetők, az általuk nyújtott előnyök elvesztése nélkül. diff --git a/public/content/translations/hu/11) Roadmap/roadmap/merge/index.md b/public/content/translations/hu/11) Roadmap/roadmap/merge/index.md new file mode 100644 index 00000000000..59c38ec9f1b --- /dev/null +++ b/public/content/translations/hu/11) Roadmap/roadmap/merge/index.md @@ -0,0 +1,229 @@ +--- +title: A beolvadás +description: További információ a beolvadásról – amikor az Ethereum fő hálózata áttért a proof-of-stake konszenzusra. +lang: hu +template: upgrade +image: /images/upgrades/merge.png +alt: +summaryPoint1: Az Ethereum fő hálózata proof-of-stake konszenzust használ, ám ez nem mindig volt így. +summaryPoint2: Az áttérés az eredeti proof-of-work mechanizmusról a proof-of-stake mechanizmusa a beolvadás nevet kapta. +summaryPoint3: A Beolvadás az eredeti Ethereum-főhálózat összeolvadását jelenti a Beacon lánc nevű különálló proof-of-stake blokklánccal, amelyek most már egy láncként léteznek. +summaryPoint4: A Beolvadás nagyjából 99,95%-kal csökkentette az Ethereum energiafogyasztását. +--- + + + A beolvadás 2022. szeptember 15-én ment végbe. Ezzel lezárult az Ethereum áttérése a proof-of-stake konszenzusra, így hivatalosan is elhagyta a proof-of-work mechanizmust, és nagyjából 99,95%-kal csökkentette az energiafogyasztását. + + +## Mi volt a beolvadás? {#what-is-the-merge} + +A beolvadás az Ethereum eredeti végrehajtási rétegének (a [genezis](/history/#frontier) óta létező fő hálózatnak) az összeolvadása volt az új proof-of-stake konszenzusréteggel, a Beacon lánccal. Ezzel szükségtelenné vált az energiaintenzív bányászat, és megnyílt a hálózat biztosításának lehetősége letétbe helyezett ETH felhasználásával. Igazán izgalmas lépés volt ez az Ethereum jövőképének – nagyobb méretezhetőség, biztonság és fenntarthatóság – megvalósítása felé vezető úton. + + + +A [Beacon lánc](/roadmap/beacon-chain/) és a [fő hálózat](/glossary/#mainnet) eredetileg külön működött. Az Ethereum-főhálózat biztonságát – az összes számlájával, egyenlegével, okosszerződésével és blokkláncállapotával együtt – továbbra is a [proof-of-work](/developers/docs/consensus-mechanisms/pow/) konszenzus szolgáltatta, még akkor is amikor a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) mechanizmust használó Beacon lánc vele párhuzamosan futott. A beolvadás volt az esemény, amikor ez a két rendszer végre egyesült, és a proof-of-work helyét végleg átvette a proof-of-stake. + +Képzeljük el, hogy az Ethereum egy űrhajó, amely még azelőtt felszállt, hogy igazán készen állt volna a csillagközi utazásra. A Beacon lánccal a közösség egy új hajtóművet és egy erősebb hajótestet épített. Jelentős tesztelést követően eljött az ideje, hogy a régi hajtóművet menet közben kicseréljék az újra. Ezzel az új, hatékonyabb hajtómű beolvadt a már meglévő hajóba, megteremtve a lehetőséget, hogy súlyos fényéveket tegyen meg, és nyakába vegye az univerzumot. + +## Összeolvadás a fő hálózattal {#merging-with-mainnet} + +A proof-of-work mechanizmus biztosította az Ethereum-főhálózatot a születésétől a beolvadásig. Ez tette lehetővé, hogy az általunk jól ismert Ethereum-blokklánc 2015 júliusában az összes ismerős funkciójával együtt (tranzakciók, okosszerződések, számlák stb.) létrejöjjön. + +A fejlesztők az Ethereum története során végig készültek arra, hogy egyszer majd áttérnek a proof-of-work konszenzusról a proof-of-stake mechanizmusra. 2020. december 1-jén a fő hálózattól elkülönült, vele párhuzamosan működő blokkláncként létrejött a Beacon lánc. + +A Beacon lánc eredetileg nem kezelte a fő hálózat tranzakcióit. Ehelyett a saját állapotát illetően jutott konszenzusra az aktív validátorok számlaegyenlegekre vonatkozó egyetértésén keresztül. Mélyreható tesztelést követően eljött az ideje, hogy a Beacon lánc való világbeli adatokkal kapcsolatban is konszenzusra jusson. A beolvadás után a Beacon lánc lett az összes hálózati adat konszenzusmotorja, beleértve a végrehajtási réteg tranzakcióit és számlaegyenlegeit is. + +A beolvadás jelentette a hivatalos váltást, amely után a Beacon lánc tölti be a blokkelőállítás hajtómotorjának szerepét. Az érvényes blokkok előállításának módja többé már nem a bányászat. Ehelyett a proof-of-stake validátorok vették át ezt a szerepet, és most már ők felelnek a tranzakciók validálásának végrehajtásáért és az új blokkok előterjesztéséért. + +Az előzmények nem vesztek el a beolvadással. Ahogy a fő hálózat egyesült a Beacon lánccal, az Ethereum összes tranzakcióelőzményét is magával vitte. + + +A proof-of-stake mechanizmus átvétele megváltoztatta az Ether kibocsátásának módját. Tudjon meg többet: Ether-kibocsátás a beolvadás előtt és után. + + +### Felhasználók és tulajdonosok {#users-holders} + +**A beolvadás nem hozott változást a tulajdonosok/felhasználók számára.** + +_Erre ráfér az ismétlés_: az ETH vagy az Ethereum hálózatán található bármely egyéb digitális eszköz felhasználójaként vagy tulajdonosaként, valamint nem csomópont-operátor letétesként **semmit sem kell tennie a pénzeszközeivel vagy a tárcájával a beolvadás kapcsán.** Az ETH egyszerűen csak ETH. Nincs olyan, hogy „régi ETH”/„új ETH” vagy olyan, hogy „ETH1”/„ETH2”, és a tárcák a beolvadás után is pontosan ugyanúgy működnek, mint azelőtt. Akik mást állítanak, valószínűleg csalók. + +Annak ellenére, hogy lecserélte a proof-of-work mechanizmust, az Ethereum összes előzménye – a létrejöttéig visszamenőleg – változatlan formában megmaradt a proof-of-stake-re való áttérés során. A beolvadás előtt az Ön tárcájában lévő eszközök a beolvadást követően is elérhetők. **Az ön részéről semmilyen frissítési intézkedés nem szükséges.** + +[Az Ethereum biztonságáról bővebben](/security/#eth2-token-scam) + +### Csomópont-operátorok és dapp-fejlesztők {#node-operators-dapp-developers} + + + +A fő intézkedési elemekhez tartoznak az alábbiak: + +1. Futtasson _egyidejűleg_ egy konszenzusklienst és egy végrehajtási klienst; a harmadik fél végpontok a beolvadás után már nem tudnak végrehajtási adatokat szerezni. +2. A végrehajtási és a konszenzusklienst is egy megosztott JWT titkos kulccsal hitelesítse, hogy biztonságosan tudjanak kommunikálni. +3. Állítson be egy „díj címzettje” címet a kapott tranzakciós illetéktételek/MEV fogadásához. + +Ha a fenti felsorolás első két elemét nem teljesíti, akkor a csomópontja „offline” állapotot mutat majd, amíg mindkét réteg szinkronizálása és hitelesítése be nem fejeződik. + +Ha nem állít be egy „díj címzettje” címet, attól még a validátor a szokásos módon tud működni, de Ön lemarad az el nem égetett díjtételekről/MEV-ről, amelyeket egyébként megkapott volna a validátora által előterjesztett blokkokkal. + + + + +Egészen a beolvadásig egy végrehajtási kliens (például: Geth, Erigon, Besu vagy Nethermind) elég volt ahhoz, hogy valaki fogadja, megfelelően validálja és propagálja a hálózaton terjedő blokkokat. _A beolvadás óta_ egy végrehajtási csomagban található tranzakciók érvényessége az őket tartalmazó „konszenzusblokk” érvényességétől is függ. + +Ennek eredményeképpen egy teljes Ethereum-csomóponthoz most már végrehajtási kliens és egy konszenzuskliens is szükséges. Ez a két kliens egy új motor-API segítségével működik együtt. A motor-API JWT titkos kulcsot használó hitelesítést igényel. A kulcsot mindkét kliens megkapja, ami biztonságos kommunikációt tesz lehetővé. + +A fő intézkedési elemekhez tartoznak az alábbiak: + +– konszenzuskliens telepítése a végrehajtási kliens mellé +– végrehajtási és konszenzuskliens hitelesítése megosztott JWT titkos kulccsal, hogy biztonságosan kommunikálhassanak egymással. + +Ha a fenti felsorolás elemeit nem teljesíti, akkor a csomópontja „offline” állapotúnak tűnik majd, amíg mindkét réteg szinkronizálása és hitelesítése be nem fejeződik. + + + + + +A Beolvadás megváltoztatta a konszenzust, amely a következőkre is hatott:< + +
    +
  • blokkstruktúra
    • +
  • slot-/blokkidőzítés
    • +
  • operációskód-változások
    • +
  • a láncon belüli véletlenszerűség forrása
    • +
  • a biztonságos fejléc és a véglegesített blokkok koncepciója
    • +
+ +További információért nézze meg Tim Beiko blog postját: Hogyan érinti a Beolvadás az Ethereum alkalmazási rétegét. + + + +## A beolvadás és az energiafogyasztás {#merge-and-energy} + +A beolvadás a proof-of-work végét jelentette az Ethereum számára, valamint egy fenntarthatóbb, környezetbarátabb Ethereum kezdetét. Az Ethereum energiafogyasztása nagyjából 99,95%-kal csökkent, ezzel az Ethereum zöld blokklánc lett. Tudjon meg többet az [Ethereum energiafogyasztásáról](/energy-consumption/). + +## A beolvadás és a méretezhetőség {#merge-and-scaling} + +A beolvadás a további méretezhetőségi fejlesztések lehetőségét is megteremtette, amelyek a proof-of-work konszenzus mellett lehetetlenek voltak, egy lépéssel közelebb hozva az Ethereumot az [Ethereum-jövőképben](/roadmap/vision/) felvázolt méretezési, biztonsági és fenntarthatósági célok eléréséhez. + +## Téveszmék a beolvadásról {#misconceptions} + + + +Két típusú Ethereum-csomópont létezik: olyanok, amelyek képesek blokkjavaslatot tenni, és olyanok, amelyek nem. + +A blokkot előterjesztő csomópontok csak kis részét adják az Ethereum hálózatán működő csomópontoknak. Ebbe a kategóriába tartoznak a proof-of-work (PoW) mechanizmus bányászcsomópontjai és a proof-of-stake (PoS) mechanizmus validátor-csomópontjai. Ez a kategória megköveteli a gazdasági erőforrások elkülönítését (például GPU hash-teljesítményt a proof-of-work mechanizmus alatt, illetve ETH-letétbe helyezést a proof-of-stake mechanizmus mellett) cserébe azért, hogy az operátor alkalomadtán javaslatot tehessen a következő blokkra, és megkaphassa a protokolljutalmakat. + +A hálózat többi csomópontja (tehát a csomópontok többsége) nem köteles gazdasági erőforrásokat feláldozni egy átlagos személyi számítógépen, 1-2 TB elérhető tárhelyen és egy internetkapcsolaton túl. Ezek a csomópontok nem terjesztenek elő blokkjavaslatokat, mégis kritikus szerepet játszanak a hálózat biztosításában azzal, hogy a blokkelőterjesztőket szemmel tartva vizsgálják az újonnan érkező blokkokat, és hálózat konszenzusszabályaival összhangban ellenőrzik azok érvényességét. Ha a blokk érvényes, akkor a csomópont propagálja azt a hálózaton keresztül. Ha a blokk bármilyen okból kifolyólag érvénytelen, akkor a csomópont szoftverje figyelmen kívül hagyja azt, és nem folytatja a propagálását. + +Egy nem blokk-készítő csomópontot bárki futtathat, működjön bármilyen konszenzusmechanizmus szerint is (proof-of-work vagy proof-of-stake); de aki megteheti, azt erőteljesen bátorítják. Egy csomópont futtatása hihetetlen értékkel bír az Ethereum számára, és előnyöket biztosít a csomópontot futtató egyén számára is, például nagyobb biztonságot, adatvédelmet és ellenálló képességet a cenzúrával szemben. + +Az Ethereum-hálózat decentralizációjának fenntartásához rendkívül lényeges az a képesség, hogy bárki tudjon saját csomópontot működtetni. + +Bővebben a saját csomópont működtetéséről + + + + + +A gasdíjak a hálózati teljesítmény iránti kereslet és a hálózati kapacitás egymáshoz viszonyított változásának eredményeként alakulnak. A beolvadással megszűnt a proof-of-work mechanizmus használata, és áttértünk a proof-of-stake konszenzusra, ám a hálózati kapacitást vagy feldolgozóképességet közvetlenül érintő paraméterekben jelentős változás nem következett be. + +A összevonttranzakció-centrikus fejlesztési tervvel az erőfeszítések oda irányultak, hogy a felhasználói aktivitást az L2-n tegyék skálázhatóvá, miközben lehetővé teszik, hogy az L1 főhálózat egy biztonságos, decentralizált réteg, ami optimális az összevont tranzakciós adatok tárolására, így azok használata exponenciálisan olcsóbb lehet. Ennek eléréséhez az áttérés a proof-of-stake mechanizmusra létfontosságú előfeltétel volt. Bővebben a gázról és a díjakról. + + + + +A tranzakciók „sebessége” több módon is mérhető, például az egy blokkban foglalt idővel és a véglegesítés időigényével. Ezek mindegyike változik kicsit, de a felhasználók számára ez nem észlelhető. + +Korábban, a proof-of-work konszenzus ideje alatt a cél az volt, hogy körülbelül 13,3 másodpercenként létrejöjjön egy új blokk. A proof-of-stake mechanizmussal a slotok pontosan 12 másodpercenként ismétlődnek, mind egy-egy lehetőség, hogy egy validátor közzétegyen egy blokkot. A legtöbb slothoz tartozik blokk is, de nem feltétlenül mindegyikhez (például ha egy validátor offline állapotban van). A proof-of-stake mechanizmus mellett körülbelül 10%-kal gyakrabban jön létre blokk, mint a proof-of-work mellett. Ez egy viszonylag jelentéktelen változás, amely a felhasználóknak valószínűleg nem tűnik fel. + +A proof-of-stake magával hozta a tranzakció véglegességének koncepcióját, amely korábban nem létezett. A proof-of-work rendszerében egy blokk visszafordításának nehézsége az adott tranzakció után kibányászott minden egyes blokkal exponenciálisan növekszik, de valójában sosem válik lehetetlenné. A proof-of-stake mechanizmusban a blokkok úgynevezett korszakokba (epoch) rendeződnek (6,4 perces időintervallumonként, amelyek 32 blokklehetőséget tartalmaznak), amelyekről a validátorok szavaznak. Amikor egy korszak lezárul, a validátorok szavaznak arról, hogy adott korszakot „igazolt” állapotúnak tekintsék. Ha a validátorok megegyeznek, hogy a korszakot igazolt állapotúnak tekintsék, akkor az a következő korszakban végleges állapotba kerül. A véglegesített tranzakciók visszafordítása gazdaságtalan lenne, mivel ehhez a teljes letétbe helyezett ETH-állomány több mint egyharmadát meg kellene szerezni és el kellene égetni. + + + + + +Kezdetben a Beolvadás után a letétesek csak az extra díjakat és a MEV-et kapták meg, amelyet a blokkjavaslások eredményeként nyertek. Ezek a jutalmak egy nem letéti számlára kerültek, amelyet a validátor kontrollál (aki a díjakat kapja), és azonnal elérhetők. Ezek különböznek a protokolljutalmaktól, amelyeket a validátori kötelezettségeikért kapnak. + +A Shanghai/Capella hálózatfrissítés óta a letétesek egy visszavonási számlát jelölnek ki, hogy automatikusan megkapják a letéti összeg feletti részt (32 ETH felett). Ez a fejlesztés lehetővé tette, hogy a validátor kilépjen a hálózatból, és ezzel felszabadítsa és visszakapja a teljes egyenlegét. + +Bővebben a letétek visszavonásáról + + + + +Mióta a Shanghai/Capella frissítés lehetővé tette a letétek visszavonását, minden validátort arra ösztönöznek, hogy lehívja a 32 ETH feletti letéti egyenlegét, mivel ezek a pénzeszközök nem járnak plusz hozammal, de a rendszer zárolja őket. Az APR-értéktől függően (amelyet a teljes letétbe helyezett ETH-mennyiség határoz meg) ez arra ösztönözheti őket, hogy teljesen feladják a validátori pozíciójukat és visszakérjék a teljes egyenlegüket, vagy éppen arra, hogy a jutalmaik felhasználásával növeljék a letétjüket és nagyobb hozamhoz jussanak. + +Egy fontos kikötés, hogy a validátor kilépése egy rátához van kötve, és csak eszerint léphet ki valaki egy adott korszakban (minden 6,4. percben). Ez a határérték az aktív validátorok számától függően változik, de a teljes letétbe helyezett ETH-nak kb. 0,33%-a lehet egy adott napon. + +Így nem lehet tömegesen letéti összeget kivonni. Emellett azt is megakadályozza, hogy egy potenciális támadó a letétjét felhasználva slashing-sértést kövessen el, és egyazon korszakon belül felszámolja a validátor teljes ETH-letéti egyenlegét, mielőtt a protokoll érvényesíthetné a megsemmisítési szankciót. + +Az APR értéke szándékosan dinamikus, segítségével a letétesek által alkotott piac megállapíthatja azt a kifizetési szintet, amely mellett hajlandók gondoskodni a hálózat biztonságáról. Ha ez a szint túl alacsony, akkor a validátorok a protokoll által korlátozott tempóban kilépnek. Ez fokozatosan megemeli az APR értékét a maradók számára, ami új vagy visszatérő letéteseket eredményez majd. + + +## Mi történt az „Eth2”-vel? {#eth2} + +Az „Eth2” kifejezést elhagytuk. Miután az „Eth1” és az „Eth2” egyetlen láncban egyesült, már nincs szükség arra, hogy különbséget tegyünk két Ethereum-hálózat között. Csak egy Ethereum maradt. + +A zavar elkerülése érdekében a közösség frissítette az alábbi kifejezéseket: + +- Az „Eth1” helyett a „végrehajtási réteg” kifejezést használjuk. Ez a réteg kezeli a tranzakciókat és a végrehajtást. +- Az „Eth2” helyett a „konszenzusréteg” kifejezést használjuk. Ez a réteg kezeli a proof-of-stake konszenzust. + +Ezek a terminológiai módosítások csak az elnevezési szabályokat változtatják meg; ez nem változtatnak az Ethereum céljain vagy ütemtervén. + +[Tudjon meg többet az „Eth2” átnevezéséről](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/) + +## A frissítések közötti kapcsolat {#relationship-between-upgrades} + +Az Ethereum-frissítések némileg összefüggnek egymással. Foglaljuk össze hát, hogy a beolvadás hogyan viszonyul a többi frissítéshez. + +### A beolvadás és a Beacon lánc {#merge-and-beacon-chain} + +A beolvadás a Beacon lánc hivatalos átvételét jelenti az eredeti fő hálózat végrehajtási rétegéhez tartozó új konszenzusrétegként. A beolvadás óta a validátorok feladata az Ethereum-főhálózat biztosítása, és a [proof-of-work](/developers/docs/consensus-mechanisms/pow/) rendszerű bányászat már nem érvényes módszer a blokkok előállítására. + +Ehelyett a blokkokra azok a validáló csomópontok tesznek javaslatot, amelyek ETH-t helyeztek letétbe a konszenzusban való részvétel jogáért. Ezek a frissítések készítik elő a terepet a jövőbeni méretezhetőségi frissítésekhez, többek között a szilánkoláshoz. + + + A Beacon lánc + + +### A beolvadás és a Shanghai frissítés {#merge-and-shanghai} + +Hogy leegyszerűsítsük az áttérést a proof-of-stake mechanizmusra, és maximalizáljuk az összpontosítást erre a feladatra, a beolvadás nem tartalmazott bizonyos várt funkciókat, mint például a letétbe helyezett ETH lehívásának lehetőségét. Ez a funkció külön vált elérhetővé a Shanghai/Capella frissítéssel. + +A kíváncsibbak többet megtudhatnak arról, hogy [Mi történik A Beolvadás után](https://youtu.be/7ggwLccuN5s?t=101), méghozzá Vitalik 2021. áprilisi ETHGlobal eseményen tartott előadásából. + +### A beolvadás és a szilánkolás {#merge-and-data-sharding} + +Az eredeti terv szerint a beolvadás előtt dolgozták volna ki a láncszilánkolást (sharding) a méretezhetőség megoldására. Azonban a [2. rétegű méretezési megoldások](/layer-2/) elterjedésével a prioritás eltolódott afelé, hogy előbb a proof-of-stake leváltsa a proof-of-work rendszert. + +A szilánkolással kapcsolatos tervek gyorsan fejlődnek, ám a 2. rétegű technológiák felemelkedése és sikere kapcsán – amelyet a tranzakció-végrehajtás méretezése terén elértek – a szilánkolásra vonatkozó elképzelések most már arra irányulnak, hogy megtalálják a legoptimálisabb módot a rollupszerződések tömörített lehívási adatainak tárolásával járó teher elosztására, és így lehetővé tegyék a hálózati kapacitás exponenciális növekedését. Ehhez azonban előbb át kell térni a proof-of-stake mechanizmusra. + + + Szilánkolás (sharding) + + +## További olvasnivaló {#further-reading} + + + + diff --git a/public/content/translations/hu/11) Roadmap/roadmap/merge/issuance/index.md b/public/content/translations/hu/11) Roadmap/roadmap/merge/issuance/index.md new file mode 100644 index 00000000000..8589d40858b --- /dev/null +++ b/public/content/translations/hu/11) Roadmap/roadmap/merge/issuance/index.md @@ -0,0 +1,134 @@ +--- +title: Hogyan hatott az ETH kínálatra a Beolvadás +description: Részletes bemutatása annak, hogy a Beolvadás hogyan hatott az ETH kínálatára +lang: hu +--- + +# Hogyan hatott az ETH kínálatra a Beolvadás {#how-the-merge-impacts-ETH-supply} + +A Beolvadás jelenti az Ethereum hálózatok azon változását, amikor 2022. szeptemberében áttértek a proof-of-work mechanizmusról a proof-of-stake mechanizmusra. Akkor az is megváltozott, ahogy az ETH-t kibocsátják. Korábban az új ETH két forrásból származott: a végrehajtási rétegből. (főhálózat) és a konszenzusrétegből (Beacon lánc). A Beolvadás óta a végrehajtási réteg kibocsátása nulla. Nézzük meg ennek részleteit. + +## Az ETH-kibocsátás komponensei {#components-of-eth-issuance} + +A ETH-kínálatot két elsődleges erő irányítja: a kibocsátás és az elégetés. + +Az ETH **kibocsátása** az a folyamat, amikor olyan ETH-t hoznak létre, amely korábban nem létezett. Az ETH **elégetése** az a folyamat, amikor a létező ETH-t megsemmisítik, ezzel kivonva azt a körforgásból. A kibocsátás és elégetés rátája számos paraméter alapján kerül kiszámításra, és az ezek közötti egyensúly határozza meg az ether inflációs/deflációs rátáját. + + + +– A proof-of-stake mechanizmusra való átállás előtt a bányászok kb. 13 000 ETH-t bocsátottak ki naponta +– A letétbe helyezők kb. 1700 ETH-t adnak ki naponta, amelynek alapja 14 millió letétbe helyezett ETH +– A letétbe helyezési kibocsátás a letétbe helyezett ETH összegétől függ +– **A Beolvadás óta a napi kibocsátás 1700 ETH körüli, amely 88%-os csökkenés a korábbihoz képest** +– Az elégetés: a hálózati kereslettől függően változik. Ha egy adott napra az átlagos gázdíj legalább 16 gwei, akkor ez kiegyenlíti a validátoroknak kibocsátott 1700 ETH-t, és a nettó ETH infláció nulla vagy annál kevesebb. + + + +## A Beolvadás előtt (régi szisztéma) {#pre-merge} + +### A végrehajtási réteg kibocsátása {#el-issuance-pre-merge} + +A proof-of-work mechanizmusban a bányászok csak a végrehajtási réteggel kapcsolódtak, és blokkjutalmat kaptak, ha elsőként oldották meg a következő blokkot. A [Constantinople-frissítés](/history/#constantinople) után, 2019-től ez a jutalom 2 ETH volt blokkonként. A bányászok jutalmat szereztek akkor is, ha nem egy valid blokkot hoztak létre, amely nem került be a leghosszabb/hiteles láncba, hanem annak csak [ommer](/glossary/#ommer) vagy testvérblokkja volt. Ezek a jutalmak maximum 1,75 ETH-t értek ommerenként, és az érvényes blokk nyereségén _felül_ kerültek kibocsátásra. A bányászat egy gazdaságilag intenzív tevékenység volt, amelynek fenntartásához magas szintű ETH kibocsátásra volt szükség. + +### A konszenzusréteg kibocsátása {#cl-issuance-pre-merge} + +A [Beacon lánc](/history/#beacon-chain-genesis) 2020-től működik élesben. A bányászok helyett validátorok biztosították a rendszert a proof-of-stake mechanizmussal. Ezt a láncot úgy állították fel, hogy az Ethereum-felhasználók ETH-t helyeztek letétbe egy okosszerződésbe a főhálózaton (a végrehajtási rétegen), amelyet a Beacon lánc felismert és az új láncon ugyanannyit ETH-t adott a felhasználónak. A Beolvadás bevezetéséig a Beacon lánc validátorai nem kezelték a tranzakciókat és lényegében a validátor gyűjtőjének státuszáról hozták meg a konszenzust. + +A Beacon láncon a validátorok ETH jutalmat kaptak azért, hogy tanúsítják a lánc státuszát és blokkokat javasolnak. A validátor teljesítménye alapján jutalmak és büntetések kerülnek kiszabásra minden korszakban (epoch, minden 6,4 percben). A validátorok jutalma **jelentősen** kevesebb, mint a bányászoké volt a proof-of-work mechanizmusban (2 ETH kb. 13,5 másodpercenként), mivel a validáló csomópont üzemeltetése nem annyira intenzív feladat, és így nem jár olyan magas jutalom érte. + +### A Beolvadás előtti kibocsátás részletei {#pre-merge-issuance-breakdown} + +Teljes ETH-kínálat: **~120 520 000 ETH** (a Beolvadás idején, 2022. szeptemberben) + +**A végrehajtási réteg kibocsátása:** + +- A becslések szerint 2,08 ETH 13,3 másodpercenként \*: **kb. 4 930 000** ETH került kibocsátásra egy évben +- Ennek eredményeként egy **hozzávetőleges 4,09%-os** inflációs ráta keletkezett (évi 4,93 millió osztva a teljes 120,5 millióval) +- \*Beleértve a kanonikus blokkokért adott 2 ETH-t, plusz az ommer blokkokért adott átlagos 0,08 ETH-t. Emellett a 13,3 másodperc az alap blokkidő, eltekintve az esetleges [nehézség bombák](/glossary/#difficulty-bomb) hatásaitól. ([Tekintse meg a forrást](https://bitinfocharts.com/ethereum/)) + +**A konszenzusréteg kibocsátása:** + +- A teljes 14 000 000 letétbe helyezett ETH-t figyelembe véve az ETH kibocsátás kb. 1700 ETH/nap ([Tekintse meg a forrást](https://ultrasound.money/)) +- Ennek eredményeként **kb. 620 500** ETH-t bocsátanak ki évente +- Ennek eredménye a **kb. 0,52%-os** inflációs ráta (évi 620,5 ezer osztva a teljes 119,3 millióval) + + +Teljes éves kibocsátási ráta (a Beolvadás előtt): ~4,61% (4,09% + 0,52%)

+a kibocsátás kb. 88,7%-a ment a bányászoknak a végrehajtási rétegen (4,09 / 4,61 * 100)

+kb. 11,3%-a a letétesekhez került a konszenzusrétegen (0,52 / 4,61 * 100) + + +## A Beolvadás után (jelenlegi szisztéma) {#post-merge} + +### A végrehajtási réteg kibocsátása {#el-issuance-post-merge} + +A Beolvadás óta a végrehajtási réteg kibocsátása nulla. A blokkokat többé nem a proof-of-work mechanizmus alapján hozzák létre a konszenzus megújított szabályai szerint. A végrehajtási réteg tevékenységeit „beacon blokkokba” csomagolják, amelyeket a proof-of-stake validátorok publikálnak és tanúsítanak. A beacon blokk tanúsításért és publikálásért járó jutalmakat a konszenzusrétegen külön kezelik. + +### A konszenzusréteg kibocsátása {#cl-issuance-post-merge} + +A konszenzusréteg kibocsátása ma is ugyanúgy folytatódik, mint a Beolvadás előtt, kis összegű jutalmakat ad a validátoroknak a blokkok tanúsításáért és javaslattevésért. A validátori jutalmak továbbra is _validátoregyenlegként_ gyűlnek, amelyet a konszenzusrétegen kezelnek. Ezek nem általános, a főhálózaton használható („végrehajtási”) számlák, hanem elkülönített Ethereum számlák, amelyek nem léphetnek tranzakcióba más számlákkal. Az itt tárolt pénzeszközöket csak ki lehet vonni egy meghatározott végrehajtási címre. + +Ezt a visszavonási lehetőséget a Shanghai/Capella-frissítés tette lehetővé 2023. áprilisban. A letétbe helyezőket arra ösztönzik, hogy vegyék ki a _jutalmakat (a 32 ETH feletti összeget)_, mivel ezek nem járulnak hozzá a letéthez (ami maximum 32 ETH lehet). + +A letétbe helyezők emellett ki is léphetnek és kivonhatják a teljes validátoregyenlegüket. Az Ethereum stabilitása érdekében az egyszerre távozó validátorok száma korlátozott. + +Egy adott napon kb. a teljes validátoroknak a 0,33%-a távozhat. Alapból 4 validátor léphet ki egy korszakon (6,4 perc) belül, vagyis egy nap alatt 900. Plusz 1 validátor kiléphet akkor, ha 65 536 (216) új validátor jön és a teljes számuk több mint 262 144 (218). Például 327 680 validátor felett minden korszakban 5-en léphetnek ki (1125 naponta). Ha az aktív validátorok száma meghaladja a 393 216-t, akkor már 6-an léphetnek ki, és így tovább. + +Ahogy több validátor vonul ki, a meglévő validátorok száma fokozatosan lecsökken a minimum négy validátorra, így megvédi a rendszert attól, hogy az ETH-letétek egyidejű kivonása miatt labilissá váljon. + +### A Beolvadás utáni infláció részletezése {#post-merge-inflation-breakdown} + +- Teljes ETH-kínálat: **~120 520 000 ETH** (a Beolvadás idején, 2022. szeptemberben) +- A végrehajtási réteg kibocsátása: **0** +- A konszenzusréteg kibocsátása: A fentivel megegyezik, **kb. 0,52%** éves kibocsátási ráta (14 millió letétbe helyezett ETH-szel) + + +Teljes éves kibocsátási ráta: kb. 0,52%

+Az éves ETH kibocsátás nettó csökkenése: kb. 88,7% ((4,61% – 0,52%) / 4,61% * 100) + + +##  Az elégetés {#the-burn} + +Az ETH kibocsátással ellenkező erő az a ráta, ahogy az ETH-t elégetik. Az Ethereumon végrehajtandó tranzakcióért fizetni kell egy minimális díjat (alapdíj), amely állandóan változik, blokkról blokkra, a hálózati működés függvényében. Ezt a díjat ETH-ben fizetik, és _elengedhetetlen_ ahhoz, hogy egy tranzakció érvényes legyen. Ezt a díjat _elégetik_ a tranzakció végrehajtása során, így kikerül a körforgásból. + + +A díj elégetése a London-frissítés óta (2021. augusztus) működik, és a Beolvadás óta változatlan. + + +A bevezetett díj elégetése mellett a validátorok büntetéseket is kaphatnak azért, ha nincsenek online, vagy ami még rosszabb, ha olyan szabályokat hágnak át, amely a hálózat biztonságát veszélyeztetik, akkor az súlyos büntetéssel és kizárással jár. Ezek a büntetések lecsökkentik az ETH-t a validátor számláján, ami utána nem kerül máshova, tehát lényegében kivonják a forgalomból vagy elégetik. + +### A deflációhoz szükséges átlagos gázdíj kiszámítása {#calculating-average-gas-price-for-deflation} + +Az ETH kibocsátása egy adott napon a teljese letétbe helyezett ETH-től függ. A jelen leírás idején ez kb. 1700 ETH/nap. + +Ahhoz, hogy meghatározzuk azt az átlagos gázdíjat, ami ellensúlyozza ezt az ETH-kibocsátást egy 24 órás periódusban, először kiszámoljuk a blokkok számát az adott napon, tekintve, hogy a blokkidő 12 másodperc: + +- `(1 blokk / 12 másodperc) * (60 másodperc/perc) = 5 blokk/perc` +- `(5 blokk/perc) * (60 perc/óra) = 300 blokk/óra` +- `(300 blokk/óra) * (24 óra/nap) = 7200 blokk/nap` + +Minden blokk a `15x10^6 gáz/blokk` összeget célozza ([Bővebben a gázról](/developers/docs/gas/)). Ez alapján kiszámolhatjuk az átlagos gázdíjat (gwei/gáz), ami kiegyensúlyozza az ETH-kibocsátást, a napi kibocsátást 1700 ETH-nek véve: + +- `7200 blokk/nap * 15x10^6 gáz/blokk *`**`Y gwei/gáz`**`* 1 ETH/ 10^9 gwei = 1700 ETH/nap` + +Megoldva az `Y-ra`: + +- `Y = (1700(10^9))/(7200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 gwei` (két számjegyre kerekítve) + +Egy másik módon rendezve ezt egy `X` változót tehetünk az `1700` helyére, ami a napi ETH-kibocsátás, a többit pedig leegyszerűsítve: + +- `Y = (X(10^3)/(7200 * 15)) = X/108` + +Leegyszerűsíthetjük úgy, hogy az `X` függvényét írjuk fel: + +- `f(X) = X/108`, ahol `X` a napi ETH-kibocsátás, és az `f(X)` jelenti gwei/gáz árat, amely ellensúlyozni tudja az újonnan kibocsátott ETH-t. + +Tehát ha az `X` (napi ETH kibocsátás) megnövekszik 1800-ra a teljes letétbe helyezett ETH alapján, `f(X)` (gwei, amivel kiegyensúlyozható a kibocsátás) ekkor `17 gwei` lesz (2 számjegyre kerekítve) + +## További olvasnivaló {#further-reading} + +- [A beolvadás](/roadmap/merge/) +- [Ultrasound.money](https://ultrasound.money/) – _Dashboardok az ETH-kibocsátás és -elégetés valós idejű vizualizációjára_ +- [Az Ethereum-kibocsátás grafikonos ábrázolása](https://www.attestant.io/posts/charting-ethereum-issuance/) – _Jim McDonald 2020._ diff --git a/public/content/translations/hu/11) Roadmap/roadmap/scaling/index.md b/public/content/translations/hu/11) Roadmap/roadmap/scaling/index.md new file mode 100644 index 00000000000..ae4ba29b790 --- /dev/null +++ b/public/content/translations/hu/11) Roadmap/roadmap/scaling/index.md @@ -0,0 +1,51 @@ +--- +title: Az Ethereum skálázása +description: A összevont tranzakciók összekötegelik a tranzakciókat a láncon kívül, ezzel csökkentve a felhasználó költségét. Az összesítések jelenlegi adatfelhasználásának módja azonban túl drága, ami korlátozza a tranzakciók olcsóságát. Erre a Proto-Danksharding nyújt megoldást. +lang: hu +image: /images/roadmap/roadmap-transactions.png +alt: "Ethereum-ütemterv" +template: roadmap +--- + +Az Ethereum skálázása a [layer 2s](/layer-2/#rollups) második blokkláncréteg (L2), vagy más néven összevont tranzakciók által történik, ami kötegbe rendezi a tranzakciókat és az eredményt beküldi az Ethereumra. Habár az összevont tranzakciók költsége a nyolcada az Ethereum főhálózaténak, még mindig van hova optimalizálni a működésüket és ezzel csökkenteni a felhasználók költségét. A összevont tranzakciók emellett néhány centralizált komponensre támaszkodnak, amelyet a fejlesztők eltávolíthatnak majd, ahogy az összevont tranzakciók fejlődik. + + +
    +
  • Ma az összevont tranzakciók kb. 5–20× olcsóbbak, mint az Ethereum L1
    • +
  • A ZK összevont tranzakciók esetében hamarosan ~40–100× alacsonyabb lesz a díj
    • +
  • Az eljövendő Ethereum-módosítások további ~100–1000×-szoros skálázást tesznek lehetővé
    • +
  • A felhasználók számára egy tranzakció kevesebb mint 0,001 $-ba fog kerülni
    • +
+ + +## Az adatok olcsóbbá tétele {#making-data-cheaper} + +A összevont tranzakciók sok tranzakciót gyűjtenek össze, végrehajtják azokat és az eredményt az Ethereumra küldik. Ez rengeteg adatot jelent, amelyet nyíltan elérhetővé kell tenni bárki számára, hogy lefuttathassa a tranzakciókat és ellenőrizze, hogy az összevont tranzakció operátora jóhiszeműen járt el. Ha valaki talál egy eltérést, akkor megkérdőjelezheti azt. + +### Proto-Danksharding {#proto-danksharding} + +Az összevont tranzakciós adatok korábban tartósan az Ethereumon maradtak, ami drága volt. Az összevont tranzakciók tranzakciós költségeinek több mint 90%-át az adattárolás teszi ki. A tranzakciós költségek csökkentéséhez az adatot egy új átmeneti blob tárhelyre mozgathatjuk. A blob olcsóbb, mert nem tartós; törölhetők az Ethereumról, amint már nincs rájuk szükség. Az összevont tranzakciós adatok hosszú távon azoknak a felelősségébe tartoznak, akiknek szükségük van azokra, mint például az összevont tranzakciós operátorok, tőzsdék, indexáló szolgáltatások stb. Az Ethereum blob-tranzakcióval való kiegészítése a „Proto-Danksharding” néven ismert frissítés része. + +A Proto-Danksharding segítségével sok blobot lehet hozzáadni az Ethereum blokkokhoz. Ez egy újabb jelentős (több mint 100×) skálázási lehetőség az Ethereum tranzakcióátvitelét illetően és a költségek csökkentésére. + +### Dank-féle párhuzamos futtatás (Danksharding) {#danksharding} + +A blob adatok bővítésének második szakasza bonyolult, mert új módszereket igényel az összesítő adatok hálózaton való elérhetőségének ellenőrzéséhez, és [ellenőrzőkre](/glossary/#validator) támaszkodik, amelyek elválasztják a [blokk](/glossary/#block) felépítési és blokkjavaslat-feladatokat. Kell hozzá egy olyan módszer is, amely kriptográfiailag bizonyítja, hogy a validátor igazolta a blobadat egy kis részét. + +Ez a második lépés a [Danksharding](/roadmap/danksharding/). **Valószínűleg több év múlva** a teljes megvalósításig. A Danksharding más fejlesztéseken is múlik, mint a [PBS](/roadmap/pbs) és új hálózati dizájn, hogy a hálózat hatékonyan tudja konfirmálni, hogy az adatok elérhetők, azáltal hogy véletlenszerűen néhány kilobájtos mintát választ egy adott időben, ezt [adat-elérhetőségi mintavételnek (DAS)](/developers/docs/data-availability) nevezzük. + +Bővebben a Dankshardingról + +## Az összevont tranzakciók decentralizálása {#decentralizing-rollups} + +Az [összevont tranzakciók](/layer-2) már most is gondoskodnak az Ethereum méretezhetőségéről. Az [összevont tranzakciós projektek gazdag ökoszisztémája](https://l2beat.com/scaling/tvl) teszi lehetővé, hogy a felhasználó gyorsabban és olcsóbban indítson tranzakciót, a biztonsági garanciák széles körét kiélvezve. Ugyanakkor az összevont tranzakciók centralizált szekvenszert használnak (ami feldolgozza a tranzakciókat és aggregálja azokat, mielőtt az Ethereumra küldené). Ez lehetővé teszi a cenzúrát, mivel a szekvenszeroperátorokat meg lehet büntetni, vesztegetni vagy máshogy veszélyeztetni. Emellett az [összevont tranzakciók eltérnek abban](https://l2beat.com), hogyan validálják a bejövő adatokat. A legjobb módja a „bizonyítók” [csalási bizonyítékok](/glossary/#fraud-proof) vagy érvényességi igazolások benyújtása, de még nincs meg minden összesítés. Még ahol léteznek is ilyen érvényesítési/csalásbiztos összevont tranzakciók, ott is csak kevés bizonyítót használnak. Ezért a következő fontos lépés az Ethereum skálázásban, hogy elossza a szekvenszer és a bizonyító felelősségét több emberre. + +Bővebben az összevont tranzakciókról + +## Jelenlegi helyzet {#current-progress} + +A Proto-Danksharding az első ilyen ütemterv, amelyet a Cancun-Deneb („Dencun”) hálózatfrissítés részeként hajtanak végre 2024 márciusában. **A teljes Danksharding valószínűleg több év múlva lesz elérhető**, mivel számos egyéb ütemtervelemtől függ először. Az összevont tranzakciók infrastruktúrájának decentralizálása egy fokozatos folyamat lesz – több különböző összevont tranzakció létezik, amelyek kicsit más felállásban működnek, és más rátán fogják tudni elvégezni a decentralizálást. + +[További információ a Dencun hálózatfrissítésről](/roadmap/dencun/) + + diff --git a/public/content/translations/hu/11) Roadmap/roadmap/security/index.md b/public/content/translations/hu/11) Roadmap/roadmap/security/index.md new file mode 100644 index 00000000000..19f667b706c --- /dev/null +++ b/public/content/translations/hu/11) Roadmap/roadmap/security/index.md @@ -0,0 +1,48 @@ +--- +title: Biztonságosabb Ethereum +description: Az Ethereum a legbiztonságosabb és leginkább decentralizált okosszerződés-platform a világon. Azonban még mindig vannak fejlődési lehetőségek, hogy az Ethereum ellenálló maradjon minden szinten a támadásokkal szemben a jövőben is. +lang: hu +image: /images/roadmap/roadmap-security.png +alt: "Ethereum-ütemterv" +template: roadmap +--- + +Az **Ethereum már egy nagyon biztonságos**, decentralizált [okosszerződéses](/glossary/#smart-contract) platform. Azonban még mindig vannak fejlődési lehetőségek, hogy az Ethereum ellenálló maradjon mindenféle támadással szemben a jövőben is. Ezek közé tartozik az [Ethereum-kliensek](/glossary/#consensus-client) versengő [blokkokkal](/glossary/#block) való kezelésének finom módosítása, valamint a hálózat által a blokkok [„véglegesítettnek”](/developers/docs/consensus-mechanisms/pos/#finality) történő megnövelése. (ami azt jelenti, hogy nem változtathatók meg anélkül, hogy rendkívüli gazdasági veszteséget okoznának a támadónak). + +Olyan fejlesztések is folyamatban vannak, amelyek a tranzakciók cenzúrázását nehezítik meg, azáltal hogy a blokkjavasló nem tudja, mit tartalmaz az adott blokk, és új módokat kínál annak megállapítására, hogy egy kliens cenzúráz-e. Ezek a fejlesztések együtt frissítik a [tét bizonyítéka](/glossary/#pos) protokollt, hogy a felhasználók – magánszemélyektől a vállalatokig – azonnal megbízhassanak alkalmazásaikban, adataikban és eszközeikben az Ethereumban. + +## A letétbe helyezés visszavonása {#staking-withdrawals} + +A [proof-of-work](/glossary/#pow)-ről a tét-igazolásra való frissítés azzal kezdődött, hogy az Ethereum úttörői „kockáztatták” ETH-jukat egy letéti szerződésben. Ez az ETH arra van, hogy megvédje a hálózatot. 2023. április 12-én egy második frissítés is megtörtént, amely lehetővé teszi a téttel járó ETH visszavonását. Azóta a validátorok szabadon tétet tehetnek vagy visszavonhatnak ETH-t. + +Bővebben a visszahívásokról + +## Támadások elleni védelem {#defending-against-attacks} + +Vannak fejlesztések, amelyek az Ethereum proof-of-stake protokollját érintik. Az egyik a [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) néven ismert – egy biztonságosabb [elágazás](/glossary/#fork)-választási algoritmus, amely megnehezít bizonyos kifinomult támadástípusokat. + +Az Ethereumnak a blokkok [véglegesítéséhez](/glossary/#finality) szükséges idő csökkentése jobb felhasználói élményt biztosítana, és megakadályozná az olyan kifinomult „reorg” támadásokat, amelyek során a támadók megpróbálják átrendezni a legutóbbi blokkokat, hogy profitot vonjanak ki, vagy bizonyos tranzakciókat cenzúrázzanak. Az [**Single slot finality (SSF)**](/roadmap/single-slot-finality/) egy **módszer a véglegesítési késleltetés minimalizálására**. Jelenleg 15 percnyi blokk esetén tudna egy támadó elméletileg meggyőzni egy másik validátort, hogy újrakonfigurálja azokat. Az SSF esetén ez 0 lenne. A felhasználók számára, kezdve az egyénektől egészen az alkalmazásokig és tőzsdékig, mindig hasznos, ha gyorsan lehet biztosítani, hogy a tranzakcióik ne lesznek visszafordítva, a hálózatnak pedig az, hogy a támadások teljes osztályait ki tudja zárni. + +Bővebben az egy sloton belüli véglegességről (SSF) + +## A cenzúra elleni védelem {#defending-against-censorship} + +A decentralizáció megakadályozza, hogy egyének vagy [ellenőrzők](/glossary/#validator) kis csoportjai túlságosan befolyásossá váljanak. Az új letéti technológiák segítenek, hogy az Ethereum validátorai decentralizáltak maradjanak, miközben védi őket a hardver-, szoftver- és hálózati hibáktól. Ide tartoznak azok a szoftverek is, amelyek több [csomópont](/glossary/#node) között osztják meg az érvényesítői felelősséget. Ez az **elosztottvalidátor-technológia (DVT)**. A [letéti alapokat](/glossary/#staking-pool) ez ösztönzi, hogy használják a DVT-t, így több számítógép vehet részt egyszerre a validációban, ezzel redundanciával (extra kapacitás) és hibatoleranciával kiegészítve a működést. A validátorkulcsokat több rendszerre osztja el ahelyett, hogy egy operátor futtatna több validátort. Ezáltal a rosszhiszemű operátoroknak nehezebb támadást indítani az Ethereum ellen. Összességében további biztonsági előnyökkel járhat, ha a validátorok _közösségként_ működnek, nem egyénként. + +Bővebben az elosztottvalidátor-technológiáról (DVT) + +Az **előterjesztő-építő szétválasztás (PBS)** drasztikusan fejleszti az Ethereum beépített, cenzúrának való ellenállást. A PBS lehetővé teszi, hogy egy validátor rakja össze a blokkot, egy másik pedig továbbadja az Ethereum-hálózatnak. Ez biztosítja, hogy a professzionális profitmaximalizáló blokképítő algoritmusokól eredő nyereségek majd egyenletesebben oszoljanak el a hálózaton, **megakadályozva a letétek koncentrációját** a legjobban működő intézményes letéteseknél. A blokk előterjesztője a leginkább profitábilis blokkot választja azok közül, amit a blokképítők piaca ajánl. A cenzúrához a blokk előterjesztőjének gyakran egy kevésbé profitábilis blokkot kellene választania, ami **gazdaságilag irracionális és nyilvánvaló a többi validátor számára is** a hálózaton. + +Olyan potenciális kiegészítések is elérhetők a PBS-hez, mint a titkosított tranzakciók és a bekerülési lista, ami tovább növeli az Ethereum cenzúrának való ellenállást. Ezek következtében a blokk építője és javaslója nem tudja, hogy milyen tranzakciók vannak a blokkban. + +Bővebben a PBS-ről + +## A validátorok védelme {#protecting-validators} + +Lehetséges, hogy egy szofisztikált támadó beazonosítja a következő validátort és megakadályozza őt a javaslattételben; ez a **szolgáltatásmegtagadási, vagy más néven DoS**-támadás. A [**titkos vezetőválasztás (SLE)**](/roadmap/secret-leader-election) bevezetése megvéd ettől a támadási típustól, mivel a blokkjavaslók nem lesznek előre ismertek. Úgy működik, hogy a blokkjavaslókat képviselő kriptográfiai elköteleződéseket állandón keverik, és ezek sorrendje adja meg, hogy amelyik validátor kerül kiválasztásra, amiről csak ő fog tudni. + +Bővebben a titkos vezetőválasztásról + +## Jelenlegi helyzet {#current-progress} + +**Az ütemtervben szereplő biztonsági frissítések a kutatás előrehaladott szakaszában vannak**, de várhatóan még egy ideig nem hajtják végre őket. A következő lépés a nézetegyesítésre (amelyeket még nem valósítottak meg élesben) a specifikáció véglegesítése és a prototípusok létrehozása. diff --git a/public/content/translations/hu/11) Roadmap/roadmap/user-experience/index.md b/public/content/translations/hu/11) Roadmap/roadmap/user-experience/index.md new file mode 100644 index 00000000000..8903f1fdf84 --- /dev/null +++ b/public/content/translations/hu/11) Roadmap/roadmap/user-experience/index.md @@ -0,0 +1,36 @@ +--- +title: A felhasználói élmény javítása +description: A legtöbb ember számára még mindig túl bonyolult az Ethereum használata. A tömeges használathoz az Ethereumnak drasztikusan csökkentenie kell ezt az akadályt – mindenki számára előnyösnek kell lennie a decentralizált, engedélymentes és cenzúrának ellenálló Ethereum-hozzáférésnek, ugyanakkor olyan könnyednek kell lennie, mint a hagyományos web2 alkalmazás használata. +lang: hu +image: /images/roadmap/roadmap-ux.png +alt: "Ethereum-ütemterv" +template: roadmap +--- + +**Az Ethereum használatát egyszerűsíteni kell**; a [kulcsok](/glossary/#key) és [pénztárcák](/glossary/#wallet) kezelésétől a tranzakciók kezdeményezéséig. A tömeges elterjedtség elősegítése érdekében az Ethereumnak drasztikusan javítania kell a használat egyszerűsítését, lehetővé téve a felhasználók számára az engedély nélküli és cenzúraálló hozzáférést az Ethereumhoz a [Web2](/glossary/#web2) alkalmazások súrlódásmentes használatának élményével. + +## A kulcsmondatokon túl {#no-more-seed-phrases} + +Az Ethereum-számlákat egy kulcspár védi, amelyek a számla azonosítását (nyilvános kulcs) és az üzenetek aláírását (privát kulcs) szolgálják. A privát kulcs olyan, akár egy mesterjelszó; teljes hozzáférést biztosít az Ethereum-számlához. Ez egy más megközelítés, mint amelyet a legtöbb felhasználó ismer, akik a bankokra és web2-alkalmazásokra bízzák a számlák kezelését. Az Ethereum tömeges használatának eléréséhez egyértelmű és könnyed utat kell mutatni a felhasználóknak, hogyan anélkül felügyelhessék eszközeiket és adataikat, hogy érteniük kellene a nyilvános-privát kulcsok kriptográfiájához és a kulcskezeléshez. + +A megoldás az [intelligens szerződéses](/glossary/#smart-contract) pénztárcák használata az Ethereummal való interakcióhoz. Az okosszerződéses tárcák képesek megvédeni a számlát, ha a kulcsok elvesznek vagy ellopják azokat, jobban ellenállnak a csalásnak és támadásnak, és új funkciók használatát is lehetővé teszik a tárcákban. Habár okosszerződéses tárcák már most is léteznek, de nagyon nehézkes megépíteni azokat, mert az Ethereum-protokollnak jobban kellene azokat támogatni. Ezt az extra támogatást nevezzük számlaabsztrakciónak. + +Bővebben a számlaabsztrakcióról + +## Csomópont mindenkinek + +A [csomópontokat](/glossary/#node) futtató felhasználóknak nem kell megbízniuk harmadik felekben abban, hogy adatokat szolgáltatjanak nekik, és gyorsan, privát módon és engedély nélkül kommunikálhatnak az Ethereum [blokkláncával](/glossary/#blockchain). Azonban a csomópont jelenlegi működtetése technikai tudást és jelentős merevlemez-kapacitást igényel, így a legtöbb felhasználónak másokhoz kell fordulnia. + +Számos fejlesztés meg fogja könnyíteni a csomópontok működtetését és csökkenti erőforrásigényüket. Az adatok tárolásához egy sokkal kevesebb tárhelyet igénylő struktúrát fognak használni, amit **Verkle fának** neveznek. Emellett a [státusztalanság](/roadmap/statelessness) és az [adatok lejárata](/roadmap/statelessness/#data-expiry) miatt a csomópontoknak nem kell majd a teljes Ethereum-státuszadatát tárolniuk, jelentősen lecsökkentve a merevlemezigényeket. A [könnyű kliensek](/developers/docs/nodes-and-clients/light-clients/) is rengeteg előnyt nyújtanak a teljes csomópontok üzemeltetéséhez, mivel ezeket mobileszközökről vagy egyszerű böngészőalkalmazásokból is futtatni lehet majd. + +Bővebben a Verkle-fákról + +Ezekkel az fejlesztésekkel gyakorlatilag nullára csökken a csomópontfuttatás akadálya. A felhasználók biztonságos, engedélymentes hozzáférést nyernek az Ethereumhoz, anélkül hogy komoly lemezterületet vagy CPU-t áldoznának erre, és nem kell harmadik félhez fordulniuk adatért vagy a hálózat eléréséhez, amikor alkalmazásokat használnak. + +## Jelenlegi helyzet {#current-progress} + +Az okosszerződéses tárcák már elérhetők, de több fejlesztésre van szükség, hogy még decentralizáltabbak és engedélymentesek legyenek. Az EIP-4337 egy olyan javaslat, ami már nem igényli az Ethereum-protokoll komoly módosítását. Az EIP-4337-hez szükséges fő intelligens szerződést **2023 márciusában vezették be**. + +**A teljes hontalanság még a kutatási fázisban van**, és valószínűleg több év múlva kerül végrehajtásra. Ehhez még számos mérföldkövet el kell érni, ilyen például az adatok lejárata is, amelyek hamarabb bevezetésre kerülhetnek. A többi tervezett fejlesztésnek, mint a [Verkle-fáknak](/roadmap/verkle-trees/) és a [javaslattevő-építő szétválasztásnak](/roadmap/pbs/) előbb meg kell valósulnia. + +A Verkle-fás teszthálózatok már használhatók, a következő lépés a Verkle-fákkal működő kliensek privát és nyilvános teszthálózaton való futtatása. Ön is segíthet a fejlesztés meggyorsításában, ha szerződéseket hoz létre a teszthálózaton és klienseket működtet a teszthez. diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/account-abstraction/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/account-abstraction/index.md new file mode 100644 index 00000000000..a683d64e2ac --- /dev/null +++ b/public/content/translations/hu/12) Roadmap 2/roadmap/account-abstraction/index.md @@ -0,0 +1,126 @@ +--- +title: Számlaabsztrakció +description: Az Ethereum tervek áttekintése azzal kapcsolatban, hogy a felhasználói számlák egyszerűbbek és biztonságosabbak legyenek +lang: hu +summaryPoints: + - A számlaabsztrakció sokkal egyszerűbbé teszi az okosszerződéses tárcák építését + - Az okosszerződéses tárcák egyszerűbbé teszik az Ethereum számlákhoz való hozzáférés menedzselését + - Az elvesztett vagy nyilvánossá vált kulcsokat többféle biztonsági megoldással is vissza lehet nyerni +--- + +# Számlaabsztrakció {#account-abstraction} + +A felhasználók **[külső tulajdonú számlák (EOA)](/glossary/#eoa)** révén kapcsolódnak az Ethereumhoz. Ez az egyetlen módja, hogy egy tranzakciót kezdeményezzenek vagy elindítsanak egy okosszerződést. Ez behatárolja azt, ahogyan a felhasználók az Ethereummal kapcsolatba léphetnek. Nehézkessé teszi például, hogy tranzakciókötegeket hajtsanak végre és a felhasználóknak mindig tartani kell ETH-t, hogy fedezzék a tranzakciók költségeit (gáz). + +A számlaabsztrakció egy olyan mód, amely megoldást ad ezekre a problémákra azáltal, hogy a felhasználók rugalmasabban adhatnak több biztonságot a számláikhoz, illetve jobb felhasználói élményben lehet részük. Ehhez arra van szükség, hogy [EOA-kat fejleszteni kell](https://eips.ethereum.org/EIPS/eip-3074), hogy okosszerződéssel is lehessen azokat irányítani, vagy [az okosszerződéseket kell fejleszteni](https://eips.ethereum.org/EIPS/eip-2938) úgy, hogy tranzakciókat tudjanak kezdeményezni. Mindkét opcióhoz módosítani kell az Ethereum-protokollt. Egy harmadik megoldás is lehetséges, ahol egy [második, elkülönült tranzakciós rendszert](https://eips.ethereum.org/EIPS/eip-4337) hoznak létre, hogy a meglévő protokollal párhuzamosan működjön. A megoldási módtól függetlenül az eredmény az, hogy az Ethereumot okosszerződéses tárcákkal, a meglévő protokoll támogatásával vagy egy hozzáadott tranzakciós hálózattal is el lehet érni. + +Az okosszerződéses tárcák számos előnnyel járnak a felhasználók számára: + +- beállíthatják a saját rugalmas biztonsági szabályaikat +- a számlát vissza lehet állítani akkor is, ha a kulcsok elvesztek +- a számla biztonságát meg lehet osztani megbízható eszközökkel vagy egyénekkel +- lehet gázt fizetni más helyett, illetve helyettünk is fizethet más +- a tranzakciókat össze lehet kötegelni (pl. az átváltásokat egyszerre jóvá lehet hagyni és végrehajtani) +- az alkalmazás- (dapp) és tárcafejlesztőknek több lehetőségük van, hogy javítsák a felhasználói élményeket + +Jelenleg ezek az előnyök nem érhetők el, mert csak a külső tulajdonú számlák ([EOA](/glossary/#eoa)) indíthatnak tranzakciókat. Az EOA-k lényegileg egy nyilvános-privát kulcspárból állnak. Így működnek: + +- aki rendelkezik egy privát kulccsal, az _bármit_ megtehet az Ethereum Virtuális Gép (EVM) szabályain belül +- aki nem rendelkezik a privát kulccsal, az _semmit_ sem tehet. + +Ha a kulcsok elvesznek, akkor nem lehet azokat visszaszerezni, illetve az ellopott kulcsok azonnali hozzáférést adnak a számlán lévő eszközökhöz. + +Az okosszerződéses tárcák megoldást tudnak ezekre adni, de jelenleg nehéz programozni ezeket, mert minden egyes logikát a végén le kell fordítani egy adag EOA-tranzakcióra, hogy azokat végre lehessen hajtani az Ethereumon. A számlaabsztrakció lehetővé teszi az okosszerződések számára, hogy tranzakciókat indítsanak el, ezért a felhasználó bármilyen általa kívánt logikát be tud kódolni az okosszerződéses tárcába és azt végre tudja hajtatni az Ethereumon. + +Végül a számlaabsztrakció fejleszti az okosszerződéses tárcák támogatását, mivel egyszerűbb lesz azokat megépíteni és biztonságosabb lesz használni. A számlaabsztrakció révén a felhasználók az Ethereum összes előnyét kiélvezhetik, és nem kell tudniuk vagy foglalkozniuk a mögöttes technológiával. + +## A kulcsmondatokon túl {#beyond-seed-phrases} + +Jelenleg a számlákat a privát kulcsok használata védi, amelyet kulcsmondatokból állítanak elő. Aki hozzáfér a kulcsmondathoz, az könnyen fel tudja fedezni a számlát védő privát kulcsot, így hozzáférhet a számla eszközeihez. Ha a privát kulcs és a kulcsmondat elvész, akkor azokat már nem lehet visszanyerni és a számlán tárolt eszközök örökre be lesznek fagyasztva. A kulcsmondatok biztonságos tárolása elég kényelmetlen még a szakértő felhasználók számára is, és az ezekre irányuló adathalászat a fő oka annak, hogy a felhasználókat átverik. + +A számlaabsztrakció esetében az okosszerződés tárolja a eszközöket és hagyja jóvá a tranzakciókat. Ezeket az okosszerződéseket személyre szabott logikával lehet működtetni, hogy a lehető legbiztonságosabbak legyenek és a felhasználóra legyenek szabva. A felhasználó még mindig privát kulcsokat használ ahhoz, hogy a számlát irányítsa, de azt biztonsági hálóval együtt teszi, amely könnyebbé és biztonságosabbá teszi a kezelést. + +Például olyan biztonsági kulcsok adhatók a tárcához, hogy ha valaki elveszíti vagy véletlenül feltárja a fő kulcsát más előtt, akkor azt kicserélheti egy új, biztonságos kulcsra, amelyet a biztonsági kulcs engedélyez. A különféle kulcsot más-más módon biztosíthatja a felhasználó, vagy megbízott őrzők között is feloszthatja azt. Ezáltal sokkal nehezebbé válik a csalóknak, hogy teljes kontrollt szerezzenek az eszközök felett. Hasonlóképpen szabályokat is hozzáadhat a pénztárcához, hogy csökkentse a fő kulcsának veszélyeztetettségét, például lehetővé teheti az alacsony értékű tranzakciók egyetlen aláírással történő ellenőrzését, míg a nagyobb értékű tranzakciókhoz több hitelesített aláíró jóváhagyása szükséges. Az intelligens szerződéses pénztárcák más módokon is segíthetnek a tolvajok meghiúsításában, például egy engedélyezési lista segítségével blokkolhat minden tranzakciót, kivéve, ha az megbízható címre érkezik, vagy ha nem igazolja több előre jóváhagyott kulccsal. + +### Néhány példa arra, hogy milyen biztonsági logikákat lehet beépíteni az okosszerződéses tárcába: + +- **Többaláírásos jóváhagyás**: A jóváhagyásra való meghatalmazást meg lehet osztani több megbízható ember vagy eszközök között. Ekkor a szerződést úgy lehet beállítani, hogy egy előre meghatározott érték feletti tranzakció jóváhagyást kérjen a megbízott felek egy adott arányától (pl. 5-ből 3-tól). Egy magas értékű tranzakció például jóváhagyást kérhet egy mobileszköztől és egy hardvertárcától egyszerre, vagy a megbízott családtagok között megosztott számláktól igényelhet aláírást. +- **Számlabefagyasztás**: Ha egy eszköz elveszett vagy más kezébe került, akkor a számlát be lehet fagyasztani egy másik jóváhagyott eszközről, ezzel megvédve a felhasználó eszközeit. +- **Számla-visszaállítás**: Elveszett az eszköz vagy elfelejtette a jelszót? A jelenlegi felállásban ez azt jelenti, hogy a számlán tartott eszközök örökre befagyasztva maradnak. Az intelligens szerződéses pénztárcával beállíthat egy engedélyezési listát azokról a fiókokról, amelyek engedélyezhetik az új eszközöket és visszaállíthatják a hozzáférést. +- **Tranzakciólimitek beállítása**: Napi határértéket lehet megadni arra vonatkozóan, hogy milyen értéket lehet áttranszferálni az adott számláról egy nap/hét/hónap alatt. Tehát ha egy támadó hozzáférést szerez a számlához, akkor nem tudja egyszerre kiüríteni azt, a tulajdonos pedig be tudja azt fagyasztani és visszaállítani a saját hozzáférést. +- **Engedélyezőlisták létrehozása**: Csak bizonyos címekre engedélyezi a tranzakciókat, amelyekről tudja, hogy biztonságosak. Ez azt jelenti, hogy _még ha_ a privát kulcsát ellopták is, a támadó csak a listán szereplő célszámlákra küldhet pénzt. Ezekhez az engedélyezési listákhoz több aláírásra lenne szükség a módosításukhoz, így a támadók csak akkor vehetik fel a saját címüket a listára, ha hozzáfértek több biztonsági kulcshoz. + +## Jobb felhasználói élmény {#better-user-experience} + +A számlaabsztrakció lehetővé teszi a **jobb felhasználói élményt** és **a magasabb fokú biztonságot**, mert támogatást biztosít az okosszerződéses tárcának a protokoll szintjén. Ez a megoldás az okosszerződések, tárcák és alkalmazások fejlesztőinek olyan szintű szabadságot ad az innovációra a felhasználói élményt illetően, olyan módokon, amiket most még elképzelni sem tudunk. Néhány egyértelmű fejlesztés a számlaabsztrakció mellett többek között az, hogy a tranzakciókat kötegelni lehet a gyorsaság és a hatékonyság érdekében. Például egy egyszerű swapnak egy kattintásos műveletnek kell lennie, de manapság több tranzakció aláírása szükséges ahhoz, hogy jóváhagyják az egyes tokenek elköltését a csere végrehajtása előtt. A számlaabsztrakcióval megszűnik ez a többszörös jóváhagyás, mert a tranzakciókat össze lehet kötegelni. Emellett a kötegelt tranzakciókat úgy hagyja jóvá a felhasználó, hogy a tokeneknek a megfelelő értéke szerepel benne, majd a végrehajtás után visszavonja a jóváhagyást, ezzel fokozva a biztonságot. + +A gáz, vagyis a tranzakciós díjak kezelése is sokkal fejlettebbé válik a számlaabsztrakcióval. Az alkalmazások felajánlhatják, hogy kifizetik a felhasználók gázdíját, továbbá a gázt más tokenben is lehet rendezni, nem csak ETH-ben, így a felhasználóknak nem kötelező ETH-összeget tartani a számlájukon, hogy a tranzakciókat finanszírozni tudják. Ez úgy valósul meg, hogy a szerződésen belül a felhasználó tokenjeit átváltják ETH-re, és ebben fizetik ki a gázt. + + + +A gázdíjak kezelése az egyik fő gond az Ethereum-felhasználók számára, mert csak ETH-ben lehet azt rendezni. Tegyük fel, hogy van egy tárca USDC-egyenleggel, de nincs benne ETH. Akkor az USDC-tokeneket nem tudja a tulajdonos elküldeni vagy átváltani, mert nem tudja kifizetni a gázdíjat. Nem lehet átváltani az USDC-t ETH-re, mert ez önmagában gázdíjat igényel. Ennek megoldásához ETH-t kell beküldeni a számlára egy tőzsdéről vagy egy másik címről. Az okosszerződéses tárcákkal ki lehet fizetni a gázdíjat a számlán tartott USDC-ből, így szabadon használható a számla. Ennek köszönhetően nem kell ETH-egyenleget tartani az összes számlán. + +A számlaabsztrakció lehetővé teszi a dapp fejlesztőknek azt is, hogy a gázdíj kezelésében kreatívak legyenek. Például a kedvenc tőzsdéjének a felhasználó akár fix díjat is fizethetne havonta korlátlan mennyiségű tranzakcióért. A dappok felajánlhatják, hogy kifizetik az összes gázdíjat a felhasználó helyett, ezzel jutalmazva őket, hogy az adott platformot használják, vagy belépési ajánlat gyanánt. A fejlesztőknek könnyebb lesz innovatív módon hozzáállni a gázhoz, amikor az okosszerződéses tárcákat protokollszinten támogatják. + + + +A megbízható periódus használata is jelentős hatással lehet a felhasználói élményekre, főleg olyan alkalmazásoknál, mint a játékok, ahol sok kis értékű tranzakciót kell rövid időn belül jóváhagyni. Ha egyesével kell a tranzakciókat engedélyezni, akkor az megtöri a játék élményét, de az állandó jóváhagyás nem lenne biztonságos. Az okosszerződéses tárca engedélyezni tudna bizonyos tranzakciókat egy fix időre, egy meghatározott értékig vagy csak egy bizonyos címre. + +Érdekes azt is átgondolni, hogyan alakulnak a váráslások a számlaabsztrakcióval. Jelenleg minden tranzakciót jóvá kell hagyni és végre kell hajtani a tárcából úgy, a megfelelő token kellő összege rendelkezésre áll. A számlaabsztrakcióval ez az élmény inkább olyan lehet, mint egy online vásárlás, ahol a felhasználó beleteszi a tételeket a kosarába, egyszerre fizeti ki az összeset, és a szerződés kezeli azokat a logikákat, amelyek ehhez szükségesek. + +Ez csak néhány példa arra, hogy a felhasználói élmény hogyan fejlődhet a számlaabsztrakcióval, ám ennél sokkal több is lehetségessé válik. A számlaabsztrakció felszabadítja a fejlesztőket a jelenlegi EOA-k kötöttségei alól, behozhatják a web2 jó szempontjait a web3-ba anélkül, hogy feláldoznák az eszközök fölötti saját felügyeletet, illetve kreatív módon javíthatják a felhasználói élményeket. + +## Hogyan kerül bevezetésre a számlaabsztrakció? {#how-will-aa-be-implemented} + +Az okosszerződéses tárcák most is léteznek, de kihívásokkal teli a megvalósításuk, mert az EVM nem támogatja azokat. Ehelyett azon alapulnak, hogy elég összetett kódokba burkolják a standard Ethereum-tranzakciókat. Az Ethereum képes ezt megváltoztatni azáltal, hogy megengedi az okosszerződéseknek a tranzakciókezdeményezést, így az Ethereum okosszerződésbe lehet kódolni a szükséges logikákat, nem pedig a láncon kívül kezelni azokat. Az okosszerződésbe írt logikák növelik az Ethereum decentralizációját is, mivel nem lesz szükség a tárcafejlesztők által működtetett közvetítőkre, hogy lefordítsák a felhasználók által aláírt üzeneteket Ethereum-tranzakciókká. + + + +EIP-2771 a metatranzakció koncepcióját vezeti be, amelynek révén egy harmadik személy kifizetheti a felhasználó gázdíját anélkül, hogy ehhez változtatni kellene az Ethereum protokollon. Eszerint a felhasználó által aláírt tranzakciók egy „továbbító” szerződéshez kerülnek. Ez a továbbító egy megbízott entitás, amely ellenőrzi a tranzakciók érvényességét, mielőtt elküldi azokat egy gázközvetítőnek. Ezt a láncon kívül intézik, így nem kell érte gázdíjat fizetni. A gázközvetítő átadja a tranzakciót egy „fogadó” szerződésnek, és kifizeti a szükséges díjat, hogy a tranzakció végrehajtható legyen az Ethereumon. A tranzakciót végre lehet hajtani, ha a „továbbító” ismert és a „fogadó” bízta meg. Ez a modell megkönnyíti a fejlesztők számára, hogy gázdíj nélküli tranzakciókat tegyenek lehetővé a felhasználók számára. + + + + + +Az EIP-4337 az első lépés az okosszerződéses tárca támogatására decentralizált módon anélkül, hogy az Ethereum-protokollt változtatni kellene hozzá. Ahelyett, hogy a konszenzusréteget módosítanák, hogy támogassa az okosszerződéses tárcákat, egy új rendszert adnak a meglévő tranzakciós pletykaprotokollhoz. Ez a magasabb szintű rendszer egy új objektumra épül, amely a UserOperation nevet kapta, és a felhasználótól érkező tevékenységeket csomagolja össze a megfelelő aláírásokkal együtt. Majd ezeket a UserOperation-objektumokat elküldik egy dedikált memóriakészletbe, ahol a validátorok azokat egy tranzakcióköteggé szedhetik össze. A tranzakcióköteg számos egyéni UserOperations-sorozatot képvisel, és ugyanúgy bekerül egy Ethereum-blokkba, mint bármilyen normál tranzakció. Ezután a validátorok felveszik azt egy díjmaximalizáló kiválasztási modell alapján. + +Az EIP-4337 azt is megváltoztatja, ahogy a tárcák működnek. Ahelyett, hogy minden egyes tárca újraimplementálná a közös, de összetett biztonsági logikát, ezek a funkciók kikerülnének egy globális tárcaszerződésbe, amelyet „ belépési pontnak” neveznek. Ez üzemeltetné az olyan funkciókat, mint a díjak fizetése és az EVM-kód végrehajtása, így a tárcafejlesztők fókuszálhatnak a kiváló felhasználói élményre. + +Megjegyzés: az EIP-4337 által tervezett belépésipont-szerződést az Ethereum-főhálózatra 2023. március 1-én üzemelték be. A szerződés az Etherscan oldalon tekinthető meg. + + + + + +Az EIP-2938 az Ethereum-protokollt fejleszti azzal, hogy bevezet egy új, AA_TX_TYPE nevű tranzakciótípust, amely három mezőt tartalmaz: nonce, target és data, ahol a nonce egy tranzakciószámláló, a target a belépésipont-szerződés címe, a data pedig az EVM-bájtkód. Ezen tranzakciók végrehajtásához két új parancsot (operációs kódot) kell hozzáadni az EVM-hez: NONCE és PAYGAS. A NONCE opkód trekkeli a tranzakciósorrendet, a PAYGAS kalkulálja és levonja a végrehajtáshoz szükséges gázdíjat a szerződés egyenlegéből. Ezek az új funkciók lehetővé teszik az Ethereumnak, hogy támogassa az okosszerződéses tárcákat, mivel a szükséges infrastruktúra az Ethereum-protokollba épül be. + +Jelenleg az EIP-2938 változtatás nem aktív. A közösség az EIP-4337 javaslatot támogatja, mert ahhoz nem szükséges megváltoztatni a protokollt. + + + + + +Az EIP-3074 az Ethereumot úgy fejleszti, hogy a külső tulajdonú számlák képesek legyenek delegálni a kontrollt egy okosszerződésnek. Eszerint az okosszerződés logikája jóváhagyhat olyan tranzakciót, amely egy külső tulajdonú számlától (EOA) származik. Ez lehetővé teszi az olyan funkciók bevezetését, mint a gázdíjak szponzor általi kifizetése és a kötegelt tranzakciók. Ennek működéséhez két új operációs kódot kell hozzáadni az EVM-hez: AUTH és AUTHCALL. Az EIP-3074 révén az okosszerződéses tárca előnyei elérhetővé válnak úgy, hogy nem kell hozzá szerződés – ehelyett egy státuszmentes, bizalomigény-mentes, nem változtatható szerződés, a „hívó” kezeli a tranzakciókat. + +Jelenleg az EIP-3074 változtatás nem aktív. A közösség az EIP-4337 javaslatot támogatja, mert ahhoz nem szükséges megváltoztatni a protokollt. + + + +## Jelenlegi helyzet {#current-progress} + +Az okosszerződéses tárcák már elérhetők, de több fejlesztésre van szükség, hogy még decentralizáltabbak és engedélymentesek legyenek. Az EIP-4337 egy kiforrott javaslat, amely nem igényel változtatást az Ethereum-protokollban, ezért ezt gyorsan be lehet vezetni. Azok a fejlesztések, amelyekhez az Ethereum-protokollt módosítani kell, jelenleg nincsenek aktív állapotban, így ezek a változások hosszabb időt vesznek igénybe. Az is lehetséges, hogy a számlaabsztrakciót kellőképpen el lehet érni az EIP-4337 révén, ezért a protokollt nem is kell hozzá megváltoztatni. + +## További olvasnivaló {#further-reading} + +- [erc4337.io](https://www.erc4337.io/) +- [Panelbeszélgetés a számlaabsztrakcióról a Devcontól, Bogotából](https://www.youtube.com/watch?app=desktop&v=WsZBymiyT-8) +- [„A számlaabsztrakció miért hoz jelentős fejlődést a dappok számára?” – Devcon, Bogota](https://www.youtube.com/watch?v=OwppworJGzs) +- [„Számlaabsztrakció ELI5” – Devcon, Bogota](https://www.youtube.com/watch?v=QuYZWJj65AY) +- [Vitalik „Út a számlaabsztrakcióhoz” jegyzetei](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists) +- [Vitalik blogbejegyzése a közösségi médiával visszaállítható tárcákról](https://vitalik.eth.limo/general/2021/01/11/recovery.html) +- [EIP-2938 jegyzetek](https://hackmd.io/@SamWilsn/ryhxoGp4D#What-is-EIP-2938) +- [EIP-2938 dokumentáció](https://eips.ethereum.org/EIPS/eip-2938) +- [EIP-4337 jegyzetek](https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a) +- [EIP-4337 dokumentáció](https://eips.ethereum.org/EIPS/eip-4337) +- [EIP-2771 dokumentáció](https://eips.ethereum.org/EIPS/eip-2771) +- [„A számlaabsztrakció alapjai” – Mi az a számlaabsztrakció, I. rész](https://www.alchemy.com/blog/account-abstraction) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/danksharding/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/danksharding/index.md new file mode 100644 index 00000000000..09fe7abda99 --- /dev/null +++ b/public/content/translations/hu/12) Roadmap 2/roadmap/danksharding/index.md @@ -0,0 +1,95 @@ +--- +title: Dank-féle párhuzamos futtatás (Danksharding) +description: Ismerje meg a Proto-Danksharding és a Danksharding egymást követő fejlesztéseit, amelyek az Ethereum-skálázását teszik lehetővé. +lang: hu +summaryPoints: + - A Danksharding egy többfázisú fejlesztés, amely javítja az Ethereum skálázhatóságát és kapacitását. + - Az első fázisban, ami a Proto-Danksharding, a blokkokhoz hozzáadják a blobokat + - Az adatblobok egy olcsóbb megoldást ajánlanak az összevont tranzakcióknak, hogy betegyék az adatokat az Ethereumra, és ez a felhasználóknál alacsonyabb tranzakciós díjként jelenjen meg. + - Ezután a Danksharding elosztja a felelősséget az adatblobok igazolásához a csomópontok csoportjai mentén, ezzel tovább skálázva az Ethereumot másodpercenként több mint 100 000 tranzakcióra. +--- + +# Dank-féle párhuzamos futtatás (Danksharding) {#danksharding} + +A **Danksharding** az a módszer, amivel az Ethereum egy valóban skálázható blokklánc lesz, ehhez azonban számos protokollfejlesztést kell végrehajtani. A **Proto-Danksharding** egy köztes lépés a megvalósításban. Mindkettő célja az, hogy a második blokkláncrétegen (L2) a tranzakciók a lehető legolcsóbbak legyenek a felhasználók számára, az Ethereum pedig több mint 100 000 tranzakciót tudjon feldolgozni másodpercenként. + +## Mi az a Proto-Danksharding? {#what-is-protodanksharding} + +A Proto-Danksharding, más néven [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), az [összegzések](/layer-2/#rollups) egyik módja annak, hogy olcsóbb adatokat adjanak a blokkokhoz. A név attól a két kutatótól származik, akik ezt a módszert javasolták: Protolambda és Dankrad Feist. Korábban az összevont tranzakciókat a tranzakciók költségének csökkentésében behatárolta az a tény, hogy a tranzakciós adatokat a `CALLDATA` mezőbe posztolják. + +Ez egy drága megoldás, mert az Ethereum-csomópontok dolgozzák fel és a láncon örökre élő adat marad, miközben az összevont tranzakcióknak csak egy rövid időre lenne szükségük ezekre. A Proto-Danksharding az adatblobokat vezeti be, amelyeket el lehet küldeni és hozzá lehet csatolni a blokkokhoz. Az ezekben a blobokban lévő adatok nem elérhetők az EVM számára, és automatikusan törlődnek egy meghatározott idő után (a jelen írás idéjén ez 4096 korszak vagy 18 nap). Így az összevont tranzakciók sokkal olcsóbban be tudják küldeni az adatokat, és ez a felhasználóknak olcsóbb tranzakciókat eredményez. + + + +Az összevont tranzakciók az Ethereum skálázási megoldásai azáltal, hogy a tranzakciókat a láncon kívül kötegelik össze, majd azok eredményét posztolják az Ethereumra. összevont tranzakció lényegében két részből áll: adat és végrehajtás-ellenőrzés. Az adat a tranzakciók teljes sora, amelyet az összevont tranzakció dolgoz fel, hogy az Ethereumra beküldve megváltozzon annak státusza. A végrehajtás-ellenőrzés azt jelenti, hogy néhány jóhiszemű szereplő („bizonyító”) újra végrehajtja a tranzakciókat, hogy biztosan korrekt legyen a javasolt státuszváltozás. A végrehajtás-ellenőrzéshez a tranzakciós adatoknak elérhetőnek kell lenniük annyi időre, hogy azokat bárki letölthesse és ellenőrizni tudja. Így a bizonyító be tudja azonosítani és meg tudja kérdőjelezni az összevont tranzakció szekvenszerének rosszhiszemű viselkedését. Ugyanakkor az adatoknak nem kell örökre elérhetőnek maradniuk. + + + + + +A összevont tranzakciók elköteleződést posztolnak a tranzakciók adatai alapján a láncon belül, és az aktuális adatokat elérhetővé teszik az adatblobokban. Ezáltal a bizonyítók le tudják ellenőrizni az elköteleződések érvényességét, és meg tudják kérdőjelezni az általuk tévesnek tartott adatokat. A csomópont szintjén az adatblobok a konszenzusos kliensben találhatók. A konszenzus kliens tanúsítja, hogy látta az adatot és a elérhetővé vált a hálózaton. Ha az adatot örökre meg kellene tartani, akkor ezek a kliensek megnövekednek, és a csomópontok üzemeltetéséhez komoly hardverigények merülnének fel. Ehelyett az adatok automatikusan törlődnek a csomópontról 18 naponta. A konszenzusos kliens tanúsításai bizonyítják, hogy a bizonyítónak elegendő lehetősége volt az adatok ellenőrzésére. Az aktuális adatokat pedig tárolhatják a láncon kívül az összevont tranzakció üzemeltetői, a felhasználók vagy mások. + + + +### Hogyan ellenőrzik a blobadatokat? {#how-are-blobs-verified} + +A összevont tranzakciók az általuk feldolgozott tranzakciókat adatblobokban posztolják. Emellett posztolnak egy „elköteleződést” is. Tehát az adathoz hozzáillesztenek egy polinomiális funkciót. Ezt a funkciót számos ponton meg lehet vizsgálni. Például, ha egy rendkívül egyszerű függvényt definiálunk, `f(x) = 2x-1`, akkor ezt a funkciót megvizsgálhatjuk arra, hogy `x = 1`, `x = 2`, `x = 3`, amelyből az `1, 3, 5` eredmények származnak. A bizonyító ugyanezt a funkciót alkalmazza az adatra, és megvizsgálja azt ugyanazokon a pontokon. Ha az eredeti adat megváltozott, akkor a függvény sem lesz azonos, és az értékek is különbözni fognak minden ponton. Valójában az elköteleződés és a bizonyíték is elég bonyolult, mert kriptográfiai függvényekbe van csomagolva. + +### Mi az a KZG? {#what-is-kzg} + +A KZG a Kate-Zaverucha-Goldberg rövidítés egy olyan séma három [szerzője](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11), amely egy adathalmazt egy kis [kriptográfiai „elköteleződésre”](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) redukál. A összevont tranzakció által beküldött adatblobot ellenőrizni kell, hogy az összevont tranzakció megfelelően működik-e. Ennek lényege, hogy a bizonyító újrafuttatja a blobban lévő tranzakciókat, hogy megvizsgálja az elköteleződés érvényességét. Ez koncepcionálisan ugyanolyan, mint ahogy a végrehajtási kliensek ellenőrizik az Ethereum-tranzakciók érvényességét az első blokkláncrétegen (L1) a Merkle-bizonyítékok alapján. A KZG egy alternatív bizonyíték, amely egy polinomiális egyenletet illeszt az adathoz. Az elköteleződés megvizsgálja a polinomiálist néhány titkos adatponton. A bizonyító ugyanezt a polinomiálist illeszti rá az adatra, megvizsgálja ugyanazon értékeken, és ellenőrzi, hogy az eredmény ugyanaz-e. Ilyen módon lehetséges ellenőrizni az adatot a zero-knowledge technikákkal kompatibilis módon, amelyet néhány összevont tranzakció és az Ethereum-protokoll használ. + +### Mit volt a KZG-ceremónia? {#what-is-a-kzg-ceremony} + +A KZG-ceremónia egy olyan módszer volt, amellyel az Ethereum-közösség több tagja együtt létrehozhatott egy számokból álló titkos, véletlenszerű sorozatot, amelyet adatvalidálásra tudtak használni. Nagyon fontos volt, hogy ezt a számsort ne tudja meg senki és ne is lehessen újraalkotni azt. Ennek biztosításához minden egyes résztvevő az előző tagtól kapott egy részletet. Ekkor létrehozhattak néhány új, véletlenszerű értéket (pl. azzal, hogy a böngésző leköveti az egérmozgást), és ezt összekeverhették az előző részlettel. Ezután elküldték ezt az értéket a következő tagnak, és megsemmisítették a saját gépükön. Amíg volt legalább egy személy, aki jóhiszeműen végezte ezt a folyamatot, addig a támadó számára nem derült ki a végső érték. + +Az EIP-4844 KZG-ceremónia nyilvános volt és emberek tízezrei vettek benne részt, hogy hozzátegyék a saját entrópiájukat (véletlenszerűséget). Összesen több mint 140 000 hozzájáruló volt, ami a világ legnagyobb ilyen jellegű ceremóniájává tette. Ahhoz, hogy a ceremóniát megtámadhassák, ezeknek a résztvevőknek 100%-ban rosszhiszeműnek kell lenniük. A résztvevők szempontjából lényeges, hogy ha ő maguk jóhiszeműen jártak el, akkor nincs szükség arra, hogy megbízzanak másban, mert már maguk is biztosították a ceremóniát (egyénként kielégítették az N-ből 1 résztvevő kritériumot). + + + +Amikor egy összevont tranzakció adatot tesz a blobba, akkor egy „elköteleződést” ad, amit a láncon posztol. Ez az elköteleződés annak a vizsgálatnak az eredménye, ami bizonyos adatpontokon a polinomiális illesztést végzi. Ezeket a pontokat a KZG ceremónia által létrehozott véletlenszerű számok határozzák meg. Ekkor a bizonyítók ellenőrizhetik a polinomiálist ugyanazokon a pontokon, hogy az adat érvényességét igazolják – ha ugyanarra az értékre jutnak, akkor az adat helyes. + + + + + +Ha valaki ismeri az elköteleződéshez használt véletlenszerű helyet, akkor könnyedén kreálhat egy polinomiálist, ami illeszkedik a megadott pontokhoz (pl. egy „ütközés”). Ezt azt jelenti, hogy a blobhoz adhatnak vagy a blobból elvehetnek adatot, és mégis tudnak érvényes bizonyítékot adni róla. Ennek megakadályozására a bizonyítók nem az aktuális, titkos helyet kapják meg, hanem a helyet egy elliptikus görbét használó kriptográfiai „fekete dobozba” csomagolva kapják meg. Ezek gyakorlatilag annyira összetorlasztják az értékeket, hogy az eredetiket nem lehet visszafejteni, miközben néhány okos algebrai bizonyító és igazoló még mindig képes megvizsgálni a polinomiálisokat az általuk képviselt pontokon. + + + + + Se a Danksharding, se a Proto-Danksharding nem követi a hagyományos „sharding” (szilánkosítási) modellt, amelynek célja a blokklánc több részre való felosztása lenne. A shard láncok többé nem szerepelnek az Ethereum ütemtervben. Ehelyett a Danksharding elosztott adatmintavételt használ a blobokon keresztül, hogy az Ethereumot skálázza. Ezt sokkal egyszerűbb bevezetni. Ezt a modellt néha „adat-shardingnak” is nevezik. + + +## Mi az a Danksharding? {#what-is-danksharding} + +A Danksharding az összevont tranzakciós skálázási megoldás teljes megvalósítása, amely a Proto-Dankshardinggal kezdődik. A Danksharding az Ethereumon hatalmas helyet teremt az összevont tranzakcióknak, hogy az összecsomagolt tranzakciós adataikat beküldjék. Ezzel az Ethereum képes lesz könnyedén támogatni az egyéni összevont tranzakciók százait, és tranzakciók millióit végrehajtani minden másodpercben. + +Ez úgy működik, hogy a blokkokhoz csatolt blobokat a Proto-Danksharding hatról (6) a teljes Dankshardingban 64-re bővítjük. A szükséges változások többi része a konszenzus kliensek működését fejleszti, hogy azok képesek legyenek az új, nagy méretű blobokat kezelni. Ezen változások néhány része már benne van az ütemtervben, függetlenül a Danksharding bevezetéstől. Például a Dankshardinghoz szükséges a javaslattevő-építő szétválasztás (PBS) bevezetése. Ez egy olyan fejlesztés, amely szétválasztja a blokkok építését és azok előterjesztését a különböző validátorok között. Ugyanígy az adatelérhetőség-mintázás szükséges a Dankshardinghoz, de az igazán könnyű kliensek fejlesztéséhez is, amelyek nem tárolnak túl sok előzményadatot („státuszmentes kliensek”). + + + +A javaslattevő-építő szétválasztás (PBS) azért szükséges, hogy az egyéni validátoroknak ne kelljen kiterjedt elköteleződéseket és 32 MB-nyi blobadatra vonatkozó bizonyítékokat generálni. Ez túl nagy terhet jelentene az otthoni letétbe helyezőknek, és erőteljesebb hardvereket kellene beszerezniük a részvételhez, amely sértené a decentralizációt. Ehelyett specializált blokképítők veszik fel a költséges számítási művelet felelősségét. Majd a blokkot elérhetővé teszik a blokk javaslattevőinek, hogy azt elküldhessék. A javaslattevő egyszerűen a legnyereségesebb blokkot választja. Így bárki olcsón és gyorsan tudja ellenőrizni a blobokat, tehát bármelyik validátor megvizsgálhatja, hogy a blokképítők jóhiszeműen viselkednek-e. Így a nagy méretű blobokat úgy lehet feldolgozni, hogy az nem csökkenti a decentralizációt. A rosszhiszemű blokképítőket ki lehet zárni a hálózatból és meg lehet bünteti őket – mások majd a helyükbe lépnek, mert ez egy profitábilis tevékenység. + + + + + +Adatelérhetőség-mintázásra is szükség van, hogy a validátorok gyorsan és hatékonyan tudják ellenőrizni a blobadatokat. Az adatelérhetőség-mintázás segítségével a validátorok meggyőződnek arról, hogy a blobadat elérhető volt és megfelelő elköteleződés történt. Minden validátor véletlenszerűen választhat néhány adatpontot és létrehozhatja a bizonyítékot, így egyik validátornak sem kell az egész blobot ellenőrizni. Ha bármilyen adat hiányzik, azt gyorsan be lehet azonosítani, így a blobot elutasítják. + + + +### Jelenlegi helyzet {#current-progress} + +A teljes Danksharding bevezetéséhez még számos év szükséges. Időközben a KZG ceremóniája több mint 140 000 hozzájárulással zárult, és a Proto-Danksharding [EIP](https://eips.ethereum.org/EIPS/eip-4844)-je lejárt. Ezt a javaslatot az összes teszthálózatban maradéktalanul bevezették, és 2024 márciusában a Cancun-Deneb ("Dencun") hálózatfrissítéssel életbe lépett a Mainnet hálózaton. + +### További olvasnivaló {#further-reading} + +- [Proto-Danksharding jegyzetek](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) – _Vitalik Buterin_ +- [Dankrad jegyzetei a Dankshardingról](https://notes.ethereum.org/@dankrad/new_sharding) +- [Dankrad, Proto és Vitalik beszélgetése a Dankshardingról](https://www.youtube.com/watch?v=N5p0TB77flM) +- [A KZG-ceremónia](https://ceremony.ethereum.org/) +- [Carl Beekhuizen beszéde a Devconon a megbízható összeállításról](https://archive.devcon.org/archive/watch/6/the-kzg-ceremony-or-how-i-learnt-to-stop-worrying-and-love-trusted-setups/?tab=YouTube) +- [Bővebben az adatelérhetőség-mintázásról a blobokhoz](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Dankrad Feist a KZG elköteleződésekről és bizonyítékokról](https://youtu.be/8L2C6RDMV9Q) +- [KZG polinomiális elköteleződések](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/dencun/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/dencun/index.md new file mode 100644 index 00000000000..89028a204b3 --- /dev/null +++ b/public/content/translations/hu/12) Roadmap 2/roadmap/dencun/index.md @@ -0,0 +1,120 @@ +--- +title: Cancun-Deneb (Dencun) FAQ +description: Gyakori kérdések a Cancun-Deneb (Dencun) hálózati frissítés kapcsán +lang: hu +--- + +# Cancun-Deneb (Dencun) {#dencun} + +Cancun-Deneb (Dencun) az Ethereum-hálózat fejlesztése, mely bevezeti a **Proto-Danksharding (EIP-4844)** fejlesztést, lehetővé teszi az átmeneti **adatblobok** használatát, hogy olcsóbb legyen a [második blokkláncréteg (L2)](/glossary/#layer-2) összegzők tárolása. + +Egy új tranzakciótípus lehetővé teszi, hogy az összegzők költséghatékonyabban tudjanak adatot tárolni az úgynevezett „blobokban”. A blobok kb. 18 napig (pontosabban 4096 [korszakig](/glossary/#epoch)) elérhetők a hálózaton. Ezután a blobokat leválasztják a hálózatról, de az alkalmazások még mindig tudják az adatérvényességet ellenőrizni a bizonyítékok révén. + +Ez rendkívüli módon csökkenti az összegzők költségét, behatárolja a lánc növekedését, és több felhasználót képes kiszolgálni, miközben megtartja a biztonságot és a csomópontüzemeltetők decentralizált struktúráját. + +## Mikor lesznek az összegzőknek alacsonyabb díjaik a Proto-Danksharding következtében? {#when} + +- A frissítés a 269 568. korszakban lett telepítve, **2024. március 13-án, 13:55-kor (UTC)** +- A legnagyobb összegzők, mint az Arbitrum vagy Optimism, jelezték, hogy a blobokat azonnal használni fogják a frissíté után +- Az egyéni összegzők eltérő időpontban fognak átállni, mert mindnek frissíteni kell a maga rendszerét, hogy ki tudja használni az új blob-helyet + +## Hogyan lehet az ETH-t átváltani a végleges elágazás után? {#scam-alert} + +- **Az ETH-szel nincs teendője**: Az Ethereum Dencun frissítés után nincs szükség arra, hogy átváltsa vagy frissítse az ETH-t. A számlaegyenlege ugyanaz marad, a jelenleg Ön által birtokolt ETH elérhető marad az aktuális állapotában a végleges elágazás után is. +- **Figyeljen oda a csalásokra!**  **bárki mondja, hogy „frissítse” az ETH-t, az be akarja Önt csapni.** Ezzel a hálózatfrissítéssel kapcsolatban Önnek semmilyen teendője nincs. A pénzeszközei teljesen érintetlenek maradnak. Emlékezzen rá, hogy a legjobb védekezés a csalások ellen, ha Ön tájékozott. + +[Bővebben a csalások felismeréséről és elkerüléséről](/security/) + +## Milyen problémát old meg a Dencun hálózati frissítés? {#network-impact} + +A Dencun elsődlegesen a **skálázhatóságot** célozza (több felhasználó és több tranzakció kezelését) **megengedhető díjak** mellett, miközben a hálózat **decentralizációja megmarad**. + +Az Ethereum közössége egy összegzőalapú megközelítést alkalmaz a növekedésre, melynél a második blokkláncréteg (L2) összegzők biztosítják, hogy több felhasználó biztonságos módon használja a rendszert. + +A rollup hálózatok a főhálózattól függetlenül kezelik a tranzkaciók _feldolgozását_ (vagy „végrehajtását”), majd publikálják az eredmény kriptográfiai bizonyítékát és/vagy a tömörített tranzakciós adatokat a főhálózaton, hogy azok felkövethetők legyenek. Ezen bizonyítékok tárolása költséges ([gáz](/glossary/#gas) formájában), melyet a Proto-Danksharding előtt állandó módon kellett tárolnia minden csomópontüzemeltetőnek, ami drága feladat. + +A Proto-Danksharding bevezetése a Dencun frissítés által olcsóbb adattárolást tesz lehetővé ezen bizonyítékoknak, mivel a csomópontüzemeltetőknek csak 18 napig kell tárolni azokat, utána biztonsággal eltávolíthatóak, hogy ne növeljék tovább a hardverigényeket. Mivel az összegzőknek általában 7 napos visszavonási periódusuk van, ezért a biztonsági modelljük változatlan marad, amíg az L1-en ugyanilyen hosszen elérhetők a blobok. A 18 napos periódus egy kellően nagy időszakot biztosít erre. + +[Bővebben az Ethereum skálázásról](/roadmap/scaling/) + +## Hogyan lehet a régi blobadatokat elérni? {#historical-access} + +Miközben az általános Ethereum-csomópontok a hálózatnak a _jelen állapotát_ tárolják, a korábbi blobadatokat kb. 18 nappal később már mellőzni lehet. Mielőtt az adatot eltávolítaná, az Ethereum biztosítja, hogy az összes hálózati résztvevőnek elérhető volt arra, hogy: + +- Az érdekelt felek letöltsék és eltárolják az adatokat. +- Az összegző megkérdőjelezési periódusai lezáruljanak. +- Az összegző tranzakciói véglegessé váljanak. + +A blob-_előzményadatok_ számos okból szükségesek lehetnek, illetve azokat több decentralzált protokoll is elérheti és tárolhatja: + +- **Harmadik fél indexáló protokollok**, mint a The Graph, amelyek csomópont-üzemeltetők decentralizált hálózata révén tárolják ezeket az adatokat, melyet kriptogazdasági mechanizmusokkal ösztönöznek. +- **BitTorrent** egy decentralizált protokoll, ahol az önkéntesek tárolják és terjesztik ezeket az adatokat másoknak. +- **[Ethereum portal network](/developers/docs/networking-layer/portal-network/)** célja, hogy elérést biztosítson az Ethereum összes adatához a csomópont-üzemeltetők decentralizált hálózatán keresztül, akik között elosztják az adatokat, ahogy a BitTorrent esetében. +- **Egyéni felhasználók** bármikor eltárolhatják az adatokat, amelyre historikus okokból szükségük lehet. +- **Rollup szolgáltatók** számára érdemes tárolni ezeket az adatokat, hogy jobb legyen a felhasználói élmény. +- **Blokkfelfedezők** általában olyan archív csomópontokat futtatnak, melyek indexálják és eltárolják az összes információt, hogy visszakereshető legyen a felhasználóknak egy webfelületen keresztül. + +Fontos megjegyezni, hogy az előzményállapotok visszahíváse egy **N-ből 1 bizalmi modellen** alapszik. Eszerint csak _egyetlen megbízható forrásból_ kell adat ahhoz, hogy ellenőrizhető legyen a helyessége a hálózat jelen állapotát felhasználva. + +## Hogyan járul hozzá ez a frissítés az Ethereum nagyobb útitervéhez? {#roadmap-impact} + +Proto-Danksharding elősegíti a teljes [Danksharding](/roadmap/danksharding/) bevezetést. A Danksharding lényege, hogy a rollup-adatok tárolását elosztja a csomópont-üzemeltetők között, így az egyes operátoroknak csak a teljes adat egy kis részét kell kezelniük. Ez az elosztás megnöveli a blokkonkénti adatblobok számát, ami alapvető az Ethereum skálázásához, hogy több felhasználót és tranzakciót tudjon kezelni. + +Ez a skálázási megoldás elengedhetetlen ahhoz, hogy [felhasználók milliárdjait támogassa az Ethereum](/roadmap/scaling/) megengedhető díjakkal és fejlettebb alkalmazásokkal, miközben megőrzi a hálózat decentralizáltságát. E változások nélkül a csomópontüzemeltetők hardverigényei megnövekednének, amely egyre drágább gépeket követelne tőlük. Emiatt a kisebb üzemeltetők kiesnének a működésből, amitől koncentrálódna a hálózat irányítása néhány nagy operátornál, és ez ellene megy a decentralizáció alapelvének. + +## Érinti ez a frissítés az Ethereum összes konszenzusát és validátorkliensét? {#client-impact} + +Igen, a Proto-Danksharding (EIP-4844) következtében mind a végrehajtási klienseket, mind a konszenzusklienseket frissíteni kell. Az összes Ethereum-kliens új verziója elérhető, hogy alátámassza ezt a frissítést. A frissítés után az Ethereum-hálózattal való szinkronizáció érdekében a csomópont-üzemeltetőknek támogatott kliensverziót kell futattniuk. Vegye figyelembe, hogy a kliensverziók adott időben érvényesek, a felhasználók a legutóbbi frissítéseket vegyék figyelembe. [Tekintse meg a támogatott kliensverziók részleteit](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement#client-releases). + +A konszenzuskliensek kezelik a _validátorszoftvert_, melyek mind frissítve lettek, hogy eleget tegyenek a változásnak. + +## Hogyan érinti a Cancun-Deneb (Dencun) a Goerlit és az Ethereum egyéb teszthálózatait? {#testnet-impact} + +- A fejlesztői hálózatok, a Goerli, Sepolia és a Holesky is mind átesik a Dencun frissítésen és a Proto-Danksharding teljes mértékben működik ezekben +- A rollup-fejlesztők használhatják ezeket a hálózatokat az EIP-4844 tesztelésre +- A legtöbb felhasználót ugyanakkor a teszthálózatok változása egyáltalán nem érinti + +## Innentől fogva az összes L2-es tranzakció blobhelyet használ majd, vagy választani lehet? {#calldata-vs-blobs} + +Az Ethereum második blokkláncrétegének (L2) összegzői kétféle tárhelyet használhatnak: átmeneti blobhely vagy állandó okosszerződéses calldata. A blobhely egy gazdaságos megoldás, átmeneti tárolást ad alacsonyabb költségen. Biztosítja az adatelérhetőséget a megkérdőjelezési időszakra. Másrészt az okosszerződés calldata állandó tárhelyet biztosít, de sokkal drágább. + +A döntést a blobhely és a calldata között a rollup-szolgáltatók hozzák meg. Ezt a döntést a blobhely iránti igény befolyásolja. Ha a bobhelyre nagy az igény, akkor a rollupok talán a calldata-t választják, hogy időben el tudják tárolni az adatokat. + +Bár elméletileg a felhasználó is választhat, de az a jellemző, hogy a rollup-szolgáltatók hozzák meg ezt a döntést. Ha a felhasználók hoznának döntést, az összetettebb helyzetet teremtene, főleg a költséghatékény tranzakciócsomagolás esetén. E döntés részleteit a felhasználók megtekinthetik a rollup-szolgáltatók dokumentációiban. + +## A 4844 csökkenti az L1 gázdíjat? {#l1-fee-impact} + +Nem igazán. Egy új gázpiac jött létre kizárólag a blobhelyeknek a rollup-szolgáltatók részére. _Habár az L1 díjak csökkenhetnek azzal, hogy a rollup-adatokat blobokba teszik, ez a frissítés elsősorban arra fókuszál, hogy az L2-es díjak csökkenjenek. Az L1 (főhálózat) díjainak csökkenése másodlagos hatás, mely kisebb mértékű._ + +- Az L1 gázcsökkenés arányos azzal, hogy a rollup-szolgáltatók mennyire kezdik el használni a blobadatokat +- Az L1 gáz valószínűleg versenyképes marad a nem rollup-jellegű tevékenységek révén +- Azok az összegzők, amelyek blobhelyet használnak, kevesebb L1 gázt igényelnek, ezért annak díja csökkenhet +- A blobhely még behatárolt, ezért ha egy blokkban tele van a blob, akkor a rollup kénytelen állandó tárhelyet használni, ami növeli az L1 és L2 gázárakat is + +## Csökkenteni fogja ez a változás a többi EVM L1 blokkláncok díjait? {#alt-l1-fee-impact} + +Nem. A Proto-Danksharding által hozott előnyök az Ethereum L2 rollupokra vonatkoznak, melyek a bizonyítékokat az L1-en (főhálózat) tárolják. + +Az a tény, hogy valami kompatibilis az Ethereum virtuális géppel (EVM), nem jelenti azt, hogy ebből a frissítésből bármilyen előnyt is élvezne. Az Ethereumtól függetlenül működő hálózatok (legyenek akár EVM-kompatibilisek vagy sem) nem tárolják az adataikat az Ethereumon, így nem hoz számukra előnyt ez a frissítés. + +[Bővebben az L2 rollupokról](/layer-2/) + +## Ön inkább vizuális típus? {#visual-learner} + + + +_Az Ethereum skálázása, EIP-4844 — Finematics_ + + + +_Blobhely 101 Domothy-val — Bankless_ + +## További olvasnivaló {#further-reading} + +- [EIP4844.com](https://www.eip4844.com/) +- [EIP-4844: Elosztott blob tranzakciók (Proto-Danksharding)](https://eips.ethereum.org/EIPS/eip-4844) +- [Dencun főhálózati bejelentés](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) - _Ethereum Foundation blog_ +- [The Hitchhiker's Guide to Ethereum: Proto-Danksharding](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#proto-danksharding-eip-4844) - _Jon Charbonneau_ +- [Proto-Danksharding GYIK](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _Vitalik Buterin_ +- [Részletes magyarázat az EIP-4844-ről: A Cancun frissítés lényege](https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core-of-the-cancun-upgrade-de7b13761d2c) - _Ebunker_ +- [AllCoreDevs Update 016](https://tim.mirror.xyz/HzH5MpK1dnw7qhBSmzCfdCIxpwpD6DpwlfxtaAwEFro) - _Tim Beiko_ diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/pbs/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/pbs/index.md new file mode 100644 index 00000000000..cc32211809a --- /dev/null +++ b/public/content/translations/hu/12) Roadmap 2/roadmap/pbs/index.md @@ -0,0 +1,51 @@ +--- +title: Javaslattevő-építő szétválasztása +description: Ismerje meg, hogy az Ethereum-validátorok hogyan és miért osztják fel a blokképítési és -küldési feladatokat. +lang: hu +--- + +# Javaslattevő-építő szétválasztása {#proposer-builder-separation} + +Jelenleg az Ethereum validátorok blokkokat hoznak létre_és_ küldenek. Összecsomagolnak olyan tranzakciókat, amelyekről tudomást szereztek a pletykahálózaton keresztül, blokkot készítenek azokból és elküldik a társaiknak az Ethereum-hálózaton. A **javaslattevő-építő szétválasztás (PBS)** szétosztja ezeket a feladatokat a validátorok között. A blokk építői minden egyes slotban létrehozzák a blokkokat és felajánlják azokat a javaslattevőnek, aki az adott slotban felel az előterjesztésért. A javaslattevő nem láthatja a blokk tartalmát, egyszerűen a legjövedelmezőbbet választja, és megfizeti a blokképítés díját, mielőtt elküldi a blokkot a társainak. + +Ez több szempontból is egy fontos fejlesztés. Először is lehetővé teszi, hogy a tranzakciók cenzúrázása protokoll szinten ne történhessen meg. Másodsorban az egyszerűbb validátorokat nem tudják kirekeszteni a versenyből az intézményes résztvevők, akik jobban tudják optimalizálni a blokképítési profitjukat. Harmadjára az Ethereum-skálázását is támogatja azáltal, hogy lehetővé teszi a Danksharding fejlesztéseket (párhuzamos futtatás). + +## A PBS és a cenzúrának való ellenállás {#pbs-and-censorship-resistance} + +A blokk építésének és előterjesztésének szétválasztása megnehezíti a blokképítők számára, hogy cenzúrázzák a tranzakciókat. Ennek az az alapja, hogy egy viszonylag összetett kritériumokat lehet megadni arra, hogy minek muszáj benne lennie a blokkban, ezért a javaslattevés előtt nem lehet a tranzakciókat cenzúrázni. Mivel a javaslattevő egy másik entitás az építőhöz képest, ezért védekezhet a cenzúrázó blokképítők ellen. + +Például bekerülési listákat tud adni a javaslattevő, hogy a tudomására jutott tranzakciókat, amelyeket mégsem lát az adott blokkban, a következő építésnél kötelezővé tudja tenni. Ezt a bekerülési listát a javaslattevő a saját memóriakészletéből (tranzakciók, amelyekről tudomása van) készíti és küldi el a társainak még mielőtt a blokkjavaslat megtörténne. Ha a bekerülési listáról bármely tranzakció hiányzik, akkor a javaslattevő elutasíthatja az adott blokkot, hozzáteheti a hiányzó tételeket mielőtt javasolja azt, vagy elküldheti a javaslatot és a többi validátorra bízhatja, hogy azok utasítsák el. Ennek az elképzelésnek létezik egy valószínűleg még hatékonyabb verziója, amikor az építőtől azt várjuk, hogy teljesen kihasználja a blokkhelyet, és ha nem teszi, akkor a bekerülési listáról lehet még hozzáadni tranzakciókat a blokkhoz. Ez jelenleg egy aktív kutatási terület, a bekerülési listák optimális konfigurálása még nem dőlt el. + +[A titkosított memóriakészletek](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) nem teszik lehetővé az építő és a javaslattevő számára, hogy tisztában legyenek a blokkba foglalt tételekkel, csak miután az már elküldésre került. + + + +A nagyobb hatalommal bíró szervezetek nyomást gyakorolhatnak a validátorokra, hogy zárjanak ki bizonyos címekre menő vagy onnan jövő tranzakciókat. A validátorok ennek megfelelően beazonosíthatják a feketelistás tételeket a tranzakciógyűjtőben és kihagyhatják azokat a javasolt blokkból. A PBS után ez nem lehetséges, mert a javaslattevő nem fogja tudni, hogy milyen tranzakciók szerepelnek az általa elküldött blokkban. Bizonyos egyéneknek vagy alkalmazásoknak talán fontos lehet bizonyos cenzúraszabályoknak megfelelni, amikor az adott régióban azt törvény szabályozza. Ezekben az esetekben a szabálynak való megfelelés az alkalmazás szintjén történik, így a protokoll továbbra is engedélymentes és cenzúramentes marad. + + + +## A PBS és a MEV {#pbs-and-mev} + +A **maximálisan kinyerhető érték (MEV)** arra utal, amikor a validátorok maximalizálják a nyereségüket azzal, hogy kedvezőségi sorrendbe állítják a tranzakciókat. Általános példa az arbitrázs célú átváltás a decentralizált tőzsdéken (pl. egy nagy értékű eladás vagy vétel elé kerülve), vagy annak észlelése, hogy egy pénzügyi (DeFi) pozíciót érdemes lenne likvidálni. A MEV maximalizálása olyan szofisztikált technikai tudást és személyre szabott szoftverkiegészítéseket igényel a normális validátorhoz képest, hogy sokkal valószínűbb, hogy az intézményes működtetők lehagyják az egyéneket vagy egyszerű validátorokat a MEV kinyerése kapcsán. Emiatt a letétbe helyezés díjai valószínűleg magasabbak lesznek a centralizált működtetőknél, ami olyan központosítő erőt hoz létre, amely nem motiválja az otthoni letétbe helyezést. + +A PBS úgy oldja meg ezt a problémát, hogy újrakonfigurálja a MEV gazdasági helyzetét. Ahelyett, hogy a blokk javaslattevője végezne saját MEV keresést, egyszerűen felvesz egy blokkot a neki felajánlottak közül, amelyet a blokképítők készítettek. A blokk építői végezhetnek szofisztikált MEV-kinyerést, de ennek nyeresége a javaslattevőhöz jut. Tehát még ha a MEV kinyerést dominánsan néhány specializált blokképítő végzi, ennek jutalma a hálózat bármelyik validátorához kerülhet, beleértve az egyéni, otthoni letétbe helyezőket. + + + +Az egyéneket arra motiválhatja, hogy egyéni letétbe helyezés helyett inkább készletekbe tegyék a letétet, mert a szofisztikált MEV-stratégiák miatt az nagyobb nyereséget kínál. A blokk építőjének és javaslattevőjének elkülönítése azt jelenti, hogy a kinyert MEV több validátornál kerül elosztásra, nem pedig a leghatékonyabb MEV-kinyerőnél központosul. Emellett a specializált blokképítők levehetik az egyénekről a blokk készítésének terhét, megakadályozhatják, hogy az egyének saját maguknak vegyenek ki MEV-et a validálás során, miközben maximalizálják az egyéni, független validátorok számát, akik jóhiszemű módon képesek ellenőrizni a blokkokat. A fontos koncepció a „bizonyító-ellenőrző aszimmetria”, amelynek lényege, hogy a centralizált blokklétrehozás rendben van addig, amíg robosztus és maximálisan decentralizált validátorhálózat áll rendelkezésre a blokkok jóhiszemű igazolásához. A decentralizáció egy eszköz, nem pedig végcél – valós blokkokat szeretnénk elérni. + + +## A PBS és a Danksharding {#pbs-and-danksharding} + +A Danksharding az a módszer, amivel az Ethereum skálázza a teljesítményt, hogy másodpercenként több mint 100 000 tranzakciót kezeljen és közben minimalizálja az összevont tranzakcióért fizető felhasználók által fizetett díjakat. A PBS-en alapszik, mert a blokképítőknek extra feladatot ad, akiknek bizonyítékot kell készíteniük 64 MB-nyi összevonttranzakció-adatra kevesebb mint 1 másodperc alatt. Ehhez valószínűleg specializált építőkre van szükség, akik elég komoly hardvert tudnak kijelölni ehhez a feladathoz. A nem PBS szerinti helyzetben a blokképítés egyre inkább centralizálódhat a szofisztikáltabb és erőteljesebb működtetők körül a MEV kinyerése miatt is. A javaslattevő-építő szétválasztás (PBS) egy olyan mód, amely felöleli ezt a valóságot és megakadályozza a blokkvalidálás központosítását (ami nagyon fontos), illetve elősegíti a letéti jutalmak elosztását. Remek lehetőség ez arra is, hogy a specializált blokképítők hajlandók és képesek legyenek kiszámolni a Dankshardinghoz szükséges adatbizonyítékokat. + +## Jelenlegi helyzet {#current-progress} + +A PBS a kutatás előrehaladott fázisában tart, bár akadnak még fontos kérdések, mielőtt az Ethereum klienseknél bevezetésre kerül. Nincs még véglegesített specifikáció. Ebből adódhat, hogy akár egy év is szükséges a bevezetésére. Tekintse meg a [kutatás jelenlegi állapotát](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance). + +## További olvasnivaló {#further-reading} + +- [Kutatási állapot: cenzúrának való ellenállás a PBS esetén](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) +- [PBS-barát díjpiac dizájn](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) +- [A PBS és a cenzúrának való ellenállás](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions) +- [Bekerülési listák](https://notes.ethereum.org/@fradamt/H1ZqdtrBF) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/secret-leader-election/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/secret-leader-election/index.md new file mode 100644 index 00000000000..893d104f6bc --- /dev/null +++ b/public/content/translations/hu/12) Roadmap 2/roadmap/secret-leader-election/index.md @@ -0,0 +1,44 @@ +--- +title: Titkos vezetőválasztás +description: Annak áttekintése, hogyan segíthet a titkos vezetőválasztás a validátorokat megvédeni a támadóktól +lang: hu +summaryPoints: + - A blokkjavaslók IP-címe előre ismert, így sebezhetővé válnak a támadásokkal szemben + - A titkos vezetőválasztás elrejti a validátorok személyazonosságát, így nem tudni előre, hogy kire esik a választás + - Ezen elképzelés egyik további lépése az, hogy minden slotban legyen véletlenszerű a validátorválasztás. +--- + +# Titkos vezetőválasztás {#single-secret-leader-election} + +A jelenlegi [proof-of-stake](/developers/docs/consensus-mechanisms/pos) alapú konszenzusmechanizmusban a következő blokkjavaslók nyilvánosak, és az IP-címüket hozzájuk lehet kapcsolni. Tehát a támadók be tudják azonosítani, hogy melyik validátor fogja a következő blokkot javasolni, megtámadhatják őt egy szolgáltatásmegtagadásos (denial-of-service/DOS) támadással, így nem tudják időben javasolni a blokkot. + +Ez lehetőséget nyújt a támadó számára, hogy profitra tegyen szert. Például a blokkjavasló, akit a slot `n+1`-ra választottak, megtámadja a blokkjavaslót a slot `n`-ben, így az nem tud blokkot javasolni. Így a támadó két slotra vonatkozó MEV-et (maximálisan kinyerhető értéket) tud kivonni, vagy az összes tranzakciót egyben berakja egy blokkba, hogy az összes díjat megszerezze. Ez nagy valószínűséggel jobban érinti az otthoni validálókat, mint a szofisztikált, szervezeti validátorokat, akik fejlettebb módokon tudják védeni magukat, így ennek az egésznek centralizáló hatása van. + +Számos megoldás létezik erre a problémára. Az egyik az [elosztottvalidátor-technológia](https://github.com/ethereum/distributed-validator-specs), ami elosztja a validátorhoz szükséges feladatokat több számítógépen, némi duplikációval (extra kapacitással), így a támadónak sokkal nehezebb megakadályozni a javaslatot egy adott slotban. A legrobusztusabb megoldás a **Single Secret Leader Election (SSLE)**, vagyis az egyetlen, titkos vezető kiválasztása. + +## Egyetlen, titkos vezető kiválasztása {#secret-leader-election} + +Az SSLE-ben okos kriptográfia biztosítja, hogy csak a kiválasztott validátor tudja, hogy őt választották. Minden validátor elköteleződik egy titok mellett, amelyet mind ismernek. Az elköteleződéseket összekeverik és újrakonfigurálják, hogy senki se tudja összekapcsolni azokat a validátorok elköteleződésével, de minden validátor tudja, hogy melyik tartozik őhozzá. Majd a rendszer véletlenszerűen választ egyet. Ha egy validátor azt észleli, hogy az ő elköteleződésére esett a választás, akkor tudja, hogy neki kell javasolnia a blokkot. + +Ennek az elképzelésnek a vezető implementációja a [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763). Ami a következőképpen működik: + +1. A validátorok elköteleződnek egy közös titok mellett. Az elköteleződési séma úgy van kialakítva, hogy bár köthető a validátor személyazonosságához, de egyúttal véletlenszerű is, így egy harmadik fél nem tudja visszafejteni az adott validátor személyazonosságát. +2. A korszak kezdetén a validátorok véletlenszerű csoportja kerül kiválasztásra, hogy mintát vegyenek a 16 384 validátorból a RANDAO használatával. +3. A következő 8182 slotra (1 nap), a blokkjavaslók összekeverik és véletlenszerűsítik az elköteleződések csoportját a saját privát entrópiájukat (véletlenszerűség) használva. +4. Ezután RANDAO készít egy sorba rendezett listát az elköteleződésekből. Ez a lista az Ethereum slotokhoz kapcsolódik. +5. A validátorok látják, hogy az elköteleződésük egy specifikus slothoz kapcsolódik, és annak bekövetkeztével javasolják a blokkot. +6. Ezeket a lépéseket ismétlik, hogy a hozzárendelés előrébb tartson, mint az aktuális slot. + +Ekkor a támadók nem tudják előre, hogy amelyik validátor jön legközelebb, így nem tudják megtámadni DOS módszerrel. + +## Egynél több titkos vezető kiválasztása (SnSLE) {#secret-non-single-leader-election} + +Van egy másik javaslat is, amelynek lényege, hogy a validátorok mindegyikének véletlenszerű esélye legyen a blokkjavaslásra minden slotban, hasonlóan ahhoz, ahogy a proof-of-work működött, ennek a neve a**egynél több titkos vezető kiválasztása (SnSLE)**. Az adott napi protokollban lévő validátorok véletlenszerű kiválasztásához egyszerű módot kínál a RANDAO-funkció. Ennek lényege, hogy egy kellően véletlenszerű szám keletkezik, amelyet több független validátor adat kevert hashekből. Az SnSLE esetében ezeket a hasheket lehetne használni a következő blokkjavasló kiválasztására, például a legkevesebb értékű hasht választva. Az érvényes hashek tartománya behatárolható, hogy finomhangolják a valószínűségét egy adott validátor kiválasztásának minden slotban. Ha a hashnek kevesebbnek kell lennie, mint `2^256 * 5 / N` ahol `N` az aktív validátorok számát jelenti, akkor annak az esélye, hogy valamelyik egyéni validátort kiválasztják a slotban az `5/N`. Ebben a példában 99,3% az esélye, hogy legalább egy blokkjavasló valid hasht készített minden slotban. + +## Jelenlegi helyzet {#current-progress} + +Az SSLE és az SnSLE még kutatási fázisban van. Nincs véglegesített specifikáció egyik elképzelésre sem. Az SSLE és az SnSLE egymással versengő javaslatok, nem lehet mindkettőt bevezetni. A bevezetéshez több kutatásra és fejlesztésre, prototípus-készítésre és a nyilvános teszthálózatokon való telepítésre van szükség. + +## További olvasnivaló {#further-reading} + +- [SnSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/single-slot-finality/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/single-slot-finality/index.md new file mode 100644 index 00000000000..0646ca66ed5 --- /dev/null +++ b/public/content/translations/hu/12) Roadmap 2/roadmap/single-slot-finality/index.md @@ -0,0 +1,66 @@ +--- +title: Egy sloton belüli véglegesség +description: Az egy sloton belüli véglegesség magyarázata +lang: hu +--- + +# Egy sloton belüli véglegesség {#single-slot-finality} + +Jelenleg 15 percet vesz igénybe, hogy egy Ethereum blokk véglegesedjen. Ugyanakkor az Ethereum konszenzusmechanizmusa úgy is fejleszthető, hogy a blokk validálása hatékonyabb legyen, és a véglegességhez szükséges idő drasztikusan csökkenjen. Ahelyett, hogy egy blokk javaslásához tizenöt perc kellene, azt ugyanabban a slotban lehessen javasolni és véglegesíteni. Ezt a koncepciót nevezik **egy sloton belüli véglegességnek (SSF)**. + +## Mi az a véglegesség? {#what-is-finality} + +Az Ethereum proof-of-stake alapú konszenzusmechanizmusában a véglegesítés arra utal, hogy a blokkot nem lehet megváltoztatni vagy eltávolítani a blokkláncból anélkül, hogy legalább 33%-nyi résztvevő vállalná az ezzel járó súlyos büntetést, vagyis az ETH elégetését. Ez egy kriptogazdasági biztonság, mert nagyon nagy költséggel járna, ha valaki meg akarná változtatni a lánc sorrendjét vagy tartalmát, így a racionális gazdasági szereplők nem vállalnák. + +## Miért törekszünk gyorsabb véglegesítésre? {#why-aim-for-quicker-finality} + +A véglegessé válás jelenlegi ideje túl hosszúnak bizonyult. A legtöbb felhasználó nem akar 15 percet várni, hogy végleges legyen a tranzakciója. Továbbá az alkalmazások és tőzsdék számára is kellemetlen, amelyek gyors tranzakcióátvitelt szeretnének, és mégis sokáig kell várniuk, hogy állandónak tekinthessék a változást. A blokk előterjesztése és a véglegesítése közötti idő arra is lehetőséget teremt, hogy egy támadó átrendezze a tartalmat, illetve hogy blokkokat cenzúrázzon vagy MEV-et szerezzen. Az a mechanizmus, amely a várakozó blokkok frissítését intézi, elég összetett és számtalanszor volt már javítva, hogy a gyenge biztonsági pontokat lezárják, így ez az Ethereum kódjának ez az a része, ahol kisebb hibák nagy valószínűséggel fordulnak elő. Ezeket a problémákat mind megoldaná, hogy ha egy slotban véglegessé válna a blokk. + +## A decentralizáció/idő/költség átváltása {#the-decentralization-time-overhead-tradeoff} + +A véglegesség garanciája az új blokknál nem azonnal történik meg; idő kell ahhoz, hogy a blokkot véglegesnek tekintsük. Ennek az az oka, hogy a véglegesítéshez a teljes letétbe helyezett ETH 2/3-át képviselő validátoroknak tanúsítaniuk kell az új blokkot. A hálózat minden validáló csomópontjának a többi csomóponttól érkező tanúsításokat kell feldolgoznia, hogy a blokk elérte a 2/3-os határt vagy nem. + +Minél rövidebb idő alatt kell elérni a véglegesedést, annál komolyabb számítási kapacitásra van szükség a csomópontoknál, mert a tanúsítást gyorsan kell elvégezni. Emellett minél több validáló csomópont van a hálózaton, annál több tanúsításra van szükség blokkonként, ami növeli a feldolgozási kapacitási igényt. Ha nagyobb feldolgozási kapacitás szükséges, akkor kevesebb személy vehet részt benne, mert drága hardvert kell ahhoz használni, hogy a validáló csomópont működjön. Ha a blokkok között több idő telik el, akkor kevesebb számítási kapacitás is elég a csomópontokhoz, de a véglegesedés is később történik meg, mert a tanúsításokat lassan dolgozzák fel. + +Így tehát átváltás van jelen a költség (számítási kapacitás), a decentralizáció (a validációban részt vevő csomópontok száma) és a véglegesítés ideje között. Az ideális rendszer a minimális számítási kapacitás, a maximális decentralizáció és a minimális véglegesítési idő között egyensúlyoz. + +Az Ethereum jelenlegi konszenzusmechanizmusa e három paraméter között a következőképpen egyensúlyoz: + +- **A minimális letétbe helyezést 32 ETH-ben állapítja meg**. Ez meghatároz egy felső határt arra, hogy a validátoroknak mennyi tanúsítást kell végezniük, amelyet az egyéni csomópontok hajtanak végre, és ezáltal egy felső határt határoz meg e csomópontok számítási igényeinek is. +- **A véglegesítés idejét kb. 15 percre teszi**. Ez elegendő időt ad az otthoni számítógépen futó validátoroknak is, hogy biztonsággal elvégezzék minden blokk tanúsítását. + +A jelenlegi mechanizmussal a véglegesítés idejét úgy lehet csökkenteni, ha csökkentjük a validátorok számát a hálózaton vagy növeljük a hardverszükségletet minden csomópont esetében. Ugyanakkor fejleszthető a tanúsítások végzése is, amellyel több tanúsítás lehetséges növekvő költség és az egyes csomópontok túlterhelése nélkül. A hatékonyabb végrehajtás lehetővé teszi, hogy a véglegesítés egy sloton belül, ne két korszak alatt történjen meg. + +## Az egy sloton belüli véglegesítéshez (SSF) vezető út {#routes-to-ssf} + + + +A jelenlegi konszenzusmechanizmus összekombinálja a több validátortól, vagyis a bizottságtól származó tanúsítást, hogy csökkentse az üzenetek számát, amelyet minden validátornak fel kell dolgoznia a validálás során. Minden validátornak lehetősége van tanúsítani egy adott korszakban (32 slot), de egy adott slotban csak a validátorok egy csoportja, a bizottság végzi a tanúsítást. Ehhez alhálózatokra osztódnak, amelyekben néhány validátor aggregátorként működik. Ezek az aggregátorok a saját alhálózatukban lévő validátortól látott összes aláírást összevonják egy aggregált aláírásba. Az aggregátor, aki a legtöbb egyéni hozzájárulást tudta összevonni, átadja az aggregált aláírást a blokk javaslattevőjének, aki azt beleteszi a blokkba a többi bizottságtól kapott aggregált aláírással együtt. + +Ez a folyamat elegendő kapacitást ad minden validátornak, hogy szavazzon minden korszakban, mert ez korszakonként 32 slot × 64 bizottság× 256 validátor bizottságonként = 524 288 validátor. A jelen szöveg írásának időpontjában (2023. február) kb. 513 000 aktív validátor van. + +E séma szerint egy teljes korszak kell ahhoz, hogy minden validátor részt vehessen a tanúsításban egy blokkhoz kapcsolódóan. Ugyanakkor lehetséges ezt a mechanizmust úgy is továbbfejleszteni, hogy minden validátor minden slotban végezhessen tanúsítást. + + +Mióta az Ethereum konszenzusmechanizmusát megtervezték, az aláírásaggregálás sémája (BLS) sokkal skálázhatóbbnak bizonyult, mint azt korábban gondolták, és közben a kliensek is fejlődtek az aláírások feldolgozásában és ellenőrzésében. Kiderült, hogy a nagy számú validátor valójában egyetlen slotban is képes végrehajtani a tanúsításokat. Például egymillió validátorral, akik közül mindenki kétszer szavaz egy slotban, a slot ideje pedig 16 másodperc, a csomópontoknak az aláírások ellenőrzését egy minimális másodpercenként 125 000 aggregációs rátán kellene végrehajtaniuk, hogy egymillió tanúsítást végezzenek a slotban. Valójában egy átlagos számítógépnek 500 nanomásodpercig tart egy aláírás ellenőrzése, tehát 125 000 ellenőrzést nagyjából 62,5 ms alatt végezne el – jóval az egy másodperces határ alatt. + +Még hatékonyabb lenne, ha szuperbizottságokat hoznának létre, pl. 125 000 véletlenszerűen kiválasztott validátort slotonként. Csak ezek a validátorok szavaznának egy adott blokkra, ezért a validátoroknak csak ezen alcsoportja döntene a blokk véglegesítéséről. Hogy vajon ez egy jó ötlet vagy sem, az azon múlik, hogy a közösség számára mennyire drága egy sikeres támadás az Ethereum ellen. Mivel ahelyett, hogy a támadó véglegesíteni tudna egy blokkot, ha a teljes letétbe helyett ethernek a 2/3-t kontrollálja, csak a _szuperbizottságban_ kell a 2/3-nyi lekötött etherrel bírnia egy rosszhiszemű blokk véglegesítéséhez. Ez továbbra is egy aktívan kutatott terület, de valószínű, hogy egy igazán nagy méretű validátorkészlet esetén, amelynél már szuperbizottságokat kell bevezetni, ezen csoportok megtámadásának költsége rendkívül magas lenne (pl. a denominált költség ETH-ben `2/3 × 125 000 × 32 = kb. 2,6 millió ETH`). A támadás költsége igazítható azáltal, hogy a validátorkészlet méretét megnövelik (pl. úgy igazítható a validátorszám, hogy a támadás költsége 1, 4, 10 stb. millió ether legyen). [A kezdeti vélemények](https://youtu.be/ojBgyFl6-v4?t=755) a közösség részéről azt sugallják, hogy az 1-2 millió ether egy elfogadható támadási költség, ami szuperbizottságonként ~65 536–97 152 validátort jelentene. + +Ugyanakkor nem az ellenőrzés a valódi szűk keresztmetszet, hanem az aláírások aggregálása a kihívás a validátor-csomópontok számára. Az aláírásaggregáció skálázásához a validátorok számát valószínűleg meg kell növelni minden alhálózatban, növelni kell az alhálózatok számát, vagy az aggregáció új rétegeit kell bevezetni (pl. a bizottságok bizottságát létrehozni). A megoldás része lehet a specializált aggregátorok létrehozása is, hasonlóan ahhoz, ahogy a javaslattevő-építő szétválasztás (PBS) és a Danksharding bevezetésénél a blokk építését és az összevont tranzakcióhoz tartozó elköteleződés létrehozását kiszervezik specializált építőknek. + +## Mi a szerepe az elágazásválasztásnak az SSF-ben? {#role-of-the-fork-choice-rule} + +A jelenlegi konszenzusmechanizmus a véglegesedési mechanizmus és az elágazásválasztás közötti szoros kapcsolaton alapszik, az első az az algoritmus, amely meghatározza, hogy a validátorok 2/3-a tanúsított-e egy adott láncot, a második pedig az az algoritmus, amelyik eldönti, hogy melyik lánc a megfelelő, amikor több opció is létezik. Az elágazásválasztás algoritmusa csak azokat a blokkokat veszi figyelembe, amelyek az utolsó véglegesített blokk _után_keletkeznek. Az SSF bevezetésével nem lesz olyan blokk, ami az elágazásválaszt határkörébe esik, mert a véglegesítés ugyanabban a slotban történik, mint a blokk előterjesztése. Ennélfogva az SSF bevezetésével _sem_ az elágazásválasztás algoritmusa, _sem_ a véglegességi mechanizmus nem lesz aktív. A véglegességi mechanizmus véglegesítené azokat a blokkokat, ahol a validátorok 2/3-a online volt és jóhiszeműen tanúsított. Ha a blokk nem tudná meghaladni a 2/3-os határt, akkor az elágazásválasztási szabály lépne életbe, hogy meghatározza a követendő láncot. Ez arra is lehetőséget ad, hogy az inaktivitás miatti elszivárgás mechanizmusát fenntartsák, amely visszaállítja a láncot, amikor a validátorok több mint 1/3-a offline, jóllehet némileg továbbfejlesztve azt. + +## Fennálló problémák {#outstanding-issues} + +Ha az aggregáció skálázásához az alhálózatokban megnövelnék a validátorok számát, az azzal a problémával járna, hogy a peer-to-peer hálózatra nagyobb teher nehezedne. Az aggregáció új rétegeinek bevezetése elég összetett programozási feladat és késleltetést okoz (mivel hosszabb időbe telik, mire a blokkot ellenőrző minden alhálózati aggregátortól kap valamit). Az sem egyértelmű, hogyan lehetne kezelni azt, hogy több aktív validátor van a hálózaton, mint amit egy slotban fel lehet dolgozni, még akár BLS aláírásaggregációval is. Mivel minden slotban minden validátor tanúsít és nincsenek bizottságok az SSF koncepcióban, egy lehetséges megoldás lehet az is, hogy az effektív egyenleg maximális 32 ETH határát teljesen eltörölnék, így a több validátort működtetők konszolidálhatnák a letétjeiket és kevesebb validátort futtathatnának, ezzel csökkentve az üzenetek számát, amelyet a validátor-csomópontoknak kell feldolgozniuk a teljes validátorkészletet illetően. A nagyletéteseken múlik, hogy konszolidálják a validátoraikat. Az is lehetséges, hogy bármikor felső határt húznak a validátorok számát vagy a letétbe helyezett ETH összegét illetően. Ugyanakkor ehhez szükséges egy olyan mechanizmus, amely eldönti, hogy melyik validátor vehet részt és amelyik nem, ez pedig nem kívánt másodlagos hatásokat okozhat. + +## Jelenlegi helyzet {#current-progress} + +Az SSF még kutatási fázisban van. Nem várható, hogy a következő években bevezetésre kerül, csak miután más lényeges fejlesztések elérhetővé váltak, mint a [Verkle-fák](/roadmap/verkle-trees/) és a [Danksharding](/roadmap/danksharding/). + +## További olvasnivaló {#further-reading} + +- [Vitalik az SSF-ről az EDCON rendezvényen (2022)](https://www.youtube.com/watch?v=nPgUKNPWXNI) +- [Vitalik jegyzetei: az egy sloton belüli véglegességhez vezető út](https://notes.ethereum.org/@vbuterin/single_slot_finality) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/statelessness/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/statelessness/index.md new file mode 100644 index 00000000000..3949b9a5d33 --- /dev/null +++ b/public/content/translations/hu/12) Roadmap 2/roadmap/statelessness/index.md @@ -0,0 +1,103 @@ +--- +title: Státuszmentesség, a státusz és az előzményadatok lejárata +description: Az előzményadatok lejáratának és a státuszmentes Ethereumnak a magyarázata +lang: hu +--- + +# Státuszmentesség, a státusz és az előzményadatok lejárata {#statelessness} + +A valódi decentralizácóhoz szükség van arra, hogy az Ethereum-csomópontokat egyszerű hardveren lehessen futtatni. A csomópontok futtatása lehetővé teszi a felhasználónak, hogy független kriptográfiai validálással ellenőrizzék az információkat, és ne kelljen megbízniuk egy harmadik félben, hogy az adatokkal lássa el őket. A csomópont futtatásával a felhasználó közvetlenül küldhet tranzakciót az Ethereum peer-to-peer hálózatára, és nem kell megbíznia egy közvetítőben. A decentralizáció nem lehetséges, ha ezek az előnyök csak a drága hardverrel rendelkező felhasználók számára elérhetők. Ehelyett a csomópontokat rendkívül szerény teljesítményű és memóriaigényű készülékeken is lehessen működtetni, mint amilyenek a mobiltelefonok, a mikroszámítógépek vagy az otthoni számítógépek. + +Jelenleg a nagy tárhelyigény jelenti a legnagyobb akadályt ahhoz, hogy a csomópontokat bárki működtethesse globálisan. Ennek az a fő oka, hogy az Ethereum státuszadatainak nagy halmazait kell eltárolni. Ezek a státuszadatok kritikus információkat tartalmaznak az új blokkok és tranzakciók megfelelő lefuttatásához. A jelen cikk írásának időpontjában egy gyors 2 TB SSD szükséges ahhoz, hogy egy teljes Ethereum csomópontot lehessen futtatni. Ez egy olyan csomópont tárhelyigénye, amely nem törli ki a régebbi adatokat és nagyjából heti 14 GB-tal nő. Az archív csomópontok pedig, amelyek a genezis óta az összes adatot tartalmazzák, már 12 TB-t érnek el (ezen leírás időpontjában, 2023. februárjában). + +A régebbi adatokhoz lehet olcsóbb merevlemezeket használni, de ezek túl lassúak ahhoz, hogy a bejövő blokkokkal lépést tartsanak. Az csak egy átmeneti és részleges megoldás, hogy a kliensek jelenlegi tárolási modelljét megtartva olcsóbbá és könnyebbé tegyük az adattárolást, mivel az Ethereum státusznövekedése határtalan, tehát a tárhelyigény csak növekszik, a technológiai fejlesztéseknek pedig folyamatosan lépést kell tartaniuk ezzel. Ehelyett a klienseknek új módszert kell találni a blokkok és tranzakciók ellenőrzésére, amelyhez az adatokat nem szükséges a lokális adatbázisból kikeresni. + +## A csomópontokhoz szükséges tárhely csökkentése {#reducing-storage-for-nodes} + +Számos módon le lehet csökkenteni a csomópontban tárolt adatmennyiséget, ehhez azonban különféle mértékben, de módosítani kell az Ethereum-protokollon: + +- **Az előzményadatok lejárata**: lehetővé teszi, hogy a csomópont törölje azokat a státuszadatokat, amelyek X blokknál régebbiek, de nem változtatja meg a Ethereum-kliens státuszkezelési módját +- **A státusz lejárata**: lehetővé teszi, hogy inaktívvá válhassanak azok a státuszadatok, amelyeket nem használnak rendszeresen. Az inaktív adatokkal nem kell foglalkoznia a kliensnek mindaddig, amíg az újból be nem hívják őket. +- **Gyenge státusztalanság**: csak a blokk-készítőknek van szükségük a teljes státuszadatra, a többi csomópont a lokális státuszadatbázis nélkül is képes ellenőrizni a blokkokat. +- **Erős státusztalanság**: semelyik csomópontnak nincs szüksége az összes státuszadatra. + +## Az adatok lejárata {#data-expiry} + +### Az előzményadatok lejárata {#history-expiry} + +Az előzményadatok lejárata azt jelenti, hogy a kliensek törlik a régebbi adatokat, amelyekre már valószínűleg nem lesz szükség, így csak kevés előzményadatot tárolnak, és az új adatok felülírják a legrégebbieket. A klienseknek két okból van szükségük előzményadatokra: szinkronizáláshoz és adatlekérdezések teljesítéséhez. Eredetileg a klienseknek a genezisblokkból kellett szinkronizálniuk, ellenőrizve, hogy minden egyes soron következő blokk megfelelő-e egészen a lánc elejéig. Jelenleg a kliensek ezt az utat a lánc elejéig a „gyenge szubjektivitású ellenőrzési pontoktól” kiindulva teszik meg. Ezek az ellenőrzési pontok megbízható kiindulási pontok, vagyis olyan, mintha a genezisblokk közelebb lenne a jelenhez, nem az Ethereum kezdetétől nézné. Tehát a kliensek törölhetnek minden olyan információt, amely a legutóbbi gyenge szubjektivitású ellenőrzési pontnál korábbi, így is képesek szinkronizálni a lánc elejével. A kliensek jelenleg úgy szolgáltatnak előzményadatokat (amelyek JSON-RPC-n keresztül érkeznek), hogy azokat a helyi adatbázisukból kérik le. Ez az előzményadatok lejáratával nem lesz lehetséges, mert az adat egy része nem lesz már elérhető. Az előzményadatok biztosítására egy innovatív megoldásra van szükség. + +Az egyik lehetőség az, hogy a kliensek az előzményadatokat a társaiktól kérik le olyan megoldással, mint amilyen a Portal Network. A Portal Network egy fejlesztés alatt álló peer-to-peer hálózat az előzményadatok biztosítására, ahol minden csomópont az Ethereum előzményadatának egy kis részét tárolja, így a teljes adathalmaz a hálózaton elosztva létezik. Ezek megszerzése úgy működik, hogy megkeresik azokat a peereket, akik tárolja az adott adatokat és lekérik tőlük ezeket. Másik megoldás lehet, hogy mivel általában az alkalmazásoknak van szüksége előzményadatokra, ezért az ő felelősségük lenne ezek tárolása. Talán lenne elég önfeláldozó szereplő az Ethereum világában, akik önkéntesen tárolnának előzményarchívumokat. Lehetne egy decentralizált autonóm szervezet (DAO), ami felvállalja az adattárolást, vagy ideális esetben lehetne ezen opciók kombinációja is. Ezek a szolgáltatók számos módon szolgálhatnának adattal, például torrent, FTP, Filecoin vagy IPFS formájában. + +Az előzményadatok lejárata egy kicsit ellentmondásos téma, mert eddig az Ethereum mindig nyilvánosan vállalta bármilyen adat elérhetőségét. Mindig alapból elérhető volt egy teljes szinkronizáció a genezistől kezdve, még akkor is, ha az újraépítéshez a régi adatok pillanatfelvételét kellett használni. Az előzményadatok lejárata ezt a felelősséget az Ethereum-protokollon kívülre helyezi. Ez akár új cenzúrakockázatot is hordozhat magában, ha végül centralizált szerzetek biztosítják az előzményadatokat. + +Az EIP-4444 még nem áll készen, de aktív egyeztetés folyik róla. Érdekes módon, az EIP-4444-gyel kapcsolatos kihívások jellemzően nem technikaiak, hanem inkább a közösségi kezelésből erednek. A közösségnek bele kell egyeznie az új módszerbe, el kell fogadnia, hogy az előzményadatokat megbízható entitások szolgáltassák. + +Ez a fejlesztés nem változtatja meg alapjaiban az Ethereum-csomópontok státuszadat-kezelését, csak azok elérésére lesz hatással. + +### A státusz lejárata {#state-expiry} + +A státusz lejárata azt jelenti, hogy az egyéni csomópontokból eltávolítják a státuszt, ha azt az utóbbi időben nem használták. Ezt többféle módon is meg lehet valósítani, például: + +- **Lejárat a bérleti díj alapján**: kapcsoljunk a számlákhoz „bérleti díjat”, és amikor ez nullázódik, akkor a számla is lejár +- **Lejárat idő alapján**: a számlák inaktíválódnak, ha egy ideig nem végeznek olvasási/írási műveletet rajtuk + +A bérleti díj alapján vett lejárat lehet egy közvetlen díjkérés a számláktól, hogy azok maradjanak aktív állapotban az adatbázisban. Az idő alapján vett lejárat lehet az utolsó interakció óta eltelt idő, illetve az összes számla periodikus lejárata. Lehetnek olyan mechanizmusok is, amelyek ötvözik az idő- és a bérletidíj-alapú modelleket, például az egyéni számlák aktív státuszban maradnak, ha fizetnek egy kis összeget az időalapú lejárat előtt. Ezzel kapcsolatban fontos megérteni, hogy az inaktív állapot nem jelent **törlést**, csak elkülönítve tárolják a kapcsolódó adatokat az aktív státusztól. Az inaktív státuszt vissza lehet állítani élő állapotra. + +Ez úgy valósulhat meg, hogy például egy státuszfa áll rendelkezésekre bizonyos időperiódusokra (talán 1 évre). Amikor az új periódus elkezdődik, egy teljesen új státuszfa jön létre. Csak a jelenlegi státuszfát lehet módosítani, a többi megváltoztathatatlan. Az Ethereum-csomópontoknak csak a jelenlegi és a legutóbbi státuszfát kellene tárolniuk. Ehhez időbélyeget kell tenni a címekre, hogy melyik periódusban léteznek. [Számos módja van annak](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607), hogy ezt bevezessék, de a legjobb megoldáshoz a [címeket meg kell hosszabbítani](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485), hogy elférjen az új információ, illetve a hosszabb címek biztonságosabbak is. Az ütemtervben ezt a fejlesztés a [címhely kiterjesztése](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) címen szerepel. + +Az előzményadatok lejáratához hasonlóan a státuszlejáratnál is az egyéni felhasználók helyett tárolhatják a régi státuszadatokat más entitások, mint központi szolgáltatók, önfeláldozó közösségi tagok vagy olyan jövőbeli, decentralizált megoldások, mint amilyen a Portal Network. + +A státusz lejárata még kutatási fázisban van, a fejlesztés nem áll készen a bevezetésre. A státuszlejárat talán a státuszmentes kliensek és az előzményadatok lejárata után kerül bevezetésre, mert ezek a fejlesztések a legtöbb validátor számára már kezelhetővé teszik a nagy státuszokat. + +## Hontalanság {#statelessness} + +A státusztalanság nem azt jelenti, hogy a státusz megszűnik, hanem megváltozik az Ethereum-csomópontok státuszkezelési módja. A státusztalanság kétféle jelleget ölthet: gyenge és erős státusztalanság. A gyenge státusztalanság a legtöbb csomópont számára megengedi, hogy státusz nélkül állapotban fussanak, mivel csak néhánynak lesz a feladata a tárolás. Az erős státusztalanság megszűnteti azt, hogy bármelyik csomópontnak tárolnia kelljen az összes státuszadatot. Mindkét fajta a következő előnyökkel jár az átlagos validátorok számára: + +- szinte azonnali szinkronizálás +- képesek a blokkokat soron kívül is validálni +- a csomópontokat egyszerű hardverrel is lehet futtatni (pl. telefonnal) +- a csomópontokhoz olcsó merevlemezt is lehet használni, mert nincs szükség írásra/olvasásra +- kompatibilis az Ethereum elkövetkező kriptográfiai fejlesztéseivel + +### Gyenge státusztalanság {#weak-statelessness} + +A gyenge státusztalanság megváltoztatja azt, ahogy az Ethereum-csomópontok ellenőrzik a státuszváltozásokat, de teljesen nem szüntetik meg azt, hogy a hálózaton néhány csomópontnak ne kelljen státuszt tárolni. Ehelyett a státusz tárolásának felelősségét a blokkelőterjesztőknek adja, a hálózat többi csomópontja, amely a blokkokat ellenőrzi, működhet a teljes státuszadat nélkül. + +**Gyenge státusztalanság esetén a blokkelőterjesztőknek szükségük van a teljes státuszadatra, de az ellenőrzőknek nincs** + +Ehhez előbb [Verkle-fákat](/roadmap/verkle-trees/) kell bevezetni az Ethereum-klienseknél. A Verkle-fák adatstruktúrák az Ethereum státuszainak tárolására, amelyek kicsi, fix méretű „tanúkat” készítenek, amelyet meg lehet osztani a társakkal, és a blokkokat ezekhez lehet validálni a lokális adatbázisok helyett. Egy [ javaslattevő-építő szétválasztás (PBS)](/roadmap/pbs/) is szükséges, mert így a blokképítőknek specializált csomópontjaik lehetnek sokkal erőteljesebb hardverrel, és csak nekik kell hozzáférni a teljes státuszadathoz. + + + +A státusztalanság arra épül, hogy a blokképítők tárolják a teljes státuszadatot, így képesek olyan tanúkat készíteni, amit a blokk validálásához használnak. A többi csomópontnak nincs szüksége a státuszadatokra, minden szükséges információ benne van a tanúban. Ez egy olyan helyzet, amelyben a blokképítés drága, viszont a blokkellenőrzés olcsó tevékenység, így kevesebben fognak blokképítő csomópontokat működtetni. Ugyanakkor a blokképítők decentralizációja nem annyira kritikus téma, hogyha a lehető legtöbb résztvevő képes függetlenül részt venni a blokkok ellenőrzésében. + +Tudjon meg többet a témáról Dankrad jegyzeteiből + + +A blokképítők használják a státuszadatot a tanúk létrehozásához – ez egy minimális adathalmaz, mellyel ellenőrizhető a blokkban lévő tranzakciók által okozott státuszváltozás. A többi validátornak nincs szüksége a státuszra, csak a státuszgyökeret (a teljes státusz hashje) tárolják. Megkapják a blokkot és a tanút, és ezeket felhasználva frissítik a saját státuszgyökerüket. Ezáltal a validáló csomópont rendkívül könnyű lesz. + +A gyenge státusztalanság a kutatás előrehaladott állapotában tart, de a bevezetése a javaslattevő-építő szétválasztáson (PBS) és a Verkle-fák bevezetésén múlik, hogy a kis méretű tanúkat el lehessen küldeni a társaknak. Ez alapján a bevezetése talán néhány év múlva történhet meg az Ethereum főhálózatán. + +### Erős státusztalanság {#strong-statelessness} + +Az erős státusztalanság megszünteti azt, hogy bármelyik csomópontnak tárolnia kelljen a státuszadatot. Ehelyett a tranzakciókat a tanúkkal együtt küldik, amelyet a blokképítők aggregálnak. Így a blokképítők felelősek azért, hogy a szükséges státuszokat tárolják, hogy abból elkészítsék a tanúkat a releváns számlákra. A státuszhoz kapcsolódó felelősség szinte teljesen a felhasználókhoz kerül, mivel tanúkat és hozzáférési listákat küldenek arról, hogy milyen számlákkal és tárhelykulcsokkal kapcsolódnak. Ennek következtében rendkívül könnyű csomópontok működhetnek, viszont az okosszerződésekkel nehezebb lesz az interakciójuk. + +Az erős státusztalanságot vizsgálják a kutatók, de jelenleg nem valószínű, hogy része lesz az Ethereum ütemtervének – sokkal valószínűbb, hogy a gyenge státusztalanság elegendő az Ethereum skálázási igényekhez. + +## Jelenlegi helyzet {#current-progress} + +A gyenge státusztalanság, az előzményadatok és a státuszadatok lejárata még kutatási fázisban van, és talán évek múlva kerül bevezetésre. Az sem biztos, hogy a javaslatokból mindegyiket be kell vezetni, mert kiderülhet például, hogy a státusz lejárati ideje után már nincs szükség az előzményadat-lejáratot is megvalósítani. Előbb az ütemterv más elemeiknek kell megvalósulniuk, mint például a [Verkle-fák](/roadmap/verkle-trees) és a [javaslattevő-építő szétválasztás (PBS)](/roadmap/pbs). + +## További olvasnivaló {#further-reading} + +- [Vitalik a státusztalanságról (AMA)](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) +- [A státuszméret menedzsmentjének elmélete](https://hackmd.io/@vbuterin/state_size_management) +- [Státusz összekapcsolása az élesedés okozta konfliktus minimalizálására](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) +- [A státusztalansághoz és a státuszlejárathoz vezető út](https://hackmd.io/@vbuterin/state_expiry_paths) +- [Az EIP-4444 specifikációi](https://eips.ethereum.org/EIPS/eip-4444) +- [Alex Stokes az EIP-4444 fejlesztéséről](https://youtu.be/SfDC_qUZaos) +- [Miért olyan fontos a státusztalanság](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) +- [Ez eredeti státusztalan kliens koncepciójának leírása](https://ethresear.ch/t/the-stateless-client-concept/172) +- [Bővebben a státuszlejáratról](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) +- [Még több tudnivaló a státuszlejáratról](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/verkle-trees/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/verkle-trees/index.md new file mode 100644 index 00000000000..2f608b229e9 --- /dev/null +++ b/public/content/translations/hu/12) Roadmap 2/roadmap/verkle-trees/index.md @@ -0,0 +1,66 @@ +--- +title: Verkle-fák +description: A Verkle-fák részletes bemutatása, illetve annak leírás, hogy miként használják ezeket az Ethereum fejlesztésére +lang: hu +summaryPoints: + - Fedezze fel, hogy mire valók a Verkle-fák + - Tekintse meg, hogy a Verkle-fák hogyan járulnak hozzá az Ethereum fejlődéséhez +--- + +# Verkle-fák {#verkle-trees} + +A Verkle-fák (a vektor elköteleződés és a „Merkel-fák” összevonásából) olyan adatstruktúrát alkotnak, amely az Ethereum-csomópontokat fejleszti, hogy ne kelljen nagy mennyiségű státuszadat tárolniuk, de mégis validálni tudják a blokkokat. + +## Hontalanság {#statelessness} + +A Verkle-fák kritikus lépést jelentenek a státusztalan Ethereum-kliensekhez vezető úton. A státusztalan kliensek úgy tudják validálni a bejövő blokkokat, hogy ahhoz nem kell tárolniuk a teljes státuszadatbázist. Ahelyett, hogy az Ethereum státuszának saját lokális másolatát használnák, a státusztalan kliensek egy „tanút” használnak a státuszadatokhoz, amely a blokkal együtt érkezik. A tanú a státuszadat egyéni darabjainak halmaza, amely ahhoz szükséges, hogy a tranzakciók egy adott kötegét le lehessen futtatni, illetve egy kriptográfiai bizonyíték arra, hogy a tanú valóban a teljes adat része. Ezt a tanút használják a státuszadatbázis _helyett_. Ehhez arra van szükség, hogy a tanúk nagyon kis méretűek legyenek, így biztosan időben el lehet juttatni őket a hálózaton keresztül a validátorokhoz, hogy azt egy 12 másodperces slotban feldolgozzák. A jelenlegi státuszadatstruktúra nem megfelelő, mert a tanúk túl nagy méretűek. A Verkle-fák megoldják ezt a problémát, mert kis méretű tanúkat tudnak készíteni, így a státusztalan kliensek egyik fő akadályát ki tudják küszöbölni. + + + +Az Ethereum-kliensek jelenleg a Patricia Merkle Trie-adatstruktúrát használják a státuszadatok tárolására. Az egyéni számlákra vonatkozó információk a fa és a digitális fa leveleiként tárolódnak, ahol a levélpárokat addig hashelik, amíg már csak egyetlen hash marad. Ezt a végső hasht hívják gyökérnek. A blokkellenőrzéshez az Ethereum-kliensek végrehajtják az összes tranzakciót a blokkban és frissítik a lokális státuszfájukat. A blokkot akkor tekintik érvényesnek, amikor a lokális fa gyökere azonos lesz azzal, amit a blokkelőterjesztő adott, mivel ha bármilyen különbség lenne az előterjesztő és a validáló csomópont számolása között, akkor a gyökérhash teljesen eltérne. Ezzel az a gond, hogy a blokklánc validálásához minden kliensnek tárolnia kell a vezetőblokk és számos előzményblokk teljes státuszfáját (a Geth-ben alapvető, hogy a vezetőblokk utáni 128 blokkra megtartják a státuszadatokat). Ehhez a klienseknek nagy tárhelyre van szükségük, ami megakadályozza, hogy teljes csomópontokat lehessen olcsón és kisebb kapacitású hardverrel üzemeltetni. Ezt úgy lehet megoldani, hogy a státuszfát egy hatékonyabb struktúrára (Verkle-fa) cserélik, ami képes kis méretű tanúkkal összefoglalni az adatokat, amit a teljes státuszadat helyett meg lehet osztani a validátorokkal. A státuszadat átformázása a Verkle-fa struktúrájába egy mérföldkő a státuszmentes kliensek bevezetéséhez. + + + +## Mi az a tanú és miért van rá szükség? {#what-is-a-witness} + +A blokk ellenőrzése azt jelenti, hogy a benne lévő tranzakciókat újra végrehajtják, megváltoztatják az Ethereum státuszfát, és kiszámolják az új gyökérhasht. Az érvényes blokk az lesz, amelynek a kiszámolt státuszgyökér-hashe ugyanazt, mint amit a blokkal együtt adtak (mert ekkor a blokkot javasló valóban végrehajtotta a számításokat úgy, ahogy mondja). A jelenlegi Ethereum-kliensekben a státusz frissítéséhez hozzá kell férni a teljes státuszfához, ami egy nagyméretű adatstruktúra, és lokálisan kell azt tárolni. A tanú a státuszadatnak csak töredékeit tartalmazza, ami a blokkban lévő tranzakciók lefuttatásához szükségesek. A validátornak tehát csak ezeket a töredékeket kell használnia arra, hogy leellenőrizze, a javaslattevő végrehajtotta-e a blokk tranzakcióit és megfelelő módon frissítette-e a státuszt. Ugyanakkor ez azt is jelenti, hogy a tanút az Ethereum hálózatán olyan gyorsan kell eljuttatni a peereknek, hogy azt biztosan megkapja és feldolgozza minden egyes csomópont a 12 másodperces slotban. Ha a tanú túl nagy méretű, akkor néhány csomópont számára sokáig tart a letöltése, így nehéz lépést tartani a lánccal. Ez egy centralizáló erő, mert csak gyors internetkapcsolattal bíró csomópontok vehetnek részt a blokkvalidálásban. A Verkle-fák révén nem kell a státuszt a merevlemezen tárolni; a blokk validálásához _mindent_ maga a blokk tartalmaz. Sajnos a Merkle-fákból előállítható tanúk túl nagy méretűek ahhoz, hogy lehetővé tegyék a státusztalan klienseket. + +## Hogyan állítható elő a Verkle-fákkal kisebb méretű tanúk? {#why-do-verkle-trees-enable-smaller-witnesses} + +A Merkle-fa struktúrája nagy méretű tanúkat ad – ezeket nem lehet biztonsággal szétküldeni a peerek között a 12 másodperces slotban. Ennek az az oka, hogy a tanú egy olyan útvonal, amely összeköti az adatokat (amelyeket a levelek tartalmaznak) a gyökérhash-sel. Az adatok ellenőrzéséhez nem elég az összes köztes hash, ami összeköti a leveleket és a gyökeret, hanem szükség van testvérpontokra is. A bizonyítékban minden csomópontnak van egy testvére, amivel hashelődik, hogy létrehozza a fa következő hashét. Ez rengeteg adat. A Verkle-fák úgy csökkentik a tanú méretét, hogy megrövidítik a falevelek és a gyökér közötti távolságot, és nem kell a testvérpontokat is megadni ahhoz, hogy a gyökér-hash validálható legyen. Még ennél is több hely nyerhető azzal, hogy egy erőteljes polinomiális elköteleződési sémát használnak a hash-stílusú vektorelköteleződés helyett. A polinomiális elköteleződés lehetővé teszi, hogy a tanú adott méretű legyen, függetlenül az általa bizonyított levelek számától. + +A polinomiális elköteleződési séma alapján a tanú kezelhető méretű lesz, és könnyedén átadható a peer-to-peer hálózaton keresztül. Ez alapján a kliensek minimális adatmennyiséggel képesek minden blokkban ellenőrizni a státuszváltozást. + + + +A tanú mérete a benne lévő levelek száma alapján változik. Feltéve, hogy a tanú 1000 levelet fed le, akkor a Merkle-fához tartozó tanú 3,5 MB lenne (egy 7 szintű fa esetében). Ugyanezen adatok esetében a Verkle-fa tanúja (4 szintű fát feltételezve) 150 kB – **ez nagyjából 23-szor kisebb**. A tanú ilyen szintű méretcsökkenése megengedi, hogy a státusztalan kliensek tanúi elfogadhatóan kicsik maradjanak. A polinomiális tanúk 0,128–1 kB méretűek, attól függően, hogy amelyik polinomiális elköteleződést használják. + + + +## Mi a Verkle-fák struktúrája? {#what-is-the-structure-of-a-verkle-tree} + +A Verkle-fák `key, value` (kulcs, érték) párokból állnak, ahol a kulcsok 32 bájtos elemek, amelyek egy 31 bájtos _tőből_ és egy egyetlen bájtos _toldalékból_ tevődnek össze. Ezek a kulcsok _kiterjesztő_ pontokba és _belső_ pontokba rendeződnek. A kiterjesztőpontok egyetlen tövet képviselnek 256 gyermek számára különböző toldalékokkal. A belső pontoknak is 256 gyermekük van, de ezek lehetnek más kiterjesztőpontok is. A Verkle- és a Merkle-fastruktúra közötti fő különbség az, hogy a Verkle-fa sokkal laposabb, kevesebb köztes pont kapcsolja a levelet a gyökérhez, ezért kevesebb adat kell a bizonyíték legyártásához. + +![](./verkle.png) + +[Tudjon meg többet a Verkle-fák struktúrájáról](https://blog.ethereum.org/2021/12/02/verkle-tree-structure) + +## Jelenlegi helyzet {#current-progress} + +A Verkle-fa teszthálózatai már működnek, de jelentős mértékű kliensfrissítésre van még szükség ahhoz, hogy támogatni tudják ezt az adatstruktúrát. Ön is segíthet a fejlesztés meggyorsításában, ha szerződéseket hoz létre a teszthálózaton és klienseket működtet a teszthez. + +[Fedezze fel a Verkle Gen Devnet 6 teszthálózatot](https://verkle-gen-devnet-6.ethpandaops.io/) + +[Nézze meg, ahogy Guillaume Ballet bemutatja a Condrieu Verkle-teszthálózatot](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (a Condrieu teszthálózat még a proof-of-work mechanizmus szerint működött, és mára már Verkle Gen Devnet 6 teszthálózat váltotta fel). + +## További olvasnivaló {#further-reading} + +- [Verkle-fák a státusztalanság megvalósításához](https://verkle.info/) +- [Dankrad Feist magyarázata a Verkle-fákról a PEEPanEIP csatornán](https://www.youtube.com/watch?v=RGJOQHzg3UQ) +- [Guillaume Ballet magyarázata a Verkle-fákról az ETHGlobal rendezvényen](https://www.youtube.com/watch?v=f7bEtX3Z57o) +- [„Hogyan segítenek a Verkle-fák abban, hogy az Ethereum áttekinthető és egyszerű legyen?” – Guillaume Ballet előadása a Devcon 6 rendezvényen](https://www.youtube.com/watch?v=Q7rStTKwuYs) +- [Piper Merriam előadása a státusztalan kliensekről az ETHDenver 2020-as rendezvényén](https://www.youtube.com/watch?v=0yiZJNciIJ4) +- [Dankrad Fiest Verkle-fákról és státuszmentességről szóló podcastja a Zero Knowledge csatornán](https://zeroknowledge.fm/episode-202-stateless-ethereum-verkle-tries-with-dankrad-feist/) +- [Vitalik Buterin magyarázata a Verkle-fákról](https://vitalik.eth.limo/general/2021/06/18/verkle.html) +- [Dankrad Feist magyarázata a Verkle-fákról](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html) +- [A Verkle-fák EIP-dokumentációja](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/accounts/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/accounts/index.md new file mode 100644 index 00000000000..a0a01058a0c --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/accounts/index.md @@ -0,0 +1,136 @@ +--- +title: Ethereum számlák +description: Az Ethereum számlák magyarázata – az adatstruktúrájuk és a kapcsolatuk a kulcspár kriptográfiával. +lang: hu +--- + +Egy Ethereum számla egy olyan entitás, mely ether (ETH) egyenleggel rendelkezik és tranzakciókat tud indítani az Ethereumon. A számlák lehetnek felhasználók által irányítottak, vagy okos szerződésként telepítettek. + +## Előfeltételek {#prerequisites} + +Ennek az oldalnak a jobb megértése érdekében javasoljuk, hogy először olvassa el a [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) oldalunkat. + +## Számlatípusok {#types-of-account} + +Az Ethereum két számlatípust kínál: + +- Externally owned account (EOA) – bárki irányíthatja a privát kulcsokkal +- Szerződéses számla – egy okosszerződés, amelyet a hálózatra telepítettek és kód irányítja. Tudjon meg többet az [okosszerződésekről](/developers/docs/smart-contracts/) + +Mindkét számlatípus képes: + +- ETH és más tokenek fogadása, tartása és küldése +- Interakcióba lépni a telepített okosszerződésekkel + +### Legfontosabb különbségek {#key-differences} + +**Külső tulajdonú** + +- Egy számla létrehozása nem kerül semmibe +- Tranzakciókat indíthatsz +- A külső tulajdonú számlák közötti tranzakciók csak ETH/token átutalások lehetnek +- Egy kriptográfiai kulcspárból állnak: a nyilvános és a privát kulcs kontrollálja a számlával kapcsolatos ügyleteket + +**Szerződés** + +- Egy számla létrehozása költséggel jár, mivel a hálózati tárhelyet használja +- Csak úgy küldhet tranzakciókat ha az egy válasz egy bejövő tranzakcióra +- A külső tulajdonú számláról szerződéses számlára küldött tranzakciók egy programkódot indítanak, amely sokféle parancsot tud végrehajtani, mint például token átutalása vagy akár új szerződés létrehozása +- A szerződéses számláknak nincs privát kulcsuk. Ehelyett az okosszerződés logikája kontrollálja azokat + +## Egy számla közelebbről {#an-account-examined} + +Az Ethereum számláknak négy mezőjük van: + +- `nonce` – Egy számláló, amely az elküldött tranzakciók számát (külső tulajdonú számla) vagy a létrehozott szerződések számát (szerződéses számla) mutatja. Egy adott nonce segítségével csak egy tranzakció hajtható végre az adott számlára, így nem lehet újrajátszani a tranzakciót, így védve van az ilyen jellegű támadásoktól. +- `balance` – A cím által birtokolt Wei-k száma. A Wei az ETH denominált egysége és 1e+18 Wei van egy ETH-ben. +- `codeHash` – Ez a hash egy számla _kódjára_ hivatkozik az Ethereum Virtuális Gépen (EVM). A szerződéses számlák olyan kódrészleteket tartalmaznak, amelyek különféle műveleteket tudnak végrehajtani. Ez az EVM-kód kerül végrehajtásra, ha a számla egy üzenethívást kap. A többi számlamezővel ellentétben ezt nem lehet megváltoztatni. Az összes ilyen kódrészletet az státuszadatbázis tartalmazza a megfelelő hashek alatt későbbi visszakeresés céljából. Ezt a hash-értéket nevezik codeHash-nek. Külső tulajdonú számláknál a codeHash mező egy üres sztring hash-e. +- `storageRoot` – Néha úgy is hivatkoznak rá, mint tárhely-hash. Egy Merkle Patricia trie gyökér csomópontjához tartozó 256 bites hash, amely a számla tárhelyének tartalmát kódolja (256 bites integer értékek közötti leképzés), a fába kódolva, mint egy 256 bites integer kulcsok 256 bites Keccak hash-e és az RLP kódolású 256 bites integer értékek közötti leképzés. Ez a fa a számla tárolótartalmának hash-ét kódolja, és alapértelmezés szerint üres. + +![Egy diagram mely egy számla felépítését mutatja be](./accounts.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból + +## Külső tulajdonú számlák és kulcspárok {#externally-owned-accounts-and-key-pairs} + +Egy számla egy kriptográfiai kulcspárból áll: egy publikusból és egy privátból. Segítenek bizonyítani, hogy a tranzakciót valóban a küldő írta alá és megelőzik a hamisítást. A privát kulcs az, amellyel aláírja a tranzakciókat, így felügyeletet biztosít a számlához tartozó pénz felett. Valójában sosem birtokolsz kriptovalutát, privát kulcsokat birtokolsz - a tőke mindvégig az Ethereum főkönyvében van. + +Ez biztosítja azt, hogy rosszindulatú szereplők ne indíthassanak hamis tranzakciókat, mivel mindig azonosítani tudod a tranzakció küldőjének kilétét. + +Ha Alice ethert szeretne küldeni a számlájáról Bob számlájára, akkor Alice-nek egy tranzakció kérelmet kell készítenie és elküldeni a hálózatra hitelesítésre. Az Ethereum publikus kulcs kriptográfiája biztosítja, hogy Alice be tudja bizonyítani, hogy ő volt aki elindította a tranzakciós kérelmet. Kriptográfiai mechanizmusok nélkül egy kártékony ellenség, Eve, egyszerűen elküldhetne egy kérelmet, mely úgy néz ki, mint „küldj 5 ETH-t Alice számlájáról Eve számlájára” és senki sem tudná bebizonyítani, hogy ez nem Alice-től származik. + +## Számla létrehozása {#account-creation} + +Amikor szeretne létrehozni egy számlát, akkor a legtöbb könyvtár generál egy véletlenszerű privát kulcsot. + +Egy privát kulcs 64 hexadecimális karakterből áll, és jelszóval lehet titkosítani. + +Példa: + +`fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f` + +A nyilvános kulcsot a privát kulcsból generálják az [Elliptic Curve Digital Signature Algorithm](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) segítségével. A számla publikus címét úgy lehet megkapni, ha elvesszük a legutolsó 20 bájtot a Keccak-256 hash nyilvános kulcsából és hozzáadunk egy `0x` előtagot az elejére. + +Ez azt jelenti, hogy egy külső tulajdonú számla (EOA) 42 karakter hosszú címmel bír (20 bájtnyi szegmens, ami 40 hexadecimális karakter, plusz a `0x` előtag). + +Példa: + +`0x5e97870f263700f46aa00d967821199b9bc5a120` + +A következő példa megmutatja, hogyan lehet a [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) nevű aláíró eszközzel egy új számlát létrehozni. A Clef egy számlakezelő és -aláíró eszköz, amely az Ethereum klienssel, a [Geth-szel](https://geth.ethereum.org) van egybecsomagolva. A `clef newaccount` parancs egy új kulcspárt hoz létre, és egy titkosított kulcstárolóba menti el. + +``` +> clef newaccount --keystore + +Please enter a password for the new account to be created: +> + +------------ +INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120 +WARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120 +WARN [10-28|16:19:09.306] Please remember your password! +Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120 +``` + +[Geth-dokumentáció](https://geth.ethereum.org/docs) + +Lehetséges új publikus kulcsokat származtatni a privát kulcsodból, de nem tudsz publikus kulcsokból privát kulcsot származtatni. Létfontosságú a privát kulcs biztonságban tartása, mert ahogy a neve is sugallja, ez **PRIVÁT**. + +Egy privát kulcsra van szükséged, hogy üzeneteket és tranzakciókat tudj aláírni, mely egy aláírást hoz létre. Ezáltal mások az aláírásodból leszármaztathatják a publikus kulcsodat, amely az üzenet feladójának kilétét bizonyítja. Az alkalmazásában használhat javascript könyvtárat, hogy tranzakciókat küldjön a hálózatra. + +## Szerződéses számlák {#contract-accounts} + +A szerződéses számláknak szintén egy 42 karakterből álló hexadecimális címük van: + +Példa: + +`0x06012c8cf97bead5deae237070f9587f8e7a266d` + +Ez a szerződés cím általában akkor jön létre, amikor egy szerződést feltelepítenek az Ethereum blokkláncra. A cím a készítő címéből és az erről a címről küldött tranzakciók számából („nonce”) származik. + +## Validátorkulcsok {#validators-keys} + +Az Ethereumon létezik egy másik típusú kulcs is, amelyet a proof-of-work-alapú konszenzusról a proof-of-stake-alapúra való átálláskor vezettek be. Ezek a BLS kulcsok, amelyek a validátorokat azonosítják. Hatékonyan aggregálhatók, hogy a hálózatnak kevesebb sávszélességre legyen szüksége a konszenzus elérésekor. Ezen kulcsaggregáció nélkül a validátor minimális letétének sokkal nagyobbnak kellene lennie. + +[Bővebben a validátorkulcsokról](/developers/docs/consensus-mechanisms/pos/keys/). + +## Megjegyzés a tárcákkal kapcsolatban {#a-note-on-wallets} + +A számla nem egyenlő a tárcával. A tárca egy olyan interfész vagy alkalmazás, amely lehetővé teszi az Ethereum-számlával való interakciót, legyen az külső tulajdonú számla vagy szerződéses számla. + +## Egy vizuális bemutató {#a-visual-demo} + +Nézze meg, ahogy Austin elmagyarázza a hash funkciót és a kulcspárokat. + + + + + +## További olvasnivaló {#further-reading} + +- [Az Ethereum-számlák megértése](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan + +_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Okosszerződések](/developers/docs/smart-contracts/) +- [Tranzakciók](/developers/docs/transactions/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/blocks/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/blocks/index.md new file mode 100644 index 00000000000..d877e79182f --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/blocks/index.md @@ -0,0 +1,152 @@ +--- +title: Blokkok +description: Egy áttekintő a blokkokról az Ethereum blokkláncban - az adatstruktúrájukról, miért van rájuk szükség és hogyan készülnek. +lang: hu +--- + +A blokkok tranzakciókból álló csoportosítások a láncban lévő előző blokk hash-ével ellátva. Ez összeköti a blokkokat (egy lánccá), mivel a hasheket kriptográfiailag származtatjuk a blokk adatból. Ez megelőzi a csalásokat, mivel bármely blokkon történő változtatás érvénytelenítené az összes következő blokkot, mivel az összes többi hash megváltozna és bárki aki a blokkláncot futtatja észrevenné. + +## Előfeltételek {#prerequisites} + +A blokkok könnyen feldolgozhatók még a legkezdőbb felhasználóknak is. De ennek az oldalnak a jobb megértése érdekében javasoljuk, hogy először olvassa el a [Számlák](/developers/docs/accounts/), a [Tranzakciók](/developers/docs/transactions/) és a [Bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) című cikkeinket. + +## Miért kellenek a blokkok? {#why-blocks} + +Annak biztosítása érdekében, hogy az Ethereum-hálózat minden résztvevője egy szinkronizált állapotot tart fenn és megegyezik a pontos tranzakciós történetben, a tranzakciókat blokkokba rendezzük. Ez azt jelenti, hogy több tucatnyi (vagy több száz) tranzakció felett van elköteleződés, egyetértés és szinkronizáció egyszerre. + +![Diagram, amely egy státuszt módosító blokkban lévő tranzakciót mutat](./tx-block.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból + +Az elkötelezettségek elosztásával elegendő időt adunk az összes hálózati résztvevőnek arra, hogy konszenzusra tudjanak jutni: annak ellenére, hogy a tranzakciós kérelmek másodpercenként több tucatszor fordulnak elő, az Ethereum blokkjai tizenkét másodpercenként köteleződnek el. + +## Hogy működnek a blokkok {#how-blocks-work} + +Hogy megőrizzük a tranzakciós történetet, a blokkoknak szigorú sorrendet kell betartaniuk (minden létrejövő új blokk tartalmaz egy referenciát a szülő blokkjára), és a blokkokban lévő tranzakciók is szigorú sorrendet követnek. Ritka esetek kivételével bármikor amikor a hálózat összes résztvevője egyetért a blokkok pontos számában és előzményeiben, és azon dolgozik, hogy az aktuális élő tranzakciós kérelmeket a következő blokkba csomagolja. + +Amint egy blokkot egy véletlenszerűen választott validátor összeállít által a hálózaton, az továbbterjed a hálózat többi részére; az összes csomópont hozzáfűzi ezt a blokkot a blokkláncukra, majd egy új validátort választanak a következő blokk összeállításához. A pontos blokk-összeállítási folyamatot és az elköteleződés/konszenzus folyamatot jelenleg az Ethereum „proof-of-stake” protokollja specifikálja. + +## Proof-of-stake protokoll {#proof-of-work-protocol} + +A proof-of-stake a következőket jelenti: + +- A validációt végző csomópontoknak letétbe kell helyezniük 32 ETH-t egy letéti szerződésbe fedezetként, hogy elkerülhető legyen a rosszhiszemű viselkedés. Ez segít megvédeni a hálózatot, mert a rosszhiszemű viselkedés következtében a letét egy része vagy egésze megsemmisül. +- Minden slotban (tizenkét másodpercben) a validátort véletlenszerűen választják ki, hogy javasoljon egy blokkot. Tranzakciókat gyűjt össze, végrehajtja azokat és meghatározza a blokklánc új státuszát. Ezt az információt egy blokkba csomagolja és elküldi a többi validátornak. +- A többi validátor megtudja, hogy van egy új blokk, újra végrehajtja a tranzakciókat, hogy azok megegyeznek-e a javasolt új státusszal. Feltéve a blokk érvényes, hozzáteszik a saját adatbázisukhoz. +- Ha egy validátor két ütköző blokkot talál ugyanarra a slotra, akkor az elágazást választó algoritmussal azt választják, amelyet a legtöbb letétbe helyezett ETH támogat. + +[A proof-of-stake-ről bővebben](/developers/docs/consensus-mechanisms/pos) + +## Mi van egy blokkban? {#block-anatomy} + +A blokkban rengeteg információ van. A legmagasabb szinten a következő mezőket tartalmazza: + +| Mező | Leírás | +|:---------------- |:----------------------------------------------------------------------------- | +| `slot` | az a slot, amelyhez a blokk tartozik | +| `proposer_index` | a validátor azonosítója, aki a blokkot javasolta | +| `parent_root` | az előző blokk hash-e | +| `state_root` | a státusz objektum gyökér hash-e | +| `törzs` | egy olyan objektum, amely számos mezőt tartalmaz, ahogy azt alább definiáljuk | + +A blokk `body` számos mezőt tartalmaz: + +| Mező | Leírás | +|:-------------------- |:------------------------------------------------------------------- | +| `randao_reveal` | egy érték, amely a következő blokkjavaslót választja ki | +| `eth1_data` | információ a letéti szerződésről | +| `graffiti` | tetszőleges adat a blokkok taggelésére | +| `proposer_slashings` | a validátorok listája, akiket slashelni kell | +| `attester_slashings` | a tanusítók listája, akiket slashelni kell | +| `tanúsítások` | a tanúsítók listája, akik ezt a blokkot támogatják | +| `behelyezés` | az új letétek listája a letéti szerződésbe | +| `voluntary_exits` | a validátorok listája, akik kilépnek a hálózatból | +| `sync_aggregate` | a validátorok egy csoportja, akik a könnyű klienseket szolgálják ki | +| `execution_payload` | a végrehajtási klienstől jövő tranzakciók | + +A `attestations` (tanúsítások) mező tartalmazza a blokkban lévő az összes tanúsítást. A tanúsítások saját adattípussal rendelkezik, amelyben számos adat megtalálható. A tanúsítások a következőket tartalmazzák: + +| Mező | Leírás | +|:------------------ |:------------------------------------------------------------ | +| `aggregation_bits` | a validátorok listája, akik részt vettek a tanúsításban | +| `adat` | konténer számos almezővel | +| `aláírás` | az összes tanúsítást végző validátor aláírásának aggregátuma | + +A `data` mező a `tanúsítás` részen belül tartalmazza: + +| Mező | Leírás | +|:------------------- |:----------------------------------------------------------------- | +| `slot` | a slot, amelyhez a tanúsítás kapcsolódik | +| `index` | a tanúsítást végző validátorok indexei | +| `beacon_block_root` | a Beacon blokk gyökér hash-e, amely ezt az objektumot tartalmazza | +| `forrás` | az utolsó igazolt ellenőrzési pont | +| `target` | a legutolsó korszak határoló blokkja | + +A tranzakciók végrehajtása az `execution_payload` paraméterben frissíti a globális állapotot. Minden kliens újra végrehajtja a tranzakciókat, amelyek a `execution_payload` paraméterben vannak, hogy biztosítsa, az új állapot egyezik az új blokk `state_root` mezőjében lévőjével. Így tudják a kliensek megmondani, hogy az új blokkot érvényes és biztonságos-e hozzáadni a saját blokkláncukhoz. Az `execution payload` maga egy objektum, amely számos mezővel rendelkezik. Van egy `execution_payload_header` is, ami fontos összegzőinformációkat tartalmaz a végrehajtási adatokról. Ezek az adatstruktúrák a következőképpen vannak rendezve: + +Az `execution_payload_header` a következő mezőket tartalmazza: + +| Mező | Leírás | +|:------------------- |:------------------------------------------------------------------------ | +| `parent_hash` | a jelenlegi blokk elődjének a hash-e | +| `fee_recipient` | a számla címe, amelyre a tranzakciós díjakat fizették | +| `state_root` | a globális állapot gyökér hash-e, miután a változások bementek a blokkba | +| `receipts_root` | a tranzakció fogadói fájának hash-e | +| `logs_bloom` | eseménynaplókat tartalmazó adatstruktúra | +| `prev_randao` | egy érték, amit a véletlenszerű validátor kiválasztásnál használnak | +| `block_number` | a jelenlegi blokk száma | +| `gas_limit` | a jelenlegi blokkban megengedett maximális gáz | +| `gas_used` | a jelenlegi blokkban elhasznált gáz aktuális összege | +| `időbélyeg` | a blokk ideje | +| `extra_data` | tetszőleges hozzáadott adat, mint nyers bájt | +| `base_fee_per_gas` | az alapdíj értéke | +| `block_hash` | a végrehajtó blokk hash-e | +| `transactions_root` | a végrehajtási csomagban lévő tranzakciók gyökér hash-e | +| `withdrawal_root` | a végrehajtási csomagban lévő visszavonások gyökér hash-e | + +Az `execution_payload` maga a következőket tartalmazza (ami azonos a fejléccel, kivéve, hogy a gyökér hash-ek helyett a tranzakciók és visszavonások aktuális listáját tartalmazza): + +| Mező | Leírás | +|:------------------ |:------------------------------------------------------------------------ | +| `parent_hash` | a jelenlegi blokk elődjének a hash-e | +| `fee_recipient` | a számla címe, amelyre a tranzakciós díjakat fizették | +| `state_root` | a globális állapot gyökér hash-e, miután a változások bementek a blokkba | +| `receipts_root` | a tranzakció fogadói fájának hash-e | +| `logs_bloom` | eseménynaplókat tartalmazó adatstruktúra | +| `prev_randao` | egy érték, amit a véletlenszerű validátor kiválasztásnál használnak | +| `block_number` | a jelenlegi blokk száma | +| `gas_limit` | a jelenlegi blokkban megengedett maximális gáz | +| `gas_used` | a jelenlegi blokkban elhasznált gáz aktuális összege | +| `időbélyeg` | a blokk ideje | +| `extra_data` | tetszőleges hozzáadott adat, mint nyers bájt | +| `base_fee_per_gas` | az alapdíj értéke | +| `block_hash` | a végrehajtó blokk hash-e | +| `tranzakciók` | a tranzakciók listája, amit végre kell hajtani | +| `kivételek` | a visszavonásra kerülő objektumok listája | + +A `withdrawals` (visszavonások) listája tartalmazza a `withdrawal` (visszavonási) objektumokat, amelyek a következőképpen vannak strukturálva: + +| Mező | Leírás | +|:---------------- |:---------------------------------- | +| `address` | a visszavonásra került számla címe | +| `amount` | a visszavonás összege | +| `index` | a visszavonás index értéke | +| `validatorIndex` | a validátor index értéke | + +## Blokk idő {#block-time} + +A blokk ideje arra utal, hogy mennyi idő választja el a blokkokat. Az Ethereumban az időt tizenkét másodperces egységekre bontják, amelyet slotnak neveznek. Minden slotban egy validátort választanak, hogy javasoljon blokkot. Feltéve, hogy minden validátor online van és teljesen működőképes, minden slotban lesz egy blokk, tehát a blokk idő 12 másodperc. Azonban a validátorok lehetnek néha offline is, amikor felkérik őket blokkjavaslatra, tehát a slot néha üresen megy. + +Ez különbözik a proof-of-work alapú rendszerektől, ahol a blokk ideje valószínű érték és a protokoll céljának kibányászási nehézsége állítja be. Az Ethereum [átlagos blokkideje](https://etherscan.io/chart/blocktime) egy tökéletes példa erre, ahol az átállás a proof-of-work mechanizmusról a proof-of-stake-re egyértelműen kikövetkeztethető az új 12 másodperces blokkidő konzisztens voltából. + +## Blokkméret {#block-size} + +Utolsó fontos megjegyzés, hogy a blokkok maguk is korlátozott méretűek. Minden blokk 15 millió gáz célmérettel rendelkezik, de a blokk mérete a hálózati kereslet függvényében, egészen a 30 millió gáz határig (ami a célméret kétszerese) változik. A blokk gázkorlátja felfelé vagy lefelé is igazodhat az előző blokk gázkorlátjának 1/1024 faktorával. Így a validátorok megváltoztathatják a blokk gázkorlátját a konszenzus révén. A blokkban lévő tranzakciók által elköltött teljes gáz mennyisége kevesebb kell legyen, mint a blokk gázkorlátozása. Ez fontos, mert ez azt jelenti, hogy a blokkok nem lehetnek tetszőlegesen nagyok. Ha a blokkok tetszőlegesen nagyok lehetnének, akkor a kevésbé teljesítőképes teljes csomópontok egyre kevésbé tudnának lépést tartani a hálózattal a tárhely- és sebességigények miatt. Minél nagyobb a blokk, annál nagyobb számítási erő kell ahhoz, hogy időben fel legyen dolgozva a következő slotra. Ez egy centralizáló erő, amelynek úgy áll ellen, hogy határt szab a méretnek. + +## További olvasnivaló {#further-reading} + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Tranzakciók](/developers/docs/transactions/) +- [Gáz](/developers/docs/gas/) +- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/dapps/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/dapps/index.md new file mode 100644 index 00000000000..adf50977ec0 --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/dapps/index.md @@ -0,0 +1,96 @@ +--- +title: Bevezetés a dappokba +description: +lang: hu +--- + +A decentralizált alkalmazás (dapp) egy olyan applikáció, amely olyan decentralizált hálózatra épült, ami egy [okosszerződést](/developers/docs/smart-contracts/) és egy frontend felhasználói felületet egyesít magában. Megjegyzésül: az Ethereum okosszerződések elérhetőek és transzparensek - mint a nyílt API-ok - így a dappod tartalmazhat olyan okosszerződést, melyet másvalaki írt. + +## Előfeltételek {#prerequisites} + +Mielőtt a dappokról tanulnál érdemes átnézned a [blokklánc alapok](/developers/docs/intro-to-ethereum/) oldalt, valamint eolvasnod az Ethereum hálózatról szóló oldalt, és azt, hogy mitől lesz decentralizált. + +## A dapp meghatározása {#definition-of-a-dapp} + +A dapp egy olyan backend kód, mely egy decentralizált peer-to-peer hálózaton fut. Ezzel szemben egy app esetében a backend kód centralizált szervereken fut. + +Egy dappnak bármely nyelven íródott frontend kódja vagy felhasználói felülete lehet (akárcsak az appoknak), mely hívásokat indíthat a backend felé. Továbbá a frontendje olyan decentralizált tárhelyeken lehet, mint az [IPFS](https://ipfs.io/). + +- **Decentralizált** – a dapp-ok az Ethereumon működnek, azaz egy nyitott, nyilvános, decentralizált platformon, ahol egyetlen személy vagy csoportnak sem irányít +- **Determinisztikusak** vagyis ugyanazt a függvényt hajtják végre a végrehajtási környezettől függetlenül. +- **Turing-teljes** – a dappok képesek végrehajtani bármilyen akciót, ha a megfelelő erőforrások rendelkezésre állnak +- **Izolált** – a dappok egy virtuális környezetben, az Ethereum Virtuális Gépen futnak, így ha az okosszerződésben hiba van, az nem érinti a blokklánchálózat normál működését + +### Az okosszerződésekről {#on-smart-contracts} + +Hogy bevezessük a dappokat, először be kell vezetnünk az okosszerződéseket – a dapp backendjét jobb kifejezés híján. A részletes áttekintéshez keresse fel az [okosszerződések](/developers/docs/smart-contracts/) oldalt. + +Az okosszerződés olyan kód, mely az Ethereum blokkláncon fut és pontosan úgy, ahogyan programozták. Amint az okosszerződések feltelepültek a hálózatra, azok többé nem módosíthatók. A dappok decentralizáltak lehetnek, mivel a szerződésbe írt logika irányítja őket, nem pedig egy egyén vagy egy vállalat. Ez azt is jelenti, hogy nagyon óvatosan kell megtervezned a szerződéseidet és alaposan le kell tesztelned őket. + +## A dapp fejlesztés előnyei {#benefits-of-dapp-development} + +- **Nulla állásidő** – amint az alkalmazás alapjául szolgáló okosszerződés telepítésre kerül a blokkláncon, a hálózat állandóan készen áll kiszolgálni a szerződéssel interakcióba lépő klienseket. Rosszindulatú szereplők emiatt nem tudnak szolgáltatásmegtagadási támadásokat indítani az egyes dappok ellen. +- **Adatvédelem** – nem kell igazolnod a valódi személyazonosságodat, hogy interakcióba lépj egy dappal. +- **Cenzúra rezisztancia** – nincs olyan egyedüli entitás a hálózaton, mely megakadályozhatná a felhasználókat abban, hogy tranzakciókat indítsanak, dappokat telepítsenek vagy adatot olvassanak a blokkláncról. +- **Teljes adat integritás** – a blokkláncon tárolt adatot nem megváltoztatható és nem megkérdőjelezhető a kriptográfiai primitíveknek köszönhetően. Rosszindulatú szereplők nem tudnak tranzakciókat vagy egyéb más adatot hamaisítni, amelyet publikáltak. +- **Bizalommentes számítás/hitelesíthető viselkedés** – az okosszerződéseket lehet elemezni és garantált, hogy megjósolható módon fognak végbe menni anélkül, hogy meg kellene bízni egy központi hatóságban. Ez nem igaz a hagyományos modellek esetében; ha például online bankolást használunk, meg kell bíznunk a pénzintézetekben, hogy nem fognak visszaélni a pénzügyi adatainkkal, megmásítani a feljegyzéseket vagy hacker támadást elszenvedni. + +## A dapp-fejlesztés hátrányai {#drawbacks-of-dapp-development} + +- **Karbantartás** – a dappokat nehezebb karbantartani, mivel a blokkláncra publikált kódot és az adatot nehezebb módosítani. A fejlesztők számára nehézkes frissíteni a dappjukat (vagy a dapp által tárolt mögöttes adatot), amint felkerültek a blokkláncra – még akkor is ha hibákat vagy biztonsági kockázatokat fedeztek fel a régi verzióban. +- **Végrehajtási költség** – magas a végrehajtási költség, a skálázás pedig nagyon nehéz. Ahhoz, hogy azt a biztonsági, integritási, átláthatósági és megbízhatósági szintet elérjük, melyre az Ethereum törekszik, minden egyes csomópont lefuttatja és eltárolja az összes tranzakciót. Ezen felül a proof-of-work konszenzus is időbe telik. +- **Hálózati torlódás** – ha egy dapp túl sok számítási kapacitást használ fel, akkor a teljes hálózat feltorlódik. Jelenleg a hálózat körülbelül 10 tranzakciót tud feldolgozni egy másodperc alatt; ha ennél gyorsabban küldenek be tranzakciókat, akkor a feldolgozatlan tranzakciók száma gyorsan felfújódhat. +- **Felhasználói élmény** – nehezebb felhasználóbarát élményeket adni, mivel az átlagos felhasználók túl nehéznek találhatják az eszközkészlet felállítását ahhoz, hogy a blokklánccal valóban biztonságos módon interakcióba léphessenek. +- **Centralizálás** – előfordulhat, hogy a felhasználó- és fejlesztőbarát megoldások, amelyek az Ethereum alaprétegére épülnek, végül centralizált szolgáltatásként fognak működni. Például az ilyen szolgáltatások kulcsokat vagy más bizalmas információkat tárolnak a szerveroldalon, centralizált szervert használnak a frontend kiszolgálására, vagy fontos üzleti logikákat futtatnak egy centralizált szerveren, mielőtt a blokkláncra írnának. Ez kizárja rengeteg (ha nem az összes) előnyét a blokkláncnak a hagyományos modellel szemben. + +## Ön inkább vizuális típus? {#visual-learner} + + + +## Eszközök a dappok létrehozásához {#dapp-tools} + +**Scaffold-ETH _– Próbálja ki a Solidity megoldást olyan frontenddel, amely illeszkedik az Ön okosszerződéséhez._** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) +- [Példa egy dappra](https://punkwallet.io/) + +**Create Eth App _– Hozzon létre Ethereum-alapú alkalmazásokat egy paranccsal._** + +- [GitHub](https://github.com/paulrberg/create-eth-app) + +**One Click Dapp _- FOSS-eszköz dapp-frontendek készítéshez egy [ABI-ból](/glossary/#abi)._** + +- [oneclickdapp.com](https://oneclickdapp.com) +- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) + +**Etherflow _– FOSS-eszköz az Ethereum fejlesztők számára, amellyel tesztelheti csomópontjukat, illetve RPC-hívásokat állíthatnak össze és debuggolhatnak a böngészőből._** + +- [etherflow.quiknode.io](https://etherflow.quiknode.io/) +- [GitHub](https://github.com/abunsen/etherflow) + +**thirdweb _– SDK-k minden nyelven, okosszerződések, eszközök és infrastruktúra a web3 fejlesztéshez._** + +- [Honlap](https://thirdweb.com/) +- [Dokumentáció](https://portal.thirdweb.com/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Crossmint _– Vállalati szintű web3 fejlesztési platform okosszerződések telepítéséhez, hitelkártyás és láncok közötti fizetések lehetővé tételéhez, valamint API-ok használatára NFT-k létrehozása, terjesztése, értékesítése, tárolása és szerkesztése érdekében._** + +- [crossmint.com](https://www.crossmint.com) +- [Dokumentáció](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +## További olvasnivaló {#further-reading} + +- [Fedezze fel a dappokat](/dapps) +- [A web 3.0 alkalmazások architektúrája](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ +- [Egy 2021-es útmutató a decentralizált alkalmazásokról](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) – _LimeChain_ +- [Mik azok decentralizált alkalmazások?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) – _Gemini_ +- [Népszerű dapp-ok](https://www.alchemy.com/dapps) - _Alchemy_ + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Bevezetés az Ethereum stack-be](/developers/docs/ethereum-stack/) +- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/index.md new file mode 100644 index 00000000000..f50543ecffd --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/index.md @@ -0,0 +1,78 @@ +--- +title: Ethereum virtuális gép (EVM) +description: Bevezetés az Ethereum virtuális gépbe és arról, hogy hogyan kapcsolódik az állapothoz, tranzakciókhoz és okosszerződésekhez. +lang: hu +--- + +Az Ethereum Virtual Machine (EVM) egy decentralizált virtuális környezet, amely következetesen és biztonságosan hajtja végre a kódot az Ethereum összes csomópontján. A csomópontok az EVM-et futtatják az intelligens szerződések végrehajtására, a „[gáz](/gas/)” használatával mérik a [műveletekhez](/developers/docs/evm/opcodes/) szükséges számítási erőfeszítést, biztosítva az erőforrások hatékony elosztását és a hálózat biztonságát. + +## Előfeltételek {#prerequisites} + +Alapvető számítástudományi fogalmak ismerete, mint például a [bájtok](https://wikipedia.org/wiki/Byte), [memória](https://wikipedia.org/wiki/Computer_memory), és a [stack](https://wikipedia.org/wiki/Stack_(abstract_data_type)) szükségesek ahhoz, hogy megértse az EVM-et. Érdemes tisztában lenni egy pár kriptográfiai/blokklánc fogalommal úgy, mint a [hash függvények](https://wikipedia.org/wiki/Cryptographic_hash_function) és a [Merkle-fa](https://wikipedia.org/wiki/Merkle_tree). + +## Főkönyvtől az állapot gépig {#from-ledger-to-state-machine} + +Az 'elosztott főkönyv' analógiáját gyakran használjuk olyan blokkláncok jellemzésére, mint a Bitcoin, mely lehetővé egy decentralizált valuta létrehozását alapvető kriptográfiai eszközök használatával. A főkönyv tartalmazza a történések rekordjait, amelynek meg kell felelnie bizonyos szabályoknak, ami azt irányítja, hogy mit tehet meg és mit nem tehet meg valaki a főkönyv módosításához. Például egy Bitcoin cím nem költhet el több bitcoint, mint amennyit előzőleg megkapott. Ezek a szabályok támasztják alá az összes Bitcoin tranzakciót és sok más blokkláncot is. + +Míg az Ethereumnak megvan a saját natív kriptovalutája (Ether), amely ugyanazokat az intuitív szabályokat követi, emellett lehetőséget ad egy másik hathatós funkciónak is: [az okosszerződéseknek](/developers/docs/smart-contracts/). Ehhez a bonyolultabb funkcióhoz egy szofisztikáltabb analógia szükségeltetik. Egy elosztott főkönyv helyett az Ethereum egy elosztott [állapot gép](https://wikipedia.org/wiki/Finite-state_machine). Az Ethereum állapota egy nagy adatstruktúra, mely nem csak a számlákat és az egyenlegeket tárolja, de egy _állapot gépet_ is, mely blokkról blokkra változhat egy előre meghatározott szabályrendszer szerint és tetszőleges gépi kódot tud végrehajtani. Az állatot blokkról blokkra történő megváltozásának specifikus szabályait az EVM rögzíti. + +![Egy diagram mely az EVM felépítését mutatja be](./evm.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból + +## Az Ethereum állapot átmeneti függvény {#the-ethereum-state-transition-function} + +Az EVM úgy viselkedik, mint egy matematikai függvény: Adott egy bemenet, mely egy determinisztikus kimenetet generál. Ezért nagyon hasznos, ha az Ethereumot formálisabban úgy írjuk le, mint egy **állapot átmeneti függvényt**: + +``` +Y(S, T)= S' +``` + +Adott egy régebbi érvényes állapot `(S)` és egy új érvényes tranzakciókból álló halmaz `(T)`, az Ethereum állapot átmeneti függvény `Y(S, T)` létrehoz egy új érvényes kimeneti állapotot `S'` + +### Állapot {#state} + +Az Ethereum kontextusában az állapot egy hatalmas adatstruktúra, amelyet úgy hívnak, hogy [módosított Merkle Patricia-fa](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), amely az összes [számlát](/developers/docs/accounts/) hashekkel köti össze és redukálja egy gyökér hash-é, amelyet a blokklánc tárol. + +### Tranzakciók {#transactions} + +A tranzakciók számlákból származó kriptográfiailag aláírt instrukciók. A tranzakcióknak két típusa van: azok, amelyek üzenet hívásokat eredményeznek és azok melyek szerződés létrehozásokat. + +A szerződés létrehozás egy új szerződéses számla létrehozásával jár, mely a fordított [okosszerződés](/developers/docs/smart-contracts/anatomy/) bájtkódot tartalmazza. Amikor egy másik számla egy üzenet hívást intéz ehhez a szerződéshez, végrehajtja a bájtkódját. + +## EVM Utasítások {#evm-instructions} + +Az EVM egy [veremgépként](https://wikipedia.org/wiki/Stack_machine) fut 1024 elemes mélységgel. Mindegyik tétel egy 256 bites szó, amelyet a 256 bitet kriptográfia használata miatt választottak (mint amilyen a Keccak-256 hash-e vagy secp256k1 aláírások). + +A végrehajtás alatt az EVM egy tranziens _memóriát_ tart fenn (mint egy szócímzett bájttömböt), amely nem folytatólagos a tranzakciók között. + +A szerződések azonban tartalmaznak egy Merkle Patricia _tároló_ fát (mint egy szócímezhető szótömböt), amely hozzá van rendelve a kérdéses számlához és része a globális státusznak. + +A befordított okosszerződés bájtkódja EVM-[opcode-ként](/developers/docs/evm/opcodes) fut le, amely standard stack művelet, mint a `XOR`, `AND`, `ADD`, `SUB` stb. Az EVM egy pár blokklánc-specifikus stack-műveletet is implementál, mint az `ADDRESS`, `BALANCE`, `BLOCKHASH` stb. + +![Egy diagram, amely azt mutatja, hogy hol van szükség gázra az EVM-műveleteknél](../gas/gas.png) _Diagramok átvéve az [Illusztrált Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból + +## EVM Implementációk {#evm-implementations} + +Az összes EVM-implementációnak meg kell felelnie az Ethereum sárgakönyvben megfogalmazott specifikációnak. + +Az Ethereum kilenc éves története alatt az EVM több revízión átesett és számos EVM-implementáció létezik különböző programozási nyelveken. + +Az [Ethereum végrehajtási kliensek](/developers/docs/nodes-and-clients/#execution-clients) tartalmaznak egy EVM-implementációt. Továbbá több önálló implementáció létezik, ilyen például: + +- [Py-EVM](https://github.com/ethereum/py-evm) - _Python_ +- [evmone](https://github.com/ethereum/evmone) - _C++_ +- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ +- [revm](https://github.com/bluealloy/revm) - _Rust_ + +## További olvasnivaló {#further-reading} + +- [Ethereum sárga könyv](https://ethereum.github.io/yellowpaper/paper.pdf) +- [Jello könyv, vagyis a KEVM: az EVM szemantikái K-ban](https://jellopaper.org/) +- [The Beigepaper](https://github.com/chronaeon/beigepaper) +- [Ethereum Virtuális Gép Opcode-ok](https://www.ethervm.io/) +- [Ethereum Virtuális Gép operációskódjainak interaktív referenciája](https://www.evm.codes/) +- [Rövid bevezetés a Solidity dokumentációjába](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) +- [Az Ethereum elsajátítása - az Ethereum virtuális gép](https://github.com/ethereumbook/ethereumbook/blob/develop/13evm.asciidoc) + +## Kapcsolódó témák {#related-topics} + +- [Gáz](/developers/docs/gas/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/opcodes/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/opcodes/index.md new file mode 100644 index 00000000000..d5f93cfe26a --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/opcodes/index.md @@ -0,0 +1,174 @@ +--- +title: Az EVM operációs kódjai +description: Az Ethereum Virtuális Gép összes elérhető operációs kódja. +lang: hu +--- + +## Áttekintés {#overview} + +Ez az EVM referenciaoldalának [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes) frissített változata. A [Sárga könyvből](https://ethereum.github.io/yellowpaper/paper.pdf), a [Jello könyvből](https://jellopaper.org/evm/) és a [geth](https://github.com/ethereum/go-ethereum) implementációból származik. Ez egy mindenki számára elérhető referencia, de nem feltétlen szigorú. Ha biztosra szeretne menni, akkor használja a Jello könyvet vagy egy kliens implementációját. + +Interaktív referenciát keres? Tekintse meg az [evm.codes](https://www.evm.codes/) oldalt. + +A dinamikus gázköltséggel működő műveletekhez nézze meg a következőt: [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md). + +Tipp: a teljes sorokhoz használja a `[shift] + scroll` funkciót, hogy vízszintesen tudjon mozogni. + +| Stack | Név | Gáz | Kezdő stack | Eredmény stack | Memória / Tárhely | Megjegyzések | +|:-----:|:-------------- |:---------------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 00 | STOP | 0 | | | | halt execution | +| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 | +| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 | +| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 | +| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division | +| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division | +| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus | +| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus | +| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N | +| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N | +| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 | +| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes | +| 0C-0F | _invalid_ | | | | | | +| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than | +| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than | +| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than | +| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than | +| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality | +| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero | +| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND | +| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR | +| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR | +| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT | +| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left | +| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left | +| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right | +| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right | +| 1E-1F | _invalid_ | | | | | | +| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | +| 21-2F | _invalid_ | | | | | | +| 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract | +| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei | +| 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx | +| 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender | +| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei | +| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` | +| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes | +| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data | +| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes | +| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode | +| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | +| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes | +| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` | +| 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes | +| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call | +| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 | +| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | +| 41 | COINBASE | 2 | `.` | `block.coinbase` | | a jelenlegi blokk előterjesztőjének címe | +| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block | +| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block | +| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon | +| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block | +| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack | +| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei | +| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block | +| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | +| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | a jelenlegi blokk blob alapdíjja ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | +| 4B-4F | _invalid_ | | | | | | +| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it | +| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` | +| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory | +| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | write a single byte to memory | +| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage | +| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | write word to storage | +| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest | +| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` | +| 58 | PC | 2 | `.` | `$pc` | | program counter | +| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes | +| 5A | GAS | 2 | `.` | `gasRemaining` | | | +| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data | +| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | kiolvasás az átmeneti tárhelyről ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | +| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | írás az átmeneti tárhelyre ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | +| 5E | MCOPY | 3+3\* szavak + [A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | memóriamásolás egyik helyről a másikra ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | +| 5F | PUSH0 | 2 | `.` | `uint8` | | az állandó 0 érték áttolása a stackre | +| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack | +| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack | +| 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack | +| 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack | +| 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack | +| 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack | +| 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack | +| 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack | +| 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack | +| 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack | +| 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack | +| 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack | +| 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack | +| 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack | +| 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack | +| 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack | +| 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack | +| 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack | +| 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack | +| 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack | +| 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack | +| 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack | +| 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack | +| 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack | +| 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack | +| 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack | +| 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack | +| 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack | +| 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack | +| 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack | +| 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack | +| 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack | +| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack | +| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack | +| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack | +| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack | +| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack | +| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack | +| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack | +| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack | +| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack | +| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack | +| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack | +| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack | +| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack | +| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack | +| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack | +| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack | +| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | +| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | +| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | +| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | +| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | +| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | +| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | +| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | +| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | +| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | +| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | +| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | +| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | +| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | +| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | +| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | +| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | +| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | +| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | +| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | +| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | +| A5-EF | _invalid_ | | | | | | +| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | +| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | +| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value | +| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] | +| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | +| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | +| F6-F9 | _invalid_ | | | | | | +| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | +| FB-FC | _invalid_ | | | | | | +| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | +| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | +| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | elküldi az összes ETH-t az `addr` címre; ha ugyanabban a tranzakcióban hajtják végre, mint a szerződés létrejött, az megsemmisíti a szerződést | diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/gas/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/gas/index.md new file mode 100644 index 00000000000..7d839ae7b4b --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/gas/index.md @@ -0,0 +1,140 @@ +--- +title: Gáz és tranzakciós díjak +description: +lang: hu +--- + +Az gáz nélkülözhetetlen az Ethereum hálózaton. Ez az üzemanyag, amitől működik, ahogyan az autóknak is szükségük van benzinre, hogy menjenek. + +## Előfeltételek {#prerequisites} + +Hogy jobban megértse ezt az oldalt, javasoljuk, hogy olvassa el a [tranzakciókról](/developers/docs/transactions/) és az [EVM-ről](/developers/docs/evm/) szóló oldalakat. + +## Mi az a gáz? {#what-is-gas} + +A gáz a számítási erőfeszítés mértékegységét jelenti, mely bizonyos műveletek végrehajtásához szükséges az Ethereum hálózaton. + +Mivel az Ethereum-tranzakciók számítási kapacitást igényelnek a végrehajtáshoz, ezeket ki kell fizetni, hogy a hálózat ne legyen sebezhető a szemeteléssel vagy a végtelen ciklusokat indító logikákkal szemben. A számításokért gázdíj formájában kell fizetni. + +A gázdíj **a művelet végrehajtásához szükséges gáz mennyisége, szorozva a gázegység költségével**. A díjat a tranzakció sikerességétől függetlenül is ki kell fizetni. + +![Egy diagram, amely azt mutatja, hogy hol van szükség gázra az EVM-műveleteknél](./gas.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból + +A gázdíjakat az Ethereum saját valutájában, etherben (ETH) kell kifizetni. A gázdíjakat általában gwei-ben adják meg, ami az ETH címlete. Egy gwei az ETH egymilliárdnyi részével (0,000000001 ETH vagy 10-9 ETH) egyenlő. + +Például ahelyett, hogy azt mondanánk, hogy a gáz 0,000000001 ether-be kerül, azt mondjuk, hogy a gáz ára 1 gwei. + +A gwei a giga-wei-ből ered, ami milliárd weit jelent. Egy gwei az egy milliárd wei. A wei (amit [Wei Dai](https://wikipedia.org/wiki/Wei_Dai) után neveztek el, aki a [b-pénz feltalálója](https://www.investopedia.com/terms/b/bmoney.asp)) az ETH legkisebb egysége. + +## Hogyan kerül kiszámításra a gázdíj? {#how-are-gas-fees-calculated} + +Amikor a felhasználó egy tranzakciót indít, akkor ki tudja választani, hogy mennyi gázdíjat hajlandó fizetni a végrehajtásért. Bizonyos gázmennyiség felajánlásával ajánlatot tesz, hogy az adott tranzakció bekerüljön a következő blokkba. Ha túl kicsi az összeg, akkor a validátorok kisebb valószínűséggel kapják fel a tranzakciót, így az később vagy esetleg egyáltalán nem kerül feldolgozásra. Ha túl sokat ajánl valaki, akkor talán elveszíti az ETH-összeg egy részét. Hogyan érdemes meghatározni a fizetendő díjat? + +A teljes gázdíj két komponensből áll: az `alapdíj` és az `elsőbbségi díj` (borravaló). + +Az `alapdíjat` a protokoll állapítja meg – ahhoz, hogy a tranzakció érvényes legyen, legalább ennyit ki kell érte fizetni. Az `elsőbbségi díj` egy borravaló az alapdíjon felül, amely miatt a tranzakció vonzóvá válhat a validátorok szemében, ezért felveszik azt a következő blokkba. + +Az a tranzakció, amely csak az `alapdíjat` fizeti meg, technikailag érvényes, de kevéssé valószínű, hogy bekerül, mert nem jelent motivációt a validátoroknak, hogy egy másik tranzakció helyett ezt válasszák. A „megfelelő” `elsőbbségi díjat` a hálózat használata határozza meg abban az időpontban, amikor a felhasználó a tranzakciót elküldi – ha nagy a kereslet, akkor magasabb `elsőbbségi díjat` kell fizetni, kisebb keresletnél pedig kevesebb is elég lehet. + +Például Jordannek ki kell fizetnie 1 ETH-t Taylornak. Az ETH transzferhez 21 000 egységnyi gázra van szükség, az alapdíj pedig 10 gwei. Jordan 2 gwei borravalót ad hozzá. + +A teljes díj így néz ki: + +`a felhasznált gáz mennyisége * (alapdíj + elsőbbségi díj)` + +ahol az `alapdíjat` a protokoll határozza meg, az `elsőbbségi díjat` pedig a felhasználó adja, hogy a validátort díjazza. + +pl. `21 000 * (10 + 2) = 252 000 gwei` (0,000252 ETH). + +Amikor Jordan elküldi a pénzt, akkor a számlájáról 1,000252 ETH-t fognak levonni. Taylornak pedig jóváírnak 1,0000 ETH-t. A validátor megkapja 0,000042 ETH borravalót. A 0,00021 ETH `alapdíjat` elégetik. + +### Alapdíj {#base-fee} + +Minden blokk rendelkezik alapdíjjal, ami egyfajta foglalási díjként működik. A blokkba csak úgy lehet bekerülni, hogy a gázért felajánlott ár eléri az alapdíjat. Az alapdíj az aktuális blokktól függetlenül kerül kiszámításra, inkább az előző blokk határozza meg, hogy a tranzakciós illeték kiszámíthatóbb legyen a felhasználók számára. Amikor a blokk létrejön, akkor ez az **alapdíj „elég”**, vagyis kivonják a körforgásból. + +Az alapdíj egy olyan képlettel kerül kiszámításra, amely összeveti az előző blokk méretét (a benne lévő tranzakciók által felhasznált gáz mennyisége) a célmérettel. Ha a blokk meghaladja a célméretet, akkor az alapdíj legfeljebb 12,5%-kal emelkedik blokkonként. Ez az exponenciális növekedés gazdasági szempontból eléri, hogy a blokkméret ne maradhasson ilyen nagy a végtelenségig. + +| Blokkszám | Benne lévő gáz | Díjnövekedés | Jelenlegi alapdíj | +| --------- | --------------:| ------------:| -----------------:| +| 1 | 15M | 0% | 100 gwei | +| 2 | 30M | 0% | 100 gwei | +| 3 | 30M | 12,5% | 112,5 gwei | +| 4 | 30M | 12,5% | 126,6 gwei | +| 5 | 30M | 12,5% | 142,4 gwei | +| 6 | 30M | 12,5% | 160,2 gwei | +| 7 | 30M | 12,5% | 180,2 gwei | +| 8 | 30M | 12,5% | 202,7 gwei | + +A táblázatot folytatva a 9. blokkba kerülő tranzakcióra a tárca megadja a felhasználónak, hogy a **maximális alapdíj**, amivel bekerülhet a következő blokkba, az `a jelenlegi alapdíj * 112,5%` vagy `202,7 gwei * 112,5% = 228,1 gwei`. + +Fontos megjegyezni, hogy nem valószínű, hogy egymás után sok teljes blokk készül, mert az alapdíj gyorsan növekszik a teljes blokk előtt. + +| Blokkszám | Benne lévő gáz | Díjnövekedés | Jelenlegi alapdíj | +| --------- | --------------:| ------------:| -----------------:| +| 30 | 30M | 12,5% | 2705,6 gwei | +| ... | ... | 12,5% | ... | +| 50 | 30M | 12,5% | 28 531,3 gwei | +| ... | ... | 12,5% | ... | +| 100 | 30M | 12,5% | 10 302 608,6 gwei | + +### Elsőbbségi díj (borravaló) {#priority-fee} + +Az elsőbbségi díj (borravaló) motiválja a validátorokat, hogy bevegyék a tranzakciót a blokkba. A borravaló nélkül a validátoroknak gazdaságilag ugyanolyan értékű, ha üresen marad a blokk, mint ha felvesznek bele tranzakciókat, mert a blokkért megkapják a díjazásukat. A kis értékű borravaló egy minimális ösztönzést ad a validátoroknak, hogy felvegyenek egy tranzakciót. Azokért a tételekért, amelyeket ugyanabban a blokkban, de a többi tétel előtt szeretnénk végrehajtatni, magasabb borravalót érdemes fizetni, hogy lekörözze a többi tranzakció ajánlatát. + +### Maximális díj {#maxfee} + +Ahhoz, hogy a hálózaton végre legyen hajtva egy tranzakció, a felhasználók meghatározhatnak egy maximális határt, amit még hajlandók kifizetni érte. Ennek az opcionális paraméternek a neve `maxFeePerGas`. A tranzakció végrehajtásához a maximális díjnak meg kell haladnia az alapdíj és a borravaló összegét. A tranzakció küldője visszakapja azt a különbözetet, ami a maximális díj, valamint az alapdíj és a borravaló összege között van. + +### Blokkméret {#block-size} + +Minden blokk 15 millió gáz célmérettel rendelkezik, de a blokk mérete a hálózati kereslet függvényében, egészen a 30 millió gáz határig (amely a célméret kétszerese) változik. A protokoll úgy éri el az egyensúlyi, átlagos 15 milliós blokkméretet, hogy a _tâtonnement_, vagyis a közelítés módszerét alkalmazza. Tehát, ha a blokkméret meghaladja a célértéket, akkor a protokoll megnöveli az alapdíjat a következő blokknál. Ugyanígy csökkenti az alapdíjat, ha a blokkméret kisebb, mint a célérték. Az alapdíj mértéke arányosan változik annak függvényében, hogy a jelenlegi blokkméret hogyan viszonyul a célmérethez. [Bővebben a blokkokról](/developers/docs/blocks/). + +### A gázdíjak kiszámítása a gyakorlatban {#calculating-fees-in-practice} + +A felhasználó egyértelműen kijelentheti, hogy mennyit hajlandó fizetni azért, hogy a tranzakciót végrehajtsák. Emellett a legtöbb tárcaszolgáltató automatikusan beállít egy javasolt tranzakciós illetéket (alapdíj + a javasolt elsőbbségi díj), hogy csökkentse a használat komplexitását. + +## Miért léteznek a gázdíjak? {#why-do-gas-fees-exist} + +Röviden, a gázdíjak tartják fenn a Ethereum hálózat biztonságát. Azzal, hogy a hálózaton végrehajtott minden számítás egy díjat von maga után, megelőzzük, hogy rosszhiszemű személyek túlterheljék a hálózatot. Azért, hogy megelőzzük a véletlen vagy ártó szándékú végtelen ciklusokat vagy más számítási pazarlással járó kódot, minden egyes tranzakciónak be kell állítani egy határt, hogy mennyi számítási lépést hajthat végre a kód futtatása. A számítás alapmértékegysége a „gáz”. + +Habár a tranzakció tartalmaz egy határt, a fel nem használt gázdíj visszakerül a felhasználóhoz. Például a `maximális díj – (alapdíj + borravaló)` visszatérítésre kerül. + +![Egy diagram, amely a fel nem használt gáz visszatérítését ábrázolja](../transactions/gas-tx.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból + +## Mit jelent a gázkorlátozás? {#what-is-gas-limit} + +A gázkorlátozás arra utal, hogy egy tranzakció során legfeljebb mennyi gázra lesz szükség. A bonyolultabb tranzakciók, mint az [okosszerződések](/developers/docs/smart-contracts/), több számítási kapacitást igényelnek, ezért magasabb gázkorlátozásra van szükségük, mint egy egyszerű átutalásnál. Egy általános ETH-transzfer 21 000 egységi gázkorlátozást igényel. + +Például, ha egy egyszerű ETH transzferre azt állítjuk be, hogy a gázkorlátozás 50 000 legyen, az EVM felhasznál 21 000-et, a felhasználó pedig visszakapja a maradék 29 000-et. Ha viszont túl kevés gázt határozunk meg, például a gázkorlátozás 20 000 lesz egy egyszerű ETH transzferhez, akkor az EVM elfogyasztja a 20 000 egységet, és megpróbálja végrehajtani a tranzakciót, de nem tudja azt teljesíteni. Ekkor az EVM visszaforgatja a változtatásokat, de mivel a validátor már elvégzett 20 000 gáz mennyiségű munkát, ezért ez el lett fogyasztva. + +## Miért lehetnek olyan magasak a gázdíjak? {#why-can-gas-fees-get-so-high} + +A magas gázdíjak oka az Ethereum népszerűsége. Amikor nagy a kereslet, akkor a felhasználóknak magasabb borravalót kell ajánlaniuk, hogy lekörözzék a többi tranzakciót. A magasabb borravaló miatt az adott tranzakció valószínűleg bekerül a következő blokkba. Emellett a sokkal összetettebb okosszerződéses alkalmazások sok műveletet végezhetnek funkcióik támogatása érdekében, amivel sok gázt fogyasztanak el. + +## Kezdeményezések a gázköltségek csökkentésére {#initiatives-to-reduce-gas-costs} + +Az Ethereum [skálázhatósági fejlesztései](/roadmap/) meg fogják oldani a gázdíjak körüli problémák egy részét, így lehetővé teszik, hogy a platform ezernyi tranzakciót dolgozzon fel másodpercenként és globálisan skálázható legyen. + +A második blokkláncréteggel (L2) kialakított skálázás a fő kezdeményezés arra, hogy nagy mértékben javuljanak a gázköltségek, a felhasználói élmény és a skálázhatóság. [Bővebben az L2 skálázásról](/developers/docs/scaling/#layer-2-scaling). + +## A gázdíjak felügyelete {#monitoring-gas-fees} + +Ha Ön szeretné felügyelni a gázdíjakat azért, hogy kevesebbet kelljen fizetnie az ETH-tranzakciókért, akkor számos eszköz áll rendelkezésre: + +- [Etherscan](https://etherscan.io/gastracker) _ Tranzakció gázdíjának becslése_ +- [ETH Gas Tracker](https://www.ethgastracker.com/) _Figyeli és kövesti az Ethereum és az L2 gázárakat a tranzakciós díjak csökkentése és a pénzmegtakarítás érdekében_ +- [Blocknative ETH gázbecslés](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Gázbecslő Chrome-kiterjesztés, amely támogatja az eredeti (0. típusú) és az EIP-1559 (2. típusú) tranzakciókat._ +- [Cryptoneur gázdíjkalkulátor](https://www.cryptoneur.xyz/gas-fees-calculator) _Számolja ki a gázdíjat a saját pénznemében a különféle tranzakciókra az Ethereum főhálózatán, az Arbitrumon és a Polygonon._ + +## Kapcsolódó eszközök {#related-tools} + +- [Blocknative gázplatform](https://www.blocknative.com/gas) _Gázbecslő API, amelyet a Blocknative globális memóriakészlet adatplatformja támogat_ + +## További olvasnivaló {#further-reading} + +- [Az Ethereum gázdíjról részletesen](https://defiprime.com/gas) +- [Csökkentse az okosszerződésének gázfogyasztását](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) +- [A proof-of-stake és a proof-of-work összehasonlítása](https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/) +- [Gázoptimalizáló stratégiák fejlesztők számára](https://www.alchemy.com/overviews/solidity-gas-optimization) +- [EIP-1559-dokumentumok](https://eips.ethereum.org/EIPS/eip-1559). +- [Tim Beiko EIP-1559 forrásai](https://hackmd.io/@timbeiko/1559-resources). diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/index.md new file mode 100644 index 00000000000..5b5b808dd9e --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/index.md @@ -0,0 +1,25 @@ +--- +title: Ethereum-fejlesztési dokumentáció +description: Bevezetés az ethereum.org fejlesztői dokumentációjába. +lang: hu +--- + +Ezt a dokumentációt arra tervezték, hogy segítsen az Ethereumon való fejlesztésben. Bemutatja az Ethereumot, mint koncepciót, elmagyarázza az Ethereum tech stacket, és áttekintést nyújt a haladó témákról és a komplexebb alkalmazásokról használati esetek segítségével. + +Ez egy nyílt forráskódú közösségi kezdeményezés, így nyugodtan javasolhat új témákat, hozzáadhat új tartalmat és példákat adhat meg, ahol úgy érzi, hogy hasznos lehet. Az összes dokumentáció szerkeszthető a GitHub-on – csak [kövesse az instrukciókat](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md). + +## Fejlesztési modulok {#development-modules} + +Ha most először fejleszt az Ethereumon, akkor azt javasoljuk, hogy kezdje a legelején, és olvassa végig, mint egy könyvet. + +### Alapvető témák {#foundational-topics} + + + +### Ethereum stack {#ethereum-stack} + + + +### Speciális {#advanced} + + diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ether/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ether/index.md new file mode 100644 index 00000000000..12b283273ac --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ether/index.md @@ -0,0 +1,78 @@ +--- +title: Bevezetés az ether világába +description: Bevezetés fejlesztőknek az ether kriptovalutába. +lang: hu +--- + +## Előfeltételek {#prerequisites} + +Ennek az oldalnak a jobb megértése érdekében javasoljuk, hogy először olvassa el a [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) oldalunkat. + +## Mi az a kriptovaluta? {#what-is-a-cryptocurrency} + +A kriptovaluta a csere eszköze, amelyet egy blokkláncalapú főkönyv biztosít. + +A csere eszköze bármi lehet, amit széles körben elfogadnak az áruk és szolgáltatások kifizetésére, a főkönyv pedig egy adattároló, ahol a tranzakciókat követik. A blokklánc-technológia lehetővé teszi a felhasználóknak, hogy tranzakciókat végezzenek a főkönyvön, anélkül hogy egy harmadik félben kellene megbízniuk, aki a főkönyvet kezeli. + +Az első kriptovaluta a Bitcoin volt, amelyet Satoshi Nakamoto hozott létre. A Bitcoin 2009-es elindulása óta az emberek ezernyi kriptovalutát hoztak létre számos különféle blokkláncon. + +## Mi az ether? {#what-is-ether} + +**Ether (ETH)** a kriptovaluta, amelyet számtalan dologra használnak az Ethereum hálózaton. Alapvetően ez az egyetlen elfogadott fizetési eszköz a tranzakciódíjakhoz, és a [Beolvadás](/roadmap/merge) után ether kell ahhoz, hogy blokkot javasoljanak és validáljanak a főhálózaton. Az ether emellett az elsődleges fedezet a [decentralizált pénzügyek (DeFi)](/defi) kölcsönzési piacain, az NFT (nem helyettesíthető token) piactereken könyvelési egység, fizetség a szolgáltatások nyújtásakor vagy termékeladáskor és még sok más esetben. + +Az Ethereum lehetővé teszi a fejlesztők számára, hogy [**decentralizált alkalmazásokat (dapp)**](/developers/docs/dapps) hozzanak létre, amely ugyanazt a számítási kapacitást használja. Ez egy véges kapacitás, ezért az Ethereumnak szüksége van egy olyan mechanizmusra, amellyel megállapítható, hogy ki használja fel azt. Máskülönben egy alkalmazás véletlenül vagy rosszhiszeműen fel tudná használni a hálózat összes erőforrását, így mások nem férnének ahhoz hozzá. + +Az ether kriptovaluta segíti az árazási mechanizmust az Ethereum számítógépes kapacitására vonatkozóan. Amikor a felhasználó tranzakciót akar indítani, ethert kell fizetnie, hogy ez a tranzakció bekerülhessen a blokkláncra. Ezt a felhasználói költséget [gázdíjnak (tranzakciós díj)](/developers/docs/gas/) nevezik, ami pedig attól függ, hogy az adott tranzakció végrehajtásához mennyi kapacitásra van szükség, illetve ugyanabban az időben mennyire van kereslet. + +Ezért még ha egy rosszindulatú dapp egy végtelen körforgást indítana is el, a tranzakció végül kifogyna az etherből és leállna, így a hálózat visszatér a normális állapotba. + +[Gyakori az, hogy összekapcsolják](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) az Ethereumot és az ethert – amikor az emberek az Ethereum árára gondolnak, akkor az ethernek az árát értik alatta. + +## Az ether létrehozása (minting) {#minting-ether} + +A minting az a folyamat, amikor új ethert hoznak létre az Ethereum főkönyvön. A mögöttes Ethereum protokoll kreálja az új ethert, a felhasználók nem tudnak ilyet tenni. + +Az ether minden javasolt blokk jutalmaként keletkezik, illetve minden korszakban azért a validátori tevékenységért jár, ami a konszenzus létrehozását adja. A teljes kiadott összeg függ a validátorok számától, és hogy ők mennyi ethert helyeztek letétbe. Ez a teljes kiadás ideális esetben egyenlően oszlik el a validátorok között az, mivel minden validátor jóhiszemű és online van, de a valóságban változik a validátor teljesítménye alapján. A blokkjavasló a kiadott összeg 1/8-át kapja meg, a többi eloszlik a többi validátor között. A blokkjavasló emellett még borravalót kap a tranzakciós díjból és MEV-hez (maximálisan kinyerhető érték) kapcsolódó bevételt, ez azonban az újrahasznált etherből ered, nem az újból. + +## Az ether elégetése {#burning-ether} + +Ahogy új ether keletkezik a blokkhoz kapcsolódó jutalmak következtében, úgy meg is szűnik, amit elégetésnek nevezünk. Amikor az ethert elégetik, az örökre kivonódik a körforgásból. + +Ez minden tranzakciónál megtörténik az Ethereumon. Amikor a felhasználó fizet a tranzakcióért, akkor az alap gázdíj, amit a kereslet alapján állapít meg a rendszer, megsemmisül. Ez megkönnyíti a tranzakciós illeték becslését az Ethereumon, tekintve, hogy a blokkméretek változóak és van egy maximális gázdíj. Amikor nagy a kereslet a hálózaton, akkor a [blokkok](https://etherscan.io/block/12965263) több ethert égetnek el, mint amennyit létrehoznak, tehát ellentételezik a kibocsátást. + +Az alapdíj elégetése megakadályozza, hogy a blokk-készítők manipulálják a tranzakciókat. Például, ha egy blokk-készítő megkapná az alapdíjat, akkor a saját tranzakcióit ingyen tehetné be, míg a többiek díját megemelné. Alternatívaként vissza lehetne adni az alapdíjat a felhasználóknak láncon kívül, ami egy homályosabb és komplexebb tranzakciósilleték-piachoz vezetne. + +## Az ether címletei {#denominations} + +Mivel számos tranzakció értéke az Ethereumon viszonylag kicsi, ezért az ether számos címlettel bír, amelyek kisebb egységek. Ezekből a wei és a gwei a legfontosabbak. + +Wei a legkisebb címlet, ezért sok technikai bevezetés, mint az [Ethereum Sárga könyv](https://ethereum.github.io/yellowpaper/paper.pdf) minden kalkulációt ebben végez. + +Gwei vagyis giga wei általában a gázdíj meghatározásában jelenik meg az Ethereumon. + +| Címlet | Érték etherben | Gyakori használat | +| ------ | ---------------- | ---------------------------------- | +| Wei | 10-18 | Technikai implementáció | +| Gwei | 10-9 | A felhasználóknak érthető gázdíjak | + +## Az ether küldése {#transferring-ether} + +Az Ethereumon minden tranzakció tartalmaz egy `value` (érték) mezőt, ami az elküldendő ether összegét mutatja wei címletben, hogy a küldő címéről a fogadó címére érkezzen. + +Amikor a fogadó címe egy [okosszerződés](/developers/docs/smart-contracts/), akkor ezt az elküldött ethert a gázdíjak fizetésére is használhatják, amikor az okosszerződés végrehajtja a programkódját. + +[Bővebben a tranzakciókról](/developers/docs/transactions/) + +## Az ether-egyenleg lekérdezése {#querying-ether} + +A felhasználók bármelyik [számla](/developers/docs/accounts/) egyenlegét meg tudják nézni az adott számla `balance` (egyenleg) mezőjében, ami az ott lévő ethert weiben mutatja. + +Az [Etherscan](https://etherscan.io) egy népszerű eszköz arra, hogy egy webalapú alkalmazásban megnézhessék egy adott cím egyenlegét. Például [ez az Etherscan oldal](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae) megmutatja az Ethereum Alapítvány egyenlegét. A számlaegyenlegeket a tárcák lekérdezésével vagy a csomópontokon közvetlenül is meg lehet nézni. + +## További olvasnivaló {#further-reading} + +- [Az Ether és az Ethereum meghatározása](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ +- [Ethereum fehérkönyv](/whitepaper/): Az eredeti javaslat az Ethereum megalkotására. A jelen dokumentum az ether lényegét és a kialakításának célját írja le. +- [Gwei-kalkulátor](https://www.alchemy.com/gwei-calculator): Használja ezt a gwei-kalkulátort, hogy könnyedén váltson wei, gwei és ether címleteket. Egyszerűen adja meg az összeget weiben, gweiben vagy ETH-ban, és automatikusan kiszámolja az átváltást. + +_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md new file mode 100644 index 00000000000..8f4502e2801 --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md @@ -0,0 +1,116 @@ +--- +title: Bevezetés az Ethereumba +description: A dapp fejlesztője bemutatja az Ethereum alapfogalmait. +lang: hu +--- + +## Mi az a blokklánc? {#what-is-a-blockchain} + +A blokkláncot legjobban úgy lehet leírni, mint egy nyilvános adatbázist, melyet frissítenek és megosztanak egy számítógépes hálózaton. + +A "blokk" arra utal, hogy az adat és az állapot szekvenciális adagokban vagy "blokkokban" van tárolva. Ha ETH-t küld valakinek, akkor a tranzakciós adatot hozzá kell adni egy blokkhoz, hogy végrehajtásra kerüljön. + +A "lánc" arra a tényre utal, hogy minden egyes blokk kriptográfiailag hozzá van rendelve a szülő blokkjához. Tehát a blokkok össze vannak kötve. Egy blokk adatát nem lehet megváltoztatni anélkül, hogy megváltoztatnánk az összes későbbi blokkot, amely a teljes hálózat konszenzusát igényelné. + +A hálózat minden számítógépének meg kell egyeznie minden új blokkon és az egész láncon. Ezeket a számítógépeket úgy ismerjük, mint csomópontok. A csomópontok biztosítják, hogy mindenki számára ugyanaz az adat. Ahhoz, hogy ezt az elosztott megegyezést teljesítse, a blokkláncoknak szükségük van konszenzusmechanizmusra. + +Az Ethereum [proof-of-stake alapú konszenzusmechanizmust](/developers/docs/consensus-mechanisms/pos/) használ. Aki új blokkot akar adni a lánchoz, annak le kell kötnie ETH-t – az Ethereum saját valutáját – fedezetként, és futtatniuk kell a validátor szoftvert. Ezen validátorok közül véletlenszerűen választják ki a blokkot javaslót, amelyet a többi validátor ellenőriz és hozzáad a lánchoz. Jutalmak és büntetések rendszere ösztönzi a résztvevőket a jóhiszemű viselkedésre és arra, hogy online legyenek. + +Ha szeretné látni, hogy a blokklánc adat hogyan hashelődik és azután hogyan adódik hozzá a blokkreferenciák történetéhez, akkor nézze meg [ezt a bemutatót](https://andersbrownworth.com/blockchain/blockchain) Anders Brownworth narrálásával, illetve az alábbi videót. + +Nézze meg, ahogy Anders elmagyarázza a hasheket a blokkláncban: + + + +## Mi az Ethereum? {#what-is-ethereum} + +Az Ethereum egy blokklánc egy beágyazott számítógéppel. Alapot szolgáltat alkalmazások és szervezetek számára egy decentralizált, engedélymentes és cenzúrának ellenálló módon. + +Az Ethereum univerzumban van egy kanonikus számítógép (melyet Ethereum Virtuális Gépnek vagy EVM-nek hívnak), amelynek állapota felett mindenki egyetért a hálózaton. Mindenki, aki részt vesz az Ethereum hálózatban (minden Ethereum-csomópont) egy másolattal rendelkezik ennek a számítógépnek az állapotáról. Ezen kívül bármely résztvevő közvetíthet kéréseket ehhez a számítógéphez, hogy tetszőleges számításokat hajtsanak végre. Amikor egy ilyen kérést közvetítenek, a többi résztvevő a hálózaton hitelesíti, validálja és véghez viszi (lefuttatja) a számítást. Ez állapotváltozást okoz az EVM-ben, amelyet a teljes hálózatban elköteleznek és tovább terjesztenek. + +A számítási kérelmeket tranzakciós kérelmeknek nevezzük; az összes tranzakció bejegyzését, valamint az EVM jelenlegi állapotát a blokklánc tárolja, amelyet viszont minden csomópont tárol és elfogad. + +A kriptográfiai mechanizmusok biztosítják, hogy az ellenőrzött és a blokklánchoz hozzáadott tranzakciók később nem változtathatók meg. Ugyanazok a mechanizmusok biztosítják azt is, hogy az összes tranzakciót megfelelő engedélyekkel írják alá és hajtják végre (senki ne legyen képes digitális eszközök küldésére Alice számlájáról, kivéve magát Alice-t). + +## Mi az ether? {#what-is-ether} + +**Ether (ETH)** az Ethereum saját kriptovalutája. Az ETH célja, hogy a számítási kapacitásért fizetni lehessen. Egy ilyen piac gazdasági ösztönzőt biztosít a résztvevőknek, hogy hitelesítsék/végrehajtsák a tranzakciós kérelmeket és, hogy számítási kapacitást szolgáltassanak a hálózatnak. + +A résztvevők a tranzakcióért jutalomként felajánlanak ETH-t a hálózatnak. A hálózat elégeti a jutalom egy részét és díjazza azokat, akik végül elvégzik a tranzakció ellenőrzését, végrehajtását, a blokkláncba való beillesztését és a hálózatba történő közvetítését. + +Az ETH összege a számítási kapacitáshoz kapcsolódik. Ezek a jutalmak megakadályozzák a rosszindulatú résztvevőket is abban, hogy szándékosan eltömítsék a hálózatot azzal, hogy végtelen ciklusokat vagy erőforrásigényes szkriptek végrehajtását kérik, mivel ezeknek a szereplőknek fizetni kell a kalkulációért. + +Az ETH-t arra is használják, hogy kriptogazdasági biztonságot adjon a hálózatnak három módon: 1) a validátorok jutalmat kapnak, hogy blokkot javasolnak vagy kiszűrik a rosszhiszemű viselkedést; 2) a validátorok letétbe helyezik fedezetként a rosszhiszemű viselkedés elkerülése érdekében (csalás esetén az ETH megsemmisül); 3) a szavazatok súlyozására használják az újonnan javasolt blokkoknál, a konszenzusmechanizmus elágazási pontjához kapcsolódóan. + +## Mi az az okosszerződés? {#what-are-smart-contracts} + +A gyakorlatban a résztvevők nem írnak minden alkalommal új kódot, amikor számítást kérelmeznek az EVM-től. Ehelyett az alkalmazásfejlesztők programokat (újrafelhasználható kódrészleteket) töltenek fel az EVM tárhelyére, majd a felhasználók kérik, hogy ezeket a kódrészleteket lefuttassák változó paraméterekkel. A feltöltött és a hálózat által végrehajtott programokat okosszerződéseknek hívjuk. + +Úgy is elképzelheti ezeket az okosszerződéseket, mint egyfajta ételautomata: egy szkript, amelyet ha meghívnak bizonyos paraméterekkel, végrehajt valamilyen akciót vagy számítást, ha bizonyos feltételek teljesülnek. Például egy egyszerű árusító okosszerződés létrehozhatná és átruházhatná egy digitális eszköz tulajdonjogát, ha a hívó fél ETH-t küld egy bizonyos címzettnek. + +Bármely fejlesztő írhat egy okosszerződést és teheti nyilvánossá a hálózat számára úgy, hogy a blokkláncot egy adat rétegként használja a hálózatnak fizetett díj ellenében. Bármely felhasználó meghívhatja az okosszerződést és végrehajthatja a kódját szintén valamekkora díj ellenében. + +Ezáltal az okosszerződésekkel a fejlesztők tetszőlegesen bonyolult felhasználó oldali alkalmazásokat és szolgáltatásokat fejleszthetnek és telepíthetnek: piactereket, pénzügyi eszközöket, játékokat stb. + +## Terminológia {#terminology} + +### Blokklánc {#blockchain} + +Az összes blokk sorozata, amely elköteleződött az Ethereum hálózaton a hálózati történetben. A név onnan származik, hogy minden egyes blokk tartalmaz egy referenciát az előző blokkra, amely segít fenntartani egy sorrendet a összes blokk között (így egy pontos történetet is). + +### ETH {#eth} + +**Ether (ETH)** az Ethereum saját kriptovalutája. A felhasználók más felhasználóknak ETH-t fizetnek, hogy teljesítsék a kód végrehajtási kérelmeiket. + +[Többet az ETH-ről](/developers/docs/intro-to-ether/) + +### EVM {#evm} + +Az Ethereum Virtuális Gép egy globális számítógép, amelynek állapota felett az Ethereum-hálózat minden résztvevője tárol és egyet ért. Bármely résztvevő kérelmezheti valamilyen tetszőleges kód végrehajtását az EVM-en; a kód végrehajtás megváltoztatja az EVM állapotát. + +[További tudnivalók az EVM-ről](/developers/docs/evm/) + +### Csomópontok {#nodes} + +A valódi gépek, amelyek az EVM állapotot tárolják. A csomópontok kommunikálnak egymással, hogy információkat terjesszenek az EVM állapotáról és az új állapotváltozásokról. Bármely felhasználó kérheti a kód végrehajtását azáltal is, hogy kód végrehajtási kérelmet közvetít egy csomópontból. Az Ethereum hálózat az összes Ethereum csomópont és a kommunikációjuk összessége. + +[Többet a csomópontokról](/developers/docs/nodes-and-clients/) + +### Számlák {#accounts} + +Ahol az ETH tárolódik. A felhasználók indíthatnak számlákat, ETH-t helyezhetnek el a számlákon, és utalhatnak át a számlájukról más felhasználóknak. A számlák és a számla egyenlegek egy nagy táblában vannak eltárolva az EVM-ben; a teljes EVM állapot részei. + +[További tudnivalók a számlákról](/developers/docs/accounts/) + +### Tranzakciók {#transactions} + +A tranzakciós kérelem egy formális kifejezés a kód végrehajtási kérelemre az EVM-en, a tranzakció pedig egy teljesített tranzakciós kérelem és a hozzárendelt változás az EVM állapotában. Bármely felhasználó közvetíthet tranzakciós kérelmet a hálózatra egy csomópontból. Ahhoz, hogy a tranzakciókérelemnek valóban legyen hatása az elfogadott EVM-állapot felett, először validálni kell, végre kell hajtani és komittálni kell a hálózatra egy másik csomópont által. Bármely kód végrehajtása állapotváltozást okoz az EVM-ben; elkötelezettséggel ez az állapotváltozás a hálózat minden csomópontjához eljut. Néhány tranzakció példa: + +- Küldjön X ETH-t a számlámról Alice számlájára. +- Publikáljon egy okosszerződéses kódot az EVM státuszba. +- Hajtsd végre az okosszerződés kódot az X címen az EVM-ben Y paraméterekkel. + +[Többet a tranzakciókról](/developers/docs/transactions/) + +### Blokkok {#blocks} + +A tranzakciók száma nagyon magas, így a tranzakciókat adagokban vagy blokkokban „kötelezzük el”. A blokkok általában több tucat vagy több száz tranzakciót tartalmaznak. + +[További tudnivalók a blokkokról](/developers/docs/blocks/) + +### Okosszerződések {#smart-contracts} + +Egy újra felhasználható kódrészlet (egy program), amelyet egy fejlesztő publikál az EVM státuszba. Bárki kérheti az okosszerződéses kód végrehajtását egy tranzakciós kérelemmel. Mivel a fejlesztők tetszőlegesen végrehajtható alkalmazásokat írhatnak az EVM-be (játékokat, piactereket, pénzügyi eszközöket stb.) okosszerződések publikálásával, ezért gyakran hívjuk ezeket [dappoknak, vagy decentralizált alkalmazásoknak](/developers/docs/dapps/). + +[Többet az okos szerződésekről](/developers/docs/smart-contracts/) + +## További olvasnivaló {#further-reading} + +- [Ethereum fehérkönyv](/whitepaper/) +- [Amúgy hogyan működik az Ethereum?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_ (**Megjegyzés:** bár ez a forrás még mindig értékes, de a [Beolvadás](/roadmap/merge) előtti, és ezért az említett proof-of-work mechanizmus helyett az Ethereum már [proof-of-stake](/developers/docs/consensus-mechanisms/pos)-et használ) + +_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ + +## Kapcsolódó útmutatók {#related-tutorials} + +- [Egy fejlesztő útmutatása az Ethereumba 1. rész](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Az Ethereum nagyon kezdőbarát felfedezése Python és web3.py használatával_ diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/networks/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/networks/index.md new file mode 100644 index 00000000000..7412237f931 --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/networks/index.md @@ -0,0 +1,149 @@ +--- +title: Hálózatok +description: Egy áttekintő az Ethereum hálózatairól és hogy hol lehet tesztnet ethert (ETH) szerezni, hogy teszteld az alkalmazásaidat. +lang: hu +--- + +Az Ethereum-hálózatok olyan összekapcsolt számítógépek csoportjai, amelyek az Ethereum-protokoll segítségével kommunikálnak. Egyetlen Ethereum főhálózat létezik, de ugyanazt a protokollt használó, független hálózatokat is létre lehet hozni tesztelési és fejlesztési célból. Számos ilyen független hálózat létezik, amelyek a protokollt követik, de nem kommunikálnak egymással. Akár a saját számítógépén is létrehozhat egyet, hogy egy okosszerződést vagy egy web3 alkalmazást teszteljen. + +Ethereum-számlája működni fog a különböző hálózatokon, de a számlaegyenlege és a tranzakciós előzmények nem kerülnek át az Ethereum fő hálózatából. Tesztelési célból hasznos tudni, hogy amely hálózatok állnak rendelkezésre, és hogy hogyan szerezhet egy teszthálózat ETH-t, amivel kipróbálhat dolgokat. Biztonsági okokból nem javasolt olyan számla használata a teszthálózaton, amely a főhálózathoz tartozik és fordítva. + +## Előfeltételek {#prerequisites} + +Érdemes tisztában lennie az [Ethereum alapjaival](/developers/docs/intro-to-ethereum/), mielőtt a különböző hálózatokról olvas, mivel ezek a teszthálózatok az Ethereum olcsó és biztonságos verziói, amelyekkel ki lehet próbálni dolgokat. + +## Nyilvános hálózatok {#public-networks} + +A nyilvános hálózatokat bárki elérheti szerte a világban egy internetkapcsolattal. Bárki olvashat és indíthat tranzakciókat egy nyilvános blokkláncon és hitelesítheti a tranzakciók végrehajtását. A tagok közötti konszenzus dönti el az új tranzakciók bedolgozását és a hálózat státuszát. + +### Ethereum-főhálózat {#ethereum-mainnet} + +A főhálózat az elsődleges nyilvános Ethereum produkciós blokklánc, ahol valós értékű tranzakciók történnek az elosztott főkönyvön. + +Amikor az emberek és tőzsdék az ETH árfolyamon vitatkoznak, akkor a főhálózati ETH-ről beszélnek. + +### Ethereum-teszthálózatok {#ethereum-testnets} + +A főhálózat mellett vannak nyilvános tesztnetek. Ezeket a hálózatokat a protokoll fejlesztők vagy az okosszerződések fejlesztői használják, hogy teszteljék mind a protokoll frissítéseket, és a lehetséges okosszerződéseket egy produkciószerű környezetben a főhálózatba történő telepítés előtt. Úgy is gondolhatsz rá, mint a produkciós és a staging szerver analógiájára. + +Általában fontos, hogy le legyen tesztelve egy teszthálózatra írt szerződéses kód, mielőtt a főhálózatra telepítenénk. Azoknál az alkalmazásoknál, ahol már meglévő okosszerződéssel kell kapcsolódni, a legtöbb projekt ezeknek a másolatát átteszi a teszthálózatra. + +A legtöbb teszthálózat úgy indul, hogy egy engedélyezett proof-of-authority konszenzusmechanizmust használ. Ez azt jelenti, hogy a csomópontok egy kis csoportja van kiválasztva a tranzakciók validálására és új blokkok létrehozására - az identitásukat helyezik letétbe a folyamat alatt. Alternatívaként néhány teszthálózat egy nyitott proof-of-stake konszenzusmechanizmust vezet be, ahol mindenki futtathat validátort, ahogy az Ethereum főhálózaton is működik. + +A teszthálózathoz tartozó ETH-nak elvileg nincs valós értéke. Ugyanakkor a ritka vagy nehezen megszerezhető teszthálózati ETH-nek mégis kialakulhat valamilyen piaca. Mivel ETH-re van szükség, hogy ténylegesen interakcióba lépjen az Ethereummal (még a teszthálózaton is), a legtöbb ember csapokból szerzi a teszthálózati ETH-t. A legtöbb csap egy web alkalmazás, ahol beírhatja a címét, amire ETH-t szeretne kapni. + +#### Melyik teszthálózatot használja? + +A két nyilvános teszthálózat, amelyet a kliens fejlesztők jelenleg fenntartanak a Sepolia és a Goerli. Sepolia egy hálózat a szerződés- és alkalmazásfejlesztők számára, ahol az alkalmazásaikat tesztelhetik. A Goerli-hálózat a protokollfejlesztőknek biztosít teret frissítéseik teszteléséhez, illetve a letétbe helyezőknek a validátorok futtatásához. + +#### Sepolia {#sepolia} + +**a Sepolia az ajánlott teszthálózat az alkalmazásfejlesztők számára.**. A Sepolia-hálózat egy engedélyezett validátorszettet használ. Viszonylag új, tehát kevés státusz és előzmény található rajta. Ezért gyorsan tud szinkronizálni, a csomópont futtatása pedig kevesebb tárhelyet igényel. Ez hasznos azoknak, akik gyorsan fel akarnak állítani egy csomópontot és közvetlenül kapcsolódni a hálózattal. + +- Zárt validátorszett, amelyet a kliensek és a tesztelő csapatok irányítanak +- Új teszthálózat, amelyre kevesebb alkalmazás van telepítve +- Gyorsan szinkronizál és kevesebb tárhely kell a csomópont futtatáshoz + +##### Források + +- [Honlap](https://sepolia.dev/) +- [GitHub](https://github.com/eth-clients/sepolia) +- [Otterscan](https://sepolia.otterscan.io/) +- [Etherscan](https://sepolia.etherscan.io) +- [Blockscout](https://eth-sepolia.blockscout.com/) + +##### Csapok + +- [QuickNode Sepolia csap](https://faucet.quicknode.com/drip) +- [Grabteeth](https://grabteeth.xyz/) +- [PoW csap](https://sepolia-faucet.pk910.de/) +- [Coinbase Wallet csap | Sepolia](https://coinbase.com/faucets/ethereum-sepolia-faucet) +- [Alchemy Sepolia csap](https://sepoliafaucet.com/) +- [Infura Sepolia csap](https://www.infura.io/faucet) +- [Chainstack Sepolia csap](https://faucet.chainstack.com/sepolia-faucet) +- [Ethereum-ökoszisztéma csap](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) + +#### Goerli _(hosszútávú támogatás)_ {#goerli} + +_Megjegyzés: [a Goerli teszthálózat lezárásra kerül](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) és a [Holesovice](https://github.com/eth-clients/holesovice) veszi át a helyét 2023-ban. Kérjük, hogy vigye át az alkalmazásait a Sepolia hálózatra._ + +A Goerli egy olyan teszthálózat, ahol a validálást és a letétbe helyezést lehet tesztelni. A Goerli hálózat minden olyan felhasználók számára elérhető, aki teszthálózati validátort szeretne futtatni. Ezt használhatják azok a letétesek is, akik tesztelni akarják a protokollfrissítéseket, mielőtt azok a főhálózatra kerülnének. + +- Nyitott validátorszett, a letétesek tesztelhetik a hálózati frissítéseket +- Sok státusz elérhető, ezért alkalmas az okosszerződések komplex interakcióit letesztelni +- Hosszabb ideig tart a szinkronizálás és több tárhely kell a csomópont futtatáshoz + +##### Erőforrások + +- [Honlap](https://goerli.net/) +- [GitHub](https://github.com/eth-clients/goerli) +- [Etherscan](https://goerli.etherscan.io) +- [Blockscout](https://eth-goerli.blockscout.com/) + +##### Csapok + +- [QuickNode Goerli csap](https://faucet.quicknode.com/drip) +- [Grabteeth](https://grabteeth.xyz/) +- [PoW csap](https://goerli-faucet.pk910.de/) +- [Paradigm csap](https://faucet.paradigm.xyz/) +- [Alchemy Goerli csap](https://goerlifaucet.com/) +- [All That Node Goerli csap](https://www.allthatnode.com/faucet/ethereum.dsrv) +- [Coinbase Wallet csap | Goerli](https://coinbase.com/faucets/ethereum-goerli-faucet) +- [Chainstack Goerli csap](https://faucet.chainstack.com/goerli-faucet) + +Ha szeretne egy validátort indítani a Holesky teszthálózaton, akkor használja az ethstaker [„olcsó Holesky validátor” indítópultot](https://holesky.launchpad.ethstaker.cc/en/). + +### Második blokkláncréteg (L2) teszthálózatok {#layer-2-testnets} + +[A második blokkláncréteg (L2)](/layer-2/) az Ethereum skálázási megoldásait takarja. Az L2 egy elkülönült blokklánc, ami kiterjeszti az Ethereumot, örökölve annak biztonsági garanciáit. Az L2 teszthálózatok szorosan kapcsolódnak a nyilvános Ethereum teszthálózatokhoz. + +#### Arbitrum Goerli {#arbitrum-goerli} + +Teszthálózat az [Arbitrum-hoz](https://arbitrum.io/). + +##### Csapok + +- [Chainlink csap](https://faucets.chain.link/) + +#### Optimistic Goerli {#optimistic-goerli} + +Teszthálózat az [Optimism-hoz](https://www.optimism.io/). + +##### Csapok + +- [Paradigm csap](https://faucet.paradigm.xyz/) +- [Coinbase Wallet csap | Optimism Goerli](https://coinbase.com/faucets/optimism-goerli-faucet) + +#### Starknet Goerli {#starknet-goerli} + +Teszthálózat a [Starknethez](https://www.starknet.io). + +##### Csapok + +- [Starknet csap](https://faucet.goerli.starknet.io) + +## Privát hálózatok {#private-networks} + +Egy Ethereum hálózat privát, ha a csomópontok nem kapcsolódnak egy nyilvános hálózathoz (vagyis a főhálózathoz vagy egy teszthálózathoz). Ebben a kontextusban a privát azt jelenti, hogy elszigetelt és fenntartott, nem pedig azt, hogy védett vagy biztonságos. + +### Fejlesztői hálózatok {#development-networks} + +Egy Ethereum alkalmazás fejlesztésekor fontos, hogy egy privát hálózaton futtassa, hogy megnézze, hogyan működik telepítés előtt. Hasonlóan ahhoz, amikor egy lokális szervert futtat a számítógépén webfejlesztés céljából, egy lokális blokklánc-példányt is futtathat, ahol tesztelheti a dappot. Ez gyorsabb iterációt tesz lehetővé, mint egy nyilvános tesztnet. + +Vannak olyan projektek és eszközök, amelyek ebben segítenek. Tudjon meg többet a [fejlesztői hálózatokról](/developers/docs/development-networks/). + +### Konzorciumhálózatok {#consortium-networks} + +Egy konszenzus folyamatot néhány előre meghatározott megbízható csomópont végzi. Például egy ismert tudományos intézmények magánhálózata, amelyek mindegyike egyetlen csomópontot irányít, és a blokkokat az aláírók küszöbértéke érvényesíti a hálózaton belül. + +Ha egy nyilvános Ethereum hálózat olyan, mint a nyilvános internet, akkor úgy gondoljon a konzorcium hálózatra, mint egy privát intranetre. + +## Kapcsolódó eszközök {#related-tools} + +- [Chainlist](https://chainlist.org/) _– az EVM-hálózatok listája, hogy a tárcákat és a szolgáltatókat a megfelelő Chain ID és Network ID segítségével kapcsolják be_ +- [EVM-alapú láncok](https://github.com/ethereum-lists/chains) _– GitHub könyvtár a lánc metaadatokból, amelyek a Chainlisten megjelennek_ + +## További olvasnivaló {#further-reading} + +- [Javaslat: kiszámítható Ethereum teszthálózati életciklus](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) +- [Az Ethereum teszthálózatok evolúciója](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/transactions/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/transactions/index.md new file mode 100644 index 00000000000..a2b0532b580 --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/transactions/index.md @@ -0,0 +1,221 @@ +--- +title: Tranzakciók +description: Egy áttekintő az Ethereum tranzakciókról – hogyan működnek, az adatszerkezetük és hogyan lehet őket elküldeni egy alkalmazáson keresztül. +lang: hu +--- + +A tranzakciók számlákból származó kriptográfiailag aláírt instrukciók. Egy számla tranzakciót indíthat, hogy frissítse az Ethereum hálózat állapotát. A legegyszerűbb tranzakció az ETH átutalása egyik számláról a másikra. + +## Előfeltételek {#prerequisites} + +Ennek az oldalnak a jobb megértése érdekében javasoljuk, hogy először a [Számlák](/developers/docs/accounts/) és a [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) című cikkeinket olvassa el. + +## Mi az a tranzakció? {#whats-a-transaction} + +Az Ethereum-tranzakció egy külső tulajdonú számla által kezdeményezett tevékenységre utal, más szóval egy számla, amelyet egy ember, nem pedig egy szerződés kezel. Például, ha Bob elküld Alice-nek 1 ETH-t, akkor Bob számláját terhelni kell, Alice számlájára pedig jóvá kell írni az összeget. Ez az állapotot megváltoztató művelet egy tranzakción belül történik. + +![Diagram, amely egy állapotot módosító tranzakciót ábrázol](./tx.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból + +Az EVM állapotát megváltoztató tranzakciókat a teljes hálózat számára közvetíteni kell. Bármely csomópont kérvényezheti egy tranzakció végrehajtását az EVM-en; miután ez megtörténik, egy validátor végrehajtja a tranzakciót és továbbterjeszti az eredményül kapott állapotot a hálózat többi része számára. + +A tranzakciókért fizetni kell, és be kell kerüljenek egy validált blokkba. Hogy egyszerűbb legyen ez az áttekintés, a gázdíjak és a validáció témaköröket máshol taglaljuk. + +Az elküldött tranzakció a következő információkat tartalmazza: + +- `from` – a küldő címe, aki aláírja a tranzakciót. Ez egy külső tulajdonú számla, mivel a szerződéses számlák nem küldenek tranzakciót. +- `to` – a fogadó címe (ha egy külső tulajdonú számla, akkor a tranzakció értéket továbbít. Ha egy szerződéses számla, akkor a tranzakció szerződéskódot fog végrehajtani) +- `signature` – a küldő azonosítója. Ez akkor jön létre, amikor a feladó privát kulcsa aláírja a tranzakciót, és megerősíti, hogy a küldő engedélyezte ezt a tranzakciót +- `nonce` – egy növekvő számláló, amely a számláról küldött tranzakciók számát mutatja +- `value` – az átküldendő ETH mennyisége a küldőtől a címzettnek (WEI-ben, ahol 1 ETH 1e+18 wei-nek felel meg) +- `input data` – opcionális mező tetszőleges adatok megadására +- `gasLimit` – a maximális gáz mennyisége, amelyet a tranzakció elfogyaszthat. Az [EVM](/developers/docs/evm/opcodes) határozza meg a számítási lépésekhez szükséges gázmennyiségét +- `maxPriorityFeePerGas` – az elfogyasztott gáz maximális ára, amely a validátor által kapott borravaló részét képezi +- `maxFeePerGas` – a gázegységért fizethető maximális díj, amit a tranzakcióért kifizetnek (beleértve a `baseFeePerGas` és a `maxPriorityFeePerGas` értékét is) + +A gáz a tranzakció feldolgozásához szükséges számításért jár, amelyet a validátor feldolgoz. A felhasználóknak díjat kell fizetniük ezért a számításért. A `gasLimit` és a `maxPriorityFeePerGas` meghatározza a validátornak fizetett maximális tranzakciós illetéket. [Bővebben a gázról](/developers/docs/gas/). + +A tranzakcióobjektum nagyjából így néz ki: + +```js +{ + from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8", + to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a", + gasLimit: "21000", + maxFeePerGas: "300", + maxPriorityFeePerGas: "10", + nonce: "0", + value: "10000000000" +} +``` + +De a tranzakcióobjektumot alá kell írni a küldő privát kulcsával. Ez bizonyítja, hogy a tranzakció kizárólag a küldőtől jöhetett, és nem történt csalás. + +Egy Ethereum-kliens, mint a Geth, fogja kezelni az aláírási folyamatot. + +Példa egy [JSON-RPC](/developers/docs/apis/json-rpc)-hívásra: + +```json +{ + "id": 2, + "jsonrpc": "2.0", + "method": "account_signTransaction", + "params": [ + { + "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db", + "gas": "0x55555", + "maxFeePerGas": "0x1234", + "maxPriorityFeePerGas": "0x1234", + "input": "0xabcd", + "nonce": "0x0", + "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", + "value": "0x1234" + } + ] +} +``` + +Példa válasz: + +```json +{ + "jsonrpc": "2.0", + "id": 2, + "result": { + "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", + "tx": { + "nonce": "0x0", + "maxFeePerGas": "0x1234", + "maxPriorityFeePerGas": "0x1234", + "gas": "0x55555", + "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", + "value": "0x1234", + "input": "0xabcd", + "v": "0x26", + "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e", + "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", + "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e" + } + } +} +``` + +- a `raw` az aláírt tranzakció a [Recursive Length Prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp) által kódolt formában +- a `tx` az aláírt tranzakció JSON-ban + +Az aláírás hash-sel a tranzakcióról kriptográfiailag be lehet bizonyítani, hogy a küldőtől jött és így továbbították a hálózatra. + +### Az adatmező {#the-data-field} + +A tranzakciók többsége egy szerződést ér el egy külső tulajdonú számláról. A legtöbb szerződést Solidity nyelven írják, az adatmezőt az [alkalmazás bináris interfész (ABI)](/glossary/#abi) alapján lehet értelmezni. + +Az első négy bájt adja meg a funkciót a híváshoz, a funkció nevének és argumentumok hash-ét használva. A funkció néha beazonosítható ebből az [adatbázisból](https://www.4byte.directory/signatures/). + +A hívási adat többi része az argumentumok, [az ABI-specifikáció szerint kódolva](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding). + +Nézzük meg ezt a [tranzakciót](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1). **Kattintson a részletekért** a hívási adatok megtekintéséért. + +A funkcióválasztó a `0xa9059cbb`. Számos [ismert funkció létezik ezzel az aláírással](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb). Ebben az esetben [a szerződés forráskódját](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code) feltöltöttük az Etherscan-be, így tudjuk, hogy a funkció a `transfer(address,uint256)`. + +Az adat többi része: + +``` +0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279 +000000000000000000000000000000000000000000000000000000003b0559f4 +``` + +Az ABI specifikáció szerint az integer értékek (mint a címek, amelyek 20 bájt hosszú integerek) az ABI-ban 32 bájt hosszan jelennek meg, nullákkal az elején. Így tudjuk, hogy a `to` (fogadó) cím a [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279). Az `value` (érték) pedig 0x3b0559f4 = 990206452. + +## Tranzakciótípusok {#types-of-transactions} + +Az Ethereumon található néhány tranzakciótípus: + +- Általános tranzakciók: egyik számláról a másikra. +- Szerződést telepítő tranzakciók: ahol nincs „to” vagyis fogadó cím, és az adatmezőket a szerződéskódra használják. +- A szerződés végrehajtása: olyan tranzakció, amely egy telepített okosszerződéssel kapcsolódik. Ekkor a „to” vagyis fogadó cím az okosszerződés címe. + +### A gázról {#on-gas} + +Ahogy korábban említettük, a tranzakciók [gáz](/developers/docs/gas/)költséget igényelnek a lefutáshoz. Egy egyszerű átutalás 21 000 gázegységet igényel. + +Bob 1 ETH-t küld Alice-nek, ahol a `baseFeePerGas` 190 gwei és a `maxPriorityFeePerGas` 10 gwei, így Bobnak a következő díjat kell kifizetnie: + +``` +(190 + 10) * 21 000 = 4 200 000 gwei +--vagyis-- +0,0042 ETH +``` + +Bob számlája **-1,0042 ETH-val** csökken (1 ETH Alice-nek + 0,0042 ETH gázdíjakra) + +Alice számlájára **+1,0 ETH** érkezik + +Az elégetendő alapdíj **-0,00399 ETH** + +A validátor megtartja a borravalót, ami **+0,000210 ETH** + + +![Egy diagram, amely a fel nem használt gáz visszatérítését ábrázolja](./gas-tx.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból + +A tranzakcióban fel nem használt összes gáz visszakerül a felhasználó számlájára. + +### Okosszerződéses interakciók {#smart-contract-interactions} + +Minden olyan tranzakció gázt igényel, mely okosszerződéssel függ össze. + +Az okosszerződések olyan funkciókat is tartalmazhatnak, mint a [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) vagy [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions), melyek nem változtatnak a szerződés állapotán. Emiatt ezen függvények meghívása egy külső tulajdonú számláról (EOA) nem igényel gázt. Az ennek megfelelő RPC meghívás az [`eth_call`](/developers/docs/apis/json-rpc#eth_call) + +Kivéve, ha az `eth_call` révén használják ezeket, a `view` vagy `pure` függvényeket általában belülről hívják meg (vagyis magából a szerződésből vagy másik szerződésből), ami gázba kerül. + +## Tranzakció-életciklus {#transaction-lifecycle} + +Amikor valaki elküld egy tranzakciót, a következő történik: + +1. A tranzakciós hash kriptográfiailag generálódik: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017` +2. A tranzakció ezután elterjed a hálózaton, bekerül a tranzakció gyűjtőmedencébe, ami az összes függő tranzakciót tartalmazza. +3. A validátornak ki kell választania a tranzakciót és bele kell foglalnia egy blokkba, hogy hitelesítse és „sikeresnek” minősítse. +4. Az idő múlásával a tranzakciót tartalmazó adott blokk a hitelesítettből a véglegesített állapotba jut. Ezek a frissítések biztossá teszik, hogy a tranzakció sikeres és többé nem lehet megváltoztatni. Amint a blokk végleges lesz, csak egy hálózatszintű támadás tudja megváltoztatni, ami sok milliárd dollárba kerülne a támadó részéről. + +## Vizuális bemutató {#a-visual-demo} + +Kövesse végig, ahogy Austin bemutatja a tranzakciókat, a gázt és a bányászatot. + + + +## Beírt tranzakciógöngyöleg {#typed-transaction-envelope} + +Az Ethereum eredetileg egyetlen formátummal rendelkezett a tranzakciókat illetően. Minden tranzakcióban a következő értékek voltak jelen: nonce, gázdíj, gázkorlátozás, a fogadó címe, az érték, adatok, v, r és s. Ezek a mezők [RLP-kódolásúak](/developers/docs/data-structures-and-encoding/rlp/), hogy így nézzenek ki: + +`RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])` + +Az Ethereum tovább fejlődött, hogy többféle tranzakciót is támogatni tudjon olyan funkciók lehetővé tételéhez, mint a hozzáférési listák és a [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), és úgy tudja ezeket bevezetni, hogy ne érintsék az eredeti tranzakció formátumát. + +Az [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) teszi ezt lehetővé. A tranzakciókat így interpretálják: + +`TransactionType || TransactionPayload` + +Ahol a mezők jelentése: + +- `TransactionType` – egy szám 0 és 0x7f között, összesen 128 lehetséges tranzakciótípusra. +- `TransactionPayload` – tetszőleges bájtsor, amelyet a tranzakció típusa határoz meg. + +A `TransactionType` értéke alapján a tranzakció a következő kategórába eshet + +1. **0-s típusú (eredeti) tranzakciók:** Az eredeti tranzakciós formátum az Ethereum bevezetése óta. Nem tartalmaznak az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) által bevezetett jellemzőket, mint a dinamikus gázdíj-kalkuláció vagy elérhetőségi listák az okosszerződéseknek. Ezek az eredeti tranzakciók nem tartalmaznak olyan specifikus előtagot, amely jelezné a típusukat a sorosított formájukban, a `0xf8` bájttal kezdődnek, amikor [Rekurzív hosszúságú prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp) kódolást használnak. A TransactionType értéke ekkor `0x0`. + +2. **1-es típusú tranzakciók:** Az [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) vezette be ezeket az Ethereum [Berlin frissítése](/history/#berlin) során, és ezek egy `accessList` (elérési lista) paramétert tartalmaznak. Ez a lista meghatározza azokat a címeket és tárolási kulcsokat, melyeket a tranzakció várhatóan elér, hogy így csökkentse a [gáz](/developers/docs/gas/)költségét az összetett tranzakcióknak, melyek okosszerződésekből erednek. Az EIP-1559 díjpiaci változások nem részei az 1-es típusú tranzakcióknak. Ezek magukba foglalnak egy `yParity` paramétert, amely lehet `0x0` vagy `0x1`, amely a secp256k1 aláírás y értékének megfelelését jelöli. Ezek a `0x01`bájttal kezdődnek, és a TransactionType értéke `0x1`. + +3. **2-es típusú tranzakciók**, általában EIP-1559-tranzakciók, melyeket az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) vezetett be az Ethereum [London frissítésekor](/history/#london). Ezek lettek az Ethereum-hálózat sztenderd tranzakciótípusai. Egy új díjpiaci mechanizmust vezettek be, amely javítja az előrejelezhetőséget azáltal, hogy egy alapdíjra és egy prioritási díjra osztja fel a tranzakciós díjat. A `0x02` bájttal kezdődnek és olyan mezőket tartalmaznak, mint a `maxPriorityFeePerGas` és `maxFeePerGas`. Jelenleg a 2-es típusú tranzakciók az alapértelmezettek a rugalmasság és a hatékonyság okán, főleg a nagy hálózati leterheltség idején, mert a felhasználók jobban tudják kezelni a tranzakciós díjakat ezáltal. A TransactionType értéke ezekre `0x2`. + + + +## További olvasnivaló {#further-reading} + +- [EIP-2718: Tranzakciógöngyöleg](https://eips.ethereum.org/EIPS/eip-2718) + +_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Számlák](/developers/docs/accounts/) +- [Ethereum virtuális gép (EVM)](/developers/docs/evm/) +- [Üzemanyag](/developers/docs/gas/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/web2-vs-web3/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/web2-vs-web3/index.md new file mode 100644 index 00000000000..d2fd0ad437b --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/web2-vs-web3/index.md @@ -0,0 +1,62 @@ +--- +title: Web2 vs Web3 +description: +lang: hu +--- + +A web2 arra az internetre utal, melyet ma legtöbbünk ismer. Egy internet, melyet olyan cégek dominálnak, melyek szolgáltatásokat nyújtanak a személyes adataidért cserébe. A web3 az Ethereum kontextusában decentralizált alkalmazásokra utal, melyek a blokkláncon futnak. Ezek olyan alkalmazások, amelyek lehetővé teszik, hogy bárki részt vegyen anélkül, hogy monetizálná a személyes adatait. + +Egy sokkal inkább kezdőknek szóló áttekintést szeretne? Tekintse meg a [bevezetés a web3-ba](/web3/) oldalt. + +## Web3 előnyök {#web3-benefits} + +Sok web3-fejlesztő választotta a dappok fejlesztését az Ethereum örökletes decentralizációja miatt: + +- A hálózaton mindenkinek hozzáférése van, hogy használja a szolgáltatást - máshogy megfogalmazva, nincs engedélyhez kötve. +- Senki sem blokkolhatja és nem tagadhatja meg a szolgáltatáshoz való hozzáférést. +- A fizetések be vannak építve a natív tokennel, Etherrel (ETH). +- Az Ethereum Turing-kompatibilis, vagyis lényegében bármi leprogramozható a számára. + +## Gyakorlati összehasonlítás {#practical-comparisons} + +| Web2 | Web3 | +| ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | +| A Twitter bármely felhasználót vagy tweetet cenzúrázhatja | A web3 tweetek cenzúrázhatatlanok, mivel az irányítás decentralizált | +| A fizetési szolgáltatás úgy dönthet, hogy bizonyos munkákért nem engedélyezi a kifizetéseket | A web3 fizetési alkalmazások nem igényelnek személyes adatot és nem tudnak fizetéseket megakadályozni | +| A maszek gazdaságot kiszolgáló alkalmazások leállhatnak és ez hatással lehet a dolgozó bevételére | A web3 szerverek nem állhatnak le – az Ethereumot használják backendként, mely egy több ezer számítógépből álló decentralizált hálózat | + +Ez nem jeleni azt, hogy minden szolgáltatást dappá kell alakítani. Ezek a példák a web2 és a web3 szolgáltatások közötti fő különbségeket hivatottak bemutatni. + +## Web3 korlátok {#web3-limitations} + +A web3-at jelenleg több dolog is korlátozza: + +- Méretezhetőség – a tranzakciók lassabbak a web3-on, mivel decentralizált. Az olyan státuszváltozásokat, mint amilyen a fizetés is, egy csomópontnak kell feldolgoznia és közvetíteni azt a hálózaton keresztül. +- UX – a web3 alkalmazásokkal történő interakció extra lépéseket, szoftvert és oktatást igényelhet. Ez akadályozza az elterjedését. +- Elérhetőség – a modern webböngészők nem elég integráltak ahhoz, hogy a web3-at a legtöbb felhasználó elérhesse. +- Költség – a legtöbb sikeres dapp csak a kódjának csak egy kis hányadát teszi fel a blokkláncra, mivel ez elég költséges. + +## Centralizáció versus decentralizáció {#centralization-vs-decentralization} + +Az alábbi táblázatban felsoroljuk a centralizált és decentralizált digitális hálózatok néhány széleskörű előnyét és hátrányát. + +| Centralizált hálózatok | Decentralizált hálózatok | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Alacsony hálózati átmérő (minden résztvevő egy központi fennhatósághoz kapcsolódik); az információ gyorsan terjed, mivel a terjesztést egy központi fennhatóság kezeli nagy mennyiségű számítási kapacitással. | Hálózat legtávolabbi résztvevői között jelentősen több élnyi távolság is előfordulhat. Az információ közvetítése a hálózat egyik sarkából a másikba sok idő vehet igénybe. | +| Általában nagyobb teljesítmény (nagyobb átvitel, kevesebb a teljes kiadott számítási kapacitás) és könnyebb implementálni. | Általában alacsonyabb teljesítmény (kisebb átvitel, több a teljes kiadott számítási kapacitás) és bonyolultabb implementálni. | +| Az egymásnak ellentmondó adatok előfordulásakor a megoldás tiszta és egyszerű: az igazság végső forrása a központi fennhatóság. | Egy protokoll (gyakran bonyolult) szükséges, hogy a nézeteltéréseket feloldja, ha a peerek egymásnak ellentmondanak az adat állapotáról, melyekről a résztvevőknek szinkronban kéne lenniük. | +| Egyetlen meghibásodási pont: a rosszindulatú szereplők képesek megállítani a hálózatot a központi hatóság megtámadásával. | Nincs egyetlen meghibásodási pont: a hálózat akkor is működhet, ha a résztvevők nagy részét megtámadják/megszűntetik. | +| A hálózati résztvevők közötti koordináció sokkal könnyebb, és azt egy központi hatóság kezeli. A központi hatóság arra kényszerítheti a hálózati résztvevőket, hogy frissítéseket, protokollfrissítéseket stb. fogadjanak el nagyon kis súrlódással. | A koordináció gyakran nehéz, mivel egyetlen résztvevőnek sincs végső szava a hálózati szintű döntésekben, a protokollfrissítésekben stb. A legrosszabb esetben a hálózat hajlamos a szétesésre, ha nézeteltérések vannak a protokoll változásaival kapcsolatban. | +| A központi hatóság cenzúrázhatja az adatokat, potenciálisan elvágva a hálózat egyes részeit a hálózat többi részével való interakciótól. | A cenzúra sokkal nehezebb, mivel az információ sokféleképpen terjedhet a hálózaton keresztül. | +| A hálózatban való részvételt a központi hatóság ellenőrzi. | Bárki részt vehet a hálózatban; nincsenek "kapuőrök." Ideális esetben a részvétel költsége nagyon alacsony. | + +Azt meg kell jegyezni, hogy ezek a minták nem biztos, hogy minden hálózatra igazak. Továbbá a valóságban egy hálózat centralizáltsága/decentralizáltsága skálán mérhető; nincsen teljesen centralizált vagy teljesen decentralizált hálózat. + +## További olvasnivaló {#further-reading} + +- [Mi az a web3?](/web3/) – _ethereum.org_ +- [A web 3.0 alkalmazások architektúrája](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ +- [A decentralizáció jelentése](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _Feb 6, 2017 - Vitalik Buterin_ +- [Why Decentralization Matters](https://medium.com/s/story/why-decentralization-matters-5e3f79f7638e) _Feb 18, 2018 - Chris Dixon_ +- [Mi az a web 3.0 és miért fontos?](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _2019. december 31. – Max Mersch and Richard Muirhead_ +- [Miért van szükség a web 3.0-ra?](https://medium.com/@gavofyork/why-we-need-web-3-0-5da4f2bf95ab) _2018. szeptember 12. – Gavin Wood_ diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/wrapped-eth/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/wrapped-eth/index.md new file mode 100644 index 00000000000..2eacb55c159 --- /dev/null +++ b/public/content/translations/hu/13) Foundational Docs/developers/docs/wrapped-eth/index.md @@ -0,0 +1,65 @@ +--- +title: Mi az a becsomagolt ether (WETH) +description: A becsomagolt ether (WETH) bemutatása, ami egy ERC-20 kompatibilis burkolata az ethernek (ETH). +lang: hu +--- + +# Becsomagolt ether (WETH) {#intro-to-weth} + +Az Ether (ETH) az Ethereum fő valutája. Számos célra használják, mint letétbe helyezéshez, valutaként, illetve a számolási kapacitás kifizetésére gázdíjakban. **A WETH egy továbbfejlesztett formája az ETH-nek néhány új funkcionalitással, melyek az alkalmazásokhoz és az [ERC-20 tokenekhez](/glossary/#erc-20)** szükségesek, amelyek az Ethereumon található más digitális eszközök. Ahhoz, hogy ezekkel a tokenekkel kapcsolódni lehessen, az ETH-nak is ugyanazokat a szabályokat kell követnie, vagyis az ERC-20 szabványt. + +Ennek áthidalására jött létre a becsomagolt ETH (WETH). **A becsomagolt ETH egy okosszerződés, amely lehetővé teszi, hogy bármilyen összeget beletegyen a szerződésbe, és ugyanazt megkapja WETH-ben**, amely megfelel az ERC-20 tokenszabványnak. A WETH az ETH reprezentációja, mellyel lehetségessé válik, hogy ne natív eszközként, hanem ERC-20 tokenként lehessen interakciót végezni vele. A natív ETH-re még mindig szükség van a gázdíjak kifizetéséhez, ezért a letétbe helyezésnél tartson meg valamekkora összeget. + +A WETH ETH-re való kicsomagolásához WETH-okosszerződést használhat. Bármekkora összeget átválthat WETH-ről a WETH okosszerződéssel, és ugyanazt megkapja ETH-ben. Ekkor a letétbe helyezett WETH elég és kikerül az elérhető WETH kínálatból. + +**Nagyjából az ETH kinálat kb. 3%-a van lekötve a WETH tokenszerződésben**, melynek következtében ez a leginkább használt [okosszerződés](/glossary/#smart-contract). A WETH különösen fontos azoknak a felhasználóknak, akik a decentralizált pénzügyek (DeFi) alkalmazásait használják. + +## Miért kell az ETH-t becsomagolni ERC-20 tokenként? {#why-do-we-need-to-wrap-eth} + +Az [ERC-20](/developers/docs/standards/tokens/erc-20/) egy sztenderd interfészt határoz meg az átváltható tokenekhez, így bárki létrehozhat olyan tokent, mely gond nélkül interaktál az Ethereum ökoszisztémában ezen szabvány által működő alkalmazásokkal és tokenekkel. Mivel az **ETH korábban keletkezett, mint az ERC-20 szabvány**, ezért nem felel meg ennek a specifikációnak. Emiatt **nem lehet egyszerűen** átváltani az ETH-t más ERC-20 tokenre vagy **ETH-t használni olyan alkalmazásokban, melyek ERC-20 szabványt használnak**. A becsomagolt ETH a következőket teszi lehetővé: + +- **ETH átváltása ERC-20 tokenekre**: közvetlen módon nem lehet ETH-t váltani ERC-20 tokenekre. A WETH az ether reprezentációja, amely megfelel az ERC-20 helyettesíthető tokenszabványnak, így átváltható más ERC-20 tokenekre. + +- **ETH használata dappokban**: mivel az ETH nem ERC-20-kompatibilis, ezért a fejlesztőknek külön interfészeket kell építeniük (egyet az ETH-hez, egy másikat az ERC-20 tokenekhez) az alkalmazásokban. A becsomagolt ETH átugorja ezt az akadályt, így a fejlesztők ugyanabban a dappban tudják kezelni az ETH-t és a többi tokent. Számos decentralizált pénzügyi alkalmazás használja ezt a szabványt, és piacokat hoz létre e tokenek átváltására. + +## A becsomagolt ether (WETH) és az ether (ETH) közötti különbség {#weth-vs-eth-differences} + +| | **Ether (ETH)** | **Becsomagolt ether (WETH)** | +| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Kínálat | Az ETH kínálatát az Ethereum-protokoll kezeli. Az ETH [kibocsátását](/roadmap/merge/issuance) az Ethereum validátorok kezelik, amikor tranzakciókat hajtanak végre és blokkokat hoznak létre. | A WETH egy ERC-20 token, melynek kínálatát egy okosszerződés kezeli. A WETH új egységeit a szerződés bocsátja ki, miután ETH-letétet kapott a felhasználóktól, vagy a WETH egységek elégnek, amikor a felhasználó vissza akarja azt váltani ETH-re. | +| Tulajdonlás | A tulajdonjogot az Ethereum-protokoll által van kezelve a számlaegyenleg révén. | A WETH tulajdonjogát a WETH token okosszerződés kezeli, melyet az Ethereum protokoll biztosít. | +| Gáz | Az ether (ETH) az elfogadott fizetés a számítási kapacitásért az Ethereum hálózaton. A gázdíjakat gwei-ben (az ether egyik egységében) fejezik ki. | A WETH tokennel való gázfizetés alapvetően nem támogatott. | + +## Gyakran ismételt kérdések {#faq} + + + +Gázdíjat kell fizetni az ETH be- vagy kicsomagolásáért, amikor a WETH szerződést használja. + + + + + +A WETH általánossában biztonságosnak tekinthető, mert egy egyszerű, harcedzett okosszerződésen alapul. A WETH szerződést formálisan is ellenőrizték, mely az Ethereum okosszerződések legmagasabb biztonsági sztenderdje. + + + + + +[A WETH kanonikus bevezetése](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) mellett, melyet ezen az oldalon részleteznek, más változatok is léteznek. Ezek lehetnek személyreszabott tokenek, melyeket az alkalmazásfejlesztők hoztak létre, vagy más blokkláncokon kiadott változatok, illetve máshogy viselkedhetnek vagy más biztonsági beállításokkal bírhatnak. **Mindig ellenőrizze le a tokeninformációt, hogy melyik WETH implementációval végez interakciót.** + + + + + +- [Ethereum főhálózat](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2) +- [Arbitrum](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1) +- [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006) + + + +## További olvasnivaló {#further-reading} + +- [Mi az a WETH?](https://weth.tkn.eth.limo/) +- [WETH tokeninformáció az Etherscan oldalon](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) +- [A WETH formális ellenőrzése](https://zellic.io/blog/formal-verification-weth) diff --git a/public/content/translations/hu/14) Community Pages/community/code-of-conduct/index.md b/public/content/translations/hu/14) Community Pages/community/code-of-conduct/index.md new file mode 100644 index 00000000000..043e7b01a6e --- /dev/null +++ b/public/content/translations/hu/14) Community Pages/community/code-of-conduct/index.md @@ -0,0 +1,77 @@ +--- +title: Magatartási szabályok +description: Alapvető szabályok az ethereum.org oldalain. +lang: hu +--- + +# Magatartási szabályok {#code-of-conduct} + +## Misszió {#mission} + +A legátfogóbb és legelérhetőbb tudásközpont kifejlesztése és fenntartása az Ethereum számára. + +## Értékek {#values} + +Az ethereum.org közösség arra törekszik, hogy: + +- tanító jellegű legyen, mindenkinek segít megérteni az Ethereumot +- befogadó legyen +- elérhető legyen +- közösség által vezérelt legyen +- az Ethereum mögötti technológiákra és alkalmazási területekre fókuszál +- az Ethereumhoz kapcsolódó koncepciókra és dizájnelvekre fókuszál + +## Nem vagyunk {#what-we-are-not} + +- Az Ethereum Alapítvány weboldala +- Olyan platform, ahol befektetéseket vagy bármilyen profitszerzést támogatunk +- Olyan platform, ahol egyéni projekteket vagy szervezeteket mutatunk be vagy hagyunk jóvá +- Decentralizált tőzsde (DEX), centralizált tőzsde (CEX) vagy bármilyen már pénzügyi platform +- Olyan platform, amely bármilyen pénzügyi vagy jogi tanácsot ad + +## Magatartási szabályok {#code-of-conduct} + +### Vállalás {#pledge} + +Az ethereum.org világképének lényege a nyitott részvétel. Ezt a weboldalt és közösséget ezernyi közreműködő tartja fenn, és ez csak úgy lehetséges, ha egy befogadó, részvételt támogató környezetet tartunk fenn. A közreműködők vállalják, hogy olyan környezetet teremtenek, melynek nem része a bántás vagy bosszantás, a ethereum.org minden platformját és közösségi terét beleértve. Az ethereum.org közösség mindenkit örömmel fogad és értékel, aki konstruktív és barátságos módon részt akar venni, és ebben nem számít a kor, bármilyen alkalmatlanság, etnikum, nemi identitás, tapasztalat, a szakértelem területe, tanulmányok, szociogazdasági státusz, nemzetiség, megjelenés, faj, vallás vagy a diverzitás bármelyik dimenziója. + +### Érvényességi terület {#scope} + +Ez a magatartási szabályzat minden ethereum.org helyre érvényes (mint amilyen a GitHub, Discord, Figma Crowdin, Twitter és más online platformok), és amikor a közösség találkozik a valóságban különféle eseményeken, konferenciákon. + +### Irányelveink {#our-standards} + +A pozitív környezethez hozzájáruló viselkedések például: + +- Befogadó nyelvezetet használunk +- A különböző nézeteket és tapasztalatokat tisztelettel kezeljük +- A konstruktív kritikát örömmel vesszük és együttérzően adjuk +- A konfliktusok és ellentétek esetén nyugodtan és professzionálisan közelítünk +- A többi tag felé empátiával és toleranciával fordulunk +- Bátorítjuk az új hangokat a közösségben + +Az elfogadhatatlan viselkedések például: + +- Fizikai erőszak, azzal való fenyegetés vagy támogatása bármilyen formában +- Szexualitással kapcsolatos beszéd vagy kép használata, illetve ilyen jellegű közeledés +- Egy másik ember megszemélyesítése, vagy rosszhiszeműen azt állítani, hogy egy személlyel vagy szervezettel kapcsolatban áll valaki +- Zavaró, derogáló kommentek, személyes vagy politikai támadások +- Más tag zaklatása nyilvános vagy privát csatornákon +- Mások privát információinak nyilvánossá tétele, mint fizikai vagy elektronikus cím, kifejezett kérése nélkül +- Pszichológiai manipuláció, csalás vagy más jellegű befolyásolása a tagoknak +- Bármilyen befektetés, token, projekt hirdetése személyes haszonszerzés céljából, legyen az pénzügyi vagy nem +- A szerverek teleszemetelése nem odavaló tartalommal +- A közösségi moderátorok kérését vagy figyelmeztetését nem venni figyelembe +- Bármilyen viselkedés, ami nem tekinthető megfelelőnek egy professzionális helyzetben + +### Jelentés {#reporting} + +A magatartási szabályok megsértése általában látható a közösségnek, mivel mindent nyitott, nyilvános csatornákon kezelünk, hogy a tagok maguk vigyázzák a rendet. + +Ha úgy véli, hogy valami figyelmet igényelne, akkor szóljon egy moderátornak (pl. discord-vezető), így segíthetnek a kivizsgálásban és a megfelelő válasz megtételében. + +A jelentésnél minden részletet adjon meg, példákkal és időpontokkal. Ez segít, hogy igazságos eredmény születhessen. + +### Szankciók {#enforcement} + +Az eset súlyosságától függően figyelmeztetések, átmeneti kizárások és végleges kizárások várhatók az ethereum.org közösségeitől. diff --git a/public/content/translations/hu/14) Community Pages/community/events/index.md b/public/content/translations/hu/14) Community Pages/community/events/index.md new file mode 100644 index 00000000000..0b564281725 --- /dev/null +++ b/public/content/translations/hu/14) Community Pages/community/events/index.md @@ -0,0 +1,24 @@ +--- +title: Ethereum események +description: Hogyan lehet bekapcsolódni az Ethereum közösségébe. +lang: hu +hideEditButton: true +--- + +# Közelgő események {#events} + +**Minden hónapban részt vehet Ethereum-eseményeken a világ bármely pontján.** Vegyen részt egy Önhöz közel eső eseményen, hogy találkozzon a közösség tagjaival, megismerje a munkalehetőségeket és új képességeket fejlesszen. + + + +A lista nem teljeskörű, a közösség tagjai frissítik. Tudomása van egy tervezett Ethereum-eseményről? [Kérjük, adja hozzá](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-events.json)! + +## Ethereum-találkozók {#meetups} + +Nem talál olyan eseményt, amely jó lenne Önnek? Próbáljon meg elmenni egy találkozóra. Ezek kisebb események, melyeket az Ethereum-rajongók szerveznek, hogy az Ethereum iránt érdeklődők összegyűljenek, beszélgessenek az Ethereumról, megismerjék az új fejlesztéseket. + + + +Saját találkozót szeretne szervezni? Nézze meg a [BUIDL Network-öt](https://consensys.net/developers/buidlnetwork/), ami a ConsesSys kezdeményezése, hogy támogassa az Ethereum találkozókat. + +Ez a lista nem teljeskörű, a közösség tagjai írják. [Több Ethereum találkozót](https://www.meetup.com/topics/ethereum/) találhat itt. Ismer olyan találkozót szervező csoportot, amelyik nincs a listán? [Kérjük, adja hozzá!](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-meetups.json) diff --git a/public/content/translations/hu/14) Community Pages/community/get-involved/index.md b/public/content/translations/hu/14) Community Pages/community/get-involved/index.md new file mode 100644 index 00000000000..577a957a598 --- /dev/null +++ b/public/content/translations/hu/14) Community Pages/community/get-involved/index.md @@ -0,0 +1,135 @@ +--- +title: Hogyan lehet részt venni? +description: Hogyan lehet bekapcsolódni az Ethereum közösségébe. +lang: hu +--- + +# Hogyan lehet részt venni? {#get-involved} + +Az Ethereum-közösségek tagjai különféle háttérrel és képességekkel rendelkeznek. Lehet Ön fejlesztő, művész vagy könyvelő, mindenkinek lehetősége van közreműködni. Az alábbi javaslatok segíthetnek megtalálni a megfelelő kiindulási pontot. + +Kezdje azzal, hogy elolvassa az ethereum.org misszióját és értékeit a [magatartási szabályok](/community/code-of-conduct) oldalon. + +## Fejlesztők {#developers} + +- Tanuljon az Ethereumról és próbálja ki az [ethereum.org/developers/](/developers/) oldalon +- Vegyen részt egy Önhöz közel eső [ETHGlobal](http://ethglobal.co/) hackathonon! +- Nézze meg azokat a [projekteket, melyek a szakterületéhez vagy a választott programnyelvéhez kapcsolódnak](/developers/docs/programming-languages/) +- Nézze meg a [Konszenzus- és végrehajtási réteg megbeszéléseket](https://www.youtube.com/@EthereumProtocol/streams) vagy vegyen részt rajtuk +- [Ökoszisztémát támogató programok listája](https://esp.ethereum.foundation/wishlist/) – eszközök, dokumentáció és infrastruktúra, ahol az Ethereum-ökoszisztémát támogató programok aktívan várják a támogatásért jelentkezőket +- [Web3Bridge](https://www.web3bridge.com/) – csatlakozzon az inspiráló web3-közösséghez, mely egész Afrikában fejlesztők és közösségi tagok százait választja ki, tanítja be és támogatja +- Csatlakozzon az [Eth R&D Discord](https://discord.com/invite/VmG7Uxc) csatornához +- Csatlakozzon az [Ethereum Cat Herders Discord csatornához](https://discord.com/invite/Nz6rtfJ8Cu) + +## Kutatók és akadémikusok {#researchers-and-academics} + +Ön matematikus, kriptográfus vagy közgazdász háttérrel rendelkezik? Érdeklik az élvonalbeli tevékenységek az Ethereum-ökoszisztéma kapcsán: + +- Csatlakozzon az [Eth R&D Discord](https://discord.com/invite/VmG7Uxc) csatornához +- Írjon vagy véleményezzen egy Ethereum fejlesztési javaslatot (EIP) + - Írjon EIP-t + 1. Adja be ötletét az [Ethereum Magicians csoportnak](https://ethereum-magicians.org) + 2. Olvassa el az [EIP-1-et](https://eips.ethereum.org/EIPS/eip-1) – **Igen, ez a _teljes_ dokumentum.** + 3. Kövesse az EIP-1 iránymutatásait. Hivatkozzon rá, ahogy a vázlatot készíti. + - Tudja meg, hogyan lehet [EIP-szerkesztő](https://eips.ethereum.org/EIPS/eip-5069) + - Ön is véleményezheti az EIP-ket már most! Nézze meg a [nyitott PR-okat az `e-review` címkét](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review) használva. Adjon technikai visszajelzést a `discussion-to` hivatkozáson. + - Vegyen részt az [EIP-menedzsementben](https://github.com/ethereum-cat-herders/EIPIP) + - Csatlakozzon az [Ethereum Cat Herders Discord csatornához](https://discord.com/invite/Nz6rtfJ8Cu) + - [Bővebben az EIP-kről](/eips/) +- [Challenges.ethereum.org](https://challenges.ethereum.org/) – magas értékű kutatói jutalmak, ahol akár >$100 000 dollárnál is többet kaphat +- [Ethresear.ch](https://ethresear.ch) – az Ethereum elsődleges kutatói fóruma, illetve a világ legbefolyásosabb fóruma a kriptogazdaság terén +- [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) – egy folyamatos kérdés-válasz sorozat a kutatókkal. A következő részek megnyitásakor bárki feltehet kérdéseket. +- [Ökoszisztémát támogató programok listája](https://esp.ethereum.foundation/wishlist/) – kutatási területek, ahol az Ethereum-ökoszisztémát támogató programok aktívan várják a támogatásért jelentkezőket +- [AllWalletDevs](https://allwallet.dev) – fórum az Ethereum-fejlesztők, -tervezők és -érdeklődők számára, hogy rendszeresen összegyűljenek és megtárgyalják a tárcákat + +[Fedezzen fel még több kutatási területet](/community/research/). + +## Nem technikai képességek {#non-technical} + +Ha Ön nem fejlesztő, nehéz lehet felmérni, hogy hol kapcsolódjon be az Ethereum világába. Íme néhány javaslat hivatkozásokkal együtt a specifikus szakmai hátterekhez. + +### Szervezzen találkozót a városában {#meetups} + +- Nem tudja, hogyan kezdje? A [BUIDL-hálózat](https://consensys.net/developers/buidlnetwork/) segít benne. + +### Írjon az Ethereumról {#write-content} + +- Az Ethereumnak szüksége van jó írókra, akik el tudják magyarázni az értékeit egyszerű nyelven +- Még nem áll készen, hogy a saját cikkét megjelentesse? Vegyen részt a meglévő tartalom kezelésében vagy [javasoljon új tartalmat az ethereum.org számára](/contributing/)! + +### Készítsen jegyzetet a közösségi megbeszéléseken (community calls) {#take-notes} + +- Számos nyilvános közösségi megbeszélés létezik, ahol a jegyzet készítése nagy segítség. Ha érdekli Önt, akkor csatlakozzon az [Ethereum Cat Herders discord](https://discord.com/invite/Nz6rtfJ8Cu) csatornához, és mutatkozzon be! + +### Fordítsa saját nyelvére az Ethereumhoz kapcsolódó tartalmat {#translate-ethereum} + +- Az ethereum.org egy fordítói programot is üzemeltet, mely a weboldalakat és más forrásokat fordítja különféle nyelvekre +- Nézze meg [itt](/contributing/translation-program), hogyan tudna ebben segíteni + +### Csomópont futtatása {#run-a-node} + +Csatlakozzon ezernyi csomópont működtetőjéhez, hogy az Ethereum még decentralizáltabb legyen. + +- [Bővebben a csomópontok futtatásáról](/developers/docs/nodes-and-clients/run-a-node/) + +### Helyezze letétbe a rendelkezésére álló ETH-t {#staking} + +A letétbe helyezéssel jutalmakat tud szerezni, miközben segít az Ethereum hálózatát biztosítani. + +- [Többet a letétbe helyezésről](/staking/) + +### Támogasson projekteket {#support-projects} + +Az Ethereum-ökoszisztéma missziója, hogy közjóval kapcsolatos és nagy hatást tevő projekteket finanszírozzon. Még a kis adományokkal is kimutathatja támogatását és fontos munkákat segíthet. + +- [Gitcoin](https://gitcoin.co/fund) +- [clr.fund](https://clr.fund/#/about) + +## Pénzügyi szakemberek és könyvelők {#financial-professionals} + +- Az Ethereum otthont ad a decentralizált pénzügyek ökoszisztémának – protokollok és alkalmazások hálózata, ami egy alternatív pénzügyi rendszert kínál. Nézzen meg néhány DeFi-alkalmazást a [DeFi Llama](https://defillama.com/) vagy [DeFiPrime](https://defiprime.com) oldalakon +- Ön könyvelő? Az Ethereum-eszközök, mint ETH, tokenek, DeFi stb. számtalan új könyvelési kérdést vetnek fel. Nézzen meg néhány projektet, amelyek a felhasználók könyvelési kihívásait próbálják támogatni – ilyen például a [Rotki](https://rotki.com/) + +## Termékmenedzserek {#product-managers} + +- Az Ethereum-ökoszisztémának az Ön tehetségére is szüksége van! Számos cég keres ilyen pozícióra munkaerőt. Ha szeretne egy nyílt forráskódú projektben közreműködni, keresse meg az [Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) vagy [RaidGuild](https://www.raidguild.org/) csapatokat + +## Marketing {#marketing} + +- Számtalan marketinggel és kommunikációval összefüggő pozíció érhető el az Ethereumnál! + +## Ethereum-álláslehetőségek {#ethereum-jobs} + +**Szeretne munkát találni az Ethereum világában?** + +- [ethereum.org jobs](/about/#open-jobs) +- [Ethereum Foundation job board (Lever)](https://jobs.lever.co/ethereumfoundation) +- [Ethereum Foundation job board (BambooHR)](https://ethereum.bamboohr.com/jobs/) +- [JobStash](https://jobstash.xyz) +- [Cryptocurrency Jobs](https://cryptocurrencyjobs.co/ethereum/) +- [Careers at ConsenSys](https://consensys.net/careers/) +- [Crypto Jobs List](https://cryptojobslist.com/ethereum-jobs) +- [Bankless jobs board](https://pallet.xyz/list/bankless/jobs) +- [Web3 Jobs](https://web3.career) +- [Web3 Army](https://web3army.xyz/) +- [Crypto Valley Jobs](https://cryptovalley.jobs/) +- [Ethereum-álláslehetőségek](https://startup.jobs/ethereum-jobs) +- [CryptoJobster](https://cryptojobster.com/tag/ethereum/) + +## Csatlakozzon egy DAO-hoz {#decentralized-autonomous-organizations-daos} + +A DAO-k decentralizált autonóm szervezetek. Ezek az Ethereum technológiára építve működtetnek szerveződéseket és együttműködéseket. Például a tagság kezelése, a javaslatok megszavazása vagy összegyűjtött eszközök kezelése kapcsán. Bár kísérleti fázisban vannak, de rengeteg lehetőséget ajánlanak, hogy találjon egy hasonlóan gondolkodó csoportot, együttműködő partnereket és hatást gyakoroljon az Ethereum közösségre. [Bővebben a DAO-król](/dao/) + +- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) – _A DAO koncepció támogatása a nem technikai területeken, illetve hogy az emberek értéket teremtsenek a DAO által_ +- [Developer DAO](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) – _Fejlesztők közössége, akik hisznek az internet közös tulajdonlásában_ +- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) – _egy szabadúszó web3-fejlesztői csapat, amely DAO-ként működik_ +- [HausDAO](https://daohaus.club) [@nowdaoit](https://twitter.com/nowdaoit) – _A DAOhaus közösségi irányítása_ +- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) – _Jogi szerepkörök_ +- [Machi X](https://machix.com) [@MachiXOfficial](https://twitter.com/MachiXOfficial) - _Művészeti közösség_ +- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) – _kockázati tőke a korai fázisban lévő kriptoprojektek számára_ +- [MetaGame](https://metagame.wtf) [@MetaFam](https://twitter.com/MetaFam) – _MMORPG játékmechanika a való élethez_ +- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) – _Digifizikális ruházati márkák_ +- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) – _Az Ethereum-fejlesztések finanszírozását intéző közösség_ +- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild) – _Web3-fejlesztők csoportja_ + +Kérjük, hogy az ethereum.org [magatartási szabályait](/community/code-of-conduct) vegye figyelembe, amikor bármilyen kezdeményezésben közreműködik! diff --git a/public/content/translations/hu/14) Community Pages/community/grants/index.md b/public/content/translations/hu/14) Community Pages/community/grants/index.md new file mode 100644 index 00000000000..06307fb83f2 --- /dev/null +++ b/public/content/translations/hu/14) Community Pages/community/grants/index.md @@ -0,0 +1,47 @@ +--- +title: Az Ethereum Alapítvány és közösségi támogatói program +description: A támogatói programok listája az egész Ethereum-ökoszisztémára vonatkozóan. +lang: hu +--- + +# Ethereum-támogatások {#ethereum-grants} + +Az itt bemutatott programok különféle finanszírozási támogatást adnak projekteknek, melyek az Ethereum-ökoszisztéma sikerét és fejlődését segítik elő. Használja ezt útmutatóként ahhoz, hogy finanszírozási lehetőséget találjon magának és jelentkezzen, hogy a következő Ethereum-projektje sikerét előmozdítsa. + +A listát a közösség tartja karban. Ha bármit hiányol vagy nem talál helyesnek, akkor szerkessze az oldalt! + +## Kiterjedt Ethereum-ökoszisztéma {#broad-ethereum-ecosystem} + +Ezek a programok a kiterjed Ethereum-ökoszisztémát támogatják és a projektek széles körének ajánlanak finanszírozást. Mint a skálázási megoldások, közösségépítés, biztonság, adatvédelem és még sok más. Nem kötődnek valamelyik platformhoz, és mindig jó kiindulópont, ha valamiért Ön bizonytalan a támogatások témájában. + +- [EF Ecosystem Support Program](https://esp.ethereum.foundation) – _Nyílt forráskódú projektek finanszírozása: fókuszban az egyetemes eszközök, infrastruktúra, kutatás és közjavak_ +- [Moloch DAO](https://www.molochdao.com/) – _Adatvédelem, L2 skálázás, kliensbiztonság és más területek_ +- [DAO Grants](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) – _A támogatást ajánló szervezetek listája Google-táblázatban_ +- [Academic Grants](https://esp.ethereum.foundation/academic-grants) – _Az Ethereummal kapcsolatos akadémiai munkák támogatása_ +- [Blockworks Grantfarm](https://blockworks.co/grants/programs) – _A Blockworks egy átfogó jegyzéket hozott létre, lefedve az összes támogatást, változtatási javaslatot (RFP) és hibavadászatot._ + +## Projektspecifikus {#project-specific} + +Projektek által adott támogatás olyanoknak, akik az adott technológiát fejlesztenék vagy kísérleteznének vele. + +- [Aave Grants Program](https://aavegrants.org/) – _[Aave](https://aave.com/) támogatási DAO_ +- [Balancer](https://grants.balancer.community/) – _[Balancer](https://balancer.fi/) ökoszisztéma alap_ +- [Chainlink Grants Program](https://chain.link/community/grants) – _[Chainlink](https://chain.link/) közösségi támogatások_ +- [Decentraland Grants Program](https://governance.decentraland.org/grants/) – _[Decentraland](https://decentraland.org/) DAO Metaverzum_ +- [Lido Ecosystem Grants Organisation (LEGO)](https://lido.fi/lego) – _[Lido](https://lido.fi/) pénzügyi ökoszisztéma_ +- [MetaMask Program](https://metamaskgrants.org/) – _[MetaMask](https://metamask.io/) munkavállalók által vezetett támogatási DAO_ +- [SKALE Network Grants Program](https://skale.space/developers#grants) – _[SKALE Network](https://skale.space/) ökoszisztéma_ +- [Swarm Foundation Grants Program](https://my.ethswarm.org/grants) - _[Swarm Foundation](https://www.ethswarm.org/) ökoszisztéma_ +- [The Graph](https://thegraph.com/ecosystem/grants/) – _[The Graph](https://thegraph.com/) ökoszisztéma_ +- [Uniswap Grants Program](https://www.uniswapfoundation.org/approach) – _[Uniswap](https://uniswap.org/)-közösség_ + +## Kvadratikus finanszírozás {#quadratic-funding} + +Az Ethereum nyílt forráskódú gyökerei egy érdekes, új finanszírozási modellhez vezettek: kvadratikus finanszírozás. Ennek lehetősége van azt a módot továbbfejleszteni, ahogy a közjavak finanszírozását kezelhetjük. A kvadratikus finanszírozás gondoskodik arról, hogy azok a projektek kapják a finanszírozást, amelyre tényleg a legnagyobb az igény. Tehát azokat támogatjuk, amelyek a leginkább magasabb szintre emelik az emberek életét. [Bővebben a kvadratikus finanszírozásról.](/defi/#quadratic-funding) + +- [Gitcoin](https://gitcoin.co/grants) +- [clr.fund](https://clr.fund/) + +## Dolgozzon az Ethereumnál {#work-in-ethereum} + +Még nem áll készen, hogy a saját projektjét elindítsa? Cégek százai keresnek lelkes munkavállalókat, hogy az Ethereum-ökoszisztémában közreműködjenek. Többet szeretne tudni? [Nézze meg az Ethereummal kapcsolatos álláshirdetéseket](/community/get-involved/#ethereum-jobs) diff --git a/public/content/translations/hu/14) Community Pages/community/language-resources/index.md b/public/content/translations/hu/14) Community Pages/community/language-resources/index.md new file mode 100644 index 00000000000..1f4bf27fbfb --- /dev/null +++ b/public/content/translations/hu/14) Community Pages/community/language-resources/index.md @@ -0,0 +1,153 @@ +--- +title: Nyelvi források +description: Az Ethereumról szóló nem angol nyelvű források +lang: hu +--- + +# Nyelvi források {#language-resources} + +Az Ethereum közösség globális és sok millió nem angolul beszélő taggal bír. + +Az a célunk, hogy oktatási anyagokat biztosítsunk minden nyelven és segítsünk a nyelvi akadályok leküzdését, amely sok ember számára kihívást jelent. + +Ha Ön az anyanyelvén olvasna szívesen, vagy ismer olyat, aki nem beszél angolul, akkor alább hasznos forrásokat talál. Ethereum rajongók százezrei gyűlnek össze ezeken az online fórumokon, hogy megosszák a híreket, megbeszéljék az új fejlesztéseket, megvitassák a technikai problémákat és elképzeljék a jövőt. + +Ismer valamilyen oktatási anyagot az anyanyelvén? [Adjon be egy kérést](https://github.com/ethereum/ethereum-org-website/issues/new/choose), hogy adják hozzá a listához! + +## Ethereum.org források {#ethereum-org} + +Az Ethereum.org több mint 40 nyelvre van lefordítva, amelyeket minden oldal tetején található nyelvválasztó menüben találhat. + +![Nyelvválasztó menü](./language-selector-menu.png) + +Ha Ön kétnyelvű és segítene nekünk, hogy több embert érjünk el, akkor közreműködhet az [ethereum.org Fordítói programban](/contributing/translation-program/#translation-program) és segíthet lefordítani a weboldalt. + +## Közösségi források {#community} + +### Brazíliai portugál {#br-pt} + +**Hírek** + +- [BeInCrypto](http://www.beincrypto.com.br) – kriptovalutával kapcsolatos hírek és cikkek, beleértve a tőzsdék listáját, amelyek Braziliában elérhetők +- [Cointelegraph](http://cointelegraph.com.br/category/analysis) – brazil verzió a főbb kriptovalutával kapcsolatos hírekkel +- [Livecoins](http://www.livecoins.com.br/ethereum) – kriptovalutával kapcsolatos hírek és eszközök +- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/) – kriptovalutával kapcsolatos hírek és riportok +- [Modular Crypto](https://modularcrypto.xyz/) - kriptovalutával kapcsolatos hírek és oktatási cikkek + +**Oktatás** + +- [web3dev](https://www.web3dev.com.br/) – tartalomközpont és Discord-közösség web3-fejlesztők számára. +- [Web3Brasil](https://github.com/web3brasil/web3brasil) – web3 és DeFi oktatóanyagok +- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) – kriptovalutával kapcsolatos hírek és oktatás, beleértve az Ethereum kezdőknek és a DeFi kezdőknek anyagokat +- [CriptoAtivos](http://www.criptoativos.wiki.br/) – a kriptovaluta világa, oktatás és blog +- [Cointimes](http://www.cointimes.com.br/) – kriptovalutával kapcsolatos hírek és oktatás +- [Web3 starter pack](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/) – útmutató, ami a leggyakoribb és alapvető kriptokérdésekre ad választ + +### Kínai {#zh} + +**Általános források** + +- [Ethereum.cn](https://www.ethereum.cn/) – közösségi tartalom, amely a konszenzusréteg frissítéseit, a core dev megbeszélések jegyzeteit, L2-ket stb. tartalmazza. +- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) – tanuljon meg mindent az alapoktól a haladó szintű Ethereum-témákig +- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) – közösségi tartalom, amely az Ethereum, DeFi, NFT, web3 témákhoz tartozó tudást fedi le +- [123ETH](https://123eth.org/) – Portál az Ethereum-ökoszisztémához +- [Zhen Xiao](http://zhenxiao.com/blockchain/) – ingyenes online kurzusok a kriptovalutáról és alkalmazásairól +- [Ethereum Whitepaper](https://github.com/ethereum/wiki/wiki/[%E4%B8%AD%E6%96%87]-%E4%BB%A5%E5%A4%AA%E5%9D%8A%E7%99%BD%E7%9A%AE%E4%B9%A6) – az Ethereum tanulmányok kínai verziói + +**Ethereum-ökoszisztéma** + +- [ETHPlanet](https://www.ethplanet.org/) – online és személyes hackathonok, képzés egyetemisták számára +- [PrimitivesLane](https://www.primitiveslane.org/) – non-profit kutatói csoport, amely a blokklánc-technológiára fókuszál +- [Ethereum Translation Community CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) – az Ethereum oktatási anyagok lefordítása + +**Fejlesztőknek** + +- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) – tanulócsoport a legfontosabb dapp-projektek tanulmányozására, gondolatok és kommentek megosztása hetente +- [LearnBlockchain](https://learnblockchain.cn/) – fejlesztői közösség a blokklánc-technológiával kapcsolatos információk megosztására + +**Kriptográfiai kutatóknak** + +- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) – WeChat-profil, amely a kriptográfiát, biztonságot stb. magyarázza el. +- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) – WeChat profil, amely a zero-knowledge technológiát ismerteti + +### Cseh {#cs} + +- [Gwei.cz](https://gwei.cz) – helyi közösség a web3 körül, amely oktatási anyagokat készít, online és személyes találkozókat szervez +- [Gwei.cz Příručka](https://prirucka.gwei.cz/) – Ethereum útmutató kezdőknek +- [DAO Příručka](https://dao.gwei.cz/) – útmutató kezdőknek a DAO-okról +- [Mastering Ethereum](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) – Az Ethereum elsajátítása, cseh verzió + +### Francia {#fr} + +- [Ethereum France](https://www.ethereum-france.com/) – az Ethereum mentén események szervezése, tartalomkészítés, beszélgetések +- [Ethereum.fr](https://ethereum.fr/) – Ethereummal kapcsolatos hírek és oktatás +- [BanklessFR](https://banklessfr.substack.com/) – Bankless hírlevél franciául +- [CryptoFR](https://cryptofr.com/category/44/ethereum-general) – kriptovalutával kapcsolatos fórum egy Ethereum aloldallal + +### Német {#de} + +- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) – A Solidity használata +- [Microsoft Learn (smart contracts)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) – Ethereum okosszerződések írása Solidity-val +- [Microsoft Learn (Ethereum networks)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) – az Ethereum-hálózatokhoz való kapcsolódás és azok telepítése +- [Microsoft Learn (blockchains)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) – a blokkláncfejlesztés első lépései + +### Héber {#he} + +- [Udi Wertheimer – Amit a bitcoin használók tanulhatnak az Ethereumtól](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/) +- [Omer Greismen (OpenZeppelin) - Hogyan akadályoztunk meg egy 15 milliárd dolláros okosszerződés meghackelését](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/) +- [Shy Datika (INX) - Tokenizálás és a kötvények jövője, beleértve azt, hogy vajon az Ethereum egy kötvény](https://www.cryptojungle.co.il/shy-datika-tokenization/) +- [Roy Confino (Lemonade) - Biztosítás az Ethereumon](https://www.cryptojungle.co.il/roy-confino-insurance/) +- [Idan Ofrat (Fireblocks) - Intézményi bevezetés](https://www.cryptojungle.co.il/idan-ofrat-fireblocks/) +- [Gal Weizman (MetaMask) - Mi az a MetaMask](https://www.cryptojungle.co.il/gal-weizman-metamask/) +- [Dror Aviely (Consensys) - Az Ethereum központja](https://www.cryptojungle.co.il/dror-aviely-ethereum-center/) +- [Nir Rozin - Egy kriptopunk élete](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/) +- [Adan Kedem - Játékok és a metaverzum](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/) +- [Uri Kolodny (Starkware) - Ethereum és a blokkláncrétegek](https://www.cryptojungle.co.il/uri-kolodny-starkware/) +- [Udi Wertheimer - Ethereum 2.0 vs. versenyzés](https://www.cryptojungle.co.il/udi-on-eth2/) +- [Ben Samocha (myself) - Ethereum 2.0 - egy lehetőség?](https://www.cryptojungle.co.il/etherurm2-week-summary/) +- [Alon Muroch (Bloxstaking) - Mi az Ethereum 2.0?](https://www.cryptojungle.co.il/alon-moroch-eth2/) +- [Eilon Aviv (Collider Ventures) - Mi sülhet el rosszul az Ethereum 2.0-val](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/) +- [Eilon Aviv (Collider Ventures) - Miért van szükség Ethereum 2.0-ra](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/) + +### Olasz {#it} + +- [Ethereum Italia](https://www.ethereum-italia.it/) – Ethereummal kapcsolatos oktatás, események és hírek, főleg az okosszerződésekről és a blokklánc-technológiáról +- [Ethereum Italia Podcast](https://www.ethereum-italia.it/podcast/) – Ethereum podcast olaszul +- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) – A Solidity használatának bemutatása +- [Microsoft Learn (Smart contracts)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) – Okosszerződések írása a Solidity-val +- [Microsoft Learn (dapps)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/) – felhasználói felület létrehozása decentralizált alkalmazásokkal + +### Japán {#ja} + +- [Japán virtuális és kriptoeszközök tőzsdei szövetsége](https://jvcea.or.jp/) +- [Japán kriptoeszközök üzleti szövetsége](https://cryptocurrency-association.org/) +- [A blokkláncfejlesztés első lépései – Oktatási anyagok | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) – a blokkláncba és fejlesztésbe való bevezetés az Ethereum platformon +- [Mastering Ethereum](https://www.oreilly.co.jp/books/9784873118963/) – Az Ethereum elsajátítása, japán verzió +- [Hands-On Smart Contract Development with Solidity and Ethereum](https://www.oreilly.co.jp/books/9784873119342/) – okosszerződés fejlesztés Solidity-val az Ethereumon japánul + +### Orosz {#ru} + +- [Cyber Academy](https://cyberacademy.dev) – Oktatási anyagok web3-fejlesztők számára +- [Forklog](https://forklog.com) - hírek és oktatási cikkek a kriptóról általában, a különféle blokkláncok létező technológiáiról és a jövőbeli fejlesztéseiről +- [BeInCrypto](https://ru.beincrypto.com) - hírek, kriptoárelemzések és nem technikai cikkek egyszerű magyarázatokkal mindenről, ami kripto + +### Spanyol {#es} + +- [Ethereum Madrid](https://ethereummadrid.com/) – blokklánc, DeFi és irányítási tanfolyamok, események és blog +- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) – Ethereum útmutató kezdőknek spanyolul +- [Tutoriales online](https://tutoriales.online/curso/solidity) – sajátítsa el a Solidity használatát és programozást az Ethereumon +- [Curso Introducción a Ethereum Development](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) – A Solidity alapjai, az első okosszerződések tesztelése és telepítése +- [Curso Introducción a Seguridad y Hacking en Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) – gyakori sebezhető pontok és biztonsági problémák a valódi okosszerződésekben +- [Curso Introducción a DeFi Development](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) – tanulja meg, hogyan működnek a DeFi okosszerződések a Solidity-ben és készítse el a saját automata Market Maker-ét +- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) – Nem technikai blokkláncok oktatása a kezdőtől a haladó szintig. Tudjon meg mindent a kriptóról és az Ethereumról. + +### Török {#tr} + +- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) – blokklánc- és kriptovaluta-központú tanfolyam +- [Az nagyszerű átnevezés: mi történt az Eth2-vel?](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) – török fordítása a blogpostnak, ami elmagyarázza az eth2-től való elmozdulást + +### Vietnámi {#vi} + +- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) – Ethereum, dapp-ok, tárcák áttekintése és gyakran ismételt kérdések +- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) – webplatform Ethereummal kapcsolatos hírekkel és oktatással +- [Coin68](https://coin68.com/ethereum-tieu-diem/) – kriptovaluta-portál Ethereummel kapcsolatos hírekkel és oktatási anyagokkal diff --git a/public/content/translations/hu/14) Community Pages/community/online/index.md b/public/content/translations/hu/14) Community Pages/community/online/index.md new file mode 100644 index 00000000000..f93382c295f --- /dev/null +++ b/public/content/translations/hu/14) Community Pages/community/online/index.md @@ -0,0 +1,75 @@ +--- +title: Online közösségek +description: A támogatói programok listája az egész Ethereum-ökoszisztémára vonatkozóan. +lang: hu +--- + +# Online közösségek {#online-communities} + +Ethereum rajongók százezrei gyűlnek össze ezeken az online fórumokon, hogy megosszák a híreket, megbeszéljék az új fejlesztéseket, megvitassák a technikai problémákat és elképzeljék a jövőt. + +## Listázási szabály {#listing-policy} + +A felsorolt közösségek integritásának és értékének megőrzése érdekében az ethereum.org szigorú irányelveket követ a jogosultság meghatározásakor: + +### Jogosultsági kritériumok {#eligibility-criteria} + +- **Relevancia**: A közösségnek közvetlenül az Ethereumhoz és annak ökoszisztémájához kell kapcsolódnia. +- **Aktivitási szint**: A közösségnek aktívnak kell lennie, rendszeres interakciókkal, hozzászólásokkal vagy párbeszédekkel. A szunnyadó vagy inaktív közösségek eltávolíthatók. +- **Inkluzivitás**: A közösségnek olyan barátságos környezetet kell kialakítania, amely tiszteletben tartja a sokszínűséget, és ösztönzi a különböző hátterű emberek részvételét. +- **Nem kereskedelmi fókusz**: A listázás közösségi célú terek, nem kereskedelmi vagy promóciós platformok számára elérhető. + +### Tartalmi irányelvek {#content-guidelines} + +- **Megfelelő tartalom**: A közösségeknek saját moderálási irányelvekkel kell rendelkezniük, elkerülve a levélszemetet, a gyűlöletbeszédet, a zaklatást vagy bármilyen olyan tartalmat, amely illegális tevékenységet népszerűsít. +- **Nyelv**: Bár az angol az elsődleges nyelv, más nyelvű közösségeket is bátorítunk, hogy jelentkezzenek, amíg fenntartják a befogadó és tiszteletteljes légkört. +- **Átláthatóság**: A közösség céljáról, szabályairól és moderátorairól világos információknak kell a tagok számára elérhetőnek lenniük. + +### További javaslatok {#other-recommendations} + +- **Elérhetőség**: A közösségi fórumoknak mindenki számára elérhetőnek kell lenniük bejelentkezés vagy regisztráció nélkül. +- **Meghívók a Discord-szerverre**: Ajánlott, hogy csak megbízható Discord-szerver meghívók kerüljenek fel az ethereum.org-ra. Ideális esetben ezek a meghívók a weboldal közösségi oldalára (pl. [ethglobal.com/discord](https://ethglobal.com/discord)) vagy egy hivatalos URL-re (pl. [discord.gg/ethstaker](https://discord.gg/ethstaker) vagy [discord.com/invite/ethstaker](https://discord.com/invite/ethstaker)) mutatnak. + +Ha úgy gondolja, hogy egy közösséget hozzá kellene adni vagy el kellene távolítani ezen irányelvek alapján, kérjük, [nyisson egy problémát a GitHub könyvtárban](https://github.com/ethereum/ethereum-org-website/issues). + + +## Fórumok {#forums} + +r/ethereum – minden az Ethereumról +r/ethfinance – az Ethereum pénzügyi része, beleértve a decentralizált pénzügyeket (DeFi) +r/ethdev – az Ethereum fejlesztéséről +r/ethtrader – trendek és piaci elemzések +r/ethstaker – az Ethereumon történő letétbe helyezés iránt érdeklődőknek +Fellowship of Ethereum Magicians – a technikai szabványok felé orientálódó közösség +Ethereum Stackexchange – az Ethereum-fejlesztők támogatása +Ethereum Research – a legbefolyásosabb üzenőfal a kriptogazdasági kutatáshoz + +## Csevegőszobák {#chat-rooms} + +Ethereum Cat Herders – projektmanagement-támogatás az Ethereum-fejlesztésekhez +Ethereum Hackers – az ETHGlobal által üzemeltetett Discord chat: online közösség az Ethereum hackereknek világszinten +CryptoDevs – Ethereum-fejlesztésre fókuszáló Discord-közösség +EthStaker Discord – közösségi vezetésű útmutatás, oktatás, támogatás és források a meglévő és lehetséges letéteseknek +Ethereum.org website team – beszélgessen az ethereum.org web fejlesztésről és dizájnról a közösség tagjaival +Matos Discord – web3 alkotói közösség, ahol a fejlesztők, az iparági vezetők és az Ethereum rajongók találkoznak. Szenvedélyünk a web3 fejlesztés, a dizájn és a kultúra. Jöjjön és építsen velünk. +Solidity Gitter – solidity fejlesztésről (Gitter) szóló csevegés +Solidity Matrix – solidity fejlesztősről (Matrix) szóló csevegés +Ethereum Stack Exchange *–kérdések és válaszok fóruma* +Peeranha *– decentralizált kérdések és válaszok fóruma* + +## YouTube és Twitter {#youtube-and-twitter} + +Ethereum Alapítvány – legyen napra kész az Ethereum Alapítvány újdonságaival kapcsolatban +@ethereum – az Ethereum Alapítvány hivatalos profilja +@ethdotorg – portál az Ethereumhoz, a növekvő globális közösségünk számára +Nagy befolyással bíró Ethereum Twitter-fiókok listája + + + + +
+ + Tudjon meg többet a DAO-król + +
+ diff --git a/public/content/translations/hu/14) Community Pages/community/research/index.md b/public/content/translations/hu/14) Community Pages/community/research/index.md new file mode 100644 index 00000000000..f5b68e42663 --- /dev/null +++ b/public/content/translations/hu/14) Community Pages/community/research/index.md @@ -0,0 +1,399 @@ +--- +title: Az Ethereum-kutatás aktív területei +description: Fedezze fel a nyitott kutatás különféle területeit, és hogy hogyan tud Ön is bekapcsolódni. +lang: hu +--- + +# Az Ethereum-kutatás aktív területei {#active-areas-of-ethereum-research} + +Az Ethereum egyik fontos erőssége, hogy egy aktív kutatási és mérnöki közösség folyamatosan fejleszti. Számtalan lelkes és képzett ember a világ minden táján szeretné belevetni magát a jelenlegi problémák megoldásába, de gyakran nem könnyű megtalálni, hogy mik is a problémák. Ez az oldal körvonalazza a legfontosabb aktív kutatási területeket. + +## Hogyan működik az Ethereum-kutatás {#how-ethereum-research-works} + +Az Ethereum-kutatás nyitott és transzparens, a [decentralizált tudomány (DeSci)](https://hackernoon.com/desci-decentralized-science-as-our-chance-to-recover-the-real-science) elveit testesítve meg. Olyan kultúrát követünk, amely a kutatási eszközöket és eredményeket olyan nyilvánossá és interaktívvá teszi, amennyire csak lehetséges, például a végrehajtható fájlok révén. Az Ethereum-kutatás gyorsan halad, az új eredményeket nyilvánosan posztolják és megvitatják az olyan fórumokon, mint az [ethresear.ch](https://ethresear.ch/), ahelyett hogy a hagyományos módon, a véleményezések után adnák ki a nyilvánosságnak. + +## Általános kutatási források {#general-research-resources} + +Minden téma gazdag forrásanyagban bővelkedik az [ethreser.ch](https://ethresear.ch) és az [Eth R&D Discord csatornán](https://discord.gg/qGpsxSA). Ezek a főbb helyek, ahol a kutatók megvitatják a legutóbbi ötleteket és fejlesztési lehetőségeket. + +Ezt a riportot 2022. májusában készítette a [DelphiDigital](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum), melyben kiváló áttekintést adnak az Ethereum fejlesztési tervéről (roadmap). + +## Finanszírozási források {#sources-of-funding} + +Ön is bekapcsolódhat az Ethereum-kutatásba, és kereshet vele! Például az [Ethereum Alapítvány](/foundation/) nemrég adott [akadémikus finanszírozási támogatásokat](https://esp.ethereum.foundation/academic-grants). Az [Ethereum-támogatások oldalon](/community/grants/) megtalálhatja az aktív és jövőbeli finanszírozási lehetőségeket. + +## Protokollkutatás {#protocol-research} + +A protokollkutatás az Ethereum alaprétegével foglalkozik – szabályok összessége, hogy a csomópontok hogyan kapcsolódnak, kommunikálnak, cserélik és tárolják az adatot, és hogyan jutnak konszenzusra a blokklánc státuszát illetően. A protokollkutatás két fő kategóriára oszlik: konszenzus és végrehajtási. + +### Konszenzus {#consensus} + +A konszenzuskutatás az [Ethereum proof-of-stake mechanizmusával](/developers/docs/consensus-mechanisms/pos/) foglalkozik. Néhány példa: + +- sebezhető pontok azonosítása és befedése; +- a kriptogazdasági biztonság mérése; +- a kliensbevezetések biztonságának vagy teljesítményének növelése; +- és könnyű kliensek fejlesztése. + +Emellett a jövőbe előretekintő kutatások, a protokoll alapvető újratervezése, mint amilyen az egy sloton belüli véglegesedés is, jelentős fejlődést tudnának hozni az Ethereum számára. Továbbá a peer-to-peer hálózat hatékonysága, biztonsága és monitorozása a konszenzus kliensek között is fontos terület. + +#### Háttérolvasmányok {#background-reading} + +- [Bevezetés a proof-of-stake mechanizmusba](/developers/docs/consensus-mechanisms/pos/) +- [Casper-FFG dokumentáció](https://arxiv.org/abs/1710.09437) +- [Casper-FFG magyarázat](https://arxiv.org/abs/1710.09437) +- [Gasper dokumentáció](https://arxiv.org/abs/2003.03052) + +#### Jelenlegi kutatás {#recent-research} + +- [Ethresear.ch konszenzus](https://ethresear.ch/c/consensus/29) +- [Elérhetőségi/véglegességi dilemma](https://arxiv.org/abs/2009.04987) +- [Egy sloton belüli véglegesség](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259) +- [Javaslattevő-építő elkülönítés](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) + +### Végrehajtás {#execution} + +A végrehajtási réteg a tranzakciók feldolgozását végzi, az [Ethereum virtuális gépet (EVM)](/developers/docs/evm/) futtatja és végrehajtási csomagokat küld a konszenzusrétegnek. Számos aktív kutatási terület van, beleértve: + +- a könnyű kliens támogatás kiépítése; +- gáz korlátok kutatása; +- és új adatstruktúrák (pl. Verkle-fák) beépítése. + +#### Háttérolvasmányok {#background-reading-1} + +- [Bevezetés az EVM-be](/developers/docs/evm) +- [Ethresear.ch konszenzusréteg](https://ethresear.ch/c/execution-layer-research/37) + +#### Jelenlegi kutatás {#recent-research-1} + +- [Adatbázis-optimalizálások](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md) +- [Státuszlejárat](https://notes.ethereum.org/@vbuterin/state_expiry_eip) +- [A státuszlejárathoz vezető út](https://hackmd.io/@vbuterin/state_expiry_paths) +- [Verkle és státuszlejárat-javaslat](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal) +- [Előzményadatok kezelése](https://eips.ethereum.org/EIPS/eip-4444) +- [Verkle-fák](https://vitalik.eth.limo/general/2021/06/18/verkle.html) +- [Adatelérhetőségi mintavétel](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding) + +## Kliensfejlesztés {#client-development} + +Az Ethereum kliensek az Ethereum protokoll implementációi. A kliensfejlesztés teszi lehetővé, hogy a protokoll kutatás eredményei valósággá váljanak azáltal, hogy ezekbe a kliensekbe beépítik azokat. A kliens fejlesztés magába foglalja a kliensspecifikációk frissítését és specifikus implementációk beépítését. + +Az Ethereum-csomópontok két szoftvert futtatnak: + +1. a konszenzuskliens a blokklánc elejét/fejét trekkeli, elterjeszti a blokkokat (pletyka) és kezeli a konszenzus logikáját +2. a végrehajtási kliens az Ethereum virtuális gépet támogatja, valamint a tranzakciókat és okosszerződéseket futtatja + +Bővebb információkért tekintse át a [node-ok és kliensek oldalt](/developers/docs/nodes-and-clients/), ahol a jelenlegi kliensbevezetések listáját is megtalálja. Az Ethereum-fejlesztésekről is találhat információkat az [Ethereum története oldalon](/history/). + +### Végrehajtási kliensek {#execution-clients} + +- [Végrehajtásikliens-specifikáció](https://github.com/ethereum/execution-specs) +- [Végrehajtási API-specifikáció](https://github.com/ethereum/execution-apis) + +### Konszenzuskliensek {#consensus-clients} + +- [Konszenzuskliens-specifikáció](https://github.com/ethereum/consensus-specs) +- [Beacon API-specifikáció](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot) + +## Skálázás és teljesítmény {#scaling-and-performance} + +Az Ethereum skálázása egy hatalmas kutatási terület. A jelenlegi megközelítések felölelik a rollupokba történő tranzakciógyűjtést, ami az adatblobok használatával rendkívül olcsó lesz a felhasználók számára. A skálázás áttekintését megtalálja a [skálázási oldalon](/developers/docs/scaling). + +### Második blokkláncréteg (L2) {#layer-2} + +Jelenleg több második blokkláncréteg (L2) protokoll létezik, ami az Ethereumot skálázza, amelyek különféle technikákkal csomagolják össze a tranzakciókat és biztosítják azokat az L1 rétegen. Ez egy gyorsan fejlődő téma rengeteg kutatási és fejlesztési potenciállal. + +#### Háttérolvasmányok {#background-reading-2} + +- [Bevezetés az L2-be](/layer-2/) +- [Polynya: rollupok, adatelérhetőségi rétegek (DA) és moduláris láncok](https://polynya.medium.com/rollups-data-availability-layers-modular-blockchains-introductory-meta-post-5a1e7a60119d) + +#### Jelenlegi kutatás {#recent-research-2} + +- [A helyes sorbarendezés a szekvenszereknél az Arbitrumnál](https://eprint.iacr.org/2021/1465) +- [ethresear.ch L2](https://ethresear.ch/c/layer-2/32) +- [Rollupra fókuszáló ütemterv](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) +- [L2Beat](https://l2beat.com/) + +### Hidak {#bridges} + +Az L2 az egyik területe még több kutatást és fejlesztést igényel – ez pedig nem más, mint a hidak biztonsága és teljesítménye. Ez a különböző L2 megoldások közötti hidakra, valamint az L1 és L2 közötti hidakra vonatkozik. Fontos terület, mert gyakori célpontja a támadásoknak. + +#### Háttérolvasmányok {#background-reading-3} + +- [Bevezetés a blokklánchidak működésébe](/bridges/) +- [Vitalik a hidakról](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) +- [Blokklánc-hidak cikk](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) +- [A hidakba ragadt érték](https://dune.com/eliasimos/Bridge-Away-\(from-Ethereum\)) + +#### Jelenlegi kutatás {#recent-research-3} + +- [Hidak validálása](https://stonecoldpat.github.io/images/validatingbridges.pdf) + +### Szilánkolás (sharding) {#sharding} + +Az Ethereum-blokklánc shardingja már régóta része a terveknek. Míg az új skálázási megoldások, mint a Danksharding, mostanában kerülnek a középpontba. + +A teljes Danksharding előzménye, a Proto-Danksharding a Cancun-Deneb („Dencun”) hálózati frissítéssel került bevezetésre. + +[További információ a Dencun hálózatfrissítésről](/roadmap/dencun/) + +#### Háttérolvasmányok {#background-reading-4} + +- [Proto-Danksharding jegyzetek](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) +- [Bankless Danksharding video](https://www.youtube.com/watch?v=N5p0TB77flM) +- [Ethereum sharding kutatási összefoglaló](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view) +- [Danksharding (Polynya)](https://polynya.medium.com/danksharding-36dc0c8067fe) + +#### Jelenlegi kutatás {#recent-research-4} + +- [EIP-4844: Proto-Danksharding](https://eips.ethereum.org/EIPS/eip-4844) +- [Vitalik a shardingról és az adatelérhetőségi mintavételről](https://hackmd.io/@vbuterin/sharding_proposal) + +### Hardver {#hardware} + +A [csomópontok futtatása](/developers/docs/nodes-and-clients/run-a-node/) szerényebb hardvereken alapvető lenne az Ethereum decentralizáltan tartásához. Ezért a hardverszükségletek minimalizálása is fontos kutatási terület. + +#### Háttérolvasmányok {#background-reading-5} + +- [Ethereum az ARM-ról](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) + +#### Jelenlegi kutatás {#recent-research-5} + +- [ecdsa az FPGA-król](https://ethresear.ch/t/does-ecdsa-on-fpga-solve-the-scaling-problem/6738) + +## Biztonság {#security} + +A biztonság nagyon kiterjedt téma, beleértjük a szemetelés (spam) és család elleni védelmet, a tárca-, hardver- és kriptogazdasági biztonságot, az alkalmazások és kliensszoftverekben való hibakeresést és ezek tesztelését, valamint a kulcskezelést is. E területek mélyebb feltárása hozzájárul a szélesebb körű alkalmazáshoz. + +### Kriptográfia & ZKP {#cryptography--zkp} + +A zero-knowledge bizonyítékok (ZKP) és a kriptográfia kritikus a személyes adatok védelme és a biztonság szempontjából. A zero-knowledge egy viszonylag új, de gyorsan fejlődő ág, számos nyitott kutatási és fejlesztési lehetőségekkel. Néhány kiemelt lehetőség, például a hatékonyabb implementációja a [Keccak hashing algoritmusnak](https://hackmd.io/sK7v0lr8Txi1bgION1rRpw?view#Overview), jobb polinomiális kommitmentek találása vagy az ecdsa nyilvános kulcsok és aláírás ellenőrző hálózatok költségének csökkentése. + +#### Háttérolvasmányok {#background-reading-6} + +- [0xparc blog](https://0xparc.org/blog) +- [zkp.science](https://zkp.science/) +- [Zero Knowledge podcast](https://zeroknowledge.fm/) + +#### Jelenlegi kutatás {#recent-research-6} + +- [Jelenlegi előrehaladás az elliptikus görbe kriptográfiában](https://ethresear.ch/t/the-ec-fft-algorithm-without-elliptic-curve-and-isogenies/11346) +- [Ethresear.ch ZK](https://ethresear.ch/c/zk-s-nt-arks/13) + +### Tárcák {#wallets} + +Az Ethereum-tárcák lehetnek böngészőkiterjesztések, asztali gépen és mobilon lévő alkalmazások vagy okosszerződések az Ethereumon. Aktív kutatás folyik a hagyományos módon visszaállítható tárcák területén, hogy az egyéni felhasználói kulcs kezelése kevesebb kockázatot jelentsen. A tárcák fejlődéséhez kapcsolódik az éppen születő kutatási terület a számlaabsztrakciók alternatív formáiról. + +#### Háttérolvasmányok {#background-reading-7} + +- [Bevezetés a tárcákba](/wallets/) +- [Bevezetés a tárcabiztonságba](/security/) +- [ethresear.ch biztonság](https://ethresear.ch/tag/security) +- [EIP-2938 Számlaabsztrakció](https://eips.ethereum.org/EIPS/eip-2938) +- [EIP-4337 Számlaabsztrakció](https://eips.ethereum.org/EIPS/eip-4337) + +#### Jelenlegi kutatás {#recent-research-7} + +- [Validációfókuszú okosszerződéses tárcák](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) +- [A számlák jövője](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) +- [EIP-3074 AUTH és AUTHCALL opkódok](https://eips.ethereum.org/EIPS/eip-3074) +- [Kód publikálása egy EOA címen](https://eips.ethereum.org/EIPS/eip-5003) + +## Közösség, oktatás és a felhasználók elérése {#community-education-and-outreach} + +Az új felhasználók bevezetése az Ethereumra új oktatási anyagokat igényel és új megközelítéseket az emberek elérésére. Ezek lehetnek blogbejegyzések és cikkek, könyvek, podcastok, mémek, oktatási anyagok, események és bármi más, ami közösséget épít, fogadja az újonnan érkezőket és tanítja őket az Ethereumról. + +### UX/UI {#uxui} + +Ahhoz, hogy több embert lehessen bevezetni az Ethereum világába, fejleszteni kell a felhasználói élményt / kezelőfelületet (UX/UI). Ehhez a dizájnerek és termékszakértők meg kell vizsgálják a tárcák és alkalmazások dizájnját. + +#### Háttérolvasmányok {#background-reading-8} + +- [Ethresear.ch UX/UI](https://ethresear.ch/c/ui-ux/24) + +#### Jelenlegi kutatás {#recent-research-8} + +- [Web3 tervezés Discord](https://discord.gg/FsCFPMTSm9) +- [Web3 tervezési elvek](https://www.web3designprinciples.com/) +- [Ethereum Magicians UX egyeztetések](https://ethereum-magicians.org/t/og-council-ux-follow-up/9032/3) + +### Gazdaság {#economics} + +Az Ethereumban a gazdasági kutatás nagyjából két megközelítés mentén zajlik: a mechanizmusok biztonságának validálása, melyek a gazdasági ösztönzőkön alapulnak (mikroökonómia), valamint a protokoll, az alkalmazások és a felhasználók közötti értékáramlás elemzése (makroökonómia). Összetett kriptogazdasági tényezők állnak fenn az Ethereum saját eszközei (ether) és a rá épülő tokenek (mint NFT-k és ERC20 tokenek) kapcsán. + +#### Háttérolvasmányok {#background-reading-9} + +- [Robust Incentives Group](https://ethereum.github.io/rig/) +- [ETHconomics workshop a Devconnect-en](https://www.youtube.com/playlist?list=PLTLjFJ0OQOj5PHRvA2snoOKt2udVsyXEm) + +#### Jelenlegi kutatás {#recent-research-9} + +- [EIP1559 empírikus elemzése](https://arxiv.org/abs/2201.05574) +- [A kínálati egyensúly megközelítése](https://ethresear.ch/t/circulating-supply-equilibrium-for-ethereum-and-minimum-viable-issuance-during-the-proof-of-stake-era/10954) +- [A MEV tényleges mennyisége: mennyire sötét az erdő?](https://arxiv.org/abs/2101.05511) + +### Blokkméret és díjpiacok {#blockspace-fee-markets} + +A blokkméretpiacok irányítják, hogy a felhasználó tranzakciói közvetlenül az Ethereumban (L1) vagy hidakkal összekötött hálózatokon keresztül (pl. rollupok (L2)) kerülnek-e be a blokkláncba. Az Ethereumon a tranzakciók a díjpiacra kerülnek, melyet az EIP-1559 mentén vezettek be a protokollba, hogy ne lehessen szemeteléssel (spam) és ártorlódással veszélyeztetni a láncot. Mindkét rétegen a tranzakciók externáliákat hoznak létre, melyet maximálisan kinyerhető értéknek (MEV) neveznek, és új piaci struktúrát eszközölt, hogy ezt megszerezze vagy kezelje. + +#### Háttérolvasmányok {#background-reading-10} + +- [A tranzakciós díj mechanizmusterve az Ethereum blokkláncra: Az EIP-1559 gazdasági elemzése (Tim Roughgarden, 2020.)](https://timroughgarden.org/papers/eip1559.pdf) +- [EIP-1559 szimulációk (Robust Incentives Group)](https://ethereum.github.io/abm1559) +- [Rollupok gazdasága az első elvektől](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url) +- [Flash Boys 2.0: beelőzés (frontrunning), tranzakcióátrendezés és konszenzusinstabilitás a decentralizált tőzsdéken](https://arxiv.org/abs/1904.05234) + +#### Jelenlegi kutatás {#recent-research-10} + +- [Multidimenzionális EIP-1559 videoprezentáció](https://youtu.be/QbR4MTgnCko) +- [Területek közötti MEV](http://arxiv.org/abs/2112.01472) +- [MEV-aukciók](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788) + +### Proof-of-stake ösztönzők {#proof-of-stake-incentives} + +A validátorok az Ethereum saját eszközét (ether) használják fedezetként a rosszhiszemű viselkedés ellen. Ennek kriptogazdasága határozza meg a hálózat biztonságát. A szofisztikált validátorok talán képesek kihasználni az ösztönző réteg finom részleteit, hogy támadást indítsanak. + +#### Háttérolvasmányok {#background-reading-11} + +- [Ethereum gazdasági mesterkurzus és gazdasági modell](https://github.com/CADLabs/ethereum-economic-model) +- [A PoS ösztönzők szimulációja (Robust Incentives Group)](https://ethereum.github.io/beaconrunner/) + +#### Jelenlegi kutatás {#recent-research-11} + +- [A tranzakciók cenzúrának való ellenállásának növelése a javaslattevő/építő elkülönítéssel (PBS)](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ) +- [Három támadás a PoS Ethereumon](https://arxiv.org/abs/2110.10086) + +### Likvid letétbe helyezés és derivatívák {#liquid-staking-and-derivatives} + +A likvid letétbe helyezés lehetővé teszi, hogy a 32 ETH-nél kevesebbel rendelkező felhasználók is részesüljenek jutalomban azáltal, hogy az ETH-t átváltják letétbe helyezett ethert képviselő tokenre, amit a decentralizált pénzügyekben (DeFi) használni lehet. Ugyanakkor az ezzel kapcsolatos ösztönzők és piaci dinamizmusok még feltárásra várnak, az Ethereum biztonságra gyakorolt hatásukkal együtt (pl. centralizáció kockázata). + +#### Háttérolvasmányok {#background-reading-12} + +- [Ethresear.ch likvid letétbe helyezés](https://ethresear.ch/search?q=liquid%20staking) +- [Lido: A bizalomigénymentes letétbe helyezéshez vezető út az Ethereumon](https://blog.lido.fi/the-road-to-trustless-ethereum-staking/) +- [Rocket Pool: Bevezető a letétbe helyezési protokollba](https://medium.com/rocket-pool/rocket-pool-staking-protocol-part-1-8be4859e5fbd) + +#### Jelenlegi kutatás {#recent-research-12} + +- [A Lido-tól való visszavonások kezelése](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873) +- [A visszavonási hitelesítő adatok](https://ethresear.ch/t/withdrawal-credential-rotation-from-bls-to-eth1/8722) +- [A likvid letéti derivatívák kockázatai](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## Tesztelés {#testing} + +### Formális ellenőrzés {#formal-verification} + +A formális ellenőrzés egy olyan kód, amely igazolja, hogy az Ethereum konszenzusspecifikációi helyesek, és nincs bennük hiba. A specifikációnak van egy végrehajtható verziója, melyet Python nyelven írtak, és ami fenntartást és fejlesztést igényel. A kutatás segíthet feltárni ennek a specifikációimplementációnak a fejlesztési lehetőségeit, és eszközöket biztosíthat, hogy az ellenőrzés robusztusabb legyen. + +#### Háttérolvasmányok {#background-reading-13} + +- [Bevezetés a formális ellenőrzésbe](https://ptolemy.berkeley.edu/projects/embedded/research/vis/doc/VisUser/vis_user/node4.html) +- [Formális ellenőrzés (Intel)](https://www.cl.cam.ac.uk/~jrh13/papers/mark10.pdf) + +#### Jelenlegi kutatás {#recent-research-13} + +- [A letéti szerződés formális ellenőrzése](https://github.com/runtimeverification/deposit-contract-verification) +- [A Beacon-lánc specifikációjának formális ellenőrzése](https://github.com/runtimeverification/deposit-contract-verification) + +## Adattudomány és elemzés {#data-science-and-analytics} + +Több adatelemzési eszközre és irányítópultra van szükség, hogy részletes adatokat nyújtson az Ethereum működéséről és a hálózat egészségéről. + +### Háttérolvasmányok {#background-reading-14} + +- [Dune elemzések](https://dune.com/browse/dashboards) +- [Kliensdiverzitási irányítópult](https://clientdiversity.org/) + +#### Jelenlegi kutatás {#recent-research-14} + +- [Robust Incentives Group adatelemzése](https://ethereum.github.io/rig/) + +## Alkalmazások és eszközök {#apps-and-tooling} + +Az alkalmazási réteg a programok kiterjedt ökoszisztémáját támogatja, melyek tranzakciókat hajtanak végre az Ethereum alaprétegén. A fejlesztői csapatok állandón új utakat találnak az Ethereum felhasználására, hogy átjárható, engedélymentes és cenzúrának ellenálló alkalmazásokat készítsenek, egyrészt a fontos web2 eszközök mását, másrészt teljesen új web3-koncepciókat. Eközben olyan új eszközöket fejlesztenek, melyekkel a dappok Ethereumra való építése kevésbé bonyolulttá válik. + +### DeFi {#defi} + +A decentralizált pénzügyek (DeFi) az egyik elsődleges alkalmazáscsoport, melyet az Ethereumra építettek. Ennek célja az egymásra illeszthető „pénz építőkockák” létrehozása, amellyel a felhasználók tárolnak, küldenek, kölcsönöznek, kölcsönvesznek és befektetnek kriptoeszközöket az okosszerződések használatával. A DeFi egy gyorsan fejlődő terület, mely folyamatosan megújul. Folyamatos igény van a biztonságos, hatékony és elérhető protokollokra. + +#### Háttérolvasmányok {#background-reading-15} + +- [DeFi](/defi/) +- [Coinbase: Mi az a DeFi?](https://www.coinbase.com/learn/crypto-basics/what-is-defi) + +#### Jelenlegi kutatás {#recent-research-15} + +- [Decentralizált pénzügyek, centralizált tulajdonjog?](https://arxiv.org/pdf/2012.09306.pdf) +- [Optimism: A sub-dollár tranzakciókhoz vezető út](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) + +### DAO-k {#daos} + +Az Ethereum képes arra, hogy decentralizált módon irányítson a decentralizált autonóm szervezetek (DAO) segítségével. Sok aktív kutatás folyik, hogy hogyan lehetne fejleszteni a DAO-kat az Ethereumon, felhasználni azokat az irányítás fejlettebb formáira, mint egy minimális bizalmat igénylő, koordinációs eszköz, mely nagyban kiterjeszti az emberek opcióit a hagyományos szervezeteken túlra. + +#### Háttérolvasmányok {#background-reading-16} + +- [Bevezetés a DAO-kba](/dao/) +- [Dao Collective](https://daocollective.xyz/) + +#### Jelenlegi kutatás {#recent-research-16} + +- [A DAO ökoszisztéma térképe](https://www.researchgate.net/publication/358694594_Mapping_out_the_DAO_Ecosystem_and_Assessing_DAO_Autonomy) + +### Fejlesztői eszközök {#developer-tools} + +Az Ethereum-fejlesztők eszközei gyorsan fejlődnek. Ezen a területen is sok aktív kutatás folyik. + +#### Háttérolvasmányok {#background-reading-17} + +- [Eszközök programozási nyelv szerint](/developers/docs/programming-languages/) +- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) +- [Konszenzusfejlesztői eszközök listája](https://github.com/ConsenSys/ethereum-developer-tools-list) +- [Tokenszabványok](/developers/docs/standards/tokens/) +- [CryptoDevHub: EVM eszközök](https://cryptodevhub.io/wiki/ethereum-virtual-machine-tools) + +#### Jelenlegi kutatás {#recent-research-17} + +- [Eth R&D Discord konszenzus eszközök csatornája](https://discordapp.com/channels/595666850260713488/746343380900118528) + +### Orákulumok {#oracles} + +Az orákulumok importálják be a láncon kívüli adatokat a blokkláncra egy engedélymentes és decentralizált módon. Mivel ez az adat a láncon belül van, ezért a dappok képesek lekövetni a világ változásait, mint a valódi eszközök árfluktuációja, a láncon kívüli alkalmazások adatai vagy akár az időjárásváltozás. + +#### Háttérolvasmányok {#background-reading-18} + +- [Bevezetés az orákulumokba](/developers/docs/oracles/) + +#### Jelenlegi kutatás {#recent-research-18} + +- [A blokklánc-orákulumok áttekintése](https://arxiv.org/pdf/2004.07140.pdf) +- [Chainlink fehérkönyv](https://chain.link/whitepaper) + +### Alkalmazások biztonsága {#app-security} + +Az Ethereum elleni támadások általában az egyéni alkalmazások gyenge pontjait használják ki, nem a protokollét. A támadók és az alkalmazásfejlesztők egy fegyverkezési versenybe kényszerültek, hogy új támadásokat és új védekezéseket fejlesszenek. Ebből az következik, hogy mindig fontos a kutatás és fejlesztés, hogy az alkalmazások biztonságban legyenek. + +#### Háttérolvasmányok {#background-reading-19} + +- [Féreglyuk-kihasználási jelentés](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/) +- [Az Ethereum-szerződések meghackelésének vizsgálatai](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191) +- [Rekt hírek](https://twitter.com/RektHQ?s=20\&t=3otjYQdM9Bqk8k3n1a1Adg) + +#### Jelenlegi kutatás {#recent-research-19} + +- [ethresear.ch alkalmazások](https://ethresear.ch/c/applications/18) + +### Technológiai stack {#technology-stack} + +A teljes Ethereum-technológiai köteg decentralizálása is egy érdekes kutatási terület. Jelenleg az Ethereum dappoknak gyakran vannak centralizációs pontjai, mert központi eszközökön vagy infrastruktúrán alapulnak. + +#### Háttérolvasmányok {#background-reading-20} + +- [Ethereum stack](/developers/docs/ethereum-stack/) +- [Coinbase: Bevezetés a web3 stackbe](https://blog.coinbase.com/a-simple-guide-to-the-web3-stack-785240e557f0) +- [Bevezetés az okosszerződésekbe](/developers/docs/smart-contracts/) +- [Bevezetés a decentralizált tárhelybe](/developers/docs/storage/) + +#### Jelenlegi kutatás {#recent-research-20} + +- [Okosszerződések összeilleszthetősége](/developers/docs/smart-contracts/composability/) diff --git a/public/content/translations/hu/14) Community Pages/community/support/index.md b/public/content/translations/hu/14) Community Pages/community/support/index.md new file mode 100644 index 00000000000..707142b32f3 --- /dev/null +++ b/public/content/translations/hu/14) Community Pages/community/support/index.md @@ -0,0 +1,105 @@ +--- +title: Ethereum támogatás +description: Kapjon támogatást az Ethereum-ökoszisztémában. +lang: hu +--- + +# Ethereum támogatás {#support} + +## Hivatalos Ethereum ügyfélszolgálat {#official-support} + +Egy hivatalos Ethereum ügyfélszolgálatot keres? Tudnia kell, hogy az Ethereum decentralizált. Nincs központi szervezet, entitás vagy ember, aki birtokolná az Ethereumot, ezért nincs hivatalos ügyfélszolgálat vagy támogatói csapat sem. + +Ezt azért is fontos megérteni, mert **bárki jelentkezik Önnél, mint hivatalos ügyfélszolgálatos, az csak csaló lehet!** A csalókkal szemben a legjobb védekezés, ha Ön mindig jól informált és komolyan veszi a saját biztonságát. + + + Ethereum-biztonság és átverés elleni védelem + + + + Ismerje meg az Ethereum alapjait + + +Amellett, hogy nincs hivatalos ügyfélszolgálat, számtalan csoport, közösség és projekt szeretne Önnek segíteni, illetve rengeteg hasznos információ és forrás áll rendelkezésre ezeken az oldalakon. További kérdése van? Csatlakozzon az [ethereum.org Discord](/discord/) csatornához, és megpróbálunk segíteni. + +## Gyakran ismételt kérdések {#faq} + +### Rossz tárcába küldtem az ETH-t {#wrong-wallet} + +Az Ethereumon küldött tranzakció visszavonhatatlan. Sajnos, ha rossz pénztárcába küldte az ETH-t, nincs mód arra, hogy visszaszerezze ezeket az összegeket. Nincs központi szervezet, entitás vagy személy, aki birtokolja az Ethereumot, tehát nincs, aki visszafordítaná a tranzakciót. Ezért létfontosságú, hogy mindig ellenőrizze a tranzakcióit, mielőtt elküldi azokat. + +### Hogyan juthatok hozzá az Ethereum-ajándékhoz? {#giveaway-scam} + +Az Ethereum ajándékok csalások, amik el akarják lopni az Ön ETH-ját. Ne essen kísértésbe az olyan ajánlatoktól, amelyek túl szépnek tűnnek ahhoz, hogy igazak legyenek – ha az ETH-t egy ajándékcímre küldi, akkor nem kap ajándékot, és nem tudja visszaszerezni a pénzét. + +[Bővebben a csalás elkerüléséről](/security/#common-scams) + +### A tranzakcióm beragadt {#stuck-transaction} + +A tranzakciók az Ethereumon néha várakoznak, ha a tranzakciós díj alacsonyabb, mint amit épp megkíván a hálózati kereslet. Számos tárcában lehetősége van újraküldeni ugyanazt a tranzakciót egy magasabb díjjal, hogy az át tudjon menni. Alternatívaként leállíthatja a függőben lévő tételt úgy, hogy egy tranzakciót küld a címéről és ugyanazt a Nonce-t használja, mint a függőben lévő tételnél. + +[Hogyan lehet felgyorsítani vagy leállítani a függő tranzakciókat a MetaMaskon](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction) + +[Hogyan lehet leállítani a függőben lévő Ethereum-tranzakciókat](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/) + +### Hogyan lehet Ethereumot bányászni? {#mining-ethereum} + +Az Ethereum bányászat többé nem elérhető. A bányászat leállt, amikor az Ethereum [proof-of-work](/glossary/#pow)-ről [proof-of-stake](/glossary/#pos)-re váltott. Ehelyett validátorok vannak. Bárki [tétbe helyezhet](/glossary/#staking) az ETH-t, és tétjutalmat kaphat a hálózat biztonságát szolgáló érvényesítő szoftver futtatásáért. + +### Hogyan legyek staker / futtathatok validátort? {#how-to-stake} + +A validátornak 32 ETH-t kell letétbe helyezni az Ethereum letéti szerződésben és fel kell állítani egy csomópontot. További információk [a letétbehelyezésről szóló oldalon](/staking) és a[letéti launchpaden](https://launchpad.ethereum.org/) érhetők el. + +## Dapp-fejlesztés {#building-support} + +A fejlesztés tele van kihívásokkal. Alább található néhány fejlesztőket támogató platform, tapasztalt Ethereum-fejlesztőkkel. + +- [Alchemy University](https://university.alchemy.com/#starter_code) +- [CryptoDevs discord](https://discord.com/invite/5W5tVb3) +- [Ethereum StackExchange](https://ethereum.stackexchange.com/) +- [StackOverflow](https://stackoverflow.com/questions/tagged/web3) +- [Web3 University](https://www.web3.university/) +- [LearnWeb3](https://discord.com/invite/learnweb3) + +Emellett dokumentációkat és fejlesztői útmutatókat is talál az [Ethereum fejlesztői források](/developers/) szekcióban. + +### Eszközök {#dapp-tooling} + +A kérdése egy bizonyos eszközhöz, projekthez vagy könyvtárhoz kapcsolódik? A legtöbb projekt működtet csevegőszervereket vagy fórumokat ilyen célból. + +Néhány népszerű példa: + +- [Solidity](https://gitter.im/ethereum/solidity) +- [ethers.js](https://discord.gg/6jyGVDK6Jx) +- [web3.js](https://discord.gg/GsABYQu4sC) +- [Hardhat](https://discord.gg/xtrMGhmbfZ) +- [Alchemy](http://alchemy.com/discord) +- [Tenderly](https://discord.gg/fBvDJYR) + +## Csomópontok futtatása {#node-support} + +Ha Ön csomópontot vagy validátort futtat, a következő közösségek segítenek belevágni. + +- [EthStaker discord](https://discord.gg/ethstaker) +- [EthStaker reddit](https://www.reddit.com/r/ethstaker) + +Az Ethereum klienseket építő csapatok is dedikált, nyilvános fórumokkal rendelkeznek, ahol kérdezni lehet. + +### Végrehajtási kliensek {#execution-clients} + +- [Geth](https://discord.gg/FqDzupGyYf) +- [Nethermind](https://discord.gg/YJx3pm8z5C) +- [Besu](https://discord.gg/p8djYngzKN) +- [Erigon](https://github.com/ledgerwatch/erigon/issues) +- [Reth](https://github.com/paradigmxyz/reth/discussions) + +### Konszenzusos kliensek {#consensus-clients} + +- [Prysm](https://discord.gg/prysmaticlabs) +- [Nimbus](https://discord.gg/nSmEH3qgFv) +- [Lighthouse](https://discord.gg/cyAszAh) +- [Teku](https://discord.gg/7hPv2T6) +- [Lodestar](https://discord.gg/aMxzVcr) +- [Grandine](https://discord.gg/H9XCdUSyZd) + +Tudja meg, hogy [futtathat csomópontot](/developers/docs/nodes-and-clients/run-a-node/). diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" new file mode 100644 index 00000000000..abb713e7ba3 --- /dev/null +++ "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" @@ -0,0 +1,80 @@ +--- +title: Ethereum archív csomópont +description: Az archív csomópontok áttekintése +lang: hu +sidebarDepth: 2 +--- + +Az archív csomópont az Ethereum-kliens egy fajtája, melynek lényege, hogy az összes státuszt tárolja. Ez egy hasznos eszköz bizonyos célokra, de nehezebb kezelni, mint egy teljes csomópontot. + +## Előfeltételek {#prerequisites} + +Meg kell érteni az [Ethereum-csomópont](/developers/docs/nodes-and-clients/), [architektúráját](/developers/docs/nodes-and-clients/node-architecture/), a [szinkronizációs stratégiáig](/developers/docs/nodes-and-clients/#sync-modes), [futtatási gyakorlatát](/developers/docs/nodes-and-clients/run-a-node/) és [használatukat](/developers/docs/apis/json-rpc/). + +## Mi is az az archív csomópont + +Az archív csomópont lényegéhez meg kell érteni, hogy mit jelent a státusz. Az Ethereumot úgy is nevezhetjük, hogy _tranzakcióalapú státuszgép_. Számlákból áll, és amikor az alkalmazások tranzakciókat hajtanak végre, akkor megváltozik ezek státusza. Az a globális adat, mely lefedi az összes számla- és szerződésinformációt, egy státusznak nevezett fastruktúrájú adatbázisban tárolódik. Ezt a végrehajtási réteg (EL) kliense kezeli, és a következő adatokat tárolja el: + +- Számlaegyenlegek és nonce-ok +- Szerződéskód és tárhely +- Konszenzussal kapcsolatos adatok, pl. a letétbe helyezési szerződés + +A hálózattal való interakció, az új blokkok ellenőrzése és létrehozása végett az Ethereum-klienseknek követniük kell a legutóbbi változásokat (a lánc elejét), így ezért a jelenlegi státuszt is. A teljes csomópontként konfigurált végrehajtási réteg kliense ellenőrzi és követi a hálózat legutóbbi státuszát, de csak néhány státuszt kap el, pl. a legutóbbi 128 blokkét, így képes kezelni a láncátrendezéseket és gyors hozzáférést tud biztosítani a legutóbbi adatokhoz. A legfrissebb státuszra van szüksége minden kliensnek, hogy ellenőrizze a bejövő tranzakciókat és használja a hálózatot. + +Úgy is felfoghatjuk a státuszt, mint egy pénzügyi rendszer pillanatfelvétele egy adott blokknál, az archív pedig a történeti visszajátszás. + +Az előzménystátuszokat biztonsággal meg lehet vágni, mert azok nem szükségesek a hálózat működéséhez, és a kliens számára haszontalan lenne a nem releváns adatok tárolása. Azokat a státuszokat, melyek egy bizonyos blokknál korábban keletkeztek (pl. 128 blokkal korábban), egyszerűen törlik. A teljes csomópontok csak blokklánc-előzményadatokat (blokkok és tranzakciók) tartanak meg, valamint esetenként korábbi pillanatfelvételeket is, amelyek alapján újragenerálhatják a régebbi státuszokat, ha azokra szükség lenne. Ehhez az EVM-ben újra lefuttatják a régi tranzakciókat, amihez sok számítási kapacitás kellhet, ha a szükséges státusz távol esik a legközelebbi pillanatfelvételtől. + +Tehát a historikus státuszok elérése egy teljes csomópont esetén számottevő számítási kapacitást fogyaszt. A kliensnek talán az összes régi tranzakciót le kell futtatnia, és a genezistől kezdve ki kell számolnia az előzménystátuszt. Az archív csomópontok úgy oldják meg ezt, hogy nemcsak a legutóbbi státuszokat tárolják, hanem minden előzménystátuszt is, amely minden egyes blokk után keletkezik. Alapvetően ez egy kompromisszum, mert a számítási kapacitás helyett ehhez nagyobb tárhely szükséges. + +Fontos megjegyezni, hogy a hálózat nem az archív csomópontoktól függ, hogy azok megtartsák és biztosítsák az összes előzményadatot. Ahogy már említettük, a teljes csomópontok minden köztes előzménystátuszt meg tudnak mutatni. A tranzakciókat mindegyik teljes csomópont tárolja (jelenleg kisebb mint 400 G), és vissza tudja azokat játszani ahhoz, hogy egy teljes archívumot felépítsen belőlük. + +### Felhasználási módok + +Az Ethereum általános használata, mint a tranzakciók küldése, a szerződések létrehozása, a konszenzus ellenőrzése stb. nem igényel semmilyen előzményadatot. A felhasználóknak nincs szükségük archív csomópontra ahhoz, hogy interakciókat hajtsanak végre a hálózattal. + +A státuszarchívumok fő haszna az előzménystátuszok gyors elérése. Például az archív csomópont azonnal megadja az eredményt a következő kérdésekre: + +- _Mi volt az ETH egyenlege a 0x1337... számlának a 15 537 393. blokknál?_ +- _Mi az egyenlege a 0x tokennek a 0x szerződéseben az 1 920 000. blokknál?_ + +Ahogy felvázoltuk, a teljes csomópont ezt az adatot az EVM végrehajtással tudja előállítani, ami CPU-t és időt igényel. Az archív csomópontok a merevlemezen érik el és azonnal meg tudják azt adni. Ez egy hasznos jellemző az infrastruktúra bizonyos részeinek, például: + +- Szolgáltatásnyújtók, mint a blokk felfedezők +- Kutatók +- Biztonsági elemzők +- Dapp-fejlesztők +- Auditálás és a szabályoknak való megfelelés + +Számtalan ingyenes [szolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service/) van, ami hozzáférést enged az előzményadatokhoz. Mivel nagyobb teherrel jár egy archív csomópont futtatása, ez a hozzáférés általában korlátozott és esetileg működik. Ha egy projekt állandó hozzáférést igényel az előzményadatokhoz, akkor érdemes saját archív csomópontot futtatnia. + +## Telepítés és használat + +Az archív csomópont ebben a kontextusban azt jelenti, hogy a végrehajtási kliensek adatot szolgáltatnak, mert kezelik a státuszadatbázist és JSON-RPC végpontokat biztosítanak. A konfigurációs lehetőségek, a szinkronizálási idő és az adatbázis mérete kliensenként változik. A részletekkel kapcsolatos részletekért, kérjük, tekintse át az Ön által használt kliens dokumentációját. + +Mielőtt egy archív csomópontot kezdene futtatni, tekintse át a kliensek közötti különbségeket, elsősorban a különböző [hardverszükségleteket](/developers/docs/nodes-and-clients/run-a-node/#requirements). A legtöbb kliensben ez a funkció nincs optimalizálva, így az archív változataik több mint 12 TB helyet igényelnek. Ezzel ellentétben az olyan implementáció, mint amilyen az Erigon, képes ugyanazt az adatot kevesebb mint 3 TB helyen tárolni, ami az archív csomópontok esetében a leghatékonyabbá teszi őket. + +## Bevált gyakorlatok + +Azon túl, amit általános [javaslatként megfogalmaznak a csomópont futtatásához](/developers/docs/nodes-and-clients/run-a-node/), az archív csomópont működtetése többet igényelhet a hardver és a fenntartás szempontjából. Figyelembe véve az Erigon [fő jellemzőit](https://github.com/ledgerwatch/erigon#key-features), a leghasznosabb megközelítés egy [Erigon](/developers/docs/nodes-and-clients/#erigon)-kliens létrehozása lenne. + +### Hardver + +Mindig ellenőrizze az egy adott csomópontra vonatkozó hardverigényeket a kliens dokumentációjában. Az archív csomópontok legnagyobb igénye a tárhely. A klienstől függően ez 3 és 12 TB között változhat. A HDD jobb lenne a nagymennyiségű adatok tárolásához, de a szinkronizálás és a lánc elejének állandó frissítése SSD-meghajtókat igényel. A [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) meghajtók elég jók, de abból is a megbízható minőségű javasolt, vagyis legalább a [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences). A lemezek elég lemezhellyel rendelkező asztali gépbe vagy szerverbe is behelyezhetők. Ezek a dedikált eszközök ideálisak egy ilyen, szinte állandóan aktív csomópont futtatásához. Laptopon is futtatható, de a hordozhatóság több költséggel jár. + +Az összes adatnak egy köteten el kell férnie, ezért a lemezeket össze kell kapcsolni, pl. a [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) vagy a [LVM](https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-lvm.html) által. Érdemes lehet megfontolni a [ZFS](https://en.wikipedia.org/wiki/ZFS) használatát is, mert ez támogatja az írásra másolás (copy-on-write) funkciót, amivel az adat biztosabban, alacsony szintű hiba nélkül íródik a lemezre. + +A nagyobb stabilitás érdekében és a véletlen adatbázis-meghibásodás megelőzésére, főleg a professzionális összeállításban, érdemes [ECC-memóriát](https://en.wikipedia.org/wiki/ECC_memory) használni, ha azt a rendszer is támogatja. A RAM méretének általában akkorának kell lennie, mint egy teljes csomópont esetében, de az ennél több RAM csak segíthet a szinkronizálás gyorsításában. + +A kezdeti szinkronizáláskor az archív csomópont kliensei lefuttatják az összes tranzakciót a genezistől kezdve. A végrehajtási sebességet a CPU korlátozza, tehát a gyorsabb CPU segít a kezdeti szinkronizáláskor. Egy átlagos számítógépen a kezdeti szinkronizálás egy hónapig is eltarthat. + +## További olvasnivaló {#further-reading} + +- [A teljes és az archív csomópont összehasonlítása az Ethereumon](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) – _QuickNode, 2022. szeptember_ +- [Építsen saját Ethereum archív csomópontot](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) – _Thomas Jay Rush, 2021. augusztus_ +- [Hogyan kell felállítani az Erigont, Erigon RPC-t és TrueBlocks-t (scrape és API) szolgáltatásként](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) – _Magnus Hansson, frissítve 2022. szeptember_ + +## Kapcsolódó témák {#related-topics} + +- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) +- [Csomópontok futtatása](/developers/docs/nodes-and-clients/run-a-node/) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" new file mode 100644 index 00000000000..473fd04c5dc --- /dev/null +++ "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" @@ -0,0 +1,31 @@ +--- +title: Bevezető az Ethereum betöltő csomópontjaiba (bootnode) +description: Alapvető információk a betöltő csomópontok megértéséhez +lang: hu +--- + +Amikor egy új csomópont csatlakozik az Ethereum hálózathoz, akkor a már hálózaton lévő csomópontokhoz kell kapcsolódnia, hogy új társakat tudjon találni. Ezeket az Ethereum hálózatba való belépőpontokat nevezik betöltő csomópontoknak. A kliensekbe bele van kódolva a betöltő csomópontok listája. Ezeket általában az Ethereum Alapítvány fejlesztőket vagy klienseket kezelő csapatai maguk működtetik. Érdemes megjegyezni, hogy a betöltő csomópontok nem azonosak a statikus csomópontokkal. A statikus csomópontokat ismételten meghívják, miközben a betöltő csomópontokat csak akkor, amikor nincs elég társ, akivel kapcsolódni lehetne, és a csomópontnak új kapcsolatokat kell felállítania. + +## Kapcsolódás egy betöltő csomóponthoz {#connect-to-a-bootnode} + +A legtöbb kliensbe bele van programozva a betöltő csomópontok listája, de egy felhasználó maga is futtathat betöltő csomópontot, vagy olyat is használhat, amely nem szerepel a kliensben. Ekkor a kliens indításakor kell megadni ezeket, ahogy a következő Geth példa mutatja (nézze meg a kliensének a dokumentációját): + +``` +geth --bootnodes "enode://@:" +``` + +## Betöltő csomópont futtatása {#run-a-bootnode} + +A betöltő csomópontok teljes csomópontok, amelyeket nem fed egy hálózati címfordítás ([Network Address Translation](https://www.geeksforgeeks.org/network-address-translation-nat/)). Minden teljes csomópont működhet betöltőként, ha nyilvánosan elérhető. + +Amikor egy csomópontot felállítanak, akkor [enode](/developers/docs/networking-layer/network-addresses/#enode) címet kell jegyezni rá, ami egy nyilvános azonosító, mellyel mások kapcsolódni tudnak hozzá. + +Ez az enode minden újraindításnál újragenerálódik, ezért a betöltő csomópont esetében ellenőrizni kell a kliens dokumentációban, hogyan lehet állandó enode-ot létrehozni. + +A betöltő csomópont hasznossága érdekében érdemes megnövelni azon társak maximális számát, akik kapcsolódhatnak hozzá. A betöltő csomópont futtatása sok kapcsolttal jelentősen megnöveli a szükséges sávszélességet. + +## Az elérhető betöltő csomópontok {#available-bootnodes} + +A go-ethereumhoz kapcsolódó beépített betöltő csomópontok listáját [itt találja](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23). Ezeket az Ethereum Alapítvány és a go-ethereum csapat tartja karban. + +Más listák is léteznek a betöltő csomópontokról, amelyeket önkéntesek tartanak karban. Legalább egy hivatalos betöltő csomópontot mindenféleképpen használni kell, különben támadás alá kerülhet a csomópont (és elvágják a kapcsolataitól). diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" new file mode 100644 index 00000000000..5d4aefd9826 --- /dev/null +++ "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" @@ -0,0 +1,109 @@ +--- +title: Kliensdiverzitás +description: Áttekintés az Ethereum-kliensdiverzitás fontosságáról. +lang: hu +sidebarDepth: 2 +--- + +Az Ethereum-csomópont viselkedését az általa használt kliensszoftver irányítja. Számos Ethereum-kliens létezik, melyeket különböző csapatok különféle nyelveken fejlesztettek és tartanak karban. A klienseket egy közös specifikáció alapján építik, hogy fennakadás nélkül tudjanak egymással kommunikálni, ugyanolyan funkcionalitással bírjanak és azonos felhasználói élményt adjanak. Ugyanakkor jelenleg a kliensek nem oszlanak el a csomópontokon elég egyenlően ahhoz, hogy a hálózat megerősítésének teljes potenciálját ki lehetne használni. Ideális esetben a felhasználók nagyjából azonosan oszlanának meg a különféle kliensek között, hogy a hálózatnak a lehető legdiverzebb legyen a klienshasználata. + +## Előfeltételek {#prerequisites} + +Ha Önnek még újdonság ez a téma, akkor tekintse meg a [Csomópontok és kliensek](/developers/docs/nodes-and-clients/) című áttekintést. A [végrehajtási réteg](/glossary/#execution-layer) és a [konszenzusréteg](/glossary/#consensus-layer) definícióját megtalálja a glosszáriumban. + +## Miért vannak különböző kliensek? {#why-multiple-clients} + +A különböző, egymástól függetlenül fejlesztett és karbantartott kliensek azért jöttek létre, mert ez a diverzitás a hálózatot sokkal ellenállóbbá teszi a támadásokkal és a hibákkal szemben. A különféle kliensek az Ethereum egyedi erősségét jelentik, mivel más blokkláncok egyetlen kliens tévedhetetlenségén alapulnak. Ugyanakkor nem elég a különféle kliensek elérhetősége, azokat használnia is kell a közösségnek, és a teljes aktív csomópontok között relatíve egyenlően kellene eloszlaniuk. + +## Miért olyan fontos a kliensdiverzitás? {#client-diversity-importance} + +A decentralizált hálózat egészsége nagy mértékben függ a függetlenül fejlesztett és fenntartott kliensektől. Nézzük át ennek okait. + +### Hibák {#bugs} + +Egy kliensben előforduló hiba kisebb kockázatot jelent a hálózatnak, amikor az az Ethereum-csomópontok kisebb hányadát képviseli. Ha a csomópontok nagyjából egyenlően oszlanak meg a különféle kliensek között, akkor nagyon kicsi az esélye, hogy a legtöbb kliens ugyanattól a hibától szenved, így a hálózat sokkal szilárdabb lesz. + +### Támadásokkal szembeni ellenállás {#resilience} + +A kliensdiverzitás nagyobb ellenállást jelent a támadásokkal szemben. Például egy olyan támadás, ami [egy bizonyos klienst arra vesz rá](https://twitter.com/vdWijden/status/1437712249926393858), hogy a lánc egy elágazását kövesse, nem valószínű, hogy sikeres lesz, mert más klienseket nem tud ugyanúgy rászedni, így a kanonikus lánc érintetlen marad. Az alacsony kliensdiverzitás növeli a kockázatát egy olyan támadásnak, amely a domináns kliens ellen irányul. A kliensdiverzitás egyértelműen fontos védelem a rosszindulatú támadások esetén, ahogy azt a 2016-os shanghai példa mutatja, amikor a támadók a domináns klienst (Geth) rávették, hogy egy lassú i/o funkciót hajtson végre blokkonként tízezerszer. Mivel más kliensek is online voltak, amelyek nem voltak ugyanígy sebezhetőek, az Ethereum képes volt ellenállni a támadásnak, folytatta működését és kijavította a Geth-kliens sebezhetőségét. + +### Proof-of-stake véglegesedés {#finality} + +Egy olyan hiba a konszenzusos kliensben, amely az Ethereum-csomópontok több mint 33%-át érinti, meg tudja akadályozni azt, hogy a konszenzusréteg véglegesedjen, tehát a felhasználók nem tudhatják, hogy a tranzakcióik nem lesznek visszaforgatva vagy megváltoztatva valamikor. Ez rendkívül problémás helyzet az Ethereumra épült alkalmazások számára, főleg a decentralizált pénzügy (DeFi) területén. + + Még ennél is rosszabb, ha egy kétharmados többséggel bíró kliensben történik hiba, ami miatt a lánc hibásan szétválik és véglegesedik, így a validátorok egy jó része egy valótlan láncon ragad. Ha ezek a validátorok újra a helyes lánchoz akarnának csatlakozni, akkor súlyos büntetéssel, vagy egy lassú és költséges visszavonási és újraaktviálási folyamattal néznének szembe. A súlyos büntetés mértéke arányos a kétharmados többség hibás csomópontjainak számával, melynek a letétjét (32 ETH) teljesen megsemmisítik. + +Habár ezek nem valószínű szcenáriók, az Ethereum ökoszisztémája képes a kockázatot csökkenteni azzal, hogy az aktív csomópontokon keresztül egyenlően oszlanak el a kliensek. Ideális esetben a teljes csomópontok 33%-át nem dominálja egy adott konszenzusos kliens. + +### Közös felelősség {#responsibility} + +A többségi klienseknek emberi költsége is van. Túlzott terhet és felelősséget helyez egy kis fejlesztői csapatra. Minél kisebb a kliensdiverzitás, annál nagyobb a felelősség terhe a fejlesztőkön, hogy karbantartsák a domináns klienst. Ennek a felelősségnek a megosztása a különféle csapatok között egyaránt egészségesebb az Ethereum-csomóponthálózat és az emberi hálózat számára. + +## Jelenlegi kliensdiverzitás {#current-client-diversity} + +![Diagram a kliensdiverzitásról](./client-diversity.png) _A diagram adatai az [ethernodes.org](https://ethernodes.org) és a [clientdiversity.org](https://clientdiversity.org/)_ honlapokról + +A két diagram a jelen írás időpontjában (2022. január) érvényes kliensmegoszlást mutatja a végrehajtási és konszenzusrétegre. A végrehajtási réteget túlságosan dominálja a [Geth](https://geth.ethereum.org/), amit távolról követ az [Open Ethereum](https://openethereum.github.io/), az [Erigon](https://github.com/ledgerwatch/erigon) és a [Nethermind](https://nethermind.io/), a többi kliens együtt nem teszi ki a hálózat 1%-át. A konszenzusréteg leggyakrabban használt kliense, a [Prysm](https://prysmaticlabs.com/#projects), nem annyira domináns, mint a Geth, de így is a hálózat több mint 60%-át lefedi. A [Lighthouse](https://lighthouse.sigmaprime.io/) és a [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) kb. 20% és 14%-ot tesznek ki, a többi klienst kevesen használják. + +A végrehajtási réteg adatai az [Ethernodes](https://ethernodes.org) oldalról származnak (2022. január 23.). A konszenzusos kliensek adatait [Michael Sproul](https://github.com/sigp/blockprint) biztosította. A konszenzusos kliensek adatait nehezebb megszerezni, mert nem rendelkeznek összetéveszthetetlen nyomokkal, amelyekkel azonosítani lehet ezeket. Az adatot egy klasszifikációs algoritmus segítségével készítették, amely bizonyos esetekben összekeveri a kisebb részesedéssel bíró klienseket (bővebben [itt](https://twitter.com/sproulM_/status/1440512518242197516) olvashat erről). A diagram esetében ezeket a nem egyértelmű klasszifikációkat egy vagy/vagy címkével láthatja (pl. Nimbus/Teku). Mindazonáltal az egyértelmű, hogy a hálózat többségét a Prysm működteti. Az adat egy pillanatfelvétel egy adott mennyiségű blokkról (jelen esetben Beacon blokkok a 2048001-tól 2164916-ig tartó slotokban), és a Prysm dominanciája néha ennél magasabb is, meghaladva a 68%-ot. Annak ellenére, hogy ezek pillanatfelvételek, mégis megmutatják a kliensdiverzitás helyzetét. + +Friss kliensdiverzitási adat elérhető már a konszenzusrétegre is a [clientdiversity.org](https://clientdiversity.org/) oldalon. + +## Végrehajtási réteg {#execution-layer} + +Mostanáig a kliensdiverzitás fókusza inkább a konszenzusrétegen volt. Ugyanakkor a [Geth](https://geth.ethereum.org) végrehajtási kliense jelenleg az összes csomópont 85%-át kiteszi. Ez az arány ugyanolyan problémás, mint a konszenzusos kliensek esetében. Például egy hiba a Geth-ben, amely a tranzakciók kezelését vagy a végrehajtási csomagok összeállítását érinti, oda vezethet, hogy a konszenzusos kliensek problémás vagy hibás tranzakciókat véglegesítenek. Ezért az Ethereum egészségesebb lenne egy egyenlőbb végrehajtásikliens-eloszlással, ideális esetben egy adott kliens nem fedné le a hálózat több mint 33%-át. + +## Kisebbségi kliens használata {#use-minority-client} + +A kliensdiverzitás eléréséhez nem elég, hogy az egyéni felhasználók kisebbségi klienseket válasszanak, ehhez szükség van arra, hogy a bányász/validátor csoportok és intézmények is, mint a nagyobb dappok és tőzsdék is átálljanak. Ugyanakkor az összes felhasználó kiveheti a részét, hogy ezt az egyenlőtlenséget orvosolja, és az összes elérhető Ethereum-szoftver használva legyen. Az egyesítés (Merge) után minden csomópont-üzemeltetőnek futtatnia kell egy végrehajtási és egy konszenzusos klienst. Az alább javasolt klienskombinációkkal növelni lehet a diverzitást. + +### Végrehajtásos kliensek {#execution-clients} + +[Besu](https://www.hyperledger.org/use/besu) + +[Nethermind](https://downloads.nethermind.io/) + +[Erigon](https://github.com/ledgerwatch/erigon) + +[Go-Ethereum](https://geth.ethereum.org/) + +### Konszenzusos kliensek {#consensus-clients} + +[Nimbus](https://nimbus.team/) + +[Lighthouse](https://github.com/sigp/lighthouse) + +[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) + +[Lodestar](https://github.com/ChainSafe/lodestar) + +[Prysm](https://docs.prylabs.network/docs/getting-started) + +A technikailag képzett felhasználók segíthetik ezt a folyamatot azzal is, hogy több útmutatót és dokumentációt készítenek a kisebbségi kliensekről, és arra bátorítják a társaikat, hogy a domináns kliens helyett mást használjanak. A kisebbségi konszenzusos kliensre való áttérésről itt talál útmutatókat: [clientdiversity.org](https://clientdiversity.org/). + +## Kliensdiverzitási irányítópultok {#client-diversity-dashboards} + +Számos irányítópult vagy kimutatás ad képet az aktuális kliensdiverzitásról a végrehajtási és konszenzusréteget illetően. + +**Konszenzusréteg:** + +- [Rated.network](https://www.rated.network/) +- [clientdiversity.org](https://clientdiversity.org/) **Végrehajtási réteg:** + +- [supermajority.info](https://supermajority.info//) +- [Ethernodes](https://ethernodes.org/) + +## További olvasnivaló {#further-reading} + +- [Kliensdiverzitás az Ethereum konszenzusrétegen](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) +- [Ethereum Merge: A többségi kliens futtatása Önt is veszélyezteti!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest, 2022. március 24._ +- [A kliensdiverzitás fontossága](https://our.status.im/the-importance-of-client-diversity/) +- [Az Ethereumcsomópont-szolgáltatások listája](https://ethereumnodes.com/) +- [Az „öt miért” kérdés alkalmazása a kliensdiverzitási problémára](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) +- [Ethereum-diverzitás és hogyan lehetne elérni (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) +- [clientdiversity.org](https://clientdiversity.org/) + +## Kapcsolódó témák {#related-topics} + +- [Ethereum-csomópont futtatása](/run-a-node/) +- [Csomópontok és kliensek](/developers/docs/nodes-and-clients/) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" new file mode 100644 index 00000000000..96cae2ec293 --- /dev/null +++ "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" @@ -0,0 +1,315 @@ +--- +title: Csomópontok és kliensek +description: Áttekintés az Ethereum csomópontokról (node) és kliens szoftverekről, valamint egy csomópont felállításának menetéről, és hogy miért érdemes sajátot működtetni. +lang: hu +sidebarDepth: 2 +--- + +Az Ethereum számítógépekből (ún. csomópontokból) álló elosztott hálózat, amelyen a számítógépek a blokkok és tranzakciós adatok hitelesítésére képes szoftvert futtatnak. A szoftver futtatása teszi a felhasználó számítógépét Ethereum-csomóponttá. A csomóponthoz két különálló szoftverre, vagyis kliensre van szükség. + +## Előfeltételek {#prerequisites} + +Mielőtt mélyebbre merülne, és megkezdené a saját Ethereum-kliensének működtetését, javasoljuk, hogy ismerje meg a közvetítőmentes (peer-to-peer) hálózatok koncepcióját és az[Ethereum Virtális Gép (EVM) alapjait](/developers/docs/evm/). Tekintse meg a [Bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) című cikket. + +Ha Önnek újdonság a csomópontok témaköre, akkor azt javasoljuk, először tekintse meg az [Ethereum-csomópont futtatása](/run-a-node) című felhasználóbarát ismertetőnket. + +## Mik azok a csomópontok és kliensek? {#what-are-nodes-and-clients} + +„Csomópont” minden olyan Ethereum-kliensszoftver-példány, amely más – szintén Ethereum-szoftvert futtató – számítógépek hálózatához kapcsolódik. A kliens az Ethereum egy implementációja, amely adatok hitelesítését végzi a protokollszabályok alapján, és fenntartja a hálózat biztonságát. A csomópontnak két klienst kell futtatnia: konszenzusos és végrehajtási kliens. + +- A végrehajtási kliens (más néven végrehajtási motor, EL-kliens vagy korábbi nevén Eth1-kliens) a hálózatban terjesztett új tranzakciókat figyeli, végrehajtja őket az EVM-ben, és tárolja az összes aktuális Ethereum-adat legutolsó állapotát és adatbázisát. +- A konszenzusos kliens (más néven Beacon-csomópont, CL-kliens vagy korábbi nevén Eth2-kliens) feladata a proof-of-stake konszenzusalgoritmus végrehajtása, amely lehetővé teszi, hogy a hálózat a végrehajtási kliens validált adatai alapján megegyezésre jusson. Létezik egy harmadik szoftver is, a validátor, amelyet a konszenzusok klienshez lehet hozzáadni, így az adott csomópont részt vehet a hálózat biztosításában. + +Ezek a kliensek együtt dolgoznak azon, hogy az Ethereum-hálózat legfrissebb állapotát kövessék, és lehetővé tegyék a felhasználók számára, hogy interakcióba lépjenek a hálózattal. Az egymással együttműködő szoftverrészekből álló moduláris felépítés neve [bennfoglalt komplexitás (encapsulated complexity)](https://vitalik.eth.limo/general/2022/02/28/complexity.html). Ez a megközelítés lehetővé tette, hogy [az egyesítés (Merge)](/roadmap/merge) hibátlanul végbemehessen, a kliensszoftvereket könnyebb legyen karbantartani és fejleszteni, továbbá az egyéni klienseket újra lehet hasznosítani, például a [2. blokkláncrétegben](/layer-2/). + +![Összekapcsolt végrehajtási és konszenzusos kliensek](./eth1eth2client.png) Az összekapcsolt végrehajtási és konszenzusos kliens egyszerűsített ábrája. + +### Kliensdiverzitás {#client-diversity} + +A [ végrehajtási klienseket](/developers/docs/nodes-and-clients/#execution-clients) és a [ konszenzusos klienseket](/developers/docs/nodes-and-clients/#consensus-clients) számos különböző programnyelvben fejlesztették ki a különféle csapatok. + +A többféle kliensimplementáció erősebbé teheti a hálózatot azáltal, hogy nem függ szorosan egyetlen programkódtól. A cél a sokszínűség elérése anélkül, hogy bármelyik kliens dominálná a hálózatot, így el lehet kerülni az egyetlen hibapont lehetőségét. A nyelvek változatossága szélesebb fejlesztői közösséget is vonz, és lehetővé teszi, hogy az általuk előnyben részesített nyelven integrációt hajtsanak végre. + +Tudjon meg többet a [kliensdiverzitásról](/developers/docs/nodes-and-clients/client-diversity/). + +Az implementációk közös vonása, hogy egyazon specifikációt követik. Ez a specifikáció diktálja, hogyan működik az Ethereum-hálózat és a blokklánc. Minden technikai részlet ki van dolgozva, a specifikációkat pedig itt találhatja: + +- Eredetileg az [Ethereum Sárga Könyvében](https://ethereum.github.io/yellowpaper/paper.pdf), vagyis műszaki alaptanulmányában. +- [Végrehajtási specifikációk](https://github.com/ethereum/execution-specs/) +- [Konszenzusspecifikációk](https://github.com/ethereum/consensus-specs) +- [EIP-ek](https://eips.ethereum.org/), amelyeket a különböző [ hálózatfrissítések](/history/) során vezettek be + +### Csomópontok követése a hálózatban {#network-overview} + +Az Ethereum-hálózat csomópontjairól számos trekker biztosít valós idejű adatokat. Megjegyzendő, hogy a decentralizált hálózatok jellege miatt ezek a letapogatók (crawler) csak korlátozott rálátást tudnak nyújtani a hálózatra, és eltérő eredményeket jelenthetnek. + +- [Csomóponttérkép](https://etherscan.io/nodetracker), készítette: Etherscan +- [Ethercsomópontok](https://ethernodes.org/), készítette: Bitfly +- [Nodewatch](https://www.nodewatch.io/), készítette: Chainsafe, konszenzuscsomópontok letapogatása +- [Monitoreth](https://monitoreth.io/) - a MigaLabs által biztosított megosztott hálózati ellenőrzési eszköz + +## Csomóponttípusok {#node-types} + +Ha [ saját csomópontot akar futtatni](/developers/docs/nodes-and-clients/run-a-node/), akkor fontos megértenie, hogy különböző típusú csomópontok léteznek, amelyek adathasználata eltérő. A kliensek valójában három különböző típusú csomópontot futtathatnak: könnyű (light), teljes (full) és archív (archive). Különböző szinkronizálási stratégiák is elérhetők, amelyek rövidebb szinkronizálási időt tesznek lehetővé. A szinkronizálás arra utal, hogy milyen gyorsan tudja elérni a csomópont az Ethereum legfrissebb státuszát. + +### Teljes csomópont (full node) {#full-node} + +A teljes csomópontok a blokklánc egymást követő blokkjait validálják, melyhez letöltik és ellenőrzik a blokk tartalmát és az adat státuszát minden egyes blokkra. A teljes csomópontoknak több fajtája létezik, néhány a kezdetektől indul, a genezis blokktól, és a blokklánc teljes történetét validálja blokkonként. Mások az ellenőrzést egy későbbi blokktól indítják, melynek érvényességében megbíznak (pl. a Geth-féle, pillanatfelvételen alapuló szinkronizálás). Függetlenül az ellenőrzés kezdőpontjától, a teljes csomópontok csak a legutóbbi adatokat (általában az utolsó 128 blokkot) tárolják, az ennél régebbieket törlik, hogy ne foglaljon annyi helyet. A régebbi adatot újra elő lehet állítani, amikor szükséges. + +- A blokkláncadatokat teljeskörűen tárolja (habár ezt időről időre megrövidíti a rendszer, tehát a teljes csomópont sem tárolja az összes állapotadatot a genezisig visszamenőleg). +- Részt vesz a blokkvalidációban, hitelesíti az összes blokkot és állapotot. +- A teljes csomópont minden státuszt elő tud hívni a lokális tárhelyéről vagy újra tudja generálni a pillanatképekből. +- Kiszolgálja a hálózatot, és kérésre adatszolgáltatást nyújt. + +### Archív csomópont {#archive-node} + +Az archív csomópontok olyan teljes csomópontok, melyek minden blokkot ellenőriznek a genezis óta, és nem törölnek semmilyen letöltött adatot. + +- Tárolja mindazt, ami a teljes csomóponton van, és archívumot épít a múltbeli állapotokból. Akkor van rá szükség, ha például valaki le akar kérni egy számlaegyenleget a 4 000 000. blokknál, vagy nyomon követést alkalmazva egyszerűen és gyorsan le akarja tesztelni a saját tranzakcióit anélkül, hogy kibányászná őket. +- Ezek az adatok terabájtnyi egységeket képviselnek, emiatt az archív csomópontok kevésbé vonzók az átlagfelhasználók számára, de hasznos lehet az olyan szolgáltatóknak, mint a blokkfelfedezők, a tárcaforgalmazók és a blokkláncelemzők. + +A kliensek szinkronizálása az archív kivételével minden módban részleges blokkláncadatokat eredményez. Ez azt jelenti, hogy nincs egy összes múltbeli státusszal rendelkező archívum, de igény esetén a teljes csomópont képes felépíteni azt. + +Tudjon meg többet az [archív csomópontokról](/developers/docs/nodes-and-clients/archive-nodes). + +### Könnyű csomópont {#light-node} + +A teljes blokkok letöltése helyett a könnyű csomópontok csak a blokkfejléceket töltik le. Ezek a fejlécek összegző információkat hordoznak a blokkok tartalmáról. A könnyű csomópont a szükséges egyéb információkat egy teljes csomóponttól kéri le. A könnyű csomópont ezután független módon hitelesítheti a kapott adatokat a blokkfejlécben található állapot-gyökérhash értékek alapján. A könnyű csomópontok segítségével a felhasználók a teljes csomópontok futtatásához elengedhetetlen erős hardver és nagy sávszélesség nélkül is részt vehetnek az Ethereum hálózatában. Végül a könnyű csomópontok mobiltelefonokon vagy beágyazott eszközökön is futtathatók lesznek. A könnyű csomópontok nem vesznek részt a konszenzusban (tehát nem lehetnek bányászok/validátorok), de ugyanolyan funkcionalitással és biztonsági garanciákkal férhetnek hozzá az Ethereum-blokklánchoz, mint egy teljes csomópont. + +A könnyű kliensek az Ethereum aktív fejlesztési területei közé tartoznak, és hamarosan új könnyű kliensek megjelenésére számítunk a konszenzusréteg és a végrehajtási réteg számára. A könnyűkliens-adatok nyújtásának további potenciális útvonala lehet a [ pletykahálózat (gossip network)](https://www.ethportal.net/). Ez előnyös, mivel a pletykahálózat képes támogatni a könnyű csomópontok hálózatát anélkül, hogy a teljes csomópontoknak kellene adatot szolgáltatniuk. + +Az Ethereum még nem támogatja a könnyű csomópontok nagy tömegeit, de számítani lehet rá, hogy ezek támogatása a közeljövőben gyorsan fejlődik majd. Különösen a [Nimbus](https://nimbus.team/), a [Helios](https://github.com/a16z/helios) és a [LodeStar](https://lodestar.chainsafe.io/) kliensek fejlesztenek aktívan a könnyű csomópontok területén. + +## Miért futtassak Ethereum csomópontot? {#why-should-i-run-an-ethereum-node} + +Egy csomópont futtatása lehetővé teszi, hogy Ön közvetlenül, bizalomigény nélkül és privát módon használhassa az Ethereumot, miközben a hálózatot támogatva fokozza annak szilárdságát és decentralizációját. + +### Milyen előnyökkel jár ez Önnek? {#benefits-to-you} + +A saját csomópont futtatása lehetővé teszi az Ethereum valóban privát, önálló és bizalomigény nélküli használatát. Önnek nem kell bíznia a hálózatban, mivel az adatokat saját maga is ellenőrizheti a kliensén keresztül. A „Nem kell megbíznia senkiben. Csak ellenőrizni” egy népszerű blokkláncmantra. + +- A csomópontja önállóan hitelesíti az összes tranzakciót és blokkot a konszenzusszabályoknak megfelelően. Ez azt jelenti, hogy nem kell a hálózat egyetlen más csomópontjára sem támaszkodnia, sem teljesen megbíznia bennük. +- Saját csomópontjához használhat egy Ethereum-tárcát. Biztonságosabban és diszkrétebben használhatja a dappokat, mivel nem kell kiadnia a címét és az egyenlegét közvetítőknek. Mindent ellenőrizhet a saját kliensével. A [MetaMask](https://metamask.io), a [Frame](https://frame.sh/)és [ számos egyéb tárca](/wallets/find-wallet/) kínál RPC-importálást, amely lehetővé teszi számukra az Ön csomópontjának használatát. +- Más olyan szolgáltatásokat is futtathat vagy végezhet saját hatáskörben, amelyek az Ethereum adataira támaszkodnak. Ilyen lehet például egy Beaconlánc-validátor, egy második blokkláncréteg szoftvere, infrastruktúra, blokkfelfedezők, fizetésfeldolgozó alkalmazások stb. +- Ön saját egyéni [RPC-végpontokat](/developers/docs/apis/json-rpc/) is kínálhat. Ezeket a végpontokat felajánlhatja nyilvánosan a közösségnek is, hogy ezzel is elkerüljék a nagy, centralizált szolgáltatókat. +- A csomópontjához a **folyamaton belüli kommunikációk (IPC)** mechanizmusával csatlakozhat, vagy átírhatja a csomópontját, hogy a saját programját töltse be pluginként. Ez rövid késleltetést tesz lehetővé, ami nagyon fontos, ha például valaki web3 könyvtárak használatával dolgoz fel nagy mennyiségű adatot, vagy amikor a lehető leggyorsabban ki kell cserélnie tranzakcióit (például frontrunning esetén). +- Közvetlenül letétbe helyezhet ETH-t, ezzel biztosítja a hálózatot és jutalmakat szerez. A kezdéshez tekintse meg az [önálló letétbe helyezésről](/staking/solo/) szóló oldalunkat. + +![Hogyan férhet hozzá az Ethereumhoz az alkalmazásával és a csomópontjával](./nodes.png) + +### Hálózati előnyök {#network-benefits} + +A csomópontok sokfélesége fontos az Ethereum egészsége, biztonsága és működési ellenálló képessége szempontjából. + +- A teljes csomópontok betartatják a konszenzusszabályokat, így nem lehet őket becsapni és rávenni szabálytalan blokkok elfogadására. Ez extra biztonságot nyújt a hálózatnak, mert ha az összes csomópont könnyű csomópont lenne, amelyek nem végeznek teljes ellenőrzést, akkor a validátorok megtámadhatnák a hálózatot. +- Ha egy támadás legyűri a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/#what-is-pos) mechanizmus kriptogazdaság-védelmi rendszerét, akkor a teljes csomópontok a becsületes lánc követése mellett szavazva közösségi visszaállítást hajthatnak végre. +- Ha több csomópont van a hálózatban, az sokszínűbb és szilárdabb hálózatot eredményez, ami a decentralizáció végső célja, és megteremti a cenzúrával szemben ellenálló és megbízható rendszer lehetőségét. +- A teljes csomópontok hozzáférést biztosítanak a blokkláncadatokhoz a könnyű kliensek számára, melyek ettől függenek. A könnyű csomópontok nem tárolják az egész blokkláncot, ehelyett az adatokat a [blokkfejlécekben található státuszgyökerek](/developers/docs/blocks/#block-anatomy) alapján ellenőrzik. Szükség esetén további információkat is kérhetnek a blokkokról a teljes csomópontoktól. + +Ha valaki egy teljes csomópontot futtat, akkor az az egész Ethereum-hálózat számára előnyös, még ha nem is működtet azon validátort. + +## Saját csomópont üzemeltetése {#running-your-own-node} + +Szeretne saját Ethereum-klienst futtatni? + +A kezdők számára is könnyen érthető bevezetőért látogasson el a [Csomópont futtatása](/run-a-node) oldalunkra. + +Ha Ön jártas a technológiában, akkor további részleteket és lehetőségeket talál arra vonatkozóan, hogyan [pörgesse fel saját csomópontját](/developers/docs/nodes-and-clients/run-a-node/). + +## Alternatívák {#alternatives} + +A saját csomópont felállítása idő- és erőforrásigényes lehet, de nem minden esetben szükséges saját példányt futtatnia. Ekkor használhat egy harmadik fél által biztosított API-t (alkalmazásprogramozási felület). Ezen szolgáltatások használatának áttekintéséhez nyissa meg a [Csomópontok mint szolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service/) című bejegyzésünket. + +Ha az Ön közösségében valaki nyilvános API-val futtat egy Ethereum-csomópontot, akkor egy egyedi RPC-n keresztül átirányíthatja a tárcáit erre a közösségi csomópontra, így nagyobb fokú adatvédelemben részesülhet, mintha egy véletlenszerűen kiválasztott, harmadik félben bízna meg. + +Ugyanakkor, ha Ön klienst üzemeltet, akkor megoszthatja azokkal a barátaival, akiknek szüksége lehet rá. + +## Végrehajtási kliensek {#execution-clients} + +Az Ethereum-közösség több nyílt forráskódú végrehajtási klienst (korábbi nevén „Eth1-kliens”, vagy egyszerűen „Ethereum-kliens”) tart fent, amelyeket különböző csapatok különböző programnyelveken hoztak létre. Ez erősebbé és [sokszínűvé](/developers/docs/nodes-and-clients/client-diversity/) teszi a hálózatot. A cél a sokszínűség elérése anélkül, hogy bármelyik kliens dominálna, így el lehet kerülni az egyetlen hibapont lehetőségét. + +Ez a táblázat összefoglalja a különböző klienseket. Ezek mindegyike megfelel a [klienstesztnek](https://github.com/ethereum/tests), és aktívan karbantartják őket, hogy naprakészek legyenek a hálózati frissítések tekintetében. + +| Kliens | Nyelv | Operációs rendszerek | Hálózatok | Szinkronizációs stratégiák | Állapot elhagyás | +| ------------------------------------------------------------------------ | ---------- | --------------------- | ------------------------- | -------------------------------------------------------------------- | ------------------- | +| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Snap](#snap-sync), [teljes](#full-sync) | Archív, megvágott | +| [Nethermind](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Snap](#snap-sync) (kiszolgálás nélkül), gyors, [teljes](#full-sync) | Archív, csökkentett | +| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Snap](#snap-sync), [gyors](#fast-sync), [teljes](#full-sync) | Archív, csökkentett | +| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Teljes](#full-sync) | Archív, csökkentett | +| [Reth](https://reth.rs/) | Rust | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Teljes](#full-sync) | Archív, megvágott | +| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(béta)_ | TypeScript | Linux, Windows, macOS | Sepolia, Holesky | [Teljes](#full-sync) | Megvágott | + +A támogatott hálózatokkal kapcsolatos további információkért olvassa el az [Ethereum-hálózatok](/developers/docs/networks/) című cikket. + +Minden kliens egyedi felhasználási esetekkel és előnyökkel rendelkezik, ezért a saját preferenciái alapján válasszon közülük. A sokféleség lehetővé teszi, hogy az implementációk különféle szolgáltatásokra és felhasználói közönségekre koncentráljanak. Előfordulhat, hogy a klienseket a szolgáltatások, a támogatás, a programozási nyelv vagy a licencek alapján választja ki. + +### Besu {#besu} + +íA Hyperledger Besu egy vállalati szintű Ethereum-kliens a nyilvános és engedélyhez kötött hálózatokhoz. Az Ethereum-főhálózat összes szolgáltatását támogatja, a nyomon követéstől a GraphQL-ig, kiterjedt felügyeleti funkciót kínál, és a ConsenSys támogatja, mind a nyílt közösségi csatornákon, mind a vállalkozások számára elérhető kereskedelmi SLA-k révén. Java nyelven íródott, és az Apache 2.0 licenc alatt fut. + +A Besu részletes [dokumentációja](https://besu.hyperledger.org/en/stable/) az összes funkció és beállítás tekintetében tájékoztatást nyújt. + +### Erigon {#erigon} + +Az Erigon – korábbi nevén Turbo-Geth – a Go Ethereum elágazásaként indult el a sebességre és a hatékony tárhelyhasználatra fókuszálva. Az Erigon az Ethereum teljesen újraépített implementációja, mely jelenleg Go nyelven elérhető, de más programozási nyelven is lehet majd implementálni. Az Erigon célja egy gyorsabb, modulárisabb és optimalizáltabb Ethereum-implementáció megteremtése. Kevesebb mint 3 nap alatt képes egy 2 TB tárhelyet használó, teljes archív csomópont szinkronizációját elvégezni. + +### Go Ethereum {#geth} + +A Go Ethereum (röviden Geth) az Ethereum protokoll egyik eredeti implementációja. Jelenleg ez a legelterjedtebb kliens a legnagyobb felhasználói bázissal és sokféle eszközzel a felhasználók és a fejlesztők számára. Go nyelven van írva, teljesen nyílt forráskódú, és a GNU LGPL v3 licenc alatt fut. + +További információkat a Geth [dokumentációjában](https://geth.ethereum.org/docs/) talál. + +### Nethermind {#nethermind} + +A Nethermind egy Ethereum-implementáció, amelyet a C# .NET tech stackkel hoztak létre az LGPL-3.0 licenc alatt, és minden nagyobb platformon fut, beleértve az ARM-et is. Nagyszerű teljesítményt nyújt: + +- egy optimizált virtuális géppel; +- állapoteléréssel; +- networkinggel és sokféle funkcióval, mint a Prometheus/Graphana irányítópultok, seq vállalati naplózási támogatás, JSON-RPC nyomon követés és analitikai plugin-ek. + +Ezenkívül a Nethermind [részletes dokumentációval](https://docs.nethermind.io), erős fejlesztői támogatással és online közösséggel is rendelkezik, valamint nonstop támogatással a prémium felhasználók részére. + +### Reth {#reth} + +A Reth (a Rust Ethereum rövidítve) egy Ethereum teljes csomópont-implementáció, amely felhasználóbarát, rendkívül moduláris, gyors és hatékony. A Reth-et eredetileg a Paradigm építette és fejlesztette, és az Apache és MIT alatt van engedélyeztetve. + +A Reth készen áll az éles használatra, olyan kritikus környezetekben is jól használható, mint a letétbe helyezés vagy nagy elérhetőséget igénylő szolgáltatások. Olyan esetekben is jól teljesít, melyek nagy teljesítményt igényelnek jó áron, mint az RPC, MEV, indexálás, szimulációk és peer-to-peer tevékenységek. + +Tudjon meg többet a [Reth Book](https://reth.rs/) vagy a [Reth GitHub repo](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth) révén. + +### Fejlesztés alatt {#execution-in-development} + +Ezek a kliensek még a fejlesztés korai fázisában vannak, és ezért nem lehet élesben használni őket. + +#### EthereumJS {#ethereumjs} + +Az EthereumJS végrehajtási kliens (EthereumJS) TypeScript nyelven íródott, és számos csomagból áll, beleértve a Block, Transaction és Merkle-Patricia Trie osztályok által képviselt alapvető Ethereum primitíveket, valamint az alapvető klienskomponenseket, beleértve az Ethereum virtuális gép (EVM) implementációját, egy blokkláncosztályt és a DevP2P hálózati stacket. + +Tudjon meg többet erről a [dokumentációból](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) + +## Konszenzusos kliensek {#consensus-clients} + +Többféle konszenzusos kliens (korábbi nevén „Eth2” kliens) is létezik, amely támogatja a [ konszenzusfrissítéseket](/roadmap/beacon-chain/). Ezek felelnek az összes konszenzushoz kapcsolódó logikáért, beleértve az elágazásalgoritmust, a tanúsítások feldolgozását, valamint a [proof-of-stake](/developers/docs/consensus-mechanisms/pos) jutalmak és büntetések kezelését. + +| Kliens | Nyelv | Operációs rendszerek | Hálózatok | +| ------------------------------------------------------------- | ---------- | --------------------- | ------------------------------------------------------------ | +| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | Beacon Chain, Goerli, Pyrmont, Sepolia, Ropsten stb. | +| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia, Ropsten stb. | +| [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia, Ropsten stb. | +| [Prysm](https://docs.prylabs.network/docs/getting-started/) | Go | Linux, Windows, macOS | Beacon Chain, Gnosis, Goerli, Pyrmont, Sepolia, Ropsten stb. | +| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | Beacon Chain, Gnosis, Goerli, Sepolia, Ropsten stb. | +| [Grandine](https://docs.grandine.io/) (béta) | Rust | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia és mások | + +### Lighthouse {#lighthouse} + +A Lighthouse egy konszenzusos kliens-implementáció, amelyet Rust nyelven írtak, és az Apache-2.0 licenc alatt adták ki. Fenntartója a Sigma Prime, és a Beacon lánc létrejötte óta stabil és szabadon használható. Különböző vállalkozások, letéti alapok és magánszemélyek támaszkodnak rá. Célja a biztonságos, nagy teljesítményű és interoperábilis működés számos különböző környezetben, az asztali számítógépektől egészen a kifinomult, automatizált rendszerekig. + +A dokumentációt a [Lighthouse Book](https://lighthouse-book.sigmaprime.io/) tartalmazza + +### Lodestar {#lodestar} + +A Lodestar egy szabadon használható konszenzusoskliens-implementáció, amelyet TypeScript nyelven írtak, és az LGPL-3.0 licenc alatt adták ki. A fenntartója a ChainSafe Systems, és az önálló letétbe helyezőknek, fejlesztőknek és kutatóknak készült legújabb konszenzusos kliens. A Lodestar egy Beacon-csomópontból és egy validátorkliensből áll, amely az Ethereum-protokollok JavaScript implementációival működik. A Lodestar célja az Ethereum használhatóbbá tétele a könnyű kliensek felhasználói számára, a hozzáférés kiterjesztése egy szélesebb fejlesztői körre, és hogy hozzájáruljon az ökoszisztéma sokszínűségéhez. + +További információ a [Lodestar webhelyünkön](https://lodestar.chainsafe.io/) található + +### Nimbus {#nimbus} + +A Nimbus egy konszenzusos kliens-implementáció, amelyet Nim nyelven írtak, és az Apache-2.0 licenc alatt adták ki. Ez egy szabadon használható kliens, amelyet önálló letétbe helyezők és letéti alapok használnak. A Nimbust erőforráshatékony rendszernek tervezték, emiatt a korlátozott erőforrásokkal rendelkező eszközökön és a vállalati szintű infrastruktúrákon egyaránt könnyű futtatni anélkül, hogy a stabilitást vagy a jutalmat szerző teljesítményt veszélyeztetné. A kisebb erőforráslábnyom azt jelenti, hogy nagy hálózati terheltség mellett nagyobb a kliens biztonsági zónája. + +További információ a [Nimbus-dokumentációban](https://nimbus.guide/) található + +### Prysm {#prysm} + +A Prysm egy teljes körű funkciókat kínáló, nyílt forráskódú konszenzusos kliens, amelyet Go nyelven írtak, és a GPL-3.0 licenc alatt adták ki. Opcionális webalkalmazási felhasználói felületet kínál, előtérbe helyezi a felhasználói élményt, a dokumentációt és a konfigurálhatóságot az otthoni letétbe helyezők és az intézményi felhasználók számára is. + +További információkért tekintse meg a [Prysm-dokumentációt](https://docs.prylabs.network/docs/getting-started/). + +### Teku {#teku} + +A Teku a Beacon lánc egyik eredeti geneziskliense. A szokásos célok (biztonság, szilárdság, stabilitás, használhatóság, teljesítmény) mellett a Teku külön célként tűzte ki, hogy teljes mértékben megfeleljen a különböző konszenzusoskliens-szabványoknak. + +A Teku nagyon rugalmas alkalmazási opciókat kínál. A Beacon-csomópont és a validátorkliens egyetlen folyamatként együtt is futtatható, ami rendkívül kényelmes az önálló letétbe helyezők számára, illetve a csomópontok a kifinomult letéti műveletek érdekében külön is futtathatók. Emellett a Teku teljesen kompatibilis a [Web3Signer](https://github.com/ConsenSys/web3signer/) rendszerrel az aláírásikulcs-biztonság, valamint a súlyos és kizárással járó büntetés (slashing) elkerülése érdekében. + +A Teku Java nyelven íródott és az Apache 2.0 licenc alatt fut. A ConsenSys Protocols csapata fejleszti, amely a Besu és a Web3Signer fejlesztője is. További információk a [Teku-dokumentációban](https://docs.teku.consensys.net/en/latest/) találhatók. + +### Grandine {#grandine} + +A Grandine egy konszenzuskliens-implementáció, amelyet Rust nyelven írtak, és a GPL-3.0 licenc alatt adták ki. Fenntartója a Grandine központi csapata, továbbá gyors, nagy teljesítményre képes és könnyű. A letétbe helyezők széles skálájához illeszkedik, a kis erőforrásigényű eszközökön, például Raspberry Pi-n futó egyéni letétbe helyezőktől kezdve a több tízezer validálót futtató, nagy intézményi letétesekig. + +A dokumentációt a [Grandine Book](https://docs.grandine.io/) tartalmazza + +## Szinkronizálási módok {#sync-modes} + +Ahhoz, hogy az Ethereum-kliens az aktuális adatokat kövesse és hitelesítse a hálózaton, szinkronizálnia kell a legfrissebb hálózati státusszal. Ez úgy történik, hogy adatokat tölt le többi klienstől, kriptográfiailag ellenőrzi azok integritását, és felépít egy helyi blokkláncadatbázist. + +A szinkronizálási módok ennek a folyamatnak a különböző megközelítéseit képviselik eltérő kompromisszumokkal. A kliensek a szinkronizálási algoritmusok végrehajtásában is különböznek. A végrehajtással kapcsolatos konkrétumokról mindig a választott kliens hivatalos dokumentációjából tájékozódjon. + +### A végrehajtási réteg szinkronizálási módjai {#execution-layer-sync-modes} + +A végrehajtási réteg különféle módokon futhat a felhasználási esetek szerint, újravégrehajtva a blokklánc globális állapotát addig, hogy csak a lánc csúcsával szinkronizál egy megbízható ellenőrzési pontból. + +#### Teljes szinkronizálás (full sync) {#full-sync} + +A teljes szinkronizálás letölti az összes blokkot (beleértve a fejléceket és a blokkadatokat), és a genezistől kezdve a blokkok végrehajtásával lépésenként legenerálja a blokklánc státuszát. + +- Minimalizálja a bizalomigényt, és a tranzakciók hiánytalan ellenőrzésével a legmagasabb fokú biztonságot garantálja. +- A tranzakciók növekvő száma miatt az összes tranzakció feldolgozása napokat vagy akár heteket is igénybe vehet. + +Az [archív csomópontok](#archive-node) teljes szinkronizálást végeznek, hogy felépítsék (és megtartsák) a státuszváltozások teljes előzményadatait, melyeket az összes blokk összes tranzakciója indukált. + +#### Gyors szinkronizálás (fast sync) {#fast-sync} + +Ahogy a teljes szinkronizálás, a gyors szinkronizálás is letölt minden blokkot (beleértve a fejléceket, tranzakciókat és visszaigazolásokat). Ugyanakkor nem hajtja újra végre a korábbi tranzakciókat, hanem a visszaigazolásokra támaszkodik, amíg elér a legújabb fejhez, ahol importálásba kezd és feldolgozza a blokkokat, hogy teljes csomópontot adjon. + +- Gyors szinkronizálási stratégia. +- Csökkenti az internet-sávszélességi igényt. + +#### Snap szinkronizálás (snap sync) {#snap-sync} + +A snap szinkronizálás is blokkról blokkra ellenőrzi a láncot. Ugyanakkor nem a genezisblokktól kezdi, hanem egy azt követő, megbízható ellenőrzési ponton, ami valóban része a blokkláncnak. A csomópont elmenti a periodikus ellenőrzési pontokat, miközben törli az adatokat, melyek egy bizonyos időpontnál régebbiek. Ezek a pillanatfelvételek kellenek az adatok újragenerálásához szükségszerint, így nem kell azokat örökre tárolni. + +- A leggyorsabb szinkronizálási stratégia jelenleg az alapértelmezett mód az Ethereum-főhálózaton. +- A biztonság feláldozása nélkül takarít meg nagy lemezterületet és sávszélességet. + +[Bővebben a snap szinkronizálásról](https://github.com/ethereum/devp2p/blob/master/caps/snap.md). + +#### Könnyű szinkronizálás (light sync) {#light-sync} + +A könnyű szinkronizálás letölti az összes blokkfejlécet és blokkadatot, és véletlenszerűen ellenőriz néhányat. Csak a lánc végét szinkronizálja a megbízható ellenőrző ponttól kezdve. + +- Csak a legutolsó állapotot hívja le, és megbízik a fejlesztőkben és a konszenzusmechanizmusban. +- A kliens néhány percen belül készen áll arra, hogy az aktuális hálózati állapottal használják. + +**Megjegyzés**: A proof-of-stake Ethereum-hálózatán még nem működik a könnyű szinkronizálás, ennek új verziói nemsokára használhatóak lesznek! + +[Bővebben a könnyű kliensekről](/developers/docs/nodes-and-clients/light-clients/) + +### A konszenzusréteg szinkronizálási módjai {#consensus-layer-sync-modes} + +#### Optimista szinkronizálás {#optimistic-sync} + +Az optimista szinkronizálás egy Merge utáni szinkronizálási stratégia, amelynek célja az opt-in és a visszamenőleges kompatibilitás megvalósítása, lehetővé téve, hogy a végrehajtási pontok a már bejáratott módszerekkel végezhessék a szinkronizálást. A végrehajtási motor _ optimista módon_ képes a beacon blokkokat importálni azok teljes körű ellenőrzése nélkül, megtalálni a legújabb fejlécet, majd a fenti módszerekkel megkezdeni a lánc szinkronizálását. Majd miután a végrehajtási kliens behozta a lemaradást, értesíti a konszenzusos klienst a Beacon láncon található tranzakciók érvényességéről. + +[Az optimista szinkronizálásról bővebben](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md) + +#### Ellenőrzésipont-alapú szinkronizálás {#checkpoint-sync} + +Az ellenőrzésipont-alapú vagy más néven gyenge szubjektivitású szinkronizálás első osztályú felhasználói élményt nyújt a Beacon-csomópont szinkronizálásához. A [gyenge szubjektivitás](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) feltevésein alapul, ami lehetővé teszi, hogy a kliens a Beacon láncot a genezis helyett egy közelmúltbeli, gyenge szubjektivitású ellenőrzési ponttól kezdve szinkronizálja. Ez jelentősen lerövidíti a kezdeti szinkronizálás idejét ahhoz hasonló bizalmi feltevések mellett, mintha a [genezistől](/glossary/#genesis-block) kezdve szinkronizálnánk. + +A gyakorlatban ez azt jelenti, hogy a csomópontunk egy távoli szolgáltatóhoz kapcsolódva a közelmúltban véglegesített állapotokat tölt le, majd attól a ponttól kezdve folytatja az adatok hitelesítését. Az adatokat szolgáltató harmadik fél bizalmat igényel, ezért körültekintően kell kiválasztani. + +Az [ ellenőrzésipont-alapú szinkronizálásról](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice) bővebben + +## További olvasnivaló {#further-reading} + +- [Ethereum-alapismeretek – 2. rész – A csomópontok megértése](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– Wil Barnes, 2019. február 13._ +- [Teljes csomópontok futtatása az Ethereumon: Útmutató az alig motivált felhasználók számára](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux, 2019. november 7._ + +## Kapcsolódó témák {#related-topics} + +- [Blokkok](/developers/docs/blocks/) +- [Hálózatok](/developers/docs/networks/) + +## Kapcsolódó útmutatók {#related-tutorials} + +- [Alakítsa át a Raspberry Pi 4-et validátor-csomóponttá pusztán a MicroSD kártya előkészítésével – Telepítési útmutató](/developers/tutorials/run-node-raspberry-pi/) _– Készítse fel a Raspberry Pi 4-et, csatlakoztasson egy Ethernet-kábelt, csatlakoztassa az SSD-t, és kapcsolja be az eszközt, hogy a Raspberry Pi 4 teljes Ethereum-csomóponttá váljon a végrehajtási rétegen (fő hálózat) és/vagy a konszenzusrétegen (Beacon lánc/validátor)._ diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" new file mode 100644 index 00000000000..5ba397e43bf --- /dev/null +++ "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" @@ -0,0 +1,61 @@ +--- +title: Könnyű kliens +description: Az Ethereum könnyű klienseinek bemutatása. +lang: hu +--- + +A teljes csomópont futtatása a leginkább bizalomigény-mentes, decentralizált és cenzúrának ellenálló mód, ahogy az Ethereummal kapcsolódni lehet. A teljes csomópont esetén Ön rendelkezik a blokklánc saját másolatával, amit azonnal lekérdezhet, illetve közvetlen hozzáférése van az Ethereum peer-to-peer hálózatához. Ehhez azonban jelentős memória, tárhely és CPU szükséges. Tehát nem lehetséges mindenki számára, hogy a saját csomópontját működtesse. Az Ethereum ütemterve számos olyan megoldást tartalmaz, mely segít majd ezen, mint például a státuszmentesség, de lehet, hogy csak néhány év múlva kerül bevezetésre. A közeljövőben az a kompromisszum jelenthet megoldást, hogy a teljes csomópont néhány előnyét feláldozzuk olyan teljesítménynövelésre, amivel a csomópont alacsony hardverszükséglettel is működtethető. Ezt a kompromisszumot képviselik a könnyű csomópontok. + +## Mi az a könnyű kliens {#what-is-a-light-client} + +A könnyű csomópont az, amely könnyű kliensszoftvert működtet. Ahelyett, hogy a blokklánc adatának másolatát tartaná és önállóan ellenőrizné a változásokat, a szükséges adatot szolgáltatóktól szerzi be. A szolgáltató lehet egy közvetlen kapcsolat egy teljes csomóponthoz vagy egy központosított RPC-szerveren keresztül. Az adatot ezután ellenőrzi a könnyű csomópont, így kezeli a lánc legfrissebb állapotát. A könnyű csomópont csak a blokkfejlécet kezeli, és csak esetenként tölti le a blokk tartalmát. A csomópontok eltérhetnek a könnyűségükben, mivel a könnyű és a teljes kliensszoftver kombinációját is működtethetik. Például könnyűségi beállítás lehet az, hogy könnyű végrehajtási kliens és könnyű konszenzusos kliens működik. Az is valószínű, hogy számos csomópont könnyű konszenzusos klienst futtat teljes végrehajtási klienssel, vagy fordítva. + +## Hogyan működnek a könnyű kliensek? {#how-do-light-clients-work} + +Amikor az Ethereum átállt a proof-of-stake mechanizmusra, akkor új infrastruktúrát vezetett be a könnyű kliensek támogatására. Ez úgy működik, hogy véletlenszerűen választ ki egy 512 validátorból álló alcsoportot minden 1,1 naponta, hogy **szinkronizálási bizottságként** működjenek. A szinkronizálási bizottság írja alá az éppen aktuális blokkok fejlécét. Minden blokkfejléc tartalmazza a bizottság validátorainak aggregált aláírását és egy bit-mezőt arról, hogy melyik validátor írta alá és melyik nem. Minden fejléc tartalmazza a következő blokk aláírásában részt vevő validátorok listáját is. Eszerint egy könnyű kliens gyorsan értelmezni tudja, hogy a szinkronizálási bizottság aláírta az adatot, amit ő is megkapott, továbbá a bizottság kilétét is igazolni tudja azáltal, hogy az előző blokkban megkapta a résztvevők listáját. Így a könnyű kliens is ismeri a legutóbbi Ethereum-blokkot anélkül, hogy ténylegesen letöltené azt, és csak a fejlécben található összefoglalást kell néznie. + +A végrehajtási rétegen nem létezik egyetlen specifikáció a könnyű végrehajtási kliensre. Ennek tartományába belefér a teljes kliens „könnyű üzemmódja”, ami rendelkezik a teljes csomópont összes EVM- és hálózati funkcionalitásával, de csak a blokkfejlécet ellenőrzi, a kapcsolódó adatot nem tölti le; vagy lehet egy sokkal egyszerűbb kliens is, amelynek az Ethereummal való kapcsolata az RPC-szolgáltatónak küldött kérésen alapszik. + +## Miért fontosak a könnyű kliensek? {#why-are-light-clients-important} + +A könnyű kliensek azért fontosak, mert lehetővé teszik a felhasználóknak, hogy ellenőrizni tudják a bejövő adatokat, és ne kelljen vakon megbízni az adatszolgáltatók korrekt és egyenes hozzáállásában, és mindeközben a teljes csomópont számítási erőforrásának csak egy apró töredékét használják. A könnyű kliensek által kapott adatot össze kell vetni a blokkfejléccel, amelyet már aláírt az Ethereum-validátorok véletlenszerűen választott, 512 tagból álló bizottságának legalább 2/3-a. Ez egy nagyon erős bizonyíték arra vonatkozóan, hogy az adat helyes. + +A könnyű kliens a számítási kapacitás, memória és tárhely töredékét használja csak, ezért mobilon is futtatható, beágyazható egy alkalmazásba vagy egy böngésző részeként is működhet. A könnyű kliensek megadják a lehetőséget arra, hogy az Ethereumhoz minimális bizalomigényű hozzáférése legyen a felhasználónak, ami épp annyira egyszerű, mint megbízni egy harmadik fél által adott szolgáltatásban. + +Vegyünk egy egyszerű példát. Tegyük fel, Ön meg szeretné nézni a számlaegyenlegét. Ehhez egy kérést kell küldenie egy Ethereum-csomópontnak. Ez a csomópont megnézi az Ethereum státuszáról készült saját másolatát az egyenlegért, és azt visszaküldi Önnek. Ha Önnek nincs közvetlen hozzáférése egy csomóponthoz, akkor központi szolgáltatók adják meg ezt az adatot. Ön küld egy kérést e szolgáltatóknak, akik ellenőrzik a csomópontjukat, és visszaküldik az eredményt. Ezzel annyi a probléma, hogy Önnek meg kell bíznia a szolgáltatóban, hogy a helyes információt adja. Sosem tudhatja, hogy az információ helyes, ha nem ellenőrzi maga. + +A könnyű kliens megoldja ezt a problémát. Ön ekkor is egy külső adatszolgáltatótól kér információt, de az adat egy bizonyítékkal érkezik, melyet a könnyű csomópont le tud ellenőrizni a blokkfejléchez képest. Tehát az Ethereum ellenőrzi az adat helyességét egy bizalmat igénylő szolgáltató helyett. + +## Milyen innovációkat tesznek lehetővé a könnyű kliensek? {#what-innovations-do-light-clients-enable} + +Az elsődleges előnye a könnyű klienseknek az, hogy több ember fér hozzá az Ethereumhoz független módon, jelentéktelen hardvert igényel és minimális a függés a harmadik felektől. Ez jó a felhasználóknak, mert ellenőrizni tudják a saját adataikat, és jó a hálózatnak is, mert növeli a csomópontok számát és diverzitását, melyek ellenőrzik a láncot. + +Az innováció egyik fő területe az, hogy az Ethereum-csomópontokat olyan eszközökön is lehet futtatni, amelyek kis tárhellyel, memóriával és feldolgozási kapacitással bírnak. Miközben a mai Ethereum-csomópontok jelentős számítási kapacitást igényelnek, addig a könnyű klienseket be lehet ágyazni a böngészőkbe, mobilon lehet futtatni, és talán még annál is kisebb eszközökön, mint az okosórák. Tehát az Ethereum-tárcák beágyazott kliensekkel futtathatók mobilon is. Emellett a mobiltárcák még inkább decentralizáltak lehetnek, mert az adatokhoz nem egy központi szolgáltatónál jutnak hozzá. + +Ennek kiterjesztése lehetővé teszi **a dolgok internete (IoT)** eszközök használatát is. A könnyű kliens gyorsan igazolni tudja valamilyen tokenegyenleg vagy NFT tulajdonlását, mindazzal a garanciával együtt, amit a szinkronizálási bizottság ad, és valamilyen akciót indít el egy IoT-hálózaton. Vegyünk egy [kerékpárkölcsönzőt](https://youtu.be/ZHNrAXf3RDE?t=929), amely egy alkalmazást használ egy beágyazott könnyű klienssel, hogy gyorsan ellenőrizze, hogy a felhasználónál megtalálható a kölcsönző NFT-je, és ha igen, akkor rendelkezésére bocsát egy kerékpárt! + +Az Ethereum összevont tranzakciói is élvezhetik a könnyű kliensek előnyét. Az összevont tranzakciók egyik nagy problémája az, hogy támadások érik azokat a hidakat, melyeken pénzeszközöket küldenek az Ethereum főhálózatról az összevont tranzakcióra. Az egyik sebezhető pont az összevont tranzakciók által használt orákulum, amellyel felismerik, hogy egy felhasználó letétet helyezett a hídba. Ha az orákulum rossz adatot szolgáltat, akkor rászedheti az összevont tranzakciót, hogy elhiggye a hídnak adott letétet, és így tévesen pénzeszközt adjon át. Az összevont tranzakcióba ágyazott könnyű kliens megvédheti azt a korrupt orákulumoktól, mert a hídnak adott letét egy olyan bizonyítékkal jön, melyet az összevont tranzakció ellenőrizni tud, mielőtt bármilyen tokent átadna. Ugyanez a koncepció alkalmazható más láncok közötti hidaknál. + +A könnyű kliensek az Ethereum-tárcák fejlesztésére is használhatók. Ahelyett, hogy egy RPC-szolgáltató által adott adatban bízna, a tárca közvetlenül ellenőrizni tudná az adatot egy beágyazott könnyű kliens révén. Ez növelné a tárca biztonságát. Ha az RPC-szolgáltató rosszhiszemű volt és helytelen adatot adott, akkor a beágyazott könnyű kliens ezt feltárná Önnek! + +## Mi a könnyű kliens fejlesztésének jelenlegi helyzete? {#current-state-of-development} + +Számos könnyű klienst fejlesztenek, beleértve a végrehajtási, konszenzusos és a kombinált klienseket is. A jelen írás keletkezésekor az alábbi bevezetésekről van információnk: + +- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): konszenzusos könnyű kliens TypeScript-ben +- [Helios](https://github.com/a16z/helios): kombinált végrehajtási és konszenzusos könnyű kliens Rust-ban +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): a végrehajtási kliens könnyű módozata (fejlesztés alatt áll) Go-ban +- [Nimbus](https://nimbus.guide/el-light-client.html): konszenzusos könnyű kliens Nim-ben + +Tudomásunk szerint ezek még nem állnak készen az éles használatra. + +Számos fejlesztés zajlott akörül is, hogy a könnyű kliensek hogyan férnek hozzá az Ethereum adataihoz. Jelenleg a könnyű kliensek a teljes csomópontoknak adott RPC-kéréseken alapulnak kliens/szerver modellt használva, de a jövőben az adatot egy decentralizáltabb módon is kérhetik egy dedikált hálózatot használva, mint amilyen a [Portal Network](https://www.ethportal.net/), amely képes adatot szolgáltatni a könnyű klienseknek a peer-to-peer pletykaprotokollt használva. + +Más tételek az [ütemtervből](/roadmap/), mint a [Verkle-fák](/roadmap/verkle-trees/) és a [státuszmentesség](/roadmap/statelessness/) végül ugyanazt a biztonsági garanciát fogják elhozni a könnyű klienseknek, mint amilyennel teljes kliensek rendelkeznek. + +## További olvasnivaló {#further-reading} + +- [Felföldi Zsolt a Geth könnyű kliensekről](https://www.youtube.com/watch?v=EPZeFXau-RE) +- [Etan Kissling a könnyű kliens networkingről](https://www.youtube.com/watch?v=85MeiMA4dD8) +- [Etan Kissling a könnyű kliensekről az egyesítés (Merge) után](https://www.youtube.com/watch?v=ZHNrAXf3RDE) +- [Piper Merriam: A működő könnyű kliensekhez vezető kanyargós ösvény](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" new file mode 100644 index 00000000000..ebe15f5ec10 --- /dev/null +++ "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" @@ -0,0 +1,57 @@ +--- +title: Csomópont-architektúra +description: Bevezetés az Ethereum-csomópontok szerveződésébe. +lang: hu +--- + +Egy Ethereum-csomópont két kliensből áll: egy [végrehajtási kliensből](/developers/docs/nodes-and-clients/#execution-clients) és egy [konszenzusos kliensből](/developers/docs/nodes-and-clients/#consensus-clients). + +Amikor az Ethereum a [proof-of-work (munkaigazolás)](/developers/docs/consensus-mechanisms/pow/) mechanizmusát használta, akkor a végrehajtási kliens elegendő volt egy teljes Ethereum-csomópont futtatásához. A [proof-of-stake (letétigazolás)](/developers/docs/consensus-mechanisms/pow/) mechanizmusának bevezetésétől a végrehajtási kliens egy másik szoftverrel együtt kell működtetni, amely a [konszenzusos kliens](/developers/docs/nodes-and-clients/#consensus-clients). + +Ez az ábra a két Ethereum-kliens kapcsolatát mutatja. A két kliens a saját megfelelő peer-to-peer (P2P), azaz társak közötti hálózatához kapcsolódik. Külön P2P hálózatra van szükségük, mert a végrehajtási kliens a saját hálózatán terjeszti a „pletykát” a tranzakciókról, hogy azok a kliensek helyi tranzakciógyűjtőjébe kerülhessenek, miközben a konszenzusos kliens a saját hálózatán a blokkokról „pletykál”, mellyel konszenzust és láncnövekedést ér el. + +![](node-architecture-text-background.png) + +Ahhoz, hogy ez a két kliensből álló struktúra működni tudjon, a konszenzusos klienseknek tranzakciókötegeket kell átadni a végrehajtási kliensnek. Ahogy a kliens ezeket a tranzakciókat lokálisan végrehajtja, le tudja ellenőrizni, hogy nem sértenek-e semmilyen Ethereum szabályt, illetve a javasolt Ethereum státusz korrekt-e. Ehhez hasonlóan, amikor az adott csomópont válik a blokképítővé, akkor a konszenzusos kliensnek tranzakciókötegeket kell kérnie a Geth-től, hogy azokat az új blokkba betegye és végrehajtsa, hogy frissíteni tudja a globális státuszt. Ez a kliensek közötti kommunikáció egy helyi RPC-kapcsolaton keresztül megy végbe az [motor API-t](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) használva. + +## Mit csinál a végrehajtási kliens? {#execution-client} + +A végrehajtási kliens feladata a tranzakciók kezelése, a tranzakciókról való pletykálás, a státusz kezelése és az Ethereum virtuális gép ([EVM](/developers/docs/evm/)) támogatása. Ugyanakkor **nem** felel a blokképítésért, a blokkról való pletykáért vagy a konszenzuslogika kezeléséért. Ezek a konszenzusos kliens feladatai. + +A végrehajtási kliens végrehajtási csomagokat készít, melynek része a tranzakciók listája, a frissített státuszfa és más végrehajtással kapcsolatos adatok. A konszenzusos kliens a végrehajtási csomagot teszi bele a blokkba. A végrehajtási kliens azért is felel, hogy az új blokkok tranzakcióit újrafuttatva biztosítsa azok érvényességét. A tranzakciók újrafuttatása a végrehajtási kliens beépített számítógépén történik, melyet [Ethereum virtuális gépként (EVM)](/developers/docs/evm) ismerünk. + +A végrehajtási kliens emellett egy felhasználói felületet is ajánl az Ethereumnak az [RPC-módszerek](/developers/docs/apis/json-rpc) révén, mellyel a felhasználók adatokhoz juthatnak az Ethereum-blokkláncról, tranzakciókat küldhetnek be és okosszerződéseket hozhatnak létre. Az RPC-kapcsolatot általában egy olyan könyvtár kezeli, mint a [Web3js](https://docs.web3js.org/), [Web3py](https://web3py.readthedocs.io/en/v5/), vagy egy olyan felhasználói felület, mint egy böngészőbővítménnyel rendelkező tárca. + +Összefoglalva a végrehajtási kliens: + +- az Ethereumhoz való hozzáférés a felhasználók számára +- az Ethereum virtuális gép, az Ethereum státusz és a tranzakciógyűjtő helye. + +## Mit csinál a konszenzusos kliens? {#consensus-client} + +A konszenzusos kliens azokat a logikákat kezeli, amellyel a csomópont szinkronban marad az Ethereum-hálózattal. Ebbe beletartozik az, hogy blokkokat kap a társaitól és futtatja az elágazási algoritmust, hogy biztosítsa, a csomópont mindig a láncot követi a tanúsítások lehető legnagyobb hányadát összegyűjtve (melyet a validátor aktuális egyenlege súlyoz). A végrehajtási klienshez hasonlóan a konszenzusos klienseknek is saját P2P hálózata van, melyen keresztül megosztják a blokkokat és a tanúsításokat. + +A konszenzusos kliens nem vesz részt a tanúsításban vagy a blokkelőterjesztésben, mivel ezt a validátor teszi, ami egy opcionális, hozzáadott program a konszenzusos klienshez. A konszenzusos kliens validátor nélkül csak azzal foglalkozik, hogy fenntartsa a lánc elejét, vagyis legutóbbi állapotát, hogy a csomópont szinkronizálva maradjon. Ennélfogva a felhasználó képes az Ethereummal a végrehajtási kliensen keresztül kapcsolódni, és biztos lehet abban, hogy azt a megfelelő láncon teszi. + +## Validátorok {#validators} + +A csomópont működtetői hozzáadhatnak egy validátort a konszenzusos klienseikhez azzal, hogy 32 ETH-t letétbe helyeznek a letéti szerződésben. A validátorkliens a konszenzusos klienssel van összecsomagolva, és bármikor hozzá lehet adni egy csomóponthoz. A validátor kezeli a tanúsításokat és a blokkelőterjesztéseket. Lehetővé teszik, hogy a csomópont jutalmakat szerezzen vagy ETH-t veszítsen a büntetések és kizárások révén. A validátorszoftver futtatása megengedi, hogy a csomópont új blokkot is javasolhasson. + +[Bővebben a letétbe helyezésről](/staking/). + +## A csomópontösszehasonlítás elemei {#node-comparison} + +| Végrehajtási kliens | Konszenzusos kliens | Validátor | +| ------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------ | +| A tranzakciókról pletykál a saját P2P hálózatán | A blokkokról és tanúsításokról pletykál a saját P2P hálózatán | Blokkot javasol | +| Végrehajt vagy újra végrehajt tranzakciókat | Az elágazási algoritmust futtatja | Jutalmakat/büntetéseket szerez | +| Ellenőrzi a bejövő státuszváltozásokat | A lánc elejét, vagyis legfrissebb állapotát követi | Tanúsításokat végez | +| Kezeli a státuszhoz és a visszaigazolásokhoz tartozó fastruktúrákat | A Beacon-státuszt kezeli (ami konszenzusos és végrehajtási infókat tartalmaz) | 32 ETH letétbe helyezése szükséges hozzá | +| Végrehajtási csomagokat készít | A felhalmozott véletlenszerűséget trekkeli a RANDAO-ban | Súlyos és kizárással járó büntetést kaphat | +| JSON-RPC API-t ad az Ethereummal való kapcsolódáshoz | Az ellenőrzést és véglegesedést trekkeli | | + +## További olvasnivaló {#further-reading} + +- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos) +- [Blokkjavaslat](/developers/docs/consensus-mechanisms/pos/block-proposal) +- [A validátor jutalmai és büntetései](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" new file mode 100644 index 00000000000..299af6a2d47 --- /dev/null +++ "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" @@ -0,0 +1,419 @@ +--- +title: Csomópontok, mint szolgáltatás +description: Belépőszintű áttekintés a csomópontszolgáltatásokról, az előnyökről és hátrányokról, valamint a népszerű szolgáltatókról. +lang: hu +sidebarDepth: 2 +--- + +## Bevezetés {#Introduction} + +A saját [Ethereum csomópont](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) futtatása kihívás lehet, különösen az induláskor, vagy amikor gyorsan növekszik. [Számos szolgáltatás van](#popular-node-services), mely optimizált csomópontinfrastruktúrát futtat a felhasználónak, így ő inkább az alkalmazás vagy termék fejlesztésére összpontosíthat. A továbbiakban feltárjuk, hogyan működnek a csomópontszolgáltatások, mik a használatuk előnyei és hátrányai, valamint bemutatjuk a szolgáltatókat, ha szeretne ilyet igénybe venni. + +## Előfeltételek {#prerequisites} + +Ha most ismerkedik a témával, akkor először nézze meg a [Csomópontok és kliensek](/developers/docs/nodes-and-clients/) című anyagot. + +## Letétbe helyezők {#stakoooooooooooooors} + +Az önálló letétbe helyezők inkább saját infrastruktúrát kell futtassanak, mint hogy egy harmadik fél által nyújtott szolgáltatásra támaszkodnának. Ez azt jelenti, hogy egy végrehajtási klienst kell futtatni egy konszenzusos klienssel együtt. Az [egyesítés (Merge)](/roadmap/merge) előtt lehetséges volt csak egy konszenzusos kliens futtatása és egy központi szolgáltató nyújtotta a végrehajtási adatot, de ez már nem működik, az önálló letétbe helyezőnek mind a két klienst működtetnie kell. Ugyanakkor vannak olyan szolgáltatások, melyek megkönnyítik ezt. + +[Bővebben a csomópont futtatásáról](/developers/docs/nodes-and-clients/run-a-node/). + +Ezen az oldalon olyan szolgáltatásokat mutatunk be, amelyek a nem letétbe helyező csomópontokra vonatkoznak. + +## Hogyan működnek a csomópont-szolgáltatások? {#how-do-node-services-work} + +A csomópont-szolgáltatók elosztott csomópontklienseket futtatnak a háttérben, így a felhasználónak nem kell. + +Ezek a szolgáltatások általában egy API-kulcsot adnak, amivel a felhasználó írhat a blokkláncra és olvashat onnan. Gyakran biztosítanak hozzáférést az [Ethereum teszthálózatokhoz](/developers/docs/networks/#ethereum-testnets) a főhálózat mellett. + +Egyes szolgáltatások olyan dedikált csomópontot kínálnak, amelyet egyedül az Ön számára tartanak fenn, míg mások terheléselosztókat használnak a tevékenység elosztására a csomópontok között. + +Szinte az összes csomópont-szolgáltatás rendkívül könnyen integrálható, egy sornyi változtatással jár a kódban, hogy kicserélje az önállóan üzemeltetett csomópontot, vagy a szolgáltatások között váltson. + +A csomópont-szolgáltatók gyakran különféle [csomópontklienseket](/developers/docs/nodes-and-clients/#execution-clients) és [-típusokat](/developers/docs/nodes-and-clients/#node-types) futtatnak, lehetővé téve ezzel a teljes vagy archív csomópontok elérését amellett, hogy kliensspecifikus metódusokat érnek el egy API-ban. + +Fontos megjegyezni, hogy a csomópont-szolgáltatások nem tárolják és nem is tárolhatják a privát kulcsokat vagy az adatokat. + +## Mik az előnyei a csomópont-szolgáltatások használatának? {#benefits-of-using-a-node-service} + +A csomópontszolgáltatás használatának legfőbb előnye, hogy Önnek a programozás mellett nem kell időt töltenie a csomópontok fenntartásával és kezelésével. Ez lehetővé teszi, hogy a termék építésére összpontosítson, és ne aggódjon az infrastruktúra karbantartása miatt. + +Saját csomópontok futtatása igen költséges lehet, figyelembe véve a tárhelyet, sávszélességet és a ráfordított, értékes programozási időt. Az olyan dolgok, mint a több csomópont felállítása a méretezéskor, a csomópontok frissítése a legújabb verziókra és a státusz konzisztenciájának biztosítása, elvonhatják a fejlesztőt a kívánt web3-termék építésétől és csökkentik a ráfordított erőforrásokat. + +## Mik a hátrányai a csomópont-szolgáltatások használatának? {#cons-of-using-a-node-service} + +A csomópontszolgáltatás használatával a felhasználó központosítja az általa fejlesztett termék infrastrukturális aspektusát. Ezért azok a projektek, amelyek a decentralizációt tartják kiemelt fontosságúnak, előnyben részesíthetik az saját fenntartású csomópontokat szemben egy harmadik fél szolgáltatásával. + +Tudjon meg többet a [saját csomópont üzemeltetésének előnyeiről](/developers/docs/nodes-and-clients/#benefits-to-you). + +## Népszerű csomópont-szolgáltatások {#popular-node-services} + +Az alábbiak a legnépszerűbb Ethereum-csomópontszolgáltatók – ha ismer olyat, amit ajánlana, akkor adja hozzá! Minden csomópont-szolgáltatás különböző előnyöket és szolgáltatásokat kínál az ingyenes vagy fizetett szintek mellett. A döntés meghozatala előtt meg kell vizsgálnia, hogy melyik felel meg legjobban az igényeinek. + +- [**Alchemy**](https://alchemy.com/) + - [Dokumentáció](https://docs.alchemyapi.io/) + - Jellemzők + - A legnagyobb ingyenes opció 300 M számítási egység havonta (kb. 30 M getLatestBlock-lekérdezés) + - Több blokklánc támogatása a Polygon, Starknet, Optimism, Arbitrum részére + - A legnagyobb Ethereum dappok és DeFi tranzakciómennyiségek 70%-át lefedi + - Valós idejű webhook-figyelmeztetés az Alchemy Notify révén + - Kiváló támogatás, valamint megbízhatóság és stabilitás + - Alchemy NFT API + - Irányítópult, melynek része a Request Explorer, Mempool Watcher és a Composer + - Integrált teszthálózati csaphozzáférés + - Aktív Discord építőközösség 18 000 felhasználóval + +- [**All That Node**](https://allthatnode.com/) + - [Dokumentáció](https://docs.allthatnode.com/) + - Jellemzők + - Napi 50 000 kérés az ingyenes opcióban + - Több mint 40 protokoll támogatása + - JSON-RPC (EVM, Tendermint), REST és Websocket API-ok támogatása + - Korlátlan hozzáférés az archív adatokhoz + - A hét minden napján, napi 24 órában rendelkezésre álló technikai támogatás és 99,9%-nál nagyobb rendelkezésre állás + - Elérhető csap több láncon is + - Korlátlan végponthozzáférés korlátlan számú API-kulccsal + - Trace/Debug API támogatás + - Automatikus frissítések + +- [**Amazon Managed Blockchain**](https://aws.amazon.com/managed-blockchain/) + - [Dokumentáció](https://aws.amazon.com/managed-blockchain/resources/) + - Jellemzők + - Teljeskörűen kezelt Ethereum csomópontok + - Hat régióban elérhető + - JSON-RPC HTTP-n és biztonságos WebSockets-en + - Három láncot támogat + - SLA-k, AWS támogatás 24/7 + - Go-ethereum és Lighthouse + +- [**Ankr**](https://www.ankr.com/) + - [Dokumentáció](https://docs.ankr.com/) + - Jellemzők + - Az Ankr-protokollnak több mint 8 láncra van nyílt hozzáférése a publikus RPC API-végpontokhoz + - Terheléselosztás és a csomópont állapotának felügyelete annak érdekében, hogy a felhasználó gyorsan és megbízható módon elérje a legközelebbi csomópontot + - Prémium opció, amely WSS-végpontot és korlátlan rátát biztosít + - Teljes és validátor-csomópont beállítása egyetlen kattintással több mint 40 láncra + - Menet közbeni méretezés + - Analitikai eszközök + - Irányítópult (dashboard) + - RPC, HTTPS és WSS végpontok + - Közvetlen támogatás + +- [**Blast**](https://blastapi.io/) + - [Dokumentáció](https://docs.blastapi.io/) + - Jellemzők + - RPC- és WSS-támogatás + - Többrégiós csomópont-szolgáltatás + - Decentralizált infrastruktúra + - Publikus API + - Dedikált ingyenes csomag + - Több láncra (>17) vonatkozó támogatás + - Archív csomópontok + - Napi 24 órás Discord támogatás a hét minden napján + - Napi 24 órás felügyelet és riasztások a hét minden napján + - Összességében 99,9% SLA + - Fizetési lehetőség kriptóban + +- [**BlockDaemon**](https://blockdaemon.com/) + - [Dokumentáció](https://ubiquity.docs.blockdaemon.com/) + - Előnyök + - Vezérlőpult + - Csomópontként + - Elemzések + +- [**BlockPI**](https://blockpi.io/) + - [Dokumentáció](https://docs.blockpi.io/) + - Jellemzők + - Robosztus és elosztott csomópontstruktúra + - Akár 40 HTTPS és WSS-végpont + - Ingyenes kezdőcsomag és havi csomag + - Nyomonkövetési módszer + archív adattámogatás + - A csomagok 90 napig érvényesek + - Személyre szabott csomag és menet közbeni fizetés + - Fizetési lehetőség kriptóban + - Közvetlen és technikai támogatás + +- [**Chainbase**](https://www.chainbase.com/) + - [Dokumentáció](https://docs.chainbase.com) + - Jellemzők + - Elérhető, gyors és skálázható RPC szolgáltatás + - Több láncot lefedő támogatás + - Ingyenes díjszabások + - Felhasználó barát irányítópult + - Blokklánc-adatszolgáltatás az RPC-n túl + +- [**Chainstack**](https://chainstack.com/) + - [Dokumentáció](https://docs.chainstack.com/) + - Jellemzők + - Ingyenes megosztott csomópontok + - Megosztott archív csomópontok + - GraphQL-támogatás + - RPC- és WSS-végpontok + - Dedikált teljes és archív csomópontok + - Gyors szinkronizálási idő a dedikált bevezetésekre + - Saját felhőt hozhat + - Óránkénti árazás + - Közvetlen, napi 24 órás támogatás a hét minden napján + +- [**DataHub**](https://datahub.figment.io) + - [Dokumentáció](https://docs.figment.io/) + - Jellemzők + - Ingyenes opció 3 000 000 havi lekéréssel + - RPC- és WSS-végpontok + - Dedikált teljes és archív csomópontok + - Automatikus méretezhetőség (mennyiségi kedvezmények) + - Ingyenes archív adatok + - Szolgáltatáselemzések + - Vezérlőpult + - Közvetlen, napi 24 órás támogatás a hét minden napján + - Fizetési lehetőség kriptóban (vállalat) + +- [**DRPC**](https://drpc.org/) + - [Dokumentáció](https://docs.drpc.org/) + - Jellemzők + - Decentralizált RPC-csomópontok + - Több mint 15 csomópont-szolgáltató + - Csomópont-kiegyensúlyozás + - Korlátlan számítási egység havonta az ingyenes opcióban + - Adatellenőrzés + - Személyre szabott végpontok + - Http és WSS-végpontok + - Korlátlan mennyiségű kulcs (ingyenes és fizetett opcióban) + - Rugalmas fallback opciók + - [Publikus végpont](https://eth.drpc.org) + - Ingyenes, megosztott archív csomópontok + +- [**GetBlock**](https://getblock.io/) + - [Dokumentáció](https://getblock.io/docs/get-started/authentication-with-api-key/) + - Jellemzők + - Hozzáférés több mint 40 blokklánc-csomóponthoz + - 40 000 ingyenes napi lekérdezés + - Korlátlan számú API-kulcs + - Gyors kapcsolódási sebesség 1 GB/másodpercnél + - Nyomon követés és archiválás + - Korszerű elemzések + - Automatikus frissítések + - Technikai támogatás + +- [**InfStones**](https://infstones.com/) + - Jellemzők + - Ingyenes opció + - Menet közbeni méretezés + - Elemzések + - Irányítópult (dashboard) + - Egyedi API-végpontok + - Dedikált teljes csomópontok + - Gyors szinkronizálási idő a dedikált bevezetésekre + - Közvetlen, napi 24 órás támogatás a hét minden napján + - Hozzáférés több mint 50 blokklánc-csomóponthoz + +- [**Infura**](https://infura.io/) + - [Dokumentáció](https://infura.io/docs) + - Jellemzők + - Ingyenes opció + - Menet közbeni méretezés + - Fizetős archív adatok + - Közvetlen támogatás + - Irányítópult (dashboard) + +- [**Kaleido**](https://kaleido.io/) + - [Dokumentáció](https://docs.kaleido.io/) + - Jellemzők + - Ingyenes kezdőopció + - Ethereum-csomópont beállítása egyetlen kattintással + - Személyre szabható kliensek és algoritmusok (Geth, Quorum és Besu || PoA, IBFT és Raft) + - Több mint 500 adminisztratív és szolgáltatói API + - RESTful-interfész az Ethereum-tranzakciók beküldésére (Apache Kafka támogatott) + - Kimenő adatfolyamok esemény-végrehajtáshoz (Apache Kafka támogatott) + - Kimerítő láncon kívüli adatok és kiegészítő szolgáltatások (pl. kétoldalú titkosított üzentátadás) + - Egyértelmű becsatlakozás a hálózatba irányítással és szerepkör szerinti hozzáféréskontroll + - Szofisztikált felhasználókezelés az adminisztrátorok és a végfelhasználók felé is + - Nagy mértékben skálázható, rugalmas, vállalati szintű infrastruktúra + - Felhőalapú HSM privátkulcs-kezelés + - Ethereum főhálózathoz kötött + - ISO 27k és SOC 2, Type 2 tanúsítványok + - Dinamikus runtime-konfiguráció (pl. felhőintegráció hozzáadása, csomópontbemenet-változtatás stb.) + - Támogatja a többfelhős, többrégiós és hibrid telepítési beállításokat + - Egyszerű, óránkénti SaaS-alapú árazás + - SLA-k és napi 24 órás támogatás a hét minden napján + +- [**Lava-hálózat**](https://www.lavanet.xyz/) + - [Dokumentáció](https://docs.lavanet.xyz/) + - Jellemzők + - Ingyenes teszthálózathasználat + - Decentralizált redundancia a nagy arányú elérhetőség érdekében + - Nyílt forráskódú + - Teljesen decentralizált SDK + - Ethers.js-integráció + - Intuitív projektmenedzsment interfész + - Konszenzusalapú adatintegritás + - Több láncot lefedő támogatás + +- [**Moralis**](https://moralis.io/) + - [Dokumentáció](https://docs.moralis.io/) + - Jellemzők + - Ingyenes megosztott csomópontok + - Ingyenes, megosztott archív csomópontok + - Adatvédelmi fókuszú (naplózás nélküli szabályzat) + - Láncokon átívelő támogatás + - Menet közbeni méretezés + - Irányítópult (dashboard) + - Egyedi Ethereum SDK + - Egyedi API-végpontok + - Közvetlen, technikai támogatás + +- [**NodeReal MegaNode**](https://nodereal.io/) + - [Dokumentáció](https://docs.nodereal.io/nodereal/meganode/introduction) + - Jellemzők + - Megbízható, gyors és skálázható RPC API-szolgáltatások + - Továbbfejlesztett API a web3-fejlesztőknek + - Több láncot lefedő támogatás + - Ingyenes kezdési lehetőség + +- [**NOWNodes**](https://nownodes.io/) + - [Dokumentáció](https://documenter.getpostman.com/view/13630829/TVmFkLwy) + - Jellemzők + - Hozzáférés több mint 50 blokklánc-csomóponthoz + - Ingyenes API-kulcs + - Blokkfelfedezők + - Az API-válaszidő kevesebb mint 1 másodperc + - A hét minden napján, napi 24 órában rendelkezésre álló támogató csapat + - Személyes számlakezelő + - Megosztott, archív, biztonsági és dedikált csomópontok + +- [**Pocket Network**](https://www.pokt.network/) + - [Dokumentáció](https://docs.pokt.network/home/) + - Jellemzők + - Decentralizált RPC-protokoll és piactér + - Ingyenes opció 1M lekérdezéssel naponta (végpontonként, max. 2) + - [Nyilvános végpontok](https://docs.pokt.network/developers/public-endpoints) + - Letétbe helyezés előtti program (ha 1M napi lekérdezésnél többre van szükség) + - Több mint 15 láncot támogat + - 6400-nál több csomópont szerez POKT-ot az applikációk kiszolgálásából + - Archív csomópont, archív csomópont nyomon követéssel, teszthálózat-csomóponttámogatás + - Ethereum főhálózat csomóponti kliensdiverzitás + - Nincs egyetlen meghibásodási pont + - Nincs kimaradás a szolgáltatásban + - Költséghatékony, nullához közeli tokengazdaságtan (POKT letétbe helyezése egyszer a hálózati szélessávért) + - Nincs havi elsüllyedt költség, eszközzé változtatja az infrastruktúrát + - A terheléseloszlás be van építve a protokollba + - A napi lekérésmennyiséget és az óránkénti csomópontokat a végtelenségig skálázza úgy, ahogy Ön halad előre + - A leginkább privát, cenzúrának ellenálló opció + - Gyakorlati fejlesztőtámogatás + - [Pocket Portal](https://bit.ly/ETHorg_POKTportal) irányítópult és elemzések + +- [**QuickNode**](https://www.quicknode.com) + - [Dokumentáció](https://www.quicknode.com/docs/) + - Jellemzők + - A hét minden napján, napi 24 órában rendelkezésre álló technikai támogatás és fejlesztői Discord-közösség + - Földrajzilag kiegyensúlyozott, többfelhős/-gépes, rövid késleltetésű hálózat + - Több láncra vonatkozó támogatás (Optimism, Arbitrum, Polygon + 11 más) + - Köztes rétegek a gyorsaság és a stabilitás érdekében (call routing, cache, indexálás) + - Okosszerződés-felügyelet a webhookokon keresztül + - Intuitív irányítópult, elemzési készlet, RPC composer + - Fejlett szintű biztonsági jellemzők (JWT, maszkolás, fehérlistázás) + - NFT-adatok és elemzési API + - [SOC2-tanúsítvánnyal](https://www.quicknode.com/security) + - Bárki számára alkalmas, legyen szó fejlesztőkről vagy nagyvállalatokról + +- [**Rivet**](https://rivet.cloud/) + - [Dokumentáció](https://rivet.readthedocs.io/en/latest/) + - Jellemzők + - Ingyenes opció + - Menet közbeni méretezés + +- [**SenseiNode**](https://senseinode.com) + - [Dokumentáció](https://docs.senseinode.com/) + - Jellemzők + - Dedikált és megosztott csomópontok + - Irányítópult (dashboard) + - Az AWS-en kívüli több szolgáltató biztosítja több helyen Latin-Amerikában + - Prysm és Lighthouse kliensek + +- [**SettleMint**](https://console.settlemint.com/) + - [Dokumentáció](https://docs.settlemint.com/) + - Jellemzők + - Ingyenes próba + - Menet közbeni méretezés + - GraphQL-támogatás + - RPC- és WSS-végpontok + - Dedikált teljes csomópontok + - Saját felhőt hozhat + - Analitikai eszközök + - Irányítópult (dashboard) + - Óránkénti árazás + - Közvetlen támogatás + +- [**Tenderly**](https://tenderly.co/web3-gateway) + - [Dokumentáció](https://docs.tenderly.co/web3-gateway/web3-gateway) + - Jellemzők + - Ingyenes opció, mely 25 millió Tenderly egységet tartalmaz havonta + - Ingyenes hozzáférés az előzményadatokhoz + - 8-szor gyorsabb olvasásintenzív terhelés + - 100%-ban konzisztens olvasási hozzáférés + - JSON-RPC-végpontok + - UI-alapú RPC lekérdezésépítő és lekérdezés-előnézet + - Szorosan integrált a Tenderly fejlesztéssel, hibajavítással és tesztelőeszközökkel + - Tranzakciószimulációk + - Használatelemzés és szűrés + - Könnyű hozzáférésikulcs-kezelés + - Dedikált programozói támogatás csevegés, e-mail és Discord által + +- [**Tokenview**](https://services.tokenview.io/) + - [Dokumentáció](https://services.tokenview.io/docs?type=nodeService) + - Jellemzők + - A hét minden napján, napi 24 órában rendelkezésre álló technikai támogatás és fejlesztői Telegram-közösség + - Több láncot támogat (Bitcoin, Ethereum, Tron, BNB Smart Chain, Ethereum Classic) + - RPC- és WSS-végpontok nyitott használata + - Korlátlan hozzáférés az archív adatot szolgáltató API-hoz + - Dashboard Request Explorer és Mempool Watcher funkcióval + - NFT-adatszolgáltató API és Webhook figyelmeztetés + - Fizetési lehetőség kriptóban + - Külső támogatás az extra funkcionális igényekhez + +- [**Watchdata**](https://watchdata.io/) + - [Dokumentáció](https://docs.watchdata.io/) + - Jellemzők + - Adatmegbízhatóság + - Megszakításmentes kapcsolat nulla leállással + - Folyamatautomatizálás + - Ingyenes díjszabások + - Magasan meghúzott határok, melyek mindenféle felhasználóhoz illeszkednek + - Támogatás a különféle csomópontok számára + - Erőforrás-méretezhetőség + - Gyors feldolgozási sebesség + +- [**ZMOK**](https://zmok.io/) + - [Dokumentáció](https://docs.zmok.io/) + - Jellemzők + - Front-running mint szolgáltatás + - Globális tranzakciógyűjtőhely kereső/szűrőmódszerekkel + - Korlátlan TX díj és végtelen gáz a tranzakcióküldéshez + - A leggyorsabban szerzi meg az új blokkot és olvassa a blokkláncot + - Az API hívásonkénti legjobb ár garantált + +- [**Zeeve**](https://www.zeeve.io/) + - [Dokumentáció](https://www.zeeve.io/docs/) + - Jellemzők + - Vállalatszintű, kódnélküli automatizációs platform, ami a blokklánc-csomópontok és hálózatok telepítését, felügyeletét és menedzselését biztosítja + - Több mint 30 támogatott protokoll és integráció, és még több jön + - Értékes web3-infrastruktúraszolgáltatások, mint a decentralizált tárhely, decentralizált identitás és a blokkláncfőkönyv-adatszolgáltató API-k valódi felhasználási módokra + - A hét minden napján, napi 24 órában rendelkezésre álló támogatás és proaktív felügyelet, amely mindenkor biztosítja a csomópontok egészségét. + - RPC-végpontok, melyek hitelesített hozzáférést kínálnak az API-okhoz, valamint problémamentes kezelést biztosítanak az intuitív irányítópultokkal és elemzésekkel. + - Egyaránt biztosít a cég által adott felhő és a felhasználó saját felhőjével működő opciókat, és támogatja a legtöbb felhőszolgáltatót, mint AWS, Azure, Google Cloud, Digital Ocean és a helyszíni megoldásokat. + - Intelligens routing, hogy a felhasználóhoz legközelebbi csomópontot tudja használni + + +## További olvasnivaló {#further-reading} + +- [Az Ethereumcsomópont-szolgáltatások listája](https://ethereumnodes.com/) + +## Kapcsolódó témák {#related-topics} + +- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) + +## Kapcsolódó útmutatók {#related-tutorials} + +- [Bevezetés az Ethereum fejlesztésbe Alchemy-vel](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) +- [Útmutató tranzakció küldéshez a web3 és az Alchemy használatával](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" new file mode 100644 index 00000000000..d3161ec3889 --- /dev/null +++ "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" @@ -0,0 +1,480 @@ +--- +title: Pörgesse fel saját Ethereum-csomópontját +description: Általános bevezető az Ethereum-kliens saját példányának működtetéséről. +lang: hu +sidebarDepth: 2 +--- + +A saját csomópont működtetése számos előnnyel jár, új lehetőségeket nyit meg, és emellett támogatja az ökoszisztémát. Ez az áttekintés a saját csomópont felpörgetéséről szól, illetve arról, hogyan vegyen részt az Ethereum tranzakciók validálásában. + +Fontos megérteni, hogy az [egyesítés (Merge)](/roadmap/merge) után két kliensre van szükség egy Ethereum-csomópont működtetéséhez: egy **végrehajtási réteg (EL)** és egy **konszenzusréteg (CL)** kliensre. Itt azt mutatjuk be, hogy ezt a két klienst hogyan kell telepíteni, konfigurálni és összekapcsolni az Ethereum-csomópont futtatásához. + +## Előfeltételek {#prerequisites} + +Először is tisztában kell lennie azzal, hogy mi az az Ethereum-csomópont, és mi a lényege annak, hogy klienst futtasson. Ezt megtalálja a [Csomópontok és kliensek](/developers/docs/nodes-and-clients/) című leírásban. + +Ha Önnek újdonság a csomópontok témaköre, vagy egy kevésbé technikai megközelítést szeretne, akkor azt javasoljuk, először tekintse meg az [Ethereum-csomópont futtatása](/run-a-node) című felhasználóbarát ismertetőnket. + +## A megközelítés kiválasztása {#choosing-approach} + +A csomópont felpörgetésének első lépése a megközelítés kiválasztása. Az igények és lehetőségek alapján el kell dönteni a klienstelepítést (a végrehajtási és a konszenzusos kliensre is), a környezetet (hardver, rendszer) és a kliensbeállítás paramétereit. + +A jelen leírás végigvezeti Önt ezeken a döntéseken, hogy megtalálja a leginkább Önnek való módot a saját Ethereum-példányának működtetésére. + +A klienstelepítés eldöntéséhez nézze meg a főhálózaton elérhető [végrehajtási klienseket](/developers/docs/nodes-and-clients/#execution-clients), [konszenzusos klienseket](/developers/docs/nodes-and-clients/#consensus-clients) és tudjon meg többet a [kliensdiverzitásról](/developers/docs/nodes-and-clients/client-diversity). + +El kell döntenie, hogy a szoftvert inkább a saját [hardverén vagy inkább a felhőben](#local-vs-cloud) futtatja, figyelembe véve a kliensek [igényeit](#requirements). + +A környezet kialakítása után telepítse a kiválasztott klienseket egy [kezdőknek is könnyen használható felülettel](#automatized-setup) vagy [manuálisan](#manual-setup) egy terminállal, ahol haladó opciókkal élhet. + +Amikor a csomópont már működik és szinkronizál, akkor Ön elkezdheti [használni](#using-the-node), de ne feledkezzen meg a [karbantartásról](#operating-the-node) sem. + +![Kliensfelállítás](./diagram.png) + +### Környezet és hardver {#environment-and-hardware} + +#### Helyi gépen vagy felhőben {#local-vs-cloud} + +Az Ethereum-klienseket általános számítógépeken is lehet futtatni, nincs szükség hozzá speciális hardverre, mint amilyenek a bányászathoz való gépek. Ennélfogva számos lehetőség adódik egy csomópont telepítésére a felhasználó igényei szerint. Nézzük meg mindkét opciót, amikor egy helyi, fizikai gépen, és amikor egy felhőszerveren vannak a kliensek: + +- Felhő + - A szolgáltatók szinte állandó szerverműködést és statikus nyilvános IP-címeket ajánlanak + - A dedikált vagy virtuális szerver kényelmesebb lehet, mint sajátot építeni + - Ugyanakkor meg kell bízni egy harmadik félben – a szerverszolgáltatóban + - A teljes csomópont nagyobb tárhelyet igényel, ezért a bérelt szerver ára is magasabb lesz +- Saját hardver + - Bizalomigény-mentesebb és önállóbb megközelítés + - Egyszeri befektetés + - Lehetőség van előre konfigurált gépeket vásárolni + - Fizikailag össze kell rakni, karban kell tartani, és valószínűleg meg kell oldania a géppel és a hálózattal kapcsolatban felmerülő problémákat is + +Mindkét opció más előnyökkel jár. Ha felhőalapú megoldás mellett dönt, akkor a hagyományos felhőalapú szolgáltatók mellett léteznek speciális szolgáltatások a csomópontok telepítésére. Tekintse meg a [Csomópontok mint szolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service/) című oldalt a csomópont-szolgáltatókról szóló információkért. + +#### Hardver {#hardware} + +Ugyanakkor egy cenzúrának ellenálló, decentralizált hálózat nem függhet a felhő alapú szolgáltatóktól. Ehelyett az ökoszisztémának egészségesebb, ha a felhasználó a saját csomópontját a saját helyi hardverén üzemelteti. [A becslések](https://www.ethernodes.org/networkType/Hosting) szerint a csomópontok nagy aránya fut felhőn, ami felveti az egyetlen hibaforrás lehetőségét. + +Az Ethereum-klienseket a saját számítógépén, laptopján, szerverén vagy akár egy egykártyás számítógépen is üzemeltetheti. Miközben lehetséges a személyi számítógépen működtetni a klienseket, egy csomópont számára dedikált gép jelentősen növeli a teljesítményt és biztonságot, és minimalizálja az Ön elsődleges számítógépére tett hatást is. + +A saját hardver használata igen könnyű is lehet. Vannak egyszerű opciók, de a műszaki területen jártasabb embereknek fejlettebb összeállítások is elérhetők. Tekintsük át az Ethereum-kliensek számítógépen való futtatásához szükséges feltételeket és eszközöket. + +#### Követelmények {#requirements} + +A hardverkövetelmények kliensenként eltérők, de általánosságban nem magasak, mivel a csomópontnak csak szinkronizálva kell lennie. Nem összekeverendő a bányászattal, amelynek sokkal magasabb számításiteljesítmény-igénye van. Ugyanakkor a szinkronizációs idő és a teljesítmény javul egy erősebb hardverrel. + +Mielőtt telepítene egy klienst, győződjön meg arról, hogy a számítógépe rendelkezik elegendő erőforrással. A minimális és az ajánlott követelményeket alább találja. + +A hardver szűk keresztmetszete leginkább a lemezterület. Az Ethereum blokklánccal való szinkronizálás igen bemenet/kimenet-intenzív folyamat, és sok helyet igényel. A legjobb a **tartós állapotú meghajtó (SSD)**, melyen még a szinkronizálás után is marad sok száz GB-nyi szabad tárhely. + +Az adatbázis mérete és a kezdeti szinkronizálás sebessége függ a kiválasztott klienstől, annak konfigurációjától és a [szinkronizálási stratégiától](/developers/docs/nodes-and-clients/#sync-modes). + +Emellett arról is meg kell győződnie, hogy az internetkapcsolatát nem korlátozza egy [sávszélességi maximum](https://wikipedia.org/wiki/Data_cap). A korlátlan kapcsolódás az ajánlott, mert a kezdeti szinkronizálás és az adat nyilvánossá tétele a hálózaton meg fogja haladni a határt. + +##### Operációs rendszer + +Minden kliens támogatja a legnagyobb operációs rendszereket, mint a Linux, ,macOS, Windows. Tehát a csomópontok működtetéséhez a számítógépén vagy a szerverén olyan operációs rendszert (OS) használ, amilyet szeretne. Biztosítsa, hogy az operációs rendszer frissítve van, hogy ezzel elkerülje a lehetséges hibákat és biztonsági gyengeségeket. + +##### Minimális követelmények + +- Processzor (CPU) 2+ maggal +- 8 GB RAM +- 2 TB SSD +- 10+ MBit/másodperc sávszélesség + +##### Ajánlott követelmények + +- Gyors processzor (CPU) 4+ maggal +- 16 GB+ RAM +- Gyors SSD 2+ TB kapacitással +- 25+ MBit/másodperc sávszélesség + +A szinkronizálási mód és a kiválasztott kliens befolyásolja a lemezterület-igényt, alább a kliensek szerinti becslést láthatja. + +| Kliens | Lemezterület (snap szinkronizálás) | Lemezterület (teljes archívum) | +| ---------- | ---------------------------------- | ------------------------------ | +| Besu | 800 GB+ | 12 TB+ | +| Erigon | N.a. | 2,5 TB+ | +| Geth | 500 GB+ | 12 TB+ | +| Nethermind | 500 GB+ | 12 TB+ | +| Reth | N.a. | 2,2 TB+ | + +- Megjegyzés: az Erigon és a Reth nem ajánl snap szinkronizálási módot, de lehetséges a teljes adatmegvágás (kb. 2 TB az Erigonnál, 1,2 TB a Rethnél) + +A konszenzusos kliens esetében a lemezterület szintén függ a telepítéstől és a beállított jellemzőktől (pl. validátor büntető/kizáró funkció), de általánosságban egy újabb 200 GB-ra van szükség a beacon-adathoz. Sok validátorral a sávszélesség terhelése is növekszik. Ebben az elemzésben [megtalálja a konszenzuskliens követelmények részleteit](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc). + +#### Plug-and-play megoldások {#plug-and-play} + +A saját csomópont futtatása saját hardverrel úgy a legegyszerűbb, ha plug and play csomagot használunk. Az előre beállított gépeknél nem kell mást tenni, mint megrendelni, csatlakoztatni és használni. Minden előre be van konfigurálva és magától fut egy intuitív útmutatóval és a szoftver felügyeletére és irányítására szolgáló irányítópulttal. + +- [DappNode](https://dappnode.io/) +- [Avado](https://ava.do/) + +#### Ethereum egy egykártyás számítógépen {#ethereum-on-a-single-board-computer} + +Egyszerű és olcsó módja egy Ethereum-csomópont futtatásának ha egykártyás számítógépet használunk, akár ARM architektúrával, mint a Raspberry Pi. Az [Ethereum az ARM-on](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) több végrehajtási és konszenzusos kliens egyszerűen futtatását teszi lehetővé a Raspberry Pi és más ARM-kártyák számára. + +Ezek a kicsi, pénztárcabarát és hatékony eszközök ideálisak a csomópont otthoni futtatására, de a teljesítményük korlátozott lehet. + +## A csomópont felpörgetése {#spinning-up-node} + +Az aktuális kliensfelállítás végezhető automata telepítőkkel vagy manuálisan, közvetlenül telepítve a kliensszoftvert. + +A kevésbé szakértő felhasználók számára az automatikus telepítés a legjobb megoldás, mivel ez a szoftver végigvezeti őket az telepítésen, a kliensbeállításokat pedig magától intézi. Ugyanakkor, akinek van már tapasztalata a terminál használatában, az a manuális beállítás lépéseit is követheti. + +### Vezetett felállítás {#automatized-setup} + +Számos felhasználóbarát projekt arra törekszik, hogy leegyszerűsítse a kliens felállítását. Ezek a bevezetők automatikus klienstelepítést és -konfigurálást kínálnak, emellett néha grafikus felületet is biztosítanak a vezetett beállításhoz és a felügyelethez. + +Több ilyen projektet is találhat alább, melyek segítenek néhány kattintással telepíteni és felügyelni a klienseket: + +- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - A DappNode nem csak a gyártótól származó géppel kapható. A szoftvert, a csomópont-telepítőt és a számos jellemzővel bíró irányítási központot tetszőleges hardveren is használhatja. +- [eth-docker](https://eth-docker.net/) – Az automatikus beállítás a Docker használatával arra fókuszál, hogy egyszerű és biztonságos legyen a letétbe helyezés – egy alapvető terminál és Docker-ismeret szükséges hozzá, ezért a haladóbb felhasználóknak ajánlott. +- [Stereum](https://stereum.net/ethereum-node-setup/) – Telepítő a kliens távoli szerveren, SSH-kapcsolódáson keresztüli telepítéséhez egy GUI beállítási útmutatóval, irányítási központtal és számos egyéb jellemzővel. +- [NiceNode](https://www.nicenode.xyz/) – Telepítő az egyértelmű felhasználói élményért, amely leírja, hogyan futtasson csomópontot saját számítógépén. Csak válassza ki a klienseket, és néhány kattintással indítsa el azokat. Még fejlesztés alatt áll. +- [Sedge](https://docs.sedge.nethermind.io/docs/intro) – Csomópont-felállítási eszköz, amely automatikusan generál egy Docker-konfigurációt a CLI-varázslót használva. Go nyelven írta a Nethermind. + +### Manuális kliensfelállítás {#manual-setup} + +Ez a másik lehetőség, hogy a kliensszoftvert manuális letöltse, ellenőrizze és konfigurálja. Még ha bizonyos kliensek ajánlanak is grafikus felületet, a manuális beállításhoz szükség van alapvető terminálismeretekre, de közben nagy mértékű rugalmasságot tesznek lehetővé. + +Ahogy említettük, az Ethereum-csomópont működtetéséhez egy konszenzusos kliens és egy végrehajtási kliens szükséges. Néhány kliens tartalmazhat másik típusú könnyű klienst és előfordulhat, hogy a szinkronizáláshoz sem kell más szoftver. Ugyanakkor a teljes, bizalomigény-mentes ellenőrzéshez mindkét klienst telepíteni kell. + +#### A kliensszoftver megszerzése {#getting-the-client} + +Először meg kell szerezni a kiválasztott [végrehajtási kliens](/developers/docs/nodes-and-clients/#execution-clients) és [konszenzusos kliens](/developers/docs/nodes-and-clients/#consensus-clients) szoftverét. + +Egyszerűen töltsön le egy végrehajtható alkalmazást vagy egy telepítőcsomagot, ami megfelel az operációs rendszernek és az architektúrának. Mindig ellenőrizze az aláírásokat és a letöltött csomagok ellenőrző összegét. Néhány kliens mappákat vagy Docker képeket is ajánl az egyszerűbb telepítés és frissítések érdekében. Minden kliens nyílt forráskódú, tehát Ön is építhet egyet a forrásból. Ez egy sokkal haladóbb módszer, de néhány esetben szükség lehet rá. + +A telepítési utasításokat megtalálja a klienshez kapcsolódó dokumentációban. + +Ezek a kliensek kiadási oldalai, ahol az előre megépített binárisok vagy instrukciók találhatók: + +##### Végrehajtásos kliensek + +- [Besu](https://github.com/hyperledger/besu/releases) +- [Erigon](https://github.com/ledgerwatch/erigon/releases) +- [Geth](https://geth.ethereum.org/downloads/) +- [Nethermind](https://downloads.nethermind.io/) +- [Reth](https://reth.rs/installation/installation.html) + +Fontos tisztában lenni azzal is, hogy a kliensdiverzitás [problémát jelent a végrehajtási rétegen](/developers/docs/nodes-and-clients/client-diversity/#execution-layer). Önnek is azt javasoljuk, hogy futtasson kisebbségi végrehajtási klienst. + +##### Konszenzusos kliensek + +- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest) +- [Lodestar](https://chainsafe.github.io/lodestar/install/source/) (nem ad előre megépített binárist, csak egy Docker-képet vagy fel kell építeni a forrásból) +- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest) +- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest) +- [Teku](https://github.com/ConsenSys/teku/releases) + +A [kliensdiverzitás](/developers/docs/nodes-and-clients/client-diversity/) kritikus a konszenzus-csomópontok esetén, melyek validátort működtetnek. Ha a validátorok többsége egyetlen kliensverziót használ, akkor a hálózat biztonsága veszélybe kerül. Ezért Ön is használjon kisebbségi klienst. + +[Tekintse meg a legfrissebb klienshasználatot](https://clientdiversity.org/), és tudjon meg többet a [kliensdiverzitásról](/developers/docs/nodes-and-clients/client-diversity). + +##### A szoftver ellenőrzése + +A szoftver letöltése után érdemes ellenőrizni annak integritását. Ez opcionális, de ilyen fontos infrastrukturális elemeknél, mint amilyen az Ethereum-kliens, fontos tisztában lenni a támadó vektorokkal és elkerülni azokat. Ha egy előre megépített binárist tölt le, akkor meg kell abban bíznia és kockáztatja, hogy egy támadó kicseréli a végrehajthatót egy ártalmasra. + +A fejlesztők aláírják a kiadott binárisokat a PGP-kulcsokkal, így kriptográfiailag ellenőrizheti, hogy tényleg az a szoftver fut-e, amit ők hoztak létre. Ehhez a fejlesztők által használt publikus kulcsokra van szükség, melyeket a kliens kiadási oldalán vagy a dokumentációban megtalál. Miután letöltötte a kliensprogramot és az aláírást, használjon egy PGP-implementációt, pl. [GnuPG](https://gnupg.org/download/index.html), hogy könnyedén ellenőrizze ezeket. Tekintse meg ezt az útmutatót a nyílt forráskódú szoftver ellenőrzéséről a `gpg` használatával kapcsolatban [linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) vagy [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/) operációs rendszeren. + +Egy másik ellenőrzési lehetőség az, hogy a letöltött szoftver hashe, vagyis egyedi kriptográfiai ujjlenyomata egyezik a fejlesztő által adottal. Ez még a PGP-nél is egyszerűbb, és néhány kliensnél csak ez a lehetőség érhető el. Csak futtassa le a hash funkciót a letöltött szoftverre, és hasonlítsa össze azzal, amit a kiadási oldalon talál. Például: + +```sh +sha256sum teku-22.6.1.tar.gz + +9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde +``` + +#### Kliensfelállítás {#client-setup} + +Miután telepítette, letöltötte vagy összeállította a kliensszoftvert, készen áll a használatra. Ennek lényege, hogy a megfelelő konfigurációkkal kell elindítani. A kliensek bőven kínálnak konfigurációs lehetőségeket, melyek különféle jellemzőket tesznek elérhetővé. + +Kezdjük azokkal az opciókkal, melyek jelentősen befolyásolják a kliens teljesítményét és adathasználatát. A [szinkronizációs módok](/developers/docs/nodes-and-clients/#sync-modes) a blokkláncadat letöltésére és validálására ajánlanak különféle módszereket. A csomópont elindítása előtt el kell dönteni, hogy milyen hálózati és szinkronizálási módokat használjon. A legfontosabb a lemezterület és a szinkronizálási idő, amire a kliensnek szüksége lesz. Nézze meg a kliens dokumentációjában, hogy melyik szinkronizálási mód az alapbeállítás. Ha ez nem felel meg Önnek, akkor válasszon egy másikat a biztonsági szint, az elérhető adatok és a költségek alapján. A szinkronizálási algoritmus mellett a korábbi adatok különféle megvágását is be lehet állítani. Ez a megvágás eltávolítja a nem releváns adatokat, pl. azokat a státuszfaszinteket, melyek a közelmúlt blokkjaiból elérhetetlenek. + +Másik alapvető konfigurációs lehetőség például a hálózat kiválasztása (főhálózat vagy teszthálózat), HTTP-végpont az RPC vagy a WebSockets részére stb. A kliens dokumentációja tartalmaz minden jellemzőt és opciót. Különféle klienskonfigurációkat lehet beállítani azáltal, hogy a klienst a megfelelő jelöléssel futtatják közvetlenül a CLI-ben vagy a konfigurációs fájlban. Minden kliens egy kicsit más, ezért mindig a hivatalos dokumentációból vagy a támogatást nyújtó oldalról szerezze be a konfigurációs lehetőségek részleteit. + +Teszteléshez futtathatja a klienst a teszthálózatok egyikén. [Bővebben a támogatott hálózatokról](/developers/docs/nodes-and-clients/#execution-clients). + +A végrehajtási kliensek alapvető konfigurációit a következő részben találja. + +#### A végrehajtási kliens elindítása {#starting-the-execution-client} + +Mielőtt elindítaná az Ethereum-kliensszoftvert, ellenőrizze, hogy a környezet készen áll. Például: + +- Elég lemezterület áll rendelkezésre a kiválasztott hálózati és szinkronizálási mód szerint. +- A memóriát és a CPU-t nem akasztotta meg más program. +- Az operációs rendszer frissítve van a legutóbbi verzióra. +- A rendszerben a helyes idő és dátum szerepel. +- A router és a tűzfal elfogad kapcsolódásokat a hallgató (listening) portokon keresztül. Alapvetően az Ethereum-kliensek hallgató (TCP) és felfedező (UDP) portot használnak, melynek alapbeállítása 30303. + +Futtassa először teszthálózaton a kliensét, hogy biztosan minden jól működik. + +Minden olyan kliensbeállítást tisztázni kell, mely a kezdőpontban nincs alapból beállítva. A választott konfigurációt a jelölőkkel vagy a konfigurációs fájlban tudja rögzíteni. Minden kliensnél különböznek az elérhető jellemzők és a konfigurációs szintaxisok. A specifikációhoz nézze meg a kliens dokumentációját. + +A végrehajtási és konszenzusos kliensek egy hitelesített végponton keresztül kommunikálnak, mely az [Engine API-ban](https://github.com/ethereum/execution-apis/tree/main/src/engine) van specifikálva. A konszenzusos klienshez való kapcsolódáshoz a végrehajtási kliensnek generálnia kell egy [`jwtsecret`](https://jwt.io/) kódot egy ismert útvonalon. Biztonsági és stabilitási okokból a klienseket ugyanazon a gépen kell működtetni, és mindkettőnek ismernie kell ezt az útvonalat, mert ez hitelesíti a helyi RPC-kapcsolódást közöttük. A végrehajtási kliensnek meg kell határoznia egy hallgató (listening) portot a hitelesített API-khoz. + +Ezt a tokent a kliensszoftver automatikusan létrehozza, de ezt néha manuálisan kell megtenni. Az [OpenSSL](https://www.openssl.org/) révén Ön is létre tudja hozni: + +```sh +openssl rand -hex 32 > jwtsecret +``` + +#### A végrehajtási kliens futtatása {#running-an-execution-client} + +Ez a rész a végrehajtási kliensek elindítását mutatja be. Csak példaként szolgál az alapszintű konfigurációkra, ami a következő beállításokkal indítja el a klienst: + +- Meghatározza a hálózatot, amihez kapcsolódik a kliens; példánkban ez a főhálózat + - Ehelyett használhatja [az egyik teszthálózatot](/developers/docs/networks/) is a beállítások kipróbálására +- Meghatározza az adatkönyvtárat, ahol az összes adat, beleértve a blokkláncot is, le lesz tárolva + - Írja át az útvonalat egy valódira, pl. ami a külső meghajtójára mutat +- Lehetővé teszi, hogy az interfészek kommunikáljanak a klienssel + - Beleértve a JSON-RPC-t és az Engine API-t a konszenzusos klienssel való kommunikációhoz +- Meghatározza a `jwtsecret` kódhoz tartozó útvonalat a hitelesített API-hoz + - Cserélje le a példát egy valódi útvonallal, amit elérnek a kliensek, pl. `/tmp/jwtsecret` + +Ne feledje, hogy ez csak alappélda, az összes beállítás a kezdőértéken marad. Tekintse át a kliensek dokumentációit, hogy megismerje a kezdeti értékeket, beállításokat és jellemzőket. A további jellemzőkért, mint a validátorok futtatása, felügyelete stb. tekintse át az adott kliens dokumentációját. + +> Vegye figyelembe, hogy a perjelek `\` a példákban csak formázásra szolgálnak, a konfigurációs jeleket egy sorban is meg lehet határozni. + +##### A Besu futtatása + +Ez a példa a Besut a főhálózaton indítja el, a blokkláncadatokat az alapértelmezett formátumban tárolja a `/data/ethereum` alatt, engedélyezi a JSON RPC-t és Engine RPC-t a konszenzusos klienssel való kapcsolódáshoz. Az Engine API-t a `jwtsecret` token hitelesíti, és csak a `localhostból` jövő hívások vannak megengedve. + +```sh +besu --network=mainnet \ + --data-path=/data/ethereum \ + --rpc-http-enabled=true \ + --engine-rpc-enabled=true \ + --engine-host-allowlist="*" \ + --engine-jwt-enabled=true \ + --engine-jwt-secret=/path/to/jwtsecret +``` + +A Besu egy telepítő opcióval bír, mely egy sor kérdést tesz fel, majd legenerálja a konfigurációs fájlt. Indítsa el az interaktív telepítőt a következővel: + +```sh +besu --Xlauncher +``` + +A [Besu dokumentációja](https://besu.hyperledger.org/en/latest/HowTo/Get-Started/Starting-node/) további opciókat és konfigurációs részleteket tartalmaz. + +##### Az Erigon futtatása + +Ez a példa az Erigont a főhálózaton indítja el, a blokkláncadatot a `/data/ethereum` alatt tárolja, engedélyezi a JSON-RPC-t, meghatározza a namespace-eket, és engedélyezi a hitelesítést a konszenzusos klienssel való kapcsolódáshoz, amit a `jwtsecret` útvonal határoz meg. + +```sh +erigon --chain mainnet \ + --datadir /data/ethereum \ + --http --http.api=engine,eth,web3,net \ + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +Az Erigon alapból teljes szinkronizálást végez 8 GB HDD-vel, ami több mint 2 TB archív adatot eredményez. Biztosítsa, hogy a `datadir` egy olyan lemezre mutat, ahol elég szabad hely van, vagy állítsa be a `--prune` jelölőt, ami megvágja a különféle adatokat. További információért nézze meg az Erigon `--help` oldalát. + +##### A Geth futtatása + +Ez a példa a Gethet a főhálózaton indítja el, a blokkláncadatokat a `/data/ethereum` alatt tárolja, engedélyezi a JSON-RPC-t, és meghatározza a namespace-eket. Engedélyezi a hitelesítést, hogy a konszenzusos klienssel lehessen kapcsolódni, amihez a `jwtsecret` útvonal szükséges, és azt is megadja, hogy milyen kapcsolódások lehetségesek, jelen példánkban csak a `localhosttól` érkezők. + +```sh +geth --mainnet \ + --datadir "/data/ethereum" \ + --http --authrpc.addr localhost \ + --authrpc.vhosts="localhost" \ + --authrpc.port 8551 + --authrpc.jwtsecret=/path/to/jwtsecret +``` + +Tekintse meg a [dokumentációt az összes konfigurálási opcióhoz](https://geth.ethereum.org/docs/fundamentals/command-line-options), és tudjon meg többet a[Geth futtatása konszenzusos klienssel](https://geth.ethereum.org/docs/getting-started/consensus-clients) témáról. + +##### A Nethermind futtatása + +A Nethermind különféle [telepítési opciókat](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/getting-started) kínál. A csomag számos binárist tartalmaz, beleértve egy Telepítőt, ami egy vezetett felállítást tesz lehetővé, így a konfigurációt interaktív módon lehet létrehozni. Másik megoldásként használhatja a Runner-t is, ami a végrehajtási program maga, és konfigurációs jelölőkkel futtathatja. A JSON-RPC alapból engedélyezve van. + +```sh +Nethermind.Runner --config mainnet \ + --datadir /data/ethereum \ + --JsonRpc.JwtSecretFile=/path/to/jwtsecret +``` + +A Nethermind dokumentációk egy [teljeskörű útmutatót](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge) adnak arról, hogyan lehet a Nethermind-ot konszenzusos klienssel működtetni. + +A végrehajtási kliens elindítja a fő funkcióit, a kiválasztott végpontokat, és társakat keres. Miután sikeresen felfedezte a társait, elkezd szinkronizálni. A végrehajtási kliens kapcsolódásra vár a konszenzusos klienstől. A jelenlegi blokkláncadatok elérhetők lesznek, amint a kliens sikeresen szinkronizál a jelen státuszhoz. + +##### A Reth futtatása + +Ez a példa a Reth-et a főhálózaton indítja el az alapértelmezett adathelyet figyelembe véve. Engedélyezi a JSON-RPC-t és az Engine RPC hitelesítést a `jwtsecret` elérési útvonal által meghatározott konszenzusklienshez való csatlakozáshoz, és csak a `localhost`-ról érkező hívások engedélyezettek. + +```sh +reth node \ + --authrpc.jwtsecret /path/to/jwtsecret \ + --authrpc.addr 127.0.0.1 \ + --authrpc.port 8551 +``` + +Tekintse meg a [Reth konfigurálást](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth), hogy többet megtudjon az alapértelmezett adatkönyvtárakról. [A Reth dokumentációja](https://reth.rs/run/mainnet.html) további opciókat és konfigurációs részleteket tartalmaz. + +#### A konszenzusos kliens elindítása {#starting-the-consensus-client} + +A konszenzusos klienst a megfelelő portkonfigurációval kell indítani, hogy egy lokális RPC-kapcsolatot hozzon létre a végrehajtási klienssel. A konszenzusos klienst a felfedett végrehajtási kliens portjával kell futtatni, mint konfigurációs argumentum. + +A konszenzusos kliensnek szüksége van a végrehajtási kliens `jwt-secret` kódjához vezető útvonalra, hogy hitelesíteni tudja az RPC-kapcsolódást közöttük. A fenti példákhoz hasonlóan, minden konszenzusos kliensnek van egy konfigurációs jelölője, ami argumentumként felveszi a jwt token útvonalát. Ennek konzisztensnek kell lennie a `jwtsecret` útvonallal, melyet a végrehajtási kliens kapott. + +Ha Ön validátort tervez majd futtatni, akkor be kell tennie egy konfigurációs jelölőt a validációs díj címzettjének Ethereum-címét megadva. Ezt az ether jutalmat gyűjti a validátor. Minden konszenzusos kliensnek van egy opciója, pl. `--suggested-fee-recipient=0xabcd1`, hogy az Ethereum címet argumentumként vegye fel. + +Amikor egy Beacon-csomópontot indít a teszthálózaton, jelentős szinkronizálási időt takaríthat meg, ha egy publikus végpontot használ a [Checkpoint sync-re](https://notes.ethereum.org/@launchpad/checkpoint-sync). + +#### Konszenzusos kliens futtatása {#running-a-consensus-client} + +##### A Lighthouse futtatása + +Mielőtt a Lighthouse-t futtatná, ismerje meg, hogyan kell telepíteni és konfigurálni azt a [Lighthouse Könyvből](https://lighthouse-book.sigmaprime.io/installation.html). + +```sh +lighthouse beacon_node \ + --network mainnet \ + --datadir /data/ethereum \ + --http \ + --execution-endpoint http://127.0.0.1:8551 \ + --execution-jwt /path/to/jwtsecret +``` + +##### A Lodestar futtatása + +Telepítse a Lodestar szoftvert összeállítva vagy a Docker-kép letöltésével. Tudjon meg többet a [dokumentációból](https://chainsafe.github.io/lodestar/) és a még részletesebb [felállítási útmutatóból](https://hackmd.io/@philknows/rk5cDvKmK). + +```sh +lodestar beacon \ + --rootDir="/data/ethereum" \ + --network=mainnet \ + --eth1.enabled=true \ + --execution.urls="http://127.0.0.1:8551" \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### A Nimbus futtatása + +A Nimbus egyaránt tartalmaz konszenzusos és végrehajtási klienst. Különféle eszközökön lehet futtatni igen szerény számítási kapacitással. Miután [installálta a hozzá tartozó dolgokat és magát a Nimbust](https://nimbus.guide/quick-start.html), futtathatja a konszenzusos kliensét: + +```sh +nimbus_beacon_node \ + --network=mainnet \ + --web3-url=http://127.0.0.1:8551 \ + --rest \ + --jwt-secret="/path/to/jwtsecret" +``` + +##### A Prysm futtatása + +A Prysm egy szkripttel együtt elérhető, amely egyszerű, automatikus telepítést tesz lehetővé. A részleteket a [Prysm dokumentációban](https://docs.prylabs.network/docs/install/install-with-script) találja. + +```sh +./prysm.sh beacon-chain \ + --mainnet \ + --datadir /data/ethereum \ + --execution-endpoint=http://localhost:8551 \ + --jwt-secret=/path/to/jwtsecret +``` + +##### A Teku futtatása + +```sh +teku --network mainnet \ + --data-path "/data/ethereum" \ + --ee-endpoint http://localhost:8551 \ + --ee-jwt-secret-file "/path/to/jwtsecret" +``` + +Amikor egy konszenzusos kliens kapcsolódik egy végrehajtási klienshez, hogy beolvassa a letéti szerződést és azonosítsa a validátorokat, szintén kapcsolódik más Beacon-csomóponttársakhoz, és elkezdi szinkronizálni a konszenzus-slotokat a genezistől kezdve. Amint a Beacon-csomópont eléri a jelenlegi korszakot (epoch), a Beacon API használhatóvá válik a validátor számára. Bővebben a [Beacon-csomópont API-król](https://eth2docs.vercel.app/). + +### Validátorok hozzáadása {#adding-validators} + +A konszenzusos kliens Beacon-csomópontként működik a validátoroknak, hogy azok kapcsolódni tudjanak. Minden konszenzusos kliensnek saját validátorszoftvere van, melyről a releváns dokumentáció részleteiben beszél. + +A saját validátor futtatása lehetővé teszi az [önálló letétbe helyezést](/staking/solo/), a leginkább hatásos és bizalomigény nélküli módszert, mely az Ethereum hálózatát támogatja. Ehhez azonban szükség van 32 ETH letétre. Ha szeretne validátort futtatni a saját csomópontján egy kisebb összeggel, akkor Önt érdekelheti az engedélyhez nem kötött csomópontműködtetőkből álló decentralizált alapok, mint amilyen a [Rocket Pool](https://rocketpool.net/node-operators). + +A letétbe helyezéssel és a validátorkulcs-generálásával a legkönnyebben a [Holesky Testnet Staking Launchpad](https://holesky.launchpad.ethereum.org/) segítségével kezdhet foglalkozni, amellyel tesztelheti a beállítását a [csomópont futtatása a Holesky-n](https://notes.ethereum.org/@launchpad/holesky) útmutatóval. Amikor készen áll a főhálózatra, akkor ugyanezeket a lépéseket kell megismételnie a [Mainnet Staking Launchpad](https://launchpad.ethereum.org/) segítségével. + +Tekintse át a [letétbe helyezési oldalt](/staking), hogy a letéti opciókról tájékozódjon. + +### A csomópont használata {#using-the-node} + +A végrehajtási kliensek [RPC API végpontokat](/developers/docs/apis/json-rpc/) kínálnak, mellyel tranzakciókat lehet beküldeni, valamint okosszerződésekkel interakcióba lépni vagy telepíteni azokat különféle módokon az Ethereum hálózaton: + +- Manuálisan meghívni azokat egy megfelelő protokollal (pl. a `curl` kódot használva) +- Egy megadott konzolt csatolva (pl. `geth attach`) +- Alkalmazásokban implementálva azokat a web3-könyvtárak segítségével, pl. [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io/ethers.js/) + +A különféle klienseknél eltér az RPC-végpontok telepítése. De van egy standard JSON-RPC, melyet minden klienssel lehet használni. Az áttekintésért [nézze meg a JSON-RPC dokumentációt](/developers/docs/apis/json-rpc/). Az alkalmazások, melyeknek információra van szükségük az Ethereum hálózatáról, ezt az RPC-t használhatják. Például a népszerű MetaMask tárca megengedi, hogy Ön [kapcsolódjon a saját RPC végpontjához](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node), ami erős adatvédelmet és biztonsági előnyöket ad. + +A konszenzusos kliensek mind felfednek egy [Beacon API-t](https://ethereum.github.io/beacon-APIs), amit a kliens státuszának ellenőrzésére vagy a blokkok és konszenzusadatok letöltésére lehet használni, lekérdezéseket küldve olyan eszközökkel, mint amilyen a [Curl](https://curl.se). Bővebben a konszenzusos kliensek dokumentációiban olvashat erről. + +#### RPC elérése {#reaching-rpc} + +Az alapértelmezett port a végrehajtási kliens JSON-RPC számára a `8545`, de a konfigurációban módosítani lehet a lokális végpontok portjait. Alapból az RPC-interfész csak a számítógépének localhost-ján érhető el. A távoli eléréshez fel kell azt fednie nyilvánosan úgy, hogy a címet `0.0.0.0` kódra változtatja. Ettől elérhetővé válik a helyi hálózat és a nyilvános IP-címek számára. A legtöbb esetben porttovábbítást is be kell állítani a routeren. + +Az interneten való port felfedéssel vigyázzon, mert ez bárki számára lehetővé teszi a csomópontjának irányítását. A támadók elérhetik a csomópontot, hogy leállítsák a rendszert vagy ellopják a pénzeszközöket, ha a klienst tárcaként használja. + +Ennek elkerülésére a potenciálisan ártó RPC-módokat megakadályozhatja úgy, hogy azok nem módosíthatók. Például a Geth-tel a módosítható módokat egy jelölővel láthatja el: `--http.api web3,eth,txpool`. + +Az RPC-interfészhez való hozzáférést kiterjesztheti edge layer API-k vagy webszerver-alkalmazások fejlesztésével, mint amilyen a Nginx, és ezeket a kliens lokális címéhez és portjához kapcsolhatja. Egy köztes réteg használata segíthet a fejlesztőknek, hogy hitelesítést állítsanak fel a biztonságos `https` kapcsolódásokhoz az RPC-interfészhez. + +A webszerver, a proxy vagy a kifelé néző Rest API nem az egyedüli módszer arra, hogy a csomópontjának az RPC-végpontjához hozzáférést adjon. Egy nyilvánosan elérhető végpont adatbiztonságot megőrző módja az, hogy a csomópontot a saját [Tor](https://www.torproject.org/) onion szolgáltatásán hosztolja. Így az RPC elérhető a lokális hálózaton kívül, statikus, nyilvános IP-cím vagy egy nyitott port nélkül is. Ugyanakkor ez a beállítás az RPC-végpontot talán csak a Tor hálózaton keresztül teszi elérhetővé, amit nem támogat minden alkalmazást, és ezért kapcsolódási problémákat okozhat. + +Ehhez létre kell hoznia a saját [onion szolgáltatását](https://community.torproject.org/onion-services/). Tekintse meg a [dokumentációt](https://community.torproject.org/onion-services/setup/) az onion szolgáltatás felállításáról ahhoz, hogy a sajátját hosztolja. Ezt egy webszerverhez kapcsolhatja egy proxy-val az RPC-porthoz vagy közvetlenül az RPC-hez. + +Végül az egyik legnépszerűbb mód a belső hálózathoz való hozzáférés-biztosításra a VPN-en keresztüli kapcsolat. Attól függően, hogy Ön mire használja és mennyi felhasználónak akar hozzáférést biztosítani a csomópontjához, a biztonságos VPN-kapcsolat jó opció lehet. Az [OpenVPN](https://openvpn.net/) egy teljes körű SSL VPN, amely OSI layer 2 vagy 3 biztonságos hálózati kiterjesztést implementál az iparági standard SSL/TLS-protokollt használva, támogatja a rugalmas klienshitelesítési módokat bizonyítványok, okoskártyák és/vagy felhasználói név és jelszó alapján, és engedi a felhasználó vagy csoport specifikus hozzáférés-kezelési szabályzatok használatát a tűzfalszabályokat alkalmazva a VPN virtuális interfészére. + +### A csomópont üzemeltetése {#operating-the-node} + +A csomópontot rendszeresen felügyelni kell, hogy az megfelelően működik-e. Emellett esetenként karbantartást kell végezni. + +#### A csomópont online tartása {#keeping-node-online} + +A csomópontnak nem kell mindig online lennie, de érdemes minél többet online tartani, hogy szinkronban legyen a hálózattal. Le lehet állítani azért, hogy újra legyen indítva, de érdemes figyelni arra, hogy: + +- A leállítás eltarthat néhány percig, ha a jelenlegi státusz még íródik a lemezre. +- A kényszerített leállítás következtében sérülhet az adatbázis, ami miatt akár az egész csomópontot újra kell szinkronizálni. +- A kliens nem lesz szinkronban a hálózattal, így az újraindításnál újra kell szinkronizálni. Miközben a csomópont képes onnan szinkronizálni, ahol legutóbb tartott, ez eltarthat egy darabig attól függően, hogy mennyit volt offline. + +_Ez nem vonatkozik a konszenzusréteg validátor-csomópontjaira._ Ekkor a csomópont offline állapota minden olyan szolgáltatást érint, amely ettől függ. Ha _letétbe helyezési_ célból üzemeltet csomópontot, akkor minimalizálni kell a kiesett időt. + +#### Kliensszolgáltatások létrehozása {#creating-client-services} + +Fontolja meg, hogy létrehoz egy szolgáltatást, hogy a klienseket automatikusan futtassa a bekapcsoláskor. Például a Linux szervereken érdemes lehet létrehozni egy szolgáltatást például a `systemd` kóddal, amely elindítja a klienst a megfelelő konfigurációval egy korlátozott privilégiumokkal bíró felhasználó alatt és automatikusan újraindítja azt. + +#### A kliensek frissítése {#updating-clients} + +Tartsa a kliensszoftverét naprakészen a legutóbbi biztonsági javításokkal, funkciókkal és [EIP-ekkel](/eips/). Főleg a [végleges elágazás (hard fork)](/history/) esetén legyen biztos abban, hogy a megfelelő kliensverziót használja. + +> A fontos hálózati frissítések előtt az Ethereum Alapítvány publikál egy cikket a [blogon](https://blog.ethereum.org). Ön is [feliratkozhat ezekre a bejelentésekre](https://blog.ethereum.org/category/protocol#subscribe), hogy e-mailes figyelmeztetést kapjon, amikor a csomópontot frissíteni kell. + +A kliensek frissítése igen egyszerű. Minden kliens dokumentációjában specifikus instrukciókat talál, de az általános eljárás az, hogy le kell tölteni a legújabb verziót és újra kell indítani a klienst az új végrehajtási programmal. A kliens ott folytatja, ahol abbahagyta, de már a frissítésekkel együtt. + +Minden kliensimplementáció rendelkezik egy ember által olvasható verziójelöléssel, melyet a peer-to-peer protokollban használnak, de a parancssorból is elérhető. Ez a verziójelölés megmutatja a felhasználóknak, hogy a megfelelő verziót használják-e, illetve a blokkfelfedezők és más elemzési eszközök számára, hogy megvizsgálják a kliensek megoszlását a hálózaton keresztül. A verziójelöléssel kapcsolatos további információkért tekintse át az adott kliens dokumentációját. + +#### Hozzáadott szolgáltatások futtatása {#running-additional-services} + +A saját csomópont futtatása megengedi olyan szolgáltatások használatát, melyhez hozzáférés szükséges az Ethereum-kliens RPC-hez. Ezek olyan, Ethereumra épített szolgáltatások, mint a [2. blokkláncréteg által nyújtott megoldások](/developers/docs/scaling/#layer-2-scaling), a tárcák biztonsági mentése, blokkfelfedezők, fejlesztői eszközök és más Ethereum infrastruktúrák. + +#### A csomópont felügyelete {#monitoring-the-node} + +A csomópont megfelelő felügyeletéhez érdemes a mérőszámokat gyűjteni. A kliensek képesek mérőszámokat biztosítani a végpontokról, így átfogó képet ad a csomóponttal kapcsolatban. Használjon olyan eszközöket, mint az [InfluxDB](https://www.influxdata.com/get-influxdb/) vagy a [Prometheus](https://prometheus.io/), hogy adatbázist hozzon létre, amelyből vizualizációt és diagrammokat készíthet olyan szoftverekkel, mint a [Grafana](https://grafana.com/). Különféle beállítások és Grafana-irányítópultok léteznek a csomópont és az egész hálózat vizualizációjára. Nézze meg például a [Geth felügyeletéről szóló útmutatót](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/). + +A felügyelet részeként figyeljen a gép teljesítményére is. A csomópont kezdeti szinkronizálásakor a kliensszoftver nagyobb terhet helyezhet a CPU-ra és RAM-ra. A Grafana mellett olyan eszközt is használhat, amit az operációs rendszere ajánl, mint a `htop` vagy az `uptime`. + +## További olvasnivaló {#further-reading} + +- [Ethereum letétbe helyezési útmutatók](https://github.com/SomerEsat/ethereum-staking-guides) – _Somer Esat, rendszeresen frissítve_ +- [Útmutató | Hogyan állítson fel validátort az Ethereum letétbe helyezéshez a főhálózaton](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew, rendszeresen frissítve_ +- [ETHStaker útmutatók a validátorok futtatásáról a teszthálózatokon](https://github.com/remyroy/ethstaker#guides) – _ETHStaker, rendszeresen frissítve_ +- [Az egyesítéssel (Merge) kapcsolatos gyakran ismételt kérdések a csomópontműködtetők számára](https://notes.ethereum.org/@launchpad/node-faq-merge) – _2022. július_ +- [A hardverkövetelmények elemzése az Ethereum teljes validátor-csomóponthoz kapcsolódóan](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Albert Palau, 2018. szeptember 24._ +- [Teljes csomópontok futtatása az Ethereumon: Útmutató az alig motivált felhasználók számára](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux, 2019. november 7._ +- [Hyperledger Besu csomópont futtatása az Ethereum főhálózaton: előnyök, követelmények és felállítás](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– Felipe Faraggi, 2020. május 7._ +- [Nethermind Ethereum-kliens bevezetése felügyeleti eszközökkel együtt](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth, 2020. július 8._ + +## Kapcsolódó témák {#related-topics} + +- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) +- [Blokkok](/developers/docs/blocks/) +- [Hálózatok](/developers/docs/networks/) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" new file mode 100644 index 00000000000..2b36bba4bb1 --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" @@ -0,0 +1,92 @@ +--- +title: Konszenzus mechanizmusok +description: Az elosztott rendszerek konszenzusprotokolljainak és szerepeiknek bemutatása az Ethereumban. +lang: hu +--- + +A konszenzusmechanizmust gyakran használják arra, hogy proof-of-stake (letéti igazolás), proof-of-work (munkaigazolás) vagy proof-of-authority (jogosultságigazolás) protokollokra hivatkoznak. Ugyanakkor ezek csak a konszenzusmechanizmus elemei, amelyek megvédik azt a [Sybil-támadásoktól](/glossary/#sybil-attack). A konszenzusmechanizmus elképzelések, protokollok és ösztönzők teljes halmaza, amely lehetővé teszi, hogy csomópontok elosztott kötege meg tudjon egyezni a blokklánc státuszáról. + +## Előfeltételek {#prerequisites} + +Ennek az oldalnak a könnyebb megértése érdekében javasoljuk, hogy először olvassa el a [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) oldalunkat. + +## Mi az a konszenzus? {#what-is-consensus} + +A konszenzus azt jelenti, hogy általános megegyezés történik. Tegyük fel, hogy egy csapat ember moziba megy. Ha a választott film kapcsán nincs nézeteltérés, akkor konszenzus van. Ha nézeteltérés van, akkor a csoportnak el kell döntenie, hogy mit nézzen. Szélsőséges esetben a csoport több felé fog válni. + +Az Ethereum blokkláncon ez a folyamat formális, a konszenzus eléréséhez a hálózaton lévő csomópontok 66%-ának egyet kell értenie a hálózat globális státuszát illetően. + +## Mi az a konszenzusmechanizmus? {#what-is-a-consensus-mechanism} + +A konszenzusmechanizmus kifejezés a protokollok, ösztönzők és elképzelések egész halmazára utal, amelyek lehetővé teszik, hogy a csomópontok hálózata megegyezzen a blokklánc státuszáról. + +Az Ethereum egy proof-of-stake-alapú konszenzusmechanizmust használ, amelynek kriptogazdasági biztonsága abból ered, hogy a letétesek által zárolt tőkéhez jutalmak és büntetések kapcsolódnak. Ez az ösztönző struktúra arra ösztönzi az egyes letéteseket, hogy becsületes validátorokat működtessenek, bünteti azokat, akik nem így tesznek, és rendkívül magas költséget teremt a hálózat megtámadásához. + +Ezután van egy protokoll, amely szabályozza, hogyan választják ki a becsületes validátorokat, hogy blokkokat javasoljanak vagy validáljanak, tranzakciókat dolgozzanak fel és szavazzanak a lánc fejéről. Azokban a ritka helyzetekben, amikor több blokk is ugyanabban a pozícióban van a lánc élén, van egy elágazásválasztó-mechanizmus, amely kiválasztja a „legnehezebb” láncot alkotó blokkokat, a blokkokra szavazó validátorok száma alapján, a letétbe helyezett ether-egyenlegükkel súlyozva. + +A konszenzus szempontjából fontosak a kódon kívüli koncepciók is, mint a megszokotton kívüli társadalmi koordináció biztonsága, mely a hálózat elleni támadások elleni védelmi vonal. + +Ezek az elemeket együttesen adják ki a konszenzusmechanizmust. + +## A konszenzusmechanizmusok fajtái {#types-of-consensus-mechanisms} + +### Proof-of-work alapú {#proof-of-work} + +Ahogy a Bitcoin, korábban Ethereum is a **proof-of-work (PoW)** alapú konszenzusprotokollt használta. + +#### Blokk létrehozás {#pow-block-creation} + +A bányászok versenyeznek, hogy új blokkokat hozzanak létre, amelyek tele vannak feldolgozott tranzakciókkal. A győztes megosztja az új blokkot a hálózat többi részével és valamennyi újonnan kibocsátott ETH-t kap jutalmul. A versenyt az a számítógép nyeri, amelyik a leggyorsabban meg tud oldani egy matematikai feladványt. Ez hozza létre a kriptográfiai kapcsolatot az aktuális és az azt megelőző blokk között. Ennek a feladványnak a megoldása jelenti a munkát a „proof-of-workben”. A kanonikus láncot ezután egy elágazásválasztási szabály határozza meg, amely kiválasztja azon blokkok halmazát, amelyek bányászatával a legtöbb munkát végezték. + +#### Biztonság {#pow-security} + +A hálózatot az tartja biztonságban, hogy a számítási kapacitás több mint 51%-ára van szükség a lánc meghamisításához. Ez olyan nagy befektetést igényelne a felszerelésben és energiában, hogy a támadó valószínűleg többet költene, mint amennyit nyerne vele. + +Bővebben a [proof-of-workről (PoW)](/developers/docs/consensus-mechanisms/pow/) + +### Proof-of-stake-alapú {#proof-of-stake} + +Az Ethereum jelenleg **proof-of-stake (PoS)** alapú konszenzusprotokollt használ. + +#### Blokk létrehozás {#pos-block-creation} + +A validátorok blokkokat hoznak létre. Minden slotban véletlenszerűen kiválasztanak egy blokkelőterjesztőt. A kiválasztott konszenzusos kliense egy adat tranzakciót kér végrehajtási csomagként a végrehajtási klienstől. Ezt konszenzusadatokba csomagolják, hogy egy blokkot alkossanak, melyet az Ethereum hálózat többi csomópontjának továbbítanak. Ezért a blokk-készítésért ETH-t kapnak. Ritka esetekben, amikor egy slothoz több blokk is létezik, vagy a csomópontok különböző időpontokban értesülnek a blokkokról, az elágazásválasztó algoritmus azt a blokkot választja ki, amely a legnagyobb súlyú tanúsítással alkotja a láncot (ahol a tanúsítást végző validátorok számát azok ETH-egyenlegével súlyozzák). + +#### Biztonság {#pos-security} + +A proof-of-stake rendszer kriptogazdasági szempontból biztonságos, mivel egy támadónak, aki megpróbálja átvenni az irányítást a lánc felett, hatalmas mennyiségű ETH-t kell feláldoznia. A jutalmak rendszere arra ösztönzi az egyes letétbe helyezőket, hogy tisztességesen viselkedjenek, a büntetések pedig visszatartják őket attól, hogy rosszhiszeműen cselekedjenek. + +Bővebben a [proof-of-stake-ről](/developers/docs/consensus-mechanisms/pos/) + +### Vizuális áttekintés {#types-of-consensus-video} + +Tekintse meg az Ethereumon használt különféle konszenzusmechanizmusokat: + + + +### Ellenállás a Sybil-támadásnak és láncválasztás {#sybil-chain} + +A proof-of-work és proof-of-stake önmagukban nem konszenzusprotokollok, de az egyszerűség kedvéért gyakran így hivatkoznak rájuk. Ezek Sybil-ellenálló mechanizmusok és a blokkok létrehozójának kiválasztói; ezek segítségével lehet eldönteni, hogy ki a legutóbbi blokk kreálója. Egy másik fontos összetevő a láncválasztó (elágazásválasztó) algoritmus, amely lehetővé teszi a csomópontok számára, hogy egyetlen helyes blokkot válasszanak a lánc élére olyan esetekben, amikor több blokk van ugyanabban a pozícióban. + +A **Sybil-rezisztencia** azt méri, hogy egy protokoll hogyan viselkedik egy Sybil-támadással szemben. Az ilyen típusú támadásokkal szembeni ellenállás lényeges egy decentralizált blokkláncnál, és lehetővé teszi, hogy a bányászok és a validáltorok a befektetett erőforrások alapján egyenlő mértékben részesüljenek jutalomban. A proof-of-work és proof-of-stake mechanizmusok úgy védekeznek, hogy a felhasználóknak sok energiát kell ráfordítaniuk vagy sok biztosítékot kell nyújtaniuk. Ezek a védelmek gazdaságilag elrettentő erejűek a Sybil-támadásokkal szemben. + +A **láncválasztási szabály** dönti el, hogy melyik lánc a „helyes”. A Bitcoin a „leghosszabb lánc” szabályt alkalmazza, ami azt jelenti, hogy amelyik blokklánc a leghosszabb, azt a többi csomópont is elfogadja érvényesnek, és azzal dolgozik. A proof-of-work láncok esetében a leghosszabb láncot a lánc összesített proof-of-work nehézsége határozza meg. Korábban az Ethereum is a leghosszabb lánc szabályát használta; most a proof-of-stake mechanizmussal működik, egy frissített elágazásválasztó algoritmust fogadott el, amely a lánc „súlyát” méri. A súly a validátorok szavazatainak összege, súlyozva a validátorok letétbe helyezett ether-egyenlegével. + +Az Ethereum a [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) nevű konszenzusmechanizmust használja, amely a [Casper FFG proof-of-stake](https://arxiv.org/abs/1710.09437) módszert a [GHOST elágazásválasztási szabállyal](https://arxiv.org/abs/2003.03052) kombinálja. + +## További olvasnivaló {#further-reading} + +- [Mi az a blokklánc-konszenzusalgoritmus?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm) +- [Mit jelent a Nakamoto-konszenzus? Útmutató kezdőknek](https://blockonomi.com/nakamoto-consensus/) +- [Hogyan működik a Casper?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) +- [A proof-of-work blokkláncok biztonságáról és teljesítményéről](https://eprint.iacr.org/2016/555.pdf) +- [Bizánci hiba](https://en.wikipedia.org/wiki/Byzantine_fault) + +_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/) +- [Bányászat](/developers/docs/consensus-mechanisms/pow/mining/) +- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/) +- [Proof-of-authority (jogosultsági igazolás)](/developers/docs/consensus-mechanisms/poa/) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" new file mode 100644 index 00000000000..fe0fed8b75a --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" @@ -0,0 +1,89 @@ +--- +title: Az Ethereum proof-of-stake rendszerére vonatkozó támadás és védekezés +description: Ismerje meg a proof-of-stake Ethereum elleni ismert támadási vektorokat és azok elleni védelmet. +lang: hu +--- + +A tolvajok és szabotőrök folyamatosan keresik a lehetőséget, hogy megtámadják az Ethereum kliensszoftverét. Ez az oldal ismerteti az Ethereum konszenzusrétegét érő ismert támadási vektorokat, és felvázolja, hogyan lehet ezeket a támadásokat kivédeni. + +## Előfeltételek {#prerequisites} + +## {#what-is-pos} + +Gyakori tévhit, hogy egy sikeres támadó képes új ethert generálni, vagy tetszőleges számlákról ethert lehívni. Egyik sem lehetséges, mivel minden tranzakciót a hálózat összes végrehajtási kliense hajtja végre. A tranzakcióknak meg kell felelniük az érvényesség alapvető feltételeinek (például a tranzakciókat a feladó privát kulcsa írja alá, a feladónak elegendő egyenleggel kell rendelkeznie stb. Az eredménynek három osztálya van, amelyet egy támadó reálisan megcélozhat: átszervezés, dupla véglegesség vagy a véglegesség késleltetése. + +## {#validators} + +Az **átszervezés** a blokkok új sorrendbe rendezése, esetleg a kanonikus láncban lévő blokkok hozzáadásával vagy kivonásával. Egy rosszindulatú átszervezés biztosíthatja, hogy bizonyos blokkok bekerüljenek vagy kikerüljenek, lehetővé téve a dupla költést vagy az értékkivonást előre és hátra futó tranzakciókkal (MEV). Az átszervezés arra is felhasználható, hogy bizonyos tranzakciókat ne lehessen felvenni a kanonikus láncba, ami a cenzúra egy formája. Az átszervezés legszélsőségesebb formája a „véglegesítés visszaállítása”, amely eltávolítja vagy helyettesíti a korábban véglegesített blokkokat. Ez csak akkor lehetséges, ha a támadó a teljes feltett ether több mint ⅓-át megsemmisíti – ez a garancia az úgynevezett „gazdasági véglegesség” (erről később még lesz szó). + +**Kettős véglegesség** az a valószínűtlen, de súlyos állapot, amikor két elágazás képes egyszerre véglegesedni, ami tartós szakadást okoz a láncban. Ez elméletileg lehetséges egy olyan támadó számára, aki hajlandó a teljes feltett ether 34%-át kockáztatni. A közösség kénytelen lenne a láncon kívül koordinálni és megegyezni arról, hogy melyik láncot kövesse, amihez a társadalmi réteg erejére lenne szükség. + +## {#transaction-execution-ethereum-pos} + +1. +2. +3. +4. +5. +6. + +A szociális réteg elleni támadás célja lehet az Ethereumba vetett közbizalom aláásása, az ether leértékelése, az elfogadás csökkentése vagy az Ethereum-közösség gyengítése, hogy megnehezítse a sávon kívüli koordinációt. + +## {#finality} + +Először is, azok a személyek, akik nem vesznek részt aktívan az Ethereumban (a kliensszoftver futtatásával), a társadalmi réteget (0. réteg) célozva támadhatnak. A 0. réteg az alap, amelyre az Ethereum épül, és mint ilyen, potenciális támadási felületet jelent, amelynek következményei a stack többi részére is kihatnak. Néhány példa: + +## {#crypto-economic-security} + +Ezeket a támadásokat az teszi különösen veszélyessé, hogy sok esetben nagyon kevés tőkére vagy technikai tudásra van szükség. Egy 0. rétegbeli támadás egy kriptogazdasági támadás multiplikátora lehet. Ha például a cenzúrát vagy a véglegesség visszaállítását egy rosszindulatú többségi érdekelt fél érné el, a szociális réteg aláásása megnehezíthetné a sávon kívüli közösségi válaszlépések koordinálását. + +A 0. rétegbeli támadások elleni védekezés valószínűleg nem egyszerű, de néhány alapelvet fel lehet állítani. Az egyik az Ethereummal kapcsolatos nyilvános információk magas jel-zaj arányának fenntartása, amelyeket a közösség becsületes tagjai hoznak létre és terjesztenek blogokon, Discord szervereken, kommentált specifikációkon, könyveken, podcastokon és Youtube-on keresztül. Itt az ethereum.org-on is igyekszünk pontos információkat fenntartani és a lehető legtöbb nyelvre lefordítani. A tér minőségi információkkal és mémekkel való elárasztása hatékony védekezés a félretájékoztatás ellen. + +## {#fork-choice} + +Egy másik fontos megerősítés a társadalmi réteg támadásaival szemben az egyértelmű küldetésnyilatkozat és az irányítási protokoll. Az Ethereum a decentralizáció és a biztonság bajnokaként pozicionálta magát az L1-es okosszerződések között, miközben nagyra értékeli a skálázhatóságot és a fenntarthatóságot is. Bármilyen nézeteltérések merülnek fel az Ethereum közösségben, ezek az alapelvek minimálisan sérülnek. A narratíva értékelése ezen alapelvek alapján és a felülvizsgálat egymást követő fordulóin keresztül az EIP (Ethereum Fejlesztési Javaslatok) folyamatában segíthet a közösségnek megkülönböztetni a jó és a rossz szereplőket, illetve korlátozhatja a rosszindulatú szereplők lehetőségét az Ethereum jövőbeli irányának befolyásolására. + +## {#pos-and-security} + +Végezetül fontos, hogy az Ethereum-közösség nyitott és befogadó maradjon minden résztvevő számára. A zártkörű közösségek különösen sebezhetők a társadalmi támadásokkal szemben, mivel könnyű „mi és ők” narratívákat építeni. A törzsiség és a mérgező maximalizmus árt a közösségnek és aláássa a 0. réteg biztonságát. A hálózat biztonságában érdekelt Ethereum-tagoknak úgy kell tekinteni az online és személyes találkozásokra, mint ami közvetlenül hozzájárul az Ethereum 0. rétegének biztonságához. + +- +- +- +- Hozzáértő, de rosszindulatú szereplők beszivárgása a fejlesztői közösségbe, akiknek célja a fejlődés lelassítása a megbeszélések megzavarásával, a fontos döntések késleltetésével, szemeteléssel (spam) stb. + +## {#pros-and-cons} + +| | | +| | | +| | | +| | | +| | | +| | | + +### {#comparison-to-proof-of-work} + +Több cikk is ismertette az Ethereum elleni olyan támadásokat, amelyek a teljes feltett ether csak kis hányadával érnek el reorgokat vagy végleges késleltetést. Ezek a támadások általában arra épülnek, hogy a támadó visszatart valamilyen információt a többi validátor elől, majd valamilyen árnyalt módon és/vagy egy alkalmas pillanatban kiadja azt. + +- +- +- +- +- +- + +## {#further-reading} + +- +- +- +- +- +- []() +- +- []() + +## {#related-topics} + +- []() +- []() diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" new file mode 100644 index 00000000000..6007bf787fe --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" @@ -0,0 +1,92 @@ +--- +title: Tanúsítások +description: A tanúsítások menete az Ethereum proof-of-stake (letéti igazolás) mechanizmusában. +lang: hu +--- + +A validátornak minden korszakban tanúsítást kell készítenie, aláírnia és szétküldenie. Ez a leírás bemutatja, hogyan néznek ki ezek a tanúsítások, hogyan kezelik azokat és kommunikálják a konszenzusos kliensek között. + +## Mi az a tanúsítás? {#what-is-an-attestation} + +Minden [korszakban](/glossary/#epoch) (6,4 perc) a validátor tanúsítást készít a hálózatnak. A tanúsítás a korszak egy megadott slotjára történik. A tanúsítás célja az, hogy szavazzon amellett, ahogyan ő maga látja a láncot, különösképpen a legutóbbi ellenőrzött blokk és a jelen korszak első blokkja tekintetében (melyeket `source` (eredet) és `target` (cél) ellenőrzési pontoknak neveznek). Az információkat összekombinálják az összes résztvevő validátorra, így a hálózat konszenzust tud elérni a blokklánc státuszát illetően. + +A tanúsítás a következő elemekből áll: + +- `aggregation_bits`: a validátorok bitlistája, ahol a pozíció a validátornak a bizottságbeli indexéhez kapcsolódik; az érték (0/1) azt mutatja, hogy a validátor aláírta a `data` mezőt (tehát aktív és egyetért a blokkelőterjesztővel) +- `data`: a tanúsításhoz kapcsolódó részletek, ahogy az alább látszik +- `signature`: egy BLS-aláírás, ami aggregálja az egyéni validátorok aláírásait + +A tanúsítást végző validátor első feladata az, hogy felépítse a `data` mezőit. A `data` a következő információkat tartalmazza: + +- `slot`: A slot száma, melyre a tanúsítás vonatkozik +- `index`: Egy szám, ami beazonosítja, hogy a validátor melyik bizottsághoz tartozik egy adott slotban +- `beacon_block_root`: A blokk gyökérhashe, amit a validátor lát a lánc fejeként (az elágazásválasztási algoritmus alkalmazásának eredménye) +- `source`: A véglegesedési szavazás része, amely azt mutatja, hogy a validátorok melyik blokkot látják a legutoljára igazoltnak +- `target`: A véglegesedési szavazás része, mely azt mutatja, hogy a validátorok melyik blokkot látják a jelen korszak első blokkjának + +Amint a `data` felépül, a validátor átválthatja a bitet az `aggregation_bits` mezőben 0-ról 1-re, amely a saját validátor indexéhez kapcsolódik, így mutatja, hogy részt vett. + +Végül a valdátor aláírja a tanúsítást és elküldi azt a hálózaton. + +### Aggregált tanúsítás {#aggregated-attestation} + +Az adat elterjesztése a hálózaton minden validátor esetében jelentős költséggel jár. Ezért az egyéni validátorok tanúsításait aggregálják az alhálózatokon belül, mielőtt szélesebb körben szétküldenék azt. Ennek része az aláírások aggregálása, így a kiküldött tanúsítás tartalmazza a konszenzus `data` mezőit és egyetlen aláírást, melyet azon validátorok aláírásából készítenek, akik egyetértettek a `data` tartalmával. Ezt le lehet ellenőrizni az `aggregation_bits` mezővel, mert ez adja meg a bizottságban lévő validátorok indexeit (akiknek az ID-ja a `data` mezőben látható), amellyel le lehet kérdezni az egyéni aláírásokat. + +Minden korszakban minden alhálóban 16 validátort kiválasztanak, hogy `aggregátor` legyen. Az aggregátorok összegyűjtik az összes tanúsítást, amelyről hallanak a pletykahálózaton, és amelyeknek ugyanolyan `data` áll rendelkezésre, mint nekik. Minden egyező tanúsítás küldője feljegyzésre kerül az `aggregation_bits` mezőben. Ezután az aggregátorok szétküldik az aggregált tanúsítást a szélesebb hálózaton. + +Amikor egy validátort választanak blokkelőterjesztőnek, akkor az új blokkba beteszi az aggregált tanúsításokat az alhálózatoktól egészen az utolsó slotig. + +### A tanúsítások belefoglalásának életciklusa {#attestation-inclusion-lifecycle} + +1. Létrehozás +2. Előterjesztés +3. Aggregálás +4. Előterjesztés +5. Belefoglalás + +A tanúsítás életciklusát a következő ábra is bemutatja: + +![a tanúsítás életciklusa](./attestation_schematic.png) + +## Jutalmak {#rewards} + +A validátorok jutalmat kapnak az elküldött tanúsításokért. A tanúsítás jutalma függ a részvételi jelzésektől (forrás, cél és fej), az alapjutalomtól és a részvételi aránytól. + +A részvételi jelzések értéke igaz vagy hamis lehet, a benyújtott tanúsítás és a kapcsolódó késedelem függvényében. + +A legjobb esetben mindhárom jelző igaz, ekkor a validátor a következő jutalmat kapná (helyes jelzőnként): + +`jutalom += alapjutalom * jelzés súlya * jelzés tanúsítási aránya / 64` + +A jelzés tanúsítási arányát az adott jelzésre vonatkozóan az összes tanúsítást végező validátor tényleges egyenlegének összegével mérik az összes aktív tényleges egyenleghez viszonyítva. + +### Alapjutalom {#base-reward} + +Az alapjutalom számítása a tanúsításban részt vevő validátorok számától és az általuk letétbe helyezett ether egyenlegétől függ: + +`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)` + +#### Belefoglalási késés {#inclusion-delay} + +Amikor a validátorok szavaztak a lánc fejére (`block n`), akkor a `block n+1` még nem volt előterjesztve. Ezért a tanúsítások természetes módon **egy blokkal később** kerülnek be, így minden tanúsítás, amelyik azt mondta, hogy a `block n` a lánc feje, az bekerül a `block n+1`-be, és a **belefoglalási késés** értéke 1. Ha a belefoglalási késés két slotnyi lesz, akkor a tanúsítási jutalom feleződik, mert a tanúsítási jutalom kiszámításához az alapjutalom szorozva van a belefoglalási késés reciprokával. + +### Tanúsítási esetek {#attestation-scenarios} + +#### Hiányzó validátor, aki szavaz {#missing-voting-validator} + +A validátoroknak legfeljebb 1 korszak áll rendelkezésre, hogy elküldjék a tanúsításukat. Ha a tanúsítás lekési a 0. korszakot, akkor belefoglalási késéssel be tudják még küldeni az 1. korszakban. + +#### Hiányzó aggregátor {#missing-aggregator} + +Összesen 16 aggregátor van minden korszakban. Emellett véletlenszerű validátorok be vannak jegyezve **két alhálózatra 256 korszakra**, és ők helyettesítik az aggregátorokat, ha bárki hiányzik. + +#### Hiányzó blokkelőterjesztő {#missing-block-proposer} + +Néhány esetben a szerencsés aggregátor blokkelőterjesztővé válhat. Ha a tanúsítás nem került be, mert a blokkelőterjesztő hiányzik, akkor a következő előterjesztő felkapja az aggregált tanúsítást és beteszi a következő blokkba. Ugyanakkor az **belefoglalási késés** növekszik eggyel. + +## További olvasnivaló {#further-reading} + +- [Tanúsítások Vitalik által kommentált konszenzusspecifikációban](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [Tanúsítások az eth2book.info oldalon](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) + +_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" new file mode 100644 index 00000000000..7ded209d33e --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" @@ -0,0 +1,69 @@ +--- +title: Blokkjavaslat +description: Magyarázat a blokkok előterjesztéséről a proof-of-stake Ethereumban. +lang: hu +--- + +A blokkok a blokklánc alapvető egységei. A blokkok az információ különálló egységei, melyeket a csomópontok terjesztenek egymás között, megegyeznek róluk és hozzáadják őket a saját adatbázisukhoz. Ez az oldal azt magyarázza el, hogyan jönnek létre a blokkok. + +## Előfeltételek {#prerequisites} + +A blokkelőterjesztés része a proof-of-stake (letéti igazolás) protokollnak. Ahhoz, hogy könnyebben átlássa a folyamatot, tekintse meg a [proof-of-stake-ről](/developers/docs/consensus-mechanisms/pos/) és a [blokk architektúráról](/developers/docs/blocks/) szóló anyagokat. + +## Ki hozza létre a blokkot? {#who-produces-blocks} + +A validátorszámlák javasolják a blokkokat. A validátorszámlákat azok a csomópontműködtetők kezelik, akik validátorszoftvert futtatnak a végrehajtási és konszenzusklienseik részeként, és letétbe helyeztek 32 ETH-t a letéti szerződésbe. Ugyanakkor egy adott validátor csak esetenként felel azért, hogy blokkot javasoljon. Az Ethereum az időt slotokra és korszakokra (epoch) osztja fel. Minden slot 12 másodperc, és 32 slot (6,4 perc) tesz ki egy korszakot. Minden slotban lehetőség van arra, hogy az Ethereumon egy új blokkot hozzanak létre. + +### Véletlenszerű kiválasztás {#random-selection} + +A kijelölt validátort ál-véletlenszerűen választják, hogy javasoljon blokkot egy adott slotban. A blokkláncban nincs olyan, hogy valódi véletlenszerűség, mert ha minden csomópont valóban véletlen számokat generálna, akkor sose lenne konszenzus. Ehelyett az a lényeg, hogy a validátorkiválasztás megjósolhatatlan legyen. A véletlenszerűséget az Ethereumon egy RANDAO néven ismert algoritmussal érik el, ami összekeveri a blokkelőterjesztőtől jövő hasht egy seeddel, ami minden blokkban frissítve van. Ezt az értéket használják, hogy kiválasszanak egy adott validátort a teljes szettből. A validátorkiválasztás két korszakra előre adott, hogy ezzel védekezzenek a seedmanipuláció ellen. + +Habár a validátorokat hozzáadják a RANDAO-hoz minden slotban, de a globális RANDAO értéke csak egyszer frissül minden korszakban. Ahhoz, hogy a következő blokkelőterjesztő indexét kiszámolja, a RANDAO értéket összekeveri a slotszámmal, hogy minden slotnak egyedi értéke legyen. A valószínűség, hogy egy adott validátor kiválasztásra kerül, nem egyszerűen `1/N` (ahol `N` = teljes aktív validátorok). Ehelyett ezt súlyozzák minden validátor aktuális ETH egyenlegével. A maximum egyenleg (balance) az 32 ETH (tehát `balance < 32 ETH` kevesebb súlyt jelent, mint `balance == 32 ETH`, de a `balance > 32 ETH` nem jelent nagyobb súlyt, mint `balance == 32 ETH`). + +Minden slotban egy blokkelőterjesztőt választanak. Normális esetben a dedikált slotban egy blokkelőterjesztő létrehoz és elküld egyetlen blokkot. Két blokk ugyanarra a slotra való létrehozásáért súlyos és kizárással járó büntetés jár, gyakran emlegetik kétértelműségként is. + +## Hogyan jön létre a blokk? {#how-is-a-block-created} + +A blokkelőterjesztőnek egy aláírt beacon blokkot kell szétküldeni, amely a lánc aktuális fejére épül, ahogy azt a lokálisan futtatott elágazásválasztási algoritmusuk mutatja. Az elágazásválasztás algoritmusa először érvényesíti az előző slotból származó tanúsításokat, majd megkeresi azt a blokkot, melynek összességében a legtöbb tanúsítása van. Ez a blokk lesz a szülője annak az új blokknak, amelyet a javaslattevő készít. + +A blokkelőterjesztő összegyűjti az adatokat a saját lokális adatbázisából és a láncról, és ezekből állít össze blokkot. A blokk tartalma alábbiakban látható: + +```rust +class BeaconBlockBody(Container): + randao_reveal: BLSSignature + eth1_data: Eth1Data + graffiti: Bytes32 + proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] + attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] + attestations: List[Attestation, MAX_ATTESTATIONS] + deposits: List[Deposit, MAX_DEPOSITS] + voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] + sync_aggregate: SyncAggregate + execution_payload: ExecutionPayload +``` + +A `randao_reveal` mező egy igazolható, véletlenszerű értéket vesz fel, melyet a blokkelőterjesztő hoz létre azzal, hogy aláírja a jelenlegi korszak számát. Az `eth1_data` egy szavazat arra, ahogy a blokkelőterjesztő a letéti szerződést látja, beleértve a letéti Merkle-fa gyökerét és a letétek teljes számát, mely lehetővé teszi az új letétek ellenőrzését. A `graffiti` egy opcionális mező, mellyel üzenetet lehet adni a blokkhoz. A `proposer_slashings` és az `attester_slashings` olyan mezők, melyek bizonyítják, hogy adott validátorok súlyos büntetést érdemelnek aszerint, ahogy az előterjesztő látja a láncot. A `deposits` az új validátorletétek listája, melyről az előterjesztő tudomással bír, a `voluntary_exits` pedig azok a validátorok, akikről a konszenzusréteg pletykahálózatán hallott, hogy ki akarnak lépni. A `sync_aggregate` egy olyan vektor, mely megmutatja, melyik validátorok voltak korábban a szinkronizálási bizottság tagjai (a validátorok alcsoportja, melyek a könnyű klienseknek biztosítanak adatot) és vettek részt az adatok aláírásában. + +Az `execution_payload` információt ad a végrehajtási és a konszenzuskliensek közötti átadott tranzakciókról. Az `execution_payload` a végrehajtandó adatok egy csomagja, melyet beágyaznak egy beacon blokkba. Az `execution_payload` mezői a blokkstruktúrát mutatják, ahogy azt az Ethereum Sárgakönyv felvázolja, kivéve, hogy nincsenek ommerek és `prev_randao` van a `difficulty` helyett. A végrehajtási kliens a tranzakciók egy helyi gyűjtőjéhez fér hozzá, melyről a saját pletykahálózatán hallott. Ezeket a tranzakciókat helyben végrehajtja, hogy egy friss státuszfát kapjon (post-state). A tranzakciók bekerülnek az `execution_payload` mezőbe egy listaként, mint `transactions`, az új státuszfa (post-state) pedig a `state-root` mezőbe kerül. + +Ezeket az adatokat egy beacon blokkba gyűjtik, melyet aláírnak és szétküldenek az előterjesztő társainak, akik továbbküldik a saját társaiknak, és így tovább. + +Bővebben a [a blokkok anatómiájáról](/developers/docs/blocks). + +## Mi történik a blokkal? {#what-happens-to-blocks} + +A blokk bekerül az előterjesztő helyi adatbázisába, és elküldi azt a társaknak a konszenzusréteg pletykahálózatán keresztül. Amikor egy validátor megkap egy blokkot, ellenőrzi a benne lévő adatokat, úgy mint hogy megfelelő szülővel rendelkezik-e, a megfelelő slotra vonatkozik-e, az előterjesztő indexe megfelel-e, a RANDAO nyilatkozat érvényes-e és az előterjesztőt nem büntették-e meg. Az `execution_payload` kicsomagolásra kerül, és a validátor végrehajtási kliense újra lefuttatja a tranzakciókat, hogy ellenőrizze a javasolt státuszváltozást. Ha a blokk átmegy minden ellenőrzésen, akkor az összes validátor hozzáadja a blokkot a saját kanonikus láncához. Majd a folyamat kezdődik elölről a következő slotban. + +## Blokkjutalmak {#block-rewards} + +A blokkelőterjesztő fizetséget kap a munkájáért. Van egy `base_reward` (alapdíj), melyet az aktív validátorok számából és az ő aktuális egyenlegeikből kalkulálnak ki. A blokkelőterjesztő ezután megkapja a `base_reward` egy töredékét minden érvényes tanúsításért, mely a blokkba került; minél több validátor tanúsítja a blokkot, annál nagyobb ez a jutalom. Azért is jutalom jár, ha valaki bejelent egy validátort, akit meg kell büntetni. Ez `1/512 * aktuális egyenleg` minden súlyosan megbüntetett validátor után. + +[Bővebben a jutalmakról és büntetésekről](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) + +## További olvasnivaló {#further-reading} + +- [Bevezetés a blokkokba](/developers/docs/blocks/) +- [Bevezetés a proof-of-stake mechanizmusba](/developers/docs/consensus-mechanisms/pos/) +- [Az Ethereum konszenzusspecifikációi](https://github.com/ethereum/consensus-specs) +- [Bevezetés a Gasperbe](/developers/docs/consensus-mechanisms/pos/) +- [Az Ethereum frissítése](https://eth2book.info/) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" new file mode 100644 index 00000000000..2338c0a3ab5 --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" @@ -0,0 +1,172 @@ +--- +title: Gyakran ismételt kérdések +description: Gyakran ismételt kérdések az Ethereum proof-of-stake (letéti igazolás) mechanizmusáról. +lang: hu +--- + +## Mi az a proof-of-stake? {#what-is-proof-of-stake} + +A proof-of-stake (letéti igazolás) egy algoritmusfajta, ami biztonságot tud adni a blokkláncoknak azáltal, hogy a támadók elveszítik az értékeiket, amint rosszhiszeműen viselkednek. A proof-of-stake rendszereknél szükség van egy validátorszettre, amely eszközöket biztosít, és ezeket lehet megsemmisíteni, ha bizonyítottan rosszindulatúan cselekszenek. Az Ethereum proof-of-stake mechanizmust használ arra, hogy biztosítsa a blokkláncot. + +## Hogyan viszonyul a proof-of-stake a proof-of-work mechanizmushoz? {#comparison-to-proof-of-work} + +A proof-of-work (munkaigazolás) és a proof-of-stake (letéti igazolás) egyaránt olyan mechanizmus, mely elrettenti a rosszhiszemű szereplőket attól, hogy teleszemeteljék vagy becsapják a hálózatot. Mindkettőnél azok a csomópontok, melyek aktívan részt vesznek a konszenzusban, valamennyi eszközt „tesznek be a hálózatba”, melyet elveszítenek, ha nem viselkednek megfelelően. + +A proof-of-work esetében ez az eszköz az energia. A bányászként ismert csomópont egy olyan algoritmust futtat, melynek célja, hogy egy értéket gyorsabban számoljon ki, mint az összes többi csomópont. A leggyorsabb csomópont javasolhat blokkot a láncra. Ahhoz, hogy a lánc történetét megváltoztassa vagy dominálja a blokkelőterjesztést, a bányásznak olyan hatalmas számítási kapacitással kell bírnia, hogy mindig megnyerje a versenyt. Ez olyan szinten drága és nehezen kivitelezhető, hogy ez megvédi a láncot a támadásoktól. A proof-of-work alapú bányászathoz szükséges energia egy valódi eszköz, amiért a bányászok fizetnek. + +A proof-of-stake-hez validátor szerepű csomópontokra van szükség, amelyek egyértelműen kriptoeszközt adnak át egy okosszerződésnek. Ha egy validátor nem megfelelően viselkedik, ezt a kriptót megsemmisíthetik, mivel ezt közvetlen módon letétbe helyezték a láncon, nem pedig közvetett módon, az energiakiadáson keresztül. + +A proof-of-work sokkal energiaigényesebb, mert a bányászati folyamatban elektromosságot égetnek el. A proof-of-stake ezzel szemben csak nagyon kevés energiát igényel – az Ethereum-validátorokat igen alacsony kapacitású eszközön is futtathatják, mint amilyen a Raspberry Pi. Az Ethereum proof-of-stake mechanizmusát sokkal biztonságosabbnak vélik, mint a proof-of-work metódust, mert a támadás költsége sokkal nagyobb, a támadót pedig sokkal súlyosabb következmények sújtják. + +A proof-of-work és proof-of-stake összehasonlítása állandó téma. [Vitalik Buterin blogja](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work), valamint a Justin Drake és Lyn Alden közötti vita jól összefoglalja az érveket. + + + +## Energiatakarékos a proof-of-stake? {#is-pos-energy-efficient} + +Igen. A proof-of-stake hálózat csomópontjai kis mennyiségű energiát használnak. Egy harmadik fél által készített tanulmány szerint az Ethereum teljes proof-of-stake hálózatának fogyasztása kb. 0,0026 TWh/év, ami nagyjából 13 000-szer kevesebb, mint a játék csak az Egyesült Államokban. + +[Bővebben az Ethereum energiafelhasználásáról](/energy-consumption/). + +## Biztonságos a proof-of-stake? {#is-pos-secure} + +Az Ethereum proof-of-stake mechanizmusa nagyon biztonságos. A mechanizmust nyolc éven át kutatták, fejlesztették és alaposan tesztelték, mielőtt életbe lépett volna. A biztonsági garanciák eltérnek a proof-of-work alapú blokkláncoktól. A proof-of-stake esetén a rosszindulatú validátorokat aktívan meg lehet büntetni (slash) és ki lehet dobni a validátorok közül, ami nekik jelentős összegű ETH-be kerül. A proof-of-work esetében a támadó megismételheti a támadását, amíg elegendő hashkapacitással nem rendelkezik. Az Ethereum proof-of-stake-nél egy ugyanolyan jellegű támadás költségesebb, mint proof-of-work esetén. A lánc elérhetőségének befolyásolásához a hálózaton lévő összes letétbe helyezett ether legalább 33%-ára van szükség (kivéve a nagyon kifinomult, rendkívül valószínűtlen sikerű támadások esetén). A jövőbeli blokkok tartalmának ellenőrzéséhez a teljes letétbe helyezett ETH legalább 51%-a szükséges, az előzményadatok átírásához pedig a teljes letét több mint 66%-a kell. Az Ethereum protokollja a 33%-os vagy 51%-os támadásoknál megsemmisítené ezeket az eszközöket, a 66%-os támadásnál pedig társadalmi konszenzussal oldaná meg. + +- [Bővebben az Ethereum proof-of-stake támadás elleni védelméről](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [Bővebben a proof-of-stake kialakításáról](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## Olcsóbbá teszi az Ethereumot a proof-of-stake? {#does-pos-make-ethereum-cheaper} + +Nem. A tranzakció elküldésének költségét (gázdíj) egy dinamikus díjpiac határozza meg, amely a hálózati kereslet növekedésével nő. A konszenzusmechanizmus ezt közvetlenül nem befolyásolja. + +[Bővebben a gázról](/developers/docs/gas). + +## Mik azok a csomópontok, kliensek és validátorok? {#what-are-nodes-clients-and-validators} + +A csomópontok az Ethereum-hálózathoz csatlakozó számítógépek. A kliensek az általuk futtatott szoftverek, amelyek a számítógépet csomóponttá alakítják. A klienseknek két típusa van: a végrehajtási és a konszenzuskliensek. Mindkettőre szükség van egy csomópont létrehozásához. A validátor a konszenzusos kliens opcionális kiegészítője, amely lehetővé teszi a csomópont számára, hogy részt vegyen a proof-of-stake konszenzusban. Ez azt jelenti, hogy blokkokat hoz létre és javasol, amikor kiválasztják, és igazolja azokat a blokkokat, amelyekről a hálózaton hall. Validátor futtatásához a csomópont üzemeltetőjének 32 ETH-t kell befizetnie a letéti szerződésbe. + +- [Bővebben a csomópontokról és kliensekről](/developers/docs/nodes-and-clients) +- [Többet a letétbe helyezésről](/staking) + +## A proof-of-stake egy új ötlet? {#is-pos-new} + +Nem. A BitcoinTalk egyik felhasználója 2011-ben [javasolta a proof-of-stake alapötletét](https://bitcointalk.org/index.php?topic=27787.0) a Bitcoin továbbfejlesztéseként. Tizenegy év telt el, mire készen állt a megvalósításra az Ethereum főhálózaton. Néhány más lánc már korábban megvalósította a proof-of-stake-et, de nem az Ethereum sajátos mechanizmusát (ami Gasper néven ismert). + +## Mi a különleges az Ethereum proof-of-stake mechanizmusában? {#why-is-ethereum-pos-special} + +Az Ethereum proof-of-stake mechanizmusa teljesen egyedi. Nem ez volt az első proof-of-stake mechanizmus, amelyet megterveztek és megvalósítottak, de ez a legstabilabb. A proof-of-stake mechanizmusát Casper-nek nevezik. A Casper határozza meg, hogyan választják ki a validátorokat a blokkelőterjesztésre, hogyan és mikor tanúsítanak, hogyan számolják a tanúsításokat, milyen jutalmakat és büntetéseket kapnak a validátorok, a súlyos büntetések feltételeit, a hibabiztos mechanizmusokat, mint például az inaktivitás elszivárgás, és a „véglegesség” feltételeit. A véglegesség egy feltétel, hogy egy blokk a kanonikus lánc állandó része legyen, a hálózaton lévő összes letétbe helyezett ETH legalább 66%-ának szavazatával kell bírnia. A kutatók a Caspert kifejezetten az Ethereum számára fejlesztették ki, így ez az első és egyetlen blokklánc, amely megvalósította. + +A Casper mellett az Ethereum proof-of-stake-je egy LMD-GHOST nevű elágazásválasztó-algoritmust használ. Erre abban az esetben van szükség, ha két blokk létezik ugyanarra a slotra. Ezáltal a blokklánc két elágazást hoz létre. Az LMD-GHOST azt választja ki, amelyiknél a tanúsítások „súlya” a legnagyobb. A súly a tanúsítások száma súlyozva a validátorok tényleges egyenlegével. Az LMD-GHOST egyedülálló az Ethereumban. + +A Casper és az LMD_GHOST kombinációja Gasper néven ismert. + +[Bővebben a Gasperről](/developers/docs/consensus-mechanisms/pos/gasper/) + +## Mi az a súlyos büntetés (slashing)? {#what-is-slashing} + +Súlyos büntetésnek nevezzük a validátor letétjének megsemmisítését és a validátornak a hálózatból való kizárását. A súlyos büntetés során elveszített ETH mennyisége a megbüntetett validátorok számával arányos – ez azt jelenti, hogy az összejátszó validátorok súlyosabb büntetést kapnak, mint az egyének. + +[Bővebben a súlyos büntetésről (slashing)](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) + +## Miért kell a validátoroknak 32 ETH? {#why-32-eth} + +A validátoroknak ETH-t kell letétbe helyezniük, hogy legyen mit veszíteniük, ha rosszhiszeműen viselkednek. Azért is kell 32 ETH-t feltölteniük, hogy a csomópontok egyszerűbb hardveren is működhessenek. Ha az egy validátorra jutó minimális ETH alacsonyabb lenne, akkor a validátorok száma, és így az egyes slotokban feldolgozandó üzenetek száma is növekedne, ezért nagyobb teljesítményű hardverre lenne szükség egy csomóponthoz. + +## Hogyan választják ki a validátorokat? {#how-are-validators-selected} + +Egy adott validátor álvéletlenszerűen kerül kiválasztásra a RANDAO nevű algoritmus segítségével, hogy egy adott slotban blokkot javasoljon; ez a blokkelőterjesztőtől származó hasht keveri egy seeddel, amely minden blokkban frissül. Ezt az értéket használják, hogy kiválasszanak egy adott validátort a teljes szettből. A validátor kiválasztását két korszakra előre elvégzik. + +[Bővebben a validátorkiválasztásról](/developers/docs/consensus-mechanisms/pos/block-proposal) + +## Mi az a letéti grinding? {#what-is-stake-grinding} + +A letéti grinding egy proof-of-stake hálózat elleni támadás, ahol a támadó megpróbálja a validátor kiválasztási algoritmust a saját validátorai javára torzítani. A RANDAO letéti grinding támadásához a teljes lekötött ETH-mennyiség felére van szükség. + +[Bővebben a letéti grindingről](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) + +## Mi az a közösségi slashing? {#what-is-social-slashing} + +A közösségi slashing a közösség azon lehetősége, hogy egy támadás esetén eldöntse a blokklánc elágazását. Ez lehetővé teszi a közösség számára, hogy helyreálljon egy helytelen láncot véglegesítő támadás esetén. A közösségi slashing a cenzúrázó támadások ellen is használható. + +- [Bővebben a közösségi slashingről](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [Vitalik Buterin a közösségi slashingről](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) + +## Engem is érhet súlyos büntetés (slashing)? {#will-i-get-slashed} + +Validátorként nehéz súlyos büntetést szerezni, hacsak nem valaki szándékosan rosszindulatúan viselkedik. A súlyos büntetést speciális esetekben alkalmazzák, amikor a validátorok több blokkot javasolnak ugyanabban a slotban, vagy ellentmondanak önmaguknak a tanúsításaikkal – ezek nem valószínű, hogy véletlenül előfordulnak. + +[Bővebben a súlyos büntetés feltételeiről](https://eth2book.info/altair/part2/incentives/slashing) + +## Mit jelent a nincs kockázat probléma? {#what-is-nothing-at-stake-problem} + +A nincs kockázat probléma egy koncepcionális hiányosság néhány proof-of-stake mechanizmus esetén, ahol csak jutalmak vannak, és nincsenek büntetések. Ha nincs kockázat, tehát nem lehet a letétet elveszíteni, akkor a gyakorlatias validátor ugyanúgy tanúsítja bármelyik vagy akár több elágazását is a blokkláncnak, mert ebből több jutalmat kap. Az Ethereum ezt úgy kezeli, hogy véglegességi feltételeket szab és létezik súlyos büntetés, így biztosítható a kanonikus lánc. + +[Bővebben a nincs kockázat problémáról](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) + +## Mi az az elágazásválasztó algoritmus? {#what-is-a-fork-choice-algorithm} + +Az elágazásválasztó algoritmus olyan szabályokat alkalmaz, amelyek meghatározzák, hogy melyik lánc a kanonikus. Optimális körülmények között nincs szükség elágazásválasztási szabályra, mivel slotonként csak egy blokkelőterjesztő van, és csak egy blokk jön létre. Alkalmanként lehetséges, hogy több blokk keletkezik ugyanarra a slotra vagy későn érkező információ miatt több lehetőség van a lánc fejéhez közeli blokkok szerveződésére. Ezekben az esetekben minden kliensnek azonos módon kell végrehajtania néhány szabályt, hogy biztosítsa, hogy a blokkok helyes sorrendjét válasszák. Az elágazásválasztó algoritmus kódolja ezeket a szabályokat. + +Az Ethereum elágazásválasztási algoritmusának neve LMD-GHOST. Azt az elágazást választja, amelynek a legnagyobb a tanúsítási súlya, vagyis amelyikre a legtöbb letétbe helyezett ETH szavazott. + +[Bővebben az LMD-GHOST-ról](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## Mit jelent a véglegesség a proof-of-stake-ben? {#what-is-finality} + +A véglegesség a proof-of-stake-ben az a garancia, hogy egy adott blokk stabil része a kanonikus láncnak, és nem lehet azt visszafordítani, kivéve, ha a konszenzus meghiúsul, és a támadó a teljes letétbe helyezett ether 33%-át elégeti. Ez egy kriptogazdasági véglegesség, szemben a „valószínűségi véglegességgel”, amely a proof-of-work blokkláncokra releváns. A valószínűségi véglegességben nincsenek explicit véglegesített/nem véglegesített státuszok a blokkok számára – egyszerűen egyre kevésbé valószínű, hogy egy blokkot el lehet távolítani a láncból, ahogy telik az idő, és a felhasználók maguk határozzák meg, hogy mikor eléggé biztosak abban, hogy egy blokk helyzete „biztonságos”. A kriptogazdasági véglegesítésnél az ellenőrzőpont blokkpárjait a letétbe helyezett ether 66%-ának kell megszavaznia. Ha ez a feltétel teljesül, akkor az ellenőrzőpontok közötti blokkok egyértelműen véglegesek. + +[Bővebben a véglegességről](/developers/docs/consensus-mechanisms/pos/#finality) + +## Mi az a „gyenge szubjektivitás”? {#what-is-weak-subjectivity} + +A gyenge szubjektivitás a proof-of-stake hálózatok egyik jellemzője, ahol a társadalmi információkat használják a blokklánc aktuális státuszának megerősítésére. Az új csomópontok vagy a hálózathoz egy hosszabb offline állapot után csatlakozó csomópontok kaphatnak egy friss állapotot, így azonnal láthatják, hogy a megfelelő láncon vannak-e. Ezeket a státuszokat a gyenge szubjektivitás ellenőrzési pontjainak nevezik, és más csomópontok üzemeltetőitől kaphatók, blokkfelfedezőktől vagy több nyilvános végponttól. + +[Bővebben a gyenge szubjektivitásról](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## Ellenáll a proof-of-stake a cenzúrának? {#is-pos-censorship-resistant} + +A cenzúrának való ellenállását jelenleg nehéz bizonyítani. A proof-of-worktől eltérően azonban a proof-of-stake lehetőséget ad a cenzúrázó validátorok megbüntetésére. A protokollban hamarosan szétválasztják a blokképítőket a blokkelőterjesztőktől, és bevezetik azon tranzakciók listáját, amelyeket a blokképítőknek bele kell foglalniuk a blokkba. Ez a javaslattevő-építő szétválasztás, mely segít megakadályozni, hogy a validátorok cenzúrázzák a tranzakciókat. + +[Bővebben a javaslattevő-építő szétválasztásról (PBS)](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## Az Ethereum proof-of-stake rendszerét érheti 51%-os támadás? {#pos-51-attack} + +Igen. A proof-of-stake rendszer ugyanúgy ki van téve az 51%-os támadásnak, mint a proof-of-work. Ahelyett, hogy a támadónak a hálózat hash teljesítményének 51%-ára lenne szüksége, az összes letétbe helyezett ETH 51%-a kell. Az a támadó, aki a teljes letét 51%-át összegyűjti, átveszi az irányítást az elágazásválasztó-algoritmus felett. Ez lehetővé teszi a támadó számára, hogy bizonyos tranzakciókat cenzúrázzon, rövidtávú átszervezéseket végezzen, és a blokkok önérdekű átrendezésével profitot (MEV) szerezzen. + +[Bővebben a proof-of-stake-re irányuló támadásokról](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## Mi a közösségi koordináció, és miért van rá szükség? {#what-is-social-coordination} + +A közösségi koordináció az Ethereum utolsó védelmi vonala, amely lehetővé teszi, hogy egy helyes láncot helyreállítsanak egy olyan támadásból, amely helytelen blokkokat véglegesített. Ebben az esetben az Ethereum közösségének „sávon kívül” kellene koordinálnia és megállapodnia egy helyes kisebbségi elágazás használatában, és ezzel a támadó validátorait kizárni (slashing). Ehhez az alkalmazásokra és a tőzsdékre is szükség lenne, hogy felismerjék a helyes elágazást. + +[Bővebben a közösségi koordinációról](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## A proof-of-stake-ben a gazdagok gazdagabbak lesznek? {#do-rich-get-richer} + +Minél több ETH-t tesz letétbe valaki, annál több validátort tud futtatni, és annál több jutalmat tud felhalmozni. A jutalmak lineárisan skálázódnak a letétbe helyezett ETH összegével, és mindenki ugyanannyi százalékos hozamot kap. A proof-of-work jobban gazdagítja a gazdagokat, mint a proof-of-stake, mivel a gazdagabb bányászok, akik hardvereket vásárolnak, a méretgazdaságosság előnyeit élvezik, tehát a vagyon és a jutalom közötti kapcsolat nem lineáris. + +## A proof-of-stake centralizáltabb, mint a proof-of-work? {#is-pos-decentralized} + +Nem, a proof-of-work a centralizáció felé hajlik, mivel a bányászati költségek növekednek és kiszorítják a magánszemélyeket, majd a kisebb vállalatokat, és így tovább. A proof-of-stake jelenlegi problémája a likvid letéti derivatívák (LSD) hatása. Ezek olyan tokenek, amelyek valamilyen letétbe helyezett ETH-t képviselnek, és amelyeket bárki elcserélhet a másodlagos piacokon anélkül, hogy a tényleges ETH letétet felbontanák. Az LSD-k lehetővé teszik a felhasználók számára, hogy 32 ETH-nél kevesebb letétet tegyenek, de egyúttal centralizációs kockázatot is teremtenek, ahol néhány nagy szervezet végül a letét nagy részét ellenőrizheti. Ezért az [önálló letétbe helyezés](/staking/solo) a legjobb megoldás az Ethereum számára. + +[Bővebben a letétcentralizációról az LSD-kben](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## Miért csak ETH-t lehet letétbe helyezni? {#why-can-i-only-stake-eth} + +Az ETH az Ethereum natív valutája. Elengedhetetlen, hogy minden letét egyetlen valutában legyen, mert így lehet a súlyozott szavazatokhoz szükséges aktuális egyenlegeket venni és ez kell a biztonsághoz is. Az ETH az Ethereum alapvető összetevője, nem egy okosszerződés. Más valuták beépítése jelentősen megnövelné a bonyolultságot és csökkentené a letétek biztonságát. + +## Az Ethereum az egyetlen proof-of-stake blokklánc? {#is-ethereum-the-only-pos-blockchain} + +Nem, több proof-of-stake blokklánc létezik. Egyik sem azonos az Ethereummal, mert annak proof-of-stake mechanizmusa egyedülálló. + +## Mi az a Beolvadás? {#what-is-the-merge} + +A Beolvadás volt az a pillanat, amikor az Ethereum kikapcsolta a proof-of-work alapú konszenzusmechanizmusát, és bekapcsolta a proof-of-stake alapút. A Beolvadás 2022. szeptember 15-én történt. + +[A beolvadásról bővebben](/roadmap/merge) + +## Mi az elérhetőség és a biztonság? {#what-are-liveness-and-safety} + +Az elérhetőség és a biztonság a blokklánc két alapvető biztonsági szempontja. Az elérhetőség azt jelenti, hogy a lánc véglegesedni tud. Ha a lánc véglegesedése leáll, vagy a felhasználók nem tudnak könnyen hozzáférni, akkor nem elérhető a lánc. A hozzáférés rendkívül magas költségei is elérhetőségi hibák. A biztonság arra utal, hogy mennyire nehéz a láncot megtámadni, vagyis egymásnak ellentmondó ellenőrzőpontokat véglegesíteni. + +[Bővebb információkat talál a Casper dokumentációban](https://arxiv.org/pdf/1710.09437.pdf) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" new file mode 100644 index 00000000000..d2dc7a2fbfd --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" @@ -0,0 +1,52 @@ +--- +title: Gasper +description: A Gasper proof-of-stake mechanizmusának magyarázata. +lang: hu +--- + +A Gasper a Casper, a baráti véglegességi eszköz (Casper-FFG), és az LMD-GHOST elágazásválasztó-algoritmus kombinációja. Ezek az összetevők együttesen alkotják az Ethereum proof-of-stake-et biztosító konszenzusmechanizmust. A Casper az a mechanizmus, amely bizonyos blokkokat „véglegesre” frissít, hogy a hálózatba újonnan belépők biztosak lehessenek abban, hogy a kanonikus láncot szinkronizálják. Az elágazásválasztó algoritmus felhalmozott szavazatokat használ, hogy a csomópontok könnyen kiválaszthassák a helyeset, amikor elágazások keletkeznek a blokkláncban. + +**Érdemes megjegyezni**, hogy a Casper-FFG eredeti definíciója kissé megváltozott a Gasperbe való beépítéshez. Ezen az oldalon a frissített változatot tekintjük át. + +## Előfeltételek + +A jelen téma könnyebb megértéséhez tekintse meg a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) alapjairól szóló bevezető oldalt. + +## A Gasper szerepe {#role-of-gasper} + +A Gasper egy proof-of-stake blokklánc tetején helyezkedik el, ahol a csomópontok biztonsági letétként ethert biztosítanak, amely megsemmisíthető, ha lusták vagy rosszhiszeműek a blokkok javaslata vagy validálása során. A Gasper az a mechanizmus, amely meghatározza, hogyan jutalmazzák és büntetik a validátorokat, hogyan döntenek arról, hogy mely blokkokat fogadják el és melyeket utasítják el, és hogy a blokklánc melyik elágazására építsenek. + +## Mi az a véglegesség? {#what-is-finality} + +A véglegesség bizonyos blokkok tulajdonsága, ami azt jelenti, hogy nem lehet visszafordítani azokat, kivéve, ha kritikus konszenzushiba történt, és a támadó a teljes letétbe helyezett ether legalább 1/3-át megsemmisítette. A véglegesített blokkok olyan információkat jelentenek, amelyekkel kapcsolatban a blokklánc biztos. Egy blokknak kétlépcsős frissítési eljáráson kell átesnie ahhoz, hogy véglegesítésre kerüljön: + +1. Az összes feltett ether kétharmadának kell megszavaznia, hogy az adott blokk bekerüljön a kanonikus láncba. Ez a feltétel a blokkot „érvényesített” kategóriába emeli. Az érvényesített blokkokat nem valószínű, hogy visszafordítják, de bizonyos feltételek mellett megtörténhet. +2. Ha egy másik blokkot érvényesítenek egy érvényesített blokk tetején, akkor az „véglegesített” állapotba kerül. Egy blokk véglegesítése az adott blokknak a kanonikus láncba való felvétele iránti elköteleződés. Nem lehet visszaállítani, kivéve, ha egy támadó több millió ethert (több milliárd $USD) semmisít meg. + +Ezek a blokkfrissítések nem minden slotban történnek meg. Ehelyett csak a korszakhatárhoz tartozó blokkok érvényesíthetők és véglegesíthetők. Ezeket a blokkokat ellenőrzőpontoknak nevezzük. A frissítés az ellenőrzőpontpárokat veszi figyelembe. Két egymást követő ellenőrzőpont között „szupertöbbségi kapcsolatnak” kell fennállnia (az összes letétbe helyezett ether kétharmada szavaz arra, hogy a B ellenőrzőpont az A ellenőrzőpont helyes leszármazottja) ahhoz, hogy a korábbi ellenőrzőpontot véglegesítettre, a frissebbet pedig érvényesítettre lehessen állítani. + +Mivel a véglegesítéshez kétharmados egyetértés kell a blokk kanonikus voltát illetően, egy támadó nem tud a következők nélkül alternatív véglegesített láncot létrehozni: + +1. A teljes letétbe helyezett ether kétharmadának birtoklása vagy manipulálása nélkül. +2. A letétbe helyezett ether legalább egyharmadának elpusztítása nélkül. + +Az első feltétel azért merül fel, mert egy lánc véglegesítéséhez a letétbe helyezett ether kétharmadára van szükség. A második feltétel azért van, mert ha a teljes letét kétharmada mindkét elágazás mellett szavazott, akkor egyharmadának mindkettőre szavaznia kellett. A kettős szavazás súlyos büntetést és kizárást von maga után, amelyet maximálisan büntetnének, és a teljes letét egyharmada megsemmisülne. 2022 májusától ezért egy támadónak körülbelül 10 milliárd dollár értékű ethert kellene elégetnie. A Gasperben a blokkokat érvényesítő és véglegesítő algoritmus a [Casper-FFG](https://arxiv.org/pdf/1710.09437.pdf) kissé módosított formája. + +### Ösztönzők és súlyos büntetés (slashing) {#incentives-and-slashing} + +A validátorok jutalmat kapnak a blokkok jóhiszemű előterjesztéséért és validálásáért. Ethert kapnak jutalomként, mely hozzáadódik a letétjükhöz. Másrészt, azok a validátorok, akik nem cselekszenek, amikor felszólítják őket, lemaradnak ezekről a jutalmakról, és bizonyos esetekben elveszítik meglévő letétjük egy kis részét. A távolmaradásért járó büntetések csekélyek, és a legtöbb esetben csak a jutalmak elmaradását jelentik. Ugyanakkor vannak olyan validátori műveletek, amelyeket nehéz lenne véletlenül megtenni, ezért valamilyen rosszindulatú szándékot jeleznek, például több blokkot javasolni vagy tanúsítani ugyanarra a slotra, vagy ellentmondani a korábbi ellenőrzési pontra vonatkozó szavazásnak. Ezek a viselkedésmódok súlyos büntetést vonnak maguk után komoly következményekkel: a slashing eredményeként a validátor letétjének egy része megsemmisül, a validátort pedig eltávolítják a hálózatból. Ez a folyamat 36 napig tart. Az 1. napon legfeljebb 1 ETH összegű kezdeti büntetés jár. Ezután a súlyos büntetést kapott validátor ether egyenlege lassan fogy a kilépési időszak alatt, de a 18. napon „korrelációs büntetést” kap, amely nagyobb, ha több validátor egy időben kerül kizárásra. A maximális büntetés a teljes letét. Ezek a jutalmak és büntetések arra szolgálnak, hogy ösztönözzék a becsületes validátorokat, és visszatartsák a hálózat elleni támadásokat. + +### Inaktivitási elszivárgás {#inactivity-leak} + +A biztonság mellett a Gasper „elfogadható elérhetőséget” is biztosít. Ez az a feltétel, hogy amíg az összes letétbe helyezett ether kétharmada becsületesen és a protokollt követve szavaz, a lánc képes lesz a véglegesítésre, függetlenül bármilyen más tevékenységtől (például támadások, késleltetés vagy súlyos büntetések). Másképp fogalmazva, a teljes letétbe helyezett ether egyharmadának veszélyeztetettnek kell lennie ahhoz, hogy a lánc ne tudjon véglegesedni. A Gasperben van egy további védelmi vonal az elérhetőség sérülése ellen, amelyet „inaktivitási elszivárgásként” ismerünk. Ez a mechanizmus akkor aktiválódik, amikor a blokklánc véglegesítése több mint négy korszakon keresztül meghiúsul. Azoknak a validátoroknak, akik nem tanúsítják aktívan a többségi láncot, a letétjük fokozatosan elszivárog, amíg a többség vissza nem nyeri a teljes letét kétharmadát, így az elérhetőség sérülése csak átmeneti. + +### Elágazásválasztás {#fork-choice} + +A Casper-FFG eredeti definíciója tartalmazott egy elágazásválasztó algoritmust a következő szabállyal: `kövesse azt a láncot, amely a legnagyobb magasságú érvényesített ellenőrzőpontot tartalmazza`, ahol a magasságot a genezisblokktól való távolságként határozzuk meg. A Gasperben az eredeti elágazásválasztási szabályt lecserélték egy kifinomultabb, LMD-GHOST nevű algoritmusra. Fontos megérteni, hogy normális körülmények között az elágazásválasztási szabály szükségtelen, mert minden slothoz egyetlen blokkajánló tartozik, és ezt a jóhiszemű validátorok tanúsítják. Csak nagy hálózati aszinkronitás esetén, vagy ha egy rosszhiszemű blokkajánló kétértelműen nyilatkozott, van szükség elágazásválasztó algoritmusra. Ha azonban ezek az esetek mégis bekövetkeznek, ez az algoritmus kritikus védelmet jelent, ás biztosítja a helyes láncot. + +Az LMD-GHOST a következő kifejezés rövidítése: latest message-driven greedy heaviest observed sub-tree (a legutolsó üzenet által vezérelt, mohó, legsúlyosabb részfa). Ez egy nehézkes meghatározása annak, hogy a tanúsítások legnagyobb összesített súlyával rendelkező elágazást választja ki kanonikusnak (mohó legsúlyosabb részfa), és ha több üzenet érkezik egy validátortól, csak a legutolsót veszi figyelembe (legutolsó üzenet által vezérelt). Mielőtt a legnehezebb blokkot hozzáadná a kanonikus láncához, minden validátor minden blokkot e szabály alapján értékel. + +## További olvasnivaló {#further-reading} + +- [Gasper: A GHOST és a Casper kombinációja](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper, a baráti véglegességi eszköz (Friendly Finality Gadget)](https://arxiv.org/pdf/1710.09437.pdf) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" new file mode 100644 index 00000000000..dda68f89056 --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" @@ -0,0 +1,99 @@ +--- +title: Proof-of-stake (PoS) +description: A proof-of-stake konszenzusprotokoll és az Ethereumban betöltött szerepének bemutatása. +lang: hu +--- + +Az Ethereum [konszenzusmechanizmusa](/developers/docs/consensus-mechanisms/) a proof-of-stake (PoS) koncepción alapul. Az Ethereum 2022-ben váltott a proof-of-stake mechanizmusra, mivel biztonságosabb, kevésbé energiaintenzív és jobban megfelel az új méretezési megoldások bevezetéséhez, mint a korábbi [proof-of-work](/developers/docs/consensus-mechanisms/pow) architektúra. + +## Előfeltételek {#prerequisites} + +Az oldal könnyebben megértéséhez javasoljuk, hogy tekintse meg a [konszenzusmechanizmusok](/developers/docs/consensus-mechanisms/) cikket. + +## Mi az a proof-of-stake (PoS)? {#what-is-pos} + +A proof-of-stake (letéti igazolás) egy módszer annak bizonyítására, hogy a validátorok valamilyen értéket helyeztek a hálózatba, amely tisztességtelen cselekedet esetén megsemmisíthető. Az Ethereum proof-of-stake mechanizmusánál a validátorok ETH formájában zárolják tőkéjüket az Ethereumon található okosszerződésben. A validátor feladata annak ellenőrzése, hogy a hálózaton keresztül terjesztett új blokkok érvényesek, és adott esetben ő maga is új blokkokat hoz létre és terjeszt elő. Ha megpróbálják meghamisítani a hálózatot (például egy helyett több blokkot javasolnak, vagy egymásnak ellentmondó tanúsításokat küldenek), a letétbe helyezett ETH egy része vagy egésze megsemmisülhet. + +## Validátorok {#validators} + +A validátorként való részvételhez a felhasználónak 32 ETH-t kell egy letéti szerződésben zárolnia, és három különböző szoftvert kell futtatnia: egy végrehajtási klienst, egy konszenzusos klienst és egy validátorklienst. Az ETH letétbe helyezésével a felhasználó beáll egy aktiválási sorba, amely korlátozza az új validátorok hálózathoz való csatlakozásának ütemét. Az aktiválást követően a validátorok új blokkokat kapnak a társaiktól az Ethereum-hálózaton. A blokkban szállított tranzakciókat újra végrehajtják, hogy ellenőrizzék, hogy az Ethereum státuszában javasolt változások érvényesek-e, és ellenőrzik a blokk aláírását. A validátor ezután szavazatot (ún. tanúsítást) ad le az adott blokkra a hálózaton keresztül. + +Amíg a proof-of-work esetében a blokkidőt a bányászati nehézség határozza meg, addig a proof-of-stake esetén a tempó rögzített. A proof-of-stake Ethereum esetén az idő (12 másodperces) slotokra és korszakokra (egy korszak 32 slotból áll) oszlik. A rendszer minden slotban véletlenszerűen kiválaszt egy validátort a blokk előterjesztésére. Ez a validátor felel az új blokk létrehozásáért és elküldéséért a hálózat többi csomópontja felé. Emellett a rendszer minden slotban véletlenszerűen megválaszt egy a validátorbizottságot, amelynek a szavazatai döntenek az előterjesztett blokk érvényességéről. A validátorok bizottságokra való felosztása fontos a hálózati terhelés kezelhetősége szempontjából. A bizottságok úgy osztják fel a validátorhalmazt, hogy minden aktív validátor minden korszakban tanúsít, de nem minden slotban. + +## Hogyan kerülnek végrehajtásra a tranzakciók az Ethereum proof-of-stake mechanizmusban {#transaction-execution-ethereum-pos} + +Az alábbiakban egy teljes magyarázatot adunk arról, hogyan hajtanak végre egy tranzakciót az Ethereum proof-of-stake-ben. + +1. A felhasználó létrehoz és aláír egy [tranzakciót](/developers/docs/transactions/) a privát kulcsával. Ezt általában egy tárca vagy egy könyvtár, például [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) stb. kezeli, eközben a háttérben a felhasználó az Ethereum [JSON-RPC API](/developers/docs/apis/json-rpc/) segítségével kérést intéz egy csomóponthoz. A felhasználó meghatározza, hogy mennyi gázt fizet borravalóként a validátornak, hogy az felkapja az adott tranzakciót és betegye egy blokkba. A [borravalót](/developers/docs/gas/#priority-fee) megkapja a validátor, az [alapdíjat](/developers/docs/gas/#base-fee) pedig elégeti a rendszer. +2. A tranzakciót beküldik az Ethereum [végrehajtási klienshez](/developers/docs/nodes-and-clients/#execution-client), hogy ellenőrizze az érvényességét. Ennek része, hogy a küldőnek van elég ETH összege, hogy végre legyen hajtva a tranzakció és a megfelelő kulccsal írta azt alá. +3. Ha a tranzakció érvényes, a végrehajtási kliens a helyi tranzakciógyűjtőjéhez (memóriakészlet, a függő tranzakciók listája) adja és előterjeszti a többi csomópontnak a végrehajtási réteg pletykahálózatán. Amikor a többi csomópont hall a tranzakcióról, akkor azok is beteszik a helyi memóriakészletbe. A haladó felhasználók úgy is dönthetnek, hogy nem a hálózaton terjesztik el a tranzakciójukat, hanem továbbíthatják azt speciális blokképítőknek, mint a [Flashbots aukció](https://docs.flashbots.net/flashbots-auction/overview). Ez lehetővé teszi számukra, hogy a tranzakciókat a következő blokkokba szervezzék a maximális profit érdekében ([MEV](/developers/docs/mev/#mev-extraction)). +4. A hálózat egyik validátor-csomópontja az aktuális slot blokkelőterjesztője, amelyet előzőleg a RANDAO segítségével álvéletlenszerűen kiválasztottak. Ez a csomópont felelős az Ethereum blokklánchoz hozzáadandó következő blokk létrehozásáért és továbbításáért, valamint a globális státusz frissítéséért. A csomópont három részből áll: végrehajtási kliens, konszenzusos kliens és validátorkliens. A végrehajtási kliens a tranzakciókat a helyi memóriakészletből egy végrehajtási csomagba rendezi, és helyben végrehajtja őket, hogy státusztváltozást generáljon. Ezt az információt továbbítják a konszenzusos kliensnek, ahol a végrehajtási csomagot egy Beacon-blokk részeként csomagolják be, amely jutalmakra, büntetésekre, súlyos büntetésekre, tanúsításokra stb. vonatkozó információkat is tartalmaz, amelyek lehetővé teszik a hálózat számára, hogy megállapodjon a lánc élén álló blokkok sorrendjében. A végrehajtási és a konszenzusos kliensek közötti kommunikáció részletesebb leírása a [A konszenzusos és a végrehajtási kliensek összekapcsolása](/developers/docs/networking-layer/#connecting-clients) című cikkben található. +5. A többi csomópont az új Beacon-blokkot a konszenzusréteg pletykahálózatán keresztül kapja meg. Átadják azt a saját végrehajtási kliensüknek, ami a tranzakciókat helyben újra végrehajtja, így megbizonyosodnak arról, hogy érvényes a javasolt státuszváltozás. A validátorkliens ezután tanúsítja, hogy a blokk érvényes, és logikailag ez a következő blokk a láncban (vagyis az [elágazásválasztási szabályok](/developers/docs/consensus-mechanisms/pos/#fork-choice) szerint a legnagyobb tanúsítási súllyal bíró láncra épül). A blokk hozzáadódik a helyi adatbázishoz minden olyan csomópontban, amely tanúsítja azt. +6. A tranzakció akkor tekinthető „véglegesítettnek”, ha egy olyan lánc részévé vált, amelyben két ellenőrzőpont között „szupertöbbségi kapcsolat” van. Az ellenőrzési pontok minden korszak kezdetén fordulnak elő, és azért léteznek, mert az aktív tanúsítóknak csak egy részhalmaza tanúsít minden slotban, de az összes aktív tanúsító minden korszakban tanúsít. Ezért csak a korszakok között lehet „szupertöbbségi kapcsolat” (mikor a hálózaton lévő összes letétbe helyezett ETH 66%-a egyetért két ellenőrzőponton). + +A véglegesedésről a következő részben találhat bővebb információkat. + +## Véglegesség {#finality} + +Az elosztott hálózatokon egy tranzakció akkor válik „véglegessé”, amikor egy olyan blokk része lesz, amelyet csak jelentős mennyiségű ETH elégetésével lehet megváltoztatni. A proof-of-stake Ethereum-hálózata ezt az úgynevezett „checkpoint” (ellenőrző pont) blokkokkal éri el. Minden korszak első blokkja egy checkpoint blokk. A validátorok szavaznak az általuk érvényesek tartott checkpoint blokkpárokra. Ha egy checkpoint blokkpár megkapja legalább az összes letétbe helyezett ETH kétharmadát képviselő szavazatmennyiséget, akkor a checkpoint blokkok frissülnek. A kettő közül a későbbi (célblokk) „igazolt” állapotba kerül. A kettő közül a korábbi már igazolt állapotú, mivel az előző korszak „célblokkja” volt. Ez a blokk „véglegesített” állapotba kerül. + +Egy véglegesített blokk visszaalakításához egy támadónak legalább a letétbe helyezett összes ETH egyharmadát fel kellene áldoznia. Ennek pontos okát az [Ethereum Alapítvány blogposztja](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) részletesen ismerteti. Mivel a véglegességhez kétharmados többség szükséges, egy támadó a teljes ETH-letét egyharmadával szavazva akadályozhatja meg, hogy a hálózat véglegesítse a blokkot. Létezik egy mechanizmus, amellyel védekezni lehet ez ellen: ez az [inactivity leak](https://eth2book.info/bellatrix/part2/incentives/inactivity) (inaktivitási szivárgás). Akkor aktiválódik, amikor a blokklánc véglegesítése több mint négy korszakon keresztül meghiúsul. Az inactivity leak elszivárogtatja a többség ellen szavazó validátorok ETH-letétjét, ezzel lehetővé teszi, hogy a többség visszaszerezze a kétharmados többséget és véglegesítse a láncot. + +## Kriptogazdaság-védelem {#crypto-economic-security} + +Egy validátor futtatása elkötelezettséget jelent. A validátortól elvárják, hogy megfelelő hardvert és internetkapcsolatot tartson fenn a blokkvalidálásban és -előterjesztésben való részvételhez. Cserébe a validátor ETH-kifizetést kap (növekszik a letéti egyenlege). Ugyanakkor a validátorként való részvétel új lehetőségeket kínál a felhasználóknak, hogy személyes haszon vagy szabotázs érdekében megtámadják a hálózatot. Ez ellen hat, hogy a validátorok elveszítik az ETH-jutalmakat, ha felhívás esetén nem vesznek részt a validálásban, és a meglévő letétjük is megsemmisülhet, ha becstelenül viselkednek. Két fő viselkedési módot tekintünk rosszhiszeműnek: egy sloton belül több blokk előterjesztése (kétértelműsítés), valamint az ellentmondásos tanúsítások elküldése. + +A megvágott ETH-mennyiség azon múlik, hogy ugyanabban az időben hány másik validátor ETH-letétjét vágja még meg a rendszer. Ez az úgynevezett [„korrelációs bírság”](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty), amelynek mértéke lehet csekély (a letét kb. 1%-a az egyedülálló validátornál), de eredményezheti akár a validátori letét 100%-ának elvesztését is (tömeges megvágási esemény). Egy kényszerített kilépési periódus felénél szabja ki a rendszer, amely egy azonnali bírsággal (legfeljebb 1 ETH) kezdődik az 1. napon, majd korrelációs bírsággal folytatódik a 18. napon, végül a hálózatból való kivetéssel fejeződik be a 36. napon. Kis összegű tanúsítási bírságot kapnak minden nap, mert jelen vannak a hálózaton, de nem adnak le szavazatot. Ez mind azt jelenti, hogy egy koordinált támadás nagyon költséges lenne a támadó számára. + +## Elágazásválasztás {#fork-choice} + +Amikor a hálózat optimálisan és becsületesen működik, akkor mindig csak egy blokk van a lánc elején, és minden validátor tanúsítja azt. Mindazonáltal lehetséges, hogy hálózati látencia vagy a blokkelőterjesztő kétértelmű javaslata miatt a validátorok eltérően látják a lánc elejét. Ezért a konszenzusklienseknek egy algoritmusra van szükségük, hogy eldöntsék, melyiket részesítsék előnyben. A proof-of-stake Ethereum által használt algoritmus az [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf), és úgy működik, hogy azonosítja az előzmények szerint a tanúsítások legnagyobb többségét magáénak tudó elágazást (fork). + +## Proof-of-stake és biztonság {#pos-and-security} + +Egy [51%-os támadás](https://www.investopedia.com/terms/1/51-attack.asp) veszélye a proof-of-work architektúrához hasonlóan a proof-of-stake konszenzusnál is fennáll, ám itt még kockázatosabb a támadók számára. A támadónak a letétbe helyezett ETH-mennyiség 51%-ára volna szüksége. Így a saját tanúsításai segítségével biztosíthatná, hogy az általa előnyben részesített elágazás (fork) szerezze meg a legtöbb tanúsítást. A felhalmozott tanúsítások „súlya” az, amit a konszenzuskliensek a helyes lánc meghatározásához használnak, tehát ez a támadó képes volna általánosan elfogadottá tenni a saját elágazását. Ugyanakkor a proof-of-work konszenzussal szemben a proof-of-stake erőssége az ellentámadás rugalmas bevezetésében rejlik. Például a becsületes validátorok dönthetnek úgy, hogy tovább építik a kisebbségi láncot, és figyelmen kívül hagyják a támadó elágazását, és ugyanerre biztatják az alkalmazásokat, a tőzsdéket és a poolokat is. Úgy is határozhatnak, hogy erőszakkal eltávolítják támadót hálózatról, és megsemmisítik az ETH-letétjét. Ezek erős gazdaságvédelmet jelentenek az 51%-os támadások ellen. + +Az 51%-os támadáson túl a rosszhiszemű szereplők megpróbálhatnak más jellegű káros tevékenységeket, mint amilyen: + +- a nagy hatótávolságú támadások (bár a véglegességi eszköz semlegesíti ezt a támadási vektort) +- rövid hatótávolságú „átrendezések” (bár a javaslattevő-erősítése és a tanúsítási határidők kivédik ezt) +- pattogó (bouncing) és a kiegyenlítő (balancing) támadások (szintén mitigálja a javaslattevő-erősítése, és ezeket főleg ideális hálózati körülmények között lehet végrehajtani) +- lavinatámadások (az elágazásválasztási algoritmus szabálya semlegesíti, amely csak az utolsó üzenetet veszi figyelembe) + +Összességében a proof-of-stake – ahogy azt az Ethereum megvalósította – gazdasági szempontból bizonyítottan védettebb, mint proof-of-work. + +## Előnyök és hátrányok {#pros-and-cons} + +| Előnyök | Hátrányok | +| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | +| A letétbe helyezés az egyének számára megkönnyíti a részvételt a hálózat biztosításában, ezzel elősegíti a decentralizációt. Validátor-csomópont egy átlagos laptopon is futtatható. A letéti alapok lehetővé teszik, hogy a felhasználók akkor is részt vegyenek, ha nincs 32 ETH-jük. | A proof-of-stake fiatalabb és még kevésbé tesztelt, mint a proof-of-work. | +| A letétbe helyezés decentralizáltabb. A méretgazdaságosság nem úgy érvényesül, mint a PoW-bányászat esetén. | A proof-of-stake esetén a megvalósítás bonyolultabb, mint a proof-of-work konszenzusnál. | +| A proof-of-stake erősebb kriptogazdasági védelmet kínál, mint a proof-of-work. | A felhasználóknak három szoftvert kell futtatniuk, hogy részt vehessenek az Ethereum proof-of-stake konszenzusában. | +| Kevesebb új ETH-t kell kibocsátani a hálózati résztvevők ösztönzéséhez. | | + +### Összehasonlítása a proof-of-work mechanizmussal {#comparison-to-proof-of-work} + +Az Ethereum eredetileg proof-of-work mechanizmust használt, amelyről proof-of-stake mechanizmusra váltott 2022 szeptemberében. A PoS számos előnnyel jár a PoW-vel szemben: + +- nagyobb energiahatékonyság – nincs szükség sok energia felhasználására a proof-of-work számításokhoz; +- alacsonyabb belépési korlát, csökkentett hardverkövetelmények – nincs szükség csúcstechnológiás hardverre ahhoz, hogy esélyünk legyen új blokkot létrehozni; +- kisebb centralizációs kockázat – a proof-of-stake architektúra több csomópont részvételét eredményezi a hálózat biztosításában; +- az alacsony energiaszükséglet miatt kevesebb ETH-t kell kibocsátani a részvételre ösztönzéshez; +- a szabálytalan viselkedés gazdasági büntetése miatt a proof-of-work architektúrához képest magasabb költséggel jár az 51%-os típusú támadás a támadó számára; +- ha egy 51%-os támadás legyűri a kriptogazdasági védelmi rendszert, a közösség dönthet egy becsületes blokklánc közösségi visszaállítása mellett. + +## További olvasnivaló {#further-reading} + +- [Proof-of-stake (letéti igazolás) GYIK](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ +- [Mi az a Proof-of-Stake?](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ +- [Mi az a Proof-of-Stake és miért fontos?](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ +- [Miért a proof-of-stake (2020. november)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ +- [Proof-of-Stake: Hogyan tanultam meg szeretni a gyenge szubjektivitást](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ +- [Proof-of-stake Ethereum – támadás és védekezés](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [A proof-of-stake tervezési filozófiája](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ +- [Videó: Vitalik Buterin elmagyarázza a proof-of-stake mechanizmust Lex Fridmannak](https://www.youtube.com/watch?v=3yrqBG-7EVE) + +## Kapcsolódó témák {#related-topics} + +- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/) +- [Proof-of-authority (jogosultsági igazolás)](/developers/docs/consensus-mechanisms/poa/) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" new file mode 100644 index 00000000000..bc2fcecc6fb --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" @@ -0,0 +1,96 @@ +--- +title: Kulcsok a proof-of-stake Ethereumban +description: Az Ethereum proof-of-stake konszenzusmechanizmusában használt kulcsok ismertetése +lang: hu +--- + +Az Ethereum a nyilvános-privát kulcspáron alapuló kriptográfia segítségével biztosítja a felhasználói eszközöket. A nyilvános kulcs az Ethereum-cím alapjául szolgál, tehát látható a nyilvánosság számára, és egyedi azonosítóként használják. A privát (vagy titkos) kulcshoz mindig csak a számla tulajdonosa férhet hozzá. A privát kulcsot tranzakciók és adatok aláírására használják, hogy a kriptográfia bizonyítani tudja, hogy a tulajdonos jóváhagyja az adott privát kulcs műveletét. + +Az Ethereum kulcsait [elliptikus görbe kriptográfiával](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) generálják. + +Amikor azonban az Ethereum [proof-of-work](/developers/docs/consensus-mechanisms/pow) mechanizmusról [proof-of-stake-re](/developers/docs/consensus-mechanisms/pos) váltott, egy új típusú kulcs került az Ethereumba. Az eredeti kulcsok továbbra is pontosan ugyanúgy működnek, mint korábban – a számlákat biztosító elliptikus görbén alapuló kulcsok nem változtak. A felhasználóknak azonban új típusú kulcsra volt szükségük ahhoz, hogy részt vehessenek a proof-of-stake-ben az ETH letétbe helyezésével és a validátorok futtatásával. Ez az igény a skálázhatóság miatt érdekes, hogy a nagyszámú validátorok közötti üzenetekhez olyan kriptográfiai módszer legyen, amely könnyen aggregálható, így csökkenti a hálózati konszenzus kommunikációs igényét. + +Ez az új típusú kulcs a [**Boneh-Lynn-Shacham (BLS)** aláírási sémát használja](https://wikipedia.org/wiki/BLS_digital_signature). A BLS lehetővé teszi az aláírások nagyon hatékony aggregálását, ugyanakkor az aggregált egyedi validátorkulcsok visszafejtését is, és ideális a validátorok közötti műveletek kezelésére. + +## A validátorkulcsok két típusa {#two-types-of-keys} + +A proof-of-stake-re való átállás előtt az Ethereum-felhasználóknak csak egyetlen elliptikus görbén alapuló privát kulccsal volt hozzáférésük a pénzükhöz. A proof-of-stake bevezetésével az önálló letétbe helyezőknek szükségük volt egy **validátorkulcsra** és egy **kivételi kulcsra** is. + +### A validátorkulcs {#validator-key} + +A validátor aláírókulcs két elemből áll: + +- Validátor **privát** kulcs +- Validátori **nyilvános** kulcs + +A validátor privát kulcsának célja a láncon belül végrehajtott műveletek, például a blokkjavaslatok és a tanúsítások aláírása. Emiatt ezeket a kulcsokat egy „forró” tárcában kell tartani (mindig online és elérhető legyen). + +Ennek a rugalmasságnak az az előnye, hogy a validátor aláírókulcsok gyorsan mozgathatók egyik eszközről a másikra, azonban ha elvesznek vagy ellopják azokat, a tolvaj többféleképpen is képes lehet **visszaélni** azokkal: + +- A validátort súlyos és kizárással járó büntetés éri: + - Amikor blokkelőterjesztő, akkor két különböző Beacon blokkot javasol és ír alá ugyanarra a slotra + - Tanúsítóként olyan tanúsítást hagy jóvá, amely „körbeölel” egy másikat + - Tanúsítóként két eltérő tanúsítást ír alá ugyanarra a dologra +- Önkéntes kilépésre kényszeríti, amely a validátor letétjét feloldja és a kivételi kulcs tulajdonosa hozzáfér az ETH-egyenleghez + +A **validátor nyilvános kulcsa** szerepel a tranzakció adataiban, amikor egy felhasználó ETH-t fizet be a letéti szerződésbe. Ez az úgynevezett _letéti adat_, amely lehetővé teszi az Ethereum számára a validátor azonosítását. + +### Kivételi hitelesítő adatok {#withdrawal-credentials} + +Minden validátor rendelkezik egy tulajdonsággal, amelyet _visszavonási hitelesítő adatoknak_ neveznek. Ez a 32 bájtos mező vagy `0x00`-val kezdődik, ami a BLS kivonási hitelesítő adatokat jelenti, vagy az eleje` 0x01`, ami a végrehajtási címre mutató hitelesítő adatokat jelenti. + +A `0x00` BLS kulcsokkal rendelkező validátoroknak frissíteniük kell ezeket a hitelesítő adatokat, hogy azok egy végrehajtási címre mutassanak a többletegyenleg kifizetéséhez vagy a letétkivonáshoz. Ezt úgy lehet megtenni, hogy a kezdeti kulcsgenerálás során a letétbe helyezési adatokban megadunk egy végrehajtási címet, _VAGY_ úgy, hogy a kivételi kulcsot egy későbbi időpontban felhasználjuk egy `BLSToExecutionChange` üzenet aláírására és továbbítására. + +### A kivételi kulcs {#withdrawal-key} + +A kivételi kulcsra a kivételi hitelesítő adatok frissítéséhez van szükség, hogy azok egy végrehajtási címre mutassanak, ha a kezdeti befizetés során ezt nem állították be. Ez lehetővé teszi a felhasználók számára a többletegyenleg-kifizetések feldolgozásának elindítását, és a letétbe helyezett ETH teljes kivételét is. + +Ahogy a validátorkulcsok, a kivételi kulcsok is két elemből állnak: + +- Kivételi **privát** kulcs +- Kivételi **nyilvános** kulcs + +Ennek a kulcsnak az elvesztése a kivételi hitelesítő adatok `0x01` típusra történő frissítése előtt a validátoregyenleghez való hozzáférés elvesztését jelenti. A validátor továbbra is aláírhatja a tanúsításokat és a blokkokat, mivel ezekhez a műveletekhez a validátor privát kulcsa szükséges, azonban a kivételi kulcsok elvesztése miatt erre igen kevés a motivációja. + +A validátorkulcsok és az Ethereum-számlakulcsok szétválasztása lehetővé teszi, hogy egyetlen felhasználó több validátort is futtasson. + +![validátorkulcs ábrája](validator-key-schematic.png) + +## Kulcsok származtatása egy kulcsmondatból {#deriving-keys-from-seed} + +Ha minden 32 ETH feltöltéséhez 2 független kulcsból álló új készletre lenne szükség, a kulcskezelés nehézkessé válna, különösen a több validátort futtató felhasználók számára. Ehelyett több validátorkulcsot lehet egyetlen titokból levezetni, és ennek a titoknak a tárolása lehetővé teszi a hozzáférést több validátorkulcshoz. + +[Az emlékeztető kódszó](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) és az útvonalak olyan kiemelkedő jellemzők, amelyekkel a felhasználók gyakran találkoznak, amikor [hozzáférnek](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) a tárcájukhoz. Az emlékeztető kódszó egy szavakból álló sorozat, amely a privát kulcs kezdeti magjaként szolgál. További adatokkal kombinálva az emlékeztető kódszó egy „mesterkulcs” néven ismert hasht generál. Ezt úgy lehet elképzelni, mint egy fa gyökerét. Ebből a gyökérből hierarchikus útvonal segítségével elágazások vezethetők le, így a gyermek csomópontok a szülői csomópont hashjének és a fán belüli indexének kombinációjaként létezhetnek. Tekintse meg a [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) és [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) szabványokat az emlékeztetőkódszó-alapú kulcsgeneráláshoz. + +Ezek az útvonalak a következőképpen néznek ki, ami ismerős lehet azoknak, akik már dolgoztak hardvertárcákkal: + +``` +m/44'/60'/0'/0` +``` + +Az ebben az elérési útvonalban lévő perjelek a következőképpen választják el a privát kulcs összetevőit: + +``` +master_key / purpose / coin_type / account / change / address_index +``` + +Ez a logika lehetővé teszi a felhasználók számára, hogy egyetlen **emlékeztető kódszóhoz** a lehető legtöbb validátort csatolják, mivel a fa gyökere közös lehet, és a differenciálás az elágazásokban történhet. A felhasználó **az emlékeztető kódszóból tetszőleges számú kulcsot** származtathat. + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +Az egyes ágakat `/` választja el egymástól, így `m/2` azt jelenti, hogy a mesterkulccsal kezdjük, és a 2. ágat követjük. Az alábbi ábrán egyetlen emlékeztető kódszót használunk három kivételi kulcs tárolására, mindegyikhez két validátor tartozik. + +![validátorkulcs-logika](multiple-keys.png) + +## További olvasnivaló {#further-reading} + +- [Ethereum Alapítvány blogbejegyzés Carl Beekhuizentől](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333 BLS12-381 kulcsgenerálás](https://eips.ethereum.org/EIPS/eip-2333) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" new file mode 100644 index 00000000000..36d344276db --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" @@ -0,0 +1,69 @@ +--- +title: A proof-of-stake és a proof-of-work összehasonlítása +description: Az Ethereum proof-of-stake és proof-of-work alapú konszenzusmechanizmusának összehasonlítása +lang: hu +--- + +Amikor az Ethereumot bevezették, a proof-of-stake (letéti igazolás) még sok kutatást és fejlesztést igényelt, mielőtt erre alapozhatták volna az Ethereum biztosítását. A proof-of-work (munkaigazolás) egy egyszerűbb mechanizmus volt, ami már működött a Bitcoinnál, így a központi fejlesztők egyszerűen implementálni tudták, hogy elindulhasson az Ethereum. Ezután a proof-of-stake mechanizmusát még nyolc évig fejlesztették, mielőtt áttérek volna rá. + +Ez az oldal az Ethereum proof-of-work mechanizumusról proof-of-stake mechanizmusra való áttérésének okait és a szükséges kompromisszumokat magyarázza el. + +## Biztonság {#security} + +Az Ethereum kutatói biztonságosabbnak tartják a proof-of-stake-et, mint a proof-of-worköt. Ez nemrég került bevezetésre a valódi Ethereum főhálózatra, és kevésbé bizonyított, mint a proof-of-work. A következő részben a proof-of-stake biztonsági modelljének előnyeit és hátrányait tárgyaljuk a proof-of-workhöz képest. + +### A támadás költsége {#cost-to-attack} + +A proof-of-stake-ben a validátoroknak letétbe kell helyezniük 32 ETH-t egy okosszerződésben. Az Ethereum a rosszhiszemű validátorokat büntetheti azzal, hogy megsemmisíti a letétbe helyezett ethert. A konszenzushoz a teljes letétbe helyezett ether legalább 66%-a kell szavazzon a blokkok egy bizonyos halmazára. A letét >=66%-a által megszavazott blokkok „véglegesítetté” válnak, ami azt jelenti, hogy nem lehet őket eltávolítani vagy átszervezni. + +A hálózat elleni támadás jelentheti azt, hogy megakadályozzák a lánc véglegesítését, vagy a blokkokat a támadó számára előnyös sorrendbe rendezik a kanonikus láncban. Ehhez a támadónak el kell térítenie a helyes konszenzus útját azzal, hogy nagy mennyiségű ethert halmoz fel, és közvetlenül azzal szavaz, vagy úgy, hogy becsapja a becsületes validátorokat, hogy egy bizonyos módon szavazzanak. A kifinomult, kis valószínűséggel bíró támadások során a jóhiszemű validátorokat eltérítik, ekkor az Ethereum megtámadásának költsége azonos a letéttel, amelyet a támadónak fel kell halmoznia ahhoz, hogy a konszenzust a maga javára befolyásolja. + +A legalacsonyabb támadási költség a teljes letét >33%-a. A teljes letét >33%-át birtokló támadó egyszerűen offline állapotba kerülve késleltetheti a véglegesítést. Ez viszonylag kisebb probléma a hálózat számára, mivel létezik egy „inaktivitási elszivárgási” mechanizmus, amely addig redukálja a letéteket az offline validátoroktól, amíg az online többség a letét 66%-át nem képviseli, és újra véglegesíteni tudja a láncot. Elméletileg az is lehetséges, hogy egy támadó a teljes letét valamivel több mint 33%-ával kettős véglegesítést idézzen elő azáltal, hogy egy helyett két blokkot hoz létre, amikor felkérik, hogy legyen blokkelőterjesztő, majd az összes validátorral együtt kétszeresen szavazzon. Mindkét elágazáshoz csak a megmaradt becsületes validátorok 50%-ának kell először látni az egyes blokkokat, így ha sikerül pontosan időzíteniük az üzeneteiket, akkor képesek lehetnek mindkét elágazást véglegesíteni. Ennek kicsi a valószínűsége, de ha egy támadó képes lenne kettős véglegesítést előidézni, akkor az Ethereum közösségének úgy kellene döntenie, hogy az egyik elágazást követi, és ebben az esetben a támadó validátorait a másik elágazáson súlyosan megbüntetnék és kizárnák. + +A teljes letét >33%-ával egy támadónak esélye van arra, hogy kisebb (véglegesítés késleltetése) vagy komolyabb (dupla véglegesítés) hatást gyakoroljon az Ethereum-hálózatra. Több mint 14 000 000 ETH letétje van a hálózaton és egy reprezentatív 1000 dollár/ETH árral, az ilyen támadások minimális költsége `1000 × 14 000 000 × 0,33 = 4 620 000 000 dollár`. A támadó ezt a pénzt elveszítené a súlyos büntetés következtében, és kiesne a hálózatból. Az újbóli támadáshoz a letét >33%-át kellene (újra) felhalmozniuk és (újra) elégetniük. Minden egyes támadási kísérlet a hálózat megtámadására >4,6 milliárd dollárba kerülne (1000 dollár/ETH és 14 millió ETH letét mellett). A támadót kidobják a hálózatból a súlyos büntetés következtében, és egy aktiválási sorba kell beállnia, hogy újra csatlakozhasson. Ez azt jelenti, hogy az ismételt támadás mértéke nemcsak arra az arányra korlátozódik, amivel a támadó a teljes letét >33%-át fel tudja halmozni, hanem arra az időre is, amíg az összes validátorát fel tudja venni a hálózatra. Minden egyes támadással a támadó sokkal szegényebbé válik, a közösség többi tagja pedig gazdagabb lesz az ebből eredő drasztikus kínálati változásnak köszönhetően. + +Más támadások, mint például az 51%-os támadás vagy a teljes letét 66%-ával történő véglegesség visszafordítása, lényegesen több ETH-t igényelnek, és sokkal költségesebbek a támadó számára. + +Összehasonlítjuk a proof-of-work mechanizmussal. A proof-of-work Ethereum elleni támadás indításának költsége az volt, hogy a teljes hálózati hashráta >50%-át folyamatosan birtokolni kellett. Ez az elegendő számítási teljesítmény hardver- és üzemeltetési költségét jelentette ahhoz, hogy a proof-of-work megoldások kiszámításában lehagyja a többi bányászt. Az Ethereumon többnyire GPU-t használtak a bányászathoz, nem ASIC-et, ami alacsonyan tartotta a költségeket (ha a proof-of-work rendszer fennmaradt volna, az ASIC-alapú bányászat népszerűbb lehetett volna). Egy támadónak rengeteg hardverre lett volna szüksége, illetve fizethette volna a működtetés költségeit, hogy megtámadhasson egy proof-of-work Ethereum-hálózatot, de ez kevesebb, mint a támadáshoz szükséges ETH felhalmozása. Egy 51%-os támadás a proof-of-work esetében [kb. 20x olcsóbb](https://youtu.be/1m12zgJ42dI?t=1562), mint a proof-of-stake esetében. Ha a támadást észlelték, és a lánc elágazott (hard fork), hogy eltávolítsák a támadó hatását, a támadó ismételten ugyanazt a hardvert használhatná az új elágazás megtámadásához. + +### Bonyolultság {#complexity} + +A proof-of-stake kivitelezése a proof-of-workhöz képest sokkal bonyolultabb. Ez a proof-of-work mellett szólhat, mivel az egyszerűbb protokollokba sokkal nehezebb véletlen hibákat vagy nem kívánt hatásokat bevinni. Habár a komplexitást sikerült megszelídíteni több éves kutatás és fejlesztés, szimulációk és teszthálózati megvalósítások révén. A proof-of-stake protokollt öt független csapat (a végrehajtási és konszenzusrétegen is), öt programozási nyelven valósította meg, ami ellenállást biztosít a klienshibákkal szemben. + +A proof-of-stake konszenzus logikájának biztonságos fejlesztése és tesztelése érdekében a Beacon lánc két évvel azelőtt indult el, hogy a proof-of-stake-et az Ethereum főhálózatra bevezették volna. A Beacon lánc a proof-of-stake tesztelési helyeként működött, mivel élő blokklánc volt proof-of-stake konszenzuslogikával, de nem kezelt valódi Ethereum-tranzakciókat, gyakorlatilag csak önmagában jutott konszenzusra. Amint ez kellő ideig stabil és hibamentes volt, a Beacon láncot „beolvasztották” az Ethereum főhálózatba. Mindez hozzájárult ahhoz, hogy a proof-of-stake összetettsége kezelhetővé váljon, és a nem kívánt következmények vagy a klienshibák kockázata alacsony legyen. + +### Támadási felület {#attack-surface} + +A proof-of-stake összetettebb, mint a proof-of-work, ami azt jelenti, hogy több potenciális támadási vektorral kell megbirkózni. A klienseket összekötő peer-to-peer hálózatból kettő van, külön protokollal. Mivel előre kiválasztanak egy validátort, hogy egy adott slotban blokkot javasoljon, így lehetőség nyílik a szolgáltatásmegtagadásra, amikor az adott validátort annyi feladattal árasztják el, hogy nem tudja végrehajtani a fő funkcióját. + +Vannak olyan módszerek is, amelyekkel a támadók gondosan időzíthetik blokkjaik vagy tanúsításaik közzétételét, hogy azokat a becsületes hálózat egy bizonyos hányada megkapja, és így bizonyos módon szavaznak. Végül egy támadó egyszerűen elegendő ETH letétet képezhet ahhoz, hogy uralja a konszenzusmechanizmust. E [támadási vektorok mindegyikének vannak kapcsolódó védekezési lehetőségei](/developers/docs/consensus-mechanisms/pos/attack-and-defense), ugyanakkor ezek nem léteznek a proof-of-work mechanizmusban. + +## Decentralizáció {#decentralization} + +A proof-of-stake decentralizáltabb, mint a proof-of-work, mivel a bányászhardverek versenyében a magánszemélyek és a kis szervezetek kiszorulnak a versenyből. Bár technikailag bárki elkezdheti a bányászatot szerény hardverrel, annak a valószínűsége, hogy jutalmat kap, elenyészően kicsi az intézményes bányászathoz képest. A proof-of-stake esetében a letét költsége és százalékos megtérülése mindenki számára azonos. Jelenleg 32 ETH-be kerül egy validátor működtetése. + +Másrészt a likvid letéti derivatívák centralizációs aggályokhoz vezettek, mivel néhány nagy szolgáltató nagy mennyiségű letétbe helyezett ETH-t kezel. Ez problémás, és minél előbb korrigálni kell, de árnyaltabb is, mint amilyennek látszik. A központosított letéti alapok nem feltétlenül központosítják a validátorok irányítását – gyakran ez egy módja annak, hogy egy központi ETH-állományt sok független csomópont-üzemeltető adjon össze anélkül, hogy minden résztvevőnek 32 saját ETH-re lenne szüksége. + +Az Ethereum számára a legjobb megoldás az, ha a validátorokat helyben, otthoni számítógépeken futtatják, maximalizálva a decentralizációt. Ezért ellenzi az Ethereum azokat a változtatásokat, amelyek növelik a csomópont és a validátor futtatásának hardverigényét. + +## Fenntarthatóság {#sustainability} + +A proof-of-stake energiafogyasztása miatt ez gazdaságos módja a blokklánc biztosításának. A proof-of-work rendszerben a bányászok versenyeznek a blokkbányászat jogáért. A bányászok sikeresebbek, ha gyorsabban tudják elvégezni a számításokat, ami miatt többet fektetnek hardverbe és nagyobb az energiafogyasztás. Ez jellemezte az Ethereumot, mielőtt átállt volna a proof-of-stake-re. Nem sokkal a proof-of-stake-re való áttérés előtt az Ethereum körülbelül 78 TWh/év mennyiséget fogyasztott, akár egy kisebb ország. A proof-of-stake-re való áttérés azonban kb. 99,98%-kal csökkentette ezt az energiafelhasználást. Ez tehát az Ethereumot egy energiahatékony, alacsony szén-dioxid-kibocsátású platformmá tette. + +[Bővebben az Ethereum energiafogyasztásáról](/energy-consumption) + +## Kibocsátás {#issuance} + +A proof-of-stake Ethereum kevesebb érmekibocsátással tudja fenntartani a biztonságát, mint a proof-of-work rendszerben, mivel a validátoroknak nem kell magas áramköltséget fizetniük. Ennek eredményeképpen az ETH inflációja csökkenhet, vagy akár deflálódhat is, ha nagy mennyiségű ETH-t égetnek el. Az alacsonyabb inflációs szintek azt jelentik, hogy az Ethereum biztonságát olcsóbb fenntartani, mint amikor proof-of-work mechanizmust használt. + +## Ön inkább vizuális típus? {#visual-learner} + +Tekintse meg Justin Drake magyarázatát a proof-of-stake előnyeiről a proof-of-workhöz képest: + + + +## További olvasnivaló {#further-reading} + +- [Vitalik proof-of-stake tervezési filozófiája](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [Vitalik proof-of-stake GYIK](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [„Simply Explained” (egyszerű magyarázat) videó a proof-of-stake és a proof-of-woork mechanizmusokról](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" new file mode 100644 index 00000000000..77c227c7940 --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" @@ -0,0 +1,90 @@ +--- +title: Proof-of-stake jutalmak és büntetések +description: Ismerje meg a protokollon belüli ösztönzőket a proof-of-stake Ethereumban. +lang: hu +--- + +Az Ethereumot a natív kriptovaluta, az ether (ETH) biztosítja. Azok a csomópont-üzemeltetők, akik részt kívánnak venni a blokkok validálásában és a lánc fejének azonosításában, ethert helyeznek el az Ethereumon egy [letéti szerződésben](/staking/deposit-contract/). Ezután etherben fizetnek nekik a validátorszoftver futtatásáért, amely ellenőrzi a peer-to-peer hálózaton keresztül érkező új blokkok érvényességét, és a lánc fejének azonosítására az elágazásválasztó-algoritmust alkalmazza. + +A validátornak két fő szerepe van: 1) az új blokkok ellenőrzése és „tanúsítása”, hogy érvényesek-e, 2) új blokk előterjesztése, amikor véletlenszerűen kiválasztják a validátorállományból. Ha a validátor nem végzi el e feladatok egyikét sem, amikor erre felkérik, akkor lemarad az ether kifizetéséről. A validátorokat felkérhetik az aláírások összesítésére és a szinkronizáló bizottságokban való részvételre is. + +Vannak olyan műveletek, amelyeket nehéz lenne véletlenül elvégezni, ezért valamilyen rosszindulatú szándékot jeleznek, például több blokkot javasolni vagy tanúsítani ugyanarra a slotra. Ezek súlyos büntetést vonnak maguk után, amelyek azt eredményezik, hogy a validátor egyenlegéből bizonyos mennyiségű ethert (legfeljebb 1 ETH-t) elégetnek, mielőtt eltávolításra kerül a hálózatból, ami 36 napot vesz igénybe. A súlyos büntetést kapott validátor ether egyenlege lassan fogy a kilépési időszak alatt, de a 18. napon „korrelációs büntetést” kap, amely nagyobb, ha több validátor egy időben kerül kizárásra. A konszenzusmechanizmus ösztönző struktúrája tehát a helyes viselkedésért jutalmat fizet, a rossz szereplőket pedig bünteti. + +Minden jutalom és büntetés korszakonként egyszer kerül alkalmazásra. + +Tekintse meg a további részleteket... + +## Jutalmak és büntetések {#rewards} + +### Jutalmak {#rewards} + +A validátorok jutalomban részesülnek, ha a többi validátorral összhangban adnak szavazatokat, ha blokkokat javasolnak, és ha részt vesznek a szinkronizáló bizottságokban. A jutalmak értékét minden egyes korszakban egy `base_reward` (alapjutalom) alapján számítják ki. Ez az alapegység, amelyből a többi jutalmat számolják. A `base_reward` az egy validátor által optimális körülmények között kapott átlagos jutalom korszakonként. Ezt a validátor tényleges egyenlegéből és az aktív validátorok teljes számából számítják ki: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +ahol `base_reward_factor` 64, `base_rewards_per_epoch` 4 és `sum(active balance)` az összes aktív validátor letétbe helyezett ether egyenlege. + +Ez azt jelenti, hogy az alapjutalom arányos a validátor tényleges egyenlegével és fordítottan arányos a hálózaton lévő validátorok számával. Minél több validátor van, annál nagyobb a teljes kibocsátás (mint `sqrt(N)`, de annál kisebb az egy validátorra jutó `base_reward` alapjutalom (mint `1/sqrt(N)`). Ezek a tényezők befolyásolják a letétbe helyező csomópontra vonatkozó APR-t (éves ráta). Tekintse meg ennek indoklását [Vitalik jegyzeteiben](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). + +A teljes jutalmat ezután öt összetevő összegeként számítják ki, amelyek mindegyike súlyozással rendelkezik, amely meghatározza, hogy az egyes összetevők mennyivel járulnak hozzá a teljes jutalomhoz. Az összetevők a következők: + +``` +1. source vote: the validator has made a timely vote for the correct source checkpoint +2. target vote: the validator has made a timely vote for the correct target checkpoint +3. head vote: the validator has made a timely vote for the correct head block +4. sync committee reward: the validator has participated in a sync committee +5. proposer reward: the validator has proposed a block in the correct slot +``` + +Az összetevők súlyozása a következő: + +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` + +A súlyok összege 64. A jutalom kiszámítása az alkalmazandó súlyok összege osztva 64-gyel. Az a validátor, aki időben leadta a forrás-, cél- és fejszavazatokat, blokkot javasolt és részt vett a szinkronizáló bizottságban az a következőt kaphatja: `64/64 * base_reward == base_reward`. Egy validátor azonban általában nem szokott blokkot javasolni, így a maximális jutalma: `64-8 /64 * base_reward == 7/8 * base_reward`. Azok a validátorok, akik nem blokkelőterjesztők és nem is tagjai szinkronizáló bizottságnak, a következőképpen kaphatnak: ` 64-8-2 / 64 * base_reward == 6,75/8 * base_reward`. + +A gyors tanúsítások ösztönzésére további jutalom jár. Ez az `inclusion_delay_reward`. Ennek értéke megegyezik a `base_reward` és `1/delay` szorzatával, ahol a `delay` a blokkjavaslat és a tanúsítás között eltelt slotok száma. Például, ha a tanúsítás a blokkjavaslat slotján belül kerül benyújtásra, a tanúsító `base_reward * 1/1 == base_reward` jutalmat kap. Ha a tanúsítás a következő slotban érkezik, akkor a tanusító `base_reward * 1/2` jutalmat kap és így tovább. + +A blokkot javaslók `8 / 64 * base_reward` jutalmat kapnak **minden egyes, a blokkban szereplő érvényes tanúsításért **, így a jutalom tényleges értéke a tanúsító validátorok számával növekszik. A blokkot javaslók növelhetik jutalmukat azáltal is, hogy a javasolt blokkjukba más validátorok helytelen viselkedésére vonatkozó bizonyítékokat is beillesztenek. Ezek azok az ösztönzők, amelyek a validátorokat őszinteségre motiválják. A súlyos büntetést tartalmazó blokkelőterjesztőt `slashed_validators_effective_balance / 512` értékkel jutalmazzák. + +### Büntetések {#penalties} + +Eddig a jól viselkedő validátorokat vettük figyelembe, de mi a helyzet azokkal, akik nem vagy csak lassan teszik meg a fej-, forrás- és célszavazatokat? + +A cél- és forrásszavazatok elmaradásáért járó büntetés megegyezik azzal a jutalommal, amelyet az igazoló kapott volna, ha leadja azokat. Ez azt jelenti, hogy ahelyett, hogy a jutalom hozzáadódna az egyenlegükhöz, ugyanekkora értéket vonnak el abból. A fejszavazás elmulasztásáért nincs büntetés (azt csak jutalmazzák, nem büntetik). Az `inclusion_delay` kapcsán nincs büntetés, a jutalom egyszerűen nem kerül hozzáadásra a validátor egyenlegéhez. Nincs büntetés azért sem, ha valaki nem javasol blokkot. + +Tudjon meg többet a jutalmakról és büntetésekről a [konszenzusspecifikációból](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). A jutalmakat és büntetéseket a Bellatrix frissítéssel módosították – nézze meg Danny Ryan és Vitalik beszélgetését erről ebben a [Peep an EIP videóban](https://www.youtube.com/watch?v=iaAEGs1DMgQ). + +## Slashing {#slashing} + +A súlyos büntetés (slash) egy komoly művelet, amely eltávolítja a validátort a hálózatból, aki a letétbe helyezett ethert is elveszti. Három oka lehet egy validátor súlyos megbüntetésének, amelyek mindegyike a blokkok rosszhiszemű felajánlását vagy tanúsítását jelenti: + +- Két különböző blokk előterjesztése és aláírása ugyanarra a slotra +- Egy olyan blokk tanúsítása, amely „magába foglal” egy másikat (gyakorlatilag megváltoztatva a historikus adatokat) +- „Kettős szavazás”, amikor két jelöltet tanúsít ugyanarra a blokkra + +Ha ezeket a műveleteket észlelik, a validátort súlyosan megbüntetik. Ez azt jelenti, hogy a letétbe helyezett etherük 1/32-ét (maximum 1 etherig) azonnal elégetik, majd egy 36 napos eltávolítási időszak kezdődik. Ezen eltávolítási időszak alatt a validátor letétje fokozatosan elszivárog. Félidőben (18. nap) további büntetést kap, amelynek nagysága a büntetés előtti 36 napban az összes megbüntetett (slashed) validátor összes letétbe helyezett etherének nagyságával arányos. Ez azt jelenti, hogy ha több validátor kap súlyos büntetést és kizárást, akkor a büntetés mértéke növekszik. A maximális büntetés az összes megbüntetett validátor teljes tényleges egyenlege (ha sok validátor kap súlyos büntetést, akkor elveszíthetik a teljes letétjüket). Másrészt egyetlen, elszigetelt súlyos büntetés a validátor letétjének csak kis részét égeti el. Ezt a középtájt kiszabott extra büntetést, amely a megbüntetett validátorok számával skálázódik, korrelációs büntetésnek nevezzük. + +## Inaktivitási elszivárgás {#inactivity-leak} + +Ha a konszenzusréteg több mint négy korszakot tölt el véglegesítés nélkül, akkor egy „inaktivitási szivárgás” vészhelyzeti protokoll aktiválódik. Az inaktivitási elszivárgás célja, hogy megteremtse a lánc véglegessé válásához szükséges feltételeket. A véglegességhez a teljes feltett ether 2/3-os többsége szükséges ahhoz, hogy a forrás- és célellenőrzési pontok megegyezzenek. Ha a validátorok több mint 1/3-a offline állapotba kerül, vagy nem küld helyes tanúsításokat, akkor nem lehetséges, hogy a 2/3-os szupertöbbség véglegesítse az ellenőrzési pontokat. Az inaktivitási elszivárgás lehetővé teszi, hogy az inaktív validátorok letétje fokozatosan elszivárogjon addig, amíg a hozzájuk tartozó letét 1/3 alá csökkent, így a megmaradt aktív validátorok véglegesíthetik a láncot. Bármilyen nagy is legyen az inaktív validátorok csoportja, a megmaradó aktív validátorok végül a letét >2/3-át birtokolják. A letét elvesztése erősen ösztönzi az inaktív érvényesítőket arra, hogy minél hamarabb újra aktiválódjanak! A Medalla teszthálózaton életbe lépett már az inaktivitási elszivárgás, amikor is az aktív validátorok <66%-a képes volt konszenzusra jutni a blokklánc aktuális fejével kapcsolatban. Az inaktivitási elszivárgás aktiválódott, és a véglegesség végül helyreállt! + +A konszenzusmechanizmus jutalom-, büntetés- és súlyos büntetési konstrukciója arra ösztönzi a validáltorokat, hogy jóhiszeműen viselkedjenek. Ezekből a tervezési döntésekből következik, hogy a rendszer érdekében a validátoroknak egyenlően kell megoszlaniuk a kliens között, és fel kell oldani az egyklienses dominanciát. + +## További olvasnivaló {#further-reading} + +- [Ethereum frissítése: Az ösztönzési réteg](https://eth2book.info/altair/part2/incentives) +- [Ösztönzők az Ethereum hibrid Casper-protokolljában](https://arxiv.org/pdf/1903.04205.pdf) +- [Vitalik jegyzetekkel ellátott specifikációja](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Eth2 – a súlyos büntetés elkerülésének módjai](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) + +_Források_ + +- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" new file mode 100644 index 00000000000..0d73cf8f920 --- /dev/null +++ "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" @@ -0,0 +1,39 @@ +--- +title: Gyenge szubjektivitás +description: A gyenge szubjektivitásnak és a proof-of-stake Ethereumban elfoglalt szerepének bemutatása. +lang: hu +--- + +A szubjektivitás a blokkláncban arra utal, hogy a jelenlegi státuszról való megegyezés közösségi információkon alapszik. Több érvényes elágazás is létezhet, amelyek közül a hálózati társaktól gyűjtött információk alapján választanak. Ennek ellentéte az objektivitás, amely olyan láncokra vonatkozik, ahol csak egy lehetséges érvényes lánc van, amelyben minden csomópont egyetért a kódolt szabályok alkalmazásával. A harmadik helyzet a gyenge szubjektivitás. Ez egy olyan lánc, amely objektíven haladhat előre, miután bizonyos kezdeti információt közösségileg megszerzett. + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértéséhez tekintse meg a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) alapjairól szóló oldalt. + +## Milyen problémákat old meg a gyenge szubjektivitás? {#problems-ws-solves} + +A szubjektivitás a proof-of-stake blokkláncok velejárója, mivel a helyes lánc kiválasztása több elágazás közül a korábbi szavazatok számolásával történik. Ez számos támadási vektornak teszi ki a blokkláncot, beleértve a hosszú távú támadásokat, amelyek során a láncban nagyon korán részt vevő csomópontok fenntartanak egy alternatív elágazást, amelyet később saját érdekükből kifolyólag kiadnak. Alternatív megoldásként, ha a validátorok 33%-a visszavonja a letétjét, de továbbra is tanúsít és blokkokat állít elő, akkor létrehozhatnak egy alternatív elágazást, amely ütközik a kanonikus lánccal. Az új vagy a hosszú ideje offline csomópontok nem biztos, hogy tudják, hogy ezek a támadó validátorok visszavonták a letétüket, így rávehetik őket, hogy egy helytelen láncot kövessenek. Az Ethereum olyan korlátozásokkal tudja megoldani a támadási vektorokat, amelyek a mechanizmus szubjektív aspektusait, beleértve a bizalmi feltételezéseket is, a minimálisra csökkenti. + +## A gyenge szubjektivitás ellenőrzőpontjai {#ws-checkpoints} + +A gyenge szubjektivitás a proof-of-stake Ethereumban az erre vonatkozó ellenőrzőpontokkal valósul meg. Ezek olyan státuszgyökerek, amelyek a hálózat összes csomópontja szerint a kanonikus láncba tartoznak. Ezek is az „egyetemes igazság” célját szolgálják, mint a genezis blokkok, azzal a különbséggel, hogy nem a genezis pozícióban helyezkednek el a blokkláncban. Az elágazásválasztó-algoritmus bízik abban, hogy az adott ellenőrzőpontban meghatározott blokkláncstátusz helyes, és hogy ettől a ponttól kezdve függetlenül és objektíven ellenőrzi a láncot. Az ellenőrzési pontok adják az adott blokk visszafordíthatóságának korlátját, mivel a gyenge szubjektivitás ellenőrzési pontjai előtti blokkok nem módosíthatók. Ez aláássa a nagy hatótávolságú támadásokat azzal, hogy a mechanizmus érvénytelennek minősíti a nagy hatótávolságú elágazásokat. Azzal, hogy a gyenge szubjektivitás ellenőrzési pontjai közelebb vannak, mint a validátor letétkivételi ideje, az elágazást készítő validátort meg tudja bünteti valamekkora összegig, mielőtt kivehetné a letétet, és így az új belépőket nem tudja eltéríteni a téves elágazásokra. + +## A gyenge szubjektivitás ellenőrzési pontjai és a véglegesített blokkok közötti különbség {#difference-between-ws-and-finalized-blocks} + +Az Ethereum-csomópontok másképp kezelik a véglegesített blokkokat és a gyenge szubjektivitás ellenőrzési pontjait. Ha egy csomópont két egymással versengő véglegesített blokkról szerez tudomást, akkor a kettő között vacilál – nem tudja automatikusan azonosítani, hogy melyik a kanonikus elágazás. Ez a konszenzuskudarc tünete. Ezzel szemben egy csomópont egyszerűen elutasít minden olyan blokkot, amely ütközik a gyenge szubjektivitás ellenőrzési pontjával. A csomópont szempontjából a gyenge szubjektivitás ellenőrzési pontja olyan abszolút igazságot képvisel, amelyet nem lehet aláásni a társaktól jövő információkkal. + +## Mennyire gyenge a gyenge? {#how-weak-is-weak} + +Az Ethereum proof-of-stake szubjektív aspektusa az, hogy a szinkronizáláshoz egy megbízható forrásból származó friss státuszra van szükség (ez a gyenge szubjektivitás ellenőrzési pontja). Annak kockázata, hogy a gyenge szubjektivitás ellenőrzési pontja rossz, nagyon alacsony, mivel több független nyilvános forrással is ellenőrizhetők, mint amilyenek a blokkfelfedezők vagy más csomópontok. Egy szoftver futtatásához azonban szükség van bizonyos fokú bizalomra, például bíznunk kell abban, hogy a fejlesztők tisztességes szoftvert készítettek. + +A gyenge szubjektivitás ellenőrzési pontja a kliensszoftver részeként is megjelenhet. Vitatható, hogy egy támadó megrongálhatja a szoftverben lévő ellenőrzőpontot, és ugyanilyen könnyen magát a szoftvert is. Nincs kriptogazdasági megoldás ennek a problémának a megkerülésére, de a megbízhatatlan fejlesztők hatása az Ethereumban minimálisra csökkenthető azáltal, hogy több független klienscsapat van, amelyek különböző nyelveken készítenek egyenértékű szoftvert, és érdekeltek a tisztességes lánc fenntartásában. A blokkfelfedezők gyenge szubjektivitást ellenőrző pontokat is biztosíthatnak, vagy a kapott ellenőrzési pontokat további forrással is össze lehet vetni. + +Végül, ellenőrzőpontokat lehet kérni más csomópontoktól; például egy másik Ethereum-felhasználó, aki teljes csomópontot futtat, adhat egy ellenőrzőpontot, amelyet a validátorok ellenőrizhetnek a blokkfelfedezőből származó adatokkal. Összességében a gyenge szubjektivitás ellenőrzési pontjának szolgáltatójában való bizalom csak annyira problémás, mint megbízni a kliensfejlesztőkben. A szükséges bizalom alacsony szintű. Fontos megjegyezni, hogy ezek a megfontolások abban a valószínűtlen esetben válnak fontossá, ha a validátorok többsége összeesküvést sző, hogy létrehozza a blokkláncnak egy alternatív elágazását. Bármilyen más körülmények között nem létezik több Ethereum-lánc, amelyek közül választani kellene. + +## További olvasnivaló {#further-reading} + +- [Gyenge szubjektivitás az Eth2-ben](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [Vitalik: Hogyan tanultam meg szeretni a gyenge szubjektivitást](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [Gyenge szubjektivitás (Teku dokumentációk)](https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/) +- [0. fázisú gyenge szubjektivitási útmutató](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [A gyenge szubjektivitás elemzése az Ethereum 2.0-n](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" new file mode 100644 index 00000000000..f3bf74f01d0 --- /dev/null +++ "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" @@ -0,0 +1,79 @@ +--- +title: Jogosultsági igazolás (proof-of-authority/PoA) +description: A jogosultsági igazolás konszenzusprotokoll bemutatása és az Ethereumban betöltött szerepe. +lang: hu +--- + +**A jogosultsági igazolás (POA)** egy reputációalapú konszenzusalgoritmus, amely a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) módosított verziója. Főleg privát láncok, teszthálózatok és helyi fejlesztői hálózatok használják. PoA egy olyan reputációalapú konszenzusalgoritmus, amelynél felhatalmazott aláírók egy csoportját bízzák meg a blokkok létrehozásával, nem a PoS-nél ismert letéti alapú mechanizmus szerint végzik. + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértéséhez érdemes áttekinteni a [tranzakciók](/developers/docs/transactions/), [blokkok](/developers/docs/blocks/) és a [konszenzusmechanizmus](/developers/docs/consensus-mechanisms/) oldalakat. + +## Mi az a jogosultsági igazolás (PoA)? {#what-is-poa} + +A jogosultsági igazolás a **[proof-of-stake](/developers/docs/consensus-mechanisms/pos/) (PoS)** módosított változata, ami egy reputációalapú konszenzusalgoritmus, nem pedig letéti alapú mechanizmus, mint a PoS esetében. A kifejezést Gavin Wood használta először 2017-ben, és ez a konszenzusalgoritmus főleg privát láncok, teszthálózatok és helyi fejlesztési hálózatok esetén működik, mely megoldja a PoW esetében szükséges jó minőségű források igényét, illetve a PoS esetében fellépő skálázási gondokat, mivel a csomópontok kis csoportja tárolja a blokkláncot és gyártja a blokkokat. + +A jogosultsági igazolásnál felhatalmazott aláírók csoportját bízzák meg, mely benne van a [genezis blokkban](/glossary/#genesis-block). A jelenlegi felhasználásoknál minden felhatalmazott aláíró ugyanolyan hatalommal és jogosultsággal bír, amikor a lánc konszenzusát meghatározza. A reputációalapú letét mögött az az elképzelés húzódik, hogy a felhatalmazott validátorok jól ismertek mindenki előtt, vegyük az ismerd meg a vevődet (KYC) módszert vagy ha az egyetlen validátor egy jól ismert szervezet - így ha a validátor rosszat tesz, az identitása egyértelműen kiderül. + +A PoA-nak számos implementációja létezik, de a sztenderd Ethereum módja a **clique**, mely az [EIP-225](https://eips.ethereum.org/EIPS/eip-225) fejlesztést vezette be. A clique egy fejlesztőbarát és könnyen bevezethető szabvány, amely mindenféle kliensszinkronizálást támogat. Más implementációk felölelik az [IBFT 2.0](https://besu.hyperledger.org/stable/private-networks/concepts/poa) és az [Aura](https://openethereum.github.io/Chain-specification) módozatokat. + +## Hogyan működik {#how-it-works} + +A PoA esetében a felhatalmazott aláírók csoportja készíti az új blokkokat. Az aláírókat a reputációjuk alapján választják, és csak ők hozhatnak létre blokkot. Az aláírókat körmérkőzéses módon választják, és mindegyik egy adott időszakban hozhat létre blokkot. A blokk létrehozásának ideje rögzített, és ekkor kell az aláíróknak előállítani azt. + +A reputáció ebben a kontextusban nem egy mérhető dolog, hanem a Microsoft és a Google esetében jól ismert módszer, így a kiválasztás se algoritmikus, hanem _bizalomalapú_, ahol az entitás, például a Microsoft, létrehoz egy PoA privát hálózatot startup-ok százai vagy ezrei részvételével, ő maga a megbízott aláíró, aki új aláírókat adhat a rendszerhez, mint például a Google-t, így a startup-ok kétely nélkül bíznak abban, hogy a Microsoft jóhiszeműen jár el és így használja a hálózatot. Ez megoldja a különböző kis/privát hálózatokban való letétek szükségességét, amelyeket különböző célokra építettek, hogy decentralizáltak és működőképesek maradjanak, valamint a bányászok szükségességét, ami sok energiát és erőforrást igényel. Néhány privát hálózat a PoA szabványt használja, mint a VeChain, és néhány módosította azt, mint a Binance, mely [PoSA](https://academy.binance.com/en/glossary/proof-of-staked-authority-posa) verziót használ, ami egy személyre szabott PoA és PoS verzió. + +A szavazási folyamatot az aláírók végzik. Minden aláíró szavaz egy adott aláíró bevétele vagy eltávolítása mellett a saját blokkjában, amikor azt létrehozza. A szavazatokat összegzik a csomópontok, így az aláírók bekerülnek vagy kikerülnek, ha a szavazatok elérik a SIGNER_LIMIT határt. + +Bizonyos esetekben apróbb elágazások történhetnek, a blokk nehézsége azon múlik, hogy soron belül vagy kívül írták alá. A soron belüli blokkok 2-es nehézséggel bírnak, a soron kívüliek 1-essel. A kisebb elágazások esetén az a lánc lesz az összetettebb és ezáltal a nyertes, amely a legtöbb soron belüli aláírót tudja felmutatni. + +## Támadási vektorok {#attack-vectors} + +### Rosszhiszemű aláírók {#malicious-signers} + +Lehetséges, hogy egy rosszhiszemű aláíró kerül be az aláírók listájába, vagy kompromittálódik egy aláírási kulcs/gép. Ilyen helyzetben a protokollnak meg kell védenie magát az átszervezések és a teleszemetelés (spamming) ellen. A javasolt megoldás az, hogy ha van egy N elemű aláírólista, mindegyik aláíró egy blokkot hoz létre minden K-ból. Így a kár korlátozott, a validátorok többi része pedig ki tudja szavazni a rosszhiszemű felhasználót. + +### Cenzúrázás {#censorship-attack} + +Egy másik érdekes támadási vektor, ha egy aláíró (vagy az aláírók egy csoportja) megpróbálja cenzúrázni a blokkokat azáltal, hogy kiszavazza azokat a jóváhagyott listából. Ennek elkerüléséhez az aláírók blokk-készítését 1-re kell korlátozni N/2-ből. Ekkor a rosszhiszemű aláíróknak legalább 51%-nyi aláírószámlát kell kontrollálniuk, és ekkor ők mondják meg mi a lánc új státusza. + +### Szemetelés (spam) {#spam-attack} + +Egy másik kisebb támadási vektor az, amikor a rosszhiszemű aláírók új szavazási javaslatot adnak az általuk készített blokkban. Mivel a csomópontoknak egyesíteni kell a szavazatokat, hogy létrehozzák az felhatalmazott aláírók listáját, így az összes szavazatot rögzíteniük kell. Ha a szavazási ablaknak nincs határa, akkor ez lassan, de a végtelenségig növekedhet. Ennek megoldása az, hogy W blokk kap egy _mozgó_ ablakot, ami után a szavazatok már elévülnek. _Az ablak 1–2 korszak hosszúságú lehetne._ + +### Párhuzamos blokkok {#concurrent-blocks} + +Egy PoA-alapú hálózatban, ha N felhatalmazott aláíró van, minden aláíró K-ból 1 blokkot hozhat létre, ami azt jelenti, hogy N-K+1 validátornak van lehetősége bármely adott időpontban blokkot készíteni. Ahhoz, hogy a validátorok ne versenyezzenek a blokkokért, minden aláírónak egy kis véletlenszerű „elmozdulást” kell adni az időhöz, amikor az új blokkot készíti. Bár ezzel a kisebb elágazások ritkák, de mégis megtörténhetnek, ahogy a főhálózatnál is. Ha egy aláíró visszaél a hatalmával és káoszt csinál, akkor a többi aláíró kiszavazhatja. + +Ha például 10 felhatalmazott aláíró van, és mindegyik készíthet 1 blokkot a 20-ból, akkor bármelyik időben 11 validátor blokkot készíthet. Ahhoz, hogy a validátorok ne versenyezzenek a blokkokért, minden aláírónak egy kis véletlenszerű „elmozdulást” kell adni az időhöz, amikor az új blokkot készíti. Bár ezzel a kisebb elágazások ritkák, de mégis megtörténhetnek, ahogy a főhálózatnál is. Ha egy aláíró visszaél a hatalmával és káoszt csinál, akkor a többi aláíró kiszavazhatja. + +## Előnyök és hátrányok {#pros-and-cons} + +| Előnyök | Hátrányok | +| --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Sokkal jobban skálázható, mint más népszerű mechanizmusok, mint a PoS és a PoW, és behatárolt blokkaláírón alapszik | A PoA-hálózatok általában kevés validáló csomóponttal működnek. Emiatt a PoA-hálózat sokkal centralizáltabb. | +| A PoA-blokkláncokat rendkívül olcsó futtatni és fenntartani | Az átlagos felhasználó nem válik felhatalmazott aláíróvá, mert a blokklánchoz olyan entitások kellenek, amelyek reputációja jól megalapozott. | +| A tranzakciókat gyorsan konfirmálják, akár 1 másodpercen belül, mert csak korlátozott számú aláíró kell az új blokk validálásához | A rosszhiszemű aláírók képesek átrendezésre, dupla költésre, tranzakciócenzúrára a hálózaton belül, amelyeket lehet mitigálni, de ettől még lehetségesek | + +## További olvasnivaló {#further-reading} + +- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique szabvány_ +- [A jogosultsági igazolásról készült tanulmány](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_ +- [Mi az a jogosultsági igazolás](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_ +- [A jogosultsági igazolás magyarázata](https://academy.binance.com/en/articles/proof-of-authority-explained) _binance_ +- [PoA a blokkláncban](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba) +- [A clique magyarázata](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d) +- [Elavult PoA, Aura-specifikáció](https://openethereum.github.io/Chain-specification) +- [IBFT 2.0, egy másik PoA-implementáció](https://besu.hyperledger.org/stable/private-networks/concepts/poa) + +### Ön inkább vizuális típus? {#visual-learner} + +Tekintse meg a jogosultsági igazolás vizuális magyarázatát: + + + +## Kapcsolódó témák {#related-topics} + +- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/) +- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/) diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" new file mode 100644 index 00000000000..c3db9756ccc --- /dev/null +++ "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" @@ -0,0 +1,109 @@ +--- +title: Proof-of-work (PoW) +description: A proof-of-work (munkaigazolás) konszenzusprotokoll bemutatása és az Ethereumban betöltött szerepe. +lang: hu +--- + +Az Ethereum-hálózat kezdetben egy olyan konszenzusmechanizmust használt, amely a **[proof-of-work (PoW)](/developers/docs/consensus-mechanisms/pow)** koncepciót használta. Ez lehetővé tette az Ethereum-hálózat csomópontjai számára, hogy az összes Ethereum-blokkláncra feljegyzett információ állapotáról megegyezzenek és kivédjenek bizonyos gazdasági támadásokat. Ugyanakkor az Ethereum 2022-ben leváltotta a proof-of-work mechanizmust, és helyette a [proof-of-stake (letéti igazolás)](/developers/docs/consensus-mechanisms/pos) koncepcióját vezette be. + + + A proof-of-work ezzel kivezetésre került. A konszenzusmechanizmusnak többé nem része a proof-of-work az Ethereumon. Ehelyett a proof-of-stake mechanizmus működik. Tudjon meg többet a proof-of-stake-ről és a letétbe helyezésről. + + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértéséhez érdemes áttekinteni a [tranzakciók](/developers/docs/transactions/), [blokkok](/developers/docs/blocks/) és a [konszenzusmechanizmus](/developers/docs/consensus-mechanisms/) oldalakat. + +## Mi az a proof-of-work (PoW)? {#what-is-pow} + +A Nakamoto konszenzus, amely a proof-of-work (PoW) mechanizmust használja, egykor lehetővé tette a decentralizált Ethereum-hálózat számára, hogy konszenzusra jusson (tehát minden csomópont egyetértsen) olyanok felett, mint a számlaegyenlegek vagy a tranzakciók sorrendje. Ez megakadályozta, hogy a felhasználók „duplán elköltsék” a coinokat és biztosította azt, hogy az Ethereum-láncot hihetetlenül nehéz volt megtámadni vagy átírni. Ezek a biztonsági jellemzők most a proof-of-stake mechanizmusból erednek, amely a [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) nevű konszenzust használja. + +## Proof-of-work és bányászat {#pow-and-mining} + +A proof-of-work a mögöttes algoritmus, amely a nehézséget és a szabályokat határozza meg a munkához, amelyet a bányászok végeznek proof-of-work blokkláncokon. A bányászat maga a „munka”. Érvényes blokkok hozzáadását jelenti a lánchoz. Ez azért fontos, mert a lánc hossza segíti a hálózatot abban, hogy kövesse a blokklánc megfelelő elágazását. Minél több „munka” van elvégezve, annál hosszabb a lánc, és minél magasabb a blokkszám, annál inkább biztosabb lehet a hálózat a dolgok jelenlegi állapotában. + +[Többet a bányászatról](/developers/docs/consensus-mechanisms/pow/mining/) + +## Hogyan működött az Ethereum proof-of-work mechanizmusa? {#how-it-works} + +Az Ethereum-tranzakciókat blokkokba dolgozzák fel. A már kivezetett proof-of-work-alapú Ethereumon minden blokkban volt: + +- blokk nehézsége – például: 3,324,092,183,262,715 +- mixHash-e – például: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- nonce-a – például: `0xd3ee432b4fb3d26b` + +Ezek a blokkadatok közvetlen kapcsolatban álltak a proof-of-work mechanizmussal. + +### A munka a proof-of-work-ben {#the-work} + +A proof-of-work protokoll, melyet Ethashnek hívnak, arra ösztönözte a bányászokat, hogy egy intenzív verseny keretében próba szerencse alapon megtalálják a nonce-t egy blokkhoz. Csak érvényes nonce-szal rendelkező blokkokat lehetett hozzáadni a lánchoz. + +Amikor a blokk létrehozásáért versenyeztek, egy adott bányász ismételten betett egy adathalmazt, melyet csak a teljes lánc letöltésével és futtatásával (ahogy a bányászok csinálják) lehetett megszerezni, egy matematikai függvényen keresztül. Az adathalmazt arra használták, hogy készítsenek egy mixHasht, ami a blokk nehézsége által megadott tartományon belül marad. Ezt a legjobban a próba és hiba módszerrel kiszámítani. + +A nehézség határozta meg a hash célját. Minél alacsonyabb a cél, annál kisebb az érvényes hashek halmaza. Amint legenerálta valaki, onnantól már rendkívül egyszerű a többi bányász és kliens számára hitelesíteni. Ha akár egy tranzakciót is megváltoztattak volna, akkor a hash teljesen más lett volna, ami egyértelműen jelzi a csalást. + +A hashing egyszerűvé teszi, hogy észrevegyük a csalásokat. Emellett a proof-of-work folyamata elrettentő erővel bírt a lánc megtámadásával szemben. + +### Proof-of-work és biztonság {#security} + +A bányászokat ösztönözték, hogy elvégezzék ezt a munkát az Ethereum láncon. A bányászok számára nem volt mérvadó az a motiváció, hogy saját láncot indítsanak, és ezzel aláássák a rendszert. A blokkláncok egy állapotra hagyatkoznak az igazság forrásaként. + +A proof-of-work célkitűzése a lánc kiterjesztése volt. A leghosszabb lánc a leghihetőbb érvényes lánc volt, mivel itt végezték el a legtöbb számítási munkát ahhoz, hogy létrehozzák. Az Ethereum proof-of-work rendszerén belül szinte lehetetlen volt olyan új blokkokat létrehozni, melyek korábbi tranzakciókat törölnének ki vagy hamis tranzakciókat tartalmaznának, vagy egy másik láncok építenének. Ennek az az oka, hogy egy rosszindulatú bányásznak mindig gyorsabban kéne megoldania a blokk nonce-ot, mint bárki másnak. + +Ahhoz, hogy valaki konzisztensen rosszindulatú, de mégis érvényes blokkokat hozhasson létre, a hálózat bányászati erejének több mint az 51%-ával rendelkeznie kellett volna. Ez a mennyiségű „munka” rengeteg, drága számítási kapacitást igényel, és az erre költött ráfordítás talán meg is haladja a támadással járó előnyöket. + +### A proof-of-work gazdaságtana {#economics} + +A proof-of-work másik feladata az volt, hogy új coinokat bocsásson ki a rendszerbe és ezzel ösztönözze a bányászokat a munka elvégzésére. + +A [Constantinople-frissítés](/history/#constantinople) után a bányászok, akik sikeresen létrehoztak egy blokkot, két frissen kibocsátott ETH-t kaptak, valamint a tranzakciós díjak egy része is az övék lett. Az ommer blokkokért is járt 1,75 ETH. Az ommerek olyan érvényes blokkok, melyeket ugyanabban az időben készítenek, mint a kanonikus blokkot, ami végül a lánc folytatása lesz. Ezek általában hálózati késedelemkor fordultak elő. + +## Véglegesség {#finality} + +A tranzakció végleges az Ethereumon, amikor egy olyan blokk része, amit már nem lehet megváltoztatni. + +Mivel a bányászok decentralizáltan dolgoztak, lehetséges volt, hogy egyszerre két érvényes blokk jöjjön létre. Ez egy átmeneti elágazást (fork) eredményez. Végül az egyik lánc lett az elfogadott, amint egy későbbi blokkot kibányásztak és hozzáfűztek, ami miatt hosszabbá vált. + +Tovább bonyolította, hogy a tranzakciók, melyek el lettek utasítva az átmeneti elágazásban, nem feltétlenül kerültek be az elfogadott láncba. Ez azt jelentette, hogy vissza lehetett azokat fordítani. A véglegesség tehát arra az időre utal, amennyit a felhasználónak várnia kell, hogy a tranzakciót visszafordíthatatlannak tekintsük. A korábbi proof-of-work-alapú Ethereumon minél több blokkot bányásztak egy adott `N` blokk tetejére, annál inkább meg lehetett bízni abban, hogy az `N` blokk tranzakciói sikeresek és nem lehet azokat visszafordítani. A jelenlegi proof-of-stake rendszerben a véglegesség a blokk kifejezett jellemzője, nem annyira valószínűségi. + +## A proof-of-work energiafelhasználása {#energy} + +A proof-of-work egyik legnagyobb hibája az energiamennyiség volt, melyet a hálózat biztonságosságáért el kellett fogyasztani. Az Ethereum proof-of-work rendszere sok energiát igényelt ahhoz, hogy biztonságos és decentralizált legyen. Röviddel a proof-of-stake-re való áttérés előtt az Ethereum-bányászok együttesen kb. 70 TWh/év energiát fogyasztottak (akár a Cseh Köztársaság a [digiconomist](https://digiconomist.net/) szerint, melyet 2022. július 18-án publikáltak). + +## Előnyök és hátrányok {#pros-and-cons} + +| Előnyök | Hátrányok | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| A proof-of-work egy semleges rendszer. Nincs szükség ETH-re, hogy valaki elkezdje, és a blokk jutalmaknak köszönhetően 0 ETH-ről pozitívba mehet át az egyenlege. A [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) esetében ETH-re van szükség, hogy valaki belekezdjen. | A proof-of-work sok energiát használ fel, ami káros a környezetnek. | +| A proof-of-work egy kipróbált és letesztelt konszenzusos mechanizmus, amely éveken keresztül biztonságban és decentralizáltan tartotta a Bitcoint és az Ethereumot. | Ha valaki bányászni szeretne, akkor speciális felszerelésre van szüksége, mely kezdetnek nagy befektetés. | +| A proof-of-stake-kel szemben viszonylag egyszerűbb implementálni. | A folyamatosan növekvő számítási igény miatt, a bányászati alapok potenciálisan dominálhatják a bányászvilágot, mely centralizációhoz és biztonsági kockázatokhoz vezet. | + +## Összehasonlítás a proof-of-stake megoldással {#compared-to-pos} + +Nagy vonalakban a proof-of-stake-nek ugyanaz a végcélja, mint a proof-of-work-nek: biztonságosan segítse elérni a konszenzust a decentralizált hálózaton. De van egy pár különbség a folyamatban és a személyekben: + +- A proof-of-stake leváltja a számítási kapacitás fontosságát a letétbe helyezett ETH-re. +- A proof-of-stake lecseréli a bányászokat validátorokra. A validátorok letétbe helyezik az ETH-jüket, hogy aktiválják a képességüket új blokkok létrehozására. +- A validátorok nem versenyeznek a blokk létrehozásért, ehelyett egy algoritmus választja ki őket véletlenszerűen. +- A véglegesség tisztább: ha bizonyos ellenőrzési pontokon a validátorok 2/3 része egyetért a blokk állapotát illetően, akkor a blokkot véglegesnek tekintjük. A validátorok a tejles letétüket felteszik erre, így ha megpróbálnak összejátszani, akkor a teljes letétüket elveszítik. + +[A proof-of-stake-ről bővebben](/developers/docs/consensus-mechanisms/pos/) + +## Ön inkább vizuális típus? {#visual-learner} + + + +## További olvasnivaló {#further-reading} + +- [Többségi támadás](https://en.bitcoin.it/wiki/Majority_attack) +- [Az elszámolási véglegességről](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) + +### Videók {#videos} + +- [A proof-of-work protokollok technikai magyarázata](https://youtu.be/9V1bipPkCTU) + +## Kapcsolódó témák {#related-topics} + +- [Bányászat](/developers/docs/consensus-mechanisms/pow/mining/) +- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/) +- [Proof-of-authority (jogosultsági igazolás)](/developers/docs/consensus-mechanisms/poa/) diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" new file mode 100644 index 00000000000..dfbe113cc15 --- /dev/null +++ "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" @@ -0,0 +1,81 @@ +--- +title: Bányászat +description: Áttekintés – hogyan működött a bányászat az Ethereumon. +lang: hu +--- + + +A proof-of-work (munkaigazolás) már nem az Ethereum konszenzusmechanizmus alapja, tehát a bányászatot kikapcsolták. Ehelyett az Ethereumot úgy biztosítják a validátorok, hogy letétbe helyeznek ETH-t. Ön is letétbe helyezheti a rendelkezésére álló ETH-t. Tudjon meg többet a egyesítés (Merge), proof-of-stake (letéti igazolás) és letétbe helyezés témákról. Ez az oldal csak elavult témákat tartalmaz. + + +## Előfeltételek {#prerequisites} + +Javasoljuk, hogy olvassa el a [tranzakciók](/developers/docs/transactions/), [blokkok](/developers/docs/blocks/) és a [proof-of-work](/developers/docs/consensus-mechanisms/pow/) oldalakat is. + +## Mi az az Ethereum bányászat? {#what-is-ethereum-mining} + +A bányászat az a tevékenység, amikor tranzakciókból álló blokkokat hoznak létre, hogy azokat hozzáadják az Ethereum-blokklánchoz abban a proof-of-work architektúrában, melyet már kivezettek az Ethereumból. + +A bányászat kifejezés a kriptovaluták aranyhoz hasonló kinyerésére vonatkozott. Az arany vagy más nemesfémek ritkák, ahogy a digitális tokenek is, ezért a mennyiséget egy proof-of-work-alapú rendszerben a bányászattal lehetett növelni. A proof-of-work-alapú Ethereumban a kibocsátás egyetlen módja a bányászat volt. Az arany és más bányászatához képest ugyanakkor az Ethereumban ez volt a hálózat biztosításának módja a blokkláncba létrehozott, ellenőrzött, publikált és elterjesztett blokkok révén. + +Ether bányászata = A hálózat biztosítása + +A bányászat a proof-of-work blokkláncok lényege. Az Ethereum-bányászok – szoftvert futtató számítógépek – az idejüket és számítási kapacitásukat fordították a tranzakciók feldolgozására és blokkok létrehozására a proof-of-stake mechanizmus bevezetése előtt. + +## Miért léteznek a bányászok? {#why-do-miners-exist} + +Az Ethereumhoz hasonló decentralizált rendszerek esetében biztosítanunk kell, hogy mindenki egyetért a tranzakciók sorrendjében. A bányászok segítettek, hogy ez megtörténjen úgy, hogy számítás szempontjából nehéz rejtvényeket oldottak meg azért, hogy blokkokat hozhassanak létre, amely így megvédte a hálózatot a támadásoktól. + +[Bővebben a proof-of-work mechanizmusról](/developers/docs/consensus-mechanisms/pow/) + +Korábban bárki bányászhatott az Ethereum hálózaton a számítógépét használva. Ugyanakkor nem mindenkit tudott nyereségesen bányászni ethert (ETH). A legtöbb esetben a bányászoknak dedikált számítógépes hardvereket kellett szerezniük, és hozzá kellett férniük az energiaforrásokhoz. Egy átlagos számítógép nem valószínű, hogy elég blokkjutalmat tudott szerezni, hogy fedezze a bányászat költségeit. + +### A bányászat költsége {#cost-of-mining} + +- Annak a hardvernek a valószínű költsége, mely a bányászati eszköz felépítéséhez és fenntartásához szükséges +- A bányászati eszközt működtető elektromosság költsége +- Ha egy bányászati alapban vett részt valaki, akkor az alap általában egy %-os általánydíjat számolt fel minden létrehozott blokk után +- A bányászati eszköz támogatásához szükséges dolgok költségei (szellőztető, energiamonitorozás, elektromos vezetékek stb.) + +A bányászat nyereségességét olyan bányászati kalkulátor segítségével ellenőrizheti, mint amilyen az [Etherscan](https://etherscan.io/ether-mining-calculator) oldalon is található. + +## Hogyan bányászták ki az Ethereum-tranzakciókat {#how-ethereum-transactions-were-mined} + +A következőkben a tranzakciók bányászatáról olvashat egy áttekintés az Ethereum proof-of-work mechanizmusa idejéből. Az Ethereum proof-of-stake mechanizmusára vonatkozó leírást [itt](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) találja. + +1. A felhasználó létrehoz és aláír egy [tranzakciós](/developers/docs/transactions/) kérvényt valamely [számla](/developers/docs/accounts/) privát kulcsával. +2. A felhasználó közvetíti a tranzakciós kérelmet a teljes hálózat számára valamilyen [csomópontról](/developers/docs/nodes-and-clients/). +3. Amint tudomást szereznek a tranzakció kérvényről, az Ethereum hálózat valamennyi csomópontja hozzáadja a kérvényt a lokális mempooljához, ami azokat a tranzakciós kérvényeket tartalmazza, amikről már tudomást szereztek, de még nem adták hozzá a blokklánchoz egy blokkban. +4. Egy bizonyos ponton egy bányászcsomópont több tucat vagy több száz tranzakciós kérvényt összesít egy potenciális [blokkba](/developers/docs/blocks/) úgy, hogy a begyűjtött [tranzakciós díj](/developers/docs/gas/) maximális legyen, de ne lépje túl a blokk gázkorlátozását. Ezután a bányász csomópont: + 1. Ellenőrzi az egyes tranzakciós kérelmek érvényességét (azaz senki nem próbál ethert átutalni olyan számláról, amelyhez nem készített aláírást, a kérés nem hibás, stb.), majd végrehajtja a kérés kódját, megváltoztatva az EVM helyi másolatának állapotát. A bányász a tranzakciós díjat minden ilyen tranzakciós kérvényért a saját számlájára teszi. + 2. Elindítja a proof-of-work “megbízhatósági bizonyítvány” előállításának folyamatát a potenciális blokkra, amint az összes tranzakciós kérelmet érvényesítette és végrehajtotta a helyi EVM másolaton. +5. Végül egy bányász befejezi a bizonyítvány elkészítését egy blokkra, mely tartalmazza a mi specifikus tranzakciós kérelmünket. A bányász ezután közvetíti a kész blokkot, mely tartalmazza a bizonyítványt és az ellenőrző összeget az új, kiállított EVM állapotról. +6. A többi csomópont is tudomást szerez a blokkról. Érvényesítik a bizonyítványt, saját maguk is végrehajtják a blokk összes tranzakcióját (beleértve azt is, amit eredetileg a felhasználónk közvetített), és megbizonyosodnak arról, hogy az új tranzakciók végrehajtása utáni EVM állapotuk ellenőrző összege megegyezik a bányász által kiállított blokk állapotának összegével. Csak ezután fűzik hozzá ezek a csomópontok ezt a blokkot a blokkláncuk végére, és fogadják el az új EVM állapotot, mint kanonikus új állapot. +7. Minden csomópont eltávolítja az új blokkban lévő összes tranzakciót a teljesítetlen tranzakciós kérvényeket tartalmazó helyi mempooljából. +8. A hálózatba újonnan becsatlakozó csomópontok letöltik az összes blokkot a sorrendet betartva, beleértve azt a blokkot is, mely a szóban forgó tranzakciónkat tartalmazza. Inicializálnak egy helyi EVM másolatot (mely egy üres állapotú EVM-ként indul), ezután végig mennek az összes blokkban található összes tranzakció végrehajtásának folyamatán a helyi EVM másolatukon, miközben érvényesítik a blokkok állapotainak ellenőrző összegeit. + +Minden tranzakciót egyszer bányásznak ki (blokkba foglalják és első alkalommal közvetítik), de minden résztvevő végrehajtja és érvényesíti azokat a kanonikus EVM-állapot előrevitelének folyamatában. Ez kiemeli a blokklánc egyik központi mantráját: **Nem kell megbíznia senkiben. Csak ellenőrizni.**. + +## Ommer (nagybácsi) blokkok {#ommer-blocks} + +A proof-of-work mechanizmusban végzett blokkbányászat valószínűségen alapult, tehát néha a hálózati késedelem miatt két érvényes blokkot is publikáltak egyszerre. Ebben az esetben a protokoll kiválasztotta a leghosszabb láncot (amelyik érvényesebb volt), miközben díjazta azt a bányászt is egy részleges jutalommal, akinek nem került be a javasolt blokkja. Ez bátorította a hálózat decentralizációját, mert a kisebb bányászok, akiknél nagyobb volt a csúszás, még mindig tudtak nyereséget szerezni az [ommer](/glossary/#ommer) blokkok jutalmából. + +Az „ommer” kifejezés a szülőblokk testvérblokkjának semleges formája, de néha nagybácsi/uncle formában is hivatkoznak rá. **Mióta az Ethereum átállt a proof-of-stake mechanizmusra, többé nincsenek ommer blokkok**, mivel csak egy előterjesztő van minden slotban. Ezt a változást megtekintheti a kibányászott ommer blokkok [előzményábráján](https://ycharts.com/indicators/ethereum_uncle_rate) is. + +## Egy vizuális bemutató {#a-visual-demo} + +Tekintse meg, ahogy Austin elmagyarázza a bányászatot és a proof-of-work blokkláncot. + + + +## A bányászati algoritmus {#mining-algorithm} + +Az Ethereum főhálózat csak egy bányászati algoritmust használt, az [Ethash-t](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Az Ethash a [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) néven ismert R&D algoritmus utódja volt. + +[Bővebben a bányászati algoritmusokról](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). + +## Kapcsolódó témák {#related-topics} + +- [Gáz](/developers/docs/gas/) +- [EVM](/developers/docs/evm/) +- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/) diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" new file mode 100644 index 00000000000..112d79e5d00 --- /dev/null +++ "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" @@ -0,0 +1,334 @@ +--- +title: Dagger-Hashimoto +description: A Dagger-Hashimoto algoritmus részletes áttekintése. +lang: hu +--- + +A Dagger-Hashimoto volt az Ethereum bányászati algoritmusának eredeti fejlesztési implementációja és specifikációja. A Dagger-Hashimoto algoritmust az [Ethash](#ethash) váltotta le. A bányászatot teljesen kikapcsolták az [egyesítés (Merge)](/roadmap/merge/) frissítés életbe lépésekor, 2022. szeptember 15-én. Azóta az Ethereumot a [proof-of-stake (letéti igazolás)](/developers/docs/consensus-mechanisms/pos) mechanizmusa biztosítja. Ez az oldal elavult témákat tartalmaz, amelyek többé már nem relevánsak az egyesítés (Merge) utáni Ethereummal kapcsolatban. + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértéséhez javasoljuk, hogy tekintse meg a [proof-of-work konszenzus](/developers/docs/consensus-mechanisms/pow), a [bányászat](/developers/docs/consensus-mechanisms/pow/mining), és a [bányászati algoritmusok](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) témáit. + +## Dagger-Hashimoto {#dagger-hashimoto} + +A Dagger-Hashimoto két célt szolgál: + +1. **ASIC-ellenálló**: az algoritmus futtatásához a specializált hardver kialakításából adódó előny a lehető legkisebb legyen +2. **Könnyű kliens általi ellenőrizhetőség**: a blokkot egy könnyű kliens is le tudja ellenőrizni hatékonyan. + +Egy újabb módosítással meghatározhatjuk, hogyan tud egy harmadik célt is kielégíteni, de ez a komplexitás növekedésével jár: + +**A teljes lánc tárolása**: a bányászathoz a teljes blokklánc státuszát le kell tárolni (az Ethereum státuszfa szabálytalan struktúrája miatt talán lehetséges ennek megrövidítése, főleg a gyakori szerződéseknél, de ezt minimalizálni szeretnénk). + +## DAG létrehozása {#dag-generation} + +Az algoritmus kódját pythonban alább találja. Először az `encode_int` kódot adjuk meg, hogy a megadott pontosságú nem aláírt egész számokat sztringekké alakítsa. Ennek fordítottja is megadásra kerül: + +```python +NUM_BITS = 512 + +def encode_int(x): + "Encode an integer x as a string of 64 characters using a big-endian scheme" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "Unencode an integer x from a string using a big-endian scheme" + x = 0 + for c in s: + x *= 256 + x += ord(c) + return x +``` + +Ezután, feltételezve, hogy az `sha3` egy olyan függvény, ami egész számot kap és azt is ad ki eredményként, továbbá a `dbl_sha3` egy dupla sha3 függvény; ha ezt a referenciakódot implementációvá alakítjuk: + +```python +from pyethereum import utils +def sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(x)) + +def dbl_sha3(x): + if isinstance(x, (int, long)): + x = encode_int(x) + return decode_int(utils.sha3(utils.sha3(x))) +``` + +### Paraméterek {#parameters} + +Az algoritmushoz a következő paramétereket használjuk: + +```python +SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512 + +params = { + "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536 + "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536 + # with epochtime=20000 gives 882 MB growth per year + "cache_size": 2500, # Size of the light client's cache (can be chosen by light + # client; not part of the algo spec) + "diff": 2**14, # Difficulty (adjusted during block evaluation) + "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated) + "k": 1, # Number of parents of a node + "w": w, # Used for modular exponentiation hashing + "accesses": 200, # Number of dataset accesses during hashimoto + "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation +} +``` + +A `P` ebben az esetben egy olyan prímszám, hogy a `log₂(P)` éppen csak kisebb legyen, mint 512, ami az 512 bithez kapcsolódik, amit a számok reprezentálására használunk. Érdemes megjegyezni, hogy a DAG-nek csak a második felét kell eltárolni, így a RAM-igény 1 GB-tól indul és 441 MB-tal növekszik évente. + +### Dagger-gráfépítés {#dagger-graph-building} + +A dagger-gráfépítési függvényt a következőképpen definiáljuk: + +```python +def produce_dag(params, seed, length): + P = params["P"] + picker = init = pow(sha3(seed), params["w"], P) + o = [init] + for i in range(1, length): + x = picker = (picker * init) % P + for _ in range(params["k"]): + x ^= o[x % i] + o.append(pow(x, params["w"], P)) + return o +``` + +Lényegében a gráfot egy egyszerű csomópontként kezdi (`sha3(seed)`), és innen ad hozzá szekvenciálisan újabb csomópontokat a véletlenszerű előzők csomópontok alapján. Egy új csomópont létrehozásakor a mag moduláris hatványát kiszámítjuk, hogy véletlenszerűen kiválasszunk néhány `i`-nél kisebb indexet (a fenti `x % i` használatával), és az ezeknél az indexeknél lévő csomópontok értékeit egy számításban felhasználjuk az `x` új értékének létrehozásához, amelyet aztán egy kis (XOR-alapú) proof-of-work függvénybe táplálunk, hogy végül az `i` indexnél lévő gráf értékét generáljuk. E sajátos kialakítás értelme az, hogy a DAG-hoz szekvenciális hozzáférést biztosítson; a DAG következő értékét nem lehet meghatározni addig, amíg a jelenlegi nem ismert. Végül a moduláris exponenciálás hasheli tovább az eredményt. + +Ez az algoritmus a számelmélet számos eredményén alapszik. Az alábbi függelékben megtalálhatja az erről szóló beszélgetést. + +## Könnyű kliens általi értékelés {#light-client-evaluation} + +Ez a gráfkonstrukció arra való, hogy a gráf minden csomópontja újraépíthető legyen egy kis számú csomópontból álló alfa segítségével, és csak kevés kiegészítő memória kelljen hozzá. Vegye figyelembe, hogy ha k=1, akkor az alfastruktúra csak az értékek egy olyan lánca, ami a DAG első eleméig tart. + +A DAG-re a következőképpen működik a könnyű kliens számítási függvénye: + +```python +def quick_calc(params, seed, p): + w, P = params["w"], params["P"] + cache = {} + + def quick_calc_cached(p): + if p in cache: + pass + elif p == 0: + cache[p] = pow(sha3(seed), w, P) + else: + x = pow(sha3(seed), (p + 1) * w, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(x % p) + cache[p] = pow(x, w, P) + return cache[p] + + return quick_calc_cached(p) +``` + +Lényegében ez a fenti algoritmus átirata, ami kiveszi a teljes DAG számítási ciklusát, és a korábbi csomópontkereső függvényt cseréli le egy rekurzív hívásra vagy egy cache-keresőre. Érdemes megjegyezni, hogy `k=1` esetén a cache szükségtelen, bár egy további optimalizálással a DAG első néhány ezer értékét előre kiszámítja, és statikus cache-ként tárolja a számításokhoz; ennek kódmegvalósítását tekintse meg a függelékben. + +## A DAG-ek dupla puffere {#double-buffer} + +Egy teljes kliensben 2 DAG [_dupla pufferét_](https://wikipedia.org/wiki/Multiple_buffering) használják, melyet a fenti képlet ad meg. Az elképzelés szerint a DAG-eket minden `epochtime` (korszakban) blokkszámonként készítik a fenti paramétereknek megfelelően. Ahelyett, hogy a kliens a legutóbbi DAG-et használná, az eggyel korábbit veszi figyelembe. Ennek előnye az, hogy a DAG-eket le lehet cserélni idővel anélkül, hogy a bányászoknak hirtelen az összes adatot újra kellene számolniuk. Máskülönben felmerül egy hirtelen, átmeneti lelassulás esélye a láncfeldolgozásnak, ami drasztikusan növeli a centralizációt. Így megnő az 51%-os támadás kockázata is az adat újraszámítása előtti percekben. + +A blokkhoz szükséges munka kiszámításához használt DAG-ek halmazának létrehozására használt algoritmus a következő: + +```python +def get_prevhash(n): + from pyethereum.blocks import GENESIS_PREVHASH + from pyethereum import chain_manager + if n <= 0: + return hash_to_int(GENESIS_PREVHASH) + else: + prevhash = chain_manager.index.get_block_by_number(n - 1) + return decode_int(prevhash) + +def get_seedset(params, block): + seedset = {} + seedset["back_number"] = block.number - (block.number % params["epochtime"]) + seedset["back_hash"] = get_prevhash(seedset["back_number"]) + seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) + seedset["front_hash"] = get_prevhash(seedset["front_number"]) + return seedset + +def get_dagsize(params, block): + return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] + +def get_daggerset(params, block): + dagsz = get_dagsize(params, block) + seedset = get_seedset(params, block) + if seedset["front_hash"] <= 0: + # No back buffer is possible, just make front buffer + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": 0}} + else: + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": seedset["front_number"]}, + "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), + "block_number": seedset["back_number"]}} +``` + +## Hashimoto {#hashimoto} + +Az eredeti Hashimoto lényege, hogy a blokkláncot adathalmazként használja, és olyan számítást végez, amely kiválaszt N indexet a blokkláncból, összegyűjti a tranzakciókat ezeken az indexeken, elvégzi a XOR-t ezekre az adatokra, és visszaadja az eredmény hashét. Thaddeus Dryja eredeti algoritmusa, Pythonra átfordítva a konzisztencia érdekében, így néz ki: + +```python +def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce): + hash_output_A = sha256(prev_hash + merkle_root + nonce) + txid_mix = 0 + for i in range(64): + shifted_A = hash_output_A >> i + transaction = shifted_A % len(list_of_transactions) + txid_mix ^= list_of_transactions[transaction] << i + return txid_mix ^ (nonce << 192) +``` + +Sajnálatos módon, miközben a Hashimoto nagy RAM-igényű, 256 bites aritmetikán alapszik, ami jelentős számítási többletköltséggel jár. Ugyanakkor a Dagger-Hashimoto csak a legkevésbé szignifikáns 64 bitet használja az adathalmaz indexálására, hogy ezt a problémát kezelje. + +```python +def hashimoto(dag, dagsize, params, header, nonce): + m = dagsize / 2 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= dag[m + (mix % 2**64) % m] + return dbl_sha3(mix) +``` + +A dupla SHA3 használata lehetővé teszi a nulla adatot tartalmazó, szinte azonnali előzetes ellenőrzést, amely csak azt ellenőrzi, hogy a helyes közbenső értéket adták meg. A proof-of-worknek ez a külső rétege rendkívül ASIC-barát és meglehetősen gyenge, de azért létezik, hogy még nehezebbé tegye a DDoS-t, mivel ezt a kis mennyiségű munkát kell elvégezni ahhoz, hogy egy olyan blokkot hozzanak létre, amelyet nem utasítanak el azonnal. Ez a könnyű kliens verziója: + +```python +def quick_hashimoto(seed, dagsize, params, header, nonce): + m = dagsize // 2 + mix = sha3(nonce + header) + for _ in range(params["accesses"]): + mix ^= quick_calc(params, seed, m + (mix % 2**64) % m) + return dbl_sha3(mix) +``` + +## Bányászat és ellenőrzés {#mining-and-verifying} + +Most vezessük be mindezt a bányászati algoritmusba: + +```python +def mine(daggerset, params, block): + from random import randint + nonce = randint(0, 2**64) + while 1: + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + if result * params["diff"] < 2**256: + break + nonce += 1 + if nonce >= 2**64: + nonce = 0 + return nonce +``` + +Ez az ellenőrzési algoritmus: + +```python +def verify(daggerset, params, block, nonce): + result = hashimoto(daggerset, get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Ez a könnyű kliens általi barátságos ellenőrzés: + +```python +def light_verify(params, header, nonce): + seedset = get_seedset(params, block) + result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block), + params, decode_int(block.prevhash), nonce) + return result * params["diff"] < 2**256 +``` + +Emellett érdemes megjegyezni, hogy a Dagger-Hashimoto a blokkfejlécre egyéb követelményeket is megfogalmazott: + +- A kétszintű ellenőrzéshez a blokkfejlécnek tartalmaznia kell a nonce-t és az sha3 előtti köztes értéket +- Valahol a blokkfejlécnek tárolnia kell a jelenlegi seed-halmaz sha3-ját + +## További olvasnivaló {#further-reading} + +_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ + +## Függelék {#appendix} + +Mint fentebb említettük, a DAG generálásához használt RNG a számelmélet néhány eredményére támaszkodik. Először is biztosítjuk, hogy a `picker` változó alapjául szolgáló Lehmer RNG széles periódussal rendelkezik. Másodszor, megmutatjuk, hogy a `pow(x,3,P)` nem fogja `x` kódot `1` vagy `P-1` értékre leképezni, feltéve, hogy `x ∈ [2,P-2]`. Végül megmutatjuk, hogy a `pow(x,3,P)` alacsony ütközési rátával rendelkezik, ha hash függvényként kezeljük. + +### Lehmer véletlenszám-generátor {#lehmer-random-number} + +Bár a `produce_dag` függvénynek nem kell torzítatlan véletlen számokat produkálnia, és potenciális veszélyt jelent, hogy a `seed**i % P` csak néhány értéket vesz fel. Ez előnyt jelenthet azoknak a bányászoknak, akik felismerik a mintát, miközben mások nem. + +Ennek elkerülése érdekében egy számelméleti eredményre hivatkozunk. A [_biztonságos prímszám_](https://en.wikipedia.org/wiki/Safe_prime) egy olyan prím `P`, amelynél a `(P-1)/2` szintén prímszám. A [multiplikatív csoport](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) egy `x` tagjának _rendje_ a `ℤ/nℤ` meghatározása szerint a minimális `m` úgy, hogy 
xᵐ mod P ≡ 1
+Ezen definíciók szerint: + +> 1. megfigyelés. Legyen `x` a `ℤ/Pℤ` multiplikatív csoport tagja egy biztonságos `P` prímszámhoz. Ha `x mod P ≠ 1 mod P` és `x mod P ≠ P-1 mod P`, akkor `x` rendje vagy `P-1` vagy `(P-1)/2`. + +_Bizonyítás_. Mivel `P` egy biztonságos prímszám, akkor a \[Lagrange-tétel\]\[lagrange\] alapján azt kell mondanunk, hogy `x` rendje vagy `1`, `2`, `(P-1)/2` vagy `P-1`. + +A `x` sorrendje nem lehet `1` Fermat kis tételéből következően: + +
xP-1 mod P ≡ 1
+ +Ezért `x` a `ℤ/nℤ` multiplikatív azonosságának kell lennie, ami egyedi. Mivel feltételezésünk szerint `x ≠ 1`, ez nem lehetséges. + +Az `x` sorrendje nem lehet `2`, kivéve, ha `x = P-1`, mivel ez sértené, hogy `P` prímszám. + +A fenti tételből felismerhetjük, hogy a `(picker * init) % P` ismétlése legalább `(P-1)/2` ciklushosszúságú lesz. Ennek az az oka, hogy a `P` értékének egy biztonságos prímszámot választottunk, amely megközelítőleg egyenlő a kettő nagyobb hatványával, és `init` a `[2,2**256+1]` intervallumban van. A `P` nagyságát tekintve a moduláris exponenciálástól nem várhatunk ciklust. + +A DAG első cellájának (az `init` feliratú változó) hozzárendelésekor kiszámítjuk a `pow(sha3(seed) + 2, 3, P)` értékét. Első pillantásra ez nem garantálja, hogy az eredmény nem `1` és nem `P-1`. Mivel azonban `P-1` egy biztonságos prímszám, a következő további bizonyosságunk van, amely az 1. megfigyelés következménye: + +> 2. megfigyelés. Legyen `x` a `ℤ/Pℤ` multiplikatív csoport tagja egy biztonságos `P` prímszámhoz, és legyen `w` egy természetes szám. Ha `x mod P ≠ 1 mod P` és `x mod P ≠ P-1 mod P`, valamint `w mod P ≠ P-1 mod P` és `w mod P ≠ 0 mod P`, akkor `xʷ mod P ≠ 1 mod P` és `xʷ mod P ≠ P-1 mod P` + +### Moduláris exponenciálás hashfüggvényként {#modular-exponentiation} + +A `P` és `w` bizonyos értékei esetén a `pow(x, w, P)` függvénynek sok ütközése lehet. Például a `pow(x,9,19)` csak `{1,18}` értékeket vesz fel. + +Adott, hogy `P` prímszám, akkor egy megfelelő `w` moduláris exponenciálási hashfüggvényhez a következő eredmény segítségével választható ki: + +> 3. megfigyelés. Legyen `P` egy prímszám; `w` és `P-1` akkor, és csak akkor relatív prímszámok, ha minden `a` és `b` esetén `ℤ/Pℤ`: +> +>
+> `aʷ mod P ≡ bʷ mod P`, ha és csak ha `a mod P ≡ b mod P` +>
+ +Így, feltéve, hogy `P` prím és `w` relatíve prím `P-1`-hez, akkor `|{pow(x, w, P) : x ∈ ℤ}| = P`, ami azt jelenti, hogy a hashfüggvény a lehető legkisebb ütközési rátával rendelkezik. + +Abban a speciális esetben, ha `P` egy biztonságos prímszám, ahogyan azt választottuk, akkor `P-1` csak 1, 2, `(P-1)/2` és `P-1` faktorokkal rendelkezik. Mivel `P` > 7, tudjuk, hogy 3 relatív prím a `P-1`-hez, ezért `w=3` kielégíti a fenti tételt. + +## Hatékonyabb cache-alapú kiértékelő algoritmus {#cache-based-evaluation} + +```python +def quick_calc(params, seed, p): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_calc_cached(cache, params, p) + +def quick_calc_cached(cache, params, p): + P = params["P"] + if p < len(cache): + return cache[p] + else: + x = pow(cache[0], p + 1, P) + for _ in range(params["k"]): + x ^= quick_calc_cached(cache, params, x % p) + return pow(x, params["w"], P) + +def quick_hashimoto(seed, dagsize, params, header, nonce): + cache = produce_dag(params, seed, params["cache_size"]) + return quick_hashimoto_cached(cache, dagsize, params, header, nonce) + +def quick_hashimoto_cached(cache, dagsize, params, header, nonce): + m = dagsize // 2 + mask = 2**64 - 1 + mix = sha3(encode_int(nonce) + header) + for _ in range(params["accesses"]): + mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m) + return dbl_sha3(mix) +``` diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" new file mode 100644 index 00000000000..93bb55dcc10 --- /dev/null +++ "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" @@ -0,0 +1,1014 @@ +--- +title: Ethash +description: Az Ethash algoritmus részletes bemutatása. +lang: hu +--- + + + Az Ethash volt az Ethereum proof-of-work (munkaigazolás) bányászati algoritmusa. A proof-of-work jelenleg **teljesen ki van kapcsolva**, az Ethereumot pedig a proof-of-stake mechanizmus biztosítja. Tudjon meg többet az egyesítés (Merge), proof-of-stake (letéti igazolás) és letétbe helyezés témákról. Ez az oldal elavult témákat tartalmaz! + + +Az [Ethash](https://github.com/ethereum/wiki/wiki/Ethash) a [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) algoritmus módosított változata. Az Ethash proof-of-work egy [ memóriaigényes (memory hard)](https://wikipedia.org/wiki/Memory-hard_function) működés, ami miatt ez az algoritmus ASIC-ellenálló. Az Ethash ASIC-t végül kifejlesztették, de a GPU-bányászat még mindig működő opció volt addig, amíg a proof-of-work metódust ki nem kapcsolták. Az Ethasht még használják más érmék bányászatánál, nem Ethereumon és nem proof-of-work hálózatokon. + +## Hogyan működik az Ethash? {#how-does-ethash-work} + +A memóriaigényt (memory hardness) egy proof-of-work algoritmussal lehet elérni, amelynek egy rögzített erőforrás részhalmazait kell kiválasztania a nonce és a blokkfejléc alapján. Ezt az erőforrást (ami néhány gigabájt nagyságú) DAG-nek (irányított aciklikus gráf/Directed Acyclic Graph) nevezik. A DAG minden 30 000. blokknál megváltozik, ami nagyjából 125 órás időtartamnak felel meg – ezt korszaknak nevezik (kb. 5,2 nap) és időbe telik, amíg létrejön. Mivel a DAG csak a blokk magasságán múlik, ezért előre el lehet készíteni, de ha nincs, akkor a kliensnek meg kell várnia a folyamat végét ahhoz, hogy blokkot készítsen. Ha a kliensek nem hozzák létre és cache-elik a DAG-eket korábban, akkor a hálózat komoly blokk-késedelmet szenved el minden korszakváltásnál (epoch). Fontos megjegyezni, hogy a DAG nem szükséges a proof-of-work ellenőrzéséhez, így ezt a folyamatot alacsony CPU-val és kevés memóriával is lehet végezni. + +Az algoritmus a következő általános utat teszi meg: + +1. Létezik egy **mag (seed)**, amelyet ki lehet számolni minden blokkra úgy, hogy a blokkfejléceket addig a pontig végigszkennelik. +2. Ebből a magból ki lehet számolni egy **16 MB álvéletlenszerű cache-t**. A könnyű kliensek tárolják a cache-t. +3. A gyorsítótárból egy **1 GB adathalmazt** lehet létrehozni, amelyben minden elem csak kevés gyorsítótár elemtől függ. A teljes kliensek és bányászok tárolják az adathalmazt. Az adathalmaz az idővel egyre növekszik. +4. A bányászat során az adathalmaz véletlenszerű szeleteit felkapják és összehashelik. Az ellenőrzést alacsony memóriával is lehet végezni, a cache-t használva arra, hogy újragenerálja az adathalmaz szükséges részeit, ezért csak a cache-t kell tárolni. + +A nagy adathalmaz minden 30 000. blokk után frissül, ezért a bányászok erőfeszítéseinek legjava az adatkészlet olvasására összpontosít, nem pedig a változtatására. + +## Definíciók {#definitions} + +A következő definíciókat használjuk: + +``` +WORD_BYTES = 4 # bytes in word +DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis +DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch +CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis +CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch +CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache +EPOCH_LENGTH = 30000 # blocks per epoch +MIX_BYTES = 128 # width of mix +HASH_BYTES = 64 # hash length in bytes +DATASET_PARENTS = 256 # number of parents of each dataset element +CACHE_ROUNDS = 3 # number of rounds in cache production +ACCESSES = 64 # number of accesses in hashimoto loop +``` + +### Az SHA3 használata {#sha3} + +Az Ethereum fejlesztése egybe esett az SHA3 szabvány kifejlesztésével, és a standard folyamat egy változtatást vitt véghez a végső hashalgoritmussal kapcsolatban, így az Ethereum „sha3_256” és „sha3_512” hashek nem szabványos sha3 hashek, hanem variánsok, melyre gyakran „Keccak-256” és „Keccak-512” néven hivatkoznak más kontextusban. Tekintse meg a kapcsolódó beszélgetéseket, például [itt](https://eips.ethereum.org/EIPS/eip-1803), [itt](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use) vagy [itt](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). + +Vegye figyelembe, hogy az alábbi leírás SHA3-hashekre hivatkozik az algoritmus tekintetében. + +## Paraméterek {#parameters} + +Az Ethash-cache és adathalmaz paraméterei a blokkszámtól függenek. A cache és az adathalmaz mérete egyenes arányosságban növekszik; ugyanakkor mindig a legnagyobb prímszámot választjuk a lineárisan növekvő határ alatt, hogy kevesebb kockázata legyen valamilyen szokatlan dolognak, ami ciklikus viselkedéshez vezet. + +```python +def get_cache_size(block_number): + sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= HASH_BYTES + while not isprime(sz / HASH_BYTES): + sz -= 2 * HASH_BYTES + return sz + +def get_full_size(block_number): + sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH) + sz -= MIX_BYTES + while not isprime(sz / MIX_BYTES): + sz -= 2 * MIX_BYTES + return sz +``` + +Az adathalmaznak és a cache-méret értékeinek táblázatát a függelékben találja. + +## Cache létrehozása {#cache-generation} + +Most meghatározzuk a cache létrehozásának függvényét: + +```python +def mkcache(cache_size, seed): + n = cache_size // HASH_BYTES + + # Sequentially produce the initial dataset + o = [sha3_512(seed)] + for i in range(1, n): + o.append(sha3_512(o[-1])) + + # Use a low-round version of randmemohash + for _ in range(CACHE_ROUNDS): + for i in range(n): + v = o[i][0] % n + o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v])) + + return o +``` + +A cache létrehozása először 32 MB-nyi memória szekvenciális feltöltését igényli, majd Sergio Demian Lerner _RandMemoHash_ algoritmusának két végrehajtását a [_Strict Memory Hard Hashing Functions-ből_ (2014)](http://www.hashcash.org/papers/memohash.pdf). Az eredmény egy 524 288 db 64-bájtos elemből álló készlet. + +## Adataggregálási függvény {#date-aggregation-function} + +Olyan algoritmust használunk, amit az [FNV hash](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) inspirált néhány esetben, mint a XOR nem-asszociatív helyettesítője. Vegye figyelembe, hogy a prímszámot a teljes 32 bites bemeneti adattal megszorozzuk, ellentétben az FNV-1 specifikációval, ami a prímszámot egy bájttal (octet) szorozza. + +```python +FNV_PRIME = 0x01000193 + +def fnv(v1, v2): + return ((v1 * FNV_PRIME) ^ v2) % 2**32 +``` + +Vegye figyelembe, hogy még a Sárgakönyv is úgy határozza meg az fnv-t, mint v1\*(FNV_PRIME ^ v2), és minden jelenlegi implementáció konzisztensen ezt használja. + +## Teljes adathalmaz kiszámítása {#full-dataset-calculation} + +Minden 64 bájtos elem a teljes 1 GB-nyi adathalmazban a következőképpen kerül kiszámolásra: + +```python +def calc_dataset_item(cache, i): + n = len(cache) + r = HASH_BYTES // WORD_BYTES + # initialize the mix + mix = copy.copy(cache[i % n]) + mix[0] ^= i + mix = sha3_512(mix) + # fnv it with a lot of random cache nodes based on i + for j in range(DATASET_PARENTS): + cache_index = fnv(i ^ j, mix[j % r]) + mix = map(fnv, mix, cache[cache_index % n]) + return sha3_512(mix) +``` + +Lényegében a 256 álvéletlenszerűen kiválasztott cache-csomópontokból származó adatot kombináljuk, és ezeket hasheljük, hogy kiszámoljuk az adathalmaz csomópontját. Ezután a teljes adathalmazt létrehozzuk: + +```python +def calc_dataset(full_size, cache): + return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] +``` + +## Fő ciklus {#main-loop} + +Most meghatározzuk a fő „hashimoto”-szerű ciklust, ahol aggregáljuk a teljes adathalmazból vett adatokat azért, hogy egy bizonyos fejléchez és nonce-hoz végső értéket rendeljünk. A lenti kódban a `header` (fejléc) az SHA3-256 _hasht_ képviseli, ami az RLP reprezentációja egy _csonka_ blokkfejlécnek, tehát olyan fejléc, amiben nincs benne a **mixHash** és a **nonce**. A `nonce` egy 64 bites, nem aláírt egész szám nyolc bájtja big-endian sorban. Tehát a `nonce[::-1]` a nyolc bájtos kis-endian reprezentációja ennek az értéknek: + +```python +def hashimoto(header, nonce, full_size, dataset_lookup): + n = full_size / HASH_BYTES + w = MIX_BYTES // WORD_BYTES + mixhashes = MIX_BYTES / HASH_BYTES + # combine header+nonce into a 64 byte seed + s = sha3_512(header + nonce[::-1]) + # start the mix with replicated s + mix = [] + for _ in range(MIX_BYTES / HASH_BYTES): + mix.extend(s) + # mix in random dataset nodes + for i in range(ACCESSES): + p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes + newdata = [] + for j in range(MIX_BYTES / HASH_BYTES): + newdata.extend(dataset_lookup(p + j)) + mix = map(fnv, mix, newdata) + # compress mix + cmix = [] + for i in range(0, len(mix), 4): + cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) + return { + "mix digest": serialize_hash(cmix), + "result": serialize_hash(sha3_256(s+cmix)) + } + +def hashimoto_light(full_size, cache, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x)) + +def hashimoto_full(full_size, dataset, header, nonce): + return hashimoto(header, nonce, full_size, lambda x: dataset[x]) +``` + +Lényegében egy 128 bájt széles „mixet” készítünk, és ismétlődő módon, szekvenciálisan felkapunk 128 bájtot a teljes adathalmazból, és az `fnv` függvénnyel összekombináljuk a mix-szel. Azért 128 bájtnyi szekvenciális bemenetet használunk, hogy az algoritmus minden egyes köre a RAM egy teljes oldalát felkapja, így minimalizálva az átfordítás hibáit, melyeket az ASIC elméletileg el tudna kerülni. + +Ha az algoritmus kimenete a várt eredményt adja, akkor a nonce érvényes. Fontos megjegyezni, hogy az `sha3_256` extra alkalmazása a végén azt biztosítja, hogy létezik egy köztes nonce, ami bizonyítja, hogy legalább egy kis munkavégzés történt; ezt a gyors, külső proof-of-work-ellenőrzést DDoS elleni célokra lehet használni. Emellett statisztikai biztosítást is ad, hogy az eredmény egy helyes 256 bites szám. + +## Bányászat {#mining} + +A bányászati algoritmust a következőképpen definiáljuk: + +```python +def mine(full_size, dataset, header, difficulty): + # zero-pad target to compare with hash on the same digit + target = zpad(encode_int(2**256 // difficulty), 64)[::-1] + from random import randint + nonce = randint(0, 2**64) + while hashimoto_full(full_size, dataset, header, nonce) > target: + nonce = (nonce + 1) % 2**64 + return nonce +``` + +## A seed hash meghatározása {#seed-hash} + +A seed hash kiszámolásához, amellyel egy adott blokk tetején lehet bányászni, a következő algoritmust használjuk: + +```python + def get_seedhash(block): + s = '\x00' * 32 + for i in range(block.number // EPOCH_LENGTH): + s = serialize_hash(sha3_256(s)) + return s +``` + +Vegye figyelembe, hogy a zavartalan bányászat és ellenőrzés érdekében érdemes előre kiszámolni a jövőbeli seed hasheket és adathalmazokat egy másik helyen. + +## További olvasnivaló {#further-reading} + +_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ + +## Függelék {#appendix} + +A következő kódot kell beilleszteni, ha Ön a fenti python-specifikációt akarja futtatni kódként. + +```python +import sha3, copy + +# Assumes little endian bit ordering (same as Intel architectures) +def decode_int(s): + return int(s[::-1].encode('hex'), 16) if s else 0 + +def encode_int(s): + a = "%x" % s + return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1] + +def zpad(s, length): + return s + '\x00' * max(0, length - len(s)) + +def serialize_hash(h): + return ''.join([zpad(encode_int(x), 4) for x in h]) + +def deserialize_hash(h): + return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)] + +def hash_words(h, sz, x): + if isinstance(x, list): + x = serialize_hash(x) + y = h(x) + return deserialize_hash(y) + +def serialize_cache(ds): + return ''.join([serialize_hash(h) for h in ds]) + +serialize_dataset = serialize_cache + +# sha3 hash function, outputs 64 bytes +def sha3_512(x): + return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) + +def sha3_256(x): + return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x) + +def xor(a, b): + return a ^ b + +def isprime(x): + for i in range(2, int(x**0.5)): + if x % i == 0: + return False + return True +``` + +### Adatméretek {#data-sizes} + +A következő tábla kb. 2048 korszak adat- és cache-méreteit mutatja meg. + +```python +def get_datasize(block_number): + return data_sizes[block_number // EPOCH_LENGTH] + +def get_cachesize(block_number): + return cache_sizes[block_number // EPOCH_LENGTH] + +data_sizes = [ +1073739904, 1082130304, 1090514816, 1098906752, 1107293056, +1115684224, 1124070016, 1132461952, 1140849536, 1149232768, +1157627776, 1166013824, 1174404736, 1182786944, 1191180416, +1199568512, 1207958912, 1216345216, 1224732032, 1233124736, +1241513344, 1249902464, 1258290304, 1266673792, 1275067264, +1283453312, 1291844992, 1300234112, 1308619904, 1317010048, +1325397376, 1333787776, 1342176128, 1350561664, 1358954368, +1367339392, 1375731584, 1384118144, 1392507008, 1400897408, +1409284736, 1417673344, 1426062464, 1434451072, 1442839168, +1451229056, 1459615616, 1468006016, 1476394112, 1484782976, +1493171584, 1501559168, 1509948032, 1518337664, 1526726528, +1535114624, 1543503488, 1551892096, 1560278656, 1568669056, +1577056384, 1585446272, 1593831296, 1602219392, 1610610304, +1619000192, 1627386752, 1635773824, 1644164224, 1652555648, +1660943488, 1669332608, 1677721216, 1686109312, 1694497664, +1702886272, 1711274624, 1719661184, 1728047744, 1736434816, +1744829056, 1753218944, 1761606272, 1769995904, 1778382464, +1786772864, 1795157888, 1803550592, 1811937664, 1820327552, +1828711552, 1837102976, 1845488768, 1853879936, 1862269312, +1870656896, 1879048064, 1887431552, 1895825024, 1904212096, +1912601216, 1920988544, 1929379456, 1937765504, 1946156672, +1954543232, 1962932096, 1971321728, 1979707264, 1988093056, +1996487552, 2004874624, 2013262208, 2021653888, 2030039936, +2038430848, 2046819968, 2055208576, 2063596672, 2071981952, +2080373632, 2088762752, 2097149056, 2105539712, 2113928576, +2122315136, 2130700672, 2139092608, 2147483264, 2155872128, +2164257664, 2172642176, 2181035392, 2189426048, 2197814912, +2206203008, 2214587264, 2222979712, 2231367808, 2239758208, +2248145024, 2256527744, 2264922752, 2273312128, 2281701248, +2290086272, 2298476672, 2306867072, 2315251072, 2323639168, +2332032128, 2340420224, 2348808064, 2357196416, 2365580416, +2373966976, 2382363008, 2390748544, 2399139968, 2407530368, +2415918976, 2424307328, 2432695424, 2441084288, 2449472384, +2457861248, 2466247808, 2474637184, 2483026816, 2491414144, +2499803776, 2508191872, 2516582272, 2524970368, 2533359232, +2541743488, 2550134144, 2558525056, 2566913408, 2575301504, +2583686528, 2592073856, 2600467328, 2608856192, 2617240448, +2625631616, 2634022016, 2642407552, 2650796416, 2659188352, +2667574912, 2675965312, 2684352896, 2692738688, 2701130624, +2709518464, 2717907328, 2726293376, 2734685056, 2743073152, +2751462016, 2759851648, 2768232832, 2776625536, 2785017728, +2793401984, 2801794432, 2810182016, 2818571648, 2826959488, +2835349376, 2843734144, 2852121472, 2860514432, 2868900992, +2877286784, 2885676928, 2894069632, 2902451584, 2910843008, +2919234688, 2927622784, 2936011648, 2944400768, 2952789376, +2961177728, 2969565568, 2977951616, 2986338944, 2994731392, +3003120256, 3011508352, 3019895936, 3028287104, 3036675968, +3045063808, 3053452928, 3061837696, 3070228352, 3078615424, +3087003776, 3095394944, 3103782272, 3112173184, 3120562048, +3128944768, 3137339264, 3145725056, 3154109312, 3162505088, +3170893184, 3179280256, 3187669376, 3196056704, 3204445568, +3212836736, 3221224064, 3229612928, 3238002304, 3246391168, +3254778496, 3263165824, 3271556224, 3279944576, 3288332416, +3296719232, 3305110912, 3313500032, 3321887104, 3330273152, +3338658944, 3347053184, 3355440512, 3363827072, 3372220288, +3380608384, 3388997504, 3397384576, 3405774208, 3414163072, +3422551936, 3430937984, 3439328384, 3447714176, 3456104576, +3464493952, 3472883584, 3481268864, 3489655168, 3498048896, +3506434432, 3514826368, 3523213952, 3531603584, 3539987072, +3548380288, 3556763264, 3565157248, 3573545344, 3581934464, +3590324096, 3598712704, 3607098752, 3615488384, 3623877248, +3632265856, 3640646528, 3649043584, 3657430144, 3665821568, +3674207872, 3682597504, 3690984832, 3699367808, 3707764352, +3716152448, 3724541056, 3732925568, 3741318016, 3749706368, +3758091136, 3766481536, 3774872704, 3783260032, 3791650432, +3800036224, 3808427648, 3816815488, 3825204608, 3833592704, +3841981568, 3850370432, 3858755968, 3867147904, 3875536256, +3883920512, 3892313728, 3900702592, 3909087872, 3917478784, +3925868416, 3934256512, 3942645376, 3951032192, 3959422336, +3967809152, 3976200064, 3984588416, 3992974976, 4001363584, +4009751168, 4018141312, 4026530432, 4034911616, 4043308928, +4051695488, 4060084352, 4068472448, 4076862848, 4085249408, +4093640576, 4102028416, 4110413696, 4118805632, 4127194496, +4135583104, 4143971968, 4152360832, 4160746112, 4169135744, +4177525888, 4185912704, 4194303616, 4202691968, 4211076736, +4219463552, 4227855488, 4236246656, 4244633728, 4253022848, +4261412224, 4269799808, 4278184832, 4286578048, 4294962304, +4303349632, 4311743104, 4320130432, 4328521088, 4336909184, +4345295488, 4353687424, 4362073472, 4370458496, 4378852736, +4387238528, 4395630208, 4404019072, 4412407424, 4420790656, +4429182848, 4437571456, 4445962112, 4454344064, 4462738048, +4471119232, 4479516544, 4487904128, 4496289664, 4504682368, +4513068416, 4521459584, 4529846144, 4538232704, 4546619776, +4555010176, 4563402112, 4571790208, 4580174464, 4588567936, +4596957056, 4605344896, 4613734016, 4622119808, 4630511488, +4638898816, 4647287936, 4655675264, 4664065664, 4672451968, +4680842624, 4689231488, 4697620352, 4706007424, 4714397056, +4722786176, 4731173248, 4739562368, 4747951744, 4756340608, +4764727936, 4773114496, 4781504384, 4789894784, 4798283648, +4806667648, 4815059584, 4823449472, 4831835776, 4840226176, +4848612224, 4857003392, 4865391488, 4873780096, 4882169728, +4890557312, 4898946944, 4907333248, 4915722368, 4924110976, +4932499328, 4940889728, 4949276032, 4957666432, 4966054784, +4974438016, 4982831488, 4991221376, 4999607168, 5007998848, +5016386432, 5024763776, 5033164672, 5041544576, 5049941888, +5058329728, 5066717056, 5075107456, 5083494272, 5091883904, +5100273536, 5108662144, 5117048192, 5125436032, 5133827456, +5142215296, 5150605184, 5158993024, 5167382144, 5175769472, +5184157568, 5192543872, 5200936064, 5209324928, 5217711232, +5226102656, 5234490496, 5242877312, 5251263872, 5259654016, +5268040832, 5276434304, 5284819328, 5293209728, 5301598592, +5309986688, 5318374784, 5326764416, 5335151488, 5343542144, +5351929472, 5360319872, 5368706944, 5377096576, 5385484928, +5393871232, 5402263424, 5410650496, 5419040384, 5427426944, +5435816576, 5444205952, 5452594816, 5460981376, 5469367936, +5477760896, 5486148736, 5494536832, 5502925952, 5511315328, +5519703424, 5528089984, 5536481152, 5544869504, 5553256064, +5561645696, 5570032768, 5578423936, 5586811264, 5595193216, +5603585408, 5611972736, 5620366208, 5628750464, 5637143936, +5645528192, 5653921408, 5662310272, 5670694784, 5679082624, +5687474048, 5695864448, 5704251008, 5712641408, 5721030272, +5729416832, 5737806208, 5746194304, 5754583936, 5762969984, +5771358592, 5779748224, 5788137856, 5796527488, 5804911232, +5813300608, 5821692544, 5830082176, 5838468992, 5846855552, +5855247488, 5863636096, 5872024448, 5880411008, 5888799872, +5897186432, 5905576832, 5913966976, 5922352768, 5930744704, +5939132288, 5947522432, 5955911296, 5964299392, 5972688256, +5981074304, 5989465472, 5997851008, 6006241408, 6014627968, +6023015552, 6031408256, 6039796096, 6048185216, 6056574848, +6064963456, 6073351808, 6081736064, 6090128768, 6098517632, +6106906496, 6115289216, 6123680896, 6132070016, 6140459648, +6148849024, 6157237376, 6165624704, 6174009728, 6182403712, +6190792064, 6199176064, 6207569792, 6215952256, 6224345216, +6232732544, 6241124224, 6249510272, 6257899136, 6266287744, +6274676864, 6283065728, 6291454336, 6299843456, 6308232064, +6316620928, 6325006208, 6333395584, 6341784704, 6350174848, +6358562176, 6366951296, 6375337856, 6383729536, 6392119168, +6400504192, 6408895616, 6417283456, 6425673344, 6434059136, +6442444672, 6450837376, 6459223424, 6467613056, 6476004224, +6484393088, 6492781952, 6501170048, 6509555072, 6517947008, +6526336384, 6534725504, 6543112832, 6551500672, 6559888768, +6568278656, 6576662912, 6585055616, 6593443456, 6601834112, +6610219648, 6618610304, 6626999168, 6635385472, 6643777408, +6652164224, 6660552832, 6668941952, 6677330048, 6685719424, +6694107776, 6702493568, 6710882176, 6719274112, 6727662976, +6736052096, 6744437632, 6752825984, 6761213824, 6769604224, +6777993856, 6786383488, 6794770816, 6803158144, 6811549312, +6819937664, 6828326528, 6836706176, 6845101696, 6853491328, +6861880448, 6870269312, 6878655104, 6887046272, 6895433344, +6903822208, 6912212864, 6920596864, 6928988288, 6937377152, +6945764992, 6954149248, 6962544256, 6970928768, 6979317376, +6987709312, 6996093824, 7004487296, 7012875392, 7021258624, +7029652352, 7038038912, 7046427776, 7054818944, 7063207808, +7071595136, 7079980928, 7088372608, 7096759424, 7105149824, +7113536896, 7121928064, 7130315392, 7138699648, 7147092352, +7155479168, 7163865728, 7172249984, 7180648064, 7189036672, +7197424768, 7205810816, 7214196608, 7222589824, 7230975104, +7239367552, 7247755904, 7256145536, 7264533376, 7272921472, +7281308032, 7289694848, 7298088832, 7306471808, 7314864512, +7323253888, 7331643008, 7340029568, 7348419712, 7356808832, +7365196672, 7373585792, 7381973888, 7390362752, 7398750592, +7407138944, 7415528576, 7423915648, 7432302208, 7440690304, +7449080192, 7457472128, 7465860992, 7474249088, 7482635648, +7491023744, 7499412608, 7507803008, 7516192384, 7524579968, +7532967296, 7541358464, 7549745792, 7558134656, 7566524032, +7574912896, 7583300992, 7591690112, 7600075136, 7608466816, +7616854912, 7625244544, 7633629824, 7642020992, 7650410368, +7658794112, 7667187328, 7675574912, 7683961984, 7692349568, +7700739712, 7709130368, 7717519232, 7725905536, 7734295424, +7742683264, 7751069056, 7759457408, 7767849088, 7776238208, +7784626816, 7793014912, 7801405312, 7809792128, 7818179968, +7826571136, 7834957184, 7843347328, 7851732352, 7860124544, +7868512384, 7876902016, 7885287808, 7893679744, 7902067072, +7910455936, 7918844288, 7927230848, 7935622784, 7944009344, +7952400256, 7960786048, 7969176704, 7977565312, 7985953408, +7994339968, 8002730368, 8011119488, 8019508096, 8027896192, +8036285056, 8044674688, 8053062272, 8061448832, 8069838464, +8078227328, 8086616704, 8095006592, 8103393664, 8111783552, +8120171392, 8128560256, 8136949376, 8145336704, 8153726848, +8162114944, 8170503296, 8178891904, 8187280768, 8195669632, +8204058496, 8212444544, 8220834176, 8229222272, 8237612672, +8246000768, 8254389376, 8262775168, 8271167104, 8279553664, +8287944064, 8296333184, 8304715136, 8313108352, 8321497984, +8329885568, 8338274432, 8346663296, 8355052928, 8363441536, +8371828352, 8380217984, 8388606592, 8396996224, 8405384576, +8413772672, 8422161536, 8430549376, 8438939008, 8447326592, +8455715456, 8464104832, 8472492928, 8480882048, 8489270656, +8497659776, 8506045312, 8514434944, 8522823808, 8531208832, +8539602304, 8547990656, 8556378752, 8564768384, 8573154176, +8581542784, 8589933952, 8598322816, 8606705024, 8615099264, +8623487872, 8631876992, 8640264064, 8648653952, 8657040256, +8665430656, 8673820544, 8682209152, 8690592128, 8698977152, +8707374464, 8715763328, 8724151424, 8732540032, 8740928384, +8749315712, 8757704576, 8766089344, 8774480768, 8782871936, +8791260032, 8799645824, 8808034432, 8816426368, 8824812928, +8833199488, 8841591424, 8849976448, 8858366336, 8866757248, +8875147136, 8883532928, 8891923328, 8900306816, 8908700288, +8917088384, 8925478784, 8933867392, 8942250368, 8950644608, +8959032704, 8967420544, 8975809664, 8984197504, 8992584064, +9000976256, 9009362048, 9017752448, 9026141312, 9034530688, +9042917504, 9051307904, 9059694208, 9068084864, 9076471424, +9084861824, 9093250688, 9101638528, 9110027648, 9118416512, +9126803584, 9135188096, 9143581312, 9151969664, 9160356224, +9168747136, 9177134464, 9185525632, 9193910144, 9202302848, +9210690688, 9219079552, 9227465344, 9235854464, 9244244864, +9252633472, 9261021824, 9269411456, 9277799296, 9286188928, +9294574208, 9302965888, 9311351936, 9319740032, 9328131968, +9336516736, 9344907392, 9353296768, 9361685888, 9370074752, +9378463616, 9386849408, 9395239808, 9403629184, 9412016512, +9420405376, 9428795008, 9437181568, 9445570688, 9453960832, +9462346624, 9470738048, 9479121536, 9487515008, 9495903616, +9504289664, 9512678528, 9521067904, 9529456256, 9537843584, +9546233728, 9554621312, 9563011456, 9571398784, 9579788672, +9588178304, 9596567168, 9604954496, 9613343104, 9621732992, +9630121856, 9638508416, 9646898816, 9655283584, 9663675776, +9672061312, 9680449664, 9688840064, 9697230464, 9705617536, +9714003584, 9722393984, 9730772608, 9739172224, 9747561088, +9755945344, 9764338816, 9772726144, 9781116544, 9789503872, +9797892992, 9806282624, 9814670464, 9823056512, 9831439232, +9839833984, 9848224384, 9856613504, 9865000576, 9873391232, +9881772416, 9890162816, 9898556288, 9906940544, 9915333248, +9923721088, 9932108672, 9940496512, 9948888448, 9957276544, +9965666176, 9974048384, 9982441088, 9990830464, 9999219584, +10007602816, 10015996544, 10024385152, 10032774016, 10041163648, +10049548928, 10057940096, 10066329472, 10074717824, 10083105152, +10091495296, 10099878784, 10108272256, 10116660608, 10125049216, +10133437312, 10141825664, 10150213504, 10158601088, 10166991232, +10175378816, 10183766144, 10192157312, 10200545408, 10208935552, +10217322112, 10225712768, 10234099328, 10242489472, 10250876032, +10259264896, 10267656064, 10276042624, 10284429184, 10292820352, +10301209472, 10309598848, 10317987712, 10326375296, 10334763392, +10343153536, 10351541632, 10359930752, 10368318592, 10376707456, +10385096576, 10393484672, 10401867136, 10410262144, 10418647424, +10427039104, 10435425664, 10443810176, 10452203648, 10460589952, +10468982144, 10477369472, 10485759104, 10494147712, 10502533504, +10510923392, 10519313536, 10527702656, 10536091264, 10544478592, +10552867712, 10561255808, 10569642368, 10578032768, 10586423168, +10594805632, 10603200128, 10611588992, 10619976064, 10628361344, +10636754048, 10645143424, 10653531776, 10661920384, 10670307968, +10678696832, 10687086464, 10695475072, 10703863168, 10712246144, +10720639616, 10729026688, 10737414784, 10745806208, 10754190976, +10762581376, 10770971264, 10779356288, 10787747456, 10796135552, +10804525184, 10812915584, 10821301888, 10829692288, 10838078336, +10846469248, 10854858368, 10863247232, 10871631488, 10880023424, +10888412032, 10896799616, 10905188992, 10913574016, 10921964672, +10930352768, 10938742912, 10947132544, 10955518592, 10963909504, +10972298368, 10980687488, 10989074816, 10997462912, 11005851776, +11014241152, 11022627712, 11031017344, 11039403904, 11047793024, +11056184704, 11064570752, 11072960896, 11081343872, 11089737856, +11098128256, 11106514816, 11114904448, 11123293568, 11131680128, +11140065152, 11148458368, 11156845696, 11165236864, 11173624192, +11182013824, 11190402688, 11198790784, 11207179136, 11215568768, +11223957376, 11232345728, 11240734592, 11249122688, 11257511296, +11265899648, 11274285952, 11282675584, 11291065472, 11299452544, +11307842432, 11316231296, 11324616832, 11333009024, 11341395584, +11349782656, 11358172288, 11366560384, 11374950016, 11383339648, +11391721856, 11400117376, 11408504192, 11416893568, 11425283456, +11433671552, 11442061184, 11450444672, 11458837888, 11467226752, +11475611776, 11484003968, 11492392064, 11500780672, 11509169024, +11517550976, 11525944448, 11534335616, 11542724224, 11551111808, +11559500672, 11567890304, 11576277376, 11584667008, 11593056128, +11601443456, 11609830016, 11618221952, 11626607488, 11634995072, +11643387776, 11651775104, 11660161664, 11668552576, 11676940928, +11685330304, 11693718656, 11702106496, 11710496128, 11718882688, +11727273088, 11735660416, 11744050048, 11752437376, 11760824704, +11769216128, 11777604736, 11785991296, 11794381952, 11802770048, +11811157888, 11819548544, 11827932544, 11836324736, 11844713344, +11853100928, 11861486464, 11869879936, 11878268032, 11886656896, +11895044992, 11903433088, 11911822976, 11920210816, 11928600448, +11936987264, 11945375872, 11953761152, 11962151296, 11970543488, +11978928512, 11987320448, 11995708288, 12004095104, 12012486272, +12020875136, 12029255552, 12037652096, 12046039168, 12054429568, +12062813824, 12071206528, 12079594624, 12087983744, 12096371072, +12104759936, 12113147264, 12121534592, 12129924992, 12138314624, +12146703232, 12155091584, 12163481216, 12171864704, 12180255872, +12188643968, 12197034112, 12205424512, 12213811328, 12222199424, +12230590336, 12238977664, 12247365248, 12255755392, 12264143488, +12272531584, 12280920448, 12289309568, 12297694592, 12306086528, +12314475392, 12322865024, 12331253632, 12339640448, 12348029312, +12356418944, 12364805248, 12373196672, 12381580928, 12389969024, +12398357632, 12406750592, 12415138432, 12423527552, 12431916416, +12440304512, 12448692352, 12457081216, 12465467776, 12473859968, +12482245504, 12490636672, 12499025536, 12507411584, 12515801728, +12524190592, 12532577152, 12540966272, 12549354368, 12557743232, +12566129536, 12574523264, 12582911872, 12591299456, 12599688064, +12608074624, 12616463488, 12624845696, 12633239936, 12641631616, +12650019968, 12658407296, 12666795136, 12675183232, 12683574656, +12691960192, 12700350592, 12708740224, 12717128576, 12725515904, +12733906816, 12742295168, 12750680192, 12759071872, 12767460736, +12775848832, 12784236928, 12792626816, 12801014656, 12809404288, +12817789312, 12826181504, 12834568832, 12842954624, 12851345792, +12859732352, 12868122496, 12876512128, 12884901248, 12893289088, +12901672832, 12910067584, 12918455168, 12926842496, 12935232896, +12943620736, 12952009856, 12960396928, 12968786816, 12977176192, +12985563776, 12993951104, 13002341504, 13010730368, 13019115392, +13027506304, 13035895168, 13044272512, 13052673152, 13061062528, +13069446272, 13077838976, 13086227072, 13094613632, 13103000192, +13111393664, 13119782528, 13128157568, 13136559232, 13144945024, +13153329536, 13161724288, 13170111872, 13178502784, 13186884736, +13195279744, 13203667072, 13212057472, 13220445824, 13228832128, +13237221248, 13245610624, 13254000512, 13262388352, 13270777472, +13279166336, 13287553408, 13295943296, 13304331904, 13312719488, +13321108096, 13329494656, 13337885824, 13346274944, 13354663808, +13363051136, 13371439232, 13379825024, 13388210816, 13396605056, +13404995456, 13413380224, 13421771392, 13430159744, 13438546048, +13446937216, 13455326848, 13463708288, 13472103808, 13480492672, +13488875648, 13497269888, 13505657728, 13514045312, 13522435712, +13530824576, 13539210112, 13547599232, 13555989376, 13564379008, +13572766336, 13581154432, 13589544832, 13597932928, 13606320512, +13614710656, 13623097472, 13631477632, 13639874944, 13648264064, +13656652928, 13665041792, 13673430656, 13681818496, 13690207616, +13698595712, 13706982272, 13715373184, 13723762048, 13732150144, +13740536704, 13748926592, 13757316224, 13765700992, 13774090112, +13782477952, 13790869376, 13799259008, 13807647872, 13816036736, +13824425344, 13832814208, 13841202304, 13849591424, 13857978752, +13866368896, 13874754688, 13883145344, 13891533184, 13899919232, +13908311168, 13916692096, 13925085056, 13933473152, 13941866368, +13950253696, 13958643584, 13967032192, 13975417216, 13983807616, +13992197504, 14000582272, 14008973696, 14017363072, 14025752192, +14034137984, 14042528384, 14050918016, 14059301504, 14067691648, +14076083584, 14084470144, 14092852352, 14101249664, 14109635968, +14118024832, 14126407552, 14134804352, 14143188608, 14151577984, +14159968384, 14168357248, 14176741504, 14185127296, 14193521024, +14201911424, 14210301824, 14218685056, 14227067264, 14235467392, +14243855488, 14252243072, 14260630144, 14269021568, 14277409408, +14285799296, 14294187904, 14302571392, 14310961792, 14319353728, +14327738752, 14336130944, 14344518784, 14352906368, 14361296512, +14369685376, 14378071424, 14386462592, 14394848128, 14403230848, +14411627392, 14420013952, 14428402304, 14436793472, 14445181568, +14453569664, 14461959808, 14470347904, 14478737024, 14487122816, +14495511424, 14503901824, 14512291712, 14520677504, 14529064832, +14537456768, 14545845632, 14554234496, 14562618496, 14571011456, +14579398784, 14587789184, 14596172672, 14604564608, 14612953984, +14621341312, 14629724288, 14638120832, 14646503296, 14654897536, +14663284864, 14671675264, 14680061056, 14688447616, 14696835968, +14705228416, 14713616768, 14722003328, 14730392192, 14738784128, +14747172736, 14755561088, 14763947648, 14772336512, 14780725376, +14789110144, 14797499776, 14805892736, 14814276992, 14822670208, +14831056256, 14839444352, 14847836032, 14856222848, 14864612992, +14872997504, 14881388672, 14889775744, 14898165376, 14906553472, +14914944896, 14923329664, 14931721856, 14940109696, 14948497024, +14956887424, 14965276544, 14973663616, 14982053248, 14990439808, +14998830976, 15007216768, 15015605888, 15023995264, 15032385152, +15040768384, 15049154944, 15057549184, 15065939072, 15074328448, +15082715008, 15091104128, 15099493504, 15107879296, 15116269184, +15124659584, 15133042304, 15141431936, 15149824384, 15158214272, +15166602368, 15174991232, 15183378304, 15191760512, 15200154496, +15208542592, 15216931712, 15225323392, 15233708416, 15242098048, +15250489216, 15258875264, 15267265408, 15275654528, 15284043136, +15292431488, 15300819584, 15309208192, 15317596544, 15325986176, +15334374784, 15342763648, 15351151744, 15359540608, 15367929728, +15376318336, 15384706432, 15393092992, 15401481856, 15409869952, +15418258816, 15426649984, 15435037568, 15443425664, 15451815296, +15460203392, 15468589184, 15476979328, 15485369216, 15493755776, +15502146944, 15510534272, 15518924416, 15527311232, 15535699072, +15544089472, 15552478336, 15560866688, 15569254528, 15577642624, +15586031488, 15594419072, 15602809472, 15611199104, 15619586432, +15627975296, 15636364928, 15644753792, 15653141888, 15661529216, +15669918848, 15678305152, 15686696576, 15695083136, 15703474048, +15711861632, 15720251264, 15728636288, 15737027456, 15745417088, +15753804928, 15762194048, 15770582656, 15778971008, 15787358336, +15795747712, 15804132224, 15812523392, 15820909696, 15829300096, +15837691264, 15846071936, 15854466944, 15862855808, 15871244672, +15879634816, 15888020608, 15896409728, 15904799104, 15913185152, +15921577088, 15929966464, 15938354816, 15946743424, 15955129472, +15963519872, 15971907968, 15980296064, 15988684928, 15997073024, +16005460864, 16013851264, 16022241152, 16030629248, 16039012736, +16047406976, 16055794816, 16064181376, 16072571264, 16080957824, +16089346688, 16097737856, 16106125184, 16114514816, 16122904192, +16131292544, 16139678848, 16148066944, 16156453504, 16164839552, +16173236096, 16181623424, 16190012032, 16198401152, 16206790528, +16215177344, 16223567744, 16231956352, 16240344704, 16248731008, +16257117824, 16265504384, 16273898624, 16282281856, 16290668672, +16299064192, 16307449216, 16315842176, 16324230016, 16332613504, +16341006464, 16349394304, 16357783168, 16366172288, 16374561664, +16382951296, 16391337856, 16399726208, 16408116352, 16416505472, +16424892032, 16433282176, 16441668224, 16450058624, 16458448768, +16466836864, 16475224448, 16483613056, 16492001408, 16500391808, +16508779648, 16517166976, 16525555328, 16533944192, 16542330752, +16550719616, 16559110528, 16567497088, 16575888512, 16584274816, +16592665472, 16601051008, 16609442944, 16617832064, 16626218624, +16634607488, 16642996096, 16651385728, 16659773824, 16668163712, +16676552576, 16684938112, 16693328768, 16701718144, 16710095488, +16718492288, 16726883968, 16735272832, 16743661184, 16752049792, +16760436608, 16768827008, 16777214336, 16785599104, 16793992832, +16802381696, 16810768768, 16819151744, 16827542656, 16835934848, +16844323712, 16852711552, 16861101952, 16869489536, 16877876864, +16886265728, 16894653056, 16903044736, 16911431296, 16919821696, +16928207488, 16936592768, 16944987776, 16953375616, 16961763968, +16970152832, 16978540928, 16986929536, 16995319168, 17003704448, +17012096896, 17020481152, 17028870784, 17037262208, 17045649536, +17054039936, 17062426496, 17070814336, 17079205504, 17087592064, +17095978112, 17104369024, 17112759424, 17121147776, 17129536384, +17137926016, 17146314368, 17154700928, 17163089792, 17171480192, +17179864192, 17188256896, 17196644992, 17205033856, 17213423488, +17221811072, 17230198912, 17238588032, 17246976896, 17255360384, +17263754624, 17272143232, 17280530048, 17288918912, 17297309312, +17305696384, 17314085504, 17322475136, 17330863744, 17339252096, +17347640192, 17356026496, 17364413824, 17372796544, 17381190016, +17389583488, 17397972608, 17406360704, 17414748544, 17423135872, +17431527296, 17439915904, 17448303232, 17456691584, 17465081728, +17473468288, 17481857408, 17490247552, 17498635904, 17507022464, +17515409024, 17523801728, 17532189824, 17540577664, 17548966016, +17557353344, 17565741184, 17574131584, 17582519168, 17590907008, +17599296128, 17607687808, 17616076672, 17624455808, 17632852352, +17641238656, 17649630848, 17658018944, 17666403968, 17674794112, +17683178368, 17691573376, 17699962496, 17708350592, 17716739968, +17725126528, 17733517184, 17741898112, 17750293888, 17758673024, +17767070336, 17775458432, 17783848832, 17792236928, 17800625536, +17809012352, 17817402752, 17825785984, 17834178944, 17842563968, +17850955648, 17859344512, 17867732864, 17876119424, 17884511872, +17892900224, 17901287296, 17909677696, 17918058112, 17926451072, +17934843776, 17943230848, 17951609216, 17960008576, 17968397696, +17976784256, 17985175424, 17993564032, 18001952128, 18010339712, +18018728576, 18027116672, 18035503232, 18043894144, 18052283264, +18060672128, 18069056384, 18077449856, 18085837184, 18094225792, +18102613376, 18111004544, 18119388544, 18127781248, 18136170368, +18144558976, 18152947328, 18161336192, 18169724288, 18178108544, +18186498944, 18194886784, 18203275648, 18211666048, 18220048768, +18228444544, 18236833408, 18245220736] + +cache_sizes = [ +16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072, +17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088, +18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208, +19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968, +20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216, +21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104, +22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096, +23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112, +24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488, +25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096, +25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472, +26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744, +27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504, +28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752, +29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976, +30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248, +31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392, +32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768, +33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992, +34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984, +35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976, +36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656, +36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904, +37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672, +38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632, +39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032, +40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304, +41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912, +42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696, +43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432, +44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448, +45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208, +46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328, +47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936, +47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312, +48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712, +49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472, +50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848, +51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968, +52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576, +53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744, +54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248, +55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856, +56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488, +57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632, +58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984, +58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512, +59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968, +60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752, +61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512, +62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656, +63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392, +64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792, +65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296, +66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672, +67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304, +68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912, +69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184, +69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816, +70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168, +71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568, +72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944, +73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832, +74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544, +75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072, +76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832, +77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336, +78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664, +79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472, +80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848, +81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304, +81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984, +82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464, +83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608, +84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496, +85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112, +86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632, +87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264, +88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384, +89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376, +90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776, +91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384, +92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912, +92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136, +93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896, +94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016, +95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544, +96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536, +97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168, +98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928, +99352384, 99482816, 99614272, 99745472, 99876416, 100007104, +100138048, 100267072, 100401088, 100529984, 100662592, 100791872, +100925248, 101056064, 101187392, 101317952, 101449408, 101580608, +101711296, 101841728, 101973824, 102104896, 102235712, 102366016, +102498112, 102628672, 102760384, 102890432, 103021888, 103153472, +103284032, 103415744, 103545152, 103677248, 103808576, 103939648, +104070976, 104201792, 104332736, 104462528, 104594752, 104725952, +104854592, 104988608, 105118912, 105247808, 105381184, 105511232, +105643072, 105774784, 105903296, 106037056, 106167872, 106298944, +106429504, 106561472, 106691392, 106822592, 106954304, 107085376, +107216576, 107346368, 107478464, 107609792, 107739712, 107872192, +108003136, 108131392, 108265408, 108396224, 108527168, 108657344, +108789568, 108920384, 109049792, 109182272, 109312576, 109444928, +109572928, 109706944, 109837888, 109969088, 110099648, 110230976, +110362432, 110492992, 110624704, 110755264, 110886208, 111017408, +111148864, 111279296, 111410752, 111541952, 111673024, 111803456, +111933632, 112066496, 112196416, 112328512, 112457792, 112590784, +112715968, 112852672, 112983616, 113114944, 113244224, 113376448, +113505472, 113639104, 113770304, 113901376, 114031552, 114163264, +114294592, 114425536, 114556864, 114687424, 114818624, 114948544, +115080512, 115212224, 115343296, 115473472, 115605184, 115736128, +115867072, 115997248, 116128576, 116260288, 116391488, 116522944, +116652992, 116784704, 116915648, 117046208, 117178304, 117308608, +117440192, 117569728, 117701824, 117833024, 117964096, 118094656, +118225984, 118357312, 118489024, 118617536, 118749632, 118882112, +119012416, 119144384, 119275328, 119406016, 119537344, 119668672, +119798464, 119928896, 120061376, 120192832, 120321728, 120454336, +120584512, 120716608, 120848192, 120979136, 121109056, 121241408, +121372352, 121502912, 121634752, 121764416, 121895744, 122027072, +122157632, 122289088, 122421184, 122550592, 122682944, 122813888, +122945344, 123075776, 123207488, 123338048, 123468736, 123600704, +123731264, 123861952, 123993664, 124124608, 124256192, 124386368, +124518208, 124649024, 124778048, 124911296, 125041088, 125173696, +125303744, 125432896, 125566912, 125696576, 125829056, 125958592, +126090304, 126221248, 126352832, 126483776, 126615232, 126746432, +126876608, 127008704, 127139392, 127270336, 127401152, 127532224, +127663552, 127794752, 127925696, 128055232, 128188096, 128319424, +128449856, 128581312, 128712256, 128843584, 128973632, 129103808, +129236288, 129365696, 129498944, 129629888, 129760832, 129892288, +130023104, 130154048, 130283968, 130416448, 130547008, 130678336, +130807616, 130939456, 131071552, 131202112, 131331776, 131464384, +131594048, 131727296, 131858368, 131987392, 132120256, 132250816, +132382528, 132513728, 132644672, 132774976, 132905792, 133038016, +133168832, 133299392, 133429312, 133562048, 133692992, 133823296, +133954624, 134086336, 134217152, 134348608, 134479808, 134607296, +134741056, 134872384, 135002944, 135134144, 135265472, 135396544, +135527872, 135659072, 135787712, 135921472, 136052416, 136182848, +136313792, 136444864, 136576448, 136707904, 136837952, 136970048, +137099584, 137232064, 137363392, 137494208, 137625536, 137755712, +137887424, 138018368, 138149824, 138280256, 138411584, 138539584, +138672832, 138804928, 138936128, 139066688, 139196864, 139328704, +139460032, 139590208, 139721024, 139852864, 139984576, 140115776, +140245696, 140376512, 140508352, 140640064, 140769856, 140902336, +141032768, 141162688, 141294016, 141426496, 141556544, 141687488, +141819584, 141949888, 142080448, 142212544, 142342336, 142474432, +142606144, 142736192, 142868288, 142997824, 143129408, 143258944, +143392448, 143523136, 143653696, 143785024, 143916992, 144045632, +144177856, 144309184, 144440768, 144570688, 144701888, 144832448, +144965056, 145096384, 145227584, 145358656, 145489856, 145620928, +145751488, 145883072, 146011456, 146144704, 146275264, 146407232, +146538176, 146668736, 146800448, 146931392, 147062336, 147193664, +147324224, 147455936, 147586624, 147717056, 147848768, 147979456, +148110784, 148242368, 148373312, 148503232, 148635584, 148766144, +148897088, 149028416, 149159488, 149290688, 149420224, 149551552, +149683136, 149814976, 149943616, 150076352, 150208064, 150338624, +150470464, 150600256, 150732224, 150862784, 150993088, 151125952, +151254976, 151388096, 151519168, 151649728, 151778752, 151911104, +152042944, 152174144, 152304704, 152435648, 152567488, 152698816, +152828992, 152960576, 153091648, 153222976, 153353792, 153484096, +153616192, 153747008, 153878336, 154008256, 154139968, 154270912, +154402624, 154533824, 154663616, 154795712, 154926272, 155057984, +155188928, 155319872, 155450816, 155580608, 155712064, 155843392, +155971136, 156106688, 156237376, 156367424, 156499264, 156630976, +156761536, 156892352, 157024064, 157155008, 157284416, 157415872, +157545536, 157677248, 157810496, 157938112, 158071744, 158203328, +158334656, 158464832, 158596288, 158727616, 158858048, 158988992, +159121216, 159252416, 159381568, 159513152, 159645632, 159776192, +159906496, 160038464, 160169536, 160300352, 160430656, 160563008, +160693952, 160822208, 160956352, 161086784, 161217344, 161349184, +161480512, 161611456, 161742272, 161873216, 162002752, 162135872, +162266432, 162397888, 162529216, 162660032, 162790976, 162922048, +163052096, 163184576, 163314752, 163446592, 163577408, 163707968, +163839296, 163969984, 164100928, 164233024, 164364224, 164494912, +164625856, 164756672, 164887616, 165019072, 165150016, 165280064, +165412672, 165543104, 165674944, 165805888, 165936832, 166067648, +166198336, 166330048, 166461248, 166591552, 166722496, 166854208, +166985408, 167116736, 167246656, 167378368, 167508416, 167641024, +167771584, 167903168, 168034112, 168164032, 168295744, 168427456, +168557632, 168688448, 168819136, 168951616, 169082176, 169213504, +169344832, 169475648, 169605952, 169738048, 169866304, 169999552, +170131264, 170262464, 170393536, 170524352, 170655424, 170782016, +170917696, 171048896, 171179072, 171310784, 171439936, 171573184, +171702976, 171835072, 171966272, 172097216, 172228288, 172359232, +172489664, 172621376, 172747712, 172883264, 173014208, 173144512, +173275072, 173407424, 173539136, 173669696, 173800768, 173931712, +174063424, 174193472, 174325696, 174455744, 174586816, 174718912, +174849728, 174977728, 175109696, 175242688, 175374272, 175504832, +175636288, 175765696, 175898432, 176028992, 176159936, 176291264, +176422592, 176552512, 176684864, 176815424, 176946496, 177076544, +177209152, 177340096, 177470528, 177600704, 177731648, 177864256, +177994816, 178126528, 178257472, 178387648, 178518464, 178650176, +178781888, 178912064, 179044288, 179174848, 179305024, 179436736, +179568448, 179698496, 179830208, 179960512, 180092608, 180223808, +180354752, 180485696, 180617152, 180748096, 180877504, 181009984, +181139264, 181272512, 181402688, 181532608, 181663168, 181795136, +181926592, 182057536, 182190016, 182320192, 182451904, 182582336, +182713792, 182843072, 182976064, 183107264, 183237056, 183368384, +183494848, 183631424, 183762752, 183893824, 184024768, 184154816, +184286656, 184417984, 184548928, 184680128, 184810816, 184941248, +185072704, 185203904, 185335616, 185465408, 185596352, 185727296, +185859904, 185989696, 186121664, 186252992, 186383552, 186514112, +186645952, 186777152, 186907328, 187037504, 187170112, 187301824, +187429184, 187562048, 187693504, 187825472, 187957184, 188087104, +188218304, 188349376, 188481344, 188609728, 188743616, 188874304, +189005248, 189136448, 189265088, 189396544, 189528128, 189660992, +189791936, 189923264, 190054208, 190182848, 190315072, 190447424, +190577984, 190709312, 190840768, 190971328, 191102656, 191233472, +191364032, 191495872, 191626816, 191758016, 191888192, 192020288, +192148928, 192282176, 192413504, 192542528, 192674752, 192805952, +192937792, 193068608, 193198912, 193330496, 193462208, 193592384, +193723456, 193854272, 193985984, 194116672, 194247232, 194379712, +194508352, 194641856, 194772544, 194900672, 195035072, 195166016, +195296704, 195428032, 195558592, 195690304, 195818176, 195952576, +196083392, 196214336, 196345792, 196476736, 196607552, 196739008, +196869952, 197000768, 197130688, 197262784, 197394368, 197523904, +197656384, 197787584, 197916608, 198049472, 198180544, 198310208, +198442432, 198573632, 198705088, 198834368, 198967232, 199097792, +199228352, 199360192, 199491392, 199621696, 199751744, 199883968, +200014016, 200146624, 200276672, 200408128, 200540096, 200671168, +200801984, 200933312, 201062464, 201194944, 201326144, 201457472, +201588544, 201719744, 201850816, 201981632, 202111552, 202244032, +202374464, 202505152, 202636352, 202767808, 202898368, 203030336, +203159872, 203292608, 203423296, 203553472, 203685824, 203816896, +203947712, 204078272, 204208192, 204341056, 204472256, 204603328, +204733888, 204864448, 204996544, 205125568, 205258304, 205388864, +205517632, 205650112, 205782208, 205913536, 206044736, 206176192, +206307008, 206434496, 206569024, 206700224, 206831168, 206961856, +207093056, 207223616, 207355328, 207486784, 207616832, 207749056, +207879104, 208010048, 208141888, 208273216, 208404032, 208534336, +208666048, 208796864, 208927424, 209059264, 209189824, 209321792, +209451584, 209582656, 209715136, 209845568, 209976896, 210106432, +210239296, 210370112, 210501568, 210630976, 210763712, 210894272, +211024832, 211156672, 211287616, 211418176, 211549376, 211679296, +211812032, 211942592, 212074432, 212204864, 212334016, 212467648, +212597824, 212727616, 212860352, 212991424, 213120832, 213253952, +213385024, 213515584, 213645632, 213777728, 213909184, 214040128, +214170688, 214302656, 214433728, 214564544, 214695232, 214826048, +214956992, 215089088, 215219776, 215350592, 215482304, 215613248, +215743552, 215874752, 216005312, 216137024, 216267328, 216399296, +216530752, 216661696, 216790592, 216923968, 217054528, 217183168, +217316672, 217448128, 217579072, 217709504, 217838912, 217972672, +218102848, 218233024, 218364736, 218496832, 218627776, 218759104, +218888896, 219021248, 219151936, 219281728, 219413056, 219545024, +219675968, 219807296, 219938624, 220069312, 220200128, 220331456, +220461632, 220592704, 220725184, 220855744, 220987072, 221117888, +221249216, 221378368, 221510336, 221642048, 221772736, 221904832, +222031808, 222166976, 222297536, 222428992, 222559936, 222690368, +222820672, 222953152, 223083968, 223213376, 223345984, 223476928, +223608512, 223738688, 223869376, 224001472, 224132672, 224262848, +224394944, 224524864, 224657344, 224788288, 224919488, 225050432, +225181504, 225312704, 225443776, 225574592, 225704768, 225834176, +225966784, 226097216, 226229824, 226360384, 226491712, 226623424, +226754368, 226885312, 227015104, 227147456, 227278528, 227409472, +227539904, 227669696, 227802944, 227932352, 228065216, 228196288, +228326464, 228457792, 228588736, 228720064, 228850112, 228981056, +229113152, 229243328, 229375936, 229505344, 229636928, 229769152, +229894976, 230030272, 230162368, 230292416, 230424512, 230553152, +230684864, 230816704, 230948416, 231079616, 231210944, 231342016, +231472448, 231603776, 231733952, 231866176, 231996736, 232127296, +232259392, 232388672, 232521664, 232652608, 232782272, 232914496, +233043904, 233175616, 233306816, 233438528, 233569984, 233699776, +233830592, 233962688, 234092224, 234221888, 234353984, 234485312, +234618304, 234749888, 234880832, 235011776, 235142464, 235274048, +235403456, 235535936, 235667392, 235797568, 235928768, 236057152, +236190272, 236322752, 236453312, 236583616, 236715712, 236846528, +236976448, 237108544, 237239104, 237371072, 237501632, 237630784, +237764416, 237895232, 238026688, 238157632, 238286912, 238419392, +238548032, 238681024, 238812608, 238941632, 239075008, 239206336, +239335232, 239466944, 239599168, 239730496, 239861312, 239992384, +240122816, 240254656, 240385856, 240516928, 240647872, 240779072, +240909632, 241040704, 241171904, 241302848, 241433408, 241565248, +241696192, 241825984, 241958848, 242088256, 242220224, 242352064, +242481856, 242611648, 242744896, 242876224, 243005632, 243138496, +243268672, 243400384, 243531712, 243662656, 243793856, 243924544, +244054592, 244187072, 244316608, 244448704, 244580032, 244710976, +244841536, 244972864, 245104448, 245233984, 245365312, 245497792, +245628736, 245759936, 245889856, 246021056, 246152512, 246284224, +246415168, 246545344, 246675904, 246808384, 246939584, 247070144, +247199552, 247331648, 247463872, 247593536, 247726016, 247857088, +247987648, 248116928, 248249536, 248380736, 248512064, 248643008, +248773312, 248901056, 249036608, 249167552, 249298624, 249429184, +249560512, 249692096, 249822784, 249954112, 250085312, 250215488, +250345792, 250478528, 250608704, 250739264, 250870976, 251002816, +251133632, 251263552, 251395136, 251523904, 251657792, 251789248, +251919424, 252051392, 252182464, 252313408, 252444224, 252575552, +252706624, 252836032, 252968512, 253099712, 253227584, 253361728, +253493056, 253623488, 253754432, 253885504, 254017216, 254148032, +254279488, 254410432, 254541376, 254672576, 254803264, 254933824, +255065792, 255196736, 255326528, 255458752, 255589952, 255721408, +255851072, 255983296, 256114624, 256244416, 256374208, 256507712, +256636096, 256768832, 256900544, 257031616, 257162176, 257294272, +257424448, 257555776, 257686976, 257818432, 257949632, 258079552, +258211136, 258342464, 258473408, 258603712, 258734656, 258867008, +258996544, 259127744, 259260224, 259391296, 259522112, 259651904, +259784384, 259915328, 260045888, 260175424, 260308544, 260438336, +260570944, 260700992, 260832448, 260963776, 261092672, 261226304, +261356864, 261487936, 261619648, 261750592, 261879872, 262011968, +262143424, 262274752, 262404416, 262537024, 262667968, 262799296, +262928704, 263061184, 263191744, 263322944, 263454656, 263585216, +263716672, 263847872, 263978944, 264108608, 264241088, 264371648, +264501184, 264632768, 264764096, 264895936, 265024576, 265158464, +265287488, 265418432, 265550528, 265681216, 265813312, 265943488, +266075968, 266206144, 266337728, 266468032, 266600384, 266731072, +266862272, 266993344, 267124288, 267255616, 267386432, 267516992, +267648704, 267777728, 267910592, 268040512, 268172096, 268302784, +268435264, 268566208, 268696256, 268828096, 268959296, 269090368, +269221312, 269352256, 269482688, 269614784, 269745856, 269876416, +270007616, 270139328, 270270272, 270401216, 270531904, 270663616, +270791744, 270924736, 271056832, 271186112, 271317184, 271449536, +271580992, 271711936, 271843136, 271973056, 272105408, 272236352, +272367296, 272498368, 272629568, 272759488, 272891456, 273022784, +273153856, 273284672, 273415616, 273547072, 273677632, 273808448, +273937088, 274071488, 274200896, 274332992, 274463296, 274595392, +274726208, 274857536, 274988992, 275118656, 275250496, 275382208, +275513024, 275643968, 275775296, 275906368, 276037184, 276167872, +276297664, 276429376, 276560576, 276692672, 276822976, 276955072, +277085632, 277216832, 277347008, 277478848, 277609664, 277740992, +277868608, 278002624, 278134336, 278265536, 278395328, 278526784, +278657728, 278789824, 278921152, 279052096, 279182912, 279313088, +279443776, 279576256, 279706048, 279838528, 279969728, 280099648, +280230976, 280361408, 280493632, 280622528, 280755392, 280887104, +281018176, 281147968, 281278912, 281411392, 281542592, 281673152, +281803712, 281935552, 282066496, 282197312, 282329024, 282458816, +282590272, 282720832, 282853184, 282983744, 283115072, 283246144, +283377344, 283508416, 283639744, 283770304, 283901504, 284032576, +284163136, 284294848, 284426176, 284556992, 284687296, 284819264, +284950208, 285081536] +``` diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" new file mode 100644 index 00000000000..3767d2f369c --- /dev/null +++ "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" @@ -0,0 +1,37 @@ +--- +title: Bányászati algoritmusok +description: Az Ethereum-bányászat algoritmusainak bemutatása. +lang: hu +--- + + +A proof-of-work (munkaigazolás) már nem az Ethereum konszenzusmechanizmus alapja, tehát a bányászatot kikapcsolták. Ehelyett az Ethereumot úgy biztosítják a validátorok, hogy letétbe helyeznek ETH-t. Ön is letétbe helyezheti a rendelkezésére álló ETH-t. Tudjon meg többet a egyesítés (Merge), proof-of-stake (letéti igazolás) és letétbe helyezés témákról. Ez az oldal csak elavult témákat tartalmaz. + + +Az Ethereum-bányászat egy Ethash nevű algoritmust használt. k az algoritmusnak az a lényege, hogy a bányász megpróbál egy nonce értéket találni nagy számítási kapacitás révén, hogy a létrejövő hash kisebb legyen, mint a kiszámolt nehézség határértéke. Ez a nehézségi szint dinamikusan változtatható, így a blokkok létrehozása rendszeresen meg tud történni. + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértéséhez javasoljuk, hogy előbb tekintse meg a [proof-of-work konszenzusról](/developers/docs/consensus-mechanisms/pow) és a [bányászatról](/developers/docs/consensus-mechanisms/pow/mining) szóló oldalakat. + +## Dagger Hashimoto {#dagger-hashimoto} + +A Dagger Hashimoto az Ethereum-bányászat korábbi algoritmusa volt a fejlesztés idején, melyet az Ethash váltott le. Ez két különböző algoritmus, a Dagger és a Hashimoto, összeolvadása volt. Ezt a fejlesztés idején használták, és az Ethereum főhálózat bevezetésekor már az Ethash működött. + +A [Dagger](http://www.hashcash.org/papers/dagger.html) bevezette az [irányított aciklikus gráf (Directed Acyclic Graph)](https://en.wikipedia.org/wiki/Directed_acyclic_graph) generációját, melyeknek véletlenszerű szeleteit hashelik össze. A lényegi elve az, hogy a nonce a nagy adatfából csak egy kis részt igényel. A bányászatnál nem lehet újrakalkulálni a nonce-hoz az alfát – tehát tárolni kell a fát –, de az egy nonce értékű ellenőrzésnél ez rendben van. A Dagger a létező algoritmusok, mint a Scrypt, alternatívája volt, ami sok memóriát igényelt (memory hard), de nehéz volt ellenőrizni, hogy a memóriahasználat mikor éri el a valóban biztonságos szintet. A Dagger ugyanakkor sebezhető volt a megosztott memóriaalapú hardver-gyorsítás esetén, ezért a kutatás során elvetették. + +A [Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) egy olyan algoritmus, amely ASIC-ellenállást biztosít az I/O bound révén (mivel a memóriaolvasások a bányászat behatároló tényezői). A lényeg az, hogy a RAM elérhetőbb, mint a számítási kapacitás; sok milliárd dollárnyi kutatás már optimalizálta a RAM használatot különféle esetekre, ami gyakran szinte véletlenszerű elérési mintákat (tehát a véletlenszerű memóriaelérést is) foglal magában. Ennek eredményeként a meglévő RAM elég közel van az optimálishoz, hogy értékelje az algoritmust. A Hashimoto a blokkláncot adatforrásnak használta, így megfelelt a fenti (1) és (3) pontoknak. + +A Dagger-Hashimoto a Dagger és a Hashimoto algoritmusok módosított változatát használta. A Dagger-Hashimoto és a Hashimoto között az a különbség, hogy nem blokkláncot használ adatforrásként, hanem egy személyre szabott adathalmazt, amely a blokkadatokból frissül minden N-edik blokknál. Az adathalmaz a Dagger-algoritmussal készült, amellyel hatékonyan lehetett minden nonce-ra egy alhalmazt kikalkulálni a könnyű kliens ellenőrzéshez. A Dagger-Hashimoto és a Dagger közötti különbség az, hogy a blokklekérdezéshez használt adathalmaz félig állandó, és esetileg frissítik (például hetente). Így az adathalmaz létrehozásának erőfeszítése nullához közelít, így a megosztott memória felgyorsításával kapcsolatos problémák (lásd Sergio Lerner) elhanyagolhatóvá váltak. + +Bővebben a [Dagger-Hashimoto algoritmusról](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). + +## Ethash {#ethash} + +Az Ethash az a bányászati algoritmus, melyet az Ethereum főhálózaton használtak a ma már kivezetett proof-of-work architektúrában. Az Ethash az új neve a Dagger-Hashimoto egy specifikus verziójának, mivel azt jelentősen megváltoztatták, de mégis megmaradtak az alapvető elvei az elődjének. Az Ethereum-főhálózat csak az Ethasht használta, mivel a Dagger-Hashimoto a kutatás-fejlesztés idején működött, és még a bányászat megkezdése előtt lecserélték. + +[Bővebben az Ethash-ről](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash). + +## További olvasnivaló {#further-reading} + +_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" new file mode 100644 index 00000000000..31dc9b44563 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" @@ -0,0 +1,207 @@ +--- +title: Backend API könyvtárak +description: Bevezetés az Ethereum kliens API-okba, melyek lehetővé teszik, hogy interakcióba lépj a blokklánccal az alkalmazásodban. +lang: hu +--- + +Ahhoz, hogy egy szoftver alkalmazás interakcióba lépjen az Ethereum blokklánccal (vagyis képes legyen blokklánc adatok olvasására és/vagy tranzakció küldésre a hálózatra), rá kell csatlakoznia egy Ethereum csomópontra. + +Erre a célra minden Ethereum-kliens implementálja a [JSON-RPC](/developers/docs/apis/json-rpc/) specifikációt, így egységes [metódusok](/developers/docs/apis/json-rpc/#json-rpc-methods) állnak rendelkezésre, amelyekre az alkalmazások támaszkodhatnak. + +Ha egy bizonyos programnyelvet szeretne használni, hogy kapcsolódjon egy Ethereum csomóponttal, akkor számos könyvtár létezik az ökoszisztémán belül, melyek megkönnyítik ezt. Ezekkel a könyvtárakkal a fejlesztők intuitív, egysoros metódusokat írhatnak, hogy kezdeményezzenek egy JSON RPC kérést (a háttérben), mely interakcióba lép az Ethereummal. + +## Előfeltételek {#prerequisites} + +Érdemes lehet előbb alaposan megismerni az [Ethereum stacket](/developers/docs/ethereum-stack/) és az [Ethereum-klienseket](/developers/docs/nodes-and-clients/). + +## Miért használj egy könyvtárat? {#why-use-a-library} + +Ezek a könyvtárak elveszik a komplexitás nagy részét, mely Ethereum csomóponthoz történő közvetlen csatlakozással jár. Ezenkívül használati függvényeket is szolgáltatnak (pl.: ETH konvertálása Gwei-be), így fejlesztőként kevesebb időt kell az Ethereum kliensek bonyodalmaival foglalkoznod és több időd jut egyedi funkcionalitást kialakítani az alkalmazásodnak. + +## Elérhető könyvtárak {#available-libraries} + +### Infrastruktúra és csomóponti szolgáltatások {#infrastructure-and-node-services} + +**Alchemy -** **_Ethereum Fejlesztési Platform._** + +- [alchemy.com](https://www.alchemy.com/) +- [Dokumentáció](https://docs.alchemy.com/) +- [GitHub](https://github.com/alchemyplatform) +- [Discord](https://discord.com/invite/alchemyplatform) + +**All That Node -** **_Csomópont mint szolgáltatás._** + +- [All That Node.com](https://www.allthatnode.com/) +- [Dokumentáció](https://docs.allthatnode.com) +- [Discord](https://discord.gg/GmcdVEUbJM) + +**Blast by Bware Labs -** **_Decentralizált API-k az Ethereum főhálózatra és teszthálózatokra._** + +- [blastapi.io](https://blastapi.io/) +- [Dokumentáció](https://docs.blastapi.io) +- [Discord](https://discord.gg/bwarelabs) + +**BlockPi -** **_Hatékonyabb és gyorsabb RPC-szolgáltatások_** + +- [blockpi.io](https://blockpi.io/) +- [Dokumentáció](https://docs.blockpi.io/) +- [GitHub](https://github.com/BlockPILabs) +- [Discord](https://discord.com/invite/xTvGVrGVZv) + +**Cloudflare Ethereum Gateway.** + +- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/) + +**Etherscan - Blokkfelfedező és tranzakciós API-ok** +- [Dokumentáció](https://docs.etherscan.io/) + +**GetBlock-** **_Blokklánc mint szolgáltatás a Web3 fejlesztéshez_** + +- [GetBlock.io](https://getblock.io/) +- [Dokumentáció](https://getblock.io/docs/) + +**Infura -** **_Az Ethereum API, mint szolgáltatás._** + +- [infura.io](https://infura.io) +- [Dokumentáció](https://docs.infura.io/api) +- [GitHub](https://github.com/INFURA) + +**Node RPC - _Költséghatékony EVM JSON-RPC szolgáltató_** + +- [noderpc.xyz](https://www.noderpc.xyz/) +- [Dokumentáció](https://docs.noderpc.xyz/node-rpc) + +**NOWNodes – _Teljes csomópontok és blokkfelfedezők._** + +- [NOWNodes.io](https://nownodes.io/) +- [Dokumentáció](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro) + +**QuickNode -** **_Blokklánc-infrastruktúra mint szolgáltatás._** + +- [quicknode.com](https://quicknode.com) +- [Dokumentáció](https://www.quicknode.com/docs/welcome) +- [Discord](https://discord.gg/quicknode) + +**Rivet -** **_Ethereum és Ethereum Classic API-k mint szolgáltatás, amelyeket nyílt forráskódú szoftver működtet._** + +- [rivet.cloud](https://rivet.cloud) +- [Dokumentáció](https://rivet.cloud/docs/) +- [GitHub](https://github.com/openrelayxyz/ethercattle-deployment) + +**Zmok -** **_Sebességorientált Ethereum-csomópontok mint JSON-RPC/WebSockets API._** + +- [zmok.io](https://zmok.io/) +- [GitHub](https://github.com/zmok-io) +- [Dokumentáció](https://docs.zmok.io/) +- [Discord](https://discord.gg/fAHeh3ka6s) + +### Fejlesztőeszközök {#development-tools} + +ethers-kt – **_Async, nagy teljesítményű Kotlin/Java/Android könyvtár EVM-alapú blokkláncokhoz._** + +- [GitHub](https://github.com/Kr1ptal/ethers-kt) +- [Példák](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) +- [Discord](https://discord.gg/rx35NzQGSb) + +**Nethereum -** **_Egy nyílt forráskódú .NET integrációs könyvtár blokkláncoknak._** + +- [GitHub](https://github.com/Nethereum/Nethereum) +- [Dokumentáció](http://docs.nethereum.com/en/latest/) +- [Discord](https://discord.com/invite/jQPrR58FxX) + +**Python Tooling -** **_Különféle Ethereum-könyvtárak Python-nal való interakciókhoz_** + +- [py.ethereum.org](https://python.ethereum.org/) +- [web3.py GitHub](https://github.com/ethereum/web3.py) +- [web3.py Chat](https://gitter.im/ethereum/web3.py) + +**Tatum -** **_A végső blokklánc-fejlesztési platform._** + +- [Tatum](https://tatum.io/) +- [GitHub](https://github.com/tatumio/) +- [Dokumentáció](https://docs.tatum.io/) +- [Discord](https://discord.gg/EDmW3kjTC9) + +**web3j -** **_Java/Android/Kotlin/Scala integrációs könyvtár Ethereumra._** + +- [GitHub](https://github.com/web3j/web3j) +- [Dokumentáció](https://docs.web3j.io/) +- [Gitter](https://gitter.im/web3j/web3j) + +### Blockchain-szolgáltatások {#blockchain-services} + +**BlockCypher -** **_Ethereum Web API-k._** + +- [blockcypher.com](https://www.blockcypher.com/) +- [Dokumentáció](https://www.blockcypher.com/dev/ethereum/) + +**Chainbase -** **_Teljes web3-adatinfrastruktúra az Ethereumra._** + +- [chainbase.com](https://chainbase.com/) +- [Dokumentáció](https://docs.chainbase.com/) +- [Discord](https://discord.gg/Wx6qpqz4AF) + +**Chainstack -** **_Osztott és dedikált Ethereum-csomópontok mint szolgáltatás._** + +- [chainstack.com](https://chainstack.com) +- [Dokumentáció](https://docs.chainbase.com/docs) +- [Ethereum API reference](https://docs.chainstack.com/reference/ethereum-getting-started) + +**Coinbase Cloud Node -** **_Blokklánc-infrastruktúra API._** + +- [Coinbase Cloud Node](https://www.coinbase.com/cloud) +- [Dokumentáció](https://docs.cloud.coinbase.com/) + +**DataHub by Figment -** **_Web3 API szolgáltatások az Ethereum főhálózattal és teszthálózatokkal._** + +- [DataHub](https://www.figment.io/) +- [Dokumentáció](https://docs.figment.io/) + +**Moralis -** **_Vállalati szintű EVM API-szolgáltató._** + +- [moralis.io](https://moralis.io) +- [Dokumentáció](https://docs.moralis.io/) +- [GitHub](https://github.com/MoralisWeb3) +- [Discord](https://moralis.io/joindiscord/) +- [Fórum](https://forum.moralis.io/) + +**NFTPort -** **_Ethereum-adatok és Mint API-k._** + +- [nftport.xyz](https://www.nftport.xyz/) +- [Dokumentáció](https://docs.nftport.xyz/) +- [GitHub](https://github.com/nftport/) +- [Discord](https://discord.com/invite/K8nNrEgqhE) + +**Tokenview -** **_Az általános multikripto blokklánc API-k platformja._** + +- [services.tokenview.io](https://services.tokenview.io/) +- [Dokumentáció](https://services.tokenview.io/docs?type=api) +- [GitHub](https://github.com/Tokenview) + +**Watchdata -** **_Egyszerű és megbízható API-hozzáférés az Ethereum-blokklánchoz._** + +- [Watchdata](https://watchdata.io/) +- [Dokumentáció](https://docs.watchdata.io/) +- [Discord](https://discord.com/invite/TZRJbZ6bdn) + +**Covalent –** **_Gazdagított blokklánc API-ok 200+ lánchoz._** + +- [covalenthq.com](https://www.covalenthq.com/) +- [Dokumentáció](https://www.covalenthq.com/docs/api/) +- [GitHub](https://github.com/covalenthq) +- [Discord](https://www.covalenthq.com/discord/) + + +## További olvasnivaló {#further-reading} + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) +- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) + +## Kapcsolódó útmutatók {#related-tutorials} + +- [Web3js beállítása az Ethereum-blokklánc használatához JavaScriptben](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Útmutató a web3.js projektben való beállításához.._ +- [Okosszerződés hívása JavaScriptből](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– A DAI token használatával tekintse meg, hogyan hívhat be szerződéseket a JavaScript segítségével._ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" new file mode 100644 index 00000000000..8356791c6f7 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" @@ -0,0 +1,295 @@ +--- +title: JavaScript API könyvtárak +description: Bevezetés az JavaScript kliens könyvtárakba, melyek lehetővé teszik, hogy interakcióba lépj a blokklánccal az alkalmazásodban. +lang: hu +--- + +Ahhoz, hogy egy web alkalmazás interakcióba lépjen az Ethereum blokklánccal (vagyis képes legyen blokklánc adatok olvasására és/vagy tranzakció küldésre a hálózatra), rá kell csatlakoznia egy Ethereum csomópontra. + +Erre a célra minden Ethereum-kliens implementálja a [JSON-RPC](/developers/docs/apis/json-rpc/) specifikációt, így egységes [módszerek](/developers/docs/apis/json-rpc/#json-rpc-methods) állnak rendelkezésre, amelyekre az alkalmazások támaszkodhatnak. + +Ha JavaScript programnyelvet szeretne használni, hogy kapcsolódjon egy Ethereum csomóponthoz, lehetősége van vanilla JavaScriptet használni, de számos könyvtár létezik az ökoszisztémán belül, melyek megkönnyítik ezt. Ezekkel a könyvtárakkal a fejlesztők intuitív, egysoros metódusokat írhatnak, hogy kezdeményezzenek egy JSON RPC kérést (a háttérben), mely interakcióba lép az Ethereummal. + +Az [egyesítés (Merge)](/roadmap/merge/) után, az Ethereum szoftver két kapcsolódó darabja – egy végrehajtó kliens és egy konszenzus kliens – kell a csomópont futtatásához. Gondoskodjon arról, hogy a csomópont mindkét kliens benne legyen. Ha a csomópont nem a helyi gépen van (pl. egy AWS-en fut), akkor az IP-címet frissíteni kell az útmutatóban. Bővebb információért érdemes felkeresni a [csomópont futtatása](/developers/docs/nodes-and-clients/run-a-node/) oldalt. + +## Előfeltételek {#prerequisites} + +A JavaScript megértése mellett lehet érdemes lehet előbb alaposan megismerni az [Ethereum stacket](/developers/docs/ethereum-stack/) és az [Ethereum-klienseket](/developers/docs/nodes-and-clients/). + +## Miért használj könyvtárat? {#why-use-a-library} + +Ezek a könyvtárak elveszik a komplexitás nagy részét, mely Ethereum csomóponthoz történő közvetlen csatlakozással jár. Ezen kívül használati függvényeket is szolgáltatnak (pl.: ETH konvertálása Gwei-be), így fejlesztőként kevesebb időt kell az Ethereum kliensek bonyodalmaival foglalkoznod és több időd jut egyedi funkcionalitást kialakítani az alkalmazásodnak. + +## Könyvtár tulajdonságok {#library-features} + +### Csatlakozás Ethereum csomóponthoz {#connect-to-ethereum-nodes} + +Szolgáltatók használatakor ezen könyvtárak használatával rácsatlakozhat az Ethereumra és kiolvashatja az adatait, függetlenül attól, hogy JSON-RPC, INFURA, Etherscan, Alchemy vagy MetaMask rendszeren keresztül történik. + +**Példa az Ethers-re** + +```js +// Egy BrowserProvider bewrappol egy standard Web3 szolgáltatót, ez az +// amit a MetaMask beinjektál minden oldalra úgy mint, window.ethereum +const provider = new ethers.BrowserProvider(window.ethereum) + +// A MetaMask plugin továbbá lehetővé teszi tranzakciók aláírását +// ether küldésekor és hogy kifizessük az állapotváltást a blokkláncon. +// Ehhez kell egy számla aláíró (account signer)... +const signer = provider.getSigner() +``` + +**Példa a Web3js-re** + +```js +var web3 = new Web3("http://localhost:8545") +// vagy +var web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545")) + +// szolgáltató (provider) váltás +web3.setProvider("ws://localhost:8546") +// vagy +web3.setProvider(new Web3.providers.WebsocketProvider("ws://localhost:8546")) + +// IPC provider használata a node.js-ben +var net = require("net") +var web3 = new Web3("/Users/myuser/Library/Ethereum/geth.ipc", net) // mac os path +// vagy +var web3 = new Web3( + new Web3.providers.IpcProvider("/Users/myuser/Library/Ethereum/geth.ipc", net) +) // mac os elérési út +// windows rendszerben az elérési út: "\\\\.\\pipe\\geth.ipc" +// linux rendszerben az elérési út: "/users/myuser/.ethereum/geth.ipc" +``` + +Amint be van állítva, lekérdezéseket indíthat a blokkláncon a következőkre: + +- blokkszámok +- gas becslések +- okosszerződés események (events) +- hálózati azonosító +- és még sok mást... + +### Tárca funkcionalitás {#wallet-functionality} + +Ezek a könyvtárak funkcionalitást adnak, hogy tárcákat hozzon létre, kulcsokat kezeljen és tranzakciókat írjon alá. + +Íme egy példa az Ethers-re + +```js +//Tárca instance létrehozása emlékeztető erősítőből... +mnemonic = + "announce room limb pattern dry unit scale effort smooth jazz weasel alcohol" +walletMnemonic = Wallet.fromPhrase(mnemonic) + +// ...or from a private key +walletPrivateKey = new Wallet(walletMnemonic.privateKey) + +walletMnemonic.address === walletPrivateKey.address +// true + +// The address as a Promise per the Signer API +walletMnemonic.getAddress() +// { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' } + +// A Wallet address is also available synchronously +walletMnemonic.address +// '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' + +// The internal cryptographic components +walletMnemonic.privateKey +// '0x1da6847600b0ee25e9ad9a52abbd786dd2502fa4005dd5af9310b7cc7a3b25db' +walletMnemonic.publicKey +// '0x04b9e72dfd423bcf95b3801ac93f4392be5ff22143f9980eb78b3a860c4843bfd04829ae61cdba4b3b1978ac5fc64f5cc2f4350e35a108a9c9a92a81200a60cd64' + +// The wallet mnemonic +walletMnemonic.mnemonic +// { +// locale: 'en', +// path: 'm/44\'/60\'/0\'/0/0', +// phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol' +// } + +// Note: A wallet created with a private key does not +// have a mnemonic (the derivation prevents it) +walletPrivateKey.mnemonic +// null + +// Signing a message +walletMnemonic.signMessage("Hello World") +// { Promise: '0x14280e5885a19f60e536de50097e96e3738c7acae4e9e62d67272d794b8127d31c03d9cd59781d4ee31fb4e1b893bd9b020ec67dfa65cfb51e2bdadbb1de26d91c' } + +tx = { + to: "0x8ba1f109551bD432803012645Ac136ddd64DBA72", + value: utils.parseEther("1.0"), +} + +// Signing a transaction +walletMnemonic.signTransaction(tx) +// { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' } + +// The connect method returns a new instance of the +// Wallet connected to a provider +wallet = walletMnemonic.connect(provider) + +// Querying the network +wallet.getBalance() +// { Promise: { BigNumber: "42" } } +wallet.getTransactionCount() +// { Promise: 0 } + +// Sending ether +wallet.sendTransaction(tx) +``` + +[Olvassa el a teljes dokumentációt](https://docs.ethers.io/v5/api/signer/#Wallet) + +Amint be van állítva, a következőket teheti: + +- számlákat létrehozni +- tranzakciókat küldeni +- tranzakciókat aláírni +- és még sok mást... + +### Interakció okosszerződés függvényekkel {#interact-with-smart-contract-functions} + +A Javascript-kliens könyvtárai lehetővé teszik az alkalmazás számára, hogy okosszerződés-függvényeket hívjanak meg egy befordított szerződés Application Binary Interface-ének (ABI) olvasásával. + +Az ABI lényegében elmagyarázza a szerződés függvényeit egy JSON formátumban és lehetővé teszi, hogy normális Javascript-objektumként használja. + +A következő Solidity szerződés tehát: + +```solidity +contract Test { + uint a; + address d = 0x12345678901234567890123456789012; + + function Test(uint testInt) { a = testInt;} + + event Event(uint indexed b, bytes32 c); + + event Event2(uint indexed b, bytes32 c); + + function foo(uint b, bytes32 c) returns(address) { + Event(b, c); + return d; + } +} +``` + +A következő JSON-t adná: + +```json +[{ + "type":"constructor", + "payable":false, + "stateMutability":"nonpayable" + "inputs":[{"name":"testInt","type":"uint256"}], + },{ + "type":"function", + "name":"foo", + "constant":false, + "payable":false, + "stateMutability":"nonpayable", + "inputs":[{"name":"b","type":"uint256"}, {"name":"c","type":"bytes32"}], + "outputs":[{"name":"","type":"address"}] + },{ + "type":"event", + "name":"Event", + "inputs":[{"indexed":true,"name":"b","type":"uint256"}, {"indexed":false,"name":"c","type":"bytes32"}], + "anonymous":false + },{ + "type":"event", + "name":"Event2", + "inputs":[{"indexed":true,"name":"b","type":"uint256"},{"indexed":false,"name":"c","type":"bytes32"}], + "anonymous":false +}] +``` + +Ez azt jelenti, hogy: + +- Tranzakciókat küldhetsz az okosszerződésnek és végrehajthatod a metódusát +- Megbecsülheted a gast, melyet egy metódus végrehajtás fog használni, amikor lefut az EVM-en +- Telepíthetsz egy szerződést +- És még sok mást... + +### Használati függvények {#utility-functions} + +A használati függvények praktikus könnyítéseke adnak, hogy egyszerűbb legyen az Ethereumon való építés. + +Az ETH értékei alapvetően Wei-ben vannak megadva. 1 ETH = 1,000,000,000,000,000,000 WEI – ez azt jelenti, hogy sok számmal kell foglalkoznia! `web3.utils.toWei` átkonvertálja az ethert Wei-re. + +Az ethers-ben így néz ki: + +```js +// Egy számla egyenlege (cím vagy ENS név alapján) +balance = await provider.getBalance("ethers.eth") +// { BigNumber: "2337132817842795605" } + +// Gyakran formáznod kell a kimenetet a felhasználó számára +// aki etherben szeretné látni az értéket (wei helyett) +ethers.utils.formatEther(balance) +// '2.337132817842795605' +``` + +- [Web3js használati függvények](https://docs.web3js.org/api/web3-utils) +- [Ethers használati függvények](https://docs.ethers.io/v5/api/utils/) + +## Elérhető könyvtárak {#available-libraries} + +**Web3.js -** **_Ethereum JavaScript API._** + +- [Dokumentáció](https://docs.web3js.org/) +- [GitHub](https://github.com/ethereum/web3.js/) + +**Ethers.js -** **_Teljes Ethereum-tárcaimplementáció és segédprogramok JavaScript-ben és TypeScript-ben._** + +- [Dokumentáció](https://docs.ethers.io/) +- [GitHub](https://github.com/ethers-io/ethers.js/) + +**The Graph -** **_Egy Ethereum- és IPFS-adatindexelési és -lekérdezési protokoll a GraphQL használatával._** + +- [The Graph](https://thegraph.com/) +- [Graph Explorer](https://thegraph.com/explorer/) +- [Dokumentáció](https://thegraph.com/docs/) +- [GitHub](https://github.com/graphprotocol/) +- [Discord](https://thegraph.com/discord) + +**light.js -** **_Egy magas szintű, reaktív JS könyvtár könnyű kliensekre optimalizálva._** + +- [GitHub](https://github.com/openethereum/js-libs/tree/master/packages/light.js) + +**Web3-wrapper -** **_A Typescript Web3.js alternatíva._** + +- [Dokumentáció](https://0x.org/docs/web3-wrapper#introduction) +- [GitHub](https://github.com/0xProject/0x-monorepo/tree/development/packages/web3-wrapper) + +**Alchemyweb3 -** **_Egy Web3.js wrapper automatikus újrapróbálkozásokkal és továbbfejlesztett API-kkal._** + +- [Dokumentáció](https://docs.alchemy.com/reference/api-overview) +- [GitHub](https://github.com/alchemyplatform/alchemy-web3) + +**Alchemy NFT API -** **_API az NFT adat megszerzésére, beleértve a tulajdonjogot, metaadatok attribútumait stb._** + +- [Dokumentáció](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) +- [GitHub](https://github.com/alchemyplatform/alchemy-web3) + +**viem -** **_TypeScript-interfész az Ethereumra._** + +- [Dokumentáció](https://viem.sh) +- [GitHub](https://github.com/wagmi-dev/viem) + +## További olvasnivaló {#further-reading} + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) +- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) + +## Kapcsolódó útmutatók {#related-tutorials} + +- [Web3js beállítása az Ethereum-blokklánc használatához JavaScriptben](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Útmutató a web3.js projektben való beállításához.._ +- [Okosszerződés hívása JavaScriptből](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– A DAI token használatával tekintse meg, hogyan hívhat be szerződéseket a JavaScript segítségével._ +- [Tranzakció küldése web3-mal és Alchemy-vel](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– Egy részletes útmutató arról, hogyan lehet tranzakciókat küldeni a backendből._ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" new file mode 100644 index 00000000000..e0da2db6df4 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" @@ -0,0 +1,1773 @@ +--- +title: JSON-RPC API +description: Egy státuszmentes, könnyű remote procedure call (RPC) protokoll az Ethereum-kliensekhez. +lang: hu +--- + +Ahhoz, hogy egy szoftveralkalmazás interakcióba lépjen az Ethereum blokklánccal –a blokkláncadatokat olvasva vagy tranzakciókat küldve a hálózatra –, rá kell csatlakoznia egy Ethereum-csomópontra. + +Ebből a célból minden [Ethereum-kliens](/developers/docs/nodes-and-clients/#execution-clients) implementálja a [JSON-RPC specifikációt](https://github.com/ethereum/execution-apis), így az alkalmazások egységesen egyféle metóduscsomagra támaszkodhatnak, függetlenül az adott csomópont vagy kliens fajtájától. + +A [JSON-RPC](https://www.jsonrpc.org/specification) egy státuszmentes, könnyű remote procedure call (RPC) protokoll. Számos adatstruktúrát, valamint ezek feldolgozásának szabályait is meghatározza. Ez a megoldás nem függ az átadási módoktól, mivel a koncepciókat használni lehet ugyanabban a folyamatban, socketeknél, HTTP-vel és számos más üzenetküldő környezetben. Az adatformátum JSON (RFC 4627). + +## Kliensimplementációk {#client-implementations} + +Az Ethereum-kliensek mindegyike használhat különböző programozási nyelveket, amikor a JSON-RPC specifikációt implementálja. Tekintse meg az egyéni [kliensdokumentációt](/developers/docs/nodes-and-clients/#execution-clients) további részletekért a specifikus programozási nyelvekről. Érdemes megnézni a kliensdokumentációt a legutóbbi API-támogatási információ miatt is. + +## Kényelmi könyvtárak {#convenience-libraries} + +Választhatja, hogy az Ethereum-kliensekkel közvetlenül kapcsolódik a JSON-RPC API révén, de az alkalmazásfejlesztők rendelkezésére állnak egyszerűbb opciók is. Számos [JavaScript](/developers/docs/apis/javascript/#available-libraries) és [backend API](/developers/docs/apis/backend/#available-libraries) könyvtár létezik, hogy a JSON-RPC API tetejére egy wrappert (burkoló réteget) adjon. Ezekkel a könyvtárakkal a fejlesztők intuitív, egysoros metódusokat írhatnak, hogy JSON-RPC-kérést kezdeményezzenek (a háttérben), amely interakcióba lép az Ethereummal. + +## Konszenzusos kliens API-k {#consensus-clients} + +Ez az írás főleg a JSON-RPC API-val foglalkozik, melyet az Ethereum végrehajtási kliensei használnak. Ugyanakkor a konszenzusos klienseknek is van egy RPC API-ja, amellyel a felhasználók lekérhetnek információkat a csomópontról, Beacon-blokkokról, Beacon-státuszokról és más konszenzussal kapcsolatos adatokról közvetlenül a csomópontról. Ez az API a [Beacon API honlapon](https://ethereum.github.io/beacon-APIs/#/) van dokumentálva. + +Egy belső API-t használnak a kliensek közötti kommunikációra a csomóponton belül, így a konszenzusos kliens és a végrehajtási kliens képes adatot cserélni. Ezt nevezik Motor API-nak, amelynek specifikációja a [GitHubon](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) érhető el. + +## Végrehajtási kliens specifikációi {#spec} + +[Tekintse meg a teljes JSON-RPC API specifikációt a GitHubon](https://github.com/ethereum/execution-apis). Ez az API a [Végrehajtási API oldalon](https://ethereum.github.io/execution-apis/api-documentation/) van dokumentálva, és tartalmaz egy ellenőrt, hogy a rendelkezésre álló metódusokat ki lehessen próbálni. + +## Egyezmények {#conventions} + +### Hexadecimális értékű kódolás {#hex-encoding} + +Két fontos adattípus megy át a JSON-ön: formázatlan bájttömbök és mennyiségek. Mindkettő hexadecimális kódolásban van elküldve, de más a formázási követelmény. + +#### Mennyiségek {#quantities-encoding} + +A mennyiségek (egész számok, számok) kódolásánál: hexadecimálisban, „0x” előtaggal, a legtömörebb kifejeződésben kell kódolni (kivéve a nullát, mert az „0x0” lesz). + +Néhány példa: + +- 0x41 (65 decimálisban) +- 0x400 (1024 decimálisban) +- HELYTELEN: 0x (legalább egy számjegy még szükséges, a nulla írása „0x0”) +- HELYTELEN: 0x0400 (nem kezdődhet nullával a szám) +- HELYTELEN: ff (a 0x előtagot ki kell tenni) + +### Formázatlan adat {#unformatted-data-encoding} + +Amikor formázatlan adatot (bájtsorok, számlacímek, hashek, bájtkódtömbök) kell kódolni: hexadecimálisban, „0x” előtaggal, két hex számjegy bájtonként. + +Néhány példa: + +- 0x41 (1-es méret, „A”) +- 0x004200 (3-as méret, „0B0”) +- 0x (size 0, "") +- HELYTELEN: 0xf0f0f (páros számú kell legyen) +- HELYTELEN: 004200 (a 0x előtagot ki kell tenni) + +### Az alapértelmezett blokkparaméter {#default-block} + +A következő metódusok egy extra alapértelmezett blokkparaméterrel rendelkeznek: + +- [eth_getBalance](#eth_getbalance) +- [eth_getCode](#eth_getcode) +- [eth_getTransactionCount](#eth_gettransactioncount) +- [eth_getStorageAt](#eth_getstorageat) +- [eth_call](#eth_call) + +Amikor az Ethereum státuszát érintő kérések érkeznek, akkor a legutolsó alapértelmezett blokkparaméter határozza meg a blokk méretét. + +A defaultBlock paraméter a következők lehetnek: + +- `HEX String` – egy egész szám mint blokkszám +- `String "earliest"` – a legkorábbi/genezis blokk +- `String "latest"` – a legutóbb javasolt blokk +- `String "safe"` – a blokk legutóbbi biztonságos feje +- `String "finalized"` – a legutóbbi véglegesedett blokk +- `String "pending"` – a függőben lévő státusz/tranzakciók esetében + +## Példák + +Ebben a leírásban példákat mutatunk be, hogyan lehet használni az egyéni JSON_RPC API végpontokat a parancssoreszközzel, ami a [curl](https://curl.se). Ezek az egyéni végpontpéldák a [Curl példák](#curl-examples) szekciókban találhatók alább. Ezek után bemutatunk egy [példát az elejétől a végéig](#usage-example) egy okosszerződés átfordítására és telepítésére egy Geth csomópont, a JSON_RPC API és a curl használatával. + +## Példák a curlre {#curl-examples} + +Alább láthatók azok a példák, amikor a JSON_RPC API-t használjuk egy [curl](https://curl.se) kérést létrehozva egy Ethereum-csomópontnak. Minden példa tartalmazza az adott végpont specifikációit, paramétereit, visszatérési típusát és egy működő példát arról, hogyan kell használni. + +A curl-kérések hibát adhatnak vissza a tartalom típusa miatt. Ennek az az oka, hogy a `--data` opció beállítja a tartalomtípust `application/x-www-form-urlencoded` értékre. Ha az Ön által használt csomópontnak ez nem tetszik, akkor manuálisa állítsa át a fejlécet, hogy a `-H "Content-Type: application/json"` a hívás elején legyen. A példák nem tartalmazzák az URL/IP és port kombinációját, amit a curl utolsó változójaként kell megadni (például `127.0.0.1:8545`). Egy komplett curl-kérés, amely ezeket a plusz adatokat is tartalmazza, így néz ki: + +```shell +curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545 +``` + +## Pletyka, státusz, előzményadatok {#gossip-state-history} + +Néhány központi JSON-RPC metódushoz szükség van az Ethereum hálózati adataira, amelyek általában háromfélék lehetnek: _Pletyka, státusz és előzményadatok_. Az ebben a részben található hivatkozások segítségével az adott metódusra tud lépni, de a tartalomjegyzéket is használhatja a metódusok teljes listájának megtekintéséhez. + +### Pletyka metódusok {#gossip-methods} + +> Ezek a metódusok a lánc fejét követik nyomon. Így kerülnek be tranzakciók a hálózatra, találják meg az útjukat a blokkokba, és az, a kliensek így szereznek tudomást az új blokkokról. + +- [eth_blockNumber](#eth_blocknumber) +- [eth_sendRawTransaction](#eth_sendrawtransaction) + +### Státusz metódusok {#state_methods} + +> Olyan metódusok, melyek az összes tárolt adat jelenlegi státuszát riportálják. A „státusz” olyan, akár egy nagy, megosztott RAM rész, ami számlaegyenlegeket, szerződésadatokat és gázbecsléseket tartalmaz. + +- [eth_getBalance](#eth_getbalance) +- [eth_getStorageAt](#eth_getstorageat) +- [eth_getTransactionCount](#eth_gettransactioncount) +- [eth_getCode](#eth_getcode) +- [eth_call](#eth_call) +- [eth_estimateGas](#eth_estimategas) + +### Előzményadatok metódusok {#history_methods} + +> Minden egyes blokkból képes előzményadatokat lekérni egészen a genezisig. Olyan mint egy hatalmas, egyre bővülő fájl, amely tartalmazza az összes blokkfejlécet, blokkadatot, a szülőblokk testvérblokkjait (ommer/uncle) és a tranzakció-visszaigazolásokat. + +- [eth_getBlockTransactionCountByHash](#eth_getblocktransactioncountbyhash) +- [eth_getBlockTransactionCountByNumber](#eth_getblocktransactioncountbynumber) +- [eth_getUncleCountByBlockHash](#eth_getunclecountbyblockhash) +- [eth_getUncleCountByBlockNumber](#eth_getunclecountbyblocknumber) +- [eth_getBlockByHash](#eth_getblockbyhash) +- [eth_getBlockByNumber](#eth_getblockbynumber) +- [eth_getTransactionByHash](#eth_gettransactionbyhash) +- [eth_getTransactionByBlockHashAndIndex](#eth_gettransactionbyblockhashandindex) +- [eth_getTransactionByBlockNumberAndIndex](#eth_gettransactionbyblocknumberandindex) +- [eth_getTransactionReceipt](#eth_gettransactionreceipt) +- [eth_getUncleByBlockHashAndIndex](#eth_getunclebyblockhashandindex) +- [eth_getUncleByBlockNumberAndIndex](#eth_getunclebyblocknumberandindex) + +## JSON-RPC API próbafelület + +Az API-módszerek felfedezéséhez és kipróbálásához használhatja a [próbaeszközt](https://ethereum-json-rpc.com). Azt is megmutatja, hogy a különböző csomópontszolgáltatók milyen metódusokat és hálózatokat támogatnak. + +## JSON-RPC API metódusok {#json-rpc-methods} + +### web3_clientVersion {#web3_clientversion} + +Visszaadja a jelenlegi kliensverziót. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`String` – A jelenlegi kliensverzió + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' +// Result +{ + "id":67, + "jsonrpc":"2.0", + "result": "Geth/v1.12.1-stable/linux-amd64/go1.19.1" +} +``` + +### web3_sha3 {#web3_sha3} + +Visszaadja az adott adat keccak-256 szerinti értékét (_nem_ a szabványosított SHA3-256 szerintit). + +**Paraméterek** + +1. `DATA` – Az adatok átkonvertálva SHA3 hash formátumba + +```js +params: ["0x68656c6c6f20776f726c64"] +``` + +**Visszaad** + +`DATA` – Az adott sztring SHA3-eredménye. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}' +// Result +{ + "id":64, + "jsonrpc": "2.0", + "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad" +} +``` + +### net_version {#net_version} + +Visszaadja a jelenlegi hálózati azonosítót. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`String` – Jelenlegi hálózati azonosító. + +A jelenlegi hálózati azonosítók teljes listája a [chainlist.org](https://chainlist.org) oldalon érhető el. Néhány jellemző példa: + +- `1`: Ethereum főhálózata +- `5`: Goerli teszthálózat +- `11155111`: Sepolia teszthálózat + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}' +// Result +{ + "id":67, + "jsonrpc": "2.0", + "result": "3" +} +``` + +### net_listening {#net_listening} + +A `true` értéket adja vissza, ha a kliens aktívan hallgatja a hálózati kapcsolatokat. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`Boolean` – `true`, amikor hallgatja, máskülönben `false`. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}' +// Result +{ + "id":67, + "jsonrpc":"2.0", + "result":true +} +``` + +### net_peerCount {#net_peercount} + +Visszaadja a társak számát, amelyek jelenleg a klienshez kapcsolódnak. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`QUANTITY` – a kapcsolódó társak száma egész számként. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}' +// Result +{ + "id":74, + "jsonrpc": "2.0", + "result": "0x2" // 2 +} +``` + +### eth_protocolVersion {#eth_protocolversion} + +A jelenlegi Ethereum-protokollverziót adja vissza. Vegye figyelembe, hogy ez a metódus [a Geth-ben nem érhető el](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924). + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`String` – Az Ethereum jelenlegi protokollverziója + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}' +// Result +{ + "id":67, + "jsonrpc": "2.0", + "result": "54" +} +``` + +### eth_syncing {#eth_syncing} + +Egy objektumot ad vissza a szinkronizálási státuszról szóló adattal vagy `false`. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +A pontos visszakapott adat a kliensimplementációk szerint változik. Minden kliens `false` értéket küld, amikor a csomópont nem szinkronizál, és mindegyik elküldi a következő mezőket. + +`Object|Boolean`, egy objektum a szinkronizálási státuszról szóló adattal vagy `false`, amikor nem szinkronizál: + +- `startingBlock`: `QUANTITY` – Az a blokk, amelynél az importálása kezdődött (csak akkor lesz visszaállítva, miután a szinkronizálás elérte a fejet) +- `currentBlock`: `QUANTITY` – A jelenlegi blokk, azonos az eth_blockNumber mezővel +- `highestBlock`: `QUANTITY` – A becsült legnagyobb számú blokk + +Ugyanakkor az egyéni kliensek további adatokat is adhatnak. A Geth például ezt küldi vissza: + +```json +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "currentBlock": "0x3cf522", + "healedBytecodeBytes": "0x0", + "healedBytecodes": "0x0", + "healedTrienodes": "0x0", + "healingBytecode": "0x0", + "healingTrienodes": "0x0", + "highestBlock": "0x3e0e41", + "startingBlock": "0x3cbed5", + "syncedAccountBytes": "0x0", + "syncedAccounts": "0x0", + "syncedBytecodeBytes": "0x0", + "syncedBytecodes": "0x0", + "syncedStorage": "0x0", + "syncedStorageBytes": "0x0" + } +} +``` + +Amíg a Besu ezt küldi vissza: + +```json +{ + "jsonrpc": "2.0", + "id": 51, + "result": { + "startingBlock": "0x0", + "currentBlock": "0x1518", + "highestBlock": "0x9567a3", + "pulledStates": "0x203ca", + "knownStates": "0x200636" + } +} +``` + +Tekintse meg az adott kliens dokumentációját a további adatokért. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": { + startingBlock: '0x384', + currentBlock: '0x386', + highestBlock: '0x454' + } +} +// Or when not syncing +{ + "id":1, + "jsonrpc": "2.0", + "result": false +} +``` + +### eth_coinbase {#eth_coinbase} + +A kliens coinbase-címét adja vissza. + +> **Megjegyzés:** Ez a metódus a **v1.14.0** óta elavult, és már nem támogatott. Ha megpróbálja használni ezt a metódust, a „Nem támogatott metódus” hibaüzenetet kapja. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`DATA`, 20 bájt – a jelenlegi coinbase címe. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}' +// Result +{ + "id":64, + "jsonrpc": "2.0", + "result": "0x407d73d8a49eeb85d32cf465507dd71d507100c1" +} +``` + +### eth_chainId {#eth_chainId} + +Visszaadja a láncazonosítót, amellyel az újrajátszástól védett tranzakciókat írják alá. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`chainId`, hexadecimális érték mint sztring, amely a jelenlegi láncazonosítót mutatja egész számként. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}' +// Result +{ + "id":67, + "jsonrpc": "2.0", + "result": "0x1" +} +``` + +### eth_mining {#eth_mining} + +A visszaadott érték `true`, ha a kliens aktívan bányászik új blokkokat. Ez csak proof-of-work hálózatok esetén küld vissza `true` értéket, és talán a [egyesítés (Merge)](/roadmap/merge/) óta nincs is benne minden kliensben. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`Boolean` – `true` értéket ad vissza, ha a kliens bányászik, különben `false`. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}' +// +{ + "id":71, + "jsonrpc": "2.0", + "result": true +} +``` + +### eth_hashrate {#eth_hashrate} + +Visszaadja a hashek számát másodpercenként, amellyel a csomópont a bányászatot végzi. Ez csak proof-of-work hálózatok esetén küld vissza `true` értéket, és talán a [egyesítés (Merge)](/roadmap/merge/) óta nincs is benne minden kliensben. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`QUANTITY` – hashek száma másodpercenként. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}' +// Result +{ + "id":71, + "jsonrpc": "2.0", + "result": "0x38a" +} +``` + +### eth_gasPrice {#eth_gasprice} + +Visszaadja a jelenlegi becsült gázárat wei-ben. Például a Besu kliens megvizsgálja az utolsó 100 blokkot, és a gáz egységárának mediánját küldi vissza alapból. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`QUANTITY` – a jelenlegi gázár wei-ben egész számként. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}' +// Result +{ + "id":73, + "jsonrpc": "2.0", + "result": "0x1dfd14000" // 8049999872 Wei +} +``` + +### eth_accounts {#eth_accounts} + +A kliens által birtokolt címek listáját adja vissza. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`Array of DATA`, 20 bájt – a kliens által birtokolt címek. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1"] +} +``` + +### eth_blockNumber {#eth_blocknumber} + +A legutóbbi blokk számát adja vissza. + +**Paraméterek** + +Egyik sem + +**Visszaad** + +`QUANTITY` – a legutóbbi blokk száma egész számként, amelynél a kliens tart. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' +// Result +{ + "id":83, + "jsonrpc": "2.0", + "result": "0x4b7" // 1207 +} +``` + +### eth_getBalance {#eth_getbalance} + +Az adott cím számlaegyenlegét adja vissza. + +**Paraméterek** + +1. `DATA`, 20 bájt – cím, melynek az egyenlegét ellenőrizzük. +2. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) + +```js +params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"] +``` + +**Visszaad** + +`QUANTITY` – a jelenlegi egyenleg wei-ben egész számként. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x0234c8a3397aab58" // 158972490234375000 +} +``` + +### eth_getStorageAt {#eth_getstorageat} + +Egy adott címen lévő tárhely pozícióját adja vissza. + +**Paraméterek** + +1. `DATA`, 20 bájt – a tárhely címe. +2. `QUANTITY` – a tárhelyben lévő pozíció egész számként. +3. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) + +**Visszaad** + +`DATA` – az adott tárhelypozíció értéke. + +**Példa** Kiszámolja a pontos pozíciót, a visszakapott tárhely függvényében. Vegyük a következő szerződést, ami itt van telepítve: `0x295a70b2de5e3953354a6a8344e616ed314d7251`, ezzel a címmel:`0x391694e7e0b0cce554cb130d723a9d27458f9298`. + +``` +contract Storage { + uint pos0; + mapping(address => uint) pos1; + function Storage() { + pos0 = 1234; + pos1[msg.sender] = 5678; + } +} +``` + +A pos0 érték megszerzése egyértelmű: + +```js +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 +{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} +``` + +A térkép egyik elemének megszerzése már nehezebb. A térképen egy elem pozícióját így kalkuláljuk: + +```js +keccak(LeftPad32(key, 0), LeftPad32(map position, 0)) +``` + +Ahhoz, hogy megszerezzük a tárhelyet a pos1["0x391694e7e0b0cce554cb130d723a9d27458f9298"] tekintetében, a pozíciót így kell kalkulálni: + +```js +keccak( + decodeHex( + "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + + "0000000000000000000000000000000000000000000000000000000000000001" + ) +) +``` + +A web3-könyvtárban található Geth konzolt lehet használni a kalkulációhoz: + +```js +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +Most pedig a tárhely megszerzése: + +```js +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 +{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} +``` + +### eth_getTransactionCount {#eth_gettransactioncount} + +Visszaadja a tranzakciók számát, amelyeket egy adott címről _küldtek_. + +**Paraméterek** + +1. `DATA`, 20 bájt – cím. +2. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) + +```js +params: [ + "0x407d73d8a49eeb85d32cf465507dd71d507100c1", + "latest", // state at the latest block +] +``` + +**Visszaad** + +`QUANTITY` – a tranzakciók száma egész számként, amit erről a címről küldtek. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_getBlockTransactionCountByHash {#eth_getblocktransactioncountbyhash} + +Visszaadja a tranzakciók számát egy blokkban, egy olyan blokkból, mely egyezik a megadott blokkhashsel. + +**Paraméterek** + +1. `DATA`, 32 bájt – blokkhash + +```js +params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"] +``` + +**Visszaad** + +`QUANTITY` – ebben a blokkban lévő tranzakciók száma egész számként. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x8b" // 139 +} +``` + +### eth_getBlockTransactionCountByNumber {#eth_getblocktransactioncountbynumber} + +Visszaadja a tranzakciók számát egy blokkban, amely az adott blokkszámnak felel meg. + +**Paraméterek** + +1. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek az [alapértelmezett blokkparaméterek](/developers/docs/apis/json-rpc/#default-block) szerint. + +```js +params: [ + "0x13738ca", // 20396234 +] +``` + +**Visszaad** + +`QUANTITY` – ebben a blokkban lévő tranzakciók száma egész számként. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x8b" // 139 +} +``` + +### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash} + +Visszaadja az uncle-blokkok számát egy olyan blokkból, ami a blokkhashnek megfelel. + +**Paraméterek** + +1. `DATA`, 32 bájt – blokkhash + +```js +params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"] +``` + +**Visszaad** + +`QUANTITY` – ebben a blokkban az uncle-blokkok száma egész számként. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_getUncleCountByBlockNumber {#eth_getunclecountbyblocknumber} + +Visszaadja az uncle-blokkok számát egy olyan blokkból, ami egy adott blokkszámnak megfelel. + +**Paraméterek** + +1. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) + +```js +params: [ + "0xe8", // 232 +] +``` + +**Visszaad** + +`QUANTITY` – ebben a blokkban az uncle-blokkok száma egész számként. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x0" // 0 +} +``` + +### eth_getCode {#eth_getcode} + +Visszaadja az adott címen lévő kódot. + +**Paraméterek** + +1. `DATA`, 20 bájt – cím +2. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) + +```js +params: [ + "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", + "0x5daf3b", // 6139707 +] +``` + +**Visszaad** + +`DATA` – a kód az adott címről. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029" +} +``` + +### eth_sign {#eth_sign} + +Az aláírás metódus kikalkulál egy Ethereum-specifikus aláírást a következővel: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`. + +Ha az üzenethez egy előtagot adunk, akkor a kikalkulált aláírást úgy ismeri fel, mint Ethereum-specifikus aláírás. Ez megakadályozza a rosszhiszemű felhasználást, amikor egy támadó alkalmazás tetszőleges adatokat (például tranzakciókat) ír alá, és arra használja az aláírást, hogy megszemélyesítse áldozatát. + +Megjegyzés: az aláíráshoz olyan cím kell, amely nincs zárolva. + +**Paraméterek** + +1. `DATA`, 20 bájt – cím +2. `DATA`, N bájt – az aláírandó üzenet + +**Visszaad** + +`DATA`: Aláírás + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" +} +``` + +### eth_signTransaction {#eth_signtransaction} + +Aláír egy olyan tranzakciót, amelyet egy későbbi időpontban be lehet küldeni a hálózatra az [eth_sendRawTransaction](#eth_sendrawtransaction) segítségével. + +**Paraméterek** + +1. `Object` – A tranzakcióobjektum + +- `type`: +- `from`: `DATA`, 20 bájt – A cím, amelyről a tranzakció érkezett. +- `to`: `DATA`, 20 bájt – (opcionális új szerződés létrehozásakor) A tranzakció címzettjének címe. +- `gas`: `QUANTITY` – (opcionális, alapértelmezett: 90 000) A tranzakció végrehajtásához biztosított gáz egész számban megadva. Visszaküldi a fel nem használt gázt. +- `gasPrice`: `QUANTITY` – (opcionális, alapértelmezett: To-Be-Determined) a gasPrice (gázár) egész számként, ami a wei-ben fizetendő gázra vonatkozik. +- `value`: `QUANTITY` – (opcionális) a tranzakcióban küldött érték egész számként, wei-ben. +- `data`: `DATA` – A szerződés kódjának átfordítása VAGY a meghívott metódus aláírásának és kódolt paramétereinek a hashe. +- `nonce`: `QUANTITY` – (opcionális) A nonce egész számmal megadva. Ez lehetővé teszi a saját függőben lévő tranzakciók felülírását, amelyek ugyanazt a nonce-t használják. + +**Visszaad** + +`DATA`, Az RLP-kódolású tranzakcióobjektum, melyet a specifikus számla aláírt. + +**Példa** + +```js +// Request +curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}' +// Result +{ + "id": 1, + "jsonrpc": "2.0", + "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" +} +``` + +### eth_sendTransaction {#eth_sendtransaction} + +Készít egy új üzenetküldési tranzakciót vagy szerződéslétrehozást, ha az adatmezőben kód van, és aláírja a `from` mezőben definiált számlával. + +**Paraméterek** + +1. `Object` – A tranzakcióobjektum + +- `from`: `DATA`, 20 bájt – A cím, amelyről a tranzakció érkezett. +- `to`: `DATA`, 20 bájt – (opcionális új szerződés létrehozásakor) A tranzakció címzettjének címe. +- `gas`: `QUANTITY` – (opcionális, alapértelmezett: 90 000) A tranzakció végrehajtásához biztosított gáz egész számban megadva. Visszaküldi a fel nem használt gázt. +- `gasPrice`: `QUANTITY` – (opcionális, alapértelmezett: To-Be-Determined) a gasPrice (gázár) egész számként, ami a fizetendő gázra vonatkozik. +- `value`: `QUANTITY` – (opcionális) a tranzakcióban küldött érték egész számként. +- `input`: `DATA` – A szerződés kódjának átfordítása VAGY a meghívott metódus aláírásának és kódolt paramétereinek a hashe. +- `nonce`: `QUANTITY` – (opcionális) A nonce egész számmal megadva. Ez lehetővé teszi a saját függőben lévő tranzakciók felülírását, amelyek ugyanazt a nonce-t használják. + +```js +params: [ + { + from: "0xb60e8dd61c5d32be8058bb8eb970870f07233155", + to: "0xd46e8dd67c5d32be8058bb8eb970870f07244567", + gas: "0x76c0", // 30400 + gasPrice: "0x9184e72a000", // 10000000000000 + value: "0x9184e72a", // 2441406250 + input: + "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", + }, +] +``` + +**Visszaad** + +`DATA`, 32 bájt – a tranzakció hashe vagy a nulla hash, ha a tranzakció még nem elérhető. + +Használja az [eth_getTransactionReceipt](#eth_gettransactionreceipt) parancsot, hogy megszerezze a szerződéscímet, miután a tranzakciót egy blokkban előterjesztették, és amikor létrehozta a szerződést. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" +} +``` + +### eth_sendRawTransaction {#eth_sendrawtransaction} + +Egy új üzenetküldési tranzakciót vagy szerződéslétrehozást hoz létre az aláírt tranzakciókhoz. + +**Paraméterek** + +1. `DATA`, az aláírt tranzakciós adatok. + +```js +params: [ + "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", +] +``` + +**Visszaad** + +`DATA`, 32 bájt – a tranzakció hashe vagy a nulla hash, ha a tranzakció még nem elérhető. + +Használja az [eth_getTransactionReceipt](#eth_gettransactionreceipt) parancsot, hogy megszerezze a szerződéscímet, miután a tranzakciót egy blokkban előterjesztették, és amikor létrehozta a szerződést. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" +} +``` + +### eth_call {#eth_call} + +Azonnal végrehajt egy új üzenethívást anélkül, hogy létrehozna egy tranzakciót a blokkláncon. Gyakran használják arra, hogy csak olvasási (read-only) okosszerződés-függvényeket hajtsanak végre, például a `balanceOf` kód egy ERC-20-as szerződésnél. + +**Paraméterek** + +1. `Object` – A tranzakcióhívás objektuma + +- `from`: `DATA`, 20 bájt – (opcionális) A tranzakció küldőjének címe. +- `to`: `DATA`, 20 bájt – A tranzakció címzettjének címe. +- `gas`: `QUANTITY` – (opcionális) A tranzakció végrehajtásához adott gáz egész számként. Az eth_call nulla gázt fogyaszt, de néhány végrehajtásnak szüksége lehet rá. +- `gasPrice`: `QUANTITY` – (opcionális) a gasPrice (gázár) egész számként, ami a fizetendő gázra vonatkozik +- `value`: `QUANTITY` – (opcionális) a tranzakcióban küldött érték egész számként +- `input`: `DATA` – (opcionális) a metódus aláírásának és kódolt paramétereinek a hashe. A részletekért tekintse meg az [Ethereum-szerződés ABI-ját a Solidity dokumentációban](https://docs.soliditylang.org/en/latest/abi-spec.html). + +2. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) + +**Visszaad** + +`DATA` – a végrehajtott szerződés visszatérési értéke. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x" +} +``` + +### eth_estimateGas {#eth_estimategas} + +Megbecsüli, hogy egy tranzakció végrehajtásához mennyi gázra lesz szükség. A tranzakció nem kerül hozzáadásra a blokklánchoz. Vegye figyelembe, hogy a becslés szignifikánsan több is lehet, mint amennyit elhasznál a tranzakció, melynek számos oka van, beleértve az EVM működési módját és a csomópontok teljesítményét. + +**Paraméterek** + +Nézze meg az [eth_call](#eth_call) paramétereit az összes opcionális paraméter kivételével. Ha nincs megadva gázkorlátozás, akkor a Geth a függőben lévő blokk gázkorlátozását használja felső értékként. Ennek eredményeként a visszakapott becslés talán nem elég a hívás/tranzakció végrehajtásához, amikor a gáz mennyisége magasabb, mint a függőben lévő blokk gázkorlátozása. + +**Visszaad** + +`QUANTITY` – a felhasznált gáz mennyisége. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x5208" // 21000 +} +``` + +### eth_getBlockByHash {#eth_getblockbyhash} + +Egy blokkról ad információt hash alapján. + +**Paraméterek** + +1. `DATA`, 32 bájt – egy blokk hashe. +2. `Boolean` – Ha `true`, akkor visszaadja a teljes tranzakcióobjektumot, ha `false`, akkor csak a tranzakciók hashét. + +```js +params: [ + "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", + false, +] +``` + +**Visszaad** + +`Object` – Egy blokkobjektum, vagy `null`, amikor nem talál blokkot: + +- `number`: `QUANTITY` – a blokkszám. `null`, amikor a blokk függőben van. +- `hash`: `DATA`, 32 bájt – a blokk hashe. `null`, amikor a blokk függőben van. +- `parentHash`: `DATA`, 32 bájt – a szülőblokk hashe. +- `nonce`: `DATA`, 8 bájt – a létrehozott proof-of-work hashe. `null`, amikor a blokk függőben van. +- `sha3Uncles`: `DATA`, 32 bájt – a blokkban lévő uncle blokkok SHA3-ja. +- `logsBloom`: `DATA`, 256 bájt – a bloom-szűrés a blokkok naplózására. `null`, amikor a blokk függőben van. +- `transactionsRoot`: `DATA`, 32 bájt – a blokk tranzakciós fájának a gyökere. +- `stateRoot`: `DATA`, 32 bájt – a blokk végső státuszfájának a gyökere. +- `receiptsRoot`: `DATA`, 32 bájt – a blokk visszaigazolás-fájának a gyökere. +- `miner`: `DATA`, 20 bájt – annak a címe, akinek a bányászati jutalom jár. +- `difficulty`: `QUANTITY` – erre a blokkra vonatkozó nehézség egész számként. +- `totalDifficulty`: `QUANTITY` – a lánc teljes nehézsége eddig a blokkig, egész számként. +- `extraData`: `DATA` – ennek a blokknak a „további adatok” mezője. +- `size`: `QUANTITY` – a blokk mérete bájtban, egész számként. +- `gasLimit`: `QUANTITY` – a maximálisan megengedett gáz ebben a blokkban. +- `gasUsed`: `QUANTITY` – a tranzakciók által elhasznált összes gáz ebben a blokkban. +- `timestamp`: `QUANTITY` – a unix időbélyege, amikor a blokkot összeállították. +- `transactions`: `Array` – Tranzakcióobjektumok tömbje, vagy 32 bájtos tranzakcióhashek az utolsó megadott paraméter alapján. +- `uncles`: `Array` – Az uncle hashek sora. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}' +// Result +{ +{ +"jsonrpc": "2.0", +"id": 1, +"result": { + "difficulty": "0x4ea3f27bc", + "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32", + "gasLimit": "0x1388", + "gasUsed": "0x0", + "hash": "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", + "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", + "miner": "0xbb7b8287f3f0a933474a79eae42cbca977791171", + "mixHash": "0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843", + "nonce": "0x689056015818adbe", + "number": "0x1b4", + "parentHash": "0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54", + "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", + "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", + "size": "0x220", + "stateRoot": "0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d", + "timestamp": "0x55ba467c", + "totalDifficulty": "0x78ed983323d", + "transactions": [ + ], + "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", + "uncles": [ + ] +} +} +``` + +### eth_getBlockByNumber {#eth_getblockbynumber} + +Egy blokkról ad információt a blokkszám alapján. + +**Paraméterek** + +1. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek az [alapértelmezett blokkparaméterek](/developers/docs/apis/json-rpc/#default-block) szerint. +2. `Boolean` – Ha `true`, akkor visszaadja a teljes tranzakcióobjektumot, ha `false`, akkor csak a tranzakciók hashét. + +```js +params: [ + "0x1b4", // 436 + true, +] +``` + +**Visszaküldött információk** Nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}' +``` + +Az eredményeket nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél + +### eth_getTransactionByHash {#eth_gettransactionbyhash} + +Információt ad egy tranzakcióról a tranzakció hashe alapján. + +**Paraméterek** + +1. `DATA`, 32 bájt – tranzakció-hash + +```js +params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"] +``` + +**Visszaad** + +`Object` – Egy tranzakcióobjektum, vagy `null`, amikor nem talál tranzakciót: + +- `blockHash`: `DATA`, 32 bájt – a blokk-hash, amelyben ez a tranzakció volt. `null`, amikor függőben van. +- `blockNumber`: `QUANTITY` – a blokkszám, amelyben ez a tranzakció volt. `null`, amikor függőben van. +- `from`: `DATA`, 20 bájt – a küldő címe. +- `gas`: `QUANTITY` – a küldő által adott gáz. +- `gasPrice`: `QUANTITY` – a küldő által megadott gázár wei-ben. +- `hash`: `DATA`, 32 bájt – a tranzakció hashe. +- `input`: `DATA` – a tranzakcióval együtt küldött adatok. +- `nonce`: `QUANTITY` – a tranzakciók száma, melyet a küldő az adott tranzakció előtt végzett. +- `to`: `DATA`, 20 bájt – a fogadó címe. `null`, amikor ez egy szerződéslétrehozó tranzakció. +- `transactionIndex`: `QUANTITY` – a tranzakcióindex pozíciója a blokkban, egész számként. `null`, amikor függőben van. +- `value`: `QUANTITY` – a küldött érték wei-ben. +- `v`: `QUANTITY` – ECDSA visszaállítási azonosító +- `r`: `QUANTITY` – ECDSA aláírás r +- `s`: `QUANTITY` – ECDSA aláírás s + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}' +// Result +{ + "jsonrpc":"2.0", + "id":1, + "result":{ + "blockHash":"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", + "blockNumber":"0x5daf3b", // 6139707 + "from":"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d", + "gas":"0xc350", // 50000 + "gasPrice":"0x4a817c800", // 20000000000 + "hash":"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b", + "input":"0x68656c6c6f21", + "nonce":"0x15", // 21 + "to":"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb", + "transactionIndex":"0x41", // 65 + "value":"0xf3dbb76162000", // 4290000000000000 + "v":"0x25", // 37 + "r":"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea", + "s":"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c" + } +} +``` + +### eth_getTransactionByBlockHashAndIndex {#eth_gettransactionbyblockhashandindex} + +Egy tranzakcióról ad információt a blokk-hash és a tranzakcióindex pozíciója alapján. + +**Paraméterek** + +1. `DATA`, 32 bájt – egy blokk hashe. +2. `QUANTITY` – a tranzakcióindex pozíciója egész számként. + +```js +params: [ + "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", + "0x0", // 0 +] +``` + +**Visszaküldött információk** Nézze meg az [eth_getTransactionByHash](#eth_gettransactionbyhash) résznél + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' +``` + +Az eredményeket nézze meg az [eth_getTransactionByHash](#eth_gettransactionbyhash) résznél + +### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex} + +Egy tranzakcióról ad információt a blokkszám és a tranzakcióindex pozíciója alapján. + +**Paraméterek** + +1. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek az [alapértelmezett blokkparaméterek](/developers/docs/apis/json-rpc/#default-block) szerint. +2. `QUANTITY` – a tranzakcióindex pozíciója. + +```js +params: [ + "0x9c47cf", // 10241999 + "0x24", // 36 +] +``` + +**Visszaküldött információk** Nézze meg az [eth_getTransactionByHash](#eth_gettransactionbyhash) résznél + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}' +``` + +Az eredményeket nézze meg az [eth_getTransactionByHash](#eth_gettransactionbyhash) résznél + +### eth_getTransactionReceipt {#eth_gettransactionreceipt} + +Egy tranzakció visszaigazolását adja meg a tranzakció-hash alapján. + +**Megjegyzés:** A visszaigazolás nem érthető el függőben lévő tranzakciók esetében. + +**Paraméterek** + +1. `DATA`, 32 bájt – tranzakció-hash + +```js +params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"] +``` + +**Visszaküldött információk** `Object` – Egy tranzakció visszaigazolási objektuma, vagy `null`, amikor a visszaigazolást nem találja: + +- `transactionHash`: `DATA`, 32 bájt – a tranzakció hashe. +- `transactionIndex`: `QUANTITY` – a tranzakcióindex pozíciója a blokkban, egész számként. +- `blockHash`: `DATA`, 32 bájt – a blokk-hash, amelyben ez a tranzakció volt. +- `blockNumber`: `QUANTITY` – a blokkszám, amelyben ez a tranzakció volt. +- `from`: `DATA`, 20 bájt – a küldő címe. +- `to`: `DATA`, 20 bájt – a fogadó címe. null, amikor ez egy szerződéslétrehozó tranzakció. +- `cumulativeGasUsed` : `QUANTITY` – A gáz teljes mennyisége, amikor ez a tranzakció végrehajtásra került a blokkban. +- `effectiveGasPrice` : `QUANTITY` – Az alapdíj és a borravaló összege a gáz egységére vonatkozóan. +- `gasUsed`: `QUANTITY` – A felhasznált gáz mennyisége erre az adott tranzakcióra vonatkozóan. +- `contractAddress`: `DATA`, 20 bájt – A létrehozott szerződéscím, ha ez a tranzakció szerződéslétrehozásról szól, máskülönben `null`. +- `logs`: `Array` – A naplózási objektumok tömbje, amelyet ez a tranzakció generált. +- `logsBloom`: `DATA`, 256 bájt – Bloom-szűrés a könnyű kliensekhez, hogy gyorsan elérjék a kapcsolódó naplóbejegyzéseket. +- `type`: `QUANTITY` – a tranzakciótípus egész számként, `0x0` a korábbi tranzakciókért, `0x1` a hozzáférési lista típusért, `0x2` a dinamikus díjakért. + +Emellett megadja _a kettő közül az egyiket_ : + +- `root` : `DATA` 32 bájt tranzakció utáni státuszgyökér (pre Byzantium) +- `status`: `QUANTITY` vagy `1` (sikeres), vagy `0` (sikertelen) + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}' +// Result +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "blockHash": + "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3", + "blockNumber": "0xeff35f", + "contractAddress": null, // string of the address if it was created + "cumulativeGasUsed": "0xa12515", + "effectiveGasPrice": "0x5a9c688d4", + "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7", + "gasUsed": "0xb4c8", + "logs": [{ + // logs as returned by getFilterLogs, etc. + }], + "logsBloom": "0x00...0", // 256 byte bloom filter + "status": "0x1", + "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", + "transactionHash": + "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5", + "transactionIndex": "0x66", + "type": "0x2" + } +} +``` + +### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex} + +Egy blokk uncle-blokkjáról ad információt a hash és az uncle-index pozíciója alapján. + +**Paraméterek** + +1. `DATA`, 32 bájt – egy blokk hashe. +2. `QUANTITY` – az uncle-index pozíciója. + +```js +params: [ + "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", + "0x0", // 0 +] +``` + +**Visszaküldött információk** Nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' +``` + +Az eredményeket nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél + +**Megjegyzés**: A nagybácsi nem tartalmaz egyedi tranzakciókat. + +### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex} + +Egy blokk uncle-blokkjáról ad információt a blokkszám és az uncle-index pozíciója alapján. + +**Paraméterek** + +1. `QUANTITY|TAG` – a blokk száma egész számként, vagy az `„earliest”`, `„latest”`, `„pending”`, `„safe”`, `„finalized”` sztringek az [alapértelmezett blokkparaméterek](/developers/docs/apis/json-rpc/#default-block) szerint. +2. `QUANTITY` – az uncle-index pozíciója. + +```js +params: [ + "0x29c", // 668 + "0x0", // 0 +] +``` + +**Visszaküldött információk** Nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél + +**Megjegyzés**: A nagybácsi nem tartalmaz egyedi tranzakciókat. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}' +``` + +Az eredményeket nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél + +### eth_newFilter {#eth_newfilter} + +Egy szűrőobjektumot hoz létre a szűrőopciók alapján, hogy értesítsen, amikor a státusz változik (a naplóban). A státusz megváltozásának ellenőrzéséhez az [eth_getFilterChanges](#eth_getfilterchanges) metódust kell meghívni. + +**Megjegyzés a témaszűrők meghatározásához:** A témák sorrendfüggők. Egy tranzakció egy olyan naplóval, melyben [A, B] téma (topic) van, a következő témaszűrőkhöz lesz hozzáillesztve: + +- `[]` „bármi” +- `[A]` „A az első helyen (utána bármi)” +- `[null, B]` „bármi az első helyen ÉS B a második helyen (és utána bármi)” +- `[A, B]` „A az első helyen ÉS B a második helyen (és utána bármi)” +- `[[A, B], [A, B]]` „(A VAGY B) az első helyen ÉS (A VAGY B) a második helyen (és utána bármi)” +- **Paraméterek** + +1. `Object` – A szűrőopciók: + +- `fromBlock`: `QUANTITY|TAG` – (opcionális, alapértelmezett: `„latest”`) blokkszám egész számként, vagy `„latest”` az utolsó előterjesztett blokkra, `„safe”` az utolsó biztosított blokkra, `„finalized”` az utolsó véglegesített blokkra, vagy `„pending”`, `„earliest”` a még blokkba nem került tranzakciókra. +- `toBlock`: `QUANTITY|TAG` – (opcionális, alapértelmezett: `„latest”`) blokkszám egész számként, vagy `„latest”` az utolsó előterjesztett blokkra,`„safe”` az utolsó biztosított blokkra, `„finalized”` az utolsó véglegesített blokkra, vagy `„pending”`, `„earliest”` a még blokkba nem került tranzakciókra. +- `address`: `DATA|Array`, 20 bájt – (opcionális) A szerződéscím vagy címek listája, amelyekről a naplók származnak. +- `topics`: `Array of DATA`, – (opcionális) a `DATA` témák (topics) 32 bájtos tömbje. A témák sorrendfüggők. Minden téma egy DATA tömb lehet „vagy” opciókkal. + +```js +params: [ + { + fromBlock: "0x1", + toBlock: "0x2", + address: "0x8888f1f195afa192cfee860698584c030f4c9db1", + topics: [ + "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", + null, + [ + "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", + "0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc", + ], + ], + }, +] +``` + +**Visszaküldött információk** `QUANTITY` – Egy szűrő id. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_newBlockFilter {#eth_newblockfilter} + +Létrehoz egy szűrőt a csomópontban, hogy értesítsen az új blokk érkezéséről. A státusz megváltozásának ellenőrzéséhez az [eth_getFilterChanges](#eth_getfilterchanges) metódust kell meghívni. + +**Paraméterek** Egyik sem + +**Visszaküldött információk** `QUANTITY` – Egy szűrő id. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter} + +Létrehoz egy szűrőt a csomópontban, hogy értesítsen új függőben lévő tranzakciók érkezéséről. A státusz megváltozásának ellenőrzéséhez az [eth_getFilterChanges](#eth_getfilterchanges) metódust kell meghívni. + +**Paraméterek** Egyik sem + +**Visszaküldött információk** `QUANTITY` – Egy szűrő id. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": "0x1" // 1 +} +``` + +### eth_uninstallFilter {#eth_uninstallfilter} + +Egy adott azonosító alatti szűrő eltávolítása. Mindig érdemes meghívni, ha már nincs szükség az adott ellenőrzésre. Emellett a szűrőket ideiglenesen leállíthatja, amikor egy időszakban nincs azokra szükség az [eth_getFilterChanges](#eth_getfilterchanges) metódussal. + +**Paraméterek** + +1. `QUANTITY` – A szűrő azonosítója. + +```js +params: [ + "0xb", // 11 +] +``` + +**Visszaküldött információk** `Boolean` – `true`, ha a szűrőt sikeresen eltávolította, máskülönben `false`. + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}' +// Result +{ + "id":1, + "jsonrpc": "2.0", + "result": true +} +``` + +### eth_getFilterChanges {#eth_getfilterchanges} + +Egy szűrőre vonatkozó szelektív hívás, ami a naplótömböt adja vissza, amely az utolsó szelektív hívás óta történteket foglalja magában. + +**Paraméterek** + +1. `QUANTITY` – A szűrő azonosítója. + +```js +params: [ + "0x16", // 22 +] +``` + +**Visszaküldött információk** `Array` – Naplóobjektumok tömbje, vagy egy üres tömb, ha semmi sem változott a legutóbbi szelektív hívás óta. + +- Az `eth_newBlockFilter` által létrehozott szűrőkre a visszakapott értékek a blokkhashek (`DATA`, 32 bájt), például `["0x3454645634534..."]`. +- Az `eth_newPendingTransactionFilter` által létrehozott szűrőkre a visszakapott értékek a tranzakcióhashek (`DATA`, 32 bájt), például `["0x6345343454645..."]`. +- Az `eth_newFilter` által készített szűrőkre a naplók olyan objektumok lesznek, melyek a következő paraméterekkel rendelkeznek: + - `removed`: `TAG` – `true`, amikor a naplót törölték a lánc újrarendezése miatt. `false`, ha ez egy érvényes napló. + - `logIndex`: `QUANTITY` – a naplóindex pozíciója a blokkban, egész számként. `null`, amikor a napló függőben van. + - `transactionIndex`: `QUANTITY` – a tranzakcióindex pozíciója, amelyből a napló készült, egész számként. `null`, amikor a napló függőben van. + - `transactionHash`: `DATA`, 32 bájt – a tranzakció hashe, amelyből ez a napló készült. `null`, amikor a napló függőben van. + - `blockHash`: `DATA`, 32 bájt – a blokk-hash, amelyben ez a napló volt. `null`, amikor függőben van. `null`, amikor a napló függőben van. + - `blockNumber`: `QUANTITY` – a blokkszám, ahol ez a napló volt. `null`, amikor függőben van. `null`, amikor a napló függőben van. + - `address`: `DATA`, 20 bájt – a cím, ahonnan ez a napló származik. + - `data`: `DATA` – nullát vagy a napló több 32 bájtos nem indexált argumentumát tartalmazza. + - `topics`: `Array of DATA` – 0-tól 4-ig tartó tömbje a 32 bájtos, indexált naplóargumentumok `DATA` részleteinek. (A _Solidity-ben_: Az első téma (topic) az esemény aláírásának a _hashe_ (például `Deposit(address,bytes32,uint256)`), kivéve ha az eseményt az `anonymous` specifikációval deklarálták.) +- **Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}' +// Result +{ + "id":1, + "jsonrpc":"2.0", + "result": [{ + "logIndex": "0x1", // 1 + "blockNumber":"0x1b4", // 436 + "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d", + "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf", + "transactionIndex": "0x0", // 0 + "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d", + "data":"0x0000000000000000000000000000000000000000000000000000000000000000", + "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"] + },{ + ... + }] +} +``` + +### eth_getFilterLogs {#eth_getfilterlogs} + +Visszaadja a megadott azonosítóval rendelkező szűrőnek megfelelő összes napló tömbjét. + +**Paraméterek** + +1. `QUANTITY` – A szűrő azonosítója. + +```js +params: [ + "0x16", // 22 +] +``` + +**Visszaküldött információk** Nézze meg az [eth_getFilterChanges](#eth_getfilterchanges) résznél + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}' +``` + +Az eredményeket nézze meg az [eth_getFilterChanges](#eth_getfilterchanges) résznél + +### eth_getLogs {#eth_getlogs} + +Visszaadja az adott szűrőobjektumnak megfelelő összes naplótömböt. + +**Paraméterek** + +1. `Object` – A szűrőopciók: + +- `fromBlock`: `QUANTITY|TAG` – (opcionális, alapértelmezett: `„latest”`) blokkszám egész számként, vagy `„latest”` az utolsó előterjesztett blokkra, `„safe”` az utolsó biztosított blokkra, `„finalized”` az utolsó véglegesített blokkra, vagy `„pending”`, `„earliest”` a még blokkba nem került tranzakciókra. +- `toBlock`: `QUANTITY|TAG` – (opcionális, alapértelmezett: `„latest”`) blokkszám egész számként, vagy `„latest”` az utolsó előterjesztett blokkra,`„safe”` az utolsó biztosított blokkra, `„finalized”` az utolsó véglegesített blokkra, vagy `„pending”`, `„earliest”` a még blokkba nem került tranzakciókra. +- `address`: `DATA|Array`, 20 bájt – (opcionális) A szerződéscím vagy címek listája, amelyekről a naplók származnak. +- `topics`: `Array of DATA`, – (opcionális) a `DATA` témák (topics) 32 bájtos tömbje. A témák sorrendfüggők. Minden téma egy DATA tömb lehet „vagy” opciókkal. +- `blockhash`: `DATA`, 32 bájt – (opcionális, **jövő**) Az EIP-234 bevezetésével a `blockHash` egy új szűrőopció lesz, amely egyetlen blokkra redukálja a visszakapott naplókat egy 32-bájtos hashsel rendelkező `blockHash` segítségével. A `blockHash` használata azonos a `fromBlock` = `toBlock` = blokkszám hashsel (`blockHash`). Ha a `blockHash` benne van a szűrőkritériumban, akkor nem engedélyezett se a `fromBlock`, se a `toBlock`. + +```js +params: [ + { + topics: [ + "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", + ], + }, +] +``` + +**Visszaküldött információk** Nézze meg az [eth_getFilterChanges](#eth_getfilterchanges) résznél + +**Példa** + +```js +// Request +curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}' +``` + +Az eredményeket nézze meg az [eth_getFilterChanges](#eth_getfilterchanges) résznél + +## Használati példa {#usage-example} + +### Egy szerződés telepítése JSON_RPC-vel {#deploying-contract} + +Ez a rész azt mutatja be, hogyan lehet egy szerződést telepíteni kizárólag az RPC-interfésszel. Alternatív utak állnak rendelkezésre a szerződéstelepítéshez, ahol ez a komplexitás csökken, például az RPC-interfészre épített könyvtárak segítségével, mint amilyen a [web3.js](https://web3js.readthedocs.io/) és a [web3.py](https://github.com/ethereum/web3.py). Ezek az absztrakciók általában könnyebben érthetők és nem annyira hajlamosak a hibára, de akkor is érdemes megérteni, hogy mi is zajlik a háttérben. + +A következő egy egyszerű, `Multiply7` nevű okosszerződés, amelyet a JSON-RPC-interfésszel telepítünk egy Ethereum-csomópontra. Ez az útmutató azt feltételezi, hogy Ön már futtat egy Geth-csomópontot. A csomópontokról és a kliensekről bővebben [itt](/developers/docs/nodes-and-clients/run-a-node) olvashat. Tekintse meg az egyéni [kliensdokumentációt](/developers/docs/nodes-and-clients/), hogy hogyan lehet HTTP JSON-RPC-t indítani nem Geth-klienseken. A legtöbb kliens alapértelmezés szerint a `localhost:8545` kódon működik. + +```javascript +contract Multiply7 { + event Print(uint); + function multiply(uint input) returns (uint) { + Print(input * 7); + return input * 7; + } +} +``` + +Az első dolog, hogy a HTTP RPC-interfész engedélyezve legyen. Ez azt jelenti, hogy a Geth-nek a beállításkor megadjuk a `--http` jelölőt (flag). Ebben a példában egy Geth-csomópontot használunk egy privát fejlesztési láncon. Ehhez a megközelítéshez nincs szükség etherre, mint egy valódi hálózaton. + +```bash +geth --http --dev console 2>>geth.log +``` + +Ez elindítja a HTTP RPC interfészt a `http://localhost:8545` kódon. + +A coinbase címének lekérdezésével (az első cím megszerzésével a számlák tömbjéből) és a [curl](https://curl.se) használatával ellenőrizhetjük, hogy az interfész fut-e. Vegye figyelembe, hogy e példában az adatok mások, mint az Ön lokális csomópontján. Ha ki szeretné próbálni ezeket a parancsokat, akkor a lekérdezés paramétereit a második curl kérésben cserélje le az első kérésre kapott eredményekre. + +```bash +curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[]", "id":1}' -H "Content-Type: application/json" localhost:8545 +{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]} + +curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545 +{"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"} +``` + +Mivel a számok hexadecimálisan vannak kódolva, ezért a visszakapott egyenleg wei-ben egy hexadecimális sztring. Ha az egyenleget etherben, számként szeretnénk megkapni, akkor használhatjuk a web3-at a Geth-konzolból. + +```javascript +web3.fromWei("0x1639e49bba16280000", "ether") +// "410" +``` + +Most, hogy ethert tettünk a privát fejlesztési láncra, telepíthetjük a szerződést. Az első lépés, hogy a Multiply7 szerződést át kell fordítani bájtkódra, hogy el lehessen küldeni az EVM-nek. A solc, a Solidity átfordító telepítéséhez kövesse a [Solidity dokumentációt](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Előfordulhat, hogy egy régebbi `solc` kiadást szeretne használni, hogy az illeszkedjen [a példában szereplő átfordító verziójához](https://github.com/ethereum/solidity/releases/tag/v0.4.20).) + +Most tehát átfordíthatjuk a Multiply7 szerződést bájtkódra, hogy el lehessen küldeni az EVM-nek. + +```bash +echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin + +======= :Multiply7 ======= +Binary: +6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029 +``` + +Megvan az átfordított kód, úgyhogy most meghatározzunk, mennyi gázköltséget igényel a telepítése. Az RPC-interfésznek van egy `eth_estimateGas` metódusa, ami megadja a becsült értéket. + +```bash +curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545 +{"jsonrpc":"2.0","id":5,"result":"0x1c31e"} +``` + +Végül telepítjük a szerződést. + +```bash +curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545 +{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"} +``` + +A tranzakciót elfogadta a csomópont, és visszaküldte a tranzakcióhasht. Ezzel a hashsel lehet nyomon követni a tranzakciót. A következő lépés, hogy meghatározzuk a címet, ahová a szerződés telepítésre került. Minden végrehajtott tranzakció egy visszaigazolást ad. Ez a visszaigazolás számos információt tartalmaz a tranzakcióról, például melyik blokkba került be és mennyi gázt használt fel az EVM. Ha egy tranzakció létrehoz egy szerződést, akkor a szerződés címe is benne lesz a visszaigazolásban. A visszaigazolást megszerezhetjük az `eth_getTransactionReceipt` RPC metódussal. + +```bash +curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545 +{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}} +``` + +A szerződést a `0x4d03d617d700cf81935d7f797f4e2ae719648262` címen hozta létre. Ha nullát kapunk eredményül, akkor a tranzakció még nem került be a blokkba. Várjon egy kicsit, ellenőrizze, hogy a konszenzuskliens fut-e, és próbálja meg újra. + +#### Interakció okosszerződésekkel {#interacting-with-smart-contract} + +Ebben a példában elküldünk egy tranzakciót az `eth_sendTransaction` metódussal a szerződés `multiply` metódusának. + +Az `eth_sendTransaction` számos argumentumot igényel, mint a `from`, `to` és `data`. `From` a számla nyilvános címe, a `to` pedig a szerződés címe. A `data` tartalmazza a csomagot, hogy melyik metódust milyen argumentumokkal kell meghívni. Itt jön képbe az [ABI (application binary interface)](https://docs.soliditylang.org/en/latest/abi-spec.html). Az ABI egy JSON-fájl, amely meghatározza, hogyan kell az EVM számára megadni és kódolni az adatokat. + +Az adattörzs bájtjai határozzák meg, hogy a szerződés melyik metódusát hívják meg. Ez a Kessak-hash első 4 bájtja a függvénynév és az argumentumtípusok felett, hexadecimálisan kódolva. A szorzás függvény uint-et fogad el, ami azonos az uint256-tal. Ez a következőt jelenti: + +```javascript +web3.sha3("multiply(uint256)").substring(0, 10) +// "0xc6888fa1" +``` + +A következő lépés az argumentumok kódolása. Egyetlen uint256 van csak, amelynek értéke legyen 6. Az ABI egyik része azt mutatja be, hogy miként kell kódolni az uint256 típusokat. + +`int: enc(X)` az X két kiegészítős big-endian kódolása, a magasabb rendű (bal) oldalon 0xff-el feltöltve negatív X esetén és nulla > bájttal pozitív X esetén úgy, hogy a hossza a 32 bájt többszöröse legyen. + +Ennek a kódolása a következő: `0000000000000000000000000000000000000000000000000000000000000006`. + +A függvényválasztót és a kódolt argumentumot kombinálva az adatunk a következő: `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`. + +Ezt el lehet küldeni a csomópontnak: + +```bash +curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545 +{"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"} +``` + +Mivel egy tranzakciót küldtünk, ezért egy hasht kapunk vissza. A visszaigazolás megérkezésekor a következőt látjuk: + +```javascript +{ + blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55", + blockNumber: 268, + contractAddress: null, + cumulativeGasUsed: 22631, + gasUsed: 22631, + logs: [{ + address: "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", + blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55", + blockNumber: 268, + data: "0x000000000000000000000000000000000000000000000000000000000000002a", + logIndex: 0, + topics: ["0x24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"], + transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74", + transactionIndex: 0 + }], + transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74", + transactionIndex: 0 +} +``` + +A visszaigazolás tartalmaz egy naplót. Ezt a naplót az EVM generálta a tranzakció-végrehajtáskor és beletette a visszaigazolásba. A `multiply` függvény azt mutatja, hogy a `Print` eseményt a bemeneti érték 7-szeresével indította el. Mivel a `Print` eseményre az argumentum egy uint256 volt, kódolhatjuk az ABI szabályai szerint, ami a várt 42-es decimális értéket adja. Az adat mellett érdemes megjegyezni, hogy a témák (topics) révén meghatározható, hogy melyik esemény hozta létre a naplót: + +```javascript +web3.sha3("Print(uint256)") +// "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da" +``` + +Ez csak egy rövid bevezető volt a leggyakoribb feladatokba, a JSON-RPC közvetlen használatát demonstrálandó. + +## Kapcsolódó témák {#related-topics} + +- [JSON-RPC specifikáció](http://www.jsonrpc.org/specification) +- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) +- [JavaScript API-ok](/developers/docs/apis/javascript/) +- [Backend API-ok](/developers/docs/apis/backend/) +- [Végrehajtási kliensek](/developers/docs/nodes-and-clients/#execution-clients) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" new file mode 100644 index 00000000000..b6654f87528 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" @@ -0,0 +1,258 @@ +--- +title: Blokk felfedezők +description: Egy bevezetés a blokkfelfedezőkbe, a blokklánc adatok portáljába, ahol információs lekérdezéseket indíthatsz tranzakciókról, számlákról, szerződésekről és más egyébről. +lang: hu +sidebarDepth: 3 +--- + +A blokkfelfedezők a portálod az Ethereum adataihoz. Használatukkal valós idejű adatokat kaphat a blokkokról, tranzakciókról, validátorokról, számlákról és más on-chain tevékenységekről. + +## Előfeltételek {#prerequisites} + +Először meg kellene értened az Ethereum alapvető fogalmait ahhoz, hogy értelmezni tudd az adatokat, melyet egy blokkfelfedező biztosít neked. Kezdjen itt: [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/). + +## Szolgáltatások {#services} + +- [Etherscan](https://etherscan.io/) –_ elérhető kínai, koreai, orosz és japán nyelven is_ +- [3xpl](https://3xpl.com/ethereum) +- [Beaconcha.in](https://beaconcha.in/) +- [Blockchair](https://blockchair.com/ethereum) –_ Spanyol, francia, olasz, holland, portugál, orosz, kínai és fárszi nyelven is elérhető_ +- [Blockscout](https://eth.blockscout.com/) +- [Chainlens](https://www.chainlens.com/) +- [DexGuru Block Explorer](https://ethereum.dex.guru/) +- [Etherchain](https://www.etherchain.org/) +- [Ethernow](https://www.ethernow.xyz/) +- [Ethplorer](https://ethplorer.io/) –_Kínai, spanyol, francia, török, orosz, koreai és vietnámi nyelven is elérhető_ +- [EthVM](https://www.ethvm.com/) +- [OKLink](https://www.oklink.com/eth) +- [Rantom](https://rantom.app/) +- [Ethseer](https://ethseer.io) + +## Nyílt forráskódú eszközök {#open-source-tools} + +- [Otterscan](https://otterscan.io/) +- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) + +## Adat {#data} + +Az Ethereum tervezése folytán transzparens, így minden ellenőrizhető. A blokkfelfedezők egy felületet biztosítanak, hogy ez az információ elérhető legyen. És ez igaz az Ethereum főhálózatára és a teszt hálózatokra, ha szükséged van az adatokra. Az adatok végrehajtási adatokra és konszenzusadatokra oszthatók. A „végrehajtási adatok” megnevezés egy konkrét blokkban végrehajtott tranzakciókra vonatkoznak. A „konszenzusadatok” megnevezés magukra a blokkokra és a blokkokat előterjesztő validátorokra vonatkozik. + +Itt egy összefoglaló azokról az adatokról, melyet egy blokkfelfedezőről megszerezhetsz. + +### Végrehajtási adatok {#execution-data} + +Az Ethereum hálózata minden 12 másodpercben új blokkal bővül (kivéve, ha a blokkelőterjesztő elszalasztja a lehetőségét), így van egy közel állandó adatfolyam, amely hozzáadódik a blokkfelfedezőkhöz. A blokkok sok fontos adatot tartalmaznak, melyeket hasznosnak találhatsz: + +**Standard adat** + +- Blokkmagasság – a blokklánc hossza és a benne foglalt blokkok száma (blokkokban kifejezve) az aktuális blokk létrehozásakor. +- Időbélyegző – a blokkjavaslat megjelenésének időpontja. +- Tranzakciók – a blokkban foglalt tranzakciók száma. +- Díj címzettje – az a cím, amely a tranzakciókból származó gasdíjtételeket megkapta. +- Blokkjutalom – a blokkot előterjesztő validátornak megítélt ETH-összeg. +- Méret – a blokkban foglalt adat mérete (bájtban kifejezve). +- Felhasznált gas – a teljes gasmennyiség, amelyet a blokkban foglalt tranzakciók felhasználtak. +- Gaskorlátozás – a blokkban foglalt tranzakciók által beállított teljes gaskorlátozás. +- Alapdíj/gas – az a minimumszorzó, amely egy tranzakció felvételéhez szükséges az adott blokkba. +- Elégetett díjak – a blokkban elégetett ETH mennyisége. +- Extra adat – Bármely extra adat, amelyet a blokképítő belefoglalt a blokkba + +**Haladó adat** + +- Hash – a kriptográfiai hash, amely a blokkfejlécét adja (a blokk egyedi azonosítója). +- Anyahash – az aktuális blokk előtt kiadott blokk hashértéke. +- StateRoot – A Merkle-fa gyökérhash-értéke, amely a rendszer teljes állapotát tárolja. + +### Üzemanyag {#gas} + +A blokkfelfedezők nemcsak a tranzakciók és blokkok gasfelhasználásáról adnak információt, hanem némelyik a hálózat aktuális gasárairól is tájékoztat. Ez segít megérteni a hálózathasználatot, biztonságos tranzakciókat indítani, és nem túlkölteni a gast. Keressen olyan API-kat, amelyek segítenek felvinni ezt az információt a terméke felületére. A gasspecifikus adat a következőket fedi le: + +- A biztonságos, de lassú tranzakcióhoz szükséges gasmennyiség becslése (+ becsült ár és idő) +- Az átlagos tranzakcióhoz szükséges gasmennyiség becslése (+ becsült ár és idő) +- A gyors tranzakcióhoz szükséges gasmennyiség becslése (+ becsült ár és idő) +- Átlagos megerősítési idő a gasár alapján +- gasfogyasztó szerződések – más szóval olyan népszerű termékek, amelyeket sokat használnak a hálózaton. +- gasköltő számlák – más szóval a rendszeres hálózathasználók. + +### Tranzakciók {#transactions} + +A blokkfelfedezők bevett eszközzé váltak az emberek kezében, hogy nyomon kövessék a tranzakcióik alakulását. Ennek az az oka, hogy az elérhető részletesség extra bizonyosságot nyújt. A tranzakcióadatok a következőket tartalmazzák: + +**Standard adatok** + +- Tranzakcióhash – a tranzakció elküldésekor a rendszer által generált hashérték. +- Állapot – jelzés arról, hogy a tranzakció függőben van, meghiúsult vagy sikeres volt. +- Blokk – a blokk, amely a tranzakciót tartalmazza. +- Időbélyegző – Annak időpontja, amikor a tranzakció bekerült a blokkba, melyet a validátor javasolt +- Feladó (From) – a tranzakciót elküldő számla címe. +- Címzett (To) – a fogadó fél vagy az okosszerződés címe, amellyel a tranzakció interakcióba lép. +- Átutalt tokenek – olyan tokenekből álló lista, amelyek át lettek utalva a tranzakcióban. +- Érték – Az átutalt ETH összértéke. +- Tranzakciós díj – A validátornak fizetett összeg, hogy feldolgozza a tranzakciót (számítása: gázár * felhasznált gáz) + +**Részletes adatok** + +- Gaskorlátozás – a gasegységek maximális száma, amelyet ez a tranzakció elfogyaszthat. +- Felhasznált gas – a tényleges gasmennyiség, amelyet ez a tranzakció elfogyasztott. +- Gasár – egy gasegységre beállított ár. +- Nonce – a `from` cím tranzakciószáma (ne feledje, hogy a számozás nullánál kezdődik, így a `100`-as nonce valójában az adott számláról küldött 101. tranzakciót jelenteni). +- Bemeneti adat – a tranzakció által megkövetelt bármely extra adat. + +### Számlák {#accounts} + +Egy adott számláról rengeteg adat elérhető. Ezért gyakran javasoljuk több számla használatát, hogy az eszközök és az érték ne legyen könnyen követhető. Vannak azonban fejlesztés alatt álló megoldások, amelyek nagyobb védelmet nyújtanak a tranzakció- és számlaadatoknak. De most nézzük meg a számlákról elérhető adatokat: + +**Felhasználói számlák** + +- Számlacím – a nyilvános cím, amelyre pénzt küldhet. +- ETH egyenleg – a számlához tartozó ETH mennyisége. +- Teljes ETH érték – az ETH értéke. +- Tokenek – a számlához tartozó tokenek és értékeik. +- Tranzakciótörténet – az összes tranzakciót tartalmazó lista, ahol a számla volt a küldő vagy a címzett. + +**Okosszerződések** + +Az okosszerződés-számlák rendelkeznek az összes adattal, amivel a felhasználói számlák is, de némelyik blokkfelfedező némi kódinformációt is szolgáltat. Többek között például: + +- Szerződés létrehozója – a cím, amelyik feltöltötte a szerződést a fő hálózatra. +- Létrehozó tranzakció – a tranzakció, amely tartalmazta a telepítést a fő hálózatra. +- Forráskód – az okosszerződés solidity vagy vyper kódja. +- Szerződés ABI – a szerződés Application Binary Interface-e (alkalmazásprogramozói interfésze) – a szerződés általi hívásokat és a kapott adatokat tartalmazza. +- Szerződés létrehozási kódja – az okosszerződés lefordított bájtkódja – akkor jön létre, amikor Ön Solidityben vagy Vyperben stb. írt okosszerződést fordít. +- Szerződésesemények – az okosszerződésben lehívott módszerek előzményei. Alapvetően azt mutatja meg, hogyan és milyen gyakran használják a szerződést. + +### Tokenek {#tokens} + +A token egy szerződéstípus, így az okosszerződésekhez hasonló adatokkal rendelkezik. De mivel van értéke és lehet vele kereskedni, ezért további adatpontjai is vannak: + +- Típus – lehet ERC-20, ERC-721 vagy más tokenszabvány. +- Árfolyam – ha egy ERC-20, akkor van aktuális piaci értéke. +- Piaci kapitalizáció – ha ERC-20, akkor van piaci kapitalizációja (számítása: árfolyam × teljes kínálat). +- Teljes kínálat – a forgalomban lévő tokenek száma. +- Tulajdonosok – a tokent birtokló címek száma. +- Átutalások – a számlák közötti tokenátutalások esetszáma. +- Tranzakciótörténet – az adott tokent tartalmazó összes korábbi tranzakció. +- Szerződéscím – a fő hálózatra feltelepített token címe. +- Tizedesjegyek – az ERC-20 tokenek oszthatók és vannak tizedes helyeik. + +### Hálózat {#network} + +Egyes blokkadatok holisztikusabb módon foglalkoznak az Ethereum-hálózat egészségével. + +- Összes tranzakció – az Ethereum létrehozása óta végbement összes tranzakció száma. +- Tranzakció/másodperc – az egy másodperc alatt feldolgozható tranzakciók száma. +- ETH-árfolyam – 1 ETH aktuális értéke. +- Teljes ETH-kínálat – a forgalomban lévő ETH-mennyiség – ne feledje, hogy minden egyes blokk létrejöttével új ETH jön létre blokkjutalom formájában. +- Piaci kapitalizáció – számítása: árfolyam × kínálat. + +## Konszenzusréteg-adatok {#consensus-layer-data} + +### Korszak {#epoch} + +Biztonsági okokból minden korszak végén (vagyis 6,4 percenként) véletlenszerűen összeállított validátorbizottságok jönnek létre. A korszakadatok a következőket tartalmazzák: + +- Korszak száma +- Véglegesített állapot – véglegessé vált-e a korszak (Igen/Nem). +- Idő – az idő, amikor véget ért a korszak. +- Tanúsítások – a korszakon belüli tanúsítások száma (szavazás blokkokra a slotokon belül). +- Letétek – a korszakban foglalt ETH-letétek száma (a validátoroknak ETH-t kell letenniük, hogy validátorok lehessenek). +- Megvágások – a blokkelőterjesztőknek és tanúsítóknak kirótt büntetések száma. +- Szavazási részvétel – a letétbe helyezett ETH-mennyiség, amelyet blokktanúsításra használtak. +- Validátorok – a korszakban aktív validátorok száma. +- Átlagos validátoregyenleg – az aktív validátorok átlagos egyenlege. +- Slotok – a korszakban lévő slotok száma (a slotok egy érvényes blokkot tartalmaznak). + +### Slot {#slot} + +A slotok blokklétrehozási lehetőségek. Az egyes slotokra elérhető adat a következőket tartalmazza: + +- Korszak – a korszak, amelyben érvényes a slot. +- Slot száma +- Állapot – a slot állapota (javasolt/kihagyott). +- Idő – a slot időbélyegzője. +- Előterjesztő – a validátor, aki javasolta a blokkot a slotba. +- Blokkgyökér – a BeaconBlock hash-fa-gyökere. +- Anyagyökér – a megelőző blokk hashértéke. +- Állapotgyökér – a BeaconState hash-fa-gyökere. +- Aláírás +- Randao megjelenítés +- Graffiti – a blokkelőterjesztő belefoglalhat egy 32 bájt hosszú üzenetet a blokkjavaslatába. +- Végrehajtási adatok + - Blokkhash + - Letétszám + - Letétgyökér +- Tanúsítások – a tanúsítások száma a slotban erre a blokkra. +- Letétek – a letétek száma a slot alatt. +- Önkéntes kilépők – a kilépő validátorok száma a slot alatt. +- Megvágások – a blokkelőterjesztőknek és tanúsítóknak kirótt büntetések száma. +- Szavazatok – a validátorok, akik a blokkra szavaztak ebben a slotban. + +### Blokkok {#blocks-1} + +A proof-of-stake mechanizmus az időt slotokra és korszakokra osztja. Tehát ez új adatokat jelent! + +- Előterjesztő – az a validátor, akit algoritmussal választott ki a rendszer, hogy új blokkra tegyen javaslatot. +- Korszak – a korszak, amelyben a blokkot előterjesztették. +- Slot – a slot, amelyben a blokkot előterjesztették. +- Tanúsítások – a slotban foglalt tanúsítások száma. A tanúsítások olyanok, mint a szavazatok, amelyek azt jelzik, hogy a blokk már továbbítható a Beacon láncra. + +### Validátorok {#validators} + +A validátorok felelnek a blokkok előterjesztéséért és tanúsításáért a slotokon belül. + +- Validátorszám – egyedi szám, amely a validátort jelöli. +- Aktuális egyenleg – a validátor egyenlege a jutalmakkal együtt. +- Tényleges egyenleg – a validátor letéthez használt egyenlege. +- Bevétel – a validátor által kapott jutalmak vagy büntetések. +- Állapot – éppen online és aktív a validátor, vagy sem. +- Tanúsítási hatékonyság – az átlagos idő, amely a validátor tanúsításának lánchoz adásához szükséges. +- Aktiválási jogosultság – dátum (és korszak), amikor a validátor számára elérhetővé vált a validálás. +- Aktív ettől – dátum (és korszak), amikor a validátor aktívvá vált. +- Javasolt blokkok – a validátor által előterjesztett blokkok. +- Tanúsítások – a validátor által biztosított tanúsítások. +- Letétek – a küldő címe, a tranzakció hashértéke, a blokk száma, időbélyegzője, a validátori letét összege és állapota. + +### Tanúsítások {#attestations} + +A tanúsítások „igen” szavazatok arra, hogy a blokkot a lánchoz adják. Az adataik kapcsolódnak a tanúsítások nyilvántartásához és a tanúsító validátorokhoz. + +- Slot – a slot, amelyben a tanúsítás történt. +- Bizottságindex – a bizottság indexe az adott slotban. +- Összesítő bitek – az aggregált tanúsítást mutatja a tanúsításban részt vevő minden validátorra. +- Validátorok – a tanúsításokat szolgáltató validátorok. +- Beacon-blokkgyökér – arra a blokkra mutat, amelyet a validátorok tanúsítanak. +- Forrás – a legutolsó igazolt korszakra mutat. +- Cél – a legutolsó korszakhatárra mutat. +- Aláírás + +### Hálózat {#network-1} + +A konszenzusréteg felső szintű adatai a következők: + +- Aktuális korszak +- Aktuális slot +- Aktív validátorok – aktív validátorok száma. +- Függőben lévő validátorok – az aktiválásra váró validátorok száma. +- Letétbe helyezett ETH – a hálózaton letétbe helyezett ETH-mennyiség. +- Átlagos egyenleg – a validátorok átlagos ETH-egyenlege. + +## Blokk felfedezők {#block-explorers} + +- [Etherscan](https://etherscan.io/) – egy blokkfelfedező, amelyben adatokat kérhet le az Ethereum-főhálózatról és a Goerli tesztelőhálózatról. +- [3xpl](https://3xpl.com/ethereum) - reklámmentes nyílt forráskódú Ethereum felfedező, melyből le lehet tölteni az adatokat +- [Beaconcha.in](https://beaconcha.in/) – egy nyílt forráskódú blokkfelfedező az Ethereum főhálózatra és a Goerli teszthálózatra +- [Blockchair](https://blockchair.com/ethereum) – a legdiszkrétebb Ethereum-felfedező. Alkalmas (memóriakészlet) adatok szűrésére és válogatására is +- [Etherchain](https://www.etherchain.org/) – egy Ethereum-főhálózati blokkfelfedező +- [Ethplorer](https://ethplorer.io/) – egy blokkfelfedező, amely az Ethereum-főhálózaton és a Kovan tesztelőhálózaton található tokenekre fókuszál +- [Rantom](https://rantom.app/) – egy felhasználóbarát, nyílt forráskódú DeFi- és NFT-tranzakciómegtekintő a részletesebb betekintéshez +- [Ethernow](https://www.ethernow.xyz/) – egy valós idejű tranzakciókereső, amely lehetővé teszi az Ethereum főhálózat lánc előtti rétegének megtekintését + +## További olvasnivaló {#further-reading} + +_Ismer olyan közösségi információforrást, amely a hasznára vált? Módosítsa az oldalt, és adja hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Tranzakciók](/developers/docs/transactions/) +- [Fiókok](/developers/docs/accounts/) +- [Hálózatok](/developers/docs/networks/) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" new file mode 100644 index 00000000000..c043605dfd2 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" @@ -0,0 +1,55 @@ +--- +title: Adat és elemzések +description: Hogyan használjon on-chain elemzéseket és adatokat a dappjában +lang: hu +--- + +## Bevezetés {#Introduction} + +Ahogy a hálózat használata tovább fejlődik, a láncon belüli adatokban egyre növekszik az értékes információk mennyisége. Az adatok mennyiségének gyors növekedésével sok idő és kapacitás kell ahhoz, hogy ezeket az információkat kalkulálni és aggregálni tudjuk, hogy riportálható legyen vagy egy alkalmazást vezéreljen. + +A jelenlegi adatszolgáltatók használata előmozdíthatja a fejlesztést, sokkal pontosabb eredményeket adhat és csökkentheti a fenntartáshoz szükséges erőfeszítéseket. Ezáltal a fejlesztők koncentrálhatnak a projektjük fő funkcionalitására, melyet elérhetővé szeretnének tenni. + +## Előfeltételek {#prerequisites} + +Érdemes áttekinteni a [blokkfelfedezők](/developers/docs/data-and-analytics/block-explorers/) alapkoncepcióját, hogy hogyan használhatók adatelemzési területen. Emellett az [index](/glossary/#index) koncepciójának megértése is fontos, hogy egyértelművé váljon, a rendszerterv részeként milyen előnyöket hozhat. + +Az architektúra alapjaiból fontos ismerni, mi az az [API](https://www.wikipedia.org/wiki/API) és a [REST](https://www.wikipedia.org/wiki/Representational_state_transfer), akár csak elméletben. + +## Blokk felfedezők {#block-explorers} + +Néhány [blokkfelfedező](/developers/docs/data-and-analytics/block-explorers/) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API)-kapcsolatokat ajánl, hogy a fejlesztőknek rálátásuk legyen a blokkok, tranzakciók, validátorok, számlák és más láncon folyó tevékenységek aktuális adataira. + +A fejlesztők ezáltal ezeket az adatokat feldolgozzák és átalakítják, hogy a felhasználóiknak egyedi rálátásuk legyen a [blokkláncra](/glossary/#blockchain) és interakcióba léphessenek vele. Például az [Etherscan](https://etherscan.io) végrehajtási és konszenzusok adatokat biztosít minden 12 másodperces slotról. + +## The Graph {#the-graph} + +A [Graph Network](https://thegraph.com/) egy decentralizált indexáló protokoll a blokkláncadatok összerendezésére. Ahelyett, hogy láncon kívüli és centralizált adattárházakat építenének és menedzselnének a láncon belüli adatok aggregálására, a The Graph révén a fejlesztők szerver nélküli alkalmazásokat építhetnek, melyek teljes mértékben nyilvános infrastruktúrán működnek. + +A [GraphQL](https://graphql.org/) lekérdezési nyelv használatával a fejlesztők lekérdezhetik bármelyik gondozott, nyílt API-t, más néven algráfot (subgraph), hogy megszerezzék az alkalmazás működéséhez szükséges információkat. Az indexált algráfok lekérdezésével a riportok és alkalmazások nemcsak teljesítmény- és skálázási előnyhöz jutnak, hanem a hálózati konszenzus által biztosított adathelyességet is élvezhetik. A hálózatba kerülő új fejlesztésekkel és algráfokkal az Ön projektje is gyorsan előnyt kovácsolhat ezekből az újdonságokból. + +## Kliensdiverzitás + +A [kliensdiverzitás](/developers/docs/nodes-and-clients/client-diversity/) rendkívül fontos az egész Ethereum-hálózat átfogó egészsége szempontjából, mivel védelmet biztosít a hibák és támadások ellen. Számos kliensdiverzitásról szóló kimutatás elérhető, mint a [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) és az [Ethernodes](https://ethernodes.org/). + +## Dune-elemzések {#dune-analytics} + +A [Dune-elemzések](https://dune.com/) előre feldolgozzák a blokkláncadatokat relációs adatbázistáblákba (DuneSQL), hogy a felhasználók lekérdezhessék a blokklánc adatait SQL segítségével és ennek eredményéből további kimutatásokat építhessenek. A láncon lévő adatok 4 nyerstáblába rendeződnek: `blocks` (blokkok), `transactions` (tranzakciók), `logs` (eseménynaplózás) és `traces` (meghívások nyomai). A népszerű szerződéseket és protokollokat dekódolják, és mindegyik rendelkezik a maga eseményeket és meghívásokat tartalmazó tábláival. Ezeket az esemény- és hívástáblákat tovább dolgozzák és absztrakciós táblákba szervezik a protokollok típusa szerint, mint amilyen a DEX, kölcsönzés, stabilérmék stb. + +## SubQuery hálózat {#subquery-network} + +A [SubQuery](https://subquery.network/) egy vezető adatindexelő, amely gyors, megbízható, decentralizált és testreszabott API-okat biztosít a fejlesztőknek web3 projektjeikhez. A SubQuery több mint 165 ökoszisztéma (beleértve az Ethereumot is) fejlesztőinek ad lehetőséget indexált adatokkal, hogy intuitív és magával ragadó élményt nyújtsanak felhasználóiknak. A SubQuery Network egy rugalmas és decentralizált infrastrukturális hálózattal támogatja a megállíthatatlan alkalmazásokat. Használja a SubQuery blokklánc fejlesztői eszköztárát a jövő web3 alkalmazásainak létrehozásához, anélkül, hogy időt kellene fordítania az adatfeldolgozási tevékenységekhez szükséges egyedi backend létrehozására. + +A kezdéshez látogasson el az [Ethereum gyors kezdés útmutatóhoz](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html), hogy percek alatt elkezdhesse az Ethereum blokkláncadatok indexelését egy helyi Docker-környezetben tesztelés céljából, mielőtt élesben elindulna egy [SubQuery menedzselt szolgáltatáson](https://managedservice.subquery.network/) vagy [SubQuery decentralizált hálózaton](https://app.subquery.network/dashboard). + +## Ethernow - Mempool Data Program {#ethernow} +A [Blocknative](https://www.blocknative.com/) nyílt hozzáférést biztosít az Ethereum historikus [mempool adatarchívumához](https://www.ethernow.xyz/mempool-data-archive). Ez lehetővé teszi a kutatók és a közösségi célú projektek számára, hogy feltárják az Ethereum főhálózat lánc előtti rétegét. Az adatkészletet folyamatosan karbantartják, és az Ethereum ökoszisztémán belül ez adja a mempool tranzakciós események legátfogóbb historikus nyilvántartását. Tudjon meg többet az [Ethernow](https://www.ethernow.xyz/) működéséről. + +## További olvasnivaló {#further-reading} + +- [A gráfhálózat áttekintése](https://thegraph.com/docs/en/about/network/) +- [Gráflekérdezési próbafelület (playground)](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [API-kódpéldák az EtherScan oldalon](https://etherscan.io/apis#contracts) +- [Beaconcha.in – Beaconlánc-felfedező](https://beaconcha.in) +- [A Dune alapjai](https://docs.dune.com/#dune-basics) +- [SubQuery Ethereum gyors használati útmutató](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" new file mode 100644 index 00000000000..7a9fa7487e3 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" @@ -0,0 +1,73 @@ +--- +title: Fejlesztői hálózatok +description: Áttekintés az fejlesztői hálózatokról és az eszközökről, melyek segítségével Ethereum applikációk fejleszthetőek. +lang: hu +--- + +Amikor okosszerződéseket tartalmazó Ethereum alkalmazást épít, fontos, hogy egy lokális hálózaton lefuttassa azt, hogy megnézze hogyan működik telepítés előtt. + +Hasonlóan ahhoz, amikor egy lokális szervert futtat a számítógépén webfejlesztés céljából, használhat fejlesztői hálózatokat egy lokális blokkláncpéldány létrehozásához, ahol tesztelheti a dappot. Ezek az Ethereum fejlesztői hálózatok olyan tulajdonságokkal rendelkeznek, melyek lehetővé teszik a gyorsabb iterációt, mint egy nyilvános teszthálózat (például nem kell azzal bajlódnia, hogy ETH-t szerezz egy teszthálózati csapból). + +## Előfeltételek {#prerequisites} + +Először meg kell értenie az [Ethereum stack alapjait](/developers/docs/ethereum-stack/) és az [Ethereum hálózatokat](/developers/docs/networks/) mielőtt elmélyedne a fejlesztői hálózatokban. + +## Mi a fejlesztői hálózat? {#what-is-a-development-network} + +A fejlesztői hálózatok lényegében olyan Ethereum kliensek (Ethereum implementációk), melyeket kimondottan a lokális fejlesztéshez terveztek. + +**Miért ne futtassunk standard Ethereum csomópontot lokálisan?** + +_Akár _ [saját csomópontot is futtathat](/developers/docs/nodes-and-clients/#running-your-own-node), de mivel a fejlesztői hálózatok célzottan a fejlesztésre vannak létrehozva, olyan kényelmi funkciók is be vannak építve, mint például: + +- A lokális blokklánc determinisztikus feltöltése adatokkal (például számlák ETH egyenleggel) +- Azonnali blokklétrehozás minden egyes megkapott tranzakciónál, sorrendben és késés nélkül +- Fejlett hibakeresés és naplózási funkciók + +## Elérhető eszközök {#available-projects} + +**Megjegyzés**: A legtöbb [fejlesztői keretrendszer](/developers/docs/frameworks/) egy beépített fejlesztői hálózatot tartalmaz. Ajánljuk, hogy egy keretrendszer segítségével [állítsa be a helyi fejlesztési környezetét](/developers/local-environment/). + +### Hardhat Network {#hardhat-network} + +Egy helyi Ethereum hálózat fejlesztésre tervezve. Szerződéseket telepíthet, teszteket futtathat, hibakeresést és javítást végezhet a kódján. + +A Hardhat Network a beépített Hardhat-tel jön, ami egy Ethereum fejlesztői környezet szakembereknek. + +- [Honlap](https://hardhat.org/) +- [GitHub](https://github.com/nomiclabs/hardhat) + +### Helyi Beacon láncok {#local-beacon-chains} + +Néhány konszenzusos kliens rendelkezik olyan beépített eszközökkel, amellyel fel lehet állítani helyi Beacon láncokat a teszteléshez. Elérhető instrukciók a Lighthouse, Nimbus és Lodestar kliensekhez: + +- [Helyi teszthálózat a Lodestarhoz](https://chainsafe.github.io/lodestar/usage/local/) +- [Helyi teszthálózat a Lighthouse-hoz](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) +- [Helyi teszthálózat a Nimbushoz](https://github.com/status-im/nimbus-eth1/blob/master/fluffy/docs/local_testnet.md) + +### Nyilvános Ethereum-tesztláncok {#public-beacon-testchains} + +Az Ethereum két karbantartott, nyilvános tesztimplementációval is rendelkezik: Goerli és Sepolia. A Goerli a javasolt teszthálózat, mely hosszú távú támogatással bír, és mindenkinek ingyenesen használható validálásra. A Sepolia egy újabb, kisebb lánc, melyet szintén fenn akarnak tartani a jövőben, és amelynek része egy engedélyhez kötött validátorszett (nem működhet bárki validátorként). A Ropsten lánc 2022. 4. negyedévében, a Rinkeby lánc pedig 2023. 2./3. negyedévében kerül lezárásra. + +- [Goerli letétbe helyezési indítópult](https://goerli.launchpad.ethereum.org/) +- [Ropsten, Rinkeby és Kiln kivezetési bejelentés](https://blog.ethereum.org/2022/06/21/testnet-deprecation) + +### Kurtosis Ethereum csomag {#kurtosis} + +A Kurtosis egy felépített rendszer a több konténeres tesztkörnyezetekhez, amellyel a fejlesztők lokálisan felállíthatják a reprodukálható példányait a blokklánchálózatoknak. + +Az Ethereum Kurtosis csomag segítségével gyorsan létrehozható egy paraméterezhető, nagymértékben skálázható és privát Ethereum teszthálózat a Docker vagy a Kubernetes segítségével. A csomag támogatja az összes főbb végrehajtási (EL) és konszenzusréteg (CL) klienst. A Kurtosis elegánsan kezeli az összes helyi port hozzárendelést és szolgáltatáskapcsolatot egy reprezentatív hálózathoz, amelyet az Ethereum fő infrastruktúrával kapcsolatos validálási és tesztelési munkafolyamatokban lehet használni. + +- [Ethereum hálózati csomag](https://github.com/kurtosis-tech/ethereum-package) +- [Honlap](https://www.kurtosis.com/) +- [GitHub](https://github.com/kurtosis-tech/kurtosis) +- [Dokumentáció](https://docs.kurtosis.com/) + +## További olvasnivaló {#further-reading} + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) +- [Helyi fejlesztői környezet felállítása](/developers/local-environment/) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" new file mode 100644 index 00000000000..b6f21851595 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" @@ -0,0 +1,61 @@ +--- +title: Bevezetés az Ethereum stack-be +description: Egy áttekintő az Ethereum stack különböző rétegeiről és arról, hogyan illenek egymásba. +lang: hu +--- + +Mint bármely szoftverstack, az „Ethereum-stack” is változni fog projektről projektre az Ön céljaitól függően. + +Vannak azonban alap Ethereum technológiák, melyek segítenek egy mentális modellt szolgáltatni arról, hogy a szoftver alkalmazások hogyan lépnek interakcióba az Ethereum blokklánccal. A stack rétegeinek megértése segíteni fog megérteni az Ethereum szoftver projektekbe történő integrálásának különböző módjait. + +## Első szint: Ethereum Virtuális Gép {#ethereum-virtual-machine} + +Az [Ethereum virtuális gép (EVM)](/developers/docs/evm/) egy futtatókörnyezet az Ethereumon az okosszerződések számára. Az Ethereum blokkláncon minden okosszerződést és állapot változást [tranzakciók](/developers/docs/transactions/) hajtanak végre. Az EVM kezeli az összes tranzakció feldolgozását az Ethereum hálózaton. + +Mint bármilyen virtuális gép esetében, az EVM egy absztrakciós szintet hoz létre a kód végrehajtás és a végrehajtó gép (egy Ethereum csomópont) között. Az EVM jelenleg több ezer csomóponton fut szerte a világban. + +A háttérben az EVM opcode utasítások sorozatát használja meghatározott feladatok végrehajtásához. Ez a (140 egyedi) operációs kód lehetővé teszi az EVM számára, hogy [Turing-teljes](https://en.wikipedia.org/wiki/Turing_completeness) legyen, tehát az EVM bármit ki tud számolni, ha elég erőforrás áll rendelkezésre. + +Dapp fejlesztőként nem kell sokat tudnod az EVM-ről azon kívül, hogy létezik és megbízhatóan működteti az összes Ethereum alkalmazást állásidő nélkül. + +## Második szint: Okosszerződések {#smart-contracts} + +Az [okosszerződések](/developers/docs/smart-contracts/) olyan futtatható programok, melyek az Ethereum blokkláncon futnak. + +Az okosszerződéseket specifikus [programozási nyelveken](/developers/docs/smart-contracts/languages/) írják, melyek EVM bájtkódra fordítódnak (alacsony szintű gépi instrukciók, melyeket opcode-nak nevezünk). + +Az okosszerződések nem csak nyílt forráskódú könyvtáraknak felelnek meg, hanem lényegében nyílt API szolgáltatásokként működnek, melyek 24/7-ben futnak és nem lehet őket leállítani. Az okosszerződések nyilvános függvényeket szolgáltatnak, amelyeket a felhasználók és az alkalmazások ([dappok](/developers/docs/dapps/)) engedély nélkül meghívhatnak. Bármelyik alkalmazás összekapcsolható a működő okosszerződésekkel, hogy valamilyen funkcionalitást alkosson, mint például [adatok használata](/developers/docs/oracles/), illetve támogassa a tokenek átváltását. Bárki telepíthet új okosszerződéseket az Ethereumra, hogy tetszőleges funkcionalitást adjon, mely egyezik az alkalmazás szükségleteivel. + +Dapp fejlesztőként csak akkor kell okosszerződéseket írnia, ha szeretne egyedi funkciókat hozzáadni az Ethereum blokklánchoz. Hamar rájöhetsz, hogy a projekted legtöbb célját elérheted csupán a létező okosszerződések integrálásával, például ha szeretnéd használni a stablecoin fizetéseket vagy lehetővé tenni a tokenek decentralizált cseréjét. + +## Harmadik szint: Ethereum csomópontok {#ethereum-nodes} + +Ahhoz, hogy az alkalmazás az Ethereum-blokklánccal működni tudjon, egy [Ethereum-csomóponthoz](/developers/docs/nodes-and-clients/) kell kapcsolódnia. Egy ilyen csomópont lehetővé teszi, hogy elérje a blokkláncon lévő adatokat és/vagy tranzakciókat küldjön a hálózatnak. + +Az Ethereum csomópontok egy szoftvert - Ethereum klienst - futtató számítógépek. Egy kliens egy Ethereum implementáció, mely hitelesíti az összes tranzakciót az egyes blokkokban, így a hálózat biztonságos marad az adatok pedig pontosak. **Az Ethereum-csomópontok összessége az Ethereum-blokklánc**. Kollektívan tárolják az Ethereum blokklánc állapotát és konszenzust érnek el a tranzakciókon, melyek a blokklánc állapotot megváltoztatják. + +Hogyha összekapcsolja az alkalmazást egy Ethereum-csomóponttal ([JSON RPC-n](/developers/docs/apis/json-rpc/) keresztül), akkor az alkalmazás képes lesz adatokat leolvasni a blokkláncról (például felhasználóiszámla-egyenlegek), illetve új tranzakciókat közvetíteni a hálózatra (például ETH-átutalás felhasználói számlák között, illetve okosszerződés-függvények futtatása). + +## Négyes szint: Ethereum kliens API-ok {#ethereum-client-apis} + +Sok kényelmi könyvtár (melyet az Ethereum nyílt forráskódú közössége fejleszt és tart karban) lehetővé teszi a végfelhasználói alkalmazásodnak, hogy rácsatlakozzon és kommunikáljon az Ethereum blokklánccal. + +Ha a felhasználó oldali alkalmazásod egy web app, akkor érdemes `npm install`-lal telepítened egy [JavaScript API-t](/developers/docs/apis/javascript/) közvetlenül a frontendedre. Vagy lehet, hogy érdemesebb ezt a funkcionalitást a szerver oldalon implementálni egy [Python](/developers/docs/programming-languages/python/) vagy egy [Java](/developers/docs/programming-languages/java/) API-on keresztül. + +Annak ellenére, hogy ezek az API-ok nem szükséges elemei a stack-nek, sok komplexitást egyszerűsítenek le, amikor egy Ethereum csomóponttal szeretnénk kommunikálni. Ezen kívül használati függvényeket is szolgáltatnak (pl.: ETH konvertálása Gwei-be), így fejlesztőként kevesebb időt kell az Ethereum kliensek bonyodalmaival foglalkoznod és több időd jut egyedi funkcionalitást kialakítani az alkalmazásodnak. + +## Ötös szint: Végfelhasználói alkalmazások {#end-user-applications} + +A stack tetején a felhasználó oldali alkalmazások állnak. Ezek a standard alkalmazások, melyeket rendszeresen használsz és fejlesztesz manapság: főleg web és mobil alkalmazások. + +Ahogy ezeket a felhasználói felületeket fejleszted lényegében nem változott. Gyakran a felhasználóknak nem kell tudniuk arról, hogy az alkalmazás amit használnak, egy blokkláncot használ. + +## Készen áll kiválasztani a stacket? {#ready-to-choose-your-stack} + +Nézze meg az útmutatónkat, hogy[felállítson egy helyi fejlesztői környezetet](/developers/local-environment/) az Ethereum alkalmazásának. + +## További olvasnivaló {#further-reading} + +- [A web 3.0 alkalmazások architektúrája](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ + +_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" new file mode 100644 index 00000000000..58675256c7a --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" @@ -0,0 +1,149 @@ +--- +title: Dapp Fejlesztői Keretrendszerek +description: Fedezd fel a keretrendszerek tulajdonságait és hasonlítsd össze az elérhető lehetőségeket. +lang: hu +--- + +## Bevezetés a keretrendszerekbe {#introduction-to-frameworks} + +Egy teljes értékű dapp fejlesztése több technológiát is igényel. A szoftver keretrendszerek sok szükséges funkciót tartalmaznak, vagy egyszerű plugin rendszereket biztosítanak, melyek segítenek kiválasztani a kívánt eszközt. + +A keretrendszerek olyan dobozon-kívüli funkciókat kínálnak, melyekkel: + +- Felállíthatsz vele egy helyi blokkláncot. +- Eszközök az okos szerződéseid fordítására és tesztelésére. +- Kliens fejlesztési addonok, hogy ugyanabban a projektben/repóban fejleszthess felhasználói alkalmazásokat. +- Ethereum hálózatokhoz és szerződések telepítésére való konfiguráció, legyen az helyileg futó instance vagy valamelyik publikus Ethereum hálózat. +- Decentralizált app elosztás - IPFS-hez hasonló tárhely integrációk. + +## Előfeltételek {#prerequisites} + +Mielőtt elmerülne a keretrendszerekben, javasoljuk, hogy olvassa át a bevezetés a [dappokba](/developers/docs/dapps/) és a [Ethereum stack](/developers/docs/ethereum-stack/) cikkeket. + +## Elérhető keretrendszerek {#available-frameworks} + +**Foundry** – **_A Foundry egy gyors, hordozható és moduláris eszközrendszer az Ethereum alkalmazásfejlesztésre._** + +- [Foundry telepítése](https://book.getfoundry.sh/) +- [Foundry könyv](https://book.getfoundry.sh/) +- [Foundry közösségi csevegés Telegramon](https://t.me/foundry_support) +- [Lenyűgöző Foundry](https://github.com/crisgarner/awesome-foundry) + +**Hardhat -** **_Ethereum fejlesztői környezet profiknak._** + +- [hardhat.org](https://hardhat.org) +- [GitHub](https://github.com/nomiclabs/hardhat) + +**Ape -** **_Az okosszerződés-fejlesztői eszköz a pythonisták, adattudósok és biztonsági szakértők számára._** + +- [Dokumentáció](https://docs.apeworx.io/ape/stable/) +- [GitHub](https://github.com/ApeWorX/ape) + +**Web3j -** **_Platform a blokklánc alkalmazások fejlesztésére a JVM-n._** + +- [Honlap](https://www.web3labs.com/web3j-sdk) +- [Dokumentáció](https://docs.web3j.io) +- [GitHub](https://github.com/web3j/web3j) + +ethers-kt – **_Async, nagy teljesítményű Kotlin/Java/Android könyvtár EVM-alapú blokkláncokhoz._** + +- [GitHub](https://github.com/Kr1ptal/ethers-kt) +- [Példák](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) +- [Discord](https://discord.gg/rx35NzQGSb) + +**Create Eth App -** **_Készítsen Ethereum-alapú appokat egy paranccsal. UI-keretrendszerek és DeFi-sablonok széles választék._** + +- [GitHub](https://github.com/paulrberg/create-eth-app) +- [Sablonok](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates) + +**Scaffold-Eth -** **_Ethers.js + Hardhat + React komponensek és hook-ok web3-hoz: minden, amire szükség van, hogy el tudjon kezdeni okosszerződések által működtetett decentralizált alkalmazásokat fejleszteni._** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) + +**Tenderly -** **_Web3 fejlesztői platform, amely lehetővé teszi a blokklánc-fejlesztőknek, hogy okosszerződéseket építsenek, teszteljenek, debuggoljanak, felügyeljenek és üzemeltessenek, illetve fejlesszék a dapp UX-t._** + +- [Honlap](https://tenderly.co/) +- [Dokumentáció](https://docs.tenderly.co/ethereum-development-practices) + +**The Graph -** **_Blokkláncadatok hatékony lekérdezése a The Graph segítségével._** + +- [Honlap](https://thegraph.com/) +- [Útmutató](/developers/tutorials/the-graph-fixing-web3-data-querying/) + +**Alchemy -** **_Ethereum Fejlesztési Platform._** + +- [alchemy.com](https://www.alchemy.com/) +- [GitHub](https://github.com/alchemyplatform) +- [Discord](https://discord.com/invite/alchemyplatform) + +**NodeReal -** **_Ethereum fejlesztői platform._** + +- [Nodereal.io](https://nodereal.io/) +- [GitHub](https://github.com/node-real) +- [Discord](https://discord.gg/V5k5gsuE) + +**thirdweb SDK -** **_Építsen web3 alkalmazásokat, amelyek interakcióba lépnek az okosszerződésével az erőteljes SDK-kat és CLI-t használva._** + +- [Dokumentáció](https://portal.thirdweb.com/sdk/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Chainstack -** **_Web3 (Ethereum és egyéb) fejlesztői platform._** + +- [chainstack.com](https://www.chainstack.com/) +- [GitHub](https://github.com/chainstack) +- [Discord](https://discord.gg/BSb5zfp9AT) + +**Crossmint -** **_Vállalat szintű web3 fejlesztési platform, amely lehetővé teszi, hogy NFT alkalmazásokat építsen minden nagyobb EVM (és más) láncra._** + +- [Honlap](https://www.crossmint.com) +- [Dokumentáció](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +**Brownie -** **_Python-alapú fejlesztői környezet és tesztelési keretrendszer._** + +- [Dokumentáció](https://eth-brownie.readthedocs.io/en/latest/) +- [GitHub](https://github.com/eth-brownie/brownie) +- **A Brownie karbantartása jelenleg szünetel** + +**OpenZeppelin SDK -** **_The Ultimate Smart Contract Toolkit: egy eszköztár okosszerződések fejlesztéséhez, összeállításához, továbbfejlesztéséhez, telepítéséhez és az okosszerződésekkel való interakciókhoz._** + +- [OpenZeppelin SDK](https://openzeppelin.com/sdk/) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk) +- [Közösségi Fórum](https://forum.openzeppelin.com/c/support/17) +- **Az OpenZeppelin SDK fejlesztése befejeződött** + +**Catapulta -** **_Több láncos okosszerződések telepítési eszköze, automatizálja az ellenőrzéseket a blokkfelfedezőkben, nyomon követi a telepített okosszerződéseket és megosztja a telepítési jelentéseket, plug-n-play a Foundry és Hardhat projektekhez._** + +- [Honlap](https://catapulta.sh/) +- [Dokumentáció](https://catapulta.sh/docs) +- [Github](https://github.com/catapulta-sh) + +**Covalent –** **_Gazdagított blokklánc API-ok 200+ lánchoz._** + +- [covalenthq.com](https://www.covalenthq.com/) +- [Dokumentáció](https://www.covalenthq.com/docs/api/) +- [GitHub](https://github.com/covalenthq) +- [Discord](https://www.covalenthq.com/discord/) + +**Wake -** **_Minden az egyben Python keretrendszer a szerződéseknek a teszteléshez, fuzzinghoz, telepítéshez, sebezhetőségi vizsgálathoz és kódnavigációhoz._** + +- [Honlap](https://getwake.io/) +- [Dokumentáció](https://ackeeblockchain.com/wake/docs/latest/) +- [GitHub](https://github.com/Ackee-Blockchain/wake) +- [VS Code Extension](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) + +**Veramo -** **_Egy nyílt forráskódú, moduláris és agnosztikus keretrendszer, amely megkönnyíti a decentralizált alkalmazások fejlesztői számára a decentralizált identitások és ellenőrizhető hitelesítő adatok beépítését az alkalmazásaikba._** + +- [Honlap](https://veramo.io/) +- [Dokumentáció](https://veramo.io/docs/basics/introduction) +- [GitHub](https://github.com/uport-project/veramo) +- [Discord](https://discord.com/invite/FRRBdjemHV) +- [NPM csomag](https://www.npmjs.com/package/@veramo/core) + +## További olvasnivaló {#further-reading} + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Helyi fejlesztői környezet felállítása](/developers/local-environment/) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" new file mode 100644 index 00000000000..cc50ecb9db6 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" @@ -0,0 +1,64 @@ +--- +title: Integrált Fejlesztői Környezetek (IDE-k) +description: +lang: hu +--- + +Amikor egy [integrált fejlesztői környezet (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) felállításáról van szó, az Ethereumon történő fejlesztés hasonló bármely más szoftveres projekthez. Sok lehetőség közül lehet választani, ezért azt az IDE-t vagy kódszerkesztőt válassza, amely a legjobban megfelel a preferenciáinak. Nagy valószínűséggel a legjobb IDE az Ethereum fejlesztéséhez éppen az, amit a hagyományos szoftverfejlesztéshez is használ. + +## Web alapú IDE-k {#web-based-ides} + +Ha szeretne eljátszani a kóddal, mielőtt [felállítana egy helyi fejlesztői környezetet](/developers/local-environment/), a következő webes alkalmazások az Ethereum okosszerződések fejlesztésére letteki kialakítva. + +**[Remix](https://remix.ethereum.org/)** – **_Webalapú IDE beépített statikus analízissel, és egy teszt blokklánc virtuális géppel._** + +- [Dokumentáció](https://remix-ide.readthedocs.io/en/latest/#) +- [Gitter](https://gitter.im/ethereum/remix) + +**[ChainIDE](https://chainide.com/)** – **_Egy felhőalapú, többláncos IDE_** + +- [Dokumentáció](https://chainide.gitbook.io/chainide-english-1/) +- [Súgófórum](https://forum.chainide.com/) + +**[Replit (Solidity Starter – Beta)](https://replit.com/@replit/Solidity-starter-beta)** – **_Testre szabható fejlesztői környezet az Ethereum számára, gyors újratöltéssel, hibaellenőrzéssel és első osztályú testnet-támogatással_** + +- [Dokumentáció](https://docs.replit.com/) + +**[Tenderly Sandbox](https://sandbox.tenderly.co/)** – **_Gyors prototípus-készítő környezet, ahol okosszerződéseket tud írni, elindítani és debuggolni a böngészőben Solidity-t és JavaScriptet használva_** + +**[EthFiddle](https://ethfiddle.com/)** – **_Webalapú IDE, amivel megírhatja, összeállíthatja és debuggolhatja okosszerződéseit_** + +- [Gitter](https://gitter.im/loomnetwork/ethfiddle) + +## Asztali IDE-k {#desktop-ides} + +A legtöbb megalapozott IDE-nek vannak beépített pluginjai, amelyek tovább fokozzák az Ethereum fejlesztői élményt. Legalább egy syntax kijelölést biztosítanak az [okosszerződés nyelveknek](/developers/docs/smart-contracts/languages/). + +**Visual Studio Code -** **_Professzionális keresztplatformos IDE hivatalos Ethereum-támogatással_** + +- [Visual Studio Code](https://code.visualstudio.com/) +- [Kódminták](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md) +- [GitHub](https://github.com/microsoft/vscode) + +**JetBrains IDE-k (IntelliJ IDEA, etc.) –** **_Elengedhetetlen eszközök szoftverfejlesztőknek és csapatoknak_** + +- [JetBrains](https://www.jetbrains.com/) +- [GitHub](https://github.com/JetBrains) +- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/) + +**Remix Desktop – ** **_Próbálja ki a Remix IDE-t a saját gépén_** + +- [Letöltés](https://github.com/ethereum/remix-desktop/releases) +- [GitHub](https://github.com/ethereum/remix-desktop) + +## Plugin-ok és kiterjesztések {#plugins-extensions} + +- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) – Ethereum Solidity nyelv a Visual Studio-kódhoz +- [Solidity + Hardhat for VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) – Solidity és Hardhat a Hardhat csapat által támogatva +- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) – Kódformázó használata + +## További olvasnivaló {#further-reading} + +- [Ethereum IDEs](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _ – Alchemy listája az Ethereum IDE-okról_ + +_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" new file mode 100644 index 00000000000..92e02f00860 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" @@ -0,0 +1,28 @@ +--- +title: Ethereum Dart-fejlesztők számára +description: Sajátítsa el az Ethereum-fejlesztést a Dart programozási nyelv használatával +lang: hu +incomplete: true +--- + +## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} + +## Oktatóanyagok {#tutorials} + +- [Flutter és blokklánc – Hello World Dapp](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) átvezeti Önt a kezdeti lépéseken: + 1. Okosszerződés megírása [Solidity](https://soliditylang.org/) nyelven + 2. Felhasználói felület megírása Dart nyelven +- A [mobilalkalmazások építése a Flutterrel](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) sokkal rövidebb, amely jobb lehet, ha már ismeri az alapokat +- Ha videók segítségével jobban szeret tanulni, akkor nézze meg az [Építse meg első blokkláncos Flutter alkalmazását](https://www.youtube.com/watch?v=3Eeh3pJ6PeA) videót, amely nagyjából egy óra hosszú +- Ha ennél kevesebb ideje van, akkor talán tetszeni fog az [Egy blokklánc decentralizált alkalmazás építése a Flutterrel és a Darttal az Ethereumon](https://www.youtube.com/watch?v=jaMFEOCq_1s) videó, amely csak húsz percet veszi igénybe +- [A MetaMask integrációja a Flutter alkalmazásban a WalletConnect által nyújtott Web3Modal használatával](https://www.youtube.com/watch?v=v_M2buHCpc4) – ez a rövid videó bemutatja, hogyan kell a MetaMaskot beintegrálni a Flutter alkalmazásokba a [Web3Modal](https://pub.dev/packages/web3modal_flutter) könyvtárral, melyet a WalletConnect biztosít +- [Mobil blokkláncfejlesztői képzés Solidity-val és Flutterrel](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) – mobil blokkláncfejlesztői tanfolyam a teljes stack-kel (lejátszási lista) + +## Munka Ethereum kliensekkel {#working-with-ethereum-clients} + +Az Ethereumot decentralizált alkalmazások (dappok) fejlesztésére használhatja, amelyek a kriptovaluták és a blokklánc-technológia nyújtotta összes előnyét kiélvezhetik. A Darthoz legalább két könyvtárat tartanak karban, hogy a [JSON-RPC API-t](/developers/docs/apis/json-rpc/) használja az Ethereumra. + +1. [Web3dart a simonbutler.eu forrásból](https://pub.dev/packages/web3dart) +1. [Ethereum 5.0.0 a darticulate.com forrásból](https://pub.dev/packages/ethereum) + +Vannak még emellett olyan könyvtárak is, amelyekkel bizonyos Ethereum címeket lehet kezelni, vagy különféle kriptovaluták árait lehet lekérdezni. [Ezek teljes listája itt látható](https://pub.dev/dart/packages?q=ethereum). diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" new file mode 100644 index 00000000000..aa8c739a3d4 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" @@ -0,0 +1,56 @@ +--- +title: Ethereum Delphi-fejlesztők számára +description: Tanulja meg az Ethereum fejlesztést a Delphi programozási nyelv használatával +lang: hu +incomplete: true +--- + + + +Tanulja meg az Ethereum fejlesztést a Delphi programozási nyelv használatával + + + +Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. + +Fejlesszen decentralizált alkalmazásokat Ethereumra, és lépjen interakcióba okosszerződésekkel a Delphi programozási nyelv használatával! + +## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-the-solidity-language} + +**Tegye meg az első lépést, hogy integrálja a Delphi-t az Ethereummal** + +Szükséged van egy még kezdetlegesebb alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. + +- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Referenciák és hivatkozások kezdők számára {#beginner-references-and-links} + +**Bevezetés a Delphereum könyvtárba** + +- [Mi az a Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md) +- [A Delphi összekapcsolása egy lokális (in-memory) blokklánccal](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) +- [Delphi összekapcsolása az Ethereum főhálózattal](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83) +- [Delphi összekapcsolása okosszerződésekkel](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1) + +**Szeretné kihagyni a telepítést, és egyenesen a mintákra ugrani?** + +- [3 perces okosszerződés és Delphi - Első rész](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) +- [3 perces okosszerződés és Delphi - Második rész](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) + +## Köztes cikkek {#intermediate-articles} + +- [Egy Ethereumon aláírt üzenetaláírás generálása Delphi-ben](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) +- [Ether átutalás Delphi-vel](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4) +- [ERC-20 token átutalás Delphi-vel](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d) + +## Speciális használati minták {#advanced-use-patterns} + +- [Delphi és az Ethereum Name Service (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) +- [QuikNode, Ethereum és Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23) +- [Delphi és az Ethereumi sötét erdő](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) +- [Tokenátváltás a Delphiben](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7) + +Még több anyagot keresel? Tekintsd meg az [ethereum.org/developers](/developers/) oldalt. diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" new file mode 100644 index 00000000000..ebd7aedeba5 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" @@ -0,0 +1,86 @@ +--- +title: Ethereum .NET-fejlesztők számára +description: Tanuljon meg Ethereumon fejleszteni .NET-alapú projektek és eszközök használatával +lang: hu +incomplete: true +--- + +Tanuljon meg Ethereumon fejleszteni .NET-alapú projektek és eszközök használatával + +Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. + +Építsen decentralizált alkalmazásokat Ethereumra és lépjen kapcsolatba okosszerződésekkel a Microsoft tech stack használatával, mely támogatja a C#, # Visual Basic .NET, F# nyelveket VSCode és Visual Studio eszközökkel a .NET Framework/.NET Core/.NET Standard-on keresztül. Telepítsen percek alatt egy Ethereum blokkláncot Azure-ra a Microsoft Azure Blockchain használatával. Hozza el a .NET szeretetét az Ethereumra! + +## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-the-solidity-language} + +**Tegye meg az első lépést, hogy integrálja a .NET-et az Ethereummal** + +Szükséged van egy még kezdetlegesebb alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. + +- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Referenciák és hivatkozások kezdők számára {#beginner-references-and-links} + +**Bemutatjuk a Nethereum könyvtárat és a VS Code Solidity-t** + +- [Nethereum, Első Lépések](https://docs.nethereum.com/en/latest/getting-started/) +- [VS Code Solidity Telepítése](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) +- [Egy .NET fejlesztő workflow-ja Ethereum Okosszerződések írására és hívására](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) +- [Okosszerződés integráció Nethereummal](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) +- [A .NET és az Ethereum blokklánc okosszerződések interfészelése a Nethereummal](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), elérhető kínai verzió: [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1) +- [Nethereum – Egy nyílt forráskódú .NET integrációs könyvtár blokkláncra](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) +- [Ethereum tranzakciók írása SQL adatbázisba Nethereum használatával](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) +- [Nézze meg, hogy lehet egyszerűen Ethereum okosszerződéseket telepíteni C# és VisualStudio használatával](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) + +**Szeretnéd kihagyni a telepítést és egyenesen a mintákra ugrani?** + +- [Playground](http://playground.nethereum.com/) - Lépjen kapcsolatba az Ethereummal, és tanulja meg a Nethereum használatát a böngészőn keresztül. + - Számlaegyenleg Lekérdezés [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001) + - ERC20 Okosszerződés Egyenleglekérdezés [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004) + - Ether utalása egy számlára [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003) + - ... És még sok más! + +## Köztes cikkek {#intermediate-articles} + +- [Nethereum Munkafüzet/Minta Lista](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/) +- [Telepítse saját fejlesztői tesztláncait](https://github.com/Nethereum/Testchains) +- [VSCode Codegen Plugin Solidity-re](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/) +- [Unity és Ethereum: Miért és hogyan](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) +- [Készítsen ASP.NET Core Web API-t Ethereum dappokra](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) +- [A Nethereum Web3 használata egy ellátási lánc nyomon követési rendszer implementálására](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4) +- [Nethereum blokk feldolgozás](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/), egy[ C# Playground mintával](http://playground.nethereum.com/csharp/id/1025) +- [Nethereum Websocket Streaming](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/) +- [Kaleido és Nethereum](https://kaleido.io/kaleido-and-nethereum/) +- [Quorum és Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md) + +## Speciális használati minták {#advanced-use-patterns} + +- [Azure Key Vault és Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum) +- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid) +- [Ujo Nethereum backend referencia architektúra](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/) + +## .NET projektek, eszközök és más érdekes dolgok {#dot-net-projects-tools-and-other-fun-stuff} + +- [Nethereum Playground](http://playground.nethereum.com/) - _Fordítson, készítsen és futtasson Nethereum kódrészleteket böngészőben_ +- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Nethereum kódgenerátor UI-jal Blazor-ben_ +- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _A .NET Wasm SPA könnyű blokklánc felfedező és egyszerű tárca_ +- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) - _Egy üzleti szabályokat alkalmazó program (a .NET és az Ethereum platformra is), mely örökletesen metaadat vezérelt._ +- [Nethermind](https://github.com/NethermindEth/nethermind) – _A .NET Core Ethereum-kliens Linux, Windows, macOS rendszerhez_ +- [eth-utils](https://github.com/ethereum/eth-utils/) - _használati funkciók Ethereumhoz kapcsolódó kódbázisokkal való munkához_ +- [TestChains](https://github.com/Nethereum/TestChains) - _Előre konfigurált .NET fejlesztői láncok gyors válaszra (PoA)_ + +Még több anyagot keresel? Tekintsd meg az [ethereum.org/developers](/developers/) oldalt. + +## .NET közösségi közreműködők {#dot-net-community-contributors} + +Mi a Nethereumon főleg a [Gitteren](https://gitter.im/Nethereum/Nethereum) kommunikálunk, ahol bárki nyugodtan kérdezhet/válaszolhat, segítséget kaphat vagy csak velünk lehet. Bátran készítsen egy PR-t vagy nyisson egy „problémát” (issue) a [Nethereum Github mappában](https://github.com/Nethereum), vagy csak böngésszen a rengeteg mellék-/mintaprojektjeink között. Megtalál minket [Discord-on](https://discord.gg/jQPrR58FxX) is! + +Ha Önnek új a Nethermind és segítségre van szüksége a kezdéshez, akkor csatlakozzon a [Discord](http://discord.gg/PaCMRFdvWT) csatornánkhoz. Fejlesztőink készséggel válaszolnak a kérdéseire. PR-okért vagy issue-kért tekintse meg a [Nethermind Github mappát](https://github.com/NethermindEth/nethermind). + +## Egyéb összesített listák {#other-aggregated-lists} + +[Hivatalos Nethereum Oldal](https://nethereum.com/) +[Hivatalos Nethermind Oldal](https://nethermind.io/) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/elixir/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/elixir/index.md" new file mode 100644 index 00000000000..4b187418e5a --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/elixir/index.md" @@ -0,0 +1,55 @@ +--- +title: Ethereum Elixir-fejlesztők számára +description: Tanuljon meg Ethereumra fejleszteni Elixir-alapú projektek és eszközök használatával. +lang: hu +incomplete: false +--- + +Tanuljon meg Ethereumra fejleszteni Elixir-alapú projektek és eszközök használatával. + +Használjon Ethereumot decentralizált alkalmazások (dappok) fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok nem igényelnek bizalmat a felhasználó oldaláról, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel az újfajta pénzügyi alkalmazások számra. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. + +## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} + +**Tegye meg az első lépést, hogy integrálja a Elixirt az Ethereummal** + +Szüksége van egy kezdőknek szóló bevezetőre? Tekintse meg az [ethereum.org/learn](/learn/) vagy az [ethereum.org/developers](/developers/) oldalakat. + +- [Blokklánc magyarázat](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Okosszerződések megértése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Írja meg első okosszerződését](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Tanulja meg a Solidity átfordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Cikkek kezdőknek {#beginner-articles} + +- [Az Ethereum számlák megértése](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Ethers — Elsőrangú Ethereum web3 könyvtár az Elixirhez](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122) + +## Cikkek középhaladóknak {#intermediate-articles} + +- [Hogyan lehet nyers Ethereum szerződéses tranzakciót aláírni az Elixirrel](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b) +- [Ethereum okosszerződések és az Elixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4) + +## Elixir projektek és eszközök {#elixir-projects-and-tools} + +### Aktív {#active} + +- [block_keys](https://github.com/ExWeb3/block_keys) - _BIP32 & BIP44 implementáció Elixirben (többszámlás hierarchia a determinisztikus tárcákhoz)_ +- [ethereumex](https://github.com/mana-ethereum/ethereumex) - _Elixir JSON-RPC kliens az Ethereum blokklánchoz_ +- [ethers](https://github.com/ExWeb3/elixir_ethers) - _Egy átfogó web3 könyvtár az Ethereum-on lévő okosszerődésekkel való interakcióra az Elixirrel_ +- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) - _Egy KMS aláíró könyvtár az Ethers-hez (a tranzakciók aláírása AWS KMS révén)_ +- [ex_abi](https://github.com/poanetwork/ex_abi) - _Ethereum ABI értelmező/dekódoló/kódoló implementáció Elixirben_ +- [ex_keccak](https://github.com/ExWeb3/ex_keccak) - _Elixir könyvtár a Keccak SHA3-256 hash-ek kiszámolásához egy NIF által épített mini-keccak Rust tároló használatával_ +- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) - _Az Ethereum RLP (Rekurzív hosszúságú prefixum) kódolásának Elixir implementációja_ + +### Archivált / a karbantartás megszűnt {#archived--no-longer-maintained} + +- [eth](https://hex.pm/packages/eth) - _Ethereum szolgáltatások az Elixirhez_ +- [exw3](https://github.com/hswick/exw3) - _Magas szintű Ethereum RPC kliens az Elixirhez_ +- [mana](https://github.com/mana-ethereum/mana) - _Ethereum teljes csomópont implementáció Elixir nyelven írva_ + +Több anyagra lenne szüksége? Tekintse meg [Fejlesztői kezdőlapot](/developers/). + +## Elixir közösségi közreműködők {#elixir-community-contributors} + +Az [Elixir Slack #ethereum channel](https://elixir-lang.slack.com/archives/C5RPZ3RJL) egy gyorsan növekvő közösség szervezője, egy dedikált erőforrás a fenti projektek és kapcsolódó témák megvitatására. diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" new file mode 100644 index 00000000000..613a92534fa --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" @@ -0,0 +1,84 @@ +--- +title: Ethereum Go fejlesztőknek +description: Tanuljon meg Ethereumra fejleszteni Go-alapú projektek és eszközök használatával +lang: hu +incomplete: true +--- + +Tanuljon meg Ethereumra fejleszteni Go-alapú projektek és eszközök használatával + +Használja az Ethereumot decentralizált alkalmazások (dappok) fejlesztésére. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Decentralizáltak, ami azt jelenti, hogy egy peer-to-peer hálózaton futnak és nincs lehetőség egyetlen hiba miatti leállásra (single point of failure). Nincs olyan entitás vagy személy, ami irányítaná őket és szinte lehetetlen őket cenzúrázni. Digitális eszközöket irányíthatnak, lehetőséget teremtve ezzel újfajta alkalmazások létrejöveteléhez. + +## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} + +**Tegye meg az első lépést, hogy integrálja a Go-t az Ethereummal** + +Szükséged van egy méginkább kezdőknek szóló alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. + +- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) +- [Szerződésútmutató](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) + +## Cikkek és könyvek kezdőknek {#beginner-articles-and-books} + +- [Kezdő lépések Geth-tel](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458) +- [Golang használata Ethereumra való kapcsolódásra](https://www.youtube.com/watch?v=-7uChuO_VzM) +- [Ethereum okosszerződések telepítése Golang használatával](https://www.youtube.com/watch?v=pytGqQmDslE) +- [Egy útmutató, arról, hogy hogyan kell Ethereum okosszerződéseket tesztelni és telepíteni lépésről lépésre](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) +- [eBook: Ethereum fejlesztése a Go-val](https://goethereumbook.org/) – _Ethereum alkalmazások fejlesztése Go-val_ + +## Cikkek és dokumentációk haladóknak {#intermediate-articles-and-docs} + +- [Go Ethereum dokumentácó](https://geth.ethereum.org/docs/) – _A hivatalos Ethereum Golang dokumentáció_ +- [Erigon útmutató programozóknak](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) – _Illusztrált útmutató, amely bemutatja az állapotfát, többszöri bizonyítékokat és a tranzakciófeldolgozást_ +- [Erigon és a státuszmentes Ethereum](https://youtu.be/3-Mn7OckSus?t=394) – _2020-as Ethereum Közösségi Konferencia (EthCC 3)_ +- [Erigon: Ethereum-kliensek optimalizálása](https://www.youtube.com/watch?v=CSpc1vZQW2Q) – _2018. Devcon 4_ +- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum) +- [Egy dapp készítése Go-ban a Geth segítségével](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) +- [Dolgozzon az Ethereum privát hálózaton a Golanggal és Geth-tel](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) +- [Solidity szerződések egységtesztje az Ethereumon a Go-val](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) +- [Gyors hivatkozás, hogyan használja a Geth-t könyvtárként](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e) + +## Speciális használati minták {#advanced-use-patterns} + +- [A GETH szimulált Backend](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) +- [A blokklánc mint szolgáltatás alkalmazások az Ethereum és a Quorum használatával](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) +- [Elosztott tárhely IPFS és Swarm az Ethereum blokklánc alkalmazásokban](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) +- [Mobilkliensek: könyvtárak és inproc Ethereum csomópontok](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) +- [Natív dappok: Go-megkötések az Ethereum szerződésekre](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) + +## Go-projektek és -eszközök {#go-projects-and-tools} + +- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _Az Ethereum protokoll hivatalos Go implementációja_ +- [Go Ethereum Code Analysis](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Go Ethereum forráskód áttekintése és elemzése_ +- [Erigon](https://github.com/ledgerwatch/erigon) – _A Go Ethereum gyorsabb változata, mely az archív csomópontokra fókuszál_ +- [Golem](https://github.com/golemfactory/golem) - _A Golem egy globális piacot teremt a számítási teljesítmény számára_ +- [Quorum](https://github.com/jpmorganchase/quorum) - _Egy engedélyköteles Ethereum implementáció, mely támogatja az adatvédelmet_ +- [Prysm](https://github.com/prysmaticlabs/prysm) - _Ethereum 'Serenity' 2.0 Go implementáció_ +- [Eth Tweet](https://github.com/yep/eth-tweet) - _Decentralizált Twitter: Egy mikroblogolási szolgáltatás, mely az Ethereum blokkláncon fut_ +- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _A Minimum Viable Plasma specifikációjának Golang implementációja és kiterjesztése_ +- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) - _Egy nyílt forráskódú Ethereum bányászalap_ +- [Ethereum HD Wallet](https://github.com/miguelmota/go-ethereum-hdwallet) - _Ethereum HD Wallet levezetések Go-ban_ +- [Multi Geth](https://github.com/multi-geth/multi-geth) - _Az Ethereum hálózatok több fajtáját támogatja_ +- [Geth Light Client](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Light Ethereum Subprotocol Geth implementációja_ +- [Ethereum Golang SDK](https://github.com/everFinance/goether) – _Egy egyszerű Ethereum-tárcaimplementáció és eszközök Golangban_ +- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _hatékony blokklánc-adatelérés Go SDK-n keresztül 200+ blokklánchoz_ + +Még több anyagot keresel? Tekintse meg az [ethereum.org/developers](/developers/) oldalt + +## Go közösségi hozzájárulók {#go-community-contributors} + +- [Geth Discord](https://discordapp.com/invite/nthXNEv) +- [Geth Gist](https://gitter.im/ethereum/go-ethereum) +- [Gophers Slack](https://invite.slack.golangbridge.org/) - [#ethereum channel](https://gophers.slack.com/messages/C9HP1S9V2) +- [StackExchange - Ethereum](https://ethereum.stackexchange.com/) +- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth) +- [Ethereum Gitter](https://gitter.im/ethereum/home) +- [Geth light Client Gitter](https://gitter.im/ethereum/light-client) + +## Egyéb összesített listák {#other-aggregated-lists} + +- [Awesome Ethereum](https://github.com/btomashvili/awesome-ethereum) +- [Consensys: Az Ethereum fejlesztői eszközök döntő listája](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [GitHub forrás](https://github.com/ConsenSys/ethereum-developer-tools-list) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" new file mode 100644 index 00000000000..f5f16f24c7e --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" @@ -0,0 +1,30 @@ +--- +title: Programozási nyelvek +description: +lang: hu +--- + +Egy általános félreértés az, hogy a fejlesztőknek [okosszerződéseket](/developers/docs/smart-contracts/) kell írniuk ahhoz, hogy az Ethereumra építhessenek. Ez nem igaz. Az Ethereum hálózat és közösség egyik szépsége, hogy szinte bármiyen programozási nyelvvel [részt lehet venni](/community/). + +Az Ethereum és a közössége befogadja az nyílt forráskódot. Közösségi projekteket – kliens implementációkat, API-okat, fejlesztési keretrendszereket, tesztelő eszközöket – sokféle különböző nyelven is megtalálhat. + +## Válasszon nyelvet {#data} + +Válasszon nyelvet, hogy megtalálja a kapcsolódó projekteket, anyagokat és a virtuális közösségeket: + +- [Ethereum Dart-fejlesztők számára](/developers/docs/programming-languages/dart/) +- [Ethereum Delphi fejlesztőknek](/developers/docs/programming-languages/delphi/) +- [Ethereum .NET fejlesztőknek](/developers/docs/programming-languages/dot-net/) +- [Ethereum Elixir-fejlesztők számára](/developers/docs/programming-languages/elixir/) +- [Ethereum Go fejlesztőknek](/developers/docs/programming-languages/golang/) +- [Ethereum Java fejlesztőknek](/developers/docs/programming-languages/java/) +- [Ethereum JavaScript fejlesztőknek](/developers/docs/programming-languages/javascript/) +- [Ethereum Python-fejlesztők számára](/developers/docs/programming-languages/python/) +- [Ethereum Ruby-fejlesztők számára](/developers/docs/programming-languages/ruby/) +- [Ethereum Rust fejlesztőknek](/developers/docs/programming-languages/rust/) + +### Mi a helyzet, ha az én nyelvem nem támogatott {#other-lang} + +Ha egy másik programozói nyelvhez szeretne forrásokat megjeleníteni vagy egy virtuális közösséget feltüntetni, akkor úgy kérhet új oldalt, hogy [egy „problémát” (issue) nyit](https://github.com/ethereum/ethereum-org-website/issues/new/choose). + +Ha csak kódot szeretne írni, hogy a blokklánccal kapcsolatba lépjen, és egy jelenleg nem támogatott nyelvet használ erre, akkor a [JSON-RPC interfésszel](/developers/docs/apis/json-rpc/) tud az Ethereum hálózatához kapcsolódni. Minden olyan nyelv alkalmas erre, amelyik képes TCP/IP használatra. diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" new file mode 100644 index 00000000000..b32ffe1dacb --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" @@ -0,0 +1,65 @@ +--- +title: Ethereum Java-fejlesztők számára +description: Tanuljon meg Ethereumon fejleszteni Java alapú projektek és eszközök használatával +lang: hu +incomplete: true +--- + +Tanuljon meg Ethereumon fejleszteni Java alapú projektek és eszközök használatával + +Használjon Ethereumot decentralizált alkalmazások (dappok) fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. + +## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} + +**Tegye meg az első lépést, hogy a Java-t integrálja az Ethereummal** + +Szüksége van egy kezdőknek szóló bevezetőre? Tekintse meg az [ethereum.org/learn](/learn/) vagy az [ethereum.org/developers](/developers/) oldalt. + +- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Írja meg az első okosszerződését](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Tanulja meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Az Ethereum-kliensek használata {#working-with-ethereum-clients} + +Tanulja meg a [Web3J](https://github.com/web3j/web3j) és a Hyperledger Besu, a két vezető Java Ethereum kliens használatát + +- [Csatlakozás Ethereum klienshez Java-val, Eclipse-szel és Web3J-vel](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j) +- [Egy Ethereum számla kezelése Java-val és Web3J-vel](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j) +- [Generáljon egy Java Wrappert az okosszerződéséből](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) +- [Kapcsolódás egy Ethereum okosszerződéshez](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) +- [Ethereum okosszerződés események hallgatása](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) +- [Besu (Pantheon), a Java Ethereum kliens használata Linux-szal](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) +- [Egy Hyperledger Besu (Pantheon) csomópont futtatása Java integrációs teszteken](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) +- [Web3j Puska](https://kauri.io/web3j-cheat-sheet-(java-ethereum)/5dfa1ea941ac3d0001ce1d90/c) + +Ismerje meg az [ethers-kt](https://github.com/Kr1ptal/ethers-kt) használatát, ami egy aszinkron, nagy teljesítményű Kotlin könyvtár az EVM-alapú blokkláncokkal való interakcióhoz. JVM és Android platformokat céloz meg. +- [ERC-20 tokenek transzferje](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt) +- [UniswapV2 átváltás eseményfigyeléssel](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt) +- [ETH / ERC-20 egyenlegkövetés](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt) + +## Köztes cikkek {#intermediate-articles} + +- [Tárhelykezelés Java alkalmazásokban IPFS-szel](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs) +- [ERC20 tokenek kezelése Java-ban Web3j-vel](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j) +- [Web3j tranzakciókezelők](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers) + +## Speciális használati minták {#advanced-use-patterns} + +- [Ethereum használata Java okosszerződés adat cache építésére](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache) + +## Java-projektek és -eszközök {#java-projects-and-tools} + +- [Hyperledger Besu (Pantheon) (Ethereum kliens)](https://docs.pantheon.pegasys.tech/en/stable/) +- [Web3J (könyvtár az Ethereum kliensekkel való interakcióhoz)](https://github.com/web3j/web3j) +- [ethers-kt (aszinkron, nagy teljesítményű Kotlin/Java/Android könyvtár EVM-alapú blokkláncokhoz)](https://github.com/Kr1ptal/ethers-kt) +- [Eventeum (Event Listener)](https://github.com/ConsenSys/eventeum) +- [Mahuta (IPFS Fejlesztői Eszközök)](https://github.com/ConsenSys/mahuta) + +Több anyagra lenne szüksége? Tekintsd meg az [ethereum.org/developers](/developers/) oldalt + +## Java közösségi hozzájárulók {#java-community-contributors} + +- [IO Builders](https://io.builders) +- [Kauri](https://kauri.io) +- [Besu HL chat](https://chat.hyperledger.org/channel/besu) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" new file mode 100644 index 00000000000..bca0b0fc20e --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" @@ -0,0 +1,73 @@ +--- +title: Ethereum JavaScript fejlesztőknek +description: Tanuljon meg Ethereumon fejleszteni JavaScript alapú projektek és eszközök használatával. +lang: hu +--- + +A Javascript a legnépszerűbb nyelvek között van az Ethereum ökoszisztémában. Valójában van egy [csapat](https://github.com/ethereumjs), mely célul tűzte ki, hogy a lehető legtöbb Ethereumot vigye be a JavaScriptbe. + +Lehetőség van JavaScriptet írni (vagy valami hasonlót) a [stack összes szintjén](/developers/docs/ethereum-stack/). + +## Interakció az Ethereummal {#interact-with-ethereum} + +### JavaScript API könyvtárak {#javascript-api-libraries} + +Ha JavaScriptet szeretne írni a blokklánc lekérdezéséhez, tranzakció küldéséhez vagy máshoz, akkor ennek a legkézenfekvőbb módja egy [JavaScript API könyvtár](/developers/docs/apis/javascript/) használata. Ezek az API-k lehetővé teszik a fejlesztőknek, hogy interakcióba lépjenek az [Ethereum-hálózat csomópontjaival](/developers/docs/nodes-and-clients/). + +Ezekkel a könyvtárakkal okosszerződésekkel léphet kapcsolatba az Ethereumon, így létre lehet hozni egy dappot, ahol elég csak a JavaScriptet használni már létező okosszerződésekkel történő interakcióhoz. + +**Nézze meg** + +- [Web3.js](https://web3js.readthedocs.io/) +- [Ethers.js](https://docs.ethers.io/) _– tartalmaz egy Ethereum tárca implementációt és más segédprogramokat JavaScriptben és TypeScriptben._ +- [viem](https://viem.sh) – egy TypeScript interfész az Ethereumhoz, amely alacsony szintű, státuszmentes alapokat biztosít az Ethereummal való interakcióhoz. + +### Okosszerződések {#smart-contracts} + +Ha Ön Javascript-fejlesztő, és szeretné megírni saját okosszerződését, akkor érdemes megismerkednie a [Solidity-vel](https://solidity.readthedocs.io). Ez a legnépszerűbb okosszerződésnyelv, és szintaktikailag hasonló a JavaScript-hez, ami miatt könnyebb lehet elsajátítani azt. + +Többet az [okosszerződésekről](/developers/docs/smart-contracts/). + +## Értse meg a protokollt {#understand-the-protocol} + +### Az Ethereum virtuális gép (EVM) {#the-ethereum-virtual-machine} + +Az [Ethereum virtuális géphez](/developers/docs/evm/) létezik egy JavaScript-implementáció is. Támogatja a legfrissebb elágazási (fork) szabályokat. Az elágazási szabályok az EVM-en végzett tervezett frissítésekből adódó szabályok. + +Különböző JavaScript csomagokra oszlik, amelyeket áttekinthet a jobb megértés érdekében: + +- Számlák +- Blokkok +- A blokklánc maga +- Tranzakciók +- És még sok más... + +Ez segít megérteni olyan dolgokat, mint például, „mi a számla adatstruktúrája”. + +Ha inkább el szeretné olvasni a kódot, ez a JavaScript nagyszerű alternatíva lehet a dokumentumaink áttekintéséhez. + +**Nézze meg a kapcsolódó mappát** +[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-vm) + +### Csomópontok és kliensek {#nodes-and-clients} + +Az Ethereumjs kliens aktív fejlesztés alatt áll, így Önnek lehetősége van elmélyedni abban, hogyan működnek az Ethereum-kliensek az Ön által ismert nyelven: JavaScript-ben! + +Korábban egy különálló [`mappában`](https://github.com/ethereumjs/ethereumjs-client) tárolták, de azután beolvadt az EthereumVM monorepóba egy csomagként. + +**Nézze meg a klienst** +[`ethereumjs-client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) + +## Egyéb projektek {#other-projects} + +Rengeteg más dolog is zajlik az Ethereum JavaScript világában, mint például: + +- könyvtárak és tárcaeszközök. +- eszközök Ethereum kulcsok generálására, importálására és exportálására. +- a `merkle-patricia-tree` (Merkle Patricia-fa) implementációja – egy adatstruktúra, melyet az Ethereum Sárgakönyv részletez. + +Mélyedjen bele abba, ami a leginkább érdekli a [EthereumJS mappában](https://github.com/ethereumjs) + +## További olvasnivaló {#further-reading} + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" new file mode 100644 index 00000000000..2ac739389b2 --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" @@ -0,0 +1,90 @@ +--- +title: Ethereum Python fejlesztőknek +description: Tanuljon meg Ethereumra fejleszteni Python alapú projektek és eszközök használatával +lang: hu +incomplete: true +--- + +Tanuljon meg Ethereumra fejleszteni Python alapú projektek és eszközök használatával + +Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. + +## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} + +**Tegye meg az első lépést, hogy integrálja a Pythont az Ethereummal** + +Szükséged van egy méginkább kezdőknek szóló alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. + +- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Cikkek kezdőknek {#beginner-articles} + +- [Egy (Python) fejlesztői útmutató az Ethereumra](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) +- [A Python helyzete a 2023-as blokklánc riportban](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) +- [Bevezetés az okosszerződésekbe Vyper-rel](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) +- [Telepítse a saját ERC20-as tokenjét Pythonnal és Brownie-val](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) +- [Hogyan kell Ethereum szerződést fejleszteni Python Flask használatával?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) +- [Bevezetés Web3.py-ba · Ethereum Python fejlesztőknek](https://www.dappuniversity.com/articles/web3-py-intro) +- [Hogyan kell egy okosszerződés függvényt meghívni Python és web3.py használatával](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) + +## Köztes cikkek {#intermediate-articles} + +- [Dapp fejlesztés Python programozóknak](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28) +- [Python Ethereum felület létrehozása: Első rész](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) +- [Ethereum okosszerződések Pythonban: egy átfogó útmutató](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) +- [Okosszerződések telepítése Brownie-val és Pythonnal](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) +- [NFT-k létrehozása az OpenSea piactérre a Brownie-val](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) + +## Speciális használati minták {#advanced-use-patterns} + +- [Ethereum okosszerződések fordítása, telepítése és hívása Python használatával](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) +- [Solidity okosszerződések elemzése Slitherrel](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) +- [Blokklánc pénzügyi technológiai (fintech) útmutató: kölcsönadás és kölcsönvétel Pythonnal](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) + +## Python projektek és eszközök {#python-projects-and-tools} + +### Aktív: {#active} + +- [Web3.py](https://github.com/ethereum/web3.py) – _Python könyvtár az Ethereummal történő interakciókra_ +- [Vyper](https://github.com/ethereum/vyper/) – _Pythonikus okosszerződés nyelv az EVM-re_ +- [Ape](https://github.com/ApeWorX/ape) – _ Az okosszerződés fejlesztői eszköz a pythonisták, adatkutatók és biztonsági szakértők számára._ +- [py-evm](https://github.com/ethereum/py-evm) – _Az Ethereum virtuális gép implementációja_ +- [eth-tester](https://github.com/ethereum/eth-tester) – _Eszközök az Ethereum-alapú alkalmazások teszteléséhez_ +- [eth-utils](https://github.com/ethereum/eth-utils/) - _használati funkciók Ethereumhoz kapcsolódó kódbázisokkal való munkához_ +- [py-solc-x](https://pypi.org/project/py-solc-x/) – _Python wrapper a solc solidity fordító köré 0.5.x támogatással_ +- [pymaker](https://github.com/makerdao/pymaker) – _Python API Maker szerződésekre_ +- [siwe](https://github.com/spruceid/siwe-py) – _Bejelentkezés az Ethereummal (siwe) Pythonra_ +- [Web3 decentralizált pénzügyek (DeFi) Ethereum integrációhoz](https://github.com/tradingstrategy-ai/web3-ethereum-defi) – _Egy Python csomag, mely készen áll az ERC-20, Uniswap és más népszerű projektekkel való integrációra_ +- [Wake](https://getwake.io) - _Minden az egyben Python keretrendszer a szerződéseknek a teszteléshez, fuzzinghoz, telepítéshez, sebezhetőségi vizsgálathoz és kódnavigációhoz (nyelvi szerver - [eszközök a Solidity-hez](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_ + +### Archivált / a karbantartás megszűnt: {#archived--no-longer-maintained} + +- [Trinity](https://github.com/ethereum/trinity) – _Ethereum Python-kliens_ +- [Mamba](https://github.com/arjunaskykok/mamba) – _Keretrendszer Vyper nyelven írt okosszerződések írására, fordítására és telepítésére_ +- [Brownie](https://github.com/eth-brownie/brownie) – _Python keretrendszer Ethereum okosszerződések telepítésére, tesztelésére és alkalmazására_ +- [pydevp2p](https://github.com/ethereum/pydevp2p) – _Az Ethereum P2P stack implementációja_ +- [py-wasm](https://github.com/ethereum/py-wasm) – _A web assembly interpreter Python-implementációja_ + +Még több anyagot keresel? Tekintse meg az [ethereum.org/developers](/developers/) oldalt. + +## Python-eszközöket használó projektek {#projects-using-python-tooling} + +A következő Ethereum-alapú projektek a fent említett eszközöket használják. A kapcsolódó mappák jó referenciaként szolgálnak például a kódok és a bevált gyakorlatok tekintetében. + +- [Yearn Finance](https://yearn.finance/) és [Yearn Vault Contracts mappa](https://github.com/yearn/yearn-vaults) +- [Curve](https://curve.fi/) és [Curve okosszerződések mappa](https://github.com/curvefi/curve-contract) +- [BadgerDAO](https://badger.com/) és [Brownie eszközkészletet használó okosszerződések](https://github.com/Badger-Finance/badger-system) +- [Sushi](https://sushi.com/) [Pythont használ arra, hogy a megbízási szerződéseket kezelje és telepítse](https://github.com/sushiswap/sushi-vesting-protocols) +- [Alpha Finance](https://alphafinance.io/), amelyet az Alpha Homora révén ismerünk, [Brownie-t használ, hogy az okosszerződéseket tesztelje és telepítse](https://github.com/AlphaFinanceLab/alpha-staking-contract) + +## Python közösségi egyeztetések {#python-community-contributors} + +- [Ethereum Python közösségi Discord csatorna](https://discord.gg/9zk7snTfWe) a Web3.py és más Python keretrendszerhez kapcsolódó beszélgetésekhez +- [Vyper Discord](https://discord.gg/SdvKC79cJk) a Vyper okosszerződés programozással kapcsolatos beszélgetésekre + +## Egyéb összesített listák {#other-aggregated-lists} + +A Vyper wiki egy [rendkívüli listát tartalmaz a Vyper-forrásokról](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources). \ No newline at end of file diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" new file mode 100644 index 00000000000..2cacd55e59f --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" @@ -0,0 +1,61 @@ +--- +title: Ethereum Ruby-fejlesztők számára +description: Tanuljon meg Ethereumra fejleszteni Ruby-alapú projektek és eszközök használatával. +lang: hu +incomplete: false +--- + +Tanuljon meg Ethereumra fejleszteni Ruby-alapú projektek és eszközök használatával. + +Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok nem igényelnek bizalmat a felhasználó oldaláról, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel az újfajta pénzügyi alkalmazások számra. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. + +## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} + +**Tegye meg az első lépést a Ruby Ethereumra való integrálásához** + +Szükséged van egy méginkább kezdőknek szóló alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. + +- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Okos Szerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Cikkek kezdőknek {#beginner-articles} + +- [Az Ethereum-számlák megértése](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) +- [Rails-felhasználók hitelesítése a MetaMask használatával](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) +- [Bejelentkezés az Ethereummal – Ruby-könyvtár és Rails-példák kiadása](https://blog.spruceid.com/sign-in-with-ethereum-ruby-library-release-and-rails-examples/) +- [Hogyan lehet az Ethereum-hálózathoz kapcsolódni a Ruby-val](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby) +- [Hogyan lehet új Ethereum-címet létrehozni a Ruby-val](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby) + +## Köztes cikkek {#intermediate-articles} + +- [Blokkláncalkalmazás a Ruby-val](https://www.nopio.com/blog/blockchain-app-ruby/) +- [A Ruby használata az Ethereumon az okosszerződés végrehajtására](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) + +## Ruby-projektek és -eszközök {#ruby-projects-and-tools} + +### Aktív {#active} + +- [eth.rb](https://github.com/q9f/eth.rb) – _Ruby könyvtár és RPC-kliens az Ethereum-számlák, üzenetek és tranzakciók kezelésére_ +- [keccak.rb](https://github.com/q9f/keccak.rb) – _Az Ethereum által használt keccak (SHA3) hash_ +- [siwe-ruby](https://github.com/spruceid/siwe-ruby) – _Ruby általi implementáció az Ethereummal való bejelentkezéshez_ +- [siwe_rails](https://github.com/spruceid/siwe_rails) – _SIWE lokális bejelentkezési utakat adó Rails gem_ +- [siwe-rails-examples](https://github.com/spruceid/siwe-rails-examples) – _SIWE-példa Ruby használatával a Railsen személyre szabott irányítóval_ +- [omniauth-siwe](https://github.com/spruceid/omniauth-siwe) – _OmniAuth-stratégia az Ethereummal (SIWE) való bejelentkezéshez_ +- [omniauth-nft](https://github.com/valthon/omniauth-nft) – _OmniAuth stratégia az NFT tulajdonjogon keresztüli hitelesítésre_ +- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) – _Ethereum a Rails-en sablon, mellyel a MetaMaskot a Ruby-hoz lehet kapcsolni a Rails-en_ + +### Archivált / a karbantartás megszűnt {#archived--no-longer-maintained} + +- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) – _Az Ethereum-csomópontok RPC metódusainak meghívása Ruby-val_ +- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) – _Ruby könyvtár az ETH-címek létrehozására egy hierarchikusan determinált tárcából a BIP32 szabvány szerint_ +- [etherlite](https://github.com/budacom/etherlite) – _Ethereum integráció Ruby-ra a Rails-en_ +- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) – _Ruby Ethereum-kliens, amely JSON-RPC interfészt használ a tranzakciók küldésére, a szerződések létrehozására és az azokkal való interakcióra, valamint hasznos eszközkészlet az Ethereum-csomópontokkal való együttműködéshez_ +- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) – _Az Ethereum-szolgáltatóstratégia bevezetése az OmniAuth-ra_ + +Még több anyagot keresel? Tekintse meg [Fejlesztőink](/developers/) oldalait. + +## Ruby közösségi hozzájárulók {#ruby-community-contributors} + +Az [Ethereum Ruby Telegram csoport](https://t.me/ruby_eth) egy gyorsan növekvő közösség szervezője, egy dedikált erőforrás a fenti projektek és kapcsolódó témák megvitatására. diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" new file mode 100644 index 00000000000..e2402118a6d --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" @@ -0,0 +1,63 @@ +--- +title: Ethereum Rust-fejlesztők számára +description: Tanuljon meg Ethereumra fejleszteni Rust alapú projektek és eszközök használatával +lang: hu +incomplete: true +--- + +Tanuljon meg Ethereumra fejleszteni Rust alapú projektek és eszközök használatával + +Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. + +## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} + +**Tegye meg az első lépést, hogy integrálja a Rust-ot az Ethereummal** + +Szükséged van egy méginkább kezdőknek szóló alapozóra? Tekintse meg az [ethereum.org/learn](/learn/) vagy az [ethereum.org/developers](/developers/) oldalt. + +- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) +- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) +- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) +- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) + +## Cikkek kezdőknek {#beginner-articles} + +- [A Rust Ethereum-kliens](https://openethereum.github.io/) \* **Felhívjuk figyelmét, hogy az OpenEthereum [támogatása megszűnt](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd), karbantartása nem biztosított.** Használja körültekintően, és inkább térjen át másik kliensimplementációra. +- [Tranzakció küldése Ethereumra Rust használatával](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) +- [Részletes útmutató arról, hogyan lehet szerződéseket írni Rust Wasm nyelven Kovanra](https://github.com/paritytech/pwasm-tutorial) + +## Köztes cikkek {#intermediate-articles} + +## Speciális használati minták {#advanced-use-patterns} + +- [pwasm_ethereum externs könyvtár Ethereum-szerű hálózatokkal való interakciókhoz](https://github.com/openethereum/pwasm-ethereum) +- [Építsen egy decentralizált csevegőprogramot JavaScript és Rust használatával](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) +- [Építsen egy decentralizált teendők listája alkalmazást Vue.js-szel & Rust-tal](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) + +- [Blokklánc építése Rust nyelven](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) + +## Rust-projektek és -eszközök {#rust-projects-and-tools} + +- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) – _Külső elemek gyűjteménye az Ethereum-szerű hálózattal való interakcióhoz_ +- [Lighthouse](https://github.com/sigp/lighthouse) – _Gyors Ethereum-konszenzusrétegkliens_ +- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) – _Az Ethereum okosszerződés végrehajtási rétegének javasolt újratervezése a WebAssembly egy determinisztikus részét használva_ +- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS API referencia_ +- [Solaris](https://github.com/paritytech/sol-rs) – _Solidity okosszerződések egységtesztelésének irányítása a natív Parity kliens EVM használatával._ +- [SputnikVM](https://github.com/rust-blockchain/evm) – _Rust Ethereum virtuálisgép-implementáció_ +- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) – _Wavelet okosszerződés Rust-ban_ +- [Foundry](https://github.com/foundry-rs/foundry) – _Eszközkészlet az Ethereum-alkalmazások fejlesztéséhez_ +- [Alloy](https://alloy.rs) - _Magas teljesítményű, alaposan tesztelt és dokumentált könyvtárak az Ethereummal és más EVM-alapú lánccal való interakcióhoz._ +- [Ethers_rs](https://github.com/gakonst/ethers-rs) – _Ethereum könyvtár- és tárcaimplementáció_ +- [SewUp](https://github.com/second-state/SewUp) – _Egy könyvtár, amely segít az Ethereum webassembly szerződés Rust-ban való megépítésében, mintha egy általános backend lenne_ +- [Substreams](https://github.com/streamingfast/substreams) – _Párhuzamos blokkláncadat-indexálási technológia_ +- [Reth](https://github.com/paradigmxyz/reth) A Reth (Rust Ethereum rövidítése) egy új teljescsomópont-implementáció az Ethereumon +- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) – _Az Ethereum ökoszisztéma Rust nyelven írt projektjeinek gyűjteménye_ + +Még több anyagot keresel? Tekintse meg az [ethereum.org/developers](/developers/) oldalt. + +## Rust közösségi hozzájárulók {#rust-community-contributors} + +- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby) +- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby) +- [Parity Gitter](https://gitter.im/paritytech/parity) +- [Enigma](https://discord.gg/SJK32GY) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" new file mode 100644 index 00000000000..3baa100807c --- /dev/null +++ "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" @@ -0,0 +1,216 @@ +--- +title: Decentralizált tárhely +description: Áttekintés a decentralizált tárhelyről és az elérhető eszközökről, amellyekkel integrálhatóak a dappokba. +lang: hu +--- + +A központilag elhelyezett, egyetlen vállalat vagy szervezet által működtetett szerverrel szemben a decentralizált tárolórendszerek a felhasználói operátorok peer-to-peer hálózatából állnak, akik az összes adat egy részét tárolják egy rugalmas fájltárolási és -megosztási rendszert létrehozva. Ezek lehetnek blokklánc-alapú alkalmazásokban vagy bármilyen, közvetítő nélküli hálózatokban. + +Magát az Ethereumot is lehet decentralizált tárolórendszerként használni, és úgy is működik, amikor az okosszerződések kódjait kell tárolni. Ugyanakkor az Ethereumot nem arra tervezték, hogy nagy adathalmazokat tároljon. A lánc stabilan növekszik, a jelen írás idején az Ethereum lánc kb. 500 GB – 1TB méretű ([a klienstől függően](https://etherscan.io/chartsync/chaindefault)), és a hálózat minden csomópontjának tárolnia kell ezt az adatmennyiséget. Ha a lánc nagy adatmennyiségre növekedne meg (mondjuk 5 TB méretre), akkor már nem minden csomópont tudna működni. Ezen túl ennyi adat bevitele a főhálózatra is ellehetetlenítő módon drága lenne a [gázdíjak](/developers/docs/gas) miatt. + +Ezen megszorítások miatt egy másik láncra vagy módszerre van szükség, hogy az adatok nagy tömegét decentralizált módon tároljuk. + +Amikor decentralizált tárhely (dStorage) opcióról beszélünk, akkor a felhasználónak néhány dolgot fontos figyelembe vennie. + +- Megtartási mechanizmus / ösztönzési struktúra +- Adatmegtartás kényszere +- Decentralitás +- Konszenzus + +## Megtartási mechanizmus / ösztönzési struktúra {#persistence-mechanism} + +### Blokkláncalapú {#blockchain-based} + +Ahhoz, hogy egy adat örökké létezzen, valamilyen megtartási mechanizmusra van szükség. Például az Ethereumon az a megtartási mechanizmus, hogy a csomópont futtatásánál az egész láncra szükség van. Az új adat a lánchoz kerül, és így az folyamatosan növekszik – az összes csomópontnak replikálnia kell az összes beágyazott adatot. + +Ezt úgy nevezik, hogy **blokkláncalapú** megtartás. + +A blokkláncalapú megtartással az a gond, hogy a lánc túl nagyra nőket, hogy fenntartsa és tárolja az összes adatot (például [számos forrás](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) úgy becsli, hogy az Internet több mint 40 zettabájt tárhelyet igényel). + +A blokkláncnak emellett valamilyen ösztönzési struktúrát kell alkalmaznia. A blokkláncalapú megtartáshoz a validátorok fizetséget kapnak. Amikor az adat hozzákerül a lánchoz, a validátorok jutalmat kapnak a bekerülés intézéséért. + +Blokkláncalapú megtartással működő platformok: + +- Ethereum +- [Arweave](https://www.arweave.org/) + +### Szerződésalapú {#contract-based} + +A **szerződésalapú** megtartás úgy véli, hogy az adatot nem replikálhatja és tárolhatja örökké minden csomópont, ehelyett inkább szerződéses megállapodással kell azt fenntartani. Ezeket a megállapodásokat számos csomóponttal kötik, amelyek megígérik, hogy egy adott időszakra megtartják az adatot. Ezt vissza kell fizetni vagy meg kell újítani, amikor már nem tartják meg az adatot. + +A legtöbb esetben nem az adatot tárolják a láncon, hanem azt a hasht, ami az adat tárolási helyét mutatja. Így a teljes láncot nem kell skálázni, hogy minden adat elférjen. + +Szerződésalapú megtartással működő platformok: + +- [Filecoin](https://docs.filecoin.io/about-filecoin/what-is-filecoin/) +- [Skynet](https://siasky.net/) +- [Storj](https://storj.io/) +- [Züs](https://zus.network/) +- [Crust Network](https://crust.network) +- [Swarm](https://www.ethswarm.org/) +- [4EVERLAND](https://www.4everland.org/) + +### További megfontolások {#additional-consideration} + +Az IPFS (InterPlanetary File System) egy elosztott rendszer fájlok, honlapok, alkalmazások és adatok tárolására és elérésére. Nincs beépített ösztönzési sémája, de használható bármelyik szerződésalapú ösztönzési megoldással a hosszú távú megtartásért. Egy másik módja annak, hogy az IPFS-en megmaradjon az adat, az az odatűzési (pinning) szolgáltatás, mely rögzíti az Önnek fontos adatokat, hogy Ön elérje azokat. Ön is futtathat saját IPFS csomópontot és hozzájárulhat a hálózathoz, hogy fenntartja a saját és más adatait ingyen! + +- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/) +- [Pinata](https://www.pinata.cloud/) _(IPFS pinning service)_ +- [web3.storage](https://web3.storage/) _(IPFS/Filecoin pinning service)_ +- [Infura](https://infura.io/product/ipfs) _(IPFS pinning service)_ +- [IPFS Scan](https://ipfs-scan.io) _(IPFS pinning explorer)_ +- [4EVERLAND](https://www.4everland.org/)_（IPFS pinning service）_ +- [Filebase](https://filebase.com) _(IPFS Pinning Service)_ +- [Spheron Network](https://spheron.network/) _(IPFS/Filecoin pinning szolgáltatás)_ + +A SWARM egy decentralizáld adattárhely és elosztási technológia, mely tárolási ösztönzőrendszerrel és egy tárhelybérleti-költséges orákulummal működik. + +## Adatmegőrzés {#data-retention} + +Az adat megtartásához a rendszereknek valamilyen mechanizmusra van szükségük, hogy ezt biztosítsák. + +### Kihívásalapú mechanizmus {#challenge-mechanism} + +Az egyik legnépszerűbb módszer az adatmegtartásra, hogy valamilyen kriptográfiai kihívást használnak, amelyet a csomópontokhoz küldenek annak ellenőrzésére, hogy azok tényleg rendelkeznek-e az adattal. Egy egyszerű példa az Arweave hozzáférés-bizonyítása. Egy kihívást küldenek a csomópontoknak, hogy azoknál megvan-e a legutóbbi blokk és egy tetszőleges korábbi blokk. Ha a csomópont nem tud válaszolni, akkor megbüntetik. + +A kihívásmechanizmussal rendelkező decentralizált tárhelyek típusai: + +- Züs +- Skynet +- Arweave +- Filecoin +- Crust Network +- 4EVERLAND + +### Decentralitás {#decentrality} + +A platformok decentralitását nem lehet könnyen mérni, de általában olyan eszközt válasszon, amelyik nem valamilyen KYC-féle (ismerje meg ügyfelét) dolgot használ arra, hogy bizonyítékot adjon a decentralitásáról. + +Decentralizált eszközök KYC nélkül: + +- Skynet +- Arweave +- Filecoin +- IPFS +- Ethereum +- Crust Network +- 4EVERLAND + +### Konszenzus {#consensus} + +A legtöbb eszköz rendelkezik valamilyen [konszenzusmechanizmussal](/developers/docs/consensus-mechanisms/), általában [**proof-of-work (PoW)**](/developers/docs/consensus-mechanisms/pow/) vagy [**proof-of-stake (PoS)** mechanizmust használnak](/developers/docs/consensus-mechanisms/pos/). + +Proof-of-work-alapú: + +- Skynet +- Arweave + +Proof-of-stake-alapú: + +- Ethereum +- Filecoin +- Züs +- Crust Network + +## Kapcsolódó eszközök {#related-tools} + +**IPFS – _InterPlanetary File System egy decentralizált tárhely és fájlreferencia-rendszer Ethereumra._** + +- [Ipfs.io](https://ipfs.io/) +- [Dokumentáció](https://docs.ipfs.io/) +- [GitHub](https://github.com/ipfs/ipfs) + +**Storj DCS – _Biztonságos, privát és S3-kompatibilis, decentralizált felhőobjektum-tárhely fejlesztőknek._** + +- [Storj.io](https://storj.io/) +- [Dokumentáció](https://docs.storj.io/) +- [GitHub](https://github.com/storj/storj) + +**Skynet – _A Skynet egy decentralizált PoW lánc, ami a decentralizált web felé elkötelezett._** + +- [Skynet.net](https://siasky.net/) +- [Dokumentáció](https://siasky.net/docs/) +- [GitHub](https://github.com/SkynetLabs/) + +**Filecoin – _Filecoint az IPFS mögötti csapat hozta létre. Ez egy ösztönzőréteg az IPFS ideálok tetején._** + +- [Filecoin.io](https://filecoin.io/) +- [Dokumentáció](https://docs.filecoin.io/) +- [GitHub](https://github.com/filecoin-project/) + +**Arweave – _Az Arweave egy dStorage platform adattárolásra._** + +- [Arweave.org](https://www.arweave.org/) +- [Dokumentáció](https://docs.arweave.org/info/) +- [Arweave](https://github.com/ArweaveTeam/arweave/) + +**Züs – _A Züs egy proof-of-stake dStorage platform shardinggal és blobberekkel._** + +- [zus.network](https://zus.network/) +- [Dokumentáció](https://0chaindocs.gitbook.io/zus-docs) +- [GitHub](https://github.com/0chain/) + +**Crust Network – _Crust egy dStorage platform az IPFS tetején._** + +- [Crust.network](https://crust.network) +- [Dokumentáció](https://wiki.crust.network) +- [GitHub](https://github.com/crustio) + +**Swarm – _Egy elosztott tárhely platform és tartalom elosztó szolgáltatás az Ethereum web3-stackhez._** + +- [EthSwarm.org](https://www.ethswarm.org/) +- [Dokumentáció](https://docs.ethswarm.org/docs/) +- [GitHub](https://github.com/ethersphere/) + +**OrbitDB – _Egy decentralizált peer-to-peer adatbázis az IPFS tetején._** + +- [OrbitDB.org](https://orbitdb.org/) +- [Dokumentáció](https://github.com/orbitdb/field-manual/) +- [GitHub](https://github.com/orbitdb/orbit-db/) + +**Aleph.im – _Decentralizált felhőprojekt (adatbázis, fájltárolás, számítás és DID). A láncon kívüli és belüli, közvetítőmentes (peer-to-peer) technológia egyedi keveréke. IPFS-sel és többféle lánccal kompatibilis._** + +- [Aleph.im](https://aleph.im/) +- [Dokumentáció](https://aleph.im/#/developers/) +- [GitHub](https://github.com/aleph-im/) + +**Ceramic – _Felhasználó által kontrollált IPFS-adatbázis az adatgazdag alkalmazásokért._** + +- [Ceramic.network](https://ceramic.network/) +- [Dokumentáció](https://developers.ceramic.network/learn/welcome/) +- [GitHub](https://github.com/ceramicnetwork/js-ceramic/) + +**Filebase – _S3-kompatibilis decentralizált tárhely és georedundáns IPFS pinning szolgáltatás. Az IPFS-re a Filebase-en keresztül feltöltött összes fájlt automatikusan hozzátűzi a Filebase infrastruktúrához 3-szoros replikációval világszerte._** + +- [Filebase.com](https://filebase.com/) +- [Dokumentáció](https://docs.filebase.com/) +- [GitHub](https://github.com/filebase) + +**4EVERLAND – _Egy Web 3.0 felhőszámítási platform, ami integrálja a tárolás, számítás és hálózatépítés lényegi képességeit, S3-kompatibilis és szinkron adattárolást kínál olyan decentralizált tárolóhálózatokon, mint amilyen az IPFS és az Arweave._** + +- [4everland.org](https://www.4everland.org/) +- [Dokumentáció](https://docs.4everland.org/) +- [GitHub](https://github.com/4everland) + +**Kaleido – _Egy blokklánc mint szolgáltatás platform gombnyomásos IPFS csomópontokkal_** + +- [Kaleido](https://kaleido.io/) +- [Dokumentáció](https://docs.kaleido.io/kaleido-services/ipfs/) +- [GitHub](https://github.com/kaleido-io) + +**Spheron Network - _A Spheron egy platform mint szolgáltatás (PaaS), amelyet olyan dappok számára terveztek, amelyek jó teljesítményű decentralizált infrastruktúrán szeretnék elindítani alkalmazásaikat. Számítási kapacitást, decentralizált tárolást, CDN & web hosting szolgáltatás kínál._** + +- [spheron.network](https://spheron.network/) +- [Dokumentáció](https://docs.spheron.network/) +- [GitHub](https://github.com/spheronFdn) + +## További olvasnivaló {#further-reading} + +- [Mi az a decentralizált tárhely?](https://coinmarketcap.com/alexandria/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) – _CoinMarketCap_ +- [Öt gyakori mítosz lerombolása a decentralizált tárhelyről](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) – _Storj_ + +_Ismer olyan közösségi információforrást, amely a hasznára vált? Módosítsa az oldalt, és adja hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) diff --git a/public/content/translations/hu/19) Learn Pages 2/glossary/index.md b/public/content/translations/hu/19) Learn Pages 2/glossary/index.md new file mode 100644 index 00000000000..fc0d796c447 --- /dev/null +++ b/public/content/translations/hu/19) Learn Pages 2/glossary/index.md @@ -0,0 +1,499 @@ +--- +title: Ethereum szótár +description: Szójegyzék az Ethereumhoz kapcsolódó technikai és nem technikai szavakról, a teljesség igénye nélkül +lang: hu +--- + +# Szójegyzék {#ethereum-glossary} + +## \# {#section-numbers} + + + + + +## A {#section-a} + + + + + + + + + + + + + + + + + + + + + +## B {#section-b} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +## C {#section-c} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +## D {#section-d} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +## E {#section-e} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +## F {#section-f} + + + + + + + + + + + + + + + + + + + +## G {#section-g} + + + + + + + + + + + + + + + +## H {#section-h} + + + + + + + + + + + + + +## I {#section-i} + + + + + + + + + + + + + +## K {#section-k} + + + + + + + + + + + +## L {#section-l} + + + + + + + + + + + + + + + + + +## M {#section-m} + + + + + + + + + + + + + + + + + + + + + + + + + +## N {#section-n} + + + + + + + + + + + + + +## O {#section-o} + + + + + + + + + + + + + +## P {#section-p} + + + + + + + + + + + + + + + + + + + + + + + + + + + +## R {#section-r} + + + + + + + + + + + + + + + +## S {#section-s} + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +## T {#section-t} + + + + + + + + + + + + + + + + + + + +## V {#section-v} + + + + + + + + + + + + + +## W {#section-w} + + + + + + + + + +## Z {#section-z} + + + + + + + + + +## Források {#sources} + +_Részben [Andreas M. Antonopoulos és Gavin Wood](https://ethereumbook.info) [Mastering Ethereum](https://github.com/ethereumbook/ethereumbook) műve alapján lett létrehozva, a CC-BY-SA licence keretében_ + + + +## Járuljon hozzá az oldalhoz {#contribute-to-this-page} + +Kihagytunk valamit? Valami nem helyes? Segítsen nekünk jobbá tenni úgy, hogy közreműködik a szójegyzék fejlesztésében a GitHubon! + +[Tudjon meg többet a közreműködésről](/contributing/adding-glossary-terms) diff --git a/public/content/translations/hu/19) Learn Pages 2/history/index.md b/public/content/translations/hu/19) Learn Pages 2/history/index.md new file mode 100644 index 00000000000..4d80eed3846 --- /dev/null +++ b/public/content/translations/hu/19) Learn Pages 2/history/index.md @@ -0,0 +1,623 @@ +--- +title: Az Ethereum története és elágazásai +description: Az Ethereum blokklánc története a nagyobb mérföldkövekkel, frissítésekkel és elágazásokkal. +lang: hu +sidebarDepth: 1 +--- + +# Az Ethereum története {#the-history-of-ethereum} + +Az Ethereum blokklánc összes fontos mérföldkövének, elágazásának és frissítésének idővonala. + + + +Az elágazások a hálózat nagyobb technikai frissítései vagy változtatásai esetében jönnek létre – általában az Ethereum-fejlesztési javaslatokból (EIP) származnak és megváltoztatják a protokoll „szabályait”. + +Amikor a hagyományos, központi irányítású szoftverek esetében szükséges egy frissítés, a cég csak kibocsájt egy új verziót a végfelhasználó részére. A blokkláncok máshogy működnek, mivel nincsen központi tulajdonjog. Az Ethereum-klienseknek frissíteni kell a szoftverjét, hogy az új elágazási szabályokat életbe léptessék. Ezenkívül a blokklétrehozóknak (bányászok egy proof-of-work rendszerben, validátorok egy proof-of-stake rendszerben) és a csomópontoknak blokkokat kell létrehozniuk és az új szabályokkal szembemenően kell validálniuk. Bővebben a konszenzusmechanizmusokról + +Ezek a szabályváltozások létrehozhatnak egy átmeneti szétválást a hálózatban. Új blokkok jöhetnek létre az új szabályok vagy a régiek szerint. Az elágazásokról általában előzetes egyezség születik, így a kliensek együttesen vezetik be a változtatásokat és a változásokkal rendelkező elágazás válik a fő lánccá. Azonban néha előfordul nézeteltérés az elágazásokat illetően, mely a lánc megmaradó kettészakadását eredményezi – a legismertebb ilyen eset az Ethereum Classic létrejötte volt a DAO elágazással. + + + + + +Az Ethereum alapját képező szoftver két részből áll, ezek a [végrehajtási réteg](/glossary/#execution-layer) és a [consensus layer](/glossary/#consensus-layer). + +**Végrehajtási frissítés elnevezése** + +2021 óta a **végrehajtási rétegre** történő frissítéseket a [korábbi Devcon-helyek] (https://devcon.org/en/past-events/) városnevei szerint nevezik el, időrendi sorrendben: + +| Frissítés neve | Devcon év | Devcon szám | Frissítés dátuma | +| ------------ | ----------- | ------------- | ------------ | +| Berlin | 2015 | 0 | 2021. április 15. | +| London | 2016 | I | 2021. augusztus 5. | +| Shanghai | 2017 | II | 2023. április 12. | +| **Cancun** | 2018 | III | 2024. március 13. | +| _Prága_ | 2019 | IV | TBD | +| _Oszaka_ | 2020 | V | TBD | +| _Bogota_ | 2022 | VI | TBD | +| _Bangkok_ | 2024 | VII | TBD | + +**Konszenzusos frissítés elnevezése** + +A [Beacon Chain](/glossary/#beacon-chain) elindítása óta a **konszenzus réteg** frissítéseit az égi csillagokról nevezték el, amelyek betűkkel kezdődnek, amelyek ábécé sorrendben haladnak: + +| Frissítés neve | Frissítés dátuma | +| -------------------------------------------------- --------- | ------------ | +| Beacon Chain genesis | 2020. december 1. | +| [Altair](https://en.wikipedia.org/wiki/Altair) | 2021. október 27. | +| [Bellatrix](https://en.wikipedia.org/wiki/Bellatrix) | 2022. szeptember 6. | +| [Capella](https://en.wikipedia.org/wiki/Capella) | 2023. április 12. | +| [**Deneb**](https://en.wikipedia.org/wiki/Deneb) | 2024. március 13. | +| [_Electra_]() | TBD | + +**Kombinált elnevezés** + +A végrehajtás és a konszenzusos frissítések kezdetben különböző időpontokban kerültek bevezetésre, de a [The Merge](/roadmap/merge/) 2022-es verzióját követően ezeket egyidejűleg telepítették. Így a köznyelvi kifejezések azért jelentek meg, hogy leegyszerűsítsék az ezekre a frissítésekre való hivatkozásokat egyetlen összevont kifejezés használatával. Ez a _Shanghai-Capella_ frissítéssel kezdődött, amelyet általában "**Shapella**-ként emlegetnek", és folytatódik a _Cancun-Deneb_ frissítéssel, amelyre "**Dencun**-ként" hivatkozhatunk. + +| Végrehajtás frissítése | Konszenzus frissítése | Rövid név | +| ------------------ | ------------------ | ---------- | +| Shanghai | Capella | „Shapella” | +| Cancun | Deneb | „Dencun” | + + + +Akár egy lépéssel is elnavigálhat néhány rendkívül fontos frissítéshez: [A Beacon lánc](/roadmap/beacon-chain/); [A Beolvadás](/roadmap/merge/); és [EIP-1559](#london) + +A jövőbeli protokollfrissítések érdeklik? [Tudjon meg többet a következő frissítésekről az Ethereum ütemtervéből](/roadmap/). + + + +## 2024 {#2024} + +### Cancun-Deneb („Dencun”) {#dencun} + + + +#### Cancun összefoglalója {#cancun-summary} + +A Cancun frissítés az Ethereum _végrehajtásának_ javítását tartalmazza, amelynek célja a skálázhatóság fejlesztése, párhuzamosan a Deneb konszenzusfrissítésekkel. + +Ide tartozik az EIP-4844, az úgynevezett **Proto-Danksharding**, amely jelentősen csökkenti a második blokkláncréteg (L2) rollupok adattárolási költségeit. Ezt az adatblobok bevezetésével érik el, amely lehetővé teszi, hogy az összevont tranzakcióok az adatokat csak rövid ideig tárolják a főhálózaton. Ez jelentősen alacsonyabb tranzakciós díjakat eredményez az L2 rollupok felhasználói számára. + + + +
    +
  • EIP-1153 - Átmeneti tárolási opkódok
    • +
  • EIP-4788 - Beaconblokk-gyökér az EVM-ben
    • +
  • EIP-4844 - Shard blob tranzakciók (Proto-Danksharding)
    • +
  • EIP-5656 - MCOPY - Memóriamásolási instrukció
    • +
  • EIP-6780 - SELFDESTRUCT (önmegsemmisítés) csak ugyanabban a tranzakcióban
    • +
  • EIP-7516 - BLOBBASEFEE opkód
    • +
+ + + +- [Második blokkláncréteg (L2) rollup-ok](/layer-2/) +- [Proto-Danksharding](/roadmap/scaling/#proto-danksharding) +- [Dank-féle párhuzamos futtatás (Danksharding)](/roadmap/danksharding/) +- [Olvassa el a Cancun frissítés specifikációit](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md) + +#### Deneb összefoglaló {#deneb-summary} + +A Deneb frissítés az Ethereum _konszenzusának_ javítását tartalmazza, amelynek célja a skálázhatóság fejlesztése. Ez a frissítés a Cancun végrehajtási frissítésekkel párhuzamosan történik a Proto-Danksharding (EIP-4844) engedélyezéséhez, valamint a Beacon Chain egyéb fejlesztéseihez. + +Az előre generált, aláírt „önkéntes kilépési üzenetek” többé nem járnak le, így a felhasználók nagyobb kontrollt kapnak a csomópont-üzemeltetőknél elhelyezett pénzeszközeik felett. Ezzel az aláírt kilépési üzenettel a letétbe helyezők delegálhatják a csomópont működését, miközben továbbra is képesek biztonságosan kilépni és bármikor kivenni a pénzüket anélkül, hogy bárkitől engedélyt kellene kérniük. + +Az EIP-7514 szigorítja az ETH-kibocsátást azáltal, hogy maximálja a validátorok becsatlakozási arányát úgy, hogy korszakonként nyolcan (8) kapcsolódhatnak be a hálózatba. Mivel az ETH-kibocsátás arányos az összes letétbe helyezett ETH-szel, a csatlakozó validátorok számának korlátozása korlátozza az újonnan kibocsátott ETH _növekedési ütemét_, miközben csökkenti a csomópontüzemeltetők hardverigényét, segítve a decentralizációt. + + + +
    +
  • EIP-4788 - Beaconblokk-gyökér az EVM-ben
    • +
  • EIP-4844 - Shard blob tranzakciók
    • +
  • EIP-7044 - Örökké érvényes aláírt önkéntes kilépések
    • +
  • EIP-7045 - Növeli a maximális tanúsításbeszámítási slotot
    • +
  • EIP-7514 - Maximálja a korszakonként belépő validátorok számát
    • +
+ + + +- [Olvassa el a Deneb frissítés specifikációit](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/) +- [Cancun-Deneb („Dencun”) FAQ](/roadmap/dencun/) + + + +## 2023 {#2023} + +### Shanghai-Capella ("Shapella") {#shapella} + + + +#### Shanghai összefoglaló {#shanghai-summary} + +A Shanghai frissítés vezette be a letétek kivonási lehetőségét a végrehajtási rétegen. A Capella frissítéssel együtt ez lehetővé tette, hogy a blokkok kivonási műveletet fogadjanak el, amivel a letétesek ki tudják venni az ETH a Beacon láncról a végrehajtási rétegre. + + + +
    +
  • EIP-3651 – A COINBASE címmelegítés elkezdése
    • +
  • EIP-3855 – Új PUSH0 parancs
    • +
  • EIP-3860 – Az initkód behatárolása és mérése
    • +
  • EIP-4895 – A Beacon lánc kivételeket küld műveletként
    • +
  • EIP-6049 – ASELFDESTRUCT érvénytelenítése
    • +
+ + + +- [Olvassa el a Shanghai frissítés specifikációit](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) + +#### Capella összefoglaló {#capella-summary} + +A Capella frissítés a harmadik legnagyobb frissítés volt a konszenzusrétegen (Beacon lánc) és lehetővé tette a letétek kivételét. A Capella egyszerre történt a Shanghai frissítéssel, ami a végrehajtási réteget változtatta meg, és így lehetővé vált a letét kivétele. + +Ez a konszenzusréteg frissítés megengedte a letétbe helyezőknek, hogy ha a letét kezdetén nem adtak meg kivételi adatokat, akkor most megtehessék. + +Emellett bevezették az automatikus számlasöprési funkciót, ami folyamatosan átnézi a validátorok számláit, hogy van-e kifizetendő jutalom vagy teljes kivétel. + +- [Bővebben a letétek visszavonásáról](/staking/withdrawals/). +- [Olvassa el a Capella frissítés specifikációit](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/) + + + +## 2022 {#2022} + +### Paris (a Beolvadás) {#paris} + + + +#### Összegzés {#paris-summary} + +A Paris frissítést az váltotta ki, hogy a proof-of-work blokklánc meghaladta a [végső teljes nehézséget](/glossary/#terminal-total-difficulty), melynek mértéke 58 750 000 000 000 000 000 000 volt. Az a 15 537 393. blokknál történt 2022. szeptember 15-én, így kiváltva a következő blokktól a Paris frissítést. A Paris volt [a Beolvadásra](/roadmap/merge/) való áttérés, melynek fő jellemzője a [proof-of-work](/developers/docs/consensus-mechanisms/pow) bányászó algoritmus és a kapcsolódó konszenzuslogika kikapcsolása, ehelyett pedig a [proof-of-stake](/developers/docs/consensus-mechanisms/pos) bekapcsolása. A Paris egyúttal frissítette a [végrehajtási klienseket](/developers/docs/nodes-and-clients/#execution-clients) is (a Bellatrix-hoz hasonlóan, ami a konszenzusrétegen tette), hogy instrukciókat tudjanak fogadni a velük kapcsolódó [konszenzuskliensektől](/developers/docs/nodes-and-clients/#consensus-clients). Ehhez szükség volt arra, hogy a belső API-metódusok egy új készletét, az [Engine API-kat](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) aktiválják. Ez kétségtelenül az Ethereum történetének legjelentősebb frissítése volt a [Homestead](#homestead) óta! + +- [Olvassa el a Paris frissítés specifikációit](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md) + + + +
    +
  • EIP-3675 – A konszenzus frissítése proof-of-stake-re
    • +
  • EIP-4399 – A DIFFICULTY opkód kiváltása PREVRANDAO-val
    • +
+ + + +--- + +### Bellatrix {#bellatrix} + + + +#### Összegzés {#bellatrix-summary} + +A Bellatrix frissítés a második betervezett frissítés volt a [Beacon láncra](/roadmap/beacon-chain), hogy előkészítse a láncot a [a Beolvadásra](/roadmap/merge/). Ezzel a validátorok büntetései teljes értékűek lettek az aktivitás hiányára és a súlyos büntetésekre vonatkozóan. A Bellatrix szintén hozott egy frissítést az elágazásválasztás szabályaiba, hogy felkészítse a láncot a Beolvadásra és arra, hogy az utolsó proof-of-work blokk után az első proof-of-stake blokk következzen. A konszenzuskliensek ezzel tudatosak lettek az 58 750 000 000 000 000 000 000 [végső teljes nehézségről](/glossary/#terminal-total-difficulty). + +- [Olvassa el a Bellatrix frissítés specifikációit](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix) + +--- + +### Gray Glacier {#gray-glacier} + + + +#### Összegzés {#gray-glacier-summary} + +A Gray Glacier hálózati frissítés eltolta a [nehézségi bombát](/glossary/#difficulty-bomb) három hónappal. Ez a frissítés csak ezt változtatta meg, és így természetében hasonlít a [Arrow Glacier](#arrow-glacier) és a [Muir Glacier](#muir-glacier) frissítésekhez. Hasonló változtatások történtek a [Byzantium](#byzantium), [Constantinople](#constantinople) és [London](#london) hálózati frissítéseknél is. + +- [EF Blog – Gray Glacier frissítés bejelentése](https://blog.ethereum.org/2022/06/16/gray-glacier-announcement/) + + + +
    +
  • EIP-5133 – A nehézségi bomba elhalasztása 2022. szeptemberig
    • +
+ + + + + +## 2021 {#2021} + +### Arrow Glacier {#arrow-glacier} + + + +#### Összegzés {#arrow-glacier-summary} + +Az Arrow Glacier hálózati frissítés eltolta a [nehézségi bombát](/glossary/#difficulty-bomb) néhány hónappal. Ez a frissítés csak ezt változtatta meg, és így természetében hasonlít a [Muir Glacier](#muir-glacier) frissítéshez. Hasonló változtatások történtek a [Byzantium](#byzantium), [Constantinople](#constantinople) és [London](#london) hálózati frissítéseknél is. + +- [EF Blog – Arrow Glacier frissítés bejelentése](https://blog.ethereum.org/2021/11/10/arrow-glacier-announcement/) +- [Ethereum Cat Herders – Ethereum Arrow Glacier frissítés](https://medium.com/ethereum-cat-herders/ethereum-arrow-glacier-upgrade-e8d20fa4c002) + + + +
    +
  • EIP-4345 – A nehézségi bomba elhalasztása 2022. júniusig
    • +
+ + + +--- + +### Altair {#altair} + + + +#### Összegzés {#altair-summary} + +Az Altair frissítés a [Beacon lánc](/roadmap/beacon-chain) első tervezett változtatása volt. A „szinkronizálási bizottságokhoz” adott támogatást, mint a könnyű kliensek bevezetése, valamint megnövelte a validátor nem aktivitás és súlyos büntetések mértékét, hogy előkészítse a Beolvadást. + +- [Olvassa el az Altair frissítés specifikációit](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair) + +#### Érdekesség! {#altair-fun-fact} + +Az Altair volt az első nagyobb hálózati frissítés, aminek konkrét bevezetési ideje volt. Az összes korábbi frissítés egy adott blokkszám alapján történt a proof-of-work láncon, ahol a blokkonkénti idő változó. A Beacon láncnak nem kellett igazodnia a proof-of-workhöz, így időalapú korszakok rendszerén alapszik, amelyek 32 darab 12 másodperces slotból állnak, és a validátorok ezekben tudnak blokkot javasolni. Így pontosan lehetett tudni, hogy mikor következik a 74 240. korszak, hogy az Altair életbe léphessen! + +- [Blokk idő](/developers/docs/blocks/#block-time) + +--- + +### London {#london} + + + +#### Összegzés {#london-summary} + +A London frissítés bevezette az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) változást, amely megreformálta a tranzakciós illeték piacát, azzal együtt, hogyan kezelik a gázvisszatérítéseket, valamint betervezte az [Ice Age](/glossary/#ice-age) ütemtervet. + +#### Mi volt a London-frissítés (EIP-1559) lényege? {#eip-1559} + +A London-frissítés előtt az Ethereum fix méretű blokkokkal működött. A magas hálózati kereslet idején ezek a blokkok teljes kapacitással működtek. Ennek eredményeképp a felhasználóknak sokszor várni kellett a kereslet csökkenésére, hogy bekerülhessenek egy blokkba, ami rontott a felhasználói élményen. A London-frissítés bevezette a változó méretű blokkokat az Ethereumon. + +A tranzakciós díjak számításának módja 2021. augusztusában megváltozott [a London-frissítéssel](/history/#london) az Ethereum hálózatán. A London Upgrade előtt a díjakat úgy kalkulálták, hogy elkülönítették az `alapdíjat` és az `elsőbbségi díjat`: + +Tegyük fel, hogy Alice-nek fizetnie kell Bobnak 1 ETH-t. A tranzakcióban a gázkorlátozás 21 000 egység, a gázdíj pedig 200 gwei. + +A teljes díj: `gáz mennyisége (határ) * egységenkénti gázdíj `, vagyis `21 000 * 200 = 4 200 000 gwei` vagy 0,0042 ETH + +Az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) bevezetése a London-frissítés során bonyolultabbá tette a tranzakciós illetékek működését, de megjósolhatóbb lett a gázdíj, ami egy sokkal hatékonyabb tranzakciósilleték-piacot eredményezett. A felhasználók megadhatják a `maxFeePerGas` értékét, vagyis azt, hogy legfeljebb mennyit hajlandók fizetni a tranzakció végrehajtásáért, annak tudatában, hogy nem fognak többet fizetni érte, mint a gáz piaci ára (`baseFeePerGas`), és a borravalót leszámítva visszakapják a különbözetet. + +Ez a videó elmagyarázza az EIP-1559-et és annak előnyeit: [EIP-1559 magyarázat](https://www.youtube.com/watch?v=MGemhK9t44Q) + +- [Ön egy dapp-fejlesztő? Feltétlenül frissítse a könyvtárakat és az eszközkészletet.](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/london-ecosystem-readiness.md) +- [Olvassa el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2021/07/15/london-mainnet-announcement/) +- [Olvassa el az Ethereum Cat Herder magyarázatát](https://medium.com/ethereum-cat-herders/london-upgrade-overview-8eccb0041b41) + + + +
    +
  • EIP-1559 – fejleszti a tranzakciós illeték piacát
    • +
  • EIP-3198 – visszaküldi a BASEFEE mezőt a blokkból
    • +
  • EIP-3529 – csökkenti a gázvisszatérítést az EVM-műveletekre
    • +
  • EIP-3541 – megakadályozza olyan szerződések telepítését, melyek 0xEF kóddal kezdődnek
    • +
  • EIP-3554 – elhalasztja az Ice Age korszakot 2021. decemberig
    • +
+ + + +--- + +### Berlin {#berlin} + + + +#### Összegzés {#berlin-summary} + +A Berlin frissítés optimalizálta a gázköltséget bizonyos EVM műveleteknél, és több támogatást adott a többszörös tranzakció típusokra. + +- [Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement/) +- [Olvasd el az Ethereum Cat Herder magyarázatát](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80) + + + +
    +
  • EIP-2565 – csökkenti a ModExp gázköltséget
    • +
  • EIP-2718 – könnyebb támogatást tesz lehetővé a többszörös tranzakciótípusokra
    • +
  • EIP-2929 – a gázköltséget megnöveli a státuszelérő opkódokra
    • +
  • EIP-2930 – opcionális hozzáférési listákat hoz létre
    • +
+ + + + + +## 2020 {#2020} + +### Beacon lánc genezise {#beacon-chain-genesis} + + + +#### Összegzés {#beacon-chain-genesis-summary} + +A [Beacon lánc](/roadmap/beacon-chain/) biztonságos elindításához 16384 darab 32 ETH-nyi letétre volt szükség. Ez november 27-én történt meg, vagyis a Beacon lánc a blokkok létrehozását 2020. december 1-jén kezdte meg. Ez az [Ethereum-vízió](/roadmap/vision/) elérésének fontos első lépése volt. + +[Olvassa el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2020/11/27/eth2-quick-update-no-21/) + + + A Beacon Chain + + +--- + +### A letétbe helyezési szerződés aktiválása {#staking-deposit-contract} + + + +#### Összegzés {#deposit-contract-summary} + +A letétbe helyezési szerződés vezette be a [letétbe helyezés](/glossary/#staking) rendszerét az Ethereum ökoszisztémába. Habár ez egy szerződés a [főhálózaton](/glossary/#mainnet), közvetlen hatást gyakorolt a [Beacon lánc](/roadmap/beacon-chain/) bevezetési idejére, ami egy fontos [Ethereum frissítés](/roadmap/). + +[Olvassa el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2020/11/04/eth2-quick-update-no-19/) + + + Letétbe helyezés + + +--- + +### Muir Glacier {#muir-glacier} + + + +#### Összegzés {#muir-glacier-summary} + +A Muir Glacier nevű elágazás késleltetést vezetett be a [nehézségi bombához](/glossary/#difficulty-bomb). A blokknehézség növelése a [proof-of-work](/developers/docs/consensus-mechanisms/pow/) konszenzusmechanizmusában azzal fenyegetett, hogy az Ethereum használhatósága csökkenni fog, mert a tranzakciók küldése és a dappok használata több időt fog igénybe venni. + +- [Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2019/12/23/ethereum-muir-glacier-upgrade-announcement/) +- [Olvasd el az Ethereum Cat Herder magyarázatát](https://medium.com/ethereum-cat-herders/ethereum-muir-glacier-upgrade-89b8cea5a210) + + + +
    +
  • EIP-2384 – eltolta a nehézségi bomba bevezetését újabb 4 000 000 blokkal vagy kb. 611 nappal.
    • +
+ + + + + +## 2019 {#2019} + +### Istanbul {#istanbul} + + + +#### Összegzés {#istanbul-summary} + +Az Istanbul elágazás: + +- Bizonyos műveletek [gázdíjának](/glossary/#gas) optimalizálása az [EVM-ben](/developers/docs/ethereum-stack/#ethereum-virtual-machine). +- Fejlettebb védekezés a szolgáltatásmegtagadásos támadások ellen. +- A SNARKokon és a STARKokon alapuló [második blokkláncréteg (L2) skálázási](/developers/docs/scaling/#layer-2-scaling) megoldások teljesítményének javítása. +- Az Ethereum és a Zcash közötti együttműködés bevezetése. +- Az okosszerződésekben kreatívabb függvényeket tett lehetővé. + +[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2019/11/20/ethereum-istanbul-upgrade-announcement/) + + + +
    +
  • EIP-152 – az Ethereum együtt tud működni az adatvédelmet megőrző valutával, mint amilyen a Zcash is.
    • +
  • EIP-1108 – olcsóbb kriptográfia, hogy javuljon a gázdíj.
    • +
  • EIP-1344 – az Ethereumot védi az újrajátszási támadással szemben a CHAINID opkód bevezetésével.
    • +
  • EIP-1884 – optimalizálja az opkód gázdíjait a fogyasztás alapján.
    • +
  • EIP-2028 – a CallData költségének csökkentése, hogy több adat férjen be a blokkokba, ami támogatja az L2 skálázást.
    • +
  • EIP-2200 – az opkód gázdíjának egyéb változtatásai.
    • +
+ + + +--- + +### Constantinople {#constantinople} + + + +#### Összegzés {#constantinople-summary} + +A Constantinople elágazás: + +- A [blokkbányászat](/developers/docs/consensus-mechanisms/pow/mining/) jutalmának csökkentése 3 ETH-ről 2-re. +- A blokklánc lefagyásának megakadályozása, mielőtt a [proof-of-stake bevezetésre kerülne](#beacon-chain-genesis). +- Bizonyos műveletek [gázdíjának](/glossary/#gas) optimalizálása az [EVM-ben](/developers/docs/ethereum-stack/#ethereum-virtual-machine). +- Lehetőség olyan címekkel történő interakcióra, melyek még nem jöttek létre. + +[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/) + + + +
    +
  • EIP-145 – optimalizálja bizonyos láncon futó műveletek költségét.
    • +
  • EIP-1014 – lehetővé teszi az interakciót olyan szerződésekkel, amelyeket még nem hoztak létre.
    • +
  • EIP-1052 – a EXTCODEHASH művelet bevezetése, hogy egy másik szerződés kódjának hash-ét vissza lehessen kapni.
    • +
  • EIP-1234 – megakadályozza, hogy a blokklánc lefagyjon a proof-of-stake bevezetése előtt, és 3 ETH-ről 2-re csökkenti a blokkjutalmat.
    • +
+ + + + + +## 2017 {#2017} + +### Byzantium {#byzantium} + + + +#### Összegzés {#byzantium-summary} + +A Byzantium elágazás: + +- A [blokkbányászat](/developers/docs/consensus-mechanisms/pow/mining/) jutalmának csökkentése 5 ETH-ről 3-re. +- A [nehézségi bomba](/glossary/#difficulty-bomb) késleltetése egy évvel. +- Bevezették azt a lehetőséget, hogy állapotot nem befolyásoló hívásokat lehet indítani más szerződések felé. +- Bizonyos kriptográfiai módszerek hozzáadása, hogy támogassa az [L2 skálázást](/developers/docs/scaling/#layer-2-scaling). + +[Olvassa el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/) + + + +
    +
  • EIP-140 – a REVERT opkód bevezetése.
    • +
  • EIP-658 – a tranzakció-visszaigazolásba bekerült a státuszmező, hogy mutassa a sikeres vagy sikertelen végrehajtást.
    • +
  • EIP-196 – az elliptikus görbe és a skaláris szorzás bevezetése, hogy támogassa a ZK-SNARK-okat.
    • +
  • EIP-197 – az elliptikus görbe és a skaláris szorzás bevezetése, hogy támogassa a ZK-SNARK-okat.
    • +
  • EIP-198 – az RSA aláírásellenőrzés lehetővé tétele.
    • +
  • EIP-211 – a változó hosszúságú visszatérési értékek támogatása.
    • +
  • EIP-214 – a STATICCALL opkód bevezetése, hogy állapotot nem befolyásoló hívásokat lehessen indítani más szerződések felé.
    • +
  • EIP-100 – a nehézség beállítási formulájának változtatása.
    • +
  • EIP-649 – a nehézségi bomba elhalasztása 1 évvel, és a blokkjutalom csökkentése 5 ETH-ről 3-ra.
    • +
+ + + + + +## 2016 {#2016} + +### Spurious Dragon {#spurious-dragon} + + + +#### Összegzés {#spurious-dragon-summary} + +A Spurious Dragon elágazás volt a második válasz a szolgáltatásmegtagadásos (DoS) támadásokkal szemben a hálózaton (2016. szeptember/október), amely az alábbiakat tartalmazta: + +- opkód-díjszabás finomhangolása a jövőbeli támadások megakadályozása érdekében. +- a blokkláncállapot „leeresztésének” lehetővé tétele. +- visszajátszásos támadás elleni védelem hozzáadása. + +[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/) + + + +
    +
  • EIP-155 – megakadályozza, hogy egy Ethereum-láncról a tranzakciókat újra elküldjék egy alternatív láncon, például egy teszthálózati tranzakciót lejátszanak a főhálózaton.
    • +
  • EIP-160 – az EXP opkód árának korrigálása, hogy ezáltal nehezebb legyen lelassítani a hálózatot az intenzív számítást igénylő szerződésműködésekkel.
    • +
  • EIP-161 – az üres számlák eltávolítása, melyeket a szolgáltatásmegtagadási (DoS) támadások alatt hoztak létre.
    • +
  • EIP-170 – a láncon lévő szerződés maximális kódméretének megnövelése 24 576 bájtra.
    • +
+ + + +--- + +### Tangerine whistle {#tangerine-whistle} + + + +#### Összegzés {#tangerine-whistle-summary} + +A Tangerine Whistle elágazás volt a első válasz a szolgáltatásmegtagadásos (DoS) támadásokkal szemben a hálózaton (2016. szeptember/október), mely az alábbiakat tartalmazta: + +- az alulárazott opkódokkal kapcsolatos sürgős hálózati kérdések kezelése. + +[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/) + + + +
    +
  • EIP-150 – megnöveli azon opkódok gázköltségeit, melyeket teleszemetelési (spam) támadásokra lehet használni.
    • +
  • EIP-158 – csökkenti a státuszméretet azáltal, hogy eltávolítja az üres számlákat, melyeket alacsony költségen küldtek be a státuszba a korábbi Ethereum-protokoll hibái miatt.
    • +
+ + + +--- + +### DAO elágazás {#dao-fork} + + + +#### Összegzés {#dao-fork-summary} + +A DAO elágazás volt a válasz a [2016-os DAO-támadásra](https://www.coindesk.com/learn/understanding-the-dao-attack/), amikor egy sérülékeny [DAO](/glossary/#dao) szerződésből 3,6 millió ETH-t ürítettek le a támadás során. Az elágazás átmozgatta a pénzt a hibás szerződésből egy [új szerződésbe](https://etherscan.io/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754), amelynek csak kiutalási funkciója volt. Bárki, aki veszteséget szenvedett el, kivehetett 1 ETH-t a tárcájában lévő minden 100 DAO tokenre. + +Ennek az akciónak a menetét megszavazták az Ethereum közösségen belül. Bármely ETH tulajdonos szavazhatott egy tranzakción keresztül [egy szavazási platformon](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/). A fork mellett több mint a szavazók 85%-a voksolt. + +Némely bányász nem támogatta az elágazást, mivel a DAO incidens nem a protokollból származó hibából eredt. Ők ezután létrehozták az [Ethereum Classicot](https://ethereumclassic.org/). + +[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2016/07/20/hard-fork-completed/) + +--- + +### Homestead {#homestead} + + + +#### Összegzés {#homestead-summary} + +A Homestead elágazás a jövőbe tekintett. Számos protokollváltoztatást és egy hálózati módosítást tartalmazott, mely lehetővé tette az Ethereum számára a további hálózati változtatásokat. + +[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2016/02/29/homestead-release/) + + + +
    +
  • EIP-2 – a szerződéslétrehozási folyamat szerkesztése.
    • +
  • EIP-7 – a DELEGATECALL új opkód bevezetése
    • +
  • EIP-8 – bevezették a devp2p jövőkompatibilitási (forward compatibility) követelményeket
    • +
+ + + + + +## 2015 {#2015} + +### Frontier thawing {#frontier-thawing} + + + +#### Összegzés {#frontier-thawing-summary} + +A Frontier thawing elágazás megemelte az 5000-es [gázhatárt](/glossary/#gas) [blokkonként](/glossary/#block) és beállította az alapértelmezett gázárat 51 [gweire](/glossary/#gwei). Ez lehetővé tette a tranzakciók létrejöttét, mivel azokhoz 21 000 gázra van szükség. Bevezették a [nehézségi bombát](/glossary/#difficulty-bomb), hogy lehetőség legyen egy jövőbeli végleges elágazásra (hard fork) a [proof-of-stake](/glossary/#pos) mechanizmusra való áttérésnél. + +- [Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2015/08/04/the-thawing-frontier/) +- [Tekintse meg az Ethereum 1. protokollfrissítéséről szóló cikket](https://blog.ethereum.org/2015/08/04/ethereum-protocol-update-1/) + +--- + +### Frontier {#frontier} + + + +#### Összegzés {#frontier-summary} + +A Frontier egy működő, de teljesen leegyszerűsített implementációja volt az Ethereum projektnek. A sikeres Olympic tesztelési fázist követte. A műszaki felhasználóknak, kimondottan a fejlesztőknek készült. A [blokkoknak](/glossary/#block) 5000-es [gázhatár](/glossary/#gas) volt beállítva. Ez a „kiolvasztási” időszak lehetővé tette a bányászok számára, hogy elindítsák a tevékenységüket, és a korai felhasználóknak, hogy telepítsék a klienseiket anélkül, hogy sietniük kellene. + +[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2015/07/22/frontier-is-coming-what-to-expect-and-how-to-prepare/) + + + +## 2014 {#2014} + +### Ether-értékesítés {#ether-sale} + + + +Az Ether értékesítése hivatalosan 42 napig tartott. BTC-vel lehetett érte fizetni. + +[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2014/07/22/launching-the-ether-sale/) + +--- + +### Sárgakönyv kiadása {#yellowpaper} + + + +A Sárgakönyv, melynek a szerzője Dr. Gavin Wood, az Ethereum protokoll műszaki meghatározása. + +[A Sárgakönyv megtekintése](https://github.com/ethereum/yellowpaper) + + + +## 2013 {#2013} + +### A Fehérkönyv kiadása {#whitepaper} + + + +A bemutatkozó kiadvány, melyet Vitalik Buterin, az Ethereum alapítója adott ki 2013-ban, a projekt 2015-ös indulása előtt. + + + Fehérkönyv + diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" new file mode 100644 index 00000000000..6d6d4364b23 --- /dev/null +++ "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" @@ -0,0 +1,658 @@ +--- +title: A okosszerződések anatómiája +description: Egy részletes betekintés az okosszerződések felépítésébe, beleértve a függvényeket, adatokat és változókat. +lang: hu +--- + +Az okosszerződés egy olyan program, mely egy cím alatt fut az Ethereumon. Adatokból és függvényekből állnak, melyeket végre lehet hajtani bemenő tranzakciók által. Ez az áttekintés az okosszerződések felépítéséről szól. + +## Előfeltételek {#prerequisites} + +Először tekintse meg az [okosszerződésekről](/developers/docs/smart-contracts/) szóló cikket. Ez a dokumentum feltételezi, hogy már jártas a programozási nyelvekben, mint a JavaScript vagy a Python. + +## Adat {#data} + +Minden szerződésadatot hozzá kell rendelni egy lokációhoz, mely lehet a `storage` vagy a `memory`. Költséges a tárhelyet módosítani egy okosszerződésben, tehát érdemes fontolóra venni, hogy hol legyen az adat. + +### Tárhely {#storage} + +Az állandó adatokat tárolásnak nevezzük, és állapotváltozók reprezentálják őket. Ezeket az értékeket permanensen a blokkláncon tároljuk. Deklarálnia kell a típust, hogy a szerződés számon tudja tartani, hogy mekkora tárhelyre lesz szüksége a blokkláncon az átfordításkor. + +```solidity +// Solidity példa +contract SimpleStorage { + uint storedData; // Állapotváltozó + // ... +} +``` + +```python +# Vyper példa +storedData: int128 +``` + +Ha Ön programozott már objektumorientált nyelven, akkor a legtöbb típus valószínűleg ismerős lesz. Ugyanakkor az `address` típus új lesz, ha még csak most ismerkedik az Ethereum fejlesztéssel. + +Az `address` típus egy Ethereum címet tud tárolni, mely 20 bájttal vagy 160 bittel egyenlő. Hexadecimális értéket ad vissza vezető 0x-szel. + +A többi típus: + +- boolean +- egész (integer) +- fixpontos szám +- fix méretű bájttömb +- dinamikus méretű bájttömb +- Racionális és egész szám literálok +- String literálok +- Hexadecimális literálok +- Enum + +További magyarázatért tekintse meg az alábbi dokumentumokat: + +- [Vyper típusok megtekintése](https://vyper.readthedocs.io/en/v0.1.0-beta.6/types.html#value-types) +- [Solidity típusok megtekintése](https://solidity.readthedocs.io/en/latest/types.html#value-types) + +### Memória {#memory} + +Memóriaváltozóknak nevezzük azokat az értékeket, melyek csak a szerződésfunkció végrehajtása alatt tárolódnak. Mivel nem kell őket permanensen a blokkláncon tárolni, így sokkal olcsóbb a használatuk. + +Tudjon meg többet az EVM adattárolási módszeréről a [Solidity dokumentációból](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html?highlight=memory#storage-memory-and-the-stack) (a „Storage, Memory and the Stack” szekcióból). + +### Környezeti változók {#environment-variables} + +A szerződésben meghatározott változók mellett van néhány speciális globális változó is. Elsősorban a blokklánccal vagy az aktuális tranzakcióval kapcsolatos információk nyújtására szolgálnak. + +Példák: + +| **Tul.** | **Állapotváltozó** | **Leírás** | +| ----------------- | ------------------ | ----------------------------------- | +| `block.timestamp` | uint256 | Jelenlegi blokk korszak időbélyege | +| `msg.sender` | address | Az üzenet küldője (jelenlegi hívás) | + +## Függvények {#functions} + +A legegyszerűbben megfogalmazva, a függvények információkat kaphatnak vagy információkat állíthatnak be válaszul a bejövő tranzakciókra. + +Kétfajta függvényhívás létezik: + +- `internal` – ezek nem okoznak EVM hívást + - A belső (internal) függvényeket és állapotváltozókat csak belülről lehet elérni (vagyis a jelenlegi szerződésből vagy a származtatott szerződésekből) +- `external` – ezek EVM hívást okoznak + - A külső (external) függvények a szerződés felületének részei, mely azt jelenti, hogy meg lehet őket hívni más szerződésekből vagy tranzakciókon keresztül. Egy külső függvény `f` kódját nem lehet belülről meghívni (vagyis az `f()` nem működik, de a `this.f()` igen). + +Ezenkívül lehetnek `public` vagy `private` típusúak is + +- a `public` függvényeket belülről lehet meghívni vagy kívülről üzenetek által +- a `private` függvények csak abban a szerződésben láthatóak, amiben definiálták őket, a származtatott szerződésekben nem + +A függvények és az állapotváltozók is lehetnek publikusak vagy privátak + +Íme egy függvény, mely egy állapotváltozó értékét állítja be egy szerződésben: + +```solidity +// Solidity példa +function update_name(string value) public { + dapp_name = value; +} +``` + +- A `string` típusú `value` paraméter kerül be a függvénybe: `update_name` +- Ez `public` módon lett deklarálva, így mindenki hozzáfér +- Nem `view` módon lett deklarálva, így módosíthatja a szerződésállapotot + +### Nézet (view) függvények {#view-functions} + +Ezek a függvények azt ígérik, hogy nem módosítják a szerződés adatainak állapotát. Általános példák a „getter” függvények – ezeket használhatja például egy felhasználó egyenlegének lekérdezésére. + +```solidity +// Solidity példa +function balanceOf(address _owner) public view returns (uint256 _balance) { + return ownerPizzaCount[_owner]; +} +``` + +```python +dappName: public(string) + +@view +@public +def readName() -> string: + return dappName +``` + +Mi számít állapotmódosításnak: + +1. Állapotváltozókba írás. +2. [Események kibocsátása](https://solidity.readthedocs.io/en/v0.7.0/contracts.html#events). +3. [Másik szerződés létrehozás](https://solidity.readthedocs.io/en/v0.7.0/control-structures.html#creating-contracts). +4. A `selfdestruct` használata. +5. Ether küldése hívásokkal. +6. Bármely függvény meghívása, mely nincs `view` vagy `pure` jelöléssel ellátva. +7. Alacsony szintű hívások. +8. Egysoros assembly használata, mely bizonyos opkódot tartalmaz. + +### Konstruktor függvények {#constructor-functions} + +A `constructor` csak egyszer fut le, amikor a szerződést először telepítik. Mint a `constructor` számos osztályalapú programozási nyelv esetében, ezek a függvények gyakran inicializálják az állapotváltozókat a meghatározott értékeikre. + +```solidity +// Solidity példa +// Inicializálja a szerződés adatait, beállítja az 'owner-t' +// a szerződés létrehozó címére. +constructor() public { + // Minden okosszerződés külső tranzakciókra hagyatkozik a függvényeik végrehajtására. + // az `msg` globális változó, mely az adott tranzakcióhoz tartozó adatot tartalmaz, + // mint a küldő címe és az ETH mennyisége a tranzakcióban. + // Több infó: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + owner = msg.sender; +} +``` + +```python +# Vyper példa + +@external +def __init__(_beneficiary: address, _bidding_time: uint256): + self.beneficiary = _beneficiary + self.auctionStart = block.timestamp + self.auctionEnd = self.auctionStart + _bidding_time +``` + +### Beépített függvények {#built-in-functions} + +A szerződésben meghatározott függvények és változók mellett van néhány speciális beépített függvény is. A legnyilvánvalóbb példák: + +- `address.send()` – Solidity +- `send(address)` – Vyper + +Ez lehetőséget ad a szerződéseknek, hogy ETH-t küldjenek más számláknak. + +## Függvények írása {#writing-functions} + +A függvénynek szüksége van: + +- egy paraméterváltozóra és egy típusra (ha elfogad paramétereket) +- a belső/külső deklarációra +- a pure/view/payable deklarációra +- a visszatérítési érték típusára (ha van visszatérítési értéke) + +```solidity +pragma solidity >=0.4.0 <=0.6.0; + +contract ExampleDapp { + string dapp_name; // state variable + + // Called when the contract is deployed and initializes the value + constructor() public { + dapp_name = "My Example dapp"; + } + + // Get Function + function read_name() public view returns(string) { + return dapp_name; + } + + // Set Function + function update_name(string value) public { + dapp_name = value; + } +} +``` + +Egy kész szerződés nagyjából így nézne ki. Itt a `constructor` függvény biztosítja a `dapp_name` változó kezdeti értékét. + +## Események és naplózások {#events-and-logs} + +Az eseményeken keresztül tud kommunikálni az okosszerződés és a frontend vagy más feliratkozó alkalmazás. Amikor egy tranzakciót validálnak, az okosszerződések eseményeket és naplófájlokat bocsáthatnak ki, melyet a frontend feldolgozhat és hasznosíthat. + +## Jegyzetekkel ellátott példák {#annotated-examples} + +Íme néhány példa, amelyet Solidity-ben írtak. Ha szeretne megismerkedni a kóddal, akkor kipróbálhatja a [Remixben](http://remix.ethereum.org). + +### Hello world {#hello-world} + +```solidity +// A Solidity verziószámát írja elő szemantikailag. +// Több információ: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma +pragma solidity ^0.5.10; + +// Egy `HelloWorld` nevű szerződés definiálása. +// A szerződés egy függvények és adatok (az állapota) gyűjteménye. +// Telepítés után a szerződés egy bizonyos címen él az Ethereum blokkláncon. +//További információ: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html +contract HelloWorld { + + // Deklarálja a `string` típusú `message` állapotváltozót. + // Az állapotváltozók olyan változók, melyeknek értékei permanensen tárolódnak a szerződés tárhelyén. + // A `public` kulcsszó lehetővé teszi a változó szerződésen kívüli elérését + // és függvényt hoz létre, mellyel más szerződések vagy kliensek le tudják kérdezni az értéket. + string public message; + + // Más osztály alapú nyelvhez hasonlóan a konstruktor egy + // speciális függvény, mely csak egyszer fut le a szerződés létrehozáskor. + // A konstruktorokat az szerződés adatainak inicializálásra lehet használni. + // További információ: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors + constructor(string memory initMessage) public { + // Az `initMessage` string paramétert fogadja el és beállítja + // a szerződés `message` tárhely változójába). + message = initMessage; + } + + // Egy publikus függvény, mely egy string paramétert fogad el + // és frissíti a `message` tárhely változót. + function update(string memory newMessage) public { + message = newMessage; + } +} +``` + +### Token {#token} + +```solidity +pragma solidity ^0.5.10; + +contract Token { + // Egy `address` olyan, mint egy email cím - az Ethereum számlák beazonosítására szolgál. + // A címek okosszerződéseket vagy külső (felhasználói) számlákat jelölnek. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#address + address public owner; + + // A `mapping` lényegében egy hash tábla adatszerkezet. + // Ez a `mapping` egy unsigned integert (a token egyenleget) rendel hozzá egy címhez (a token tartóhoz). + // További információ: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types + mapping (address => uint) public balances; + + // Az eseményekkel lehet tevékenységet logolni a blokkláncon. + // Az Ethereum kliensek figyelhetik az eseményeket, hogy reagáljanak az szerződés állapotváltozásokra. + // További információ: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events + event Transfer(address from, address to, uint amount); + + // Inicializálja a szerződés adatot, beállítja az `owner` + // változót a szerződés létrehozó címére. + constructor() public { + // Minden okosszerződés külső tranzakciókra hagyatkozik a függvényeik végrehajtására. + // az `msg` globális változó, mely az adott tranzakcióhoz tartozó adatot tartalmaz, + // mint a küldő címe és az ETH mennyisége a tranzakcióban. + //További információ: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties + owner = msg.sender; + } + + // Új tokeneket hoz létre és elküldi egy címre. + function mint(address receiver, uint amount) public { + // A `require` egy kontrol struktúra, mely bizonyos feltételek betartatására szolgál. + // Ha a `require` állítás `false` értéket ad, egy kivétel triggerelődik, + // mely visszaállít minden állapotváltozást a jelenlegi hívás alatt. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + + // Only the contract owner can call this function + require(msg.sender == owner, "You are not the owner."); + + // Enforces a maximum amount of tokens + require(amount < 1e60, "Maximum issuance exceeded"); + + // Increases the balance of `receiver` by `amount` + balances[receiver] += amount; + } + + // Sends an amount of existing tokens from any caller to an address. + function transfer(address receiver, uint amount) public { + // A küldőnek elég tokennel kell rendelkeznie + require(amount <= balances[msg.sender], "Insufficient balance."); + + // Beállítja a token a két cím token mennyiségét + balances[msg.sender] -= amount; + balances[receiver] += amount; + + // Kibocsájtja a korábban definiált eseményt + emit Transfer(msg.sender, receiver, amount); + } +} +``` + +### Egyedi digitális eszköz {#unique-digital-asset} + +```solidity +pragma solidity ^0.5.10; + +// Szimbólumokat importál be más fájlokból a jelenlegi szerződésbe. +// Ebben az esetben egy pár segítő szerződést az OpenZeppelinről. +// További információ: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files + +import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol"; +import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol"; +import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol"; +import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol"; + +// Az `is` kulcsszót használjuk, hogy külső szerződések függvényeit és kulcsszavait örököltessük. +// Ebben az esetben, `CryptoPizza` örököl az `IERC721` és az `ERC165` szerződésekből. +// További információ: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance +contract CryptoPizza is IERC721, ERC165 { + // Az OpenZeppelin SafeMath könyvtárát használja aritmetikai számítások biztonságos elvégzésére. + // További információ: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath + using SafeMath for uint256; + + // A konstans állapotváltozók a Solidity-ben hasonlóak más nyelvekhez + // de a fordítás ideje alatt konstans kifejezésből kell hozzárendelni. + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables + uint256 constant dnaDigits = 10; + uint256 constant dnaModulus = 10 ** dnaDigits; + bytes4 private constant _ERC721_RECEIVED = 0x150b7a02; + + // Struct types let you define your own type + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs + struct Pizza { + string name; + uint256 dna; + } + + // Creates an empty array of Pizza structs + Pizza[] public pizzas; + + // Mapping from pizza ID to its owner's address + mapping(uint256 => address) public pizzaToOwner; + + // Mapping from owner's address to number of owned token + mapping(address => uint256) public ownerPizzaCount; + + // Mapping from token ID to approved address + mapping(uint256 => address) pizzaApprovals; + + // You can nest mappings, this example maps owner to operator approvals + mapping(address => mapping(address => bool)) private operatorApprovals; + + // Internal function to create a random Pizza from string (name) and DNA + function _createPizza(string memory _name, uint256 _dna) + // The `internal` keyword means this function is only visible + // within this contract and contracts that derive this contract + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters + internal + // `isUnique` is a function modifier that checks if the pizza already exists + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers + isUnique(_name, _dna) + { + // Adds Pizza to array of Pizzas and get id + uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1); + + // Checks that Pizza owner is the same as current user + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions + + // note that address(0) is the zero address, + // indicating that pizza[id] is not yet allocated to a particular user. + + assert(pizzaToOwner[id] == address(0)); + + // Maps the Pizza to the owner + pizzaToOwner[id] = msg.sender; + ownerPizzaCount[msg.sender] = SafeMath.add( + ownerPizzaCount[msg.sender], + 1 + ); + } + + // Creates a random Pizza from string (name) + function createRandomPizza(string memory _name) public { + uint256 randDna = generateRandomDna(_name, msg.sender); + _createPizza(_name, randDna); + } + + // Generates random DNA from string (name) and address of the owner (creator) + function generateRandomDna(string memory _str, address _owner) + public + // Functions marked as `pure` promise not to read from or modify the state + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions + pure + returns (uint256) + { + // Generates random uint from string (name) + address (owner) + uint256 rand = uint256(keccak256(abi.encodePacked(_str))) + + uint256(_owner); + rand = rand % dnaModulus; + return rand; + } + + // Returns array of Pizzas found by owner + function getPizzasByOwner(address _owner) + public + // Functions marked as `view` promise not to modify state + // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions + view + returns (uint256[] memory) + { + // Uses the `memory` storage location to store values only for the + // lifecycle of this function call. + // További info: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack + uint256[] memory result = new uint256[](ownerPizzaCount[_owner]); + uint256 counter = 0; + for (uint256 i = 0; i < pizzas.length; i++) { + if (pizzaToOwner[i] == _owner) { + result[counter] = i; + counter++; + } + } + return result; + } + + // Átadja a Pizza tulajdonjogot és másik címnek + function transferFrom(address _from, address _to, uint256 _pizzaId) public { + require(_from != address(0) && _to != address(0), "Invalid address."); + require(_exists(_pizzaId), "Pizza does not exist."); + require(_from != _to, "Cannot transfer to the same address."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + + ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1); + ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1); + pizzaToOwner[_pizzaId] = _to; + + // Kibocsájt egy eseményt, mely az importált IERC721 szerződésben van definiálva + emit Transfer(_from, _to, _pizzaId); + _clearApproval(_to, _pizzaId); + } + + /** + * Biztonságosan átadja a egy adott token ID tulajdonjogát egy másik címnek + * Ha a cél cím egy szerződés, akkor az `onERC721Received`-nek implementálva kell lennie, + * mely egy biztonságos átadáskor meghívódik és visszaadja a bűvös értéket + * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; + * ellenkező esetben a transfer visszafordul. + */ + function safeTransferFrom(address from, address to, uint256 pizzaId) + public + { + // solium-disable-next-line arg-overflow + this.safeTransferFrom(from, to, pizzaId, ""); + } + + /** + * Biztonságosan átadja a egy adott token ID tulajdonjogát egy másik címnek + * Ha a cél cím egy szerződés, akkor az `onERC721Received`-nek implementálva kell lennie, + * mely egy biztonságos átadáskor meghívódik és visszaadja a bűvös értéket + * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; + * ellenkező esetben a transfer visszafordul. + */ + function safeTransferFrom( + address from, + address to, + uint256 pizzaId, + bytes memory _data + ) public { + this.transferFrom(from, to, pizzaId); + require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implement onERC721Received."); + } + + /** + * Internal function to invoke `onERC721Received` on a target address + * The call is not executed if the target address is not a contract + */ + function _checkOnERC721Received( + address from, + address to, + uint256 pizzaId, + bytes memory _data + ) internal returns (bool) { + if (!isContract(to)) { + return true; + } + + bytes4 retval = IERC721Receiver(to).onERC721Received( + msg.sender, + from, + pizzaId, + _data + ); + return (retval == _ERC721_RECEIVED); + } + + // Burns a Pizza - destroys Token completely + // The `external` function modifier means this function is + // part of the contract interface and other contracts can call it + function burn(uint256 _pizzaId) external { + require(msg.sender != address(0), "Invalid address."); + require(_exists(_pizzaId), "Pizza does not exist."); + require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + + ownerPizzaCount[msg.sender] = SafeMath.sub( + ownerPizzaCount[msg.sender], + 1 + ); + pizzaToOwner[_pizzaId] = address(0); + } + + // Returns count of Pizzas by address + function balanceOf(address _owner) public view returns (uint256 _balance) { + return ownerPizzaCount[_owner]; + } + + // Returns owner of the Pizza found by id + function ownerOf(uint256 _pizzaId) public view returns (address _owner) { + address owner = pizzaToOwner[_pizzaId]; + require(owner != address(0), "Invalid Pizza ID."); + return owner; + } + + // Approves other address to transfer ownership of Pizza + function approve(address _to, uint256 _pizzaId) public { + require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner."); + pizzaApprovals[_pizzaId] = _to; + emit Approval(msg.sender, _to, _pizzaId); + } + + // Returns approved address for specific Pizza + function getApproved(uint256 _pizzaId) + public + view + returns (address operator) + { + require(_exists(_pizzaId), "Pizza does not exist."); + return pizzaApprovals[_pizzaId]; + } + + /** + * Private function to clear current approval of a given token ID + * Reverts if the given address is not indeed the owner of the token + */ + function _clearApproval(address owner, uint256 _pizzaId) private { + require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner."); + require(_exists(_pizzaId), "Pizza does not exist."); + if (pizzaApprovals[_pizzaId] != address(0)) { + pizzaApprovals[_pizzaId] = address(0); + } + } + + /* + * Sets or unsets the approval of a given operator + * An operator is allowed to transfer all tokens of the sender on their behalf + */ + function setApprovalForAll(address to, bool approved) public { + require(to != msg.sender, "Cannot approve own address"); + operatorApprovals[msg.sender][to] = approved; + emit ApprovalForAll(msg.sender, to, approved); + } + + // Tells whether an operator is approved by a given owner + function isApprovedForAll(address owner, address operator) + public + view + returns (bool) + { + return operatorApprovals[owner][operator]; + } + + // Takes ownership of Pizza - only for approved users + function takeOwnership(uint256 _pizzaId) public { + require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); + address owner = this.ownerOf(_pizzaId); + this.transferFrom(owner, msg.sender, _pizzaId); + } + + // Checks if Pizza exists + function _exists(uint256 pizzaId) internal view returns (bool) { + address owner = pizzaToOwner[pizzaId]; + return owner != address(0); + } + + // Checks if address is owner or is approved to transfer Pizza + function _isApprovedOrOwner(address spender, uint256 pizzaId) + internal + view + returns (bool) + { + address owner = pizzaToOwner[pizzaId]; + // Disable solium check because of + // https://github.com/duaraghav8/Solium/issues/175 + // solium-disable-next-line operator-whitespace + return (spender == owner || + this.getApproved(pizzaId) == spender || + this.isApprovedForAll(owner, spender)); + } + + // Check if Pizza is unique and doesn't exist yet + modifier isUnique(string memory _name, uint256 _dna) { + bool result = true; + for (uint256 i = 0; i < pizzas.length; i++) { + if ( + keccak256(abi.encodePacked(pizzas[i].name)) == + keccak256(abi.encodePacked(_name)) && + pizzas[i].dna == _dna + ) { + result = false; + } + } + require(result, "Pizza with such name already exists."); + _; + } + + // Returns whether the target address is a contract + function isContract(address account) internal view returns (bool) { + uint256 size; + // Currently there is no better way to check if there is a contract in an address + // than to check the size of the code at that address. + // Lásd https://ethereum.stackexchange.com/a/14016/36603 + // hogy hogyan működik ez. + // TODO A Serenity release előtt ellenőrizni, mivel azután minden cím + // szerződés lesz. + // solium-disable-next-line security/no-inline-assembly + assembly { + size := extcodesize(account) + } + return size > 0; + } +} +``` + +## További olvasnivaló {#further-reading} + +Tekintse meg a Solidity és a Vyper dokumentációit az okosszerződések teljesebb áttekintésért: + +- [Solidity](https://solidity.readthedocs.io/) +- [Vyper](https://vyper.readthedocs.io/) + +## Kapcsolódó témák {#related-topics} + +- [Okosszerződések](/developers/docs/smart-contracts/) +- [Ethereum virtuális gép](/developers/docs/evm/) + +## Kapcsolódó útmutatók {#related-tutorials} + +- [A szerződések méretének csökkentése, hogy ne okozzon gondot a méretkorlát](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– Gyakorlati tanácsok az okosszerződés méretének redukálására._ +- [Okosszerződések adatnaplózása az események mentén](/developers/tutorials/logging-events-smart-contracts/) _– Bevezetés az okossszerződések eseményeibe, s azok használata az adatnaplózáshoz._ +- [Más szerződésekkel való interakció a Solidity által](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– Hogyan telepítsen okosszerződést egy létező szerződésből és kapcsolódjon azzal._ diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" new file mode 100644 index 00000000000..ba918afa274 --- /dev/null +++ "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" @@ -0,0 +1,282 @@ +--- +title: Okos szerződések fordítása +description: Magyarázat arról, hogy miért kell az okosszerződéseket átfordítani, és hogy pontosan mit csinál az átfordítás. +lang: hu +incomplete: true +--- + +Át kell fordítani a szerződéseket, hogy a webalkalmazás és az Ethereum virtuális gép (EVM) meg tudja érteni azokat. + +## Előfeltételek {#prerequisites} + +Segítségére lehetnek az [okosszerződésekről](/developers/docs/smart-contracts/) és az [Ethereum virtuális gépről](/developers/docs/evm/) szóló cikkek, mielőtt belekezdene az átfordításba. + +## Az EVM {#the-evm} + +Ahhoz, hogy az [EVM](/developers/docs/evm/) le tudja futtatni a szerződésedet, **bytecode-ban** kell lennie. Az átfordítás során ebből: + +```solidity +pragma solidity 0.4.24; + +contract Greeter { + + function greet() public constant returns (string) { + return "Hello"; + } + +} +``` + +**ez lesz:** + +``` +PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900 +``` + +Ezeket **opkódoknak** nevezzük. Az EVM opkódok olyan alacsony szintű utasítások, amelyeket az Ethereum virtuális gép (EVM) képes végrehajtani. Minden opkód egy adott műveletet képvisel, például aritmetikai műveleteket, logikai műveleteket, adatmanipulációt, vezérlésáramlást stb. + +[Bővebben az opkódokról](/developers/docs/evm/opcodes/) + +## Webalkalmazások {#web-applications} + +Az átfordító ezenkívül létrehozza az **Application Binary Interface-t (ABI)**, amire szüksége lesz, hogy az Ön alkalmazása megértse a szerződést, és meg tudja hívni a szerződés függvényeit. + +Az ABI egy JSON fáj, mely leírja a telepített szerződést és az okosszerződés függvényeit. Ez segít áthidalni a szakadékot a web2 és a web3 között. + +Egy [Javascript klienskönyvtár](/developers/docs/apis/javascript/) fogja az **ABI-t** olvasni, hogy Ön meghívhassa az okosszerződését a webalkalmazás felületén. + +Alább látható az ERC-20 tokenszerződés ABI-ja. Az ERC-20 egy token, mellyel az Ethereumon kereskedhetsz. + +```json +[ + { + "constant": true, + "inputs": [], + "name": "name", + "outputs": [ + { + "name": "", + "type": "string" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": false, + "inputs": [ + { + "name": "_spender", + "type": "address" + }, + { + "name": "_value", + "type": "uint256" + } + ], + "name": "approve", + "outputs": [ + { + "name": "", + "type": "bool" + } + ], + "payable": false, + "stateMutability": "nonpayable", + "type": "function" + }, + { + "constant": true, + "inputs": [], + "name": "totalSupply", + "outputs": [ + { + "name": "", + "type": "uint256" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": false, + "inputs": [ + { + "name": "_from", + "type": "address" + }, + { + "name": "_to", + "type": "address" + }, + { + "name": "_value", + "type": "uint256" + } + ], + "name": "transferFrom", + "outputs": [ + { + "name": "", + "type": "bool" + } + ], + "payable": false, + "stateMutability": "nonpayable", + "type": "function" + }, + { + "constant": true, + "inputs": [], + "name": "decimals", + "outputs": [ + { + "name": "", + "type": "uint8" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": true, + "inputs": [ + { + "name": "_owner", + "type": "address" + } + ], + "name": "balanceOf", + "outputs": [ + { + "name": "balance", + "type": "uint256" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": true, + "inputs": [], + "name": "symbol", + "outputs": [ + { + "name": "", + "type": "string" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "constant": false, + "inputs": [ + { + "name": "_to", + "type": "address" + }, + { + "name": "_value", + "type": "uint256" + } + ], + "name": "transfer", + "outputs": [ + { + "name": "", + "type": "bool" + } + ], + "payable": false, + "stateMutability": "nonpayable", + "type": "function" + }, + { + "constant": true, + "inputs": [ + { + "name": "_owner", + "type": "address" + }, + { + "name": "_spender", + "type": "address" + } + ], + "name": "allowance", + "outputs": [ + { + "name": "", + "type": "uint256" + } + ], + "payable": false, + "stateMutability": "view", + "type": "function" + }, + { + "payable": true, + "stateMutability": "payable", + "type": "fallback" + }, + { + "anonymous": false, + "inputs": [ + { + "indexed": true, + "name": "owner", + "type": "address" + }, + { + "indexed": true, + "name": "spender", + "type": "address" + }, + { + "indexed": false, + "name": "value", + "type": "uint256" + } + ], + "name": "Approval", + "type": "event" + }, + { + "anonymous": false, + "inputs": [ + { + "indexed": true, + "name": "from", + "type": "address" + }, + { + "indexed": true, + "name": "to", + "type": "address" + }, + { + "indexed": false, + "name": "value", + "type": "uint256" + } + ], + "name": "Transfer", + "type": "event" + } +] +``` + +## További olvasnivaló {#further-reading} + +- [ABI specifikáció](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_ + +## Kapcsolódó témák {#related-topics} + +- [Javascript klienskönyvtárak](/developers/docs/apis/javascript/) +- [Ethereum virtuális gép](/developers/docs/evm/) diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" new file mode 100644 index 00000000000..2e69c8ec918 --- /dev/null +++ "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" @@ -0,0 +1,81 @@ +--- +title: Okos szerződések telepítése +description: +lang: hu +--- + +Telepítenie kell az okosszerződését azért, hogy az Ethereum hálózat felhasználói számára elérhető legyen. + +Egy okosszerződés telepítéséhez csak el kell küldenie egy Ethereum-tranzakciót, mely tartalmazza az átfordított kódot címzett megadása nélkül. + +## Előfeltételek {#prerequisites} + +Érdemes tisztában lennie az [Ethereum hálózatokkal](/developers/docs/networks/), a [tranzakciókkal](/developers/docs/transactions/) és az [okosszerződések anatómiájával](/developers/docs/smart-contracts/anatomy/) mielőtt belefog az okosszerződéstelepítésbe. + +A szerződés telepítéséért ETH-t kell fizetni, így érdemes ismernie a [gázt és a díjakat](/developers/docs/gas/) az Ethereumon. + +Végül át kell fordítani a szerződést telepítés előtt, ezért előtte tekintse meg az [okosszerződések telepítése](/developers/docs/smart-contracts/compiling/) című cikket. + +## Hogyan telepítse az okosszerződését {#how-to-deploy-a-smart-contract} + +### Mire lesz szükséged {#what-youll-need} + +- A szerződés bájtkódjára – ez az [átfordítás](/developers/docs/smart-contracts/compiling/) alatt generálódik +- ETH a gázra – meg kell adni a gázlimitet, mint bármely más tranzakciónál, de fontos tudni, hogy a szerződéstelepítés sokkal több gázt igényel, mint egy egyszerű ETH átutalás +- egy telepítőszkript vagy plugin +- hozzáférés egy [Ethereum-csomóponthoz](/developers/docs/nodes-and-clients/) a sajátja futtatásával, egy nyilvános csomóponthoz történő csatlakozással vagy egy API-kulcson keresztül egy [csomópontszolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service/) használatával + +### Az okosszerződés telepítésének lépései {#steps-to-deploy} + +A konkrét lépések az adott fejlesztői keretrendszertől függenek. Például megtekintheti a [Hardhat dokumentációt a szerződéstelepítésről](https://hardhat.org/guides/deploying.html) vagy a [Foundry dokumentációt az okosszerződések telepítéséről és ellenőrzéséről](https://book.getfoundry.sh/forge/deploying). A telepítés után a szerződésének lesz egy Ethereum-címe, ahogy a többi [számlának](/developers/docs/accounts/) is, és ez a [forráskód-ellenőrző eszközök](/developers/docs/smart-contracts/verifying/#source-code-verification-tools) segítségével lesz ellenőrizhető. + +## Kapcsolódó eszközök {#related-tools} + +**Remix – _A Remix IDE lehetővé teszi az okosszerződések fejlesztését, telepítését és kezelését az Ethereumhoz hasonló blokkláncokon_** + +- [Remix](https://remix.ethereum.org) + +**Tenderly – _Web3-fejlesztői platform, amely okosszerződés fejlesztéséhez, teszteléséhez, felügyeletéhez és működtetéséhez biztosít hibakeresési, megfigyelési és infrastruktúrához kapcsolódó építőelemeket_** + +- [tenderly.co](https://tenderly.co/) +- [Dokumentáció](https://docs.tenderly.co/) +- [GitHub](https://github.com/Tenderly) +- [Discord](https://discord.gg/eCWjuvt) + +**Hardhat – _Fejlesztői környezet Ethereum-szoftverek átfordításához, telepítéséhez, teszteléséhez és a hibakereséshez_** + +- [hardhat.org](https://hardhat.org/getting-started/) +- [Dokumentáció a szerződéstelepítésről](https://hardhat.org/guides/deploying.html) +- [GitHub](https://github.com/nomiclabs/hardhat) +- [Discord](https://discord.com/invite/TETZs2KK4k) + +**thirdweb – _Könnyű telepítés bármely szerződés esetében bármelyik EVM-kompatibilis láncra egyetlen parancssorral_** + +- [Dokumentáció](https://portal.thirdweb.com/deploy/) + +**Crossmint _– Vállalati szintű web3 fejlesztési platform okosszerződések telepítéséhez, hitelkártyás és láncok közötti fizetések lehetővé tételéhez, valamint API-ok használatára NFT-k létrehozása, terjesztése, értékesítése, tárolása és szerkesztése érdekében._** + +- [crossmint.com](https://www.crossmint.com) +- [Dokumentáció](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) +- [Blog](https://blog.crossmint.com) + +## Kapcsolódó útmutatók {#related-tutorials} + +- [Az első okosszerződés telepítése](/developers/tutorials/deploying-your-first-smart-contract/) _– Bevezetés az első okosszerződés telepítésébe egy Ethereum-teszthálózaton._ +- [Hello World | okosszerződés-útmutató](/developers/tutorials/hello-world-smart-contract/) _– Egyszerűen követhető útmutató egy alap okosszerződés létrehozásához és telepítéséhez az Ethereumon._ +- [Más szerződésekkel való interakció a Solidity által](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– Hogyan telepítsen okosszerződést egy létező szerződésből és kapcsolódjon azzal._ +- [Hogyan csökkenthető a szerződés mérete](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– Hogyan csökkentheti a szerződés méretét, hogy a határ alatt legyen és gázt takarítson meg_ + +## További olvasnivaló {#further-reading} + +- [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) – _OpenZeppelin_ +- [Telepítse szerződéseit a Hardhat segítségével](https://hardhat.org/guides/deploying.html) – _Nomic Labs_ + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ + +## Kapcsolódó témák {#related-topics} + +- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) +- [Ethereum-csomópont futtatása](/developers/docs/nodes-and-clients/run-a-node/) +- [Csomópont, mint szolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service) diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" new file mode 100644 index 00000000000..dfcac198f89 --- /dev/null +++ "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" @@ -0,0 +1,112 @@ +--- +title: Bevezetés az okosszerződésekbe +description: Áttekintés az okosszerződésekről, kiemelve az egyedi jellemzőiket és korlátaikat. +lang: hu +--- + +## Mi az az okosszerződés? {#what-is-a-smart-contract} + +Az „okosszerződés” egy program, mely az Ethereum blokkláncon fut. Kód (a függvényei) és adat (az állapota/státusza) gyűjteménye, mely egy bizonyos címen létezik az Ethereum blokkláncon. + +Az okosszerződés egyfajta [Ethereum-számla](/developers/docs/accounts/). Ennélfogva egyenlegük van és tranzakciók irányulhatnak feléjük. Azonban nem egy felhasználó kezeli őket, ehelyett telepítve vannak a hálózatra, és a programjuk szerint futnak. A felhasználói számlák interakcióba léphetnek az okosszerződésekkel tranzakciók indításával, melyek egy függvényt hajtanak végre az okosszerződésen. Az okosszerződések szabályokat fektethetnek le, mint egy rendes szerződés, és automatikusan betartatják azokat a kód által. Az okosszerződéseket nem lehet törölni, és a velük való interakció visszafordíthatatlan. + +## Előfeltételek {#prerequisites} + +Ha Ön most ismerkedik a témával vagy egy kevésbé technikai bevezetést keres, akkor tekintse meg a [bevezetés az okosszerződésekbe](/smart-contracts/) című cikket. + +Olvassa el a [számlákról](/developers/docs/accounts/), [tranzakciókról](/developers/docs/transactions/) és az [Ethereum virtuális gépről szóló cikkeket](/developers/docs/evm/) mielőtt belevetné magát az okosszerződések világába. + +## Egy digitális ételautomata {#a-digital-vending-machine} + +Talán a legjobb metafora az okosszerződésre egy ételautomata, ahogy azt [Nick Szabo](https://unenumerated.blogspot.com/) bemutatta. A megfelelő bemenetekkel egy bizonyos kimenet jön létre. + +Ahhoz, hogy megkapja az ételt az automatából: + +``` +pénz + nasi választás = kiadott nasi +``` + +Ez a logika be van programozva az ételautomatába. + +Az okosszerződésbe logika van programozva, akár egy ételautomatába. Egy egyszerű példa, hogyan nézne ki ez az ételautomata, ha egy okosszerződés lenne Solidity nyelven: + +```solidity +pragma solidity 0.8.7; + +contract VendingMachine { + + // A szerződés állapotváltozóinak deklarálása + address public owner; + mapping (address => uint) public cupcakeBalances; + + // Amikor a 'VendingMachine' szerződést telepítik: + // 1. beállítja a telepítő címet a szerződés tulajdonosaként + // 2. set the deployed smart contract's cupcake balance to 100 + constructor() { + owner = msg.sender; + cupcakeBalances[address(this)] = 100; + } + + // Allow the owner to increase the smart contract's cupcake balance + function refill(uint amount) public { + require(msg.sender == owner, "Only the owner can refill."); + cupcakeBalances[address(this)] += amount; + } + + // Allow anyone to purchase cupcakes + function purchase(uint amount) public payable { + require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake"); + require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase"); + cupcakeBalances[address(this)] -= amount; + cupcakeBalances[msg.sender] += amount; + } +} +``` + +Mint ahogy az ételautomaták szükségtelenné teszik az árusító alkalmazottat, az okosszerződések is számos iparágban leválthatják a közvetítőket. + +## Nem engedélyköteles {#permissionless} + +Bárki írhat okosszerződést és telepítheti azt a hálózatra. A szerződés telepítéséhez elég csak megtanulnia egy [okosszerződésnyelven](/developers/docs/smart-contracts/languages/) programozni, illetve a szükséges ETH-val kell rendelkeznie. Az okosszerződés telepítése lényegében egy tranzakció, így ugyanúgy ki kell fizetnie a [gázt](/developers/docs/gas/), mint egy egyszerű ETH-átutalás esetében. Ugyanakkor a szerződéstelepítés gázköltsége magasabb. + +Az Ethereum fejlesztőbarát okosszerződésnyelvekkel rendelkezik: + +- Solidity +- Vyper + +[Többet a nyelvekről](/developers/docs/smart-contracts/languages/) + +Azonban be kell őket fordítani telepítés előtt, hogy az Ethereum virtuális gép értelmezni és tárolni tudja majd a szerződést. [Többet a befordításról](/developers/docs/smart-contracts/compiling/) + +## Összeilleszthetőség {#composability} + +Az okosszerződések nyilvánosak az Ethereumon, így nyílt API-ként is tekinthetünk rájuk. Ez azt jelenti, hogy meghívhat más okosszerződéseket az Ön szerződésében, hogy nagymértékben kiterjeszthesse a lehetőségeket. A szerződések még más szerződéseket is tudnak telepíteni. + +Tudjon meg többet az [okosszerződések összeilleszthetőségről](/developers/docs/smart-contracts/composability/). + +## Korlátok {#limitations} + +Az okosszerződések önmagukban nem képesek információt lekérni a „külvilági” eseményekről, mivel nem tudnak adatot szerezni a láncon kívüli forrásokból. Tehát nem tudnak válaszolni a világ történéseire. Ez a tervezett logikájuk. A külső információkra való támaszkodás veszélyeztetheti a biztonság és a decentralizáció szempontjából fontos konszenzust. + +Ugyanakkor fontos a blokklánchoz tartozó alkalmazásoknak, hogy láncon kívüli adatokat használhassanak. A megoldás az [orákulum](/developers/docs/oracles/), amely egy olyan eszköz, ami láncon kívüli adatokat kap fel és tesz elérhetővé az okosszerződések számára. + +Az okosszerződések másik korlátja a maximális méret. Legfeljebb 24 KB méretű lehet egy okosszerződés, különben nem lesz elegendő gáz a működéséhez. Ezt meg lehet kerülni a [gyémántminta](https://eips.ethereum.org/EIPS/eip-2535) használatával. + +## Több aláírásos szerződések {#multisig} + +A több aláírásos szerződések olyan okosszerződésszámlák, amelyeknek több érvényes aláírás kell, hogy egy tranzakciót végrehajtsanak. Ez nagyon hasznos az egyetlen meghibásodási pont elkerülésére az olyan szerződéseknél, amelyek jelentős mennyiségű ethert vagy más tokent tartanak. A több aláírásos szerződések megosztják a szerződés­-végrehajtási és kulcskezelési felelősséget több fél között, és így nem kell attól tartani, hogy az egyetlen privát kulcs elveszik, és így a pénzeszközök elérhetetlenné válnak. Ebből az okból kifolyólag a több aláírásos szerződéseket egyszerű DAO irányításra is lehet használni. A több aláírásos szerződés N aláírást igényel M lehetséges elfogadható aláírásból (ahol N ≤ M, és M > 1) ahhoz, hogy végrehajtsa a tranzakciót. Gyakran használják a következő kombinációkat: `N = 3, M = 5` és `N = 4, M = 7`. A 4/7 több aláírásos szerződés négyet igényel a hét lehetséges érvényes aláírásból. Tehát a pénzeszközökhöz akkor is hozzáférnek, ha három aláírás elveszik. Ebben az esetben a kulcsokbirtokosok többségének egyet kell értenie és alá kell írnia ahhoz, hogy a szerződés végrehajtható legyen. + +## Okosszerződés-erőforrások {#smart-contract-resources} + +**OpenZeppelin Contracts –** **_Könyvtár a biztonságos okosszerződésfejlesztéshez._** + +- [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) +- [Közösségi Fórum](https://forum.openzeppelin.com/c/general/16) + +## További olvasnivaló {#further-reading} + +- [Coinbase: Mi az az okosszerződés?](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) +- [Chainlink: Mi az az okosszerződés?](https://chain.link/education/smart-contracts) +- [Video: Egyszerű magyarázat: Okosszerződések](https://youtu.be/ZE2HxTmxfrI) +- [Cyfrin Updraft: Web3 tanulási és ellenőrzési platform](https://updraft.cyfrin.io) diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" new file mode 100644 index 00000000000..a2ab093066e --- /dev/null +++ "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" @@ -0,0 +1,326 @@ +--- +title: Okosszerződés nyelvek +description: Áttekintjük és összehasonlítjuk a két fő nyelvet, a Solidity-t és a Vypert, melyen az okosszerződések készülnek. +lang: hu +--- + +Az Ethereum egyik kiváló jellemzője, hogy az okosszerződéseket viszonylag fejlesztőbarát nyelveken lehet programozni. Ha Ön járatos a Pythonban vagy bármilyen [kerek zárójeles nyelvben](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages), akkor találhat olyan nyelvet, melynek a szintaxisa ismerős lesz. + +A két legaktívabb és leginkább karbantartott nyelv: + +- Solidity +- Vyper + +A Remix IDE egy átfogó fejlesztési környezetet nyújt a szerződések létrehozásához és teszteléséhez Solidity és Vyper nyelveken. [Próbálja ki a böngészőben elérhető Remix IDE](https://remix.ethereum.org) használatát a kódoláshoz. + +A tapasztaltabb fejlesztők kipróbálhatják a Yul nyelvet, mely egy haladó nyelv az [Ethereum virtuális gépre](/developers/docs/evm/), vagy ennek kiterjesztését, melynek neve Yul+. + +Amennyiben Ön kíváncsi típus, és szeret olyan új nyelvek tesztelésében segíteni, amelyek még komoly fejlesztés előtt állnak, akkor fedezze fel a Fe-t, egy kialakulóban lévő okosszerződésnyelvet, amely még gyerekcipőben jár. + +## Előfeltételek {#prerequisites} + +A programozási nyelvek, különösen a JavaScript vagy a Python korábbi ismerete segíthet az okosszerződés nyelvekben mutatkozó különbségek értelmezésében. Javasoljuk, hogy először értse meg az okosszerződést, mint koncepciót, mielőtt túl mélyre ásna a nyelvi összehasonlításokban. [Bevezetés az okosszerződésekbe](/developers/docs/smart-contracts/). + +## Solidity {#solidity} + +- Objektumorientált, magas szintű nyelv az okosszerződések telepítésére. +- Kerek zárójeles nyelv, amelyet a leginkább a C++ befolyásolt. +- Statikusan típusos (a változó típusa ismert az átfordítási időben). +- A következőket támogatja: + - Öröklődés (kiterjeszthet más szerződéseket). + - Könyvtárak (újrafelhasználható kódot írhat, melyet meghívhat különböző szerződésekből – mint a statikus függvényeket statikus osztályokban más objektumorientált programozási nyelveken). + - Komplex, felhasználó által definiált típusok. + +### Fontos linkek {#important-links} + +- [Dokumentáció](https://docs.soliditylang.org/en/latest/) +- [Solidity Nyelvportál](https://soliditylang.org/) +- [Solidity példák alapján](https://docs.soliditylang.org/en/latest/solidity-by-example.html) +- [GitHub](https://github.com/ethereum/solidity/) +- [Solidity Gitter Chatroom](https://gitter.im/ethereum/solidity) összekötve a [Solidity Matrix Chatroom](https://matrix.to/#/#ethereum_solidity:gitter.im)-mal +- [Puska](https://reference.auditless.com/cheatsheet) +- [Solidity Blog](https://blog.soliditylang.org/) +- [Solidity Twitter](https://twitter.com/solidity_lang) + +### Példaszerződés {#example-contract} + +```solidity +// SPDX-License-Identifier: GPL-3.0 +pragma solidity >= 0.7.0; + +contract Coin { + // A "public" kulcsszó a változókat + // elérhetővé teszi más szerződések számára + address public minter; + mapping (address => uint) public balances; + + // Az események lehetővé teszik, hogy a kliensek + // általad deklarált szerződés változásokra reagáljanak + event Sent(address from, address to, uint amount); + + // A konstruktor csak a szerződés létrehozásakor + // fut le + constructor() { + minter = msg.sender; + } + + // Az újonnan létrehozott tokeneket elküldi egy címre + // Csak a szerződés létrehozó hívhatja meg + function mint(address receiver, uint amount) public { + require(msg.sender == minter); + require(amount < 1e60); + balances[receiver] += amount; + } + + // Elküld valamennyi létező tokent + // bármely hívótól egy címre + function send(address receiver, uint amount) public { + require(amount <= balances[msg.sender], "Insufficient balance."); + balances[msg.sender] -= amount; + balances[receiver] += amount; + emit Sent(msg.sender, receiver, amount); + } +} +``` + +Ez a példa azt mutathatja meg Önnek, hogyan néz ki a Solidity szerződés szintaxisa. A függvények és a változók részletesebb leírásáért [tekintse meg a dokumentációt](https://docs.soliditylang.org/en/latest/contracts.html). + +## Vyper {#vyper} + +- Pythonikus programozási nyelv +- Erősen típusos +- Kicsi és érthető fordító kód +- Hatékony bájtkód-generálás +- Szándékosan kevesebb elemmel rendelkezik, mint a Solidity, azzal a céllal, hogy a szerződések biztonságosabbak és könnyebben auditálhatóak legyenek. A Vyper nem támogatja a következőket: + - Módosítókat (modifier) + - Öröklést + - Soron belüli assembly + - Függvénytúlterhelés + - Operátortúlterhelés + - Rekurzív hívás + - Végtelen hosszú ciklusok + - Bináris fix pontok + +További információkért [tekintse meg a Vyper magyarázatát](https://vyper.readthedocs.io/en/latest/index.html). + +### Fontos linkek {#important-links-1} + +- [Dokumentáció](https://vyper.readthedocs.io) +- [Vyper példa alapján](https://vyper.readthedocs.io/en/latest/vyper-by-example.html) +- [Még több Vyper példák alapján](https://vyper-by-example.org/) +- [GitHub](https://github.com/vyperlang/vyper) +- [A Vyper-közösség Discord-csevegése](https://discord.gg/SdvKC79cJk) +- [Cheat Sheet](https://reference.auditless.com/cheatsheet) +- [Okosszerződés-fejlesztési keretrendszerek és eszközök Vyperre](/developers/docs/programming-languages/python/) +- [VyperPunk – tanulja meg a Vyper okosszerződéseket biztosítását és meghackelését](https://github.com/SupremacyTeam/VyperPunk) +- [VyperExamples – Példák a Vyper sebezhetőségére](https://www.vyperexamples.com/reentrancy) +- [Vyper Hub fejlesztéshez](https://github.com/zcor/vyper-dev) +- [Példák a Vyper legjobb okosszerződéseire](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) +- [A Vyper által gondozott kiváló források](https://github.com/spadebuilders/awesome-vyper) + +### Példa {#example} + +```python +# Nyílt Aukció + +# Aukció paraméterek +# A kedvezményezett pénzt kap a legnagyobb licitálótól +beneficiary: public(address) +auctionStart: public(uint256) +auctionEnd: public(uint256) + +# Az aukció jelenlegi állapota +highestBidder: public(address) +highestBid: public(uint256) + +# Legyen igaz a végén, bármely változást elutasít +ended: public(bool) + +# Számontartja a visszafizetett liciteket, így követni tudjuk a kiutalási mintát +pendingReturns: public(HashMap[address, uint256]) + +# Egy egyszerű aukció létrehozása `_bidding_time` +# másodpercnyi licit idővel a kedvezményezett cím +# `_beneficiary` nevében. +@external +def __init__(_beneficiary: address, _bidding_time: uint256): + self.beneficiary = _beneficiary + self.auctionStart = block.timestamp + self.auctionEnd = self.auctionStart + _bidding_time + +# Licitálás az aukción +# a tranzakcióval küldött értékkel. +# Az érték csak akkor kerül visszautalásra +# ha az aukció nincs megnyerve. +@external +@payable +def bid(): + # Ellenőrzi, hogy a licit idő véget ért-e már. + assert block.timestamp < self.auctionEnd + # Ellenőrzi, hogy elég magas-e a licit + assert msg.value > self.highestBid + # Nyomonköveti az előző legmagasabb licit visszatérítését + self.pendingReturns[self.highestBidder] += self.highestBid + # Nyomonköveti a legmagasabb licitet + self.highestBidder = msg.sender + self.highestBid = msg.value + +# Kiutalja az előzőleg visszatérített licitet. A kiutalási mintát használjuk itt, +# hogy elkerüljünk egy biztonsági rést. Ha a visszatérítés közvetlenül +# a bid() része lenne, egy ártalmas licit szerződés blokkolhatná +# ezeket a visszatérítéseket, így blokkolná a magasabb bejövő liciteket. +@external +def withdraw(): + pending_amount: uint256 = self.pendingReturns[msg.sender] + self.pendingReturns[msg.sender] = 0 + send(msg.sender, pending_amount) + +# Vége az aukciónak és elküldi a legmagasabb licitet +# a kedvezményezettnek. +@external +def endAuction(): + # It is a good guideline to structure functions that interact + # 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) + # 3. interakció más szerződésekkel + # Ha ezt a sorrendet felcseréljük, akkor más szerződés visszahívhat + # a jelenlegi szerződésbe és módosíthatja az állapotot vagy + # többszörösen elvégzett műveletet eredményezhet (ether kifizetés). + # Ha a belsőleg meghívott függvény külső szerződéssel történő + # interakciót tartalmaz, akkor azokat is külső szerződéssel történő + # interakcióként kell kezelni. + + # 1. Feltételek + # Ellenőrzi, hogy elértük-e az aukció végét + assert block.timestamp >= self.auctionEnd + # Ellenőrzi, hogy függvény meg lett-e már hívva + assert not self.ended + + # 2. Hatások + self.ended = True + + # 3. Interakció + send(self.beneficiary, self.highestBid) +``` + +Ez a példa megmutathatja Önnek, hogyan néz ki a Vyper szerződés szintaxisa. A függvények és a változók részletesebb leírásáért [tekintse meg a dokumentációt](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction). + +## Yul és Yul+ {#yul} + +Ha Önnek új az Ethereum és nem programozott okosszerződésnyelveken, akkor azt javasoljuk, hogy kezdjen először a Solidity-vel és a Vyperrel. Csak akkor kezdjen bele a Yul vagy Yul+ nyelvekbe, ha már ismeri az okosszerződésre vonatkozó biztonsági gyakorlatokat és az EVM-mel kapcsolatos munka részleteit. + +**Yul** + +- Haladó nyelv Ethereumra. +- Támogatja az [EVM-et](/developers/docs/evm) és az [Ewasm-ot](https://github.com/ewasm), amely egy Ethereummal fűszerezett WebAssembly, és amelyet a két platform közös nevezőjének terveztek. +- Jó cél a magas szintű optimizációs szinteknek, melyek az EVM és Ewasm platformokból egyaránt tudnak profitálni. + +**Yul+** + +- A Yul alacsony szintű, nagy hatékonyságú kiterjesztése. +- Eredetileg az [optimista összesítéses](/developers/docs/scaling/optimistic-rollups/) szerződésként fejlesztették ki. +- A Yul+ egy kísérleti fejlesztési javaslatként is tekinthető, melyhez új funkciók tartoznak. + +### Fontos linkek {#important-links-2} + +- [Yul Dokumentáció](https://docs.soliditylang.org/en/latest/yul.html) +- [Yul+ Dokumentáció](https://github.com/fuellabs/yulp) +- [Yul+ Játszótér](https://yulp.fuel.sh/) +- [Yul+ Bevezető poszt](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) + +### Példa szerződés {#example-contract-2} + +Az alábbi egyszerű példa egy hatványfüggvényt implementál. A `solc --strict-assembly --bin input.yul` használatával lehet befordítani. Ezt a példát az input.yul fájlnak kell tartalmaznia. + +``` +{ + function power(base, exponent) -> result + { + switch exponent + case 0 { result := 1 } + case 1 { result := base } + default + { + result := power(mul(base, base), div(exponent, 2)) + if mod(exponent, 2) { result := mul(base, result) } + } + } + let res := power(calldataload(0), calldataload(32)) + mstore(0, res) + return(0, 32) +} +``` + +Ha már nagy tapasztalatra tett szert az okosszerződésekkel kapcsolatban, akkor a teljes ERC20 implementáció Yul-ban [itt érhető el](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example). + +## Fe {#fe} + +- Statikusan típusos nyelv az Ethereum virtuális géphez (EVM). +- A Python és a Rust inspirálta. +- Lényege, hogy könnyen tanulható, még azoknak a fejlesztőknek is, akiknek új az Ethereum ökoszisztémája. +- A Fe fejlesztése még nagyon korai szakaszban tart, az alfa kiadása 2021. januárban történt. + +### Fontos linkek {#important-links-3} + +- [GitHub](https://github.com/ethereum/fe) +- [Fe bejelentés](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) +- [Fe 2021-es ütemterv](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) +- [Fe Discord-csevegés](https://discord.com/invite/ywpkAXFjZH) +- [Fe Twitter](https://twitter.com/official_fe) + +### Példa szerződés {#example-contract-3} + +Ez a példa egy egyszerű szerződés Fe nyelven telepítve. + +``` +type BookMsg = bytes[100] + +contract GuestBook: + pub guest_book: map + + event Signed: + book_msg: BookMsg + + pub def sign(book_msg: BookMsg): + self.guest_book[msg.sender] = book_msg + + emit Signed(book_msg=book_msg) + + pub def get_msg(addr: address) -> BookMsg: + return self.guest_book[addr].to_mem() + +``` + +## Hogyan válasszunk {#how-to-choose} + +Mint minden más programozási nyelvnél, itt is leginkább a megfelelő eszköz kiválasztása a megfelelő munkához, valamint a személyes preferenciák döntenek. + +Íme néhány szempont, amelyet érdemes figyelembe venni, ha még nem próbálta egyik nyelvet sem: + +### Mi a jó a Solidity-ben? {#solidity-advantages} + +- A kezdőknek sok útmutató és tanulási anyag áll rendelkezésükre. További anyagért látogasson el a [Tanulás kódolással](/developers/learning-tools/) című részhez. +- Remek fejlesztői eszközök érhetők el. +- A Solidity-nek kiterjedt a fejlesztői közössége, ami azt jelenti, hogy nagy valószínűséggel gyorsan választ kap a kérdéseire. + +### Mi a jó a Vyperben? {#vyper-advatages} + +- Nagyszerű módszer a Python fejlesztők számára az első okosszerződések megírására. +- A Vyper kevesebb funkcióval rendelkezik, így kiválóan alkalmas arra, hogy az ötleteiből gyorsan prototípust készítsen. +- A Vyper célja, hogy könnyen auditálható és az emberek számára olvasható legyen. + +### Mi a jó a Yul és a Yul+ nyelvekben? {#yul-advantages} + +- Egyszerűsített és funkcionális alacsony szintű nyelv. +- Közelebb enged a nyers EVM-hez, így Ön könnyebben tudja a szerződések gázfelhasználását optimalizálni. + +## Nyelv-összehasonlítások {#language-comparisons} + +Az alapvető szintaxis, szerződés-életciklus, interfészek, operátorok, adatszerkezetek, függvények, control flow és további szempontok alapján történő összehasonlításért olvassa el a [Puska az Auditless-től](https://reference.auditless.com/cheatsheet/) című cikket + +## További olvasnivaló {#further-reading} + +- [Solidity szerződéskönyvtár az OpenZeppelintől](https://docs.openzeppelin.com/contracts) +- [Solidity egy példa alapján](https://solidity-by-example.org) diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" new file mode 100644 index 00000000000..49dabb58139 --- /dev/null +++ "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" @@ -0,0 +1,117 @@ +--- +title: Okosszerződés könyvtárak +description: +lang: hu +--- + +Nem kell minden okosszerződést a nulláról megírni. Számos nyílt forráskódú okosszerződés könyvtár áll rendelkezésedre, amelyek újrafelhasználható építőelemeket kínálnak a projektedhez, így megkímélnek attól, hogy újra fel kelljen találni a kereket. + +## Előfeltételek {#prerequisites} + +Mielőtt belevetnéd magad az okosszerződés könyvtárakba, érdemes tisztában lenned az okosszerződések felépítésével. Irány az [okosszerződés anatómia](/developers/docs/smart-contracts/anatomy/) cikk, ha még nem olvastad el. + +## Mi van egy könyvtárban {#whats-in-a-library} + +Az okosszerződés könyvtárakban általában kétféle építőelem található: újrafelhasználható eljárások, amelyeket hozzáadhatsz a szerződéseidhez, valamint különféle szabványok megvalósítása. + +### Eljárások {#behaviors} + +Okosszerződés írás közben jó esély van rá, hogy újra és újra hasonló minták megírásán találod magad, mint például hozzárendelsz egy _admin_ címet védett operációk véghezviteléhez, vagy egy vészeseti _szünet_ gombot adsz hozzá egy váratlan esemény miatt. + +Az okosszerződéses könyvtárak általában ezeknek a viselkedéseknek az újrafelhasználható megvalósítását biztosítják [könyvtárakon](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) vagy [öröklésen keresztül](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) Solidity-ben. + +Példaként az alábbiakban bemutatjuk az [`Ownable` szerződés](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) egyszerűsített verzióját az [OpenZeppelin Szerződés könyvtárból](https://github.com/OpenZeppelin/openzeppelin-contracts), mely egy címet jelöl ki tulajdonosként a szerződésben, és egy módosítóval lekorlátozza az adott metódus hozzáférését az adott tulajdonosra. + +```solidity +contract Ownable { + address public owner; + + constructor() internal { + owner = msg.sender; + } + + modifier onlyOwner() { + require(owner == msg.sender, "Ownable: caller is not the owner"); + _; + } +} +``` + +Egy ehhez hasonló építőelem használatához a szerződésedben, először be kell importálnod, majd kiterjesztened belőle a szerződéseidet. Ez lehetővé teszi az `Ownable` szerződés által biztosított módosító használatát, hogy bebiztosítsd a saját függvényeidet. + +```solidity +import ".../Ownable.sol"; // Az importált könyvtár útvonala + +contract MyContract is Ownable { + // Az alábbi függvényt csak a tulajdonos hívhatja meg + function secured() onlyOwner public { + msg.sender.transfer(1 ether); + } +} +``` + +Egy másik népszerű példa a [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) vagy a [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html). Ezek olyan könyvtárak (szemben az alapszerződésekkel), amelyek számtani függvényeket biztosítanak túlcsordulás-ellenőrzésekkel, amelyeket a nyelv nem biztosít. Jó gyakorlat ezeknek a könyvtáraknak az alkalmazása a natív számtani műveletek helyett, hogy megvédd a szerződésed a túlcsordulástól, amelynek katasztrofális következményei lehetnek! + +### Szabványok {#standards} + +Hogy elősegítsük az [összeilleszthetőséget és az interoperabilitást](/developers/docs/smart-contracts/composability/), az Ethereum közösség számos szabványt vezetett be **ERC-k** formájában. Többet olvashatsz róluk a [szabványok](/developers/docs/standards/) részben. + +Amikor egy ERC-t szeretne betenni a szerződésbe, célszerű sztenderd megvalósításokat keresni ahelyett, hogy megpróbálná a sajátját bevezetni. Számos okosszerződés könyvtár tartalmazza a legnépszerűbb ERC-k megvalósításait. Például a mindenütt jelen levő [ERC20 felcserélhető tokenszabvány](/developers/tutorials/understand-the-erc-20-token-smart-contract/) megtalálható a [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token/) és [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20) platformon. Ezenkívül, egyes ERC-k kanonikus megvalósításokat is biztosítanak az ERC részeként. + +Érdemes megemlíteni, hogy egyes ERC-k nem önállóak, hanem kiegészítenek más ERC-ket. Például az [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) kiterjeszti az ERC20-as szabványt a használhatóság javítása érdekében. + +## Hogyan lehet könyvtárt hozzáadni {#how-to} + +Mindig nézd át a könyvtár dokumentációját, amit használsz a projektedben specifikus instrukciókért arról, hogyan kell használni. Számos Solidity szerződés könyvtár az `npm` használatával van csomagolva, így elég csak `npm install` módon telepíteni őket. A legtöbb szerződés [fordító](/developers/docs/smart-contracts/compiling/) eszköz végig nézi a `node_modules` mappát okosszerződés könyvtárak után kutatva, így megteheted a következőt: + +```solidity +// Ez betölti az @openzeppelin/contracts könyvtárat a node_modules könyvtárból +import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; + +contract MyNFT is ERC721 { + constructor() ERC721("MyNFT", "MNFT") public { } +} +``` + +Az általad használt módszertől függetlenül, ha könyvtárat importálsz be, mindig ellenőrizd le a [nyelv](/developers/docs/smart-contracts/languages/) verziót. Például nem használhatsz könyvtárat a Solidity 0.6-hoz, ha a szerződéseidet a Solidity 0.5-ben írod. + +## Mikor használjuk {#when-to-use} + +Egy okosszerződés könyvtár használatának számos előnye van. Először is, időt takarít meg azzal, hogy használatra kész építőelemeket biztosít, amelyeket beépíthetsz a rendszeredbe, ahelyett, hogy saját magadnak kellene leprogramozni őket. + +A biztonság is egy fontos pozitívum. A nyílt forráskódú okosszerződés könyvtárakat gyakran alaposan megvizsgálják. Tekintettel arra, hogy sok projekt függ tőlük, a közösségnek erős ösztönzője van arra, hogy folyamatosan felülvizsgálja őket. Sokkal gyakrabban lehet hibákat találni az alkalmazáskódban, mint az újrafelhasználható szerződés könyvtárakban. Némely könyvtár [külső auditnak](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) veti alá magát magasabb fokú biztonságért. + +Az okosszerződés könyvtárak használata azonban azt a kockázatot hordozza magával, hogy számodra ismeretlen kódot veszel fel a projektbe. Csábító egy szerződést importálni és közvetlenül beilleszteni a projektbe, de anélkül, hogy megértenéd, hogy ez a szerződés mit csinál pontosan, véletlenül bevihetsz egy hibát a rendszerbe egy váratlan viselkedésből kifolyólag. Mindig feltétlenül olvasd el az importált kód dokumentációját, majd nézd át magát a kódot, mielőtt a projekt részévé tennéd! + +Végül, amikor eldöntöd, hogy felveszel-e egy könyvtárat, vedd figyelembe annak általános használatát. Egy széles körben elfogadott szerződés előnye, hogy nagyobb a közössége, és többen tudnak foglalkozni a problémákkal. A biztonság legyen az elsődleges szempont okosszerződés fejlesztéskor! + +## Kapcsolódó eszközök {#related-tools} + +**OpenZeppelin Contracts -** **_A legnépszerűbb könyvtár biztonságos okosszerződés fejlesztéshez._** + +- [Dokumentáció](https://docs.openzeppelin.com/contracts/) +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) +- [Közösségi Fórum](https://forum.openzeppelin.com/c/general/16) + +**DappSys -** **_Biztonságos, egyszerű, flexibilis okosszerződés építőelemek._** + +- [Dokumentáció](https://dappsys.readthedocs.io/) +- [GitHub](https://github.com/dapphub/dappsys) + +**HQ20 -** **_Egy Solidity projekt szerződésekkel, könyvtárakkal és példákkal, melyek segítenek teljesértékű alkalmazásokat fejleszteni a külvilágnak_** + +- [GitHub](https://github.com/HQ20/contracts) + +**thirdweb Solidity SDK –** **_Olyan eszközöket biztosít, melyekkel hatékonyan lehet személyre szabott okosszerződéseket létrehozni_** + +- [Dokumentáció](https://portal.thirdweb.com/solidity/) +- [GitHub](https://github.com/thirdweb-dev/contracts) + +## Kapcsolódó útmutatók {#related-tutorials} + +- [Security considerations for Ethereum developers](/developers/docs/smart-contracts/security/) _– Egy biztonsági megfontolásokról szóló útmutató okosszerződés-fejlesztéshez könyvtárhasználattal._ +- [Az ERC-20 tokenes okosszerződés megértése](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _-Útmutató az ERC20 szabványról több könyvtáron keresztül._ + +## További olvasnivaló {#further-reading} + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" new file mode 100644 index 00000000000..5e0e193f707 --- /dev/null +++ "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" @@ -0,0 +1,580 @@ +--- +title: Okosszerződés biztonság +description: Útmutató a biztonságos Ethereum-okosszerződések építéséhez +lang: hu +--- + +Az okosszerződések rendkívüli módon rugalmasak és képesek nagy mennyiségű értéket és adatot irányítani, miközben egy megváltoztathatatlan logika alapján, a blokkláncra telepített kód szerint futnak. Ezáltal létrejött a bizalmat nem igénylő és decentralizált alkalmazások élénk ökoszisztémája, mely számos előnyt kínál a hagyományos rendszerekkel szemben. Emellett lehetőséget is jelentenek a támadók számára, akik abból akarnak nyereséget szerezni, hogy kihasználják az okosszerződések gyenge pontjait. + +A nyilvános blokkláncok, mint az Ethereum, tovább bonyolítják az okosszerződések biztosításának problémáját. A telepített szerződéskód _általában_ nem módosítható, hogy ezzel a biztonsági kockázatokat elkerüljék, eközben az okosszerződésekből ellopott eszközöket rendkívül nehéz lekövetni és a legtöbb esetben visszaszerezhetetlenek a megváltoztathatatlanság miatt. + +Bár a számok változnak, de úgy becsülik, hogy a biztonsági hibák miatt az okosszerződésből ellopott vagy onnan elvesztett értékek teljes összege könnyen meghaladhatja az 1 milliárd dollárt is. Ez magába foglal olyan nagy horderejű incidenseket is, mint amilyen a [DAO-hackelés volt](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (3,6 millió ETH-t loptak, ami meghaladja az 1 milliárd dollárt mai áron), [Parity több aláírásos tárca hackelését](https://www.coindesk.com/30-million-ether-reported-stolen-parity-wallet-breach) (30 millió USD-t veszett el), és a [Parity befagyasztott tárcaproblémát](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (300 millió USD-nyi ETH örökre elérhetetlenné vált). + +Ezek az esetek kötelezővé teszik a fejlesztők számára, hogy folyamatosan azon dolgozzanak, hogy az okosszerződések biztonságosak, robusztusak és ellenállók legyenek. Az okosszerződésbiztonság komoly téma, melyet minden fejlesztőnek a maga érdekében meg kell ismerni. Ez az útmutató lefedi azokat a biztonsági megfontolásokat, amelyek az Ethereum-fejlesztőknek fontosak, és forrásokat tár fel az okosszerződésbiztonság továbbfejlesztésére. + +## Előfeltételek {#prerequisites} + +Tisztában kell lennie az [okosszerződés-fejlesztés alapjaival](/developers/docs/smart-contracts/), mielőtt a biztonsági kérdésekkel foglalkozna. + +## Iránymutatások a biztonságos Ethereum-okosszerződések építéséhez {#smart-contract-security-guidelines} + +### 1. Tervezzen megfelelő hozzáférés-szabályozást {#design-proper-access-controls} + +Az okosszerződésekben a `public` (publikus) vagy `external` (külső) jelölésű függvényeket bármelyik külső tulajdonú számla (EOA) vagy szerződésszámla meghívhatja. A függvényeket szükséges nyilvánossá tenni, ha Ön azt akarja, hogy mások interakcióba lépjenek a szerződésével. A `private` (privát) jelölésű függvényeket csak az okosszerződésen belüli függvények hívhatják meg, külső számlák nem. Problémás lehet az összes hálózati résztvevőnek hozzáférést adni bizonyos szerződésfüggvényekhez, főleg ha így bárki végrehajthat fontos műveleteket (pl. új tokenek kibocsátása). + +Ahhoz, hogy megakadályozzuk az okosszerződés függvényeinek nem hitelesített használatát, biztonságos hozzáférés-szabályozásra van szükség. A hozzáférés-szabályozás mechanizmusai az okosszerződés bizonyos függvényeinek használatát a jóváhagyott entitások csoportjára, például a szerződés kezeléséért felelős számlákra korlátozzák. A **tulajdonosi minta** és a **szerepalapú irányítás** két hasznos minta az okosszerződésben beállítható hozzáférés-szabályozásra: + +#### Tulajdonosi minta (ownable pattern) {#ownable-pattern} + +A tulajdonosi mintában beállítható egy cím, mint a szerződés „tulajdonosa” a szerződés létrehozása folyamán. A védett függvényekhez hozzárendelnek egy `OnlyOwner`-módosítót, így a szerződés azonosítani fogja az identitását a hívást végző címnek, mielőtt végrehajtaná a függvényt. A védett függvények meghívását csak akkor engedi, ha az a szerződés tulajdonosának címéről érkezik, különben elveti azt, megakadályozva az akaratlan hozzáférést. + +#### Szerepalapú hozzáférés-szabályozás {#role-based-access-control} + +Ha az okosszerződésben egyetlen címet regisztrálnak, mint `Owner` (tulajdonos), az a centralizáció kockázatát hordozza és felmerül az egyetlen meghibásodási pont lehetősége. Ha a tulajdonos számlakulcsa nyilvánossá válik, akkor a támadók hozzáférhetnek ehhez a tulajdonolt szerződéshez. Emiatt jobb opció lehet a szerepalapú hozzáférés-szabályozás mintája, ahol több adminisztratív számla van. + +A szerepalapú hozzáférés-szabályozásban a fontos függvényekhez való hozzáférést elosztják a megbízott résztvevők között. Például az egyik számla felel a tokenek kibocsátásáért, miközben egy másik számla frissítéseket végez vagy megállítja a szerződést. A decentralizált hozzáférés-szabályozás ily módon kivédi az egyetlen meghibásodási pont lehetőségét és csökkenti a felhasználók részéről igényelt bizalmat. + +##### Több aláírásos tárca használata + +A biztonságos hozzáférés-szabályozásra egy másik megközelítés a [több aláírásos számla](/developers/docs/smart-contracts/#multisig) használata, ami a szerződést kezeli. Az általános külső tulajdonú számlához (EOA) képest a több aláírásos számlákat több entitás birtokolja, és a tranzakciók végrehajtásához egy adott számú aláírásra van szükség, például 5-ből 3-ra. + +Ennek használata egy újabb biztonsági réteget vezet be, mivel a szerződésen végrehajtandó akciókba több félnek is bele kell egyeznie. Ez különösen hasznos, ha a tulajdonosi mintát (ownable pattern) kell használni, mert még nehezebb a támadó vagy egy rosszhiszemű belső fél számára, hogy rossz célokra használja fel a fontos szerződésfüggvényeket. + +### 2. Használja a require(), assert() és revert() parancsokat, hogy óvja a szerződés működését {#use-require-assert-revert} + +Amint az okosszerződés telepítésre kerül a blokkláncon, bárki meg tudja hívni a benne lévő publikus függvényeket. Mivel nem lehet tudni előre, hogy a külső tulajdonú számlák hogyan fognak interakciókat folytatni a szerződéssel, ezért ideális esetben belső óvintézkedéseket kell tenni a problémás működésekkel kapcsolatban a telepítés előtt. Az okosszerződésben elő lehet írni a megfelelő viselkedést a `require()`, `assert()` és `revert()` parancsokkal, hogy ha bizonyos feltételek nem teljesülnek, akkor leálljon és visszaforgassa a változásokat. + +**`require()`**: a `require` (szükséges) parancsot a függvények elején kell meghatározni, és biztosítja, hogy a megadott feltételek teljesülnek, mielőtt a függvény végrehajtásra kerül. A `require` parancs révén validálni lehet a felhasználó által adott adatokat, ellenőrizhetők az állapotváltozók, vagy hitelesíteni lehet a meghívó számla identitását, mielőtt a függvény elindulna. + +**`assert()`**: az `assert()` (állítás) parancsot a belső hibák felderítésére használják, illetve a kódban lévő „konstansok” megsértését ellenőrzik ezáltal. A konstans egy logikai állítás a szerződés státuszáról, amelynek teljesülnie kell minden függvénymeghívás esetén. Például egy tokenszerződés maximális teljes kínálata vagy egyenlege. Az `assert()` használata biztosítja, hogy a szerződés nem kerül sebezhető státuszba, és ha mégis, akkor az állapotváltozók visszaállnak a korábbi értékekre. + +**`revert()`**: a `revert()` (visszatér) kódot egy if-else parancsban használhatjuk, ami egy kivételt ad, ha a szükséges feltételek nem teljesülnek. Az alábbi példaszerződés a `revert()` kódot arra használja, hogy védje a függvények végrehajtását: + +``` +pragma solidity ^0.8.4; + +contract VendingMachine { + address owner; + error Unauthorized(); + function buy(uint amount) public payable { + if (amount > msg.value / 2 ether) + revert("Not enough Ether provided."); + // Perform the purchase. + } + function withdraw() public { + if (msg.sender != owner) + revert Unauthorized(); + + payable(msg.sender).transfer(address(this).balance); + } +} +``` + +### 3. Tesztelje az okosszerződéseket és ellenőrizze a kód helyességét {#test-smart-contracts-and-verify-code-correctness} + +Az [Ethereum virtuális gépen](/developers/docs/evm/) érvényes kódváltoztathatatlanság miatt az okosszerződéseknél jelentős minőség-ellenőrzésre van szükség a fejlesztési időszakban. Tesztelje szerződését kiterjedt módon, és figyelje meg, hogy kap-e váratlan eredményeket, így fejlesztheti a biztonságot és megvédheti a felhasználókat hosszú távon is. + +Ennek megszokott módja, hogy kicsi egységteszteket ír tesztadattal, melyet a szerződés a felhasználóktól kapna. Az [egységtesztelés](/developers/docs/smart-contracts/testing/#unit-testing) arra jó, hogy bizonyos függvények működését kipróbálja, és így biztosítja, hogy az okosszerződés az elvárt módon működik. + +Sajnos az egységtesztelés minimálisan növeli az okosszerződés biztonságát, ha azt izolációban használják. Az egységteszt megmutathatja, hogy egy függvény megfelelően működik-e a tesztadatokra, de csak annyira hatásos, amennyire jó tesztet írnak hozzá. Nehéz beazonosítani a kimaradt eseteket és sebezhetőségeket, amelyek kompromittálhatják az okosszerződés biztonságát. + +Jobb megközelítés az egységtesztelés tulajdonságalapú teszteléssel (property-based testing) való kombinálása, amely [statikus és dinamikus elemzést](/developers/docs/smart-contracts/testing/#static-dynamic-analysis) használ. A statikus elemzés olyan alacsony szintű reprezentációkon alapul, mint amilyen a [kontrollfolyamat-grafikon](https://en.wikipedia.org/wiki/Control-flow_graph) és az [absztrakt szintaxisfák](https://deepsource.io/glossary/ast/), hogy elemezze az elérhető programstátuszokat és végrehajtási utakat. A dinamikus elemzési technikák, mint az [okosszerződés fuzzing](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry), a szerződéskódot véletlenszerű értékekkel hajtják végre, hogy feltárják azokat a működéseket, amelyek nem felelnek meg a biztonsági tulajdonságoknak. + +A [formális ellenőrzés (formal verification)](/developers/docs/smart-contracts/formal-verification) egy másik technika az okosszerződések biztonsági tulajdonságainak igazolására. A megszokott teszteléshez képest a formális ellenőrzés képes egyértelműen bizonyítani, hogy nincsenek hibák az okosszerződésben. Ezt úgy éri el, hogy egy formális specifikációt hoz létre, amely a kívánt biztonsági tulajdonságokat rögzíti, majd bizonyítja, hogy a szerződések formális modellje megfelel ennek a specifikációnak. + +### 4. Kérjen egy független átvizsgálást a kódjára {#get-independent-code-reviews} + +Miután tesztelte a szerződését, kérjen meg másokat is, hogy ellenőrizzék le a kódot a lehetséges biztonsági problémák szempontjából. A tesztelés nem tárja fel az okosszerződés minden hibáját, de egy független vizsgálat megnöveli annak valószínűségét, hogy kiderülnek a sebezhető pontok. + +#### Auditok {#audits} + +Az okosszerződés auditálása az egyik módja a független kódvizsgálatnak. Az auditorok fontos szerepet játszanak abban, hogy az okosszerződések biztonságosak legyenek és ne legyenek bennük minőségi és tervezési hibák. + +Mindazonáltal fontos megjegyezni, hogy az audit nem old meg minden problémát. Az okosszerződés-auditok nem tárnak fel minden egyes hibát, és a terv általában egy második körös ellenőrzés, hogy azokat a problémákat kiszúrja, ami a fejlesztőknek nem vált világossá a fejlesztés és tesztelés során. Kövesse a bevált gyakorlatokat az auditorokkal való munka kapcsán, mint amilyen a kód megfelelő dokumentálása és a sorokhoz kapcsolt kommentek, amelyek révén az okosszerződés-auditból a lehető legtöbb előnyt ki lehet hozni. + +- [Okosszerződés auditáláshoz tippek és trükkök](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_ +- [Hozza ki a legtöbbet az auditból](https://inference.ag/blog/2023-08-14-tips/) - _Inference_ + +#### Hibavadászatok {#bug-bounties} + +Egy másik megoldás lehet a hibavadászat-program felállítása, amellyel külsődleges kódvizsgálatot lehet végezni. A hibavadászat pénzügyi jutalommal jár olyan egyéneknek (általában fehérkalapos hackereknek), akik sebezhető pontokat fedeznek fel az alkalmazásban. + +Ez a jutalom a hibavadászatért, ha megfelelően használják, kellő motivációt jelenthet a hackerközösség bizonyos tagjai számára, hogy átnézzék az Ön kódját is kritikus hibákat keresve. Valós példa lehet a „végtelen mennyiségű pénz hiba”, ami egy támadónak lehetővé teszi, hogy határtalan mennyiségű ethert hozzon létre az [Optimism-mal](https://www.optimism.io/), egy [második blokkláncréteg (L2)](/layer-2/) protokollal az Ethereumon. Szerencsére egy fehérkalapos hacker [felfedezte a hibát](https://www.saurik.com/optimism.html) és értesítette a csapatot, [amelyet jelentős pénzösszeggel jutalmaztak](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/). + +Hasznos stratégia lehet, ha a kifizetés összegét arányosan kezelik a hiba által veszélybe kerülő pénzeszközök értékével. Ezt „[skálázódó hibavadászatnak](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)” is nevezhetjük, ami pénzügyi motivációt ad az egyéneknek, hogy inkább feltárják a gyenge pontokat és ne kihasználják azokat. + +### 5. Kövesse a bevált gyakorlatokat az okosszerződésfejlesztés során {#follow-smart-contract-development-best-practices} + +Az auditok és hibavadászatok nem csökkentik az Ön felelősségét, hogy jó minőségű kódot írjon. A megfelelő okosszerződés-biztonság azzal kezdődik, hogy megfelelő tervezési és fejlesztési folyamatokat követ: + +- Tárolja az összes kódot egy verziókövető rendszerben, mint amilyen a git + +- Minden kódmódosítást pull requesteken (változtatási kérelem) keresztül végezzen + +- A pull requesteknek legalább egy független ellenőrzője legyen – ha Ön egyedül dolgozik egy projekten, akkor fontolja meg, hogy más fejlesztőkkel összefogva elvégzik egymás számára a kódellenőrzéseket + +- Használjon [fejlesztői környezetet](/developers/docs/frameworks/) az okosszerződések tesztelésére, átfordítására és telepítésére + +- Futtassa le a kódját olyan alapvető kódelemző eszközökön, mint a [Cyfrin Aaderyn](https://github.com/Cyfrin/aderyn), Mythril és Slither. Ideális esetben ezt minden egyes pullrequest-beolvasztás előtt meg kell tenni, majd összehasonlítani az eredmények különbségeit + +- Biztosítsa, hogy a kód hibák nélkül kerül átfordításra, és a Solidity átfordító nem ad figyelmeztetéseket + +- Dokumentálja megfelelően a kódot (a [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html) használatában), és magyarázza el a részleteket a szerződés architektúrájáról egyszerű nyelven. Ezáltal könnyebb lesz másoknak auditálni és ellenőrizni a kódot. + +### 6. Vezessen be komoly leállást követő helyreállítási tervet {#implement-disaster-recovery-plans} + +A biztonságos hozzáférés-szabályozási terv, a függvénymódosítók bevezetése és más javaslatok fejlesztik az okosszerződés biztonságát, de nem zárhatják ki a lehetőségét egy ártó szándékú támadásnak. A biztonságos okosszerződés építése megkívánja azt is, hogy „felkészüljön a hibára”, és kidolgozzon egy tervet, amely alapján hatásosan tud reagálni egy támadásra. Egy megfelelő hibát vagy leállást követő helyreállítási terv (disaster recovery plan) a következő komponensek néhány vagy összes elemét tartalmazza: + +#### Szerződésfrissítések {#contract-upgrades} + +Miközben az Ethereum-okosszerződések alapvetően megváltozhatatlanok, mégis el lehet érni egy bizonyos fokú változtathatóságot a frissítési minták alkalmazásával. A szerződések frissítése elkerülhetetlen ha egy kritikus hiba miatt a régi szerződés használhatatlan lesz, és az új logika bevezetése a legjobb megoldás. + +A szerződésfrissítési mechanizmusok másképp működnek, de a „proxyminta” az egyik legnépszerűbb megközelítés az okosszerződések frissítésére. A [proxyminta](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) az alkalmazás státuszát és logikáját _két_ szerződésre választja szét. Az első szerződés (a proxyszerződés) tárolja az állapotváltozókat (például a felhasználó egyenlegét), miközben a második szerződés (a logikaszerződés) tartalmazza a szerződés függvényeinek végrehajtási kódját. + +A számlák a proxyszerződéssel kerülnek interakcióba, amely elküldi a függvénymeghívásokat a logikaszerződésbe a [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries) kódot, egy alacsony szintű meghívást használva. A `delegatecall()` a megszokott üzenethíváshoz képest biztosítja, hogy a kód a logikaszerződés címén lefut a meghívó szerződés kontextusában. Tehát a logikaszerződés mindig a proxy tárhelyére ír (nem a sajátjába) és megőrzi a `msg.sender` és `msg.value` eredeti értékeit. + +Ahhoz, hogy hívást lehessen delegálni a logikai szerződésnek, a címét el kell tárolni a proxyszerződés tárhelyén. Tehát a szerződés logikáját úgy lehet frissíteni, hogy egy új logikai szerződést kell telepíteni és eltárolni az új címet a proxyszerződésben. Mivel az ezt követő hívások a proxyszerződés felől automatikusan az új logikaszerződéshez kerülnek átirányításra, a kód változtatása nélkül végülis „frissítésre” kerül a szerződés. + +[Bővebben a szerződések frissítéséről](/developers/docs/smart-contracts/upgrading/). + +#### Vészleállítások {#emergency-stops} + +Ahogy már említettük, sem a kiterjedt audit, sem a tesztelés nem képes felfedezni az okosszerződés összes hibáját. Ha a telepítés után sebezhető pont jelenik meg a kódjában, akkor azt nem lehet kijavítani, mert a szerződés címén futó kód megváltoztathatatlan. Emellett a frissítési mechanizmust (például a proxymintákat) időbe telik bevezetni (gyakran több jóváhagyást is igényelnek), ami csak időt ad a támadóknak, hogy több kárt okozzanak. + +A radikális megoldás egy „vészleállítás” bevezetése, ami blokkolja azokat a hívásokat, melyek a szerződés sérülékeny függvényeire vonatkoznak. A vészleállítás általában a következő komponensekből áll: + +1. Egy globális boolean változó, mely jelzi, ha az okosszerződés leállított állapotban van vagy nem. Ezt a változót `false` értékre állítják a szerződés telepítésekor, de átvált `true` értékre, amint a szerződés leáll. + +2. Függvények, melyek a boolean-változóra hivatkoznak a végrehajtásuk során. Ezek a függvények akkor érhetők el, amikor az okosszerződés nincs leállítva, és elérhetetlenné válnak, amikor a vészleállítás megtörténik. + +3. Egy entitás, amelynek hozzáférése van a vészleállítási funkcióhoz, és a boolean változót `true` értékre állítja. Az esetleges visszaélés miatt ezt a funkciót csak egy megbízott cím hívhatja meg (például a szerződés tulajdonosa). + +Amint a szerződés aktiválja a vészleállást, bizonyos függvényeket nem lehet meghívni. Ezt úgy érik el, hogy a select függvényeket becsomagolják egy módosítóba, amely a globális változóra hivatkozik. Alább [egy példa](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) látható, amely ennek a mintának a szerződésbe való bevezetését mutatja be: + +```solidity +// This code has not been professionally audited and makes no promises about safety or correctness. Use at your own risk. + +contract EmergencyStop { + + bool isStopped = false; + + modifier stoppedInEmergency { + require(!isStopped); + _; + } + + modifier onlyWhenStopped { + require(isStopped); + _; + } + + modifier onlyAuthorized { + // Check for authorization of msg.sender here + _; + } + + function stopContract() public onlyAuthorized { + isStopped = true; + } + + function resumeContract() public onlyAuthorized { + isStopped = false; + } + + function deposit() public payable stoppedInEmergency { + // Deposit logic happening here + } + + function emergencyWithdraw() public onlyWhenStopped { + // Emergency withdraw happening here + } +} +``` + +Ez a példa a vészleállás alapvető jellemzőit ismerteti: + +- Az `isStopped` egy boolean, melynek értéke `false` az elején és `true`, amikor a szerződés vészmódba lép. + +- Az `onlyWhenStopped` és `stoppedInEmergency` függvénymódosítók ellenőrzik az `isStopped` változót. A `stoppedInEmergency` azokat a függvényeket kontrollálja, amelyeknek elérhetetlennek kell maradniuk, amikor a szerződés sebezhető (például a `deposit()`). Az ezekre a függvényekre vonatkozó hívások egyszerűen visszafordulnak. + +Az `onlyWhenStopped` azokhoz a függvényekhez használandó, amelyek vészhelyzetben is elérhetők (például az `emergencyWithdraw()`). Ezek a függvények segíthetnek megoldani a helyzetet, ezért nem részei a „korlátozott függvények” listájának. + +A vészleállítási lehetőség egy hatásos hézagpótlás ahhoz, hogy a fejlesztő a komoly sebezhetőségeket kezelni tudja az okosszerződésében. Ugyanakkor a felhasználóktól több bizalmat igényel a fejlesztők felé, hogy nem használják ki ezt a funkciót önös érdekeikre. Erre lehetséges megoldást jelenthet a vészleállítás decentralizált kontrollja, mint például egy láncon belüli szavazás, időzár alkalmazása vagy egy több aláírásos tárca általi jóváhagyás. + +#### Eseményfigyelés {#event-monitoring} + +Az [események](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) lehetővé teszik az okosszerződéshez érkező hívások trekkelését és az állapotváltozók változásának felügyeletét. Bevált gyakorlatnak számít, ha az okosszerződés mindig kiad eseményt, amikor valaki egy biztonságkritikus tevékenységet végez (például kiveszi a pénzeszközöket). + +Az események naplózása és felügyelete láncon kívül betekintést enged a szerződés működésébe, valamint az ártalmas tetteket hamarabb fel lehet fedezni általuk. Így a csapat gyorsabban tud reagálni a hackelésre, és azonnal cselekedni tud, hogy a felhasználókat ez ne érintse negatívan, például leállíthatják a függvényeket vagy frissítést indíthatnak el. + +Választhat egy előre összeállított felügyeleti eszközt, amely automatikusan figyelmeztetéseket küld, amikor valaki interakcióba lép az Ön szerződéseivel. Ezek az eszközök segítenek személyre szabott figyelmeztetéseket is létrehozni különféle paraméterek alapján, mint amilyen a tranzakciómennyiség, a függvénymeghívások gyakorisága vagy az érintett függvények. Például beállíthat egy figyelmeztetést, ha a kivett pénzmennyiség egy tranzakcióban egy bizonyos határ felett van. + +### 7. Tervezzen biztonságos irányítási rendszert {#design-secure-governance-systems} + +Talán szeretné, hogy az alkalmazása decentralizált legyen, így a központi okosszerződések kontrollját a közösségi tagoknak adná. Ebben az esetben az okosszerződés rendszere felölel egy irányítási modult is – egy olyan mechanizmust, amellyel a közösségi tagok jóváhagyhatnak adminisztratív változásokat egy láncon belüli irányítási rendszer segítségével. Például azt a javaslatot, hogy a proxyszerződést egy új verzióra frissítsék, megszavaztathatja a tokennel rendelkező felhasználókkal. + +A decentralizált irányítás előnyös lehet, főleg mivel összeegyezteti a fejlesztők és a felhasználók érdekeit. Mindazonáltal az okosszerződés irányításimechanizmusa új kockázatokat is jelenthet, ha nem megfelelően vezetik be. Kézenfekvő probléma, ha egy támadó nagyon magas szavazatierőt szerez (amit az általa birtokolt tokenek száma ad) azáltal, hogy [villámhitelt](/defi/#flash-loans) vesz fel, majd egy ártó változásra tesz javaslatot. + +A láncon működő irányítási modell problémáit meg lehet oldani az [időzár használatával](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/) is. Az időzár megakadályozza, hogy az okosszerződés végrehajtson bizonyos műveleteket addig, amíg nem telt el egy adott idő. Más stratégia lehet a tokenekhez rendelt „szavazati súly” az alapján, hogy azt mennyi időre kötötték le, vagy egy adott cím szavazati erejét hosszabb periódusra is nézhetik (például 2–3 korábbi blokkra) a jelenlegi blokk helyett. Ezek csökkentik a lehetőségét annak, hogy valaki gyorsan jelentős szavazati erőre tegyen szert, hogy a láncon zajló szavazást eltérítse. + +Többet megtudhat a [biztonságos kormányzási rendszerek tervezéséről](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), a [különböző szavazási mechanizmusokról a DAO-kban](https://hackernoon.com/governance-is-the-holy-grail-for-daos) és [a DeFi-t kihasználó gyakori DAO támadási vektorokról](https://dacian.me/dao-governance-defi-attacks) a megosztott linkeken. + +### 8. Csökkentse a kód komplexitását a minimumra {#reduce-code-complexity} + +A hagyományos szoftverfejlesztők elve az, hogy a lehető legegyszerűbb legyen a kód (KISS-elv), és így nem vezetnek be fölösleges bonyolításokat a tervben. Ennek alapja az az elgondolás, hogy az „összetett rendszerek összetett módokon vallhatnak kudarcot”, és sokkal hajlamosabbak a költséges hibákra. + +A minél egyszerűbb megközelítés kiemelten fontos az okosszerződések írásánál is, mivel ezek nagy értékeket is kontrollálhatnak. Ennek eléréséhez érdemes létező könyvtárakat használni, mint amilyen az [OpenZeppelin szerződések](https://docs.openzeppelin.com/contracts/4.x/), amikor ez lehetséges. Mivel ezeket a könyvtárakat a fejlesztők már alaposan tesztelték, auditálták, így kisebb a hiba valószínűsége, mintha a nulláról kell megírni egy új funkcionalitást. + +Másik követendő tanács az, hogy rövid függvényeket kell írni és a szerződést modulárisan kell felállítani, az üzleti logikát több szerződés között felosztva. Az egyszerű kódok írása kevesebb teret ad a támadásra, emellett a teljes rendszer helyességét is jobban lehet igazolni, és a lehetséges tervezési hibák is korán kiderülhetnek. + +### 9. Védekezzen az okosszerződés általános sebezhetőségei ellen {#mitigate-common-smart-contract-vulnerabilities} + +#### Újrabelépés {#reentrancy} + +Az EVM nem engedi a párhuzamosságot, tehát két szerződés egy üzenethívásban nem futhat egyszerre. Egy külső hívás megállítja a meghívó szerződés végrehajtását és memóriáját addig, amíg a hívás vissza nem tér, amikor is a végrehajtás normálisan megtörténik. Ezt a folyamatot hivatalosan úgy nevezik, hogy a [kontrollfolyamat](https://www.computerhope.com/jargon/c/contflow.htm) átadása egy másik szerződésnek. + +Habár általában nem jelent problémát, a kontrollfolyamat nem megbízható szerződéseknek való átadása okozhat némi gondot, például az újrabelépés lehetőségét. Újrabelépéses támadás akkor történik, amikor egy ártó szerződés visszahívást csinál egy sebezhető szerződésbe mielőtt az eredeti függvény meghívása lezárulna. Ezt a támadási fajtát a következő példával jobban elmagyarázzuk. + +Vegyünk egy egyszerű okosszerződést („áldozat/victim”), ami megengedi, hogy bárki ethert helyezzen letétbe és vegyen ki: + +```solidity +// This contract is vulnerable. Do not use in production + +contract Victim { + mapping (address => uint256) public balances; + + function deposit() external payable { + balances[msg.sender] += msg.value; + } + + function withdraw() external { + uint256 amount = balances[msg.sender]; + (bool success, ) = msg.sender.call.value(amount)(""); + require(success); + balances[msg.sender] = 0; + } +} +``` + +Ez a szerződés elérhetővé teszi a `withdraw()` (kivétel) függvényt a felhasználóknak, hogy a korábban letétbe helyezett ETH-t ki tudják venni. Amikor egy ilyen kivétel történik, a szerződés a következő műveleteket hajtja végre: + +1. Ellenőrzi a felhasználó ETH-egyenlegét +2. Pénzeszközt küld a meghívó címére +3. Átállítja az egyenleget 0-ra, hogy ne lehessen kivenni innen pénzt + +A `withdraw()` függvény az `victim` (áldozat) szerződésében tehát egy „ellenőrzés-interakciók-eredmény” mintát követ. _Ellenőrzi_, hogy a végrehajtáshoz szükséges feltételek teljesülnek-e (a felhasználónak pozitív ETH-egyenlege van) és elvégzi az _interakciót_ azáltal, hogy ETH-t küld a meghívó címére, majd a tranzakció _eredményeit_ alkalmazza (lecsökkenti a felhasználó egyenlegét). + +Ha a `withdraw()` kódot egy külső tulajdonú számláról (EOA) hívják meg, akkor a vártnak megfelelően megy végbe: `msg.sender.call.value()` ETH-t küld a meghívónak. Azonban, ha a `msg.sender` egy okosszerződéses számla, ami meghívja a `withdraw()` kódot, akkor a `msg.sender.call.value()` révén indított pénzküldés szintén beindítja a címen tárolt programkódot. + +Tegyük fel, hogy a szerződéscímen ez a kód van telepítve: + +```solidity + contract Attacker { + function beginAttack() external payable { + Victim(victim_address).deposit.value(1 ether)(); + Victim(victim_address).withdraw(); + } + + function() external payable { + if (gasleft() > 40000) { + Victim(victim_address).withdraw(); + } + } +} +``` + +Ez a szerződés három dolgot csinál: + +1. Letétet fogad el egy másik számlától (valószínűleg a támadó/attacker EOA-ja) +2. Letétbe helyez 1 ETH-t az áldozat szerződésében +3. Kivesz 1 ETH-t, amelyet az okosszerződés tárol + +Ebben még nincs semmi rossz, viszont a `attacker` (támadó) szerződésben van egy másik függvény is, amely meghívja a `withdraw()` kódot a `victim` (áldozat) esetében újra, ha a maradék gáz a bejövő `msg.sender.call.value` esetén több mint 40 000. Ezáltal a `attacker` újra beléphet az `victim` szerződésbe és kivehet több pénzt _mielőtt_ a `withdraw` (kivétel) első meghívása lezárulna. A ciklus így néz ki: + +```solidity +- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH +- `Attacker.beginAttack()` deposits 1 ETH into `Victim` +- `Attacker` calls `withdraw() in `Victim` +- `Victim` checks `Attacker`’s balance (1 ETH) +- `Victim` sends 1 ETH to `Attacker` (which triggers the default function) +- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal) +- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call) +- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function) +- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals +- `Victim` finally applies the results of the first transaction (and subsequent ones) to its state, so `Attacker`’s balance is set to 0 +``` + +Összességében, mivel a meghívó egyenlege nem lesz 0 mindaddig, amíg a függvényvégrehajtás nem zárul le, a rákövetkező meghívások sikeresek lesznek, és megengedik a meghívónak, hogy kivegye az egyenlegét többször is. Ez a támadás alkalmas arra, hogy egy okosszerződés pénzeszközeit kifolyassák, ahogy az a [2016-os DAO hackelésnél](https://www.coindesk.com/learn/2016/06/25/understanding-the-dao-attack/) megtörtént. Az újrabelépéses támadás még mindig kritikus probléma az okosszerződéseknél, ahogy azt az [újrabelépéses támadások nyilvános listája](https://github.com/pcaversaccio/reentrancy-attacks) mutatja. + +##### Hogyan lehet megakadályozni egy újrabelépéses támadást + +Az újrabelépés ellen az [ellenőrzés-eredmények-interakciók mintát](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern) lehet alkalmazni. Ez a minta a függvények végrehajtását úgy rendezi, hogy az a kód jön először, amely a szükséges ellenőrzéseket végzi, azután a szerződés státuszát változtatják meg, végül a más szerződésekkel vagy külső tulajdonú számlákkal (EOA) való interakció következik. + +Az ellenőrzés-eredmények-interakciók minta a következőképpen néz ki a `victim` (áldozat) szerződésének új verziójában: + +```solidity +contract NoLongerAVictim { + function withdraw() external { + uint256 amount = balances[msg.sender]; + balances[msg.sender] = 0; + (bool success, ) = msg.sender.call.value(amount)(""); + require(success); + } +} +``` + +Ez a szerződés _ellenőrzi_ a felhasználó egyenlegét, érvényesíti a `withdraw()` függvény _eredményét_ (azáltal, hogy az egyenleget 0-ra állítja), és végül elvégzi az _interakciót_ (ETH-t küld a felhasználó címére). Ezáltal a szerződés először befrissíti a tárolt adatot, és csak utána végzi a külső hívást, így nincs lehetőség az újrabelépésre, mint korábban. Az `attacker` szerződés még mindig vissza tudja hívni a `NoLongerAVictim` (nem áldozat) szerződést, de mivel a `balances[msg.sender]` (egyenlege) már 0, a többi kivétel hibára fut. + +Másik lehetőség egy kölcsönös kizárás (más néven mutex), amely lezárja a szerződés státuszának egy részét addig, amíg a függvénymeghívás teljesül. Ezt egy boolean változóval lehet bevezetni, ami először `true` (igaz) a függvényvégrehajtás előtt, majd `false` (hamis) lesz a meghívás befejeztével. Ahogy az alábbi példából látszik, a mutex használata megvédi a függvényt attól, hogy újra meghívják, miközben az eredeti meghívás még zajlik, így hatásosan kivédi az újrabelépést. + +```solidity +pragma solidity ^0.7.0; + +contract MutexPattern { + bool locked = false; + mapping(address => uint256) public balances; + + modifier noReentrancy() { + require(!locked, "Blocked from reentrancy."); + locked = true; + _; + locked = false; + } + // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again. + // The `return` statement evaluates to `true` but still evaluates the `locked = false` statement in the modifier + function withdraw(uint _amount) public payable noReentrancy returns(bool) { + require(balances[msg.sender] >= _amount, "No balance to withdraw."); + + balances[msg.sender] -= _amount; + bool (success, ) = msg.sender.call{value: _amount}(""); + require(success); + + return true; + } +} +``` + +Továbbá a [„fizetéskérés”](https://docs.openzeppelin.com/contracts/4.x/api/security#PullPayment) rendszere is használható, amelynél a felhasználó vesz ki pénzt az okosszerződésből ahelyett, hogy a szerződés „fizetésküldést” végezne a számlák felé. Így nem lehet véletlenül elindítani egy kódot ismeretlen címeken (és bizonyos szolgálatmegtagadási támadásokat is ki tud védeni). + +#### Egész szám túlfolyása lefelé vagy felfelé {#integer-underflows-and-overflows} + +Egy egész szám akkor folyik túl felfelé, amikor egy aritmetikai művelet eredménye kívül esik az elfogadható tartományon, így az „tovább gördül” a legalacsonyabb megjeleníthető értékre. Például egy `uint8` csak 2^8-1=255 értéket tud tárolni. Az aritmetikai művelet, amelynek eredménye nagyobb mint `255`, túlfolyik és visszaállítja az `uint` kódot `0` értékre, ahhoz hasonlóan, ahogy egy autóban a megtett távolságot mérő óra is 0-ra fordul át, ha elérte a maximális értékét (999 999). + +Az egész szám lefelé való túlfolyása hasonló okokból következik be: az aritmetikai művelet eredménye az elfogadható tartomány alá esik. Tegyük fel, Ön szeretné lecsökkenteni a `0` értéket egy `uint8` típusú mezőben, így az egyszerűen átfordul a maximális megjeleníthető értékre (`255`). + +Mindkét irányú túlfolyás a szerződés állapotváltozóiban váratlan változásokat eredményezhet, így nem tervezett végrehajtást okozhat. Az alábbi példa bemutatja, hogyan tudja egy támadó kihasználni az aritmetikai túlfolyást egy okosszerződésben, hogy érvénytelen műveletet hajtson végre: + +``` +pragma solidity ^0.7.6; + +// This contract is designed to act as a time vault. +// User can deposit into this contract but cannot withdraw for at least a week. +// User can also extend the wait time beyond the 1 week waiting period. + +/* +1. Deploy TimeLock +2. Deploy Attack with address of TimeLock +3. Call Attack.attack sending 1 ether. You will immediately be able to + withdraw your ether. + +What happened? +Attack caused the TimeLock.lockTime to overflow and was able to withdraw +before the 1 week waiting period. +*/ + +contract TimeLock { + mapping(address => uint) public balances; + mapping(address => uint) public lockTime; + + function deposit() external payable { + balances[msg.sender] += msg.value; + lockTime[msg.sender] = block.timestamp + 1 weeks; + } + + function increaseLockTime(uint _secondsToIncrease) public { + lockTime[msg.sender] += _secondsToIncrease; + } + + function withdraw() public { + require(balances[msg.sender] > 0, "Insufficient funds"); + require(block.timestamp > lockTime[msg.sender], "Lock time not expired"); + + uint amount = balances[msg.sender]; + balances[msg.sender] = 0; + + (bool sent, ) = msg.sender.call{value: amount}(""); + require(sent, "Failed to send Ether"); + } +} + +contract Attack { + TimeLock timeLock; + + constructor(TimeLock _timeLock) { + timeLock = TimeLock(_timeLock); + } + + fallback() external payable {} + + function attack() public payable { + timeLock.deposit{value: msg.value}(); + /* + if t = current lock time then we need to find x such that + x + t = 2**256 = 0 + so x = -t + 2**256 = type(uint).max + 1 + so x = type(uint).max + 1 - t + */ + timeLock.increaseLockTime( + type(uint).max + 1 - timeLock.lockTime(address(this)) + ); + timeLock.withdraw(); + } +} +``` + +##### Hogyan akadályozható meg egy egész szám túlfolyása lefelé vagy felfelé + +A 0.8.0 verzió szerint a Solidity átfordító elutasítja azokat a kódokat, amelyek az egész szám túlfolyását eredményezik. Ugyanakkor az alacsonyabb verziójú átfordítóval készült szerződések esetén ellenőrizni kell azokat a függvényeket, amelyek aritmetikai műveleteket hajtanak végre, vagy egy olyan könyvtárat lehet használni (például [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)), amely ellenőrzi a túlfolyásokat. + +#### Orákulum manipulációja {#oracle-manipulation} + +Az [orákulumok](/developers/docs/oracles/) láncon kívüli információkat gyűjtenek és beküldik azokat a láncra, hogy az okosszerződések használhassák. Az orákulumok révén Ön olyan okosszerződéseket tervezhet, amelyek együtt tudnak működni láncon kívüli rendszerekkel, mint a tőkepiacok, ezzel nagy mértékben kiterjesztve az alkalmazási körüket. + +Ha viszont az orákulum korrupttá válik és nem helyes információkat küld a láncra, az okosszerződések hibás bejövő adatok alapján fognak működni, ez pedig problémákat okoz. Ez az „orákulumprobléma” alapja, amely miatt biztosítani kell, hogy a blokklánc-orákulum által adott információ pontos, friss és időben elérhető legyen. + +Az ehhez kapcsolódó biztonsági probléma az, amikor például egy decentralizált tőzsde a láncon belüli orákulumot használja arra, hogy megszerezze egy eszköz azonnali (spot) árát. A kölcsönző platformok a [decentralizált pénzügyek (DeFi)](/defi/) iparágában gyakran csinálják ezt, hogy meghatározzák a felhasználó fedezetének értékét, és ezáltal a kölcsön mértékét. + +A DEX árak gyakran igen pontosak, akár nagy mértékben is, mivel az arbitrázst kihasználók helyreállítják a piacokon az egyensúlyt. Ugyanakkor teret adnak a manipulációra, főleg ha a láncon futó orákulum az eszköz árát a korábbi kereskedelmi minták alapján számolja (ami általában igaz). + +Például egy támadó mesterségesen fel tudja pumpálni egy eszköz azonnali árát azáltal, hogy egy villámkölcsönt vesz fel éppen a kölcsönszerződés megkötése előtt. Ekkor a DEX lekérdezés az eszköz áráról egy magasabb értéket fog mutatni (mivel a támadó nagy összegű vételi igénye elmozdította az eszköz keresletét), így magasabb kölcsönt vehetnek fel, mint amit lehetne. Az ilyen „villámkölcsön-támadások” kihasználták azt, hogy a DeFi alkalmazások az orákulumokra támaszkodnak az árakat tekintve, és így sok milliónyi elveszett pénzeszközt eredményeztek a protokolloknak. + +##### Hogyan lehet elkerülni az oracle manipulációt + +A minimum követelmény az [oracle manipuláció elkerülésére](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) az, hogy decentralizált oracle-hálózatokat kell használni, amelyek több forrásból szerzik be az információkat, így elkerülhető az egyetlen meghibásodási pont lehetősége. A legtöbb esetben a decentralizált orákulumoknak beépített kriptogazdasági ösztönzőik vannak, hogy az orákulum-csomópontok a helyes információt jelentsék, így sokkal biztonságosabbak, mint a centralizált társaik. + +Ha Ön azt tervezi, hogy egy láncon lévő orákulumot kérdez le eszközárakért, akkor használjon olyat, amely idővel súlyozott átlagárat (TWAP) számol. A [TWAP-orákulum](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) egy adott eszköz árát két különböző időpontban (ami módosítható) kérdezi le, és a megszerzett átlaga alapján kalkulálja az azonnali árat. A hosszabb időtartomány használata megvédi a protokollt az ármanipulációtól, mert a közelmúltban végrehajtott nagy rendelések nem befolyásolják az árat. + +## Okosszerződés-biztonsággal kapcsolatos anyagok fejlesztők számára {#smart-contract-security-resources-for-developers} + +### Eszközök az okosszerződések elemzéséhez és a kód helyességének ellenőrzéséhez {#code-analysis-tools} + +- **[Tesztelő eszközök és könyvtárak](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** – _Iparági standard eszközök és könyvtárak gyűjteménye az okosszerződések egységteszteléséhez, valamint a statikus és dinamikus elemzéséhez._ + +- **[Formális ellenőrzési (formal verification) eszközök](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** – _Eszközök arra, hogy ellenőrizzék az okosszerződések funkcionális helyességét és az állandókat._ + +- **[Okosszerződés auditálásra vonatkozó szolgáltatások](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** – _Szervezetek listája, amelyek auditszolgáltatást kínálnak okosszerződésekre az Ethereum fejlesztési projektek számára._ + +- **[Hibavadász platformok](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** – _Platformok a hibavadászatok és a jutalmak koordinálására, hogy azok feltárják az okosszerződésekben lévő kritikus sebezhetőségeket._ + +- **[Fork Checker](https://forkchecker.hashex.org/)** – _Egy ingyenes online eszköz arra, hogy információt kapjon egy elágaztatott szerződésről._ + +- **[ABI Encoder](https://abi.hashex.org/)** – _Egy ingyenes online szolgáltatás a Solidity szerződés függvényeinek és constructor parancsainak kódolására._ + +- **[Aderyn](https://github.com/Cyfrin/aderyn)** – _Solidity statikus elemző, amely végigjárja az absztrakt szintaxisfákat (AST), hogy kiszűrje a feltételezett sebezhetőségeket, és könnyen érthető markdown formátumban kiírja a problémákat._ + +### Eszközök az okosszerződések felügyeletére {#smart-contract-monitoring-tools} + +- **[OpenZeppelin Defender Sentinels](https://docs.openzeppelin.com/defender/v1/sentinel)** – _Egy eszköz az okosszerződés automatikus felügyeletére, valamint az eseményekre, függvényekre és tranzakcióparaméterekre való válaszadásra._ + +- **[Tenderly Real-Time Alerting](https://tenderly.co/alerting/)** – _Egy eszköz, amellyel valós idejű értesítést kaphat, amikor az okosszerződésén vagy tárcáján szokatlan vagy váratlan események történnek._ + +### Eszközök az okosszerződések biztonságos adminisztrálásához {#smart-contract-administration-tools} + +- **[OpenZeppelin Defender Admin](https://docs.openzeppelin.com/defender/v1/admin)** – _Interfész az okosszerződések adminisztrációjának kezeléséhez, beleértve a hozzáférés-kezelést, frissítéseket és leállítást is._ + +- **[Safe](https://safe.global/)** – _Egy okosszerződéses tárca az Ethereumon, amelynél adott számú embernek jóvá kell hagynia a tranzakciót, mielőtt az megtörténhetne (N számú tagból M-nek)._ + +- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/4.x/)** – _Szerződéskönyvtárak az adminisztrációs jellemzők bevezetésére, beleértve a szerződés tulajdonlását, frissítéseket, hozzáférés-kezelést, irányítást, leállíthatóság és még sok mást._ + +### Okosszerződés auditálására kínált szolgáltatások {#smart-contract-auditing-services} + +- **[ConsenSys Diligence](https://consensys.net/diligence/)** – _Okosszerződés auditálására kínált szolgáltatások, amelyek támogatják a blokklánc-ökoszisztéma projektjeit, hogy a protokolljaik készen állnak-e a bevezetésre és úgy épültek-e meg, hogy védik a felhasználókat._ + +- **[CertiK](https://www.certik.com/)** – _Egy blokkláncbiztonsággal foglalkozó cég, amely úttörőként használja az élvonalbeli formális ellenőrzés technológiáját az okosszerződésekre és a blokklánchálózatokra._ + +- **[Trail of Bits](https://www.trailofbits.com/)** – _Kiberbiztonsági cég, amely kombinálja a biztonsági kutatást és a támadói mentalitást, hogy csökkentse a kockázatot és megerősítse a kódot._ + +- **[PeckShield](https://peckshield.com/)** – _Blokkláncbiztonsággal foglalkozó cég, amely a teljes blokklánc-ökoszisztémához kínál termékeket és szolgáltatásokat a biztonság, adatvédelem és használhatóság területein._ + +- **[QuantStamp](https://quantstamp.com/)** – _Auditszolgáltatás, amely elősegíti a blokklánctechnológia kiterjedt használatát a biztonsági és kockázatelemzési szolgáltatásokkal._ + +- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** – _Okosszerződés-biztonsággal foglalkozó cég, amely a megosztott rendszerek számára biztosít biztonsági auditokat._ + +- **[Runtime Verification](https://runtimeverification.com/)** – _Biztonsági cég, amely az okosszerződések formális modellezésére és ellenőrzésére specializálódott._ + +- **[Hacken](https://hacken.io)** – _Web3 kiberbiztonsági auditor, amely 360 fokos megközelítést alkalmaz a blokkláncbiztonságban._ + +- **[Nethermind](https://nethermind.io/smart-contracts-audits)** – _Solidity és Cairo auditszolgáltatások, amelyekkel az okosszerződések integritása, valamint a felhasználók biztonsága is biztosíthat az Ethereumon és a Starkneten._ + +- **[HashEx](https://hashex.org/)** – _A HashEx a blokkláncok és okosszerződések auditálásra szakosodott a kriptovaluták biztonságának biztosítása céljából, illetve olyan szolgáltatásokat nyújt, mint az okosszerződés-fejlesztés, sérülékenység-vizsgálat, blokklánctanácsadás._ + +- **[Code4rena](https://code4rena.com/)** – _Versenyképes auditplatform, amely arra ösztönzi az okosszerződés-biztonsági szakértőket, hogy sebezhetőséget találjanak és segítsenek a web3-at biztonságosabbá tenni._ + +- **[CodeHawks](https://codehawks.com/)** – _Versenyképes auditplatform, amely okosszerződések auditálási versenyeit tartja a biztonsági szakértők számára._ + +- **[Cyfrin](https://cyfrin.io)** – _Web3 biztonsági erőmű, elősegíti kriptobiztonságot termékeken és okosszerződés-ellenőrzési szolgáltatásokon keresztül._ + +- **[ImmuneBytes](https://www.immunebytes.com//smart-contract-audit/)** – _Web3 biztonsági cég, amely a blokkláncrendszerek biztonsági ellenőrzését kínálja tapasztalt auditorcsapattal és a legjobb eszközökkel._ + +- **[Oxorio](https://oxor.io/)** - _Okosszerződés-auditok és blokkláncbiztonsági szolgáltatások, szakértelem az EVM, Solidity, ZK, kriptocégek láncok közötti technológiái és DeFi projektek területén._ + +- **[Inference](https://inference.ag/)** - _Biztonsági auditot végző cég, az EVM-alapú blokkláncok okosszerződés-auditjára specializálódva. A tapasztalt auditorok beazonosítják a lehetséges problémákat és megvalósítható megoldásokat javasolnak, hogy telepítés előtt ki legyenek javítva._ + +### Hibavadászplatformok {#bug-bounty-platforms} + +- **[Immunefi](https://immunefi.com/)** – _Hibavadászplatform okosszerződésekhez és DeFi-projektekhez, ahol a biztonsági kutatók átnézik a kódot, kizárják a sebezhetőségeket, ezért jutalmat kapnak, és biztonságosabbá teszik a kripto világát._ + +- **[HackerOne](https://www.hackerone.com/)** – _Sebezhetőségi koordináció és hibavadászplatform, amely összeköti a vállalkozásokat a sebezhetőségi tesztelőkkel és kiberbiztonsági kutatókkal._ + +- **[HackenProof](https://hackenproof.com/)** – _Szakértői hibavadászplatform kriptoprojektek (DeFi, okosszerződések, tárcák, CEX stb.) számára, ahol a biztonsági szakértők prioritási sorrendszolgáltatást nyújtanak, a kutatók pedig jutalmat kapnak a releváns, igazolt hibák jelentéséért._ + +- **[Sherlock](https://www.sherlock.xyz/)** - _Biztosítja a web3-ban az okosszerződések biztonságát, az auditorok kifizetéseit okosszerződéseken keresztül kezelik, hogy biztosítsák a releváns hibák kifizetését._ + +- **[CodeHawks](https://www.codehawks.com/)** - _Versenyképes hibavadász platform, ahol az auditorok biztonsági vetélkedőkben és kihívásokban vesznek részt, majd a saját privát auditjukban._ + +### Publikációk az okosszerződések ismert sebezhetőségeiről és azok kihasználásáról {#common-smart-contract-vulnerabilities-and-exploits} + +- **[Consensys: az okosszerződéseket ért ismert támadások](https://consensys.github.io/smart-contract-best-practices/attacks/)** – _Egyszerűen megfogalmazott magyarázat a legkomolyabb sérülékenységekről a szerződésekben, a legtöbb esetben mintakódokkal együtt._ + +- **[SWC Registry](https://swcregistry.io/)** – _A Közös gyengeségek felsorolásának (CWE) gondozott listája, amelyen az Ethereum okosszerződésekre vonatkozó tételek szerepelnek._ + +- **[Rekt](https://rekt.news/)** – _Rendszeresen frissített publikáció a nagy jelentőségű kriptohackelésekről és támadásokról, az esemény után készült részletes riportokkal._ + +### Kihívások az okosszerződés-biztonság elsajátításában {#challenges-for-learning-smart-contract-security} + +- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** – _Blokkláncbiztonsági háborús játékok, kihívások és [szerezd meg a zászlót (Capture The Flag)](https://www.webopedia.com/definitions/ctf-event/amp/) versenyek és megoldások gondozott listája._ + +- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** – _Háborús játék a DeFi okosszerződések támadó biztonságának elsajátításához, valamint készségek fejlesztéséhez a hibavadászatban és a biztonsági auditban._ + +- **[Ethernaut](https://ethernaut.openzeppelin.com/)** – _Web3/Solidity-alapú háborús játék, ahol minden szint egy okosszerződés, amelyet meg kell „hackelni”._ + +- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _Okosszerződés hackelési kihívás egy fantáziakalandba ágyazva. A kihívás sikeres teljesítése egy privát hibavadász programhoz ad hozzáférést._ + +### Bevált gyakorlatok az okosszerződések biztonságossá tételére {#smart-contract-security-best-practices} + +- **[ConsenSys: az Ethereum okosszerződés-biztonság bevált gyakorlatai](https://consensys.github.io/smart-contract-best-practices/)** – _Részletes útmutatók az Ethereum-okosszerződések biztonságossá tételére._ + +- **[Nascent: Egyszerű biztonsági eszközrendszer](https://github.com/nascentxyz/simple-security-toolkit)** – _Hasznos biztonságközpontú útmutatók és ellenőrző listák gyűjteménye okosszerződés-fejlesztéshez._ + +- **[Solidity Patterns](https://fravoll.github.io/solidity-patterns/)** – _Biztonsági minták és bevált gyakorlatok hasznos gyűjteménye Solidity programnyelven írt okosszerződésekhez._ + +- **[Solidity Docs: Biztonsági megfontolások](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** – _Útmutatók a biztonságos okosszerződések írásához Solidity nyelven._ + +- **[Smart Contract Security Verification Standard](https://github.com/securing/SCSVS)** – _Egy tizennégy részes ellenőrző lista fejlesztők, architektúrával foglalkozók, biztonság-ellenőrzők és beszállítók számára az okosszerződések biztonságának szabványosításához._ + +- **[Az okosszerződések biztonságának és auditálásának elsajátítása](https://updraft.cyfrin.io/courses/security) – _Az okosszerződések biztonságát és auditálását oktató tanfolyamot olyan fejlesztőknek hozták létre, akik a legjobb biztonsági gyakorlatok mentén szeretnének fejleszteni és biztonsági kutatókká válni._ + +### Útmutatók az okosszerződés-biztonságról {#tutorials-on-smart-contract-security} + +- [Hogyan lehet biztonságosabb okosszerződéskódot írni](/developers/tutorials/secure-development-workflow/) + +- [A Slither használata okosszerződés bugok felderítésére](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) + +- [A Manticore használata okosszerződés bugok felderítésére](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) + +- [Okosszerződések biztonsági irányelvei](/developers/tutorials/smart-contract-security-guidelines/) + +- [Hogyan lehet biztonságosan integrálni a tokenszerződést tetszőleges tokenekkel](/developers/tutorials/token-integration-checklist/) + +- [Cyfrin Updraft – Okosszerződések biztonsága és auditálása tanfolyam](https://updraft.cyfrin.io/courses/security) diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" new file mode 100644 index 00000000000..23cb43578e0 --- /dev/null +++ "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" @@ -0,0 +1,76 @@ +--- +title: Okosszerződés összeilleszthetőség +description: +lang: hu +incomplete: true +--- + +## Egy rövid bevezető {#a-brief-introduction} + +Az okosszerződések nyilvánosak az Ethereumon, így nyílt API-ként is tekinthetünk rájuk. A dapp fejlesztővé váláshoz nem kell saját okosszerződéseket írnia, csak tudnia kell, hogyan lépjen interakcióba azokkal. Például használhatja a [Uniswap](https://uniswap.exchange/swap) meglévő okosszerződéseit, egy decentralizált tőzsdét, mely kezeli a tokenváltási logikát az appban – nem kell a legelejéről kezdeni. Tekintsen meg néhány [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) és [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts) szerződést. + +## Mi az az összeilleszthetőség? {#what-is-composability} + +Az összeilleszthetőség a különböző komponensek kombinálása új rendszerek vagy kimenetek létrehozása érdekében. A szoftverfejlesztésben az összeilleszthetőség azt jelenti, hogy a fejlesztők a meglévő szoftverkomponenseket új alkalmazások létrehozásához újra felhasználhatják. Az összeilleszthetőséget úgy is el lehet képzelni, hogy az elemei a LEGO kockákra hasonlítanak. Minden egyes LEGO kombinálható egy másikkal, így a különböző elemek kombinálásával összetett szerkezeteket építhet. + +Az Ethereumban minden okosszerződés egyfajta LEGO – Ön is használhat más projektekből származó okosszerződéseket saját projektje építőköveként. Ez azt jelenti, hogy nem kell időt töltenie a kerék újbóli feltalálásával vagy a nulláról való építkezéssel. + +## Hogyan működik az összeilleszthetőség? {#how-does-composability-work} + +Az Ethereum-okosszerződések olyanok, mint a nyilvános API-ok, így bárki kölcsönhatásba léphet a szerződéssel, vagy integrálhatja azokat dappokba a hozzáadott funkciók érdekében. Az okosszerződések összeilleszthetősége három alapelv szerint működik – ez a modularitás, az autonómia és a felfedezhetőség: + +**1. Modularitás**: Az egyes komponensek képessége egy adott feladat elvégzésére. Az Ethereumban minden okosszerződésnek van egy konkrét felhasználási esete (ahogy az Uniswap példában is látható). + +**2. Autonómia**: Az összeilleszthető komponenseknek képesnek kell lenniük az önálló működésre. Az Ethereumban minden okosszerződés önvégrehajtó, és a rendszer más részei nélkül képes működni. + +**3. Felfedezhetőség**: A fejlesztők nem tudnak külső szerződéseket hívni vagy szoftverkönyvtárakat integrálni az alkalmazásokba, ha az előbbiek nem nyilvánosak. Az okosszerződések eleve nyílt forráskódúak; bárki meghívhat egy okosszerződést vagy elágaztathat egy kódot. + +## Az összeilleszthetőség előnyei {#benefits-of-composability} + +### Rövidebb fejlesztési ciklus {#shorter-development-cycle} + +Az összeilleszthetőség leveszi a munkaterhelést a fejlesztők válláról a [dappok](/dapps/#what-are-dapps) létrehozásakor. [Ahogy Naval Ravikant fogalmaz:](https://twitter.com/naval/status/1444366754650656770) „A nyílt forráskód azt jelenti, hogy egy adott problémát csak egyszer kell megoldani.” + +Ha van egy okosszerződés, amely megold egy problémát, más fejlesztők újra felhasználhatják, így nem kell ugyanazt a problémát megoldaniuk. Ezáltal a fejlesztők a meglévő szoftverkönyvtárakat felhasználhatják, és extra funkciókat adhatnak hozzá, hogy új dappokat hozzanak létre. + +### Nagyobb innováció {#greater-innovation} + +Az összeilleszthetőség ösztönzi az innovációt és a kísérletezést, mivel a fejlesztők szabadon újrafelhasználhatják, módosíthatják, duplikálhatják vagy integrálhatják a nyílt forráskódot a kívánt eredmények érdekében. Ennek eredményeképpen a fejlesztőcsapatok kevesebb időt töltenek az alapvető funkciókkal, és több időt fordíthatnak az új funkciókkal való kísérletezésre. + +### Jobb felhasználói élmény {#better-user-experience} + +Az Ethereum-ökoszisztéma összetevői közötti átjárhatóság javítja a felhasználói élményt. A felhasználók nagyobb funkcionalitáshoz férhetnek hozzá, ha a dappok külső okosszerződéseket integrálnak, mint egy széttagolt ökoszisztémában, ahol az alkalmazások nem tudnak kommunikálni. + +Az interoperabilitás előnyeit az arbitrázskereskedelemből vett példával szemléltetjük: + +Ha egy token magasabb árfolyamon kereskedik az `A tőzsdén`, mint a `B tőzsdén`, akkor kihasználhatja az árkülönbséget, hogy profitot termeljen. Ezt azonban csak akkor teheti meg, ha elegendő tőkével rendelkezik a tranzakció finanszírozásához (azaz megvásárolja a tokent a `B tőzsdén`, és eladja az `A tőzsdén`). + +Abban az esetben, amikor nincs elég pénze a kereskedés fedezésére, ideális lehet egy gyorskölcsön. A [gyorskölcsönök](/defi/#flash-loans) nagyon technikai jellegűek, de az alapötlet az, hogy Ön (fedezet nélkül) kölcsönvehet eszközöket, és ugyanezt _egy_ tranzakción belül visszaadhatja. + +Visszatérve a kezdeti példánkhoz, egy arbitrázskereskedő felvehet egy nagy összegű gyorskölcsönt, vásárolhat tokeneket a `B tőzsdén`, eladhatja azokat az `A tőzsdén`, visszafizetheti a tőkét és a kamatot, és megtarthatja a nyereséget ugyanazon tranzakción belül. Ez az összetett logika több szerződés meghívásának kombinálását igényli, ami nem lenne lehetséges, ha az okosszerződések nem lennének interoperábilisak. + +## Az összeilleszthetőség példái az Ethereumon {#composability-in-ethereum} + +### Tokenátváltások {#token-swaps} + +Ha olyan dappot hoz létre, amelyben a tranzakciókat ETH-ben kell kifizetni, a tokenátváltás-logika integrálásával lehetővé teheti a felhasználók számára, hogy más ERC-20 tokenekkel fizessenek. A kód automatikusan átváltja a felhasználó tokenjét ETH-re, mielőtt a szerződés végrehajtja a meghívott funkciót. + +### Irányítás {#governance} + +Az egyedi irányítási rendszerek kiépítése a [DAO-k](/dao/) számára költséges és időigényes lehet. Ehelyett használhat egy nyílt forráskódú irányítási eszközkészletet, például az [Aragon Client](https://client.aragon.org/) megoldást, hogy gyorsan megalkossa a DAO irányítási keretrendszerét. + +### Identitáskezelés {#identity-management} + +Ahelyett, hogy egyéni hitelesítési rendszert építene vagy központi szolgáltatókra támaszkodna, decentralizált identitás (DID) eszközöket integrálhat a felhasználók hitelesítésének kezelésére. Ilyen például a [SpruceID](https://www.spruceid.com/), egy nyílt forráskódú eszközkészlet, amely „Bejelentkezés az Ethereummal” funkciót kínál, ez pedig lehetővé teszi a felhasználók számára, hogy Ethereum-tárcával hitelesítsék az identitásukat. + +## Kapcsolódó útmutatók {#related-tutorials} + +- [Indítsa el a dapp frontend fejlesztését a create-eth-app segítségével](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– Egy áttekintés arról, hogyan használja a create-eth-appot a népszerű okosszerződésekkel rendelkező alkalmazások készítéséhez._ + +## További olvasnivaló {#further-reading} + +_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ + +- [Az összeilleszthetőség az innováció](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/) +- [Miért fontos az összeilleszthetőség a web3-nak](https://hackernoon.com/why-composability-matters-for-web3) +- [Mi az az összeilleszthetőség?](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" new file mode 100644 index 00000000000..b5593597862 --- /dev/null +++ "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" @@ -0,0 +1,283 @@ +--- +title: Az okosszerződések formális ellenőrzése +description: Az Ethereum-okosszerződések formális ellenőrzésének áttekintése +lang: hu +--- + +Az [okosszerződések](/developers/docs/smart-contracts/) lehetővé teszik a decentralizált, bizalomigény nélküli és robusztus alkalmazások létrehozását, amelyek új felhasználási módokat vezetnek be és értéket teremtenek a felhasználók számára. Mivel az okosszerződések nagy mennyiségű értéket kezelnek, a biztonság kritikus szempont a fejlesztőknek. + +A formális ellenőrzés az egyik ajánlott technika az [okosszerződések biztonságának](/developers/docs/smart-contracts/security/) javítására. A formális ellenőrzést, amely [formális módszereket](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) használ a programok specifikálására, tervezésére és ellenőrzésére, már évek óta használják a kritikus hardver- és szoftverrendszerek helyességének biztosítására. + +Az okosszerződésekben megvalósított formális ellenőrzéssel bizonyítani lehet, hogy a szerződés üzleti logikája megfelel egy előre meghatározott specifikációnak. A szerződéskód helyességének értékelésére szolgáló más módszerekkel összehasonlítva, mint amilyen a tesztelés, a formális ellenőrzés erősebb garanciát nyújt arra, hogy az okosszerződés funkcionálisan helyes. + +## Mi az a formális ellenőrzés? {#what-is-formal-verification} + +A formális ellenőrzés során egy rendszer helyességét egy formális specifikáció alapján értékeljük. Egyszerűbben, a formális ellenőrzéssel ellenőrizhetjük, hogy egy rendszer viselkedése kielégít-e meghatározott követelményeket (azt teszi-e, amit szeretnénk). + +A rendszer (jelen esetben egy okosszerződés) várható viselkedését formális modellezéssel írják le, a specifikációs nyelvek pedig lehetővé teszik a formális tulajdonságok létrehozását. A formális ellenőrzési technikákkal ellenőrizni lehet, hogy a szerződés megvalósítása megfelel-e a specifikációjának, és matematikai bizonyítékot nyerhetünk a helyességére. Ha egy szerződés megfelel a specifikációjának, akkor azt „funkcionálisan helyesnek”, „tervezési szempontból helyesnek” vagy „konstrukciós szempontból helyesnek” nevezik. + +### Mi az a formális modell? {#what-is-a-formal-model} + +Az informatikában a [formális modell](https://en.wikipedia.org/wiki/Model_of_computation) egy számítási folyamat matematikai leírása. A programokat matematikai függvényekké (egyenletekké) absztrahálják, és a modell leírja, hogy a függvények kimenetei hogyan számíthatók ki egy bemenet alapján. + +A formális modellek olyan absztrakciós szintet biztosítanak, amelyen a program viselkedésének elemzése kiértékelhető. A formális modellek létezése lehetővé teszi egy _formális specifikáció_ létrehozását, amely leírja az adott modell kívánt tulajdonságait. + +A formális ellenőrzésnél különböző technikákat használnak az okosszerződések modellezésére. Egyes modelleket például arra használnak, hogy egy okosszerződés magas szintű viselkedéséről gondolkodjanak. Ezek a modellezési technikák feketedobozos szemléletet alkalmaznak az okosszerződésekre, olyan rendszereknek tekintve őket, amelyek bemeneteket fogadnak el, és ezek alapján számításokat hajtanak végre. + +A magas szintű modellek az okosszerződések és a külső szereplők közötti kapcsolatra összpontosítanak, mint amilyenek a külső tulajdonú számlák (EOA), a szerződésszámlák és a blokklánckörnyezet. Az ilyen modellek hasznosak olyan tulajdonságok definiálásához, amelyek meghatározzák, hogy a szerződésnek hogyan kell viselkednie bizonyos felhasználói interakciók hatására. + +Ezzel szemben más formális modellek az okosszerződés alacsony szintű viselkedésére összpontosítanak. Míg a magas szintű modellek segíthetnek a szerződés funkcionalitásáról való gondolkodásban, a végrehajtás belső működésének részleteit nem feltétlenül rögzítik. Az alacsony szintű modellek fehérdobozos szemléletet alkalmaznak a programelemzésre, és az okosszerződés-alkalmazások alacsonyabb szintű reprezentációira, például programnyomokra és [kontrollfolyamat-ábrákra](https://en.wikipedia.org/wiki/Control-flow_graph) támaszkodnak, hogy a szerződés végrehajtása szempontjából releváns tulajdonságokra következtessenek. + +Az alacsony szintű modellek ideálisnak számítanak, mivel az Ethereum végrehajtási környezetében ([EVM](/developers/docs/evm/)) egy okosszerződés tényleges végrehajtását reprezentálják. Az alacsony szintű modellezési technikák különösen hasznosak az okosszerződések kritikus biztonsági tulajdonságainak megállapításában és a potenciális sebezhetőségek felderítésében. + +### Mi az a formális specifikáció? {#what-is-a-formal-specification} + +A specifikáció egyszerűen egy műszaki követelmény, amelynek egy adott rendszernek meg kell felelnie. A programozásban a specifikációk általános elképzeléseket jelentenek egy program végrehajtásáról (a programnak mit kell tennie). + +Az okosszerződésekkel összefüggésben a formális specifikációk _tulajdonságokra_ utalnak – azoknak a követelményeknek a formális leírására, amelyeknek egy szerződésnek meg kell felelnie. Az ilyen tulajdonságokat „konstansoknak” nevezik, és olyan logikai állításokat képviselnek a szerződés végrehajtásáról, amelyeknek minden lehetséges körülmény között, kivételek nélkül igaznak kell maradniuk. + +Így a formális specifikációra úgy gondolhatunk, mint egy formális nyelven írt kijelentésgyűjteményére, amelyek leírják az okosszerződés tervezett végrehajtását. A specifikációk a szerződés tulajdonságaira vonatkoznak, és meghatározzák, hogy a szerződésnek hogyan kell viselkednie különböző körülmények között. A formális ellenőrzés célja annak meghatározása, hogy egy okosszerződés rendelkezik-e ezekkel a tulajdonságokkal (konstansokkal), és hogy ezek a tulajdonságok nem sérülnek-e a végrehajtás során. + +A formális specifikációk kritikusak az okosszerződések biztonságos implementációinak fejlesztésében. Azok a szerződések, amelyek nem teljesítik a konstansokat, vagy tulajdonságaikat a végrehajtás során megsértik, hajlamosak olyan sebezhetőségekre, amelyek károsíthatják a funkcionalitást vagy rosszindulatú kihasználást okozhatnak. + +## Az okosszerződések formális specifikációinak típusai {#formal-specifications-for-smart-contracts} + +A formális specifikációk lehetővé teszik a programvégrehajtás helyességére vonatkozó matematikai következtetéseket. A formális modellekhez hasonlóan a formális specifikációk is rögzíthetik a szerződés implementációjának magas szintű tulajdonságait vagy alacsony szintű viselkedését. + +A formális specifikációkat a [programlogika](https://en.wikipedia.org/wiki/Logic_programming) elemeinek felhasználásával vezetik le, amelyek lehetővé teszik a program tulajdonságairól való formális következtetést. A programlogika formális szabályokat tartalmaz, amelyek (matematikai nyelven) kifejezik a program várható viselkedését. A formális specifikációk létrehozásához különböző programlogikákat használnak, többek között [elérhetőségi logikát](https://en.wikipedia.org/wiki/Reachability_problem), [időbeli logikát](https://en.wikipedia.org/wiki/Temporal_logic) és [Hoare-logikát](https://en.wikipedia.org/wiki/Hoare_logic). + +Az okosszerződések formális specifikációi nagy vonalakban **magas** vagy **alacsony szintű** specifikációk közé sorolhatók. Függetlenül attól, hogy egy specifikáció milyen kategóriába tartozik, megfelelően és egyértelműen le kell írnia az elemzett rendszer tulajdonságát. + +### Magas szintű specifikációk {#high-level-specifications} + +Ahogy a neve is mutatja, a magas szintű specifikáció (más néven „modellorientált specifikáció”) egy program magas szintű viselkedését írja le. A magas szintű specifikációk az okosszerződést egy [véges állapotú gépként (FSM)](https://en.wikipedia.org/wiki/Finite-state_machine) modellezik, amely műveletek végrehajtásával képes státuszt váltani, időbeli logikát használva az FSM-modell formális tulajdonságainak meghatározásához. + +[Az időbeli logika](https://en.wikipedia.org/wiki/Temporal_logic) olyan szabály, mely az idő szempontjából minősített állításokról szól (például _mindig_ éhes vagyok vagy _végül_ éhes leszek). A formális verifikációban az időbeli logikát a státuszgépekként modellezett rendszerek helyes viselkedésére vonatkozó állítások megfogalmazására használják. Pontosabban, egy időbeli logika leírja, hogy egy okosszerződés milyen státuszokban lehet, és hogyan vált azok között. + +A magas szintű specifikációk általában két kritikus időbeli tulajdonságot rögzítenek az okosszerződések esetében: **biztonság** és **elérhetőség (liveness)**. A biztonsági tulajdonságok azt képviselik, hogy „nem történik semmi rossz”, és változatlanságot fejeznek ki. Egy biztonsági tulajdonság meghatározhat általános szoftverkövetelményeket, mint a [holtpontmentesség (deadlock)](https://www.techtarget.com/whatis/definition/deadlock), vagy kifejezheti a szerződések területspecifikus tulajdonságait (például a függvények hozzáférés-szabályozásának konstansai, a státuszváltozók megengedett értékei vagy a tokenátvitel feltételei). + +Vegyük például ezt a biztonsági követelményt, amely az ERC-20 tokenszerződésekben a `transfer()` vagy `transferFrom()` használatának feltételeit tartalmazza: _„A feladó egyenlege soha nem lehet alacsonyabb, mint a küldendő tokenek kért mennyisége.”_. A szerződéskonstans természetes nyelvű leírása lefordítható formális (matematikai) specifikációvá, amelyet ellenőrizni lehet érvényességi szempontból. + +Az elérhetőségtulajdonságok azt állítják, hogy „valami jó történik”, tehát a szerződés képes-e különböző státuszokon keresztül haladni. Egy példa az elérhetőségtulajdonságra a „likviditás”, tehát a szerződés képes-e a felhasználóknak átadni az egyenleget kérés alapján. Ha ez a tulajdonság sérül, a felhasználók nem tudnák kivenni a szerződésben tárolt eszközöket, ahogy az a [Parity-tárca incidens](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html) esetében történt. + +### Alacsony szintű specifikációk {#low-level-specifications} + +A magas szintű specifikációk kiindulópontja egy szerződés véges státuszú modellje, és meghatározzák e modell kívánt tulajdonságait. Ezzel szemben az alacsony szintű specifikációk (más néven „tulajdonságorientált specifikációk”) gyakran matematikai függvények gyűjteményéből álló rendszerekként modellezik a programokat (okosszerződéseket), és leírják ezek helyes viselkedését. + +Egyszerűbben fogalmazva, az alacsony szintű specifikációk _programnyomokat_ elemeznek, és megpróbálják meghatározni egy okosszerződés tulajdonságait ezeken keresztül. A nyomvonalak az okosszerződés státuszát változtató funkcióvégrehajtások sorozataira utalnak, ezért az alacsony szintű specifikációk meghatározzák a szerződés belső végrehajtásának követelményeit. + +Az alacsony szintű formális specifikációkat Hoare-stílusú tulajdonságokként vagy végrehajtási útvonalakra vonatkozó konstansokként lehet megadni. + +### Hoare-stílusú tulajdonságok {#hoare-style-properties} + +A [Hoare-logika](https://en.wikipedia.org/wiki/Hoare_logic) egy sor formális szabályt biztosít a programok, köztük az okosszerződések helyességére vonatkozó érveléshez. Egy Hoare-stílusú tulajdonságot egy Hoare-hármas {_P_}_c_{_Q_} reprezentál, ahol _c_ egy program, _P_ és _Q_ állítások a _c_ státuszára (a programra) vonatkozóan, amelyeket formálisan _előfeltételekkel_ és _utófeltételekkel_ írunk le. + +Az előfeltétel egy állítás, amely leírja a függvény helyes végrehajtásához szükséges feltételeket; a szerződést meghívó felhasználóknak meg kell felelniük ennek a követelménynek. Az utófeltétel egy állítás, amely azt a feltételt írja le, amelyet egy függvény helyesen végrehajtva állít fel; a felhasználók elvárhatják, hogy ez a feltétel igaz legyen a függvény meghívása után. A _konstans_ a Hoare-logikában olyan állítás, amely egy függvény végrehajtása során megmarad (nem változik). + +A Hoare-stílusú specifikációk garantálhatják a _részleges_ vagy a _teljes helyességet_. Egy szerződésfüggvény végrehajtása „részben helyes”, ha az előfeltétel igaz a függvény végrehajtása előtt, és ha a végrehajtás befejeződik, akkor az utófeltétel is igaz. A teljes helyesség bizonyítékát akkor kapjuk meg, ha egy előfeltétel igaz a függvény végrehajtása előtt, a végrehajtás garantáltan befejeződik, és amikor ez megtörténik, az utófeltétel igaz. + +A teljes helyesség bizonyítása nehéz, mivel egyes végrehajtások késhetnek a befejezés előtt, vagy egyáltalán nem fejeződnek be. Ennek ellenére a kérdés, hogy a végrehajtás befejeződik-e, vitatható, mivel az Ethereum gázmechanizmusa megakadályozza a végtelen programhurkokat (a végrehajtás vagy sikeresen befejeződik, vagy a gázhiány miatt ér véget). + +A Hoare-logika segítségével létrehozott okosszerződés-specifikációk elő- és utófeltételekkel, valamint konstansokkal rendelkeznek a szerződésben szereplő függvények és ciklusok végrehajtásához. Az előfeltételek gyakran tartalmazzák egy függvény hibás bemeneteinek lehetőségét, az utófeltételek pedig leírják az ilyen bemenetekre várható választ (például megjelenik egy adott kivétel). Ily módon a Hoare-stílusú tulajdonságok hatékonyan biztosítják a szerződések megvalósításának helyességét. + +Számos formális ellenőrzési keretrendszer Hoare-stílusú specifikációkat használ a függvények szemantikai helyességének bizonyítására. Lehetőség van arra is, hogy a Hoare-stílusú tulajdonságokat (mint állításokat) közvetlenül a szerződéskódhoz adjuk hozzá a Solidity `require` és `assert` utasításokkal. + +A `require` utasítások előfeltételt vagy konstanst fejeznek ki, és gyakran használják a felhasználói bemenetek érvényesítésére, míg az `assert` a biztonsághoz szükséges utófeltételeket rögzíti. Például a függvények megfelelő hozzáférés-ellenőrzése (egy példa a biztonsági tulajdonságra) a `require` használatával érhető el, amely előfeltételként ellenőrzi a hívó fiók személyazonosságát. Hasonlóképpen, a szerződésben lévő státuszváltozók megengedett értékeire vonatkozó konstans (például a forgalomban lévő zsetonok teljes száma) védhető az `assert` használatával, hogy a függvény végrehajtása után igazoljuk a szerződés státuszát. + +### Nyomvonalszintű tulajdonságok {#trace-level-properties} + +A nyomvonalalapú specifikációk leírják a szerződés státuszváltozását biztosító műveleteket és az ezek közötti kapcsolatokat. Ahogy az korábban elhangzott, a nyomvonalak olyan műveletsorozatok, amelyek egy szerződés státuszát egy bizonyos módon változtatják meg. + +Ez a megközelítés az okosszerződések státuszváltozási rendszerként való modellezésére épül, előre meghatározott státuszokkal (amelyeket az státuszváltozók írnak le) és változásokkal (amelyeket a szerződésfüggvények írnak le). Továbbá egy [kontrollfolyamat-ábra (CFG)](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/), amely egy program végrehajtási folyamatának grafikus ábrázolása, gyakran használják a szerződés operációs szemantikájának leírására. Itt minden nyomvonal egy-egy útvonalként jelenik meg a kontrollfolyamat-ábrán. + +A nyomvonal-szintű specifikációkat elsősorban arra használják, hogy az okosszerződések belső végrehajtási mintáira következtessenek. A nyomvonal-szintű specifikációk létrehozásával biztosítják az okosszerződés végrehajtási útvonalait (azaz a státuszváltozásokat). Olyan technikák segítségével, mint a szimbolikus végrehajtás, formálisan ellenőrizhetjük, hogy a végrehajtás soha nem követ olyan utat, amely nem a formális modellben van definiálva. + +Vegyünk egy példát egy [DAO](/dao/) szerződésre, amely rendelkezik néhány nyilvánosan elérhető függvénnyel a nyomvonalszintű tulajdonságok leírására. Itt feltételezzük, hogy a DAO szerződés lehetővé teszi a felhasználók számára a következő műveletek végrehajtását: + +- Pénzeszközök letétbe helyezése + +- Pénzeszközök befizetése után szavazhat javaslatokról + +- Visszatérítést igényelhet, ha nem szavaz egy javaslatról + +A nyomvonalszintű tulajdonságok például a következők lehetnek: _„azok a felhasználók, akik nem fizetnek be pénzt, nem szavazhatnak egy javaslatról”_ vagy _„akik nem szavaznak egy javaslatról, mindig igényelhetnek visszatérítést”_. Mindkét tulajdonság a végrehajtás preferált sorrendjét érvényesíti (a szavazás nem történhet _előbb_, mint a pénzeszközök befizetése, és a visszatérítés igénylése nem történhet a javaslatról való szavazás _után_). + +## Az okosszerződések formális ellenőrzésének technikái {#formal-verification-techniques} + +### Modellellenőrzés {#model-checking} + +A modellellenőrzés egy olyan formális ellenőrzési technika, amelyben egy algoritmus egy okosszerződés formális modelljét ellenőrzi annak specifikációjával szemben. A modellellenőrzés során az okosszerződéseket gyakran státuszváltozási rendszerekként ábrázolják, míg a szerződés megengedett státuszaira vonatkozó tulajdonságokat időbeli logika segítségével határozzák meg. + +A modellellenőrzés egy rendszer absztrakt matematikai reprezentációjának (egy szerződésnek) a létrehozása és a rendszer tulajdonságainak kifejezése olyan formulák segítségével, amelyek az [üzleti logikában](https://www.baeldung.com/cs/propositional-logic) gyökereznek. Ez leegyszerűsíti a modellellenőrző algoritmus feladatát, nevezetesen annak bizonyítását, hogy egy matematikai modell kielégít-e egy adott logikai formulát. + +A modellellenőrzést a formális ellenőrzésben elsősorban a szerződés időbeli viselkedését leíró időbeli tulajdonságok értékelésére használják. Az okosszerződések időbeli tulajdonságai közé tartozik a _biztonság_ és az _elérhetőség_, amelyeket korábban már kifejtettünk. + +Például formális logikában leírható egy adott hozzáférés-szabályozással kapcsolatos biztonsági tulajdonság (pl. _kizárólag a szerződés tulajdonosa hívhatja meg a `selfdestruct` kódot_). Ezt követően a modellellenőrző algoritmus ellenőrizheti, hogy a szerződés megfelel-e ennek a formális specifikációnak. + +A modellellenőrzés státuszterek feltárását használja, amely magában foglalja az okosszerződés összes státuszának létrehozását, és megpróbálja megtalálni a tulajdonságokat megsértő státuszokat. Ez végtelen számú státuszhoz vezethet (az úgynevezett státuszrobbanás problémája), ezért a modellellenőrzők absztrakciós technikákra támaszkodnak, hogy hatékonyan elemezhessék az okosszerződéseket. + +### Tételbizonyítás {#theorem-proving} + +A tételbizonyítás a programok, köztük az okosszerződések helyességére vonatkozó matematikai érvelés módszere. Ez magában foglalja a szerződéses rendszer modelljének és specifikációinak matematikai formulákká (logikai kijelentésekké) történő átalakítását. + +A tételbizonyítás célja az állítások közötti logikai egyenértékűség igazolása. A „logikai egyenértékűség” (más néven logikai kettős következtetés) két állítás között az a kapcsolat, hogy az első állítás _akkor és csak akkor _ igaz, ha a második állítás igaz. + +A szerződés modelljére és tulajdonságára vonatkozó állítások közötti szükséges kapcsolatot (logikai egyenértékűséget) bizonyítható állításként (tételként) fogalmazzuk meg. Egy formális következtetési rendszer segítségével az automatizált tételvizsgáló képes ellenőrizni a tétel érvényességét. Más szóval, egy tételpróba meggyőzően bizonyítani tudja, hogy egy okosszerződés modellje pontosan megfelel a specifikációinak. + +Míg a modellellenőrzés a szerződéseket véges státuszváltozási rendszerekként modellezi, addig a tételbizonyítás végtelen státuszú rendszerek elemzését tudja kezelni. Ez azonban azt jelenti, hogy egy automatizált tételfelmérő nem mindig tudja, hogy egy logikai probléma „eldönthető” vagy sem. + +Ennek eredményeképpen gyakran emberi segítségre van szükség ahhoz, hogy a tételmegállapítót a helyességi bizonyítások levezetésében irányítani lehessen. A tételek bizonyítása emberi erőfeszítéssel drágább, mint modellellenőrzéssel, amely teljesen automatizált. + +### Szimbolikus végrehajtás {#symbolic-execution} + +A szimbolikus végrehajtás egy okosszerződést elemző módszer, amely a funkciókat _szimbolikus értékek_ (például `x > 5`) helyett _konkrét értékek_ (például `x == 5`) használatával hajtja végre. A szimbolikus végrehajtás egy olyan formális ellenőrzési technika, mellyel formálisan magyarázzák a szerződéskód nyomvonalszintű tulajdonságait. + +A szimbolikus végrehajtás egy végrehajtási nyomvonalat szimbolikus bemeneti értékek feletti matematikai képletként, más néven _útvonalállításként_ ábrázol. Egy [SMT megoldó](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) segítségével ellenőrizhetjük, hogy egy útvonalállítás „kielégíthető-e” (létezik-e olyan érték, amely kielégíti a formulát). Ha egy sérülékeny útvonal kielégíthető, az SMT megoldó egy konkrét értéket generál, amely a végrehajtást erre az útvonalra irányítja. + +Tegyük fel, hogy egy okosszerződés függvénye bemenetként egy `uint` értéket (`x`) fogad el, és akkor tér vissza, ha `x` nagyobb, mint `5` és kisebb, mint `10`. A hibát kiváltó `x` értékének megtalálása normál tesztelési eljárással több tucat teszteset (vagy még több) lefuttatását igényelné anélkül, hogy biztosan megtalálná a hibát. + +Ezzel szemben egy szimbolikus végrehajtó eszköz a függvényt a szimbolikus értékkel hajtaná végre: `X > 5 ∧ X < 10` (azaz `x` nagyobb, mint 5 ÉS `x` kisebb, mint 10). A kapcsolódó `x = X > 5 ∧ X < 10` útvonalállítást ezután egy SMT megoldónak adnánk megoldásra. Ha egy adott érték megfelel a `x = X > 5 ∧ X < 10` képletnek, az SMT megoldó kiszámítja azt – például a megoldó `7`-et adhat az `x` értékeként. + +Mivel a szimbolikus végrehajtás a program bemeneteire támaszkodik, ezek pedig végtelen számúak lehetnek az összes státusz feltárásához, ez még mindig a tesztelés egyik formája. Amint azonban a példa mutatja, a szimbolikus végrehajtás hatékonyabb a tulajdonságokat megsértő bemenetek megtalálásában, mint a rendszeres tesztelés. + +Ráadásul a szimbolikus végrehajtás kevesebb hamis pozitív eredményt produkál, mint más tulajdonságalapú technikák (például a fuzzing), amelyek véletlenszerűen generálják a függvénybemeneteket. Ha a szimbolikus végrehajtás során hiba lép fel, akkor lehetőség van a hibát kiváltó konkrét érték generálására és a probléma reprodukálására. + +A szimbolikus végrehajtás a helyesség bizonyos fokú matematikai bizonyítására is alkalmas. Tekintsük meg a következő példát egy túlcsordulás elleni védelemmel ellátott szerződésfüggvényre: + +``` +function safe_add(uint x, uint y) returns(uint z){ + + z = x + y; + require(z>=x); + require(z>=y); + + return z; +``` + +Egy egész szám túlcsordulását eredményező végrehajtási nyomvonalnak meg kell felelnie a képletnek: `z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y)`. Egy ilyen formula valószínűleg nem oldható meg, ezért matematikai bizonyítékul szolgál arra, hogy a `safe_add` függvény nem csordul túl. + +### Miért használjunk formális ellenőrzést az okosszerződésekhez? {#benefits-of-formal-verification} + +#### Megbízhatóság iránti igény {#need-for-reliability} + +A formális ellenőrzést olyan biztonságkritikus rendszerek helyességének értékelésére használják, amelyek meghibásodása pusztító következményekkel járhat, mint például halál, sérülés vagy pénzügyi csőd. Az okosszerződések nagy értékű alkalmazások, amelyek hatalmas értékeket irányítanak, és az egyszerű tervezési hibák [visszafordíthatatlan veszteségeket okozhatnak a felhasználóknak](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/). A szerződés formális ellenőrzése a telepítés előtt növelheti a garanciákat arra, hogy az a blokkláncon az elvárásoknak megfelelően fog működni. + +A megbízhatóság igen kívánatos tulajdonság bármely okosszerződésben, különösen azért, mert az Ethereum virtuális gépben (EVM) telepített kód alapvetően megváltoztathatatlan. Mivel a telepítés utáni frissítés nehezen megoldható, a szerződések megbízhatóságának garantálása szükségessé teszi a formális ellenőrzést. A formális ellenőrzés képes felderíteni az olyan trükkös problémákat, mint az egész számok alul- és túlcsordulása, az újbóli belépés és a rossz gázoptimalizálás, amelyek elkerülhetik az auditorok és a tesztelők figyelmét. + +#### Funkcionális helyesség bizonyítása {#prove-functional-correctness} + +A programtesztelés a leggyakoribb bizonyítási módszer arra, hogy egy okosszerződés megfelel-e bizonyos követelményeknek. Ez magában foglalja a szerződésvégrehajtást mintaadatokkal és a viselkedéselemzést. Ha a szerződés a mintaadatokra a várt eredményeket adja, akkor a fejlesztők objektív bizonyítékkal rendelkeznek a szerződés helyességéről. + +Ez a megközelítés azonban nem tudja bizonyítani a helyes végrehajtást a mintán kívüli értékek esetében. Ezért a szerződés tesztelése segíthet a hibák felderítésében (ha egyes kódútvonalak nem a kívánt eredményt adják a végrehajtáskor), de **nem tudja bizonyítani a hibák hiányát**. + +Ezzel szemben a formális ellenőrzés bebizonyíthatja, hogy egy okosszerződés végtelen számú végrehajtás esetén _megfelel a követelményeknek anélkül, hogy a szerződést lefuttatná_. Ehhez olyan formális specifikációt kell készíteni, amely pontosan leírja a szerződés helyes viselkedését, és ki kell dolgozni a rendszer formális (matematikai) modelljét. Ezután egy formális bizonyítási eljárást követve ellenőrizhetjük a szerződés modellje és a specifikáció közötti konzisztenciát. + +A formális ellenőrzésnél az egyik matematikai tétel, hogy egy szerződés üzleti logikája megfelel-e a követelményeknek, tehát bizonyítható vagy cáfolható. Egy tétel formális bizonyításával véges számú lépéssel végtelen számú tesztszcenáriót tudunk ellenőrizni. Ily módon a formális ellenőrzésnek jobbak az esélyei annak bizonyítására, hogy egy szerződés funkcionálisan helyes a specifikációhoz képest. + +#### Ideális ellenőrzési célok {#ideal-verification-targets} + +A ellenőrzési cél a formálisan ellenőrizendő rendszert írja le. A formális ellenőrzés leginkább akkor alkalmazható, ha „beágyazott rendszerekről” van szó (kis, egyszerű szoftverdarabokról, amelyek egy nagyobb rendszer részét képezik). Ideálisak a kevés szabállyal rendelkező speciális tartományok számára is, mivel így könnyebben módosíthatók a tartományspecifikus tulajdonságok ellenőrzési eszközei. + +Az okosszerződések bizonyos mértékig mindkét követelményt teljesítik. Az Ethereum-szerződések kis mérete például lehetővé teszi a formális ellenőrzést. Hasonlóképpen, az EVM egyszerű szabályokat követ, ami megkönnyíti a rajta futó programok szemantikai tulajdonságainak megadását és ellenőrzését. + +### Gyorsabb fejlesztési ciklus {#faster-development-cycle} + +A formális ellenőrzési technikák, például a modellellenőrzés és a szimbolikus végrehajtás általában hatékonyabbak, mint az okosszerződések kódjának (tesztelés vagy auditálás általi) rendszeres elemzése. Amiatt, mert a formális ellenőrzés szimbolikus értékekre támaszkodik az állítások teszteléséhez („mi van, ha egy felhasználó megpróbál _n_ ethert felvenni?”) ellentétben a teszteléssel, amely konkrét értékeket használ („mi van, ha egy felhasználó megpróbál 5 ethert kivenni?”). + +A szimbolikus bemeneti változók a konkrét értékek több osztályát is lefedhetik, így a formális ellenőrzés megközelítései rövidebb idő alatt nagyobb kódlefedettséget ígérnek. Hatékony használatnál a formális ellenőrzés felgyorsíthatja a fejlesztési ciklust. + +A formális ellenőrzés javítja a decentralizált alkalmazások (dapp) építésének folyamatát is, mivel csökkenti a költséges tervezési hibákat. A szerződések frissítése (ahol egyáltalán lehetséges) annak érdekében, hogy kijavítsák a sebezhetőségeket, a kódbázis átfogó átírását és több fejlesztési erőfeszítést igényel. A formális ellenőrzés számos olyan hibát felfedezhet a szerződések megvalósításában, amelyek elkerülhetik a tesztelők és auditorok figyelmét, így ezeket a problémákat még a bevezetés előtt kijavíthatják. + +## A formális ellenőrzés hátrányai {#drawbacks-of-formal-verification} + +### A manuális munka költsége {#cost-of-manual-labor} + +A formális ellenőrzés, különösen a félautomata verziója, amelyben egy ember irányítja a bizonyítót a helyességi bizonyítások levezetésében, jelentős manuális munkát igényel. Ráadásul a formális specifikáció készítése összetett tevékenység, amelyhez magas szintű szakértelem szükséges. + +Ezek a tényezők (erőfeszítés és szakértelem) a formális verifikációt igényesebbé és költségesebbé teszik a szerződések helyességét értékelő módszerekhez, például a teszteléshez és az auditáláshoz képest. Mindazonáltal a teljes hitelesítési audit kifizetése lényeges lehet, tekintettel az okosszerződések megvalósításában előforduló hibák költségeire. + +### Hamis negatív eredmények {#false-negatives} + +A formális ellenőrzés csak azt tudja ellenőrizni, hogy az okosszerződés végrehajtása megfelel-e a formális specifikációnak. Ezért fontos, hogy a specifikáció megfelelően leírja az okosszerződés elvárt viselkedését. + +Ha a specifikációk rosszul vannak megírva, a tulajdonságok megsértését – amelyek sebezhető végrehajtásokra utalnak – a formális ellenőrzés nem tudja felfedezni. Ebben az esetben a fejlesztő tévesen feltételezheti, hogy a szerződés hibamentes. + +### Teljesítményproblémák {#performance-issues} + +A formális ellenőrzés számos teljesítményproblémába ütközik. Például a modell- és a szimbolikus ellenőrzés során felmerülő státusz- és útvonalrobbanási problémák befolyásolhatják az ellenőrzési eljárásokat. Emellett a formális ellenőrzési eszközök gyakran használnak SMT és más korlátozó megoldókat a mögöttes rétegben, melyek számításigényes eljárásokra támaszkodnak. + +Emellett a programellenőrzők számára nem mindig lehetséges, hogy megállapítsák, egy (logikai képletként leírt) tulajdonság teljesülhet-e vagy sem ([meghatározhatósági probléma](https://en.wikipedia.org/wiki/Decision_problem)), mivel előfordulhat, hogy egy program soha nem ér véget. Mint ilyen, lehetetlen lehet bizonyítani egy szerződés bizonyos tulajdonságait, még akkor is, ha az jól specifikált. + +## Formális ellenőrzési eszközök az Ethereum-okosszerződésekhez {#formal-verification-tools} + +### Formális specifikációk létrehozására szolgáló specifikációs nyelvek {#specification-languages} + +**Act**: _*Az Act lehetővé teszi a tárolási frissítések, az elő- és utófeltételek és a szerződéskonstansok meghatározását. Eszközkészletének bizonyítási háttértárai is vannak, amelyek számos tulajdonságot képesek bizonyítani Coq, SMT megoldók vagy hevm segítségével.** + +- [GitHub](https://github.com/ethereum/act) +- [Dokumentáció](https://ethereum.github.io/act/) + +**Scribble** – _*A Scribble a Scribble specifikációs nyelvben szereplő kódmegjelöléseket konkrét állításokká alakítja, amelyek ellenőrzik a specifikációt.** + +- [Dokumentáció](https://docs.scribble.codes/) + +**Dafny** – _*A Dafny egy ellenőrzési programozási nyelv, amely magas szintű megjegyzésekre támaszkodik a kód helyességéről való gondolkodáshoz és annak bizonyításához.** + +- [GitHub](https://github.com/dafny-lang/dafny) + +### Programellenőrzők a helyesség vizsgálatára {#program-verifiers} + +**Certora Prover** – _Certora Prover egy automatikus formális ellenőrzőeszköz az okosszerződéskódok vizsgálatához. A specifikációkat CVL-en (Certora ellenőrzési nyelv) írják, a tulajdonságok megsértését statikus elemzés és kényszermegoldás kombinációjával detektálják._ + +- [Honlap](https://www.certora.com/) +- [Dokumentáció](https://docs.certora.com/en/latest/index.html) + +**Solidity SMTChecker** – _*A Solidity SMTChecker egy beépített modellellenőrző, amely SMT- (Satisfiability Modulo Theories) és Horn-megoldáson alapul. Megerősíti, hogy a szerződés forráskódja megfelel-e a specifikációknak az átfordítás során, és statikusan ellenőrzi a biztonsági tulajdonságok megsértését.** + +- [GitHub](https://github.com/ethereum/solidity) + +**solc-verify** – _*A solc-verify a Solidity fordító egy kiterjesztett változata, amely képes automatizált formális ellenőrzést végezni a Solidity kódon megjegyzések és moduláris programellenőrzés segítségével.** + +- [GitHub](https://github.com/SRI-CSL/solidity) + +**KEVM** - _*A KEVM a K keretrendszerben írt Ethereum virtuális gép (EVM) formális szemantikája. A KEVM futtatható, és képes bizonyos tulajdonságokkal kapcsolatos állítások bizonyítására az elérhetőségi logika segítségével.** + +- [GitHub](https://github.com/runtimeverification/evm-semantics) +- [Dokumentáció](https://jellopaper.org/) + +### Logikai keretek a tételbizonyításhoz {#theorem-provers} + +**Isabelle** – _Az Isabelle/HOL egy olyan bizonyítási segédprogram, amely lehetővé teszi matematikai formulák formális nyelven történő megfogalmazását, és eszközöket biztosít e formulák bizonyításához. Fő alkalmazási területe a matematikai bizonyítások formalizálása és különösen a formális ellenőrzés, amely magában foglalja a számítógépes hardver vagy szoftver helyességének bizonyítását, valamint a számítógépes nyelvek és protokollok tulajdonságainak bizonyítását._ + +- [GitHub](https://github.com/isabelle-prover) +- [Dokumentáció](https://isabelle.in.tum.de/documentation.html) + +**Coq** – _A Coq egy interaktív tételbizonyító, amely lehetővé teszi, hogy programokat definiáljon tételek segítségével, és interaktívan generálja a helyesség gépileg ellenőrzött bizonyítékait._ + +- [GitHub](https://github.com/coq/coq) +- [Dokumentáció](https://coq.github.io/doc/v8.13/refman/index.html) + +### Szimbolikus végrehajtáson alapuló eszközök az okosszerződések sebezhető mintáinak felderítésére {#symbolic-execution-tools} + +**Manticore** – _*Egy eszköz az EVM-bájtkódelemző eszköz vizsgálatára, amely szimbolikus végrehajtáson alapul.** + +- [GitHub](https://github.com/trailofbits/manticore) +- [Dokumentáció](https://github.com/trailofbits/manticore/wiki) + +**hevm** – _*a hevm egy szimbolikus végrehajtási motor és ekvivalencia-ellenőrző az EVM-bájtkódhoz.** + +- [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm) + +**Mythril** – _Egy szimbolikus végrehajtási eszköz az Ethereum-okosszerződések sebezhetőségének felderítésére_ + +- [GitHub](https://github.com/ConsenSys/mythril-classic) +- [Dokumentáció](https://mythril-classic.readthedocs.io/en/develop/) + +## További olvasnivaló {#further-reading} + +- [Hogyan működik az okosszerződések formális ellenőrzése](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) +- [Hogyan biztosíthatja a formális ellenőrzés a hibátlan okosszerződéseket](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) +- [Az Ethereum ökoszisztéma formális ellenőrzési projektjeinek áttekintése](https://github.com/leonardoalt/ethereum_formal_verification_overview) +- [Az Ethereum 2.0 letétbe helyezési okosszerződés formális ellenőrzése elejétől a végéig](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) +- [A világ legnépszerűbb okosszerződésének formális ellenőrzése](https://www.zellic.io/blog/formal-verification-weth) +- [SMTChecker és formális ellenőrzés](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html) diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" new file mode 100644 index 00000000000..18fa6d86692 --- /dev/null +++ "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" @@ -0,0 +1,308 @@ +--- +title: Okos szerződések tesztelése +description: Az Ethereum okosszerződés-tesztelési technikáinak és szempontjainak áttekintése. +lang: hu +--- + +Az Ethereumhoz hasonló nyilvános blokkláncok megváltoztathatatlanok, ami megnehezíti az okosszerződések kódjának módosítását a telepítésük után. [Léteznek szerződésfrissítési minták](/developers/docs/smart-contracts/upgrading/) a „virtuális frissítések” végrehajtására, de ezeket nehéz megvalósítani, és társadalmi konszenzust igényelnek. Ráadásul a frissítés csak a hiba _felfedezése után_ javíthatja ki azt – ha egy támadó előbb fedezi fel a sebezhetőséget, akkor az okosszerződést veszély fenyegeti. + +Ezen okok miatt az okosszerződések tesztelése a fő hálózatra való [telepítés](/developers/docs/smart-contracts/deploying/) előtt elengedhetetlen a [biztonság](/developers/docs/smart-contracts/security/) szempontjából. A szerződések tesztelésére és a kód helyességének kiértékelésére számos technika létezik; a fejlesztő igényeitől függ, hogy melyiket választja. Mindazonáltal egy különböző eszközökből és megközelítésekből álló tesztcsomag ideális a szerződéskód kisebb és nagyobb biztonsági hibáinak kiszűrésére. + +## Előfeltételek {#prerequisites} + +Ez az oldal elmagyarázza, hogyan lehet tesztelni az okosszerződéseket az Ethereum-hálózaton való telepítés előtt. Feltételezi, hogy ismeri az [okosszerződéseket](/developers/docs/smart-contracts/). + +## Mi az az okosszerződés-tesztelés? {#what-is-smart-contract-testing} + +Az okosszerződések tesztelése annak ellenőrzése, hogy a szerződés kódja az elvárásoknak megfelelően működik-e. A tesztelés egy hasznos ellenőrzés, hogy az adott okosszerződés megfelel-e a megbízhatósági, használhatósági és biztonsági követelményeknek. + +Bár a megközelítések eltérők, a legtöbb tesztelési módszerhez az okosszerződést végre kell hajtani a kezelendő adatok egy kis mintájával. Ha a szerződés helyes eredményeket ad a mintaadatokra, akkor feltételezhetően megfelelően működik. A legtöbb tesztelési eszköz forrásokat biztosít a [tesztszcenáriók](https://en.m.wikipedia.org/wiki/Test_case) megírásához és végrehajtásához, amelyekkel ellenőrizni lehet, hogy a szerződések végrehajtása megfelel-e a várt eredményeknek. + +### Miért fontos az okosszerződések tesztelése? {#importance-of-testing-smart-contracts} + +Mivel az okosszerződések gyakran nagy értékű pénzügyi eszközöket kezelnek, a kisebb programozási hibák [nagy veszteségeket okozhatnak a felhasználóknak](https://rekt.news/leaderboard/). A szigorú tesztelés segíthet abban, hogy az okosszerződés kódjában lévő hibákat és problémákat időben felfedezze és a fő hálózaton való elindítás előtt kijavítsa. + +Bár van lehetőség a szerződés frissítésére, ha hibát fedeztek fel, a frissítések összetettek, és [hibákhoz vezethetnek](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/), ha nem megfelelően kezelik őket. A szerződés frissítése ellentmond a megváltoztathatatlanság elvének, és bizalmat igényel a felhasználóktól. Ezzel szemben az átfogó tesztelési terv csökkenti az okosszerződések biztonsági kockázatait, és a telepítés utáni komplex logikai frissítések szükségességét. + +## Az okosszerződések tesztelésének módszerei {#methods-for-testing-smart-contracts} + +Az Ethereum okosszerződések tesztelési módszerei két nagy kategóriába sorolhatók: **automatizált** és **manuális tesztelés**. Az automatizált és a manuális tesztelés egyedi előnyökkel és kompromisszumokkal jár, de mindkettőt kombinálhatja, hogy megbízható tervet hozzon létre a szerződések vizsgálatához. + +### Automatizált tesztelés {#automated-testing} + +Az automatizált tesztelés olyan eszközöket használ, amelyek automatikusan ellenőrzik az okosszerződések kódját a végrehajtási hibák szempontjából. Az automatizált tesztelés előnye a [szkriptek](https://www.techtarget.com/whatis/definition/script?amp=1) használatából származik, amelyek a szerződéses funkciók értékelését irányítják. A szkriptelt teszteket úgy lehet ütemezni, hogy minimális emberi beavatkozással ismételten fussanak, így az automatizált tesztelés hatékonyabb, mint a manuális megközelítés. + +Az automatizált tesztelés különösen akkor hasznos, ha a tesztek ismétlődők és időigényesek, manuálisan nehezen kivitelezhetők, emberi hibára hajlamosak, vagy kritikus szerződéses funkciók értékelését végzik. Ezeknek is megvannak hátrányai, mert bizonyos hibákat kihagyhatnak, és számos [hamis pozitív eredményt](https://www.contrastsecurity.com/glossary/false-positive) produkálhatnak. Ezért az okosszerződések esetében az automatizált és a manuális tesztelés párosítása az ideális. + +### Manuális tesztelés {#manual-testing} + +A manuális tesztelést ember végzi, és az okosszerződések helyességének elemzése során a tesztcsomag minden egyes tesztszcenárióját egymás után hajtja végre. Ez ellentétben áll az automatizált teszteléssel, ahol egyszerre több izolált tesztet futtathat egy szerződésen, és egy olyan jelentést kaphat, amely megmutatja az összes sikertelen és sikeres tesztet. + +A manuális tesztelést egyetlen személy is elvégezheti egy írásos teszttervet követve, amely különböző tesztszcenáriókra terjed ki. A manuális tesztelés részeként több személy vagy csoport is interakcióba léphet az okosszerződéssel egy meghatározott időszak alatt. A tesztelők összehasonlítják a szerződés tényleges és elvárt viselkedését, és minden eltérést hibaként jelölnek meg. + +A hatékony manuális tesztelés jelentős erőforrásokat igényel (szakértelem, idő, pénz és erőfeszítés), és lehetséges, hogy emberi hiba miatt a tesztek végrehajtása során bizonyos hibák nem derülnek ki. A manuális tesztelés előnyös is lehet – egy ember (például egy auditor) felismerhet olyan valós helyzeteket, amelyeket egy automatizált tesztelőeszköz kihagyna. + +## Automatizált tesztelés okosszerződésekhez {#automated-testing-for-smart-contracts} + +### Egységtesztelés {#unit-testing-for-smart-contracts} + +Az egységtesztelés külön-külön értékeli a szerződés funkcióit, és ellenőrzi, hogy minden egyes komponens megfelelően működik-e. A jó egységteszteknek egyszerűnek és gyorsan lefuttathatónak kell lenniük, és ha a teszt nem a várt eredményt adja, akkor világos képet kell adniuk arról, hogy mi a hiba. + +Az egységtesztek hasznosak annak ellenőrzésére, hogy a függvények visszaadják-e a várt értékeket, és hogy a szerződés adattárhelye megfelelően frissül-e a végrehajtás során. Továbbá a szerződések kódbázisának módosítása után az egységtesztek biztosítják, hogy az új logika hozzáadása ne okozzon hibákat. Az alábbiakban bemutatjuk a hatékony egységtesztek futtatását: + +#### Irányelvek az okosszerződések egységteszteléséhez {#unit-testing-guidelines} + +##### 1. A szerződések üzleti logikájának és munkafolyamatának megértése + +Az egységtesztek megírása előtt hasznos tudni, hogy milyen funkciókat kínál egy okosszerződés, és hogy a felhasználók hogyan fogják elérni és használni ezeket a funkciókat. Ez különösen hasznos a [boldog út (happy path) tesztek](https://en.m.wikipedia.org/wiki/Happy_path) futtatásához, amelyek meghatározzák, hogy a szerződésben szereplő függvények a helyes kimenetet adják-e vissza érvényes felhasználói bemenetek esetén. Ezt a koncepciót az [aukciós szerződés](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction) rövidített példáján keresztül magyarázzuk el + +``` +constructor( + uint biddingTime, + address payable beneficiaryAddress + ) { + beneficiary = beneficiaryAddress; + auctionEndTime = block.timestamp + biddingTime; + } + +function bid() external payable { + + if (block.timestamp > auctionEndTime) + revert AuctionAlreadyEnded(); + + if (msg.value <= highestBid) + revert BidNotHighEnough(highestBid); + + if (highestBid != 0) { + pendingReturns[highestBidder] += highestBid; + } + highestBidder = msg.sender; + highestBid = msg.value; + emit HighestBidIncreased(msg.sender, msg.value); + } + + function withdraw() external returns (bool) { + uint amount = pendingReturns[msg.sender]; + if (amount > 0) { + pendingReturns[msg.sender] = 0; + + if (!payable(msg.sender).send(amount)) { + pendingReturns[msg.sender] = amount; + return false; + } + } + return true; + } + +function auctionEnd() external { + if (block.timestamp < auctionEndTime) + revert AuctionNotYetEnded(); + if (ended) + revert AuctionEndAlreadyCalled(); + + ended = true; + emit AuctionEnded(highestBidder, highestBid); + + beneficiary.transfer(highestBid); + } +} +``` + +Ez egy egyszerű aukciós szerződés, amelynek célja, hogy a licitidőszak alatt ajánlatokat fogadjon. Ha a `highestBid` (legmagasabb ajánlat) emelkedik, az előző legmagasabb ajánlatot tevő kapja meg a pénzét; ha a licitidőszak véget ér, a `beneficiary` (kedvezményezett) meghívja a szerződést, hogy megkapja a pénzt. + +Egy ilyen szerződés egységtesztjei lefedik a különböző funkciókat, amelyeket a felhasználó meghívhat a szerződés használata során. Ilyen például egy olyan egységteszt, amely ellenőrzi, hogy a felhasználó tud-e licitálni, miközben az aukció folyamatban van (azaz a `bid()` meghívása sikeres), vagy egy olyan, amely ellenőrzi, hogy a felhasználó tud-e magasabb licitet tenni, mint az aktuális `highestBid` (legmagasabb ajánlat). + +A szerződés működési folyamatának megértése segít az egységtesztek megírásában, amelyek ellenőrzik, hogy a végrehajtás megfelel-e a követelményeknek. Az aukciós szerződés például előírja, hogy a felhasználók nem tehetnek ajánlatot, ha az aukció már véget ért (azaz ha az `auctionEndTime` alacsonyabb, mint a `block.timestamp`). Így a fejlesztő futtathat egy olyan egységtesztet, amely ellenőrzi, hogy a `bid()` függvény hívása sikeres vagy sikertelen, amikor az aukció véget ér (amikor `auctionEndTime` > `block.timestamp`). + +##### 2. A szerződés teljesítésével kapcsolatos feltételezések értékelése + +Fontos dokumentálni a szerződés végrehajtásával kapcsolatos feltételezéseket, és egységteszteket írni azok érvényességének ellenőrzésére. Amellett, hogy védelmet nyújt a nem várt végrehajtás ellen, az állítások tesztelése arra készteti a fejlesztőt, hogy átgondolja azokat a műveleteket, amelyek megtörhetik az okosszerződések biztonsági modelljét. Hasznos tipp, hogy a „boldog felhasználói teszteken” túlmenően írjunk negatív teszteket, amelyek ellenőrzik, hogy egy függvény rossz bemenetek esetén nem működik-e. + +Sok egységtesztelési keretrendszer lehetővé teszi, hogy állításokat hozzon létre – azaz egyszerű kijelentéseket, amelyek meghatározzák, hogy egy szerződés mit tehet és mit nem –, és teszteket futtasson, hogy lássa, ezek az állítások érvényesek-e a végrehajtás során. Egy fejlesztő, aki a korábban leírt aukciós szerződésen dolgozik, a negatív tesztek lefuttatása előtt a következő állításokat teheti a szerződés viselkedéséről: + +- A felhasználók nem tehetnek ajánlatot, ha az aukció már véget ért vagy még el sem kezdődött. + +- Az aukciós szerződés visszalép, ha egy ajánlat az elfogadható küszöbérték alatt van. + +- Azoknak a felhasználóknak, akik nem nyerik meg a licitet, jóváírják a pénzüket + +**Megjegyzés**: A feltételezések tesztelésének egy másik módja, hogy olyan teszteket írunk, amelyek a szerződésben [függvénymódosítókat](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) váltanak ki, különös tekintettel a `require`, `assert` és `if... else` utasításokra. + +##### 3. Kódlefedettség mérése + +A [kódlefedettség](https://en.m.wikipedia.org/wiki/Code_coverage) egy tesztelési metrika, amely a tesztek során végrehajtott ágak, sorok és utasítások számát követi a kódban. A teszteknek jó kódlefedettséggel kell rendelkezniük, különben előfordulhat, hogy „hamis negatív eredményt” kapunk, amikor a szerződés átmegy az összes teszten, de a kódban még vannak sebezhetőségek. A magas kódlefedettség rögzítése biztosítékot ad arra, hogy az okosszerződésben szereplő összes utasítást/függvényt megfelelően tesztelték a helyesség szempontjából. + +##### 4. Jól kidolgozott tesztelési keretrendszerek használata + +Az okosszerződések egységtesztjeinek futtatásához használt eszközök minősége kulcsfontosságú. Az ideális tesztelési keretrendszert rendszeresen karbantartják, hasznos funkciókat biztosít (például naplózási és jelentéstételi képességek), és más fejlesztők már széles körben használták és vizsgálták. + +A Solidity okosszerződések egységtesztelési keretrendszerei különböző nyelveken (főként JavaScript, Python és Rust) készülnek. Az alábbi útmutatókból tájékozódhat arról, hogyan kezdheti el a tesztelési keretrendszerekkel az egységtesztek futtatását: + +- **[Egységtesztek futtatása a Brownie segítségével](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** +- **[Egységtesztek futtatása a Foundry segítségével](https://book.getfoundry.sh/forge/writing-tests)** +- **[Egységtesztek futtatása a Waffle segítségével](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)** +- **[Egységtesztek futtatása a Remix segítségével](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)** +- **[Egységtesztek futtatása az Ape segítségével](https://docs.apeworx.io/ape/stable/userguides/testing.html)** +- **[Egységtesztek futtatása a Hardhat segítségével](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** +- **[Egységtesztek futtatása a Wake segítségével](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** + +### Integrációs tesztelés {#integration-testing-for-smart-contracts} + +Míg az egységtesztelés a szerződés funkcióit elszigetelten vizsgálja, az integrációs tesztek az okosszerződés összetevőit egészében értékelik. Az integrációs teszteléssel felderíthetők azok a problémák, melyek a szerződésközi meghívásokból vagy az okosszerződés különböző függvényei közötti kölcsönhatásokból erednek. Az integrációs tesztek például segíthetnek ellenőrizni, hogy az olyan dolgok, mint az [öröklődés](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) és a függőségi befecskendezésnek megfelelően működnek-e. + +Az integrációs tesztelés akkor hasznos, ha a szerződés moduláris architektúrát alkalmaz, vagy ha a végrehajtás során más láncon belüli szerződésekhez kapcsolódik. Az integrációs tesztek futtatásának egyik módja, hogy [elágaztatja (fork) a blokkláncot](/glossary/#fork) egy adott magasságban (egy olyan eszközzel, mint a [Forge](https://book.getfoundry.sh/forge/fork-testing) vagy a [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks), és szimulálja a szerződése és a telepített szerződések közötti kölcsönhatásokat. + +Az elágaztatott blokklánc a fő hálózathoz hasonlóan viselkedik, és számlák vannak rajta a megfelelő státuszokkal és egyenlegekkel. De ez csak egy helyi fejlesztőkörnyezet, tehát a tranzakciókhoz nincs szükség valódi ETH-re, és a változtatások nem befolyásolják a valódi Ethereum-protokollt. + +### Tulajdonságalapú tesztelés {#property-based-testing-for-smart-contracts} + +A tulajdonságalapú tesztelés annak ellenőrzése, hogy egy okosszerződés megfelel-e valamilyen meghatározott tulajdonságnak. A tulajdonságok olyan tényeket állítanak a szerződés viselkedéséről, amelyek várhatóan különböző forgatókönyvek esetén is igazak maradnak. Egy adott okosszerződés tulajdonsága például a következő: „A szerződésben szereplő aritmetikai műveletekre nem jellemző a túlcsordulás vagy alulcsordulás.” + +A **statikus** és a **dinamikus elemzés** két gyakori technika a tulajdonságalapú tesztelésre, és mindkettő képes ellenőrizni, hogy egy program (jelen esetben egy okosszerződés) kódja megfelel-e valamilyen előre meghatározott tulajdonságnak. Egyes tulajdonságalapú tesztelési eszközök előre meghatározott szabályokat tartalmaznak a szerződés várható tulajdonságairól, és a kódot ezek alapján ellenőrzik, míg mások lehetővé teszik, hogy egyéni tulajdonságokat hozzon létre az okosszerződéshez. + +#### Statikus elemzés {#static-analysis} + +A statikus elemzés bemenetként egy okosszerződés forráskódját veszi, és olyan eredményeket ad ki, amelyek kijelentik, hogy a szerződés megfelel-e egy tulajdonságnak vagy sem. A dinamikus elemzéssel ellentétben a statikus elemzés nem foglalja magában a szerződés végrehajtását, hogy megvizsgálja annak helyességét. A statikus elemzés az összes lehetséges útvonalat megvizsgálja, amelyet egy okosszerződés a végrehajtás során bejárhat (azaz a forráskód szerkezetét vizsgálja, hogy az mit jelentene a szerződések működése kapcsán a futtatásakor). + +A [linting](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) és a [statikus tesztelés](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) a szerződések statikus elemzésének általános módszerei. Mindkettő a szerződésvégrehajtás olyan alacsony szintű reprezentációinak elemzését igényli, mint az átfordító által adott [absztrakt szintaxisfák](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) és [kontrollfolyamat-ábrák](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/). + +A legtöbb esetben a statikus elemzés hasznos a biztonsági problémák, például a nem biztonságos konstrukciók, szintaktikai hibák vagy a kódolási szabványok megsértésének felderítésére a kódban. A statikus elemzésről azonban köztudott, hogy nem alkalmasak a mélyebb sebezhetőségek felderítésére, és sok hamis pozitív eredményt produkálhatnak. + +#### Dinamikus elemzés {#dynamic-analysis} + +A dinamikus elemzés szimbolikus bemeneteket (például [szimbolikus végrehajtásnál](https://en.m.wikipedia.org/wiki/Symbolic_execution)) vagy konkrét bemeneteket (például [fuzzing](https://owasp.org/www-community/Fuzzing) esetén) generál egy okosszerződés-függvényhez, hogy vajon egy végrehajtási nyom sért-e bizonyos tulajdonságokat. A tulajdonságalapú tesztelésnek ez a formája abban különbözik az egységtesztektől, hogy a tesztesetek több szcenárióra terjednek ki, és egy program kezeli a tesztesetek generálását. + +A [fuzzing](https://halborn.com/what-is-fuzz-testing-fuzzing/) az egyik dinamikus elemzési technika, amellyel az okosszerződések tetszőleges tulajdonságait lehet ellenőrizni. A fuzzer a célszerződésben lévő függvényeket egy meghatározott bemeneti érték véletlenszerű vagy hibás variációival hívja meg. Ha az okosszerződés hibás állapotba kerül (például egy állítás sikertelen), a problémát megjelöli, és a sérülékeny útvonalat mutató bemenetek egy jelentésben jelennek meg. + +A fuzzing hasznos az okosszerződések bemenetérvényesítési mechanizmusának értékeléséhez, mivel a váratlan bemenetek nem megfelelő kezelése eredményezhet nem szándékos végrehajtást és veszélyes hatásokat is. A tulajdonságalapú tesztelésnek ez a formája több okból is ideális lehet: + +1. **Nehéz olyan tesztszcenáriókat írni, amelyek sok szcenáriót lefednek.** A tulajdonságteszthez csak egy viselkedést és egy adattartományt kell definiálnia, amellyel a viselkedést tesztelni kívánja – a program automatikusan teszteseteket generál a megadott tulajdonság alapján. + +2. **A tesztcsomag nem feltétlenül fed le minden lehetséges útvonalat a programon belül.** Még 100%-os lefedettség esetén is lehetséges, hogy kihagyja az éles eseteket. + +3. **Az egységtesztek bizonyítják, hogy a szerződés helyesen kerül végrehajtásra a mintaadatokra, az viszont ismeretlen marad, hogy helyes-e a mintán kívüli bemenetekre.** A tulajdonságtesztek egy adott bemeneti érték több variációjával hajtják végre a célszerződést, hogy megtalálják az állításhibákat okozó végrehajtási nyomokat. Így a tulajdonságteszt több garanciát nyújt arra, hogy a szerződés helyesen kerül végrehajtásra a bemeneti adatok nagyobb osztálya esetén. + +### Irányelvek az okosszerződések tulajdonságalapú tesztelésének futtatásához {#running-property-based-tests} + +A tulajdonságalapú tesztelés futtatása általában egy tulajdonság (például [egész számok túlcsordulásának](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow) hiánya) vagy tulajdonságok gyűjteményének meghatározásával kezdődik, amelyet egy okosszerződésben ellenőrizni szeretne. A tulajdonságtesztek írásakor szükség lehet egy olyan értéktartomány meghatározására is, amelyen belül a program adatokat generálhat a tranzakciós bemenetekhez. + +A megfelelő konfigurálás után a tulajdonságtesztelő eszköz véletlenszerűen generált bemenetekkel hajtja végre az okosszerződések funkcióit. Ha az állítások sérülnek, akkor a fejlesztő egy jelentést kap a konkrét bemeneti adatokkal, amelyek sértik az értékelt tulajdonságot. Tekintse meg az alábbi útmutatókat, hogy elkezdhesse a tulajdonságalapú tesztelést különböző eszközökkel: + +- **[Okosszerződések statikus elemzése a Slither segítségével](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither#slither)** +- **[Okosszerződések statikus elemzése a Wake segítségével](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** +- **[Tulajdonságalapú tesztelés a Brownie segítségével](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** +- **[Fuzzing szerződések a Foundry segítségével](https://book.getfoundry.sh/forge/fuzz-testing)** +- **[Fuzzing szerződések a Echidna segítségével](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** +- **[Fuzzing szerződések a Wake segítségével](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)** +- **[Okosszerződések szimbolikus végrehajtása a Manticore segítségével](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)** +- **[Okosszerződések szimbolikus végrehajtása a Mythril segítségével](https://mythril-classic.readthedocs.io/en/master/tutorial.html)** + +## Okosszerződések manuális tesztelése {#manual-testing-for-smart-contracts} + +Az okosszerződések manuális tesztelése gyakran a fejlesztési ciklus későbbi szakaszában, az automatizált tesztek lefuttatása után történik. A tesztelés ezen formája az okosszerződést egy teljesen integrált termékként értékeli, hogy kiderüljön, a műszaki követelményekben meghatározottak szerint teljesít-e. + +### Szerződések tesztelése helyi blokkláncon {#testing-on-local-blockchain} + +Míg a helyi fejlesztői környezetben végzett automatizált tesztelés hasznos hibakeresési információkkal szolgálhat, a fejlesztő azt is tudni szeretné, hogyan viselkedik az okosszerződése éles környezetben. A fő Ethereum-láncra való telepítés gázdíjakkal jár – arról nem is beszélve, hogy a fejlesztő vagy a felhasználók valódi pénzt veszíthetnek, ha az okosszerződés hibás. + +A szerződés tesztelését egy helyi blokkláncon ([fejlesztői hálózaton](/developers/docs/development-networks/)) ajánlott elvégezni a fő hálózat helyett. A helyi blokklánc az Ethereum egy olyan másolata, amely lokálisan fut a számítógépen, és amely a végrehajtási réteg viselkedését szimulálja. Így jelentős többletköltségek nélkül programozhat tranzakciókat a szerződéssel való interakcióra. + +A szerződések futtatása egy helyi blokkláncon hasznos lehet a manuális integrációs tesztelés egyik formájaként. [Az okosszerződések nagymértékben modulárisak](/developers/docs/smart-contracts/composability/), lehetővé téve a meglévő protokollokkal való integrációt, de továbbra is biztosítani kell, hogy az ilyen összetett láncon belüli kölcsönhatások a megfelelő eredményeket hozzák. + +[További információk a fejlesztői hálózatokról.](/developers/docs/development-networks/) + +### Szerződések tesztelése a teszthálózatokon {#testing-contracts-on-testnets} + +A teszthálózat pontosan úgy működik, mint az Ethereum fő hálózat, azzal a különbséggel, hogy a használt ethernek (ETH) nincs valós értéke. Ha a szerződést egy [teszthálózatra](/developers/docs/networks/#ethereum-testnets) telepíti, akkor bárki kapcsolatba léphet azzal (például a dapp felületén keresztül) anélkül, hogy pénzeszközt kockáztatna. + +A manuális tesztelés ezen formája hasznos az alkalmazás teljes folyamatának kiértékeléséhez a felhasználó szemszögéből. Itt a béta tesztelők próbafuttatásokat is végezhetnek, és jelenthetik a szerződés üzleti logikájával és általános funkcionalitásával kapcsolatos problémákat. + +A teszthálózatra való telepítés a helyi blokkláncon való tesztelés után ideális, mivel az előbbi közelebb áll az Ethereum virtuális gépének viselkedéséhez. Ezért számos Ethereum-projektben gyakori, hogy a dappokat teszthálózatokra telepítik, hogy valós körülmények között értékeljék az okosszerződések működését. + +[Bővebben az Ethereum teszthálózatokról.](/developers/docs/development-networks/#public-beacon-testchains) + +## A tesztelés és a formális ellenőrzés összehasonlítása {#testing-vs-formal-verification} + +Miközben a tesztelés segít annak megerősítésében, hogy a szerződés bizonyos bemeneti adatok esetében a várt eredményeket adja vissza, a nem használt bemeneti adatok esetében ugyanezt nem tudja egyértelműen bizonyítani. Az okosszerződés tesztelése nem garantálhatja a „funkcionális helyességet” (nem mutathatja meg, hogy a program _minden_ bemeneti értékre az előírt módon viselkedik-e). + +A formális ellenőrzés a szoftver helyességét vizsgálja, hogy a program formális modellje megfelel-e a formális specifikációnak. A formális modell egy program absztrakt matematikai reprezentációja, míg a formális specifikáció a program tulajdonságait (a végrehajtással kapcsolatos logikai állításokat) határozza meg. + +Mivel a tulajdonságok matematikai kifejezésekben vannak leírva, logikai következtetési szabályok segítségével ellenőrizhetővé válik, hogy a rendszer formális (matematikai) modellje megfelel-e a specifikációnak. Ezért azt mondják, hogy a formális verifikációs eszközök „matematikai bizonyítékot” állítanak elő egy rendszer helyességéről. + +A teszteléssel ellentétben a formális ellenőrzés használható arra, hogy egy okosszerződés végrehajtása megfelel-e a formális specifikációnak _minden_ végrehajtás esetén (nincs benne hiba), anélkül hogy mintaadatokkal kellene végrehajtani. Ez nem csak a több tucatnyi egységteszt futtatására fordított időt csökkenti, de hatékonyabb a rejtett sebezhetőségek felderítésében is. Ennek ellenére a formális ellenőrzési technikák haszna a megvalósítás nehézségétől és hasznosságától függ. + +[További információ az okosszerződések formális ellenőrzéséről.](/developers/docs/smart-contracts/formal-verification) + +## A tesztelés, illetve auditok és hibavadászatok összehasonlítása {#testing-vs-audits-bug-bounties} + +A szigorú tesztelés ritkán tudja garantálni, hogy egy szerződésben nincsenek hibák; a formális ellenőrzési módszerek erősebb biztosítékot nyújthatnak a helyességre, de nehéz ezeket alkalmazni, és jelentős költségekkel járnak. + +Mégis tovább növelheti a szerződéses sebezhetőségek felfedezésének lehetőségét, ha független kódellenőrzést végeztet. Az [okosszerződésaudit](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) és a [hibavadászat](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) két olyan módszer, amelynek révén mások is elemzik a szerződéseket. + +Az auditokat olyan auditorok végzik, akik tapasztaltak az okosszerződések biztonsági hibáinak és helytelen fejlesztési gyakorlatainak felderítésében. Az audit általában magában foglalja a tesztelést (és esetleg a formális ellenőrzést), valamint a teljes kódbázis manuális felülvizsgálatát. + +Ezzel szemben a hibavadász-program általában pénzjutalom felajánlását jelenti olyan személyeknek (általában [fehér kalapos hackereknek](https://en.wikipedia.org/wiki/White_hat_(computer_security))), akik felfedezik az okosszerződés sebezhetőségét és feltárják azt a fejlesztők előtt. A hibavadászatok hasonlítanak az auditokhoz, mivel mások segítségét kérik az okosszerződések hibáinak megtalálásában. + +A fő különbség az, hogy a hibavadász-programok nyitottak a szélesebb fejlesztői/hackerközösség számára, és etikus hackerek és független biztonsági szakemberek széles rétegét vonzzák, akik egyedi készségekkel és tapasztalattal rendelkeznek. Ez előnyt jelenthet az olyan okosszerződések ellenőrzésével szemben, amelyek főként olyan csapatokra támaszkodnak, akik korlátozott szakértelemmel rendelkezhetnek. + +## Tesztelőeszközök és könyvtárak {#testing-tools-and-libraries} + +### Egységtesztelési eszközök {#unit-testing-tools} + +- **[Solidity-coverage](https://github.com/sc-forks/solidity-coverage)** – _Kódlefedettségi eszköz Solidity nyelven írt okosszerződésekhez._ + +- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** – _Keretrendszer fejlett okosszerződések fejlesztéséhez és teszteléséhez (ethers.js-alapú)_. + +- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** – _Eszköz a Solidity okosszerződések teszteléséhez. A Remix IDE „Solidity Unit Testing” plugin alatt működik, amely a szerződéshez tartozó tesztek írására és futtatására szolgál._ + +- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** – _Állításkönyvtár az Ethereum okosszerződések teszteléséhez. Győződjön meg arról, hogy a szerződései az elvárt módon viselkednek!_ + +- **[Brownie unit testing framework](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** – _A Brownie a Pytest-et használja, amely egy funkciógazdag tesztelési keretrendszert, és amely lehetővé teszi kis tesztek írását minimális kóddal, jól skálázható nagyobb projektekhez és nagymértékben bővíthető._ + +- **[Foundry Tests](https://github.com/foundry-rs/foundry/tree/master/forge)** – _A Foundry a Forge megoldást kínálja, amely egy gyors és rugalmas Ethereum tesztelési keretrendszert, és amely képes egyszerű egységtesztek, gázoptimalizálási ellenőrzések és szerződés fuzzing végrehajtására._ + +- **[Hardhat Tests](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** – _Keretrendszer az ethers.js, Mocha és Chai alapú okosszerződések tesztelésére._ + +- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** – _Python-alapú fejlesztési és tesztelési keretrendszer az Ethereum virtuális gépen működő okosszerződésekhez._ + +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _Python-alapú keretrendszer az egységtesztelésre és fuzzingra erős hibakeresési képességekkel és láncok közötti teszttámogatással, mely a pytest és az Anvil használatával jó felhasználói élményt és teljesítményt biztosít._ + +### Tulajdonságalapú tesztelőeszközök {#property-based-testing-tools} + +#### Statikus elemzőeszközök {#static-analysis-tools} + +- **[Slither](https://github.com/crytic/slither)** – _Python-alapú Solidity statikus elemzési keretrendszer a sebezhetőségek felkutatására, a kódérthetőség javítására és az okosszerződések egyéni elemzésére._ + +- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** – _Linter a stílusra és biztonságra vonatkozó bevált gyakorlatok érvényesítésére a Solidity okosszerződések programozási nyelvéhez._ + +- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** – _Rust-alapú statikus elemző, amelyet kifejezetten a web3 okosszerződések biztonságához és fejlesztéséhez terveztek._ + +- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _Python-alapú statikus elemzési keretrendszer sebezhetőségi és kódminőségi ellenőrzéssel, a printer minden hasznos információt kiszed a kódból és támogatja a személyre szabott almodulok készítését._ + +#### Dinamikus elemzőeszközök {#dynamic-analysis-tools} + +- **[Echidna](https://github.com/crytic/echidna/)** – _Gyors szerződésfuzzer az okosszerződések sebezhetőségének felderítésére tulajdonságalapú teszteléssel._ + +- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** – _Automatizált fuzzing eszköz, amely hasznos a tulajdonságok megsértésének észlelésére az okosszerződés kódjában._ + +- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** – _Dinamikus szimbolikus végrehajtási keretrendszer az EVM-bájtkód elemzésére._ + +- **[Mythril](https://github.com/ConsenSys/mythril-classic)** – _EVM-bájtkódértékelő eszköz a szerződéses sebezhetőségek felderítésére szennyeződéselemzés, dinamikus szimbolikus (concolic) elemzés és a kontrollfolyamat ellenőrzésének segítségével._ + +- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** – _A Scribble egy specifikációs nyelv és futásidejű ellenőrzési eszköz, amely lehetővé teszi, hogy az okosszerződésekre olyan tulajdonságokat jegyezzen fel, amelyek lehetővé teszik a szerződések automatikus tesztelését olyan eszközökkel, mint a Diligence Fuzzing vagy a MythX._ + +## Kapcsolódó útmutatók {#related-tutorials} + +- [A különböző tesztelési termékek áttekintése és összehasonlítása](/developers/tutorials/guide-to-smart-contract-security-tools/) +- [Echinda használata okosszerződés teszteléshez](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) +- [A Manticore használata az okosszerződés hibáinak felderítésére](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) +- [A Slither használata okosszerződés bugok felderítésére](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) +- [Hogyan készítsen másolatot a Solidity szerződésekről teszteléshez](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) +- [Hogyan végezzen egységteszteket Solidity-ben a Foundry használatával](https://www.rareskills.io/post/foundry-testing-solidity) + +## További olvasnivaló {#further-reading} + +- [Részletes útmutató az Ethereum-okosszerződések teszteléséhez](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) +- [Hogyan tesztelje az Ethereum-okosszerződéseket](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d) +- [A MolochDAO egységtesztelési útmutatója fejlesztőknek](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide) +- [Hogyan teszteljen okosszerződéseket, mint egy igazi rocksztár](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" new file mode 100644 index 00000000000..d950801ad44 --- /dev/null +++ "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" @@ -0,0 +1,165 @@ +--- +title: Okosszerződések frissítése +description: Az Ethereum okosszerződések frissítési mintáinak áttekintése +lang: hu +--- + +Az Ethereumban az okosszerződések olyan önvégrehajtó programok, amelyek az Ethereum virtuális gépén (EVM) futnak. Ezek a programok eleve megváltoztathatatlanok, ami megakadályozza az üzleti logika frissítését a szerződés telepítése után. + +Bár a megváltoztathatatlanság szükséges a bizalomigény nélküliséghez, decentralizáláshoz és biztonsághoz, bizonyos esetekben hátrányt jelenthet. A megváltoztathatatlan kód például lehetetlenné teheti a fejlesztők számára a sebezhető szerződések javítását. + +Ugyanakkor az okosszerződések javítására irányuló kutatások növekedése számos frissítési minta bevezetéséhez vezetett. Ezek a minták lehetővé teszik a fejlesztők számára az okosszerződések frissítését (a megváltoztathatatlanság megőrzése mellett) azáltal, hogy az üzleti logikát különböző szerződésekben helyezik el. + +## Előfeltételek {#prerequisites} + +Érdemes ismerni az [okosszerződéseket](/developers/docs/smart-contracts/), az [okosszerződések anatómiáját](/developers/docs/smart-contracts/anatomy/) és az [Ethereum virtuális gépet (EVM)](/developers/docs/evm/). Ehhez az útmutatóhoz az is hozzátartozik, hogy az olvasók értenek az okosszerződések programozásához. + +## Mi az az okosszerződés-frissítés? {#what-is-a-smart-contract-upgrade} + +Az okosszerződés frissítése magában foglalja az üzleti logika megváltoztatását, miközben megőrzi a szerződés státuszát. Fontos tisztázni, hogy a frissíthetőség és a változtathatóság nem ugyanaz, különösen az okosszerződéseknél. + +Az Ethereum-hálózat egy adott címére telepített programot továbbra sem lehet megváltoztatni. De megváltoztathatja azt a kódot, amely akkor kerül végrehajtásra, amikor a felhasználók interakcióba lépnek egy okosszerződéssel. + +Ezt a következő módszerekkel teheti meg: + +1. Az okosszerződés több verziójának létrehozása és a státusz (az adatok) migrálása a régi szerződésből az új példányába. + +2. Külön szerződések létrehozása az üzleti logika és a státusz tárolására. + +3. Proxyminták használata a funkcióhívások delegálásához egy megváltoztathatatlan proxyszerződésből egy módosítható logikai szerződésbe. + +4. Egy megváltoztathatatlan főszerződés létrehozása, amely interfészeket hoz létre és rugalmas alszerződésekre támaszkodik bizonyos funkciók végrehajtásához. + +5. A gyémántminta használata funkcióhívások delegálására egy proxyszerződésből logikai szerződésekbe. + +### 1. frissítési mechanizmus: szerződésmigráció {#contract-migration} + +A szerződésmigráció a verziókezelésen alapul – ugyanazon szoftver egyedi státuszainak létrehozásán és kezelésén. A szerződésmigráció magában foglalja egy meglévő okosszerződés új példányának telepítését, valamint a tárolás és az egyenlegek átvitelét az új szerződésre. + +Az újonnan telepített szerződés üres tárolóval rendelkezik, ami lehetővé teszi az adatok visszaállítását a régi szerződésből és írását az új példányba. Ezt követően frissítenie kell az összes olyan szerződést, amely kölcsönhatásba lépett a régivel, hogy tükrözze az új címet. + +A szerződésátállás utolsó lépése, hogy a felhasználókat meggyőzzük az új szerződés használatáról. Az új szerződésváltozat megtartja a felhasználói egyenlegeket és címeket, ami megőrzi a megváltoztathatatlanságot. Ha token-alapú szerződésről van szó, akkor a tőzsdékkel is kapcsolatba kell lépnie, hogy dobják el a régi szerződést és használják az újat. + +A szerződésmigráció egyszerű és biztonságos intézkedés az okosszerződések frissítésére a felhasználói interakciók megszakítása nélkül. A felhasználói tárolók és egyenlegek kézi migrálása az új szerződésre azonban időigényes és magas gázköltségekkel járhat. + +[További információ a szerződésmigrációról.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) + +### 2. frissítési mechanizmus: Az adatok szétválasztása {#data-separation} + +Az okosszerződések frissítésének másik módszere az üzleti logika és az adattárolás külön szerződésekben történő szétválasztása. Ez azt jelenti, hogy a felhasználók a logikai szerződéssel lépnek kapcsolatba, míg az adatokat a tárolási szerződésben tartják. + +A logikai szerződés tartalmazza azt a kódot, amely akkor kerül végrehajtásra, amikor a felhasználók interakcióba lépnek az alkalmazással. A tárolási szerződés címét is tartalmazza, és interakcióba lép vele az adatok lekérdezése és beállítása érdekében. + +Eközben a tárolási szerződés tartja az okosszerződéshez kapcsolódó státuszt, például a felhasználói egyenlegeket és címeket. Megjegyzendő, hogy a tárolási szerződés a logikai szerződés tulajdonában van, és telepítéskor az utóbbi címével van konfigurálva. Ez megakadályozza, hogy illetéktelen szerződések meghívják a tárolási szerződést vagy frissítsék annak adatait. + +Alapértelmezés szerint a tárolási szerződés megváltoztathatatlan, de a logikai szerződést, amelyre mutat, lecserélheti egy új implementációra. Ez megváltoztatja az EVM-ben futó kódot, miközben érintetlenül hagyja a tárolást és az egyenlegeket. + +Ennek a frissítési módszernek a használata a logikai szerződés címének frissítését igényli a tárolási szerződésben. Az új logikai szerződést is be kell konfigurálnia a tárolási szerződés címével a korábban ismertetett okok miatt. + +Az adatszétválasztás mintája könnyebben megvalósítható, mint a szerződésmigráció. Azonban több szerződést kell kezelnie, és összetett engedélyezési sémákat kell megvalósítania, hogy megvédje az okosszerződéseket a rosszindulatú frissítésektől. + +### 3. frissítési mechanizmus: Proxyminták {#proxy-patterns} + +A proxyminta szintén az adatok szétválasztását használja, hogy az üzleti logikát és az adatokat külön szerződésekben tartsa. A proxymintában azonban a tárolási szerződés (a proxyt) a kód végrehajtása során hívja meg a logikai szerződést. Ez az adatok szétválasztásának fordítottja, ahol a logikai szerződés hívja meg a tárolási szerződést. + +Az alábbi történik egy proxymintában: + +1. A felhasználók interakcióba lépnek a proxyszerződéssel, amely tárolja az adatokat, de nem tartalmazza az üzleti logikát. + +2. A proxyszerződés tárolja a logikai szerződés címét, és minden funkcióhívást a logikai szerződéshez (amely az üzleti logikát tartalmazza) delegál a `delegatecall` függvény segítségével. + +3. Miután a hívás továbbításra került a logikai szerződéshez, abból visszakeresésre kerülnek a visszaküldött adatok, és átadja azokat a felhasználónak. + +A proxyminták használata megköveteli a **delegatecall** függvény ismeretét. Alapvetően a `delegatecall` egy olyan opkód, amely lehetővé teszi egy szerződés számára, hogy egy másik szerződést hívjon, miközben a tényleges kódvégrehajtás a hívó szerződés kontextusában történik. A `delegatecall` proxymintákban való használatának egyik következménye, hogy a proxyszerződés olvas és ír a tárolójába, és úgy hajtja végre a logikai szerződésben tárolt logikát, mintha egy belső függvényt hívna. + +A [Solidity dokumentációból](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries): + +> _Létezik az üzenethívásnak egy speciális változata, a **delegatecall**, amely megegyezik az üzenethívással, eltekintve attól, hogy a célcímen lévő kódot a hívó szerződés kontextusában hajtjuk végre (annak címén), és a `msg.sender` és `msg.value` értéke nem változik._ _Ez azt jelenti, hogy egy szerződés futásidőben dinamikusan betölthet kódot egy másik címről. A tárolás, az aktuális cím és az egyenleg továbbra is a hívó szerződésre hivatkozik, csak a kódot a hívott címről veszik._ + +A proxyszerződés tudja, hogy meg kell hívnia a `delegatecall` funkciót, amikor a felhasználó meghív egy függvényt, mert van egy beépített `fallback` függvénye. A Solidity programozásban a [fallback függvény](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) akkor kerül végrehajtásra, ha a hívás nem felel meg a szerződésben meghatározott függvényeknek. + +A proxyminta működéséhez egyéni fallback függvény írása szükséges, amely meghatározza, hogy a proxyszerződés hogyan kezelje az általa nem támogatott függvényhívásokat. Ebben az esetben a proxy fallback függvénye úgy van programozva, hogy egy delegatecall funkciót kezdeményezzen, és a felhasználó kérését átirányítsa az aktuális logikai szerződés implementációjához. + +A proxyszerződés alapértelmezés szerint megváltoztathatatlan, de új logikai szerződéseket lehet létrehozni frissített üzleti logikával. A frissítés elvégzése a proxyszerződésben hivatkozott logikai szerződés címének megváltoztatásával történik. + +Azáltal, hogy a proxyszerződést egy új logikai szerződésre irányítja, a felhasználók által meghívott függvényeknél végrehajtott kód megváltozik. Ez lehetővé teszi a szerződés logikájának frissítését anélkül, hogy a felhasználóknak egy új szerződéssel kellene interakcióba lépniük. + +A proxyminta népszerű módszer az okosszerződések frissítésére, mivel kiküszöböli a szerződések migrációjával járó nehézségeket. A proxyminták használata azonban bonyolultabb, és helytelen használat esetén kritikus hibákat, például [függvényválasztó ütközéseket](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357) okozhatnak. + +[Bővebben a proxymintákról](https://blog.openzeppelin.com/proxy-patterns/). + +### 4. frissítési mechanizmus: Stratégiaminta {#strategy-pattern} + +Ennek a technikának az alapja a [stratégiaminta](https://en.wikipedia.org/wiki/Strategy_pattern), amely olyan szoftverek létrehozására ösztönöz, amelyek más programokkal kapcsolódnak, hogy bizonyos funkciókat megvalósítsanak. A stratégiaminta alkalmazása az Ethereum-fejlesztésre azt jelentené, hogy olyan okosszerződést kell létrehozni, amely más szerződések függvényeit hívja meg. + +Ebben az esetben a fő szerződés tartalmazza az alapvető üzleti logikát, de bizonyos funkciók végrehajtásához más okosszerződésekkel (szatellit- vagy alszerződésekkel) interfészeket hoz létre. Ez a fő szerződés tárolja az egyes alszerződések címét is, és képes váltani azok különböző implementációi között. + +Létrehozhat egy új alszerződést, és konfigurálhatja a fő szerződést az új címmel. Ez lehetővé teszi az okosszerződési _stratégiák_ megváltoztatását (azaz új logika implementálását). + +Bár hasonló a korábban tárgyalt proxymintához, a stratégiaminta mégis különbözik, mivel a fő szerződés, amellyel a felhasználók interakcióba lépnek, tartalmazza az üzleti logikát. Ennek a mintának a használata lehetőséget biztosít arra, hogy korlátozott változtatásokat hajtson végre egy okosszerződésen anélkül, hogy az alapvető infrastruktúrát befolyásolná. + +A fő hátránya, hogy ez a minta inkább kisebb frissítések bevezetésére alkalmas. Továbbá, ha a fő szerződés veszélybe kerül (például meghackelik), akkor ezt a frissítési módszert nem tudja használni. + +### 5. frissítési mechanizmus: Gyémántminta {#diamond-pattern} + +A gyémántminta a proxyminta továbbfejlesztésének tekinthető. A gyémántminták abban különböznek a proxymintáktól, hogy a gyémánt proxyszerződés egynél több logikai szerződéshez delegálhat függvényhívásokat. + +A gyémántmintában lévő logikai szerződéseket _oldalaknak (facet)_ nevezzük. Ahhoz, hogy a gyémántminta működjön, létre kell hoznia egy olyan leképezést a proxyszerződésben, amely a [függvényválasztókat](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) különböző oldalcímekhez rendeli. + +Amikor egy felhasználó függvényhívást hajt végre, a proxyszerződés ellenőrzi a leképezést, hogy megtalálja a függvény végrehajtásáért felelős oldalt. Ezután meghívja a `delegatecall` (a fallback függvényt használva), és a hívást átirányítja a megfelelő logikai szerződéshez. + +A gyémánt frissítési mintának van néhány előnye a hagyományos proxymintákkal szemben: + +1. Lehetővé teszi a szerződés egy kis részének frissítését anélkül, hogy az egész kódot megváltoztatná. A proxyminta használata a frissítésekhez egy teljesen új logikai szerződés létrehozását igényli, még a kisebb frissítések esetében is. + +2. Minden okosszerződés (beleértve a proxymintákban használt logikai szerződéseket is) 24 KB-os méretkorlátozással rendelkezik, ami korlátot jelenthet – különösen a több funkciót igénylő összetett szerződések esetében. A gyémántminta megkönnyíti ennek a problémának a megoldását azáltal, hogy a funkciókat több logikai szerződésre osztja fel. + +3. A proxyminták a hozzáférés-ellenőrzés mindenre kiterjedő megközelítését alkalmazzák. A frissítési funkciókhoz hozzáféréssel rendelkező entitás megváltoztathatja a _teljes_ szerződést. A gyémántminta azonban lehetővé teszi a moduláris jogosultsági megközelítést, ahol az entitások korlátozhatók bizonyos funkciók frissítésére egy okosszerződésen belül. + +[Bővebben a gyémántmintáról](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w). + +## Az okosszerződések frissítésének előnyei és hátrányai {#pros-and-cons-of-upgrading-smart-contracts} + +| Előnyök | Hátrányok | +| --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Az okosszerződés frissítése megkönnyítheti a telepítés utáni fázisban felfedezett sebezhetőségek javítását. | Az okosszerződések frissítése tagadja a kód megváltoztathatatlanságának elképzelését, ami hatással van a decentralizációra és a biztonságra. | +| A fejlesztők logikai frissítésekkel új funkciókat adhatnak a decentralizált alkalmazásokhoz. | A felhasználóknak bízniuk kell abban, hogy a fejlesztők nem módosítják önkényesen az okosszerződéseket. | +| Az okosszerződések frissítései javíthatják a végfelhasználók biztonságát, mivel a hibák gyorsan kijavíthatók. | A frissítési lehetőség okosszerződésekbe történő programozása újabb komplexitási réteget jelent, és növeli a kritikus hibák lehetőségét. | +| A szerződésfrissítések nagyobb teret adnak a fejlesztőknek a különböző funkciókkal való kísérletezésre és a dappok jövőbeli javítására. | Az okosszerződések frissítésének lehetősége arra ösztönözheti a fejlesztőket, hogy gyorsabban indítsák el a projekteket, anélkül hogy a fejlesztési fázisban átvilágítást végeznének. | +| | A megbízhatatlan hozzáférés-szabályozás vagy a az okosszerződésekben lévő centralizálás megkönnyítheti a rosszindulatú szereplők számára a jogosulatlan frissítések végrehajtását. | + +## Az okosszerződések frissítésére vonatkozó megfontolások {#considerations-for-upgrading-smart-contracts} + +1. Használjon biztonságos hozzáférés-szabályozási/engedélyezési mechanizmusokat a jogosulatlan okosszerződés-frissítések megakadályozására, különösen, ha proxymintákat, stratégiamintákat vagy adatszétválasztást használ. Példa a frissítési funkcióhoz való hozzáférést úgy korlátozza, hogy csak a szerződés tulajdonosa hívhatja meg azt. + +2. Az okosszerződések frissítése összetett tevékenység, és nagyfokú körültekintést igényel a sebezhetőségek megelőzése érdekében. + +3. Csökkentse a bizalmi feltételezéseket a frissítések decentralizálásával. A lehetséges stratégiák közé tartozik a [több aláírásos (multi-sig) tárcaszerződés](/developers/docs/smart-contracts/#multisig) használata a frissítések ellenőrzésére, vagy a [a DAO tagjainak](/dao/) szavazása a frissítés jóváhagyásáról. + +4. Legyen tisztában a szerződések frissítésének költségeivel. Például a státusz (pl. a felhasználói egyenlegek) átmásolása egy régi szerződésből egy új szerződésbe a migráció során egynél több tranzakciót igényelhet, ami több gázdíjat jelent. + +5. Fontolja meg **időzárak** bevezetését a felhasználók védelme érdekében. Az időzár a rendszerben végrehajtott változtatások késleltetésére utal. Az időzár kombinálható egy több aláírásos irányítási rendszerrel a frissítések ellenőrzésére: ha egy javasolt művelet eléri a szükséges jóváhagyási küszöbértéket, nem hajtják végre, amíg az előre meghatározott késleltetési időszak el nem telik. + +Az időkorlátok időt adnak a felhasználóknak arra, hogy kilépjenek a rendszerből, ha nem értenek egyet egy javasolt változtatással (például logikai frissítés vagy új díjszabás). Az időzítés nélkül a felhasználóknak bízniuk kell abban, hogy a fejlesztők nem hajtanak végre önkényes változtatásokat az okosszerződésben előzetes értesítés nélkül. Ennek hátránya, hogy az időzár korlátozza a sebezhetőségek gyors javításának lehetőségét. + +## Források {#resources} + +**OpenZeppelin Upgrades Plugins – _Egy eszközcsomag a frissíthető okosszerződések telepítéséhez és biztosításához._** + +- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades) +- [Dokumentáció](https://docs.openzeppelin.com/upgrades) + +## Oktatóanyagok {#tutorials} + +- [Az okosszerződések frissítése | YouTube Tutorial](https://www.youtube.com/watch?v=bdXJmWajZRY) Patrick Collinstól +- [Útmutató az Ethereum okosszerződés-migrációról](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) – Austin Griffith +- [A UUPS proxyminta használata az okosszerződésfrissítéshez](https://blog.logrocket.com/author/praneshas/) – Pranesh A.S +- [Web3-útmutató: frissíthető okosszerződés (proxy) írása az OpenZeppelin használatával](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) – fangjun.eth + +## További olvasnivaló {#further-reading} + +- [Az okosszerződés frissítésének helyzetet](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) – Santiago Palladino +- [A Solidity okosszerződés frissítésének módjai](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) – Crypto Market Pool blog +- [Tanulja meg: okosszerződések frissítése](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) – OpenZeppelin Docs +- [Proxy-minták a Solidity szerződések frissíthetőségéhez: az átlátható és UUPS proxyk összehasonlítása](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) – Naveen Sahu +- [Hogyan működik a gyémántfrissítés](https://dev.to/mudgen/how-diamond-upgrades-work-417j) – Nick Mudge diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" new file mode 100644 index 00000000000..fb178d4bf47 --- /dev/null +++ "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" @@ -0,0 +1,107 @@ +--- +title: Okosszerződések érvényesítése +description: Az Ethereum okosszerződések forráskódjának ellenőrzési folyamata +lang: hu +--- + +Az [okosszerződéseket](/developers/docs/smart-contracts/) úgy tervezték, hogy „bizalom nélküliek” legyenek, vagyis a felhasználóknak ne kelljen megbízniuk harmadik félben (például fejlesztőkben és vállalatokban), mielőtt kapcsolatba lépnének egy szerződéssel. A bizalomigény nélküliség feltétele, hogy a felhasználók és más fejlesztők képesek ellenőrizni az okosszerződés forráskódját. A forráskód-ellenőrzés biztosítja a felhasználók és a fejlesztők számára, hogy a közzétett szerződéskód ugyanaz, ami a szerződés címén fut az Ethereum blokkláncon. + +Fontos különbséget tenni a forráskód-ellenőrzés és a "[formális ellenőrzés](/developers/docs/smart-contracts/formal-verification/)" között. A forráskód-ellenőrzés, amelyet ez a cikk részletesen ismertet, arra vonatkozik, hogy egy okosszerződés forráskódja egy magas szintű nyelven (mint a Solidity) lefordítható-e ugyanarra a bájtkódra, amelyet a szerződés címén végre kell hajtani. A formális ellenőrzés ugyanakkor az okosszerződés helyességének ellenőrzését írja le, ami azt jelenti, hogy a szerződés az elvárásoknak megfelelően viselkedik. Bár a kontextustól függ, a szerződés-ellenőrzés általában a forráskód ellenőrzésére utal. + +## Mi az a forráskód-ellenőrzés? {#what-is-source-code-verification} + +Mielőtt egy okosszerződést a [Ethereum virtuális gépen (EVM)](/developers/docs/evm/) telepítenének, a fejlesztők [átfordítják](/developers/docs/smart-contracts/compiling/) a szerződés forráskódját – a [Solidity](/developers/docs/smart-contracts/languages/) vagy más magas szintű programozási nyelven írt utasításokat – bájtkódra. Mivel az EVM nem tudja értelmezni a magas szintű utasításokat, a forráskód bájtkódra (azaz alacsony szintű, gépi utasításokra) történő fordítása szükséges a szerződés logikájának EVM-ben való végrehajtásához. + +A forráskód-ellenőrzés az okosszerződés forráskódjának és a szerződés létrehozásakor használt átfordított bájtkódnak az összehasonlítása azért, hogy a lehetséges különbségeket észrevegyék. Az okosszerződések ellenőrzése azért fontos, mert a nyilvánossá tett szerződéskód eltérhet attól, ami a blokkláncon fut. + +Az okosszerződések ellenőrzése lehetővé teszi annak vizsgálatát, hogy mit csinál egy szerződés a magasabb szintű nyelven, amelyen meg van írva, anélkül, hogy gépi kódot kellene olvasni. A függvények, értékek és általában a változók nevei és megjegyzései ugyanazok maradnak, mint a lefordított és telepített eredeti forráskódban. Ez sokkal könnyebbé teszi a kódolvasást. A forráshitelesítés a kód dokumentációját is biztosítja, hogy a végfelhasználók tudják, mire tervezték azt. + +### Mi az a teljes körű ellenőrzés? {#full-verification} + +A forráskódnak vannak olyan részei, amelyek nem befolyásolják a lefordított bájtkódot, mint például a megjegyzések vagy a változónevek. Ez azt jelenti, hogy két különböző változónevű és különböző megjegyzésekkel rendelkező forráskód is képes lenne ugyanazt a szerződést ellenőrizni. Ezzel egy rosszindulatú szereplő megtévesztő megjegyzéseket adhat hozzá vagy félrevezető változóneveket adhat a forráskódon belül, és a szerződést az eredetitől eltérő forráskóddal hitelesítheti. + +Ezt úgy lehet elkerülni, hogy a bájtkódhoz további adatokat csatolunk, amelyek a forráskód pontosságának _kriptográfiai garanciájaként_ és az átfordítási információk _ujjlenyomataként_ szolgálnak. A szükséges információkat a [Solidity szerződési metaadataiban](https://docs.soliditylang.org/en/v0.8.15/metadata.html) találjuk, és ennek a fájlnak a hashe a szerződés bájtkódjához van csatolva. Ezt működés közben is láthatja a [metaadatok játszótéren](https://playground.sourcify.dev) + +A metaadatfájl tartalmazza a szerződés összeállítására vonatkozó információkat, beleértve a forrásfájlokat és azok hashét is. Ez azt jelenti, hogy ha bármelyik fordítási beállítás vagy akár csak egy bájt is megváltozik az egyik forrásfájlban, a metaadatfájl is megváltozik. Következésképpen a bájtkódhoz csatolt metaadatfájl hashe is megváltozik. Ez azt jelenti, hogy ha egy szerződés bájtkódja és a hozzáfűzött metaadatok hashe egyezik a megadott forráskóddal és az átfordítási beállításokkal, akkor ez pontosan ugyanaz a forráskód, amit az eredeti fordítás során használtunk, és egyetlen bájt sem különbözik. + +Ezt a metaadatok hashét használó ellenőrzést nevezzük **"[teljes vagy tökéletes ellenőrzésnek](https://docs.sourcify.dev/docs/full-vs-partial-match/)"**. Ha a metaadathashek nem egyeznek, vagy nem veszik figyelembe az ellenőrzés során, akkor „részleges egyezésről” van szó, ami jelenleg a szerződésellenőrzés elterjedtebb módja. Lehetőség van [olyan rosszindulatú kód](https://samczsun.com/hiding-in-plain-sight/) beillesztésére, amelyet csak a teljes ellenőrzés mutat ki. A legtöbb fejlesztő nem ismeri a teljes ellenőrzést, és nem őrzi meg az átfordítás metaadatfájlját, ezért eddig a részleges ellenőrzés volt az alapvető módszer. + +## Miért fontos a forráskód-ellenőrzés? {#importance-of-source-code-verification} + +### Bizalomigénytől való mentesség {#trustlessness} + +A bizalomigénytől való mentesség az okosszerződések és a [decentralizált alkalmazások (dapp)](/developers/docs/dapps/) legfontosabb előfeltétele. Az okosszerződések alapvetően megváltoztathatatlanok, nem módosíthatók; egy szerződés a telepítés időpontjában a kódban meghatározott üzleti logikát hajtja végre. Ez azt jelenti, hogy a fejlesztők és a vállalatok nem tudják manipulálni a szerződés kódját az Ethereumra való telepítés után. + +Ahhoz, hogy egy okosszerződés megbízható legyen, a szerződés kódjának elérhetőnek kell lennie független ellenőrzésre. Bár minden okosszerződés lefordított bájtkódja nyilvánosan elérhető a blokkláncon, az alacsony szintű nyelv nehezen érthető a fejlesztők és a felhasználók számára. + +A projektek a szerződések forráskódjának közzétételével csökkentik a bizalmi feltételezéseket. Ez azonban egy másik problémához vezet: nehéz ellenőrizni, hogy a közzétett forráskód megegyezik-e a szerződéses bájtkóddal. Ebben a forgatókönyvben a bizalomigénytől való mentesség elvész, mivel a felhasználóknak meg kell bízniuk a fejlesztőkben, hogy nem változtatják meg a szerződés üzleti logikáját (például a bájtkód megváltoztatásával), mielőtt azt a blokkláncra telepítenék. + +A forráskód-ellenőrző eszközök garanciát nyújtanak arra, hogy az intelligens szerződés forráskódfájljai megegyeznek az assembly (összeszerelési) kóddal. Az eredmény egy bizalomigény nélküli ökoszisztéma, ahol a felhasználók nem bíznak vakon harmadik félben, hanem a kódot ellenőrzik, mielőtt pénzt helyeznének el egy szerződésben. + +### Felhasználói biztonság {#user-safety} + +Az okosszerződések esetében sok pénz foroghat kockán. Ez magasabb biztonsági garanciákat és az okosszerződés logikájának ellenőrzését igényli a használat előtt. A probléma az, hogy a rosszhiszemű fejlesztők megtéveszthetik a felhasználókat azzal, hogy rosszindulatú kódot illesztenek az okosszerződésbe. Ellenőrzés nélkül a rosszindulatú okosszerződések [hátsó ajtókkal](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), ellentmondásos hozzáférés-szabályozási mechanizmusokkal, kihasználható sebezhetőségekkel és egyéb, a felhasználók biztonságát veszélyeztető dolgokkal rendelkezhetnek, amelyek észrevétlenül maradnának. + +Az okosszerződés forráskódfájljainak közzététele megkönnyíti az érdeklődők, például az auditorok számára, hogy értékeljék a szerződést a potenciális támadási vektorok szempontjából. Ha több fél egymástól függetlenül ellenőrzi az okosszerződést, a felhasználók nagyobb garanciát kapnak annak biztonságára. + +## Hogyan ellenőrizhetjük az Ethereum okosszerződések forráskódját {#source-code-verification-for-ethereum-smart-contracts} + +[Egy okosszerződés Ethereumon történő telepítéséhez](/developers/docs/smart-contracts/deploying/) egy tranzakciót kell elküldeni egy speciális címre, amely egy adatcsomagot (lefordított bájtkódot) tartalmaz. Az adatcsomag úgy jön létre, hogy a forráskódot átfordítják, valamint hozzáillesztik a tranzakcióban az adatcsomaghoz csatolt szerződéspéldány [konstruktori argumentumait](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor). A fordítás determinisztikus, ami azt jelenti, hogy mindig ugyanazt a kimenetet (azaz szerződéses bájtkódot) produkálja, ha ugyanazokat a forrásfájlokat és fordítási beállításokat (például fordítóverzió, optimalizáló) használjuk. + +![Az okosszerződés forráskódjának ellenőrzését bemutató diagram](./source-code-verification.png) + +Az okosszerződés ellenőrzése alapvetően a következő lépésekből áll: + +1. A forrásfájlok és a fordítási beállítások bevitele a fordítóprogramba. + +2. A fordító kiadja a szerződés bájtkódját + +3. A telepített szerződés bájtkódjának lekérdezése egy adott címen + +4. A telepített bájtkód összehasonlítása az újrafordított bájtkóddal. Ha a kódok egyeznek, a szerződés a megadott forráskóddal és a fordítási beállításokkal kerül ellenőrzésre. + +5. Továbbá, ha a metaadatok hashe a bájtkód végén megegyezik, akkor ez egy teljes egyezés. + +Vegye figyelembe, hogy ez egy leegyszerűsített leírása az ellenőrzésnek, és számos olyan kivétel van, amelyek nem működik ilyen módon, mint például a [megmásíthatatlan változók](https://docs.sourcify.dev/docs/immutables/). + +## Forráskód-ellenőrző eszközök {#source-code-verification-tools} + +A szerződések ellenőrzésének hagyományos folyamata összetett lehet. Ezért vannak eszközeink az Ethereumon telepített okosszerződések forráskódjának ellenőrzésére. Ezek az eszközök automatizálják a forráskód-ellenőrzés nagy részét, és a felhasználók számára előnyös, ellenőrzött szerződéseket is összeállítanak. + +### Etherscan {#etherscan} + +Bár leginkább [Ethereum-blokkláncfelfedezőként](/developers/docs/data-and-analytics/block-explorers/) ismerik, az Etherscan [forráskód-ellenőrzési szolgáltatást](https://etherscan.io/verifyContract) is kínál az okosszerződések fejlesztőinek és felhasználóinak. + +Az Etherscan lehetővé teszi a szerződés bájtkódjának újrafordítását az eredeti adatcsomagból (forráskód, könyvtárcím, fordítói beállítások, szerződés címe stb.). Ha az újrafordított bájtkód a láncon belüli szerződés bájtkódjához (és konstruktor paramétereihez) kapcsolódik, akkor [a szerződés ellenőrzött](https://info.etherscan.com/types-of-contract-verification/). + +Ezt követően az Ön szerződésének forráskódja megkapja az „Ellenőrzött” címkét, és közzéteszik az Etherscan oldalon, hogy mások is ellenőrizhessék. A szerződés bekerül a [Hitelesített szerződések](https://etherscan.io/contractsVerified/) szekcióba, vagyis az ellenőrzött forráskódú okosszerződések tárházába. + +Az Etherscan a leggyakrabban használt eszköz a szerződések ellenőrzésére. Az Etherscan szerződés-ellenőrzésének azonban van egy hátránya: nem hasonlítja össze a láncon belüli és az újrafordított bájtkód **metaadat hash** értékét. Ezért az Etherscanben szereplő egyezések részlegesek. + +[Bővebben a szerződések ellenőrzéséről az Etherscanen](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327). + +### Sourcify {#sourcify} + +A [Sourcify](https://sourcify.dev/#/verifier) egy másik nyílt forráskódú és decentralizált eszköz a szerződések ellenőrzésére. Ez nem blokkfelfedező, és csak a [különböző EVM-alapú hálózatokon](https://docs.sourcify.dev/docs/chains) kötött szerződéseket ellenőrzi. Nyilvános infrastruktúraként működik, amelyre más eszközök építhetnek, és célja, hogy a metaadatfájlban található [ABI](/developers/docs/smart-contracts/compiling/#web-applications) és [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) megjegyzések segítségével felhasználóbarát szerződéses interakciókat tegyen lehetővé. + +Az Etherscannal ellentétben a Sourcify támogatja a metaadatok hashsel való teljes egyeztetést. Az ellenőrzött szerződéseket a [nyilvános adattárban](https://docs.sourcify.dev/docs/repository/) HTTP-n és [IPFS-en](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs), egy decentralizált, [tartalomcímzett](https://web3.storage/docs/concepts/content-addressing/) tárolóban jeleníti meg. Ez lehetővé teszi egy szerződés metaadatfájljának IPFS-en keresztüli lehívását, mivel a csatolt metaadat hash egy IPFS hash. + +Ezenkívül a forráskódfájlokat is lekérdezhetjük az IPFS-en keresztül, mivel a metaadatokban megtalálhatók ezen fájlok IPFS hashei is. Egy szerződés a metaadatfájl és a forrásfájlok megadásával is ellenőrizhető az API vagy [UI](https://sourcify.dev/#/verifier) révén, illetve a bővítmények használatával. A Sourcify monitoring eszköz figyeli az új blokkok szerződéseinek létrehozását is, és megpróbálja ellenőrizni a szerződéseket, ha azok metaadatait és forrásfájljait közzéteszik az IPFS-en. + +[Bővebben a szerződések ellenőrzéséről a Sourcify oldalon](https://blog.soliditylang.org/2020/06/25/sourcify-faq/). + +### Tenderly {#tenderly} + +A [Tenderly platform](https://tenderly.co/) lehetővé teszi a web3-fejlesztők számára az okosszerződések létrehozását, tesztelését, felügyeletét és működtetését. A Tenderly segít a fejlesztőknek felgyorsítani az okosszerződések fejlesztését úgy, hogy a hibakeresési eszközöket a megfigyelhetőséggel és az infrastrukturális építőelemekkel kombinálja. A Tenderly funkcióinak teljes körű használatához a fejlesztőknek [a forráskód ellenőrzését](https://docs.tenderly.co/monitoring/contract-verification) többféle módszerrel kell elvégezniük. + +Lehetőség van a szerződés privát vagy nyilvános ellenőrzésére. Privát ellenőrzés esetén az okosszerződés csak Ön (és a projekt többi tagja) számára látható. A szerződés nyilvános ellenőrzése mindenkinek látható lesz, aki a Tenderly platformot használja. + +Szerződéseit a [Dashboard](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract), a [Tenderly Hardhat plugin](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin) vagy a [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) segítségével ellenőrizheti. + +Ha a szerződéseket a Dashboardon keresztül ellenőrzi, importálnia kell a forrásfájlt vagy a Solidity fordító által generált metaadatfájlt, a címet/hálózatot és a fordító beállításait. + +A Tenderly Hardhat-plugin használata lehetővé teszi, hogy kevesebb erőfeszítéssel nagyobb kontrollt gyakoroljon az ellenőrzési folyamat felett, mivel automatikus (kód nélküli) és kézi (kódalapú) ellenőrzést is választhat. + +## További olvasnivaló {#further-reading} + +- [A szerződés forráskódjának ellenőrzése](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) diff --git a/public/content/translations/hu/21) Whitepaper/whitepaper/index.md b/public/content/translations/hu/21) Whitepaper/whitepaper/index.md new file mode 100644 index 00000000000..e05849c4fc2 --- /dev/null +++ b/public/content/translations/hu/21) Whitepaper/whitepaper/index.md @@ -0,0 +1,517 @@ +--- +title: Ethereum fehérkönyv +description: Az Ethereum működéséről szóló kiadvány, melyet 2013-ban adtak ki az indulása előtt. +lang: hu +sidebarDepth: 2 +hideEditButton: true +--- + +# Ethereum fehérkönyv {#ethereum-whitepaper} + +_Ezt a bemutató kiadványt eredetileg 2014-ban adta ki Vitalik Buterin, az [Ethereum](/what-is-ethereum/) alapítója, a projekt 2015-ös indulása előtt. Fontos megjegyezni, hogy az Ethereum sok másik közösség által vezetett, nyílt forráskódú szoftver projekthez hasonlóan, a kezdeti elindulás óta fejlődött._ + +_Noha több éve íródott, fenntartjuk ezt a kiadványt, mert továbbra is hasznos referenciaként szolgál és pontos ábrázolást mutat az Ethereumról és annak jövőképéről. Ha többet szeretne megtudni az Ethereum legutóbbi fejlesztéseiről és az általunk elvégzett protokollváltoztatásokról, akkor ezt az [útmutatót](/learn/) ajánljuk._ + +[Azoknak a kutatóknak és egyetemi oktatóknak, akik a (2014. decemberi) fehérkönyv előzmény- vagy kanonikus változatát keresik, érdemes ezt a PDF-et használni.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf) + +## Okosszerződés- és decentralizált alkalmazásplatform következő generációja {#a-next-generation-smart-contract-and-decentralized-application-platform} + +Satoshi Nakamoto 2009-ben történő Bitcoin fejlesztését gyakran a pénz és a pénznem radikális fejlesztésének nevezték, ez az első példa egy olyan digitális eszközre, amelynek egyszerre nincs mögöttes vagy [belső értéke](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/), valamint nincs központi kibocsájtója vagy irányítója. A Bitcoin kísérlet másik – vitathatatlanul fontosabb – része azonban az alapjául szolgáló blokklánc-technológia, mint az elosztott konszenzus eszköze, és a figyelem gyorsan elkezdett áttérni ezen másik aspektusra. A blokklánc-technológiát alternatív módon alkalmazzák arra, hogy a blokkláncra épülő digitális eszközök egyéni valutákat és pénzügyi eszközöket ([színes érmék](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)), fizikai eszköz tulajdonjogát ([okosingatlan](https://en.bitcoin.it/wiki/Smart_Property)), nem helyettesíthető eszközöket, például domainneveket ([Namecoin](http://namecoin.org)) képviselnek, emellett összetettebb alkalmazásokat működtetnek, amelyekben a digitális eszközöket közvetlenül egy tetszőleges szabályokat végrehajtó kódrészlet irányítja ([okosszerződések](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)), vagy akár blokkláncalapú [decentralizált autonóm szervezeteket (DAO)](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) is alapíthatnak. Az Ethereum egy olyan beépített, teljesen kidolgozott Turing-teljes programozási nyelvvel rendelkező blokkláncot szeretne nyújtani, amely olyan „szerződések” létrehozására használható, amelyek tetszőleges státuszváltozási funkciók kódolására használhatók, lehetővé téve a felhasználók számára a fent leírt rendszerek bármelyikének létrehozását, valamint sok olyan más dolgot is, amelyre még nem gondoltunk, egyszerűen pár sornyi kódba foglalva az adott logikát. + +## Bevezetés a Bitcoinba és kapcsolódó koncepciókba {#introduction-to-bitcoin-and-existing-concepts} + +### Előzmények {#history} + +A decentralizált digitális valuta, valamint az alternatív alkalmazások, például az ingatlannyilvántartások fogalma évtizedek óta létezik. Az 1980-as és 1990-es évek anonim e-cash protokolljai, melyek főleg a Chaum-féle vakításként ismert kriptográfiai primitívre támaszkodtak, egy magas fokú adatvédelemmel rendelkező valutát kínáltak, de a protokolloknak többnyire nem sikerült elterjedniük, mivel egy centralizált közvetítőre támaszkodtak. 1998-ban Wei Dai [b-money](http://www.weidai.com/bmoney.txt) pénze volt az első javaslat a pénz létrehozására számítási kirakósok megoldásával és decentralizált konszenzussal, de nem igazán volt kidolgozva az a része, hogy miként lehetne az utóbbit megvalósítani a gyakorlatban. 2005-ben Hal Finney bemutatta az [újrafelhasználható proof of work-öket (munkabizonyítékokat)](https://nakamotoinstitute.org/finney/rpow/), egy olyan rendszert, amely a b-money pénzből származó ötleteket és Adam Back számítási szempontból nehéz Hashcash rejtvényeit használta fel a kriptovaluta koncepciójának megalkotására, de az ideálistól elmaradt azáltal, hogy egy megbízható számítási háttérre támaszkodott. Először 2009-ben vezetett be Satoshi Nakamoto a gyakorlatban egy decentralizált valutát, amely egyesítette az alapként szolgáló létező primitíveket a tulajdonjog nyilvánoskulcs-kriptográfiával történő kezelésére – egy konszenzus algoritmussal – az érmék tulajdonosainak számontartására, amelyet „proof-of-worknek” (munkabizonyíték) nevezünk. + +A proof-of-work mögötti mechanizmus egy áttörés volt, mivel egyszerre két problémára is megoldást nyújtott. Egyrészt egy olyan egyszerű és mérsékelten hatékony konszenzusalgoritmust biztosított, amely lehetővé teszi a hálózat csomópontjainak, vagyis a résztvevő számítógépeknek (csomópontoknak), hogy kollektíven egyetértsenek a Bitcoin főkönyvi állapotának kanonikus frissítéseiről. Másrészt egy olyan mechanizmust biztosított, amely szabad belépést tett lehetővé abba a konszenzusfolyamatba, amely megoldja annak a politikai problémának az eldöntését, hogy ki befolyásolja a konszenzust, emellett a Sybil-támadásokat is megelőzi. Ehhez a részvétel formális akadályát – mint például egy listán egyedi entitásként való nyilvántartás követelményét – gazdasági akadályokkal helyettesíti: egy résztvevő csomópont súlya a konszenzusos szavazási folyamatban közvetlenül arányos azzal a számítási erővel, amivel a csomópont rendelkezik. Azóta javaslattétel is született egy alternatív megközelítésre, amelyet _proof-of-stake-nek_, azaz letéti bizonyítéknak neveznek, mivel a hálózaton résztvevő számítógép vagy csomópont súlyozását a valuta letétbe helyezésének arányában számítja ki, nem a számítási kapacitása alapján; a két megközelítés relatív előnyeinek megvitatása túlmutat a cikk keretein, ugyanakkor mindkét megközelítés felhasználható egy kriptovaluta alapjaként. + +### Bitcoin mint egy státuszváltozási rendszer {#bitcoin-as-a-state-transition-system} + +![Ethereum állapot átmenet](./ethereum-state-transition.png) + +Technikai szempontból egy kriptovaluta, például a Bitcoin főkönyve egy státuszváltozási rendszernek tekinthető, ahol van egy státusz, amely számon tartja az összes létező bitcoin tulajdonosi állapotát, és egy státuszváltozási függvény, ami a státusz és a tranzakció hozzáadásával egy új státuszt eredményez. Például egy szabályos banki rendszerben a státusz a vagyonmérlegnek felel meg, a tranzakció egy kérvény $X összeg átmozgatására A-ból B-be, a státuszváltozási függvény pedig csökkenti A számlájának értékét $X összeggel és növeli B számlájának értékét $X összeggel. Ha az A számla kevesebb összeggel rendelkezik mint $X, akkor a státuszváltozási függvény hibajelzést ad vissza. Tehát így definiálható formálisan: + +``` +APPLY(S,TX) -> S' or ERROR +``` + +A fentiekben leírt banki rendszerben: + +```js +APPLY({ Alice: $50, Bob: $50 },"küld $20 Alice-tól Bob-nak") = { Alice: $30, Bob: $70 } +``` + +De: + +```js +APPLY({ Alice: $50, Bob: $50 },"küld $70 Alice-tól Bob-nak") = ERROR +``` + +A Bitcoin státusza az összes kibányászott és el nem költött érme együttvéve (technikailag az „elköltetlen tranzakciós kimenetek” vagy UTXO). Minden UTXO-nak van egy névértéke és egy tulajdonosa (melyet egy 20 bájtos cím határoz meg, lényegében egy kriptográfiai nyilvános kulcs[fn1](#jegyzetek)). Egy tranzakció egy vagy több bemenetet tartalmaz, és mindegyik bemenet tartalmaz egy meglévő UTXO-ra mutató hivatkozást, valamint egy kriptográfiai aláírást, amelyet a tulajdonos címéhez társított privát kulcs hoz létre, és egy vagy több kimenetet, ahol minden egyes kimenet egy új UTXO-t tartalmaz, amik aztán hozzáadódnak a státuszhoz. + +A státuszváltozási függvény `APPLY(S,TX) -> S'` a következő módon definiálható: + +
    +
  1. + Minden egyes bemenetre a TX-ben: +
      +
    • + Ha a hivatkozott UTXO nincs benne az S-ben, hibát küld vissza. +
      • +
    • + Ha a szolgáltatott aláírás nem egyezik az UTXO tulajdonosának aláírásával, hibát küld vissza. +
      • +
    +
    2. +
  2. + Ha az összes bemeneti UTXO összege kisebb, mint az összes kimeneti UTXO egység összege, hibát küld vissza. +
    3. +
  3. + S-t küld vissza az összes bemeneti UTXO elvételével és az összes UTXO hozzáadásával. +
    4. +
+ +Az első lépés első fele megakadályozza, hogy a tranzakciók feladói nem létező érméket költsenek el, az első lépés második fele pedig megakadályozza, hogy a tranzakciók feladói mások érméit költsék el, a második lépés pedig az érték megőrzését hajtja végre. Ahhoz, hogy ezt fizetésnél használjuk, a protokoll a következő. Tegyük fel, hogy Alice 11,7 BTC-t szeretne Bob-nak átutalni. Először Alice megkeresi az általa birtokolt elérhető UTXO-k egy olyan halmazát, melynek összege legalább 11.7 BTC. A valóságban Alice nem fog pont 11.7 BTC-t találni; mondjuk, hogy a legkisebb, amit megtalált 6+4+2=12. Ezután elkészít egy tranzakciót ezzel a három bemenettel és két kimenettel. Az első kimenet 11.7 BTC lesz, aminek Bob címe lesz a tulajdonosa, a második kimenet pedig a maradék 0.3 BTC "visszajáró", melynek maga Alice a tulajdonosa. + +### Bányászat {#mining} + +![Ethereum blokkok](./ethereum-blocks.png) + +Ha hozzáférnénk egy megbízható, központosított szolgáltatáshoz, ezt a rendszert egyértelmű lenne megvalósítani; mivel pontosan a leírtak szerint lehetne kódolni egy központosított, azaz centralizált szerver merevlemezén tárolva az állapotot. Azonban a Bitcoin egy decentralizált pénzrendszert próbált kiépíteni, így a státuszváltozási rendszert egy konszenzusrendszerrel kell kombinálni, hogy biztosítsa, hogy mindenki egyetért a tranzakciók sorrendjével. A Bitcoin decentralizált konszenzus folyamata elvárja a hálózat résztvevőitől, hogy folyamatosan tranzakciókból álló csomagokat próbáljanak készíteni, melyeket '"blokkoknak" hívunk. A hálózat nagyjából egy blokkot szándékozik gyártani minden tizedik percben, ahol minden egyes blokk tartalmaz egy időbélyeget, egy nonce-t, egy hivatkozást az előző blokkra (vagyis hash-t), és az összes olyan tranzakciót tartalmazó listát, melyek az előző blokk után következtek. Idővel egy tartós, folyamatosan növekvő "blokklánc" jön létre, mely folyamatosan frissül, hogy a Bitcoin főkönyv legutóbbi állapotát reprezentálja. + +A blokkok érvényességét ellenőrző algoritmust az alábbi paradigma szerint lehet kifejezni: + +1. Ellenőrzi, hogy a blokk által hivatkozott előző blokk létezik és érvényes. +2. Ellenőrzi, hogy a blokk időbélyege későbbi-e, mint az előző blokké[fn2](#jegyzetek) és kevesebb mint 2 óra telt-e el azóta +3. Ellenőrzi, hogy a blokk proof-of-workje érvényes-e. +4. Legyen `S[0]` az előző blokk után lévő státusz. +5. Legyen `TX` a blokk tranzakciós listája `n` tranzakcióval. Minden `i`-re `0...n-1`-ig legyen beállítva `S[i+1] = APPLY(S[i],TX[i])`. Ha bármely lépés hibát ad vissza, kilép és hamis értéket ad vissza. +6. Igaz értéket ad vissza, és `S[n]`-t regisztrál státuszként a blokk végén. + +Lényegében a blokkban szereplő minden tranzakciónak érvényes státuszváltozást kell biztosítania a tranzakció lefutása előtti kanonikus állapotból egy új állapotba. Fontos megjegyezni, hogy a státusz nincs belekódolva a blokkba; pusztán absztrakció, amelyre a hálózat érvényesítő résztvevőjének emlékeznie kell, és bármely blokkra (biztonságosan) csak akkor számítható ki, ha a kezdeti státuszból indulunk ki, és minden tranzakciót egymás után lefuttatunk minden blokkban. Továbbá meg kell jegyezni, hogy az is számít, hogy a bányász a tranzakciókat milyen sorrendben helyezte el a blokkban; ha van két olyan A és B tranzakció a blokkban, ahol B az A által létrehozott UTXO-t költi el, a blokk akkor lesz érvényes, ha A előbb van mint B, fordítva nem. + +A fenti listában szereplő érvényességi feltételek közül egyedül a "munkabizonyíték" szükségessége nem található meg más rendszereknél. A pontos feltétel pedig az, hogy minden blokk dupla-SHA256 hashének, melyet egy 256 bites számként kezelünk, kisebbnek kell lennie, mint egy dinamikusan beállított célérték, mely ennek az anyagnak a megírása közben 2187. Ennek a célja, hogy a blokk létrehozása számítási szempontból "nehéz" legyen, és hogy ezáltal megakadályozza a sybil-támadókat, hogy átalakítsák a teljes blokkláncot a saját érdekükben. Mivel az SHA256-ot úgy tervezték, hogy egy teljesen megjósolhatatlan álvéletlen (pszeudo-random) függvény legyen, így a blokk létrehozásának egyetlen módja a próbaszerencse (trial and error), vagyis ismételten növelni kell a nonce-t és figyelni, hogy az új hash megfelelő-e. + +A jelenlegi 2187-es cél esetében, a hálózatnak átlagosan \~269 próbálkozást kell tennie, mielőtt valaki egy érvényes blokkot találna; általánosságban a hálózat minden 2016 blokk után újrakalibrálja a célt azért, hogy a hálózat egy résztvevője átlagosan minden tizedik percben egy új blokkot hozzon létre. Azért, hogy a bányászok kompenzálva legyenek ezért a számítási munkáért, minden blokk bányászát megilleti, hogy egy olyan tranzakciót tegyen a blokkba, amiben jóváír magának 12.5 BTC-t a semmiből. Továbbá ha bármely tranzakciónak nagyobb bemeneti egysége van, mint kimeneti, akkor a különbség a bányászokhoz került, mint egy "tranzakciós díj". Tulajdonképpen ez a BTC kibocsátásának egyetlen módja; a kezdeti állapot egyáltalán nem tartalmazott érméket. + +Hogy jobban megértsük a bányászat célját, nézzük meg, hogy mi történik egy rosszindulatú támadás esetében. Mivel a Bitcoin mögötti kriptográfia közismerten biztonságos, a támadó a rendszer azon részét fogja célba venni, melyet nem véd közvetlenül kriptográfia: a tranzakciók sorrendjét. A támadó stratégiája egyszerű: + +1. 100 BTC elküldése egy kereskedőnek valamilyen termékért cserébe (ideálisan egy digitális termék, gyors hozzáféréssel) +2. Megvárni amíg megérkezik a termék +3. Egy másik tranzakció létrehozása, amiben ugyanazt a 100 BTC-t küldi el magának +4. Meggyőzni a hálózatot, hogy a saját magának intézett tranzakció volt előbb. + +Amint az 1. lépés befejeződött, pár perc múlva valamelyik bányász beteszi a tranzakciót egy blokkba, mondjuk a 270 000-es számúba. Nagyjából egy órával később, ezután a blokk után öt új blokk kerül hozzáadásra a lánchoz, és minden egyes blokk közvetetten hivatkozik a tranzakcióra, így "megerősítve" azt. Ezen a ponton a kereskedő elfogadja a kifizetést véglegesítettként és kiszállítja a terméket; mivel feltételezzük, hogy ez egy digitális termék, a szállítás azonnali. Ekkor a támadó egy új tranzakciót hoz létre, amiben 100 BTC-t küld magának. Ha a támadó egyszerűen elküldené a tranzakciót a világba, nem kerülne feldolgozásra; mert a bányászok megpróbálják futtatni az `APPLY(S,TX)` függvényt és észreveszik, hogy a `TX` egy olyan UTXO-t akar felhasználni, ami már nem létezik a státusz szerint. Ehelyett a támadó csinál egy blokkláncelágazást (fork) úgy, hogy a 270-es blokknak egy új verzióját kezdi el bányászni, ami ugyanarra a 269-es „szülőblokkra” épül, de a régi helyett egy új tranzakcióval. Mivel a blokk adata különböző, így újra kell csinálni a proof-of-work-öt (munkaigazolás). Továbbá a támadó 270-es számú új blokk verziója egy különböző hash-sel rendelkezik, így az eredeti blokkok 271-től 275-ig nem "hivatkoznak" rá; így az eredeti lánc és a támadó új lánca teljesen különböző. Az a szabály, hogy az elágazásban a hosszabb blokkláncot kell igaznak tekinteni, így a törvényesen bányászók a 275-ös láncon fognak tovább dolgozni, míg a támadó egyedül dolgozik a 270-es láncon. Ahhoz, hogy a támadó saját blokkláncát tehesse a leghosszabbá, több számítási kapacitással kell rendelkeznie, mint a hálózat többi résztvevőjének együttvéve, hogy utolérhesse őket (innen ered az "51%-os támadás"). + +### Merkle-fák {#merkle-trees} + +![SPV Bitcoin-ban](./spv-bitcoin.png) + +_Bal: elegendő a csomópontok egy kis számát prezentálni a Merkle fában, hogy bizonyítsuk egy ág érvényességét._ + +_Jobb: bármely kísérlet, mely a Merkle fa egy részének megváltoztatására irányul, végül következetlenséghez fog vezetni valahol a láncon._ + +A Bitcoin egyik fontos skálázhatósági tulajdonsága, hogy a blokk egy több szintes adatstruktúrában van tárolva. A blokk hash valójában csak a blokk fejléc hashe, ez megközelítőleg 200 bájt adatot jelent, mely tartalmazza az időbélyeget, a nonce-t, az előző blokk hashét és a Merkle fának nevezett adat struktúra gyökér hashét, mely a blokkban lévő összes tranzakciót tárolja. A Merkle fa egyfajta bináris fa, ami csomópontokból áll; jelentős számú levél csomópontból a fa alján, amik az alapul szolgáló adatokat tartalmazzák, egy sor középső csomópontból, ahol minden csomópont két gyerekének a hashe, és végül egy gyökér csomópontból, amely szintén két gyerekének a hashéből keletkezett, és a fa "tetejét" reprezentálja. A Merkle fa célja, hogy lehetővé tegye a blokkban lévő adatok feldarabolását: egy csomópont letöltheti csak a blokk fejlécet egy forrásból; a fának számára releváns kis részét pedig egy másik forrásból, és mégis biztos lehet az adat helyességében. Az ok amiért ez működik az a hashek felfelé terjedése: ha egy rosszindulatú felhasználó megpróbál betenni egy hamis tranzakciót a Merkle fa aljára, az változást indít el az eggyel feljebb lévő csomópontban, mely megváltoztatja az afelett lévő csomópontot, végül a gyökér csomópont is megváltozik, így ezzel a blokk hash is, ebből kifolyólag a protokoll egy teljesen másik blokként regisztrálja azt (szinte biztosan érvénytelen munkabizonyítékkal). + +A Merkle fa protokoll vitathatatlanul elengedhetetlen a hosszú távú fenntarthatósághoz. Egy "teljes csomópontnak" a Bitcoin hálózatban, az amelyik az összes blokk egészét tárolja és feldolgozza, körülbelül 15 GB lemezterülettel kell rendelkeznie a Bitcoin hálózatban 2014 áprilisában, és ez havonta 1 GB-tal nő. Jelenleg ezt csak bizonyos asztali számítógépek tudják megvalósítani, telefonok nem, és a jövőben csak vállalkozások és hobbisták lesznek képesek részt venni. Egy "egyszerűsített fizetési hitelesítésnek (SPV)" nevezett protokoll lehetővé teszi egy másik csomópont típus létezését, melyeket "könnyű csomópontoknak" hívunk, ezek a hálózati résztvevők csak a blokk fejléceket töltik le, hitelesítik a munkabizonyítékot a blokk fejléceken és csak a számukra releváns tranzakciókhoz tartozó "ágakat" töltik le. Ez lehetővé teszi a könnyű csomópontoknak, hogy erős biztonsági garanciával meghatározhassák bármelyik Bitcoin tranzakció állapotát és aktuális egyenlegét, miközben a teljes blokklánc csak nagyon kis részét töltik le. + +### Alternatív blokkláncalkalmazások {#alternative-blockchain-applications} + +A mögöttes blokklánc másfajta koncepciókra történő alkalmazásának ötlete szintén hosszú történelemmel bír. 2005-ban Nick Szabo kiadta a [tulajdonosi jogokkal rendelkező biztonságos tulajdonok](https://nakamotoinstitute.org/secure-property-titles/) koncepciójával foglalkozó kiadványt. Ez a dokumentum leírja, hogy az „újdonságok a replikált adatbázis-technológiában” miként tesznek lehetővé egy blokkláncalapú rendszert, amely nyilvántartja, hogy ki milyen földterülettel rendelkezik, létrehozva ezzel egy kidolgozott keretrendszert, amely magában foglalja az olyan fogalmakat, mint a lakhatás, a hátrányos birtoklás és a grúz földadó. Abban az időben sajnos nem állt rendelkezésre hatékony replikált adatbázis-rendszer, ezért a protokollt a gyakorlatban soha nem valósították meg. 2009-től azonban a Bitcoin decentralizált konszenzusának kialakulása után számos alternatív alkalmazás kezdett gyorsan megjelenni. + +- **Namecoin** – a 2010-ben létrehozott [Namecoint](https://namecoin.org/) legjobban egy decentralizált névregisztrációs adatbázisként lehet leírni. Az olyan decentralizált protokollokban, mint a Tor, a Bitcoin és a BitMessage azért, hogy más emberek kölcsönhatásba léphessenek velük, a fiókok azonosítására van szükség valamilyen módon, de az összes létező megoldásban az egyetlen elérhető azonosítótípus egy álvéletlen hash, mint például `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. Ideális esetben olyan számlanevet szeretnénk használni, mint a „george”. A probléma azonban az, hogy ha egy személy létrehozhat egy „george” nevű fiókot, akkor valaki más is végigmehet ugyanezen a regisztrációs folyamaton, és annak adhatja ki magát. Az egyetlen megoldás az elsőt figyelembe vevő (first-to-file) paradigma, ahol az első regisztrálónak sikerül, a másodiknak pedig meghiúsul – ez a probléma tökéletesen megfelel a Bitcoin konszenzusprotokoll számára. A Namecoin a legrégebbi és a legsikeresebb névregisztrációs rendszerimplementáció, amely ezen az ötleten alapszik. +- **Colored coins** – a [colored coinok (színes érmék)](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) célja egy olyan protokoll megtestesítése, amely lehetővé teszi az emberek számára, hogy saját digitális valutát készítsenek, vagy egy egységgel rendelkező valutát, azaz digitális tokent hozzanak létre a Bitcoin blokkláncon. A colored coins protokollban egy új pénznemet „bocsát ki” valaki azáltal, hogy nyilvánosan hozzárendel egy színt egy adott Bitcoin UTXO-hoz, és a protokoll rekurzív módon meghatározza a többi UTXO színét annak az inputnak a színével, amelyet az őket létrehozó tranzakció költött (néhány speciális szabály vonatkozik a vegyes színű bemenetekre). Ez lehetővé teszi a felhasználók számára, hogy csak bizonyos színű UTXO-t tartalmazó pénztárcákat tartsanak fenn, és a szokásos bitcoinokhoz hasonlóan küldjék el őket, visszakeresve a blokkláncon, hogy meghatározzák a kapott UTXO-k színét. +- **Metacoins** – a metacoin mögött az az alapötlet áll, hogy legyen egy olyan protokoll, amely a Bitcoinra épül, és a Bitcoin tranzakciókat használja metacoin-tranzakciók tárolására, de más státuszváltozási függvénnyel rendelkezik, ami az `APPLY'`. Mivel a metacoin-protokoll nem tudja megakadályozni, hogy érvénytelen metacoin tranzakciók jelenjenek meg a Bitcoin blokkláncon, bekerült az a szabály, hogy ha az `APPLY'(S,TX)` hibaüzenetet ad vissza, a protokoll az `APPLY'(S,TX) = S` alapértelmezett értékre áll be. Ez egy egyszerű mechanizmust biztosít egy tetszőleges kriptovaluta-protokoll létrehozására, potenciálisan fejlett funkciókkal, amelyek nem valósíthatók meg a Bitcoinon belül, de a fejlesztési költségek alacsonyak, mivel a bányászat és a hálózatépítés bonyolultságait már a Bitcoin-protokoll kezeli. Metacoinokat már néhány pénzügyi szerződésfajtánál, névregisztrációnál és decentralizált tőzsdék esetében is használtak. + +Így általánosságban két megközelítés van egy konszenzus protokoll fejlesztésére: egy független hálózat építése és egy protokoll fejlesztése a Bitcoinra. Az előbbi megközelítést, ami bár meglehetősen sikeres a Namecoinhoz hasonló alkalmazások esetében, nehéz implementálni; minden egyedi implementációnak fel kell állítania egy független blokkláncot, illetve kifejleszteni és letesztelni a szükséges státuszváltozást és a hálózati kódot. Továbbá arra számítunk, hogy a decentralizált konszenzus technológiát használó alkalmazások a hatványtörvény szerinti eloszlást fogják követni, ahol az alkalmazások túlnyomó többsége túl kicsi lesz ahhoz, hogy indokolt legyen egy saját blokkláncot fenntartaniuk, és megjegyezzük, hogy a decentralizált alkalmazásoknak nagy osztályai léteznek, különösen a decentralizált autonóm szervezetek, melyeknek interakcióba kell lépniük egymással. + +Másfelől a Bitcoin alapú megközelítésnek az a hátulütője, hogy nem örökli a Bitcoin egyszerűsített fizetéshitelesítési tulajdonságait. Az SPV (egyszerűsített fizetéshitelesítés) működik a Bitcoin esetében, mivel felhasználja a blokklánc mélységét, mint érvényességi proxy; egy ponton, amint a tranzakciónak kellő mennyiségű őse van, biztonsággal állítható, hogy ezek érvényes részei a státusznak. Másfelől a blokklánc alapú meta protokollok nem kényszeríthetik a blokkláncot, hogy ne tartalmazza azokat a tranzakciókat, melyek nem érvényesek a saját protokolljuk kontextusában. Ezért egy teljesen biztonságos SPV meta-protokoll megvalósításnak vissza kell hivatkoznia a Bitcoin blokklánc elejéig annak megállapítására, hogy biztos-e a tranzakciók érvényessége. Jelenleg a Bitcoin alapú metaprotokollok összes „könnyű” implementációja egy megbízott szerverre bízza az adatszolgáltatást, ami nem a legoptimálisabb megoldás, mert a kriptovaluták elsődleges célja a bizalomigény megszüntetése. + +### Szkriptelés {#scripting} + +Még kiterjesztés nélkül is a Bitcoin protokoll lehetővé teszi az „okosszerződések” egy kezdetleges változatát. A Bitcoinban lévő UTXO-kat nem csak publikus kulcsok birtokolhatják, hanem bonyolultabb szkriptek is, melyeket egy egyszerű stack alapú programozási nyelvvel lehet kifejezni. Ebben a paradigmában az UTXO-t elköltő tranzakcióknak adatokat kell szolgáltatni a szkriptek kielégítésére. Valójában még az alapvető publikus kulcs tulajdonjog mechanizmus is egy szkripten keresztül valósul meg: a szkript egy elliptikus görbe aláírást használ bemenetként, megerősíti a tranzakció és az UTXO-t birtokló cím szerint és 1-et ad vissza, ha az érvényesítés sikeres, ellenkező esetben 0-át. Más bonyolultabb szkriptek is léteznek további különböző felhasználási esetekre. Például létre lehet hozni egy olyan szkriptet, mely három privát kulcsból kettő aláírását igényli az érvényesítéshez ("multisig"), a vállalati számlák, biztonságos megtakarítási számlák és néhány kereskedői letét számára hasznos beállítás. A szkriptek felhasználhatók a számítási problémák megoldásáért járó jutalmak kifizetésére is, sőt össze lehet állítani egy olyan szkriptet, amely valami olyasmit mond, hogy "ez a Bitcoin UTXO a tiéd, ha tudsz egy SPV bizonyítékot nyújtani arra, hogy nekem küldtél egy ilyen címletű Dogecoin tranzakciót", mely lényegében lehetővé teszi a decentralizált kereszt-kriptovaluta váltást. + +Azonban a Bitcoinban implementált szkript nyelvnek számos fontos megkötése van: + +- **Turing-teljesség hiánya** – vagyis, bár van egy nagy számítási részhalmaz, amelyet a Bitcoin szkriptnyelv támogat, közel sem támogat mindent. A fő kategória a hiányzó ciklusok. Ennek az az oka, hogy elkerüljük a végtelen ciklusokat a tranzakció ellenőrzések során; elméletileg ez egy leküzdhetetlen akadály a szkriptprogramozók számára, mivel bármely ciklus szimulálható úgy, hogy egyszerűen megismételjük több alkalommal a mögöttes kódot egy „if” (ha) utasítással, de ez nagyon kis hatékonyságú szkriptekhez vezet. Például egy alternatív elliptikusgörbe-aláírási algoritmus implementálása valószínűleg 256 ismételt szorzási kört igényelne, melynek mindegyike egyenként szerepelne a kódban. +- **Értékvakság** – nincs olyan UTXO-szkript, amely képes lenne szofisztikáltan irányítani a kiutalható mennyiséget. Például egy orákulumszerződés komoly felhasználási területe a hedging szerződés lenne, ahova A és B 1000 USD értékű BTC-t tesz be és 30 nappal később a szkript elküld 1000 USD értékű BTC-t A részére a maradékot pedig B részére. Ez egy orákulumot igényel, mely meghatározza 1 BTC értékét USD-ben, de még így is hatalmas előrelépés a bizalom és az infrastrukturális követelmények szempontjából a teljesen centralizált megoldásokhoz képest. Azonban mivel az UTXO mindent vagy semmit elven működik, ennek az egyedüli módja, ha sok UTXO-t használunk különböző egységekkel (például egy 2k UTXO minden k-ra egészen 30-ig) és az orákulum eldönti, hogy melyik UTXO-t küldi A-nak és melyiket B-nek. +- **Státuszhiány** – az UTXO lehet elköltött vagy elköltetlen; nincs lehetőség többlépcsős szerződésekre vagy szkriptekre, amelyek megtartanak minden más belső státuszt ezen túl. Ez megnehezíti a többlépcsős opciós szerződések, decentralizált csereajánlatok vagy kétlépcsős kriptográfiai elköteleződési protokollok létrehozását (ami szükséges a biztonságos számítási kompenzációhoz). Ez azt is jelenti, hogy az UTXO csak egyszerű, egyszeri szerződések és nem bonyolultabb „státuszos” szerződések, például decentralizált szervezetek létrehozására használható, és a metaprotokollok megvalósítását megnehezíti. A bináris állapot az értékvaksággal kombinálva azt is jelenti, hogy egy másik fontos funkció, a kiutalási limitek beállítása, sem lehetséges. +- **Blokkláncvakság** – az UTXO nem tud az olyan blokkláncadatokról, mint a nonce, az időbélyeg vagy az előző blokkhash. Ez súlyosan korlátozza a szerencsejátékokban és számos más kategóriában történő alkalmazásokat azáltal, hogy megfosztja a szkriptnyelvet a véletlenszerűség értékes forrásától. + +Így meglátásunk szerint háromféleképpen lehet fejlett alkalmazásokat fejleszteni egy kriptovalutára: új blokklánc indítása, a Bitcoin szkripting használata és egy meta protokoll fejlesztése Bitcoinra. Egy új blokklánc indítása lehetővé teszi a korlátlan szabadságot a funkciókészlet építésében, de a fejlesztési idő, a bootstrapping és a biztonság árán. A szkriptek használata egyszerűen megvalósítható és szabványosítható, de nagyon korlátozott a képességeiben, és a meta protokollok, míg egyszerűek, nehezen skálázhatóak. Az Ethereummal egy olyan alternatív keretrendszert szeretnénk létrehozni, mely még jobban megkönnyíti a fejlesztést, valamint erősebb könnyű kliens tulajdonságokkal rendelkezik, egyúttal az alkalmazásoknak egy közös gazdasági környezetet és blokklánc biztonságot biztosít. + +## Ethereum {#ethereum} + +Az Ethereum célja egy alternatív protokoll létrehozása decentralizált alkalmazások fejlesztésére, különböző kompromisszumokkal, amelyről úgy hisszük, hogy nagyon hasznos lesz a decentralizált alkalmazások nagy részének, különös tekintettel az olyan esetekre, ahol fontos a gyors fejlesztési idő, a biztonság a kisméretű és ritkán használt alkalmazások számára, és a különböző alkalmazások közötti nagyon hatékony együttműködés. Az Ethereum ezt úgy éri el, hogy felépíti azt, ami lényegében a végső absztrakt alapréteg: egy blokkláncot beépített Turing-teljes programozási nyelvvel, mely lehetővé teszi bárki számára az okosszerződés írást és a decentralizált alkalmazás fejlesztést, ahol létrehozhatják a saját tetszőleges tulajdonjogi szabályaikat, tranzakció formátumukat és a státuszváltozási függvényeket. A Namecoin lecsupaszított verziója két sornyi kódból megírható, a többi protokoll, mint például a valuták és az identitás rendszerek pedig kevesebb, mint húsz sorból. Okosszerződések, olyan kriptográfiai „dobozok”, melyek értéket tartalmaznak és csak akkor nyílnak ki, amikor bizonyos feltételek teljesülnek, szintén építhetőek a platformra sokkal nagyobb erővel, mint amit a Bitcoin szkriptelés kínál, a Turing-teljesség, értéktudatosság, blokklánctudatosság és a státusz hozzáadott értéke miatt. + +### Ethereum-számlák {#ethereum-accounts} + +Az Ethereumban a státuszt „számláknak” nevezett objektumok alkotják, ahol minden egyes számla egy 20 bájtos címmel rendelkezik és a státuszváltozást a számlák közötti közvetlen érték- és információátadás végzi. Az Ethereum-számlák négy mezőt tartalmaznak: + +- A **nonce**, egy számláló, mely biztosítja, hogy minden tranzakció csak egyszer kerül feldolgozásra +- A számla aktuális **ether-egyenlege** +- A számla **szerződéskódja**, ha van +- A számla **tárhelye** (alapértelmezetten üres) + +Az „ether” az Ethereum elsődleges, belső kriptoüzemanyaga és a tranzakciós díj kifizetésére lehet használni. Általánosságban kétfajta számlatípus létezik: **külső tulajdonú számlák**, melyeket privát kulcsok irányítanak és **szerződéses számlák**, melyeket a szerződéskódjuk irányít. A külső tulajdonú számláknak nincs kódjuk, és az adott személy üzenetet küldhet egy külső tulajdonú számláról egy tranzakció létrehozásával és aláírásával; a szerződéses számla esetében minden esetben, amikor e számla üzenetet kap, aktiválódik a kódja, ami lehetővé teszi a belső tárhely írását és olvasását, új üzenetek küldését vagy szerződés létrehozását. + +Fontos megjegyezni, hogy az Ethereumban a szerződések nem olyan egyezmények, amelyet teljesíteni vagy betartani kell; inkább „önálló ügynökök”, akik az Ethereum végrehajtási környezetében élnek, és végrehajtanak egy adott kóddarabot, amikor beindítja azokat egy üzenet vagy tranzakció, továbbá közvetlen ellenőrzésük alatt tartják saját ether-egyenlegüket és saját kulcs-érték-adatbázisukat a tartós változók nyomon követésére. + +### Üzenetek és tranzakciók {#messages-and-transactions} + +A „tranzakció” kifejezést az Ethereumban egy aláírt adatcsomagra használjuk, ami egy külső tulajdonú számláról érkező üzenetet tartalmaz. A tranzakció a következőket tartalmazza: + +- Az üzenet címzettje +- A küldőt azonosító aláírás +- Az ether összeg, amit a küldő át akar utalni a címzettnek +- Egy opcionális adat mező +- A `STARTGAS` érték, ami a tranzakció-végrehajtás számítási lépéseinek maximális számát jelenti +- A `GASPRICE` érték, ami a számítás lépésenkénti díját jelenti, amit a feladó fizet + +Az első három olyan standard mező, ami minden kriptovalutánál megtalálható. Az adatmezőnek alapértelmezés szerint nincs funkciója, de a virtuális gép rendelkezik egy opkóddal, amelyet a szerződés használhat az adatok elérésére; például amikor egy szerződés domainregisztrációs szolgáltatásként működik a blokkláncon, akkor úgy értelmezheti a hozzá érkező adatot, hogy az két „mezőt” tartalmaz, az első a regisztrálandó domain, a második az IP-cím, amelyre regisztrálni kell. A szerződés kiolvassa ezeket az adatokat az üzenetből, és a megfelelő helyükre helyezi azokat az adattárban. + +A `STARTGAS` és `GASPRICE` mezők kritikusak az Ethereum szolgáltatásmegtagadás elleni védekezési modelljében. Azért, hogy megelőzzük a véletlen vagy ártó szándékú végtelen ciklusokat vagy más számítási pazarlással járó kódot, minden egyes tranzakciónak be kell állítani egy határt, hogy mennyi számítási lépést hajthat végre a kód futtatása. A számítás alapvető egysége a „gáz”; általában egy számítási lépés 1 gázba kerül, de egyes műveletek többet igényelnek, mert számítási szempontból drágábbak, vagy növelik a státuszként tárolandó adatok mennyiségét. Továbbá minden egyes tranzakciós adatban található bájt után 5 gáz is felszámításra kerül. A díjrendszer célja, hogy megkövetelje a támadótól, hogy minden általa felhasznált erőforrásért arányosan fizessen, beleértve a számítást, a sávszélességet és a tárhelyet is; ennélfogva minden olyan tranzakció esetében, amelynek eredményeként a hálózat ezeknek az erőforrásoknak bármelyikét nagyobb mennyiségben fogyasztja, az erőforrások növekedésével nagyjából arányos gázköltséggel kell számolni. + +### Üzenetek {#messages} + +A szerződéseknek megvan a lehetőségük, hogy „üzeneteket” küldjenek más szerződéseknek. Az üzenetek olyan virtuális objektumok, amelyek nincsenek sorosítva és csak az Ethereum futtatási környezetben léteznek. Az üzenet a következőket tartalmazza: + +- Az üzenet küldője (magától értetődő) +- Az üzenet címzettje +- Az üzenettel küldendő ether összege +- Egy opcionális adatmező +- A `STARTGAS` érték + +Lényegében az üzenet olyan mint a tranzakció, kivéve, hogy nem külső szereplő, hanem a szerződés hozta létre. Üzenet akkor jön létre, amikor a kódot végrehajtó szerződés azt a `CALL` opkódot futtatja, amely előállítja és végrehajtja az üzenetet. A tranzakcióhoz hasonlóan az üzenet is a címzettszámla kódjának lefuttatását eredményezi. Ezáltal a szerződéseknek is ugyanúgy lehet kapcsolatuk másik szerződésekkel, mint a külső szereplőknek. + +Megjegyzendő, hogy a tranzakciók vagy szerződések által kiszabott gázdíj a teljes gázmennyiségre vonatkozik, amit az adott tranzakció és az összes végrehajtási folyamat felhasznált. Például, ha az A külső szereplő egy tranzakciót küld B-nek 1000 gázzal, és B 600 gázt fogyaszt, mielőtt üzenetet küldene C-nek, és C belső végrehajtása 300 gázt fogyaszt, mielőtt visszatérne, akkor B még további 100 gázt költhet el. + +### Az Ethereum státuszváltozási függvénye {#ethereum-state-transition-function} + +![Ether státuszváltozás](./ether-state-transition.png) + +Az Ethereum státuszváltozási függvénye, az `APPLY(S,TX) -> S'` a következőképpen írható le: + +1. Ellenőrzi, hogy a tranzakció jól formált-e (megfelelő az értékek száma), az aláírás érvényes-e, és a nonce megegyezik-e a feladó számláján szereplő nonce-szal. Ha nem, hibát küld vissza. +2. Kiszámítja a tranzakciós illeték (`STARTGAS * GASPRICE`), és meghatározza a küldő címét az aláírásból. Levonja a díjat a küldő fél számlaegyenlegéről és növeli a küldő fél nonce-át. Ha nincs elegendő egyenleg, hibát küld vissza. +3. Beállítja a `GAS = STARTGAS` kezdőértéket, és bizonyos mennyiségű, bájtonkénti gázt elvesz a tranzakció bájtjainak kifizetéséhez. +4. Átutalja a tranzakció értékét a küldő számlájáról a fogadó számlájára. Ha a fogadó számla még nem létezik, létrehozza azt. Ha a fogadó számla egy szerződés, futtatja a szerződés kódját, addig amíg a tranzakció teljesül, vagy ameddig a végrehajtás során elfogy a gáz. +5. Ha az értékátutalás azért nem sikerült, mert a feladónak nem volt elegendő pénze, vagy a kódfuttatás során elfogyott a gáz, akkor minden állapotváltozást visszavon, kivéve a díjak kifizetését, majd a díjakat a bányász számlájához adja. +6. Máskülönben az összes fennmaradó gázdíjat visszatéríti a feladónak, az elfogyasztott gázért fizetett díjakat pedig elküldi a bányásznak. + +Tegyük fel, hogy a szerződés kódja a következő: + +```py +if !self.storage[calldataload(0)]: + self.storage[calldataload(0)] = calldataload(32) +``` + +Megjegyzendő, hogy a valóságban a szerződés alacsony szintű EVM programozási nyelven van írva; ez a példa az érthetőség kedvéért az egyik magas szintű programozási nyelven, a Serpentben íródott, és le lehet fordítani EVM-nyelvre. Tegyük fel, hogy a szerződés tárhelye az elején üres, és egy 10 ether értékű tranzakciót elküldenek 2000 gázzal, 0,001 ether gázárral, és 64 bájtnyi adattal, ahol a 0–31. bájtok a `2` számot, a 32–63. bájtok pedig a karakterláncot ábrázolják (`CHARLIE`). A státuszváltozási függvény folyamata ebben az esetben a következőképpen alakul: + +1. Ellenőrzi, hogy a tranzakció érvényes és jól formált-e. +2. Ellenőrzi, hogy a tranzakció küldőjének van-e legalább 2000 \* 0,001 = 2 ethere. Ha igen, levon 2 ethert a küldő számlájáról. +3. Beállítja a gáz = 2000 kezdőértéket; feltételezve, hogy a tranzakció 170 bájt hosszú és a bájtdíj 5, levon 850-et úgy, hogy 1150 gáz marad. +4. További 10 ethert levon a küldő számlájáról, és hozzáadja azt a szerződés számlájához. +5. Lefuttatja a kódot. Ebben az esetben ez egyszerű: a kód ellenőrzi, hogy a szerződés `2`-es indexén lévő tárhelyét használja-e; ha észreveszi, hogy nem, akkor a tárhelyindexet beállítja `2`-re, az értéket pedig `CHARLIE`-ra. Tegyük fel, hogy ez 187 gázba kerül, így a fennmaradó gáz összege 1150 – 187 = 963 +6. 963 \ * 0,001 = 0,963 ethert visszaad a feladó számlájára, és visszatér az eredményül kapott státuszhoz. + +Ha a tranzakció fogadójának oldalán nem lenne szerződés, akkor a teljes tranzakciós illeték egyszerűen megegyezne a megadott `GASPRICE` értékével megszorozva a tranzakció hosszával bájtokban, és a tranzakcióval együtt elküldött adatok lényegtelenek lennének. + +Megjegyzendő, hogy az üzenetek és a tranzakciók visszafordítása ugyanúgy működik: ha az üzenet végrehajtása során elfogy a gáz, akkor az üzenet végrehajtása és az ebből következő összes többi végrehajtás visszaáll, de a „szülő végrehajtásokat” nem kell visszaállítani. Ez azt jelenti, hogy egy szerződés „biztonságosan” meghívhat egy másik szerződést, mivel ha A G mennyiségű gázzal hívja meg B-t, akkor A végrehajtása garantáltan legfeljebb G mennyiségű gázveszteséget okoz. Végül megjegyzendő, hogy van egy műveleti kód (`CREATE`), amely létrehozza a szerződést; aminek a végrehajtási mechanikája általában hasonló a `CALL`-hoz vagy híváshoz, azzal a kivétellel, hogy a végrehajtás kimenete határozza meg az újonnan létrehozott szerződés kódját. + +### Kódfuttatás {#code-execution} + +Az Ethereum szerződésekben szereplő kód alacsony szintű, stack-alapú bájtkód nyelven íródott, amelyet Ethereum virtuális gépi (EVM) kódnak neveznek. A kód bájtok sorozatából áll, ahol mindegyik bájt egy műveletet képvisel. A kódfuttatás általában egy végtelen ciklus, ami a művelet ismételt végrehajtásából áll az aktuális programszámlálón (amely nullától kezdődik), majd eggyel növeli a számlálót addig, amíg el nem éri a kód végét, vagy egy hibát, illetve ` STOP ` vagy ` RETURN ` utasítást észlel. A műveletek háromféle helyhez férnek hozzá, ahol adatokat tárolhatnak: + +- A **stack** egy utolsóként be, elsőként ki (LIFO) tárolóhely, ahol az értékek rárakhatók (push) a stackre és levehetők (pop) a stack tetejéről +- **Memória **, egy végtelenül bővíthető bájttömb +- A szerződés hosszú távú ** tárhelye **, egy kulcs-érték tároló. A stack-től és a memóriától eltérően, amelyek a számítás befejezése után nullázódnak, ez a tároló hosszú ideig fennmarad. + +A kód hozzáférhet a bejövő üzenet értékéhez, feladójához és adataihoz, valamint a blokkfejléc adataihoz, és a kód egy bájt adattömböt is visszaadhat kimenetként. + +Az EVM-kód formális végrehajtási modellje meglepően egyszerű. Amíg az Ethereum virtuális gép fut, teljes számítási állapota meghatározható a következő értéksorral: `(block_state, transaction, message, code, memory, stack, pc, gas)`, ahol a `block_state` az összes számlát tartalmazó globális státusz, amely magában foglalja az egyenlegeket és a tárolóhelyeket. Minden egyes végrehajtási kör elején, az aktuális utasítás megtalálható a `code`-nak a `pc` által meghatározott bájtja által (vagy 0 ha `pc >= len(code)`), és minden utasításnak megvan a maga meghatározása abból a szempontból, hogy milyen hatással van az értéksorra. Például, `ADD` elvesz két elemet a stack-ből és visszarakja az összegüket, csökkenti a `gas` értékét 1-gyel, növeli a `pc` értékét 1-gyel, az `SSTORE` leveszi a stack két legfelső elemét és behelyezi a második elemet a szerződés tárhelyébe az első elem által meghatározott indexen. Bár számos módja van az Ethereum virtuális gép végrehajtás-optimalizálásának, futásidejű fordítással (röpfordítás), az Ethereum alapvető megvalósítása néhány száz kódsorban elvégezhető. + +### Blokklánc és bányászat {#blockchain-and-mining} + +![Ethereum alkalmazási blokkdiagram](./ethereum-apply-block-diagram.png) + +Az Ethereum blokklánc sok szempontból hasonló a Bitcoin blokklánchoz, bár vannak közöttük különbségek. A fő különbség az Ethereum és a Bitcoin között a blokklánc felépítésének tekintetében az, hogy a Bitcointól eltérően (amely csak a tranzakciós lista másolatát tartalmazza) az Ethereum blokkok tartalmazzák a tranzakciós lista és a legutóbbi státusz másolatát is. Emellett két másik érték, a blokk száma és a nehézsége is tárolva van a blokkban. Az Ethereum blokk validációs algoritmusa a következő: + +1. Ellenőrzi, hogy az előző blokk, amelyre a blokk hivatkozik, létezik és érvényes. +2. Ellenőrzi, hogy a blokk időbélyege nagyobb-e, mint az előző blokké és kevesebb mint 15 perc telt el azóta +3. Ellenőrzi, hogy a blokk száma, a nehézség, a tranzakciógyökér, az uncle-gyökér és a gázkorlátozás (különféle alacsony szintű, Ethereum-specifikus fogalmak) érvényesek-e. +4. Ellenőrzi, hogy a blokk proof-of-workje érvényes-e. +5. Legyen `S[0]` az előző blokk után lévő állapot. +6. Legyen `TX` a blokk tranzakciólistája `n` tranzakcióval. A `0...n-1` összes `i`-je esetében állítsa be a következőt: `S[i+1] = APPLY(S[i],TX[i])`. Ha valamelyik alkalmazás hibát ad vissza, vagy a blokkban az eddig a pontig elfogyasztott gáz összmennyisége túllépi a `GASLIMIT` értéket, hibát ad vissza. +7. Legyen az `S_FINAL` `S[n]`, de hozzáadva a bányásznak fizetett blokkjutalmat. +8. Ellenőrzi, hogy az `S_FINAL` állapot Merkle-fagyökere azonos-e a blokkfejlécben megadott végleges státusszal. Ha igen, a blokk érvényes; ellenkező esetben nem az. + +A megközelítés első pillantásra nem tűnhet túl hatékonynak, mert minden blokkal a teljes státuszt kell tárolni, de a hatékonyság a Bitcoinéhoz hasonló. Ennek az az oka, hogy a státusz fastruktúrában tárolódik, és minden blokk után a fa csak egy kis részét kell megváltoztatni. Így általában két szomszédos blokk között a fa túlnyomó részének azonosnak kell lennie, ezért az adatokat egyszer kell tárolni és kétszer lehet rájuk hivatkozni mutatók (azaz részfák hasheinek) használatával. Ennek megvalósításához egy speciális „Patricia-fát” használnak, beleértve a Merkle-fa koncepciójának módosítását is, amely lehetővé teszi a csomópontok hatékony beillesztését és törlését, nem csak megváltoztatását. Ezen túlmenően, mivel az összes státuszinformáció része az utolsó blokknak, nincs szükség a teljes blokkláncelőzmények tárolására – ez egy olyan stratégia, amely ha alkalmazható lenne a Bitcoinra, 5–20-szoros megtakarítást eredményezne a tárhelyben. + +Gyakran felmerül az a kérdés, hogy „hol” történik a szerződés kódjának végrehajtása a fizikai hardver szempontjából. Erre egyszerű a válasz: a szerződés kódjának végrehajtási folyamata a státuszváltozási függvény definíciójának része, amely a blokk validációs algoritmus része, tehát ha egy tranzakciót hozzáadunk a `B` blokkhoz, akkor a tranzakció által létrehozott kód végrehajtását minden csomópont végrehajtja, most és a jövőben is, amelyek letöltik és validálják a `B` blokkot. + +## Alkalmazások {#applications} + +Az Ethereumon általánosságban háromféle alkalmazás létezik. Az első kategória a pénzügyi alkalmazások, amelyek hatékonyabb módszereket kínálnak a felhasználóknak a pénzük kezelésére és szerződéskötésre. Ebbe beletartoznak a devizák, a derivatív pénzügyi eszközök, a fedezeti ügyletek, a megtakarításitárcák, végrendeletek, és végül akár teljes körű munkaszerződések egyes kategóriái. A második kategória a félig pénzügyi alkalmazások, amelyek a pénzzel kapcsolatosak, de a tevékenységeiknek van egy jelentős, nem pénzügyi oldala is; erre tökéletes példa az önérvényesítő jutalmak a számítási problémák megoldásért. Végül vannak olyan alkalmazások, mint az online szavazás és a decentralizált irányítás, amelyek egyáltalán nem pénzügyi vonatkozásúak. + +### Tokenrendszerek {#token-systems} + +A blokkláncon alapuló tokenrendszereknek számos alkalmazási területe van, mint az alvaluták, amelyek olyan eszközöket képviselnek, mint az USA dollár vagy az arany, a vállalati részvények, az okos tulajdont képviselő egyedi tokenek, a biztonságos és hamisíthatatlan kuponok, vagy amelyeknél semmilyen kapcsolat sincs a hagyományos értékhez, csak ösztönzéshez használják azokat. A tokenrendszereket meglepően egyszerű módon létre lehet hozni az Ethereumon. Kulcsfontosságú megérteni azt, hogy a pénznem vagy a tokenrendszer alapvetően egy műveletből álló adatbázis: vonjon le X egységet A-tól, és adjon X egységet B-nek, azzal a feltétellel, hogy 1) A-nak a tranzakció előtt legalább X egysége volt és 2) a tranzakciót A jóváhagyta. A tokenrendszer megvalósításához mindössze annyi kell, hogy ezt a logikát beépítsék egy szerződésbe. + +Az alapkód a tokenrendszer megvalósítására Serpent programnyelven a következőképpen néz ki: + +```py +def send(to, value): + if self.storage[msg.sender] >= value: + self.storage[msg.sender] = self.storage[msg.sender] - value + self.storage[to] = self.storage[to] + value +``` + +Ez lényegében a „bankrendszer” státuszváltozási függvényének szó szerinti megvalósítását jelenti, amely ebben a dokumentumban fentebb már le lett írva. Néhány extra kódsort hozzá kell adni, hogy biztosítsuk a pénzegységek elosztásának kezdeti lépését, néhány másik szélsőséges esetben is, és ideális esetben egy függvényt is hozzáadunk, ami lehetővé teszi másik szerződéseknek, hogy lekérdezzék egy cím számlaegyenlegét. De ennyi az egész. Elméletileg a pénznemként működő Ethereum-alapú tokenrendszerek tartalmazhatnak egy másik fontos jellemzőt, ami a Bitcoin-alapú blokkláncon található pénzeszközöknél hiányzik: a tranzakciós díjak közvetlen fizetése ugyanabban a pénznemben. Ez úgy lehetne megvalósítható, hogy a szerződés fenntartana egy ether egyenleget, amelyből visszatérítené a feladónak a díjakra használt ethert, és ezt úgy töltené fel, hogy összegyűjti a díjakra beszedett belső valutaegységeket, és egy folyamatosan futó aukción továbbértékesíti azokat. A felhasználóknak tehát etherrel kellene „aktiválniuk” a számláikat, de onnantól, hogy az ether ott van, újrafelhasználható, mert a szerződés minden alkalommal visszatérítené. + +### Pénzügyi derivatívák és stabil értékű valuták {#financial-derivatives-and-stable-value-currencies} + +A pénzügyi derivatívák az „okosszerződés” leggyakoribb alkalmazásai, és az egyik legegyszerűbben megvalósíthatók a kód szempontjából. A pénzügyi szerződések végrehajtása során az a fő kihívás, hogy többségük külső árfolyamra való hivatkozást igényel; például kívánatos alkalmazás egy olyan okosszerződés, amely fedezetet ad az ether (vagy más kriptovaluta) árfolyamingadozására az amerikai dollárral szemben, de ehhez a szerződésnek tudnia kell az ETH/USD értékét. Ennek legegyszerűbb módja egy adott fél (például a NASDAQ) által fenntartott „adatforrás” szerződés, amelynek célja, hogy az adott fél képes legyen a szerződés szükség szerinti frissítésére, és egy olyan felület biztosítása, amely lehetővé teszi más szerződések számára, hogy üzenetet küldjenek a szerződésnek, és a válaszban megkapják az árat. + +Tekintettel erre a kritikus összetevőre, a fedezeti szerződés a következőképpen nézne ki: + +1. Megvárja, amíg az A fél berak 1000 ethert. +2. Megvárja, amíg a B fél berak 1000 ethert. +3. Az adatforrás szerződés lekérdezésén keresztül kiszámított 1000 ether USD értékének rögzítése a tárolóhelyen, mondjuk, hogy ez x USD. +4. 30 nap elteltével hagyja, hogy A vagy B „újraaktiválja” a szerződést annak érdekében, hogy x USD értékű ethert küldjön (amelyet úgy számol ki, hogy újból lekérdezi az adatforrás szerződést az új árról) A-nak, a többit pedig B-nek. + +Egy ilyen szerződés jelentős potenciállal bírna a kriptokereskedelemben. Az egyik fő probléma, amire gyakran hivatkoznak a kriptovalutával kapcsolatban, hogy ingatag az árfolyama; bár sok felhasználó és kereskedő vágyik a kriptográfiai eszközök biztonságára és kényelmére, nem biztos, hogy vállalja azt az eshetőséget, hogy egyetlen nap alatt elveszítheti pénzeszközei értékének 23%-át. Eddig a leggyakrabban a kibocsátó által biztosított eszközöket javasolták; azon elképzelés alapján, hogy a kibocsátó létrehoz egy pénzeszközt, ahol joga van kibocsátani és visszavonni egységeket, és mindenkinek egy egységnyi pénzeszközt ad, aki (offline) cserébe ad neki egy meghatározott, egy egységnyi alapul szolgáló eszközt (például arany, USA dollár). A kibocsátó ezután megígéri, hogy az alapul szolgáló eszköz egy egységét adja annak, aki visszaküldi a kriptoeszköz egy egységét. Ez a mechanizmus lehetővé teszi a nem kriptográfiai eszköz kriptográfiai eszközzé való eszkalálását, feltéve, hogy a kibocsátó megbízható. + +A gyakorlatban azonban a kibocsátók nem mindig megbízhatóak, és egyes esetekben a banki infrastruktúra túl gyenge vagy túl ellenséges ahhoz, hogy ilyen szolgáltatások létezzenek. A pénzügyi derivatívák alternatívát kínálnak. Itt ahelyett, hogy egyetlen kibocsátó biztosítaná az eszközök fedezetére szolgáló alaptőkét, a spekulánsok decentralizált piacon való fogadásai – például arról, hogy egy kriptográfiai referencia eszköz (például az ETH) ára emelkedni fog-e – játsszák ezt a szerepet. A kibocsátóktól eltérően a spekulánsoknak nincs lehetőségük az ügylettel kapcsolatos kötelezettségük elmulasztására, mert a fedezeti szerződés letétben tartja a pénzeszközeiket. Fontos megjegyezni, hogy ez a megközelítés nincs teljesen decentralizálva, mert még mindig megbízható forrásra van szükség az árjegyző szerepének betöltésére, bár már ez is hatalmas előrelépés az infrastruktúrakövetelmények csökkentése szempontjából (ellentétben a kibocsátóval, az árfolyamkiadáshoz nem szükséges engedély, és valószínűleg a szólásszabadság kategóriájába sorolhatók), és a csalás lehetőségét is csökkenti. + +### Identitás- és hírnévrendszerek {#identity-and-reputation-systems} + +A legkorábbi alternatív kriptovaluta, a [Namecoin](http://namecoin.org/), egy Bitcoinhoz hasonló blokkláncot próbált meg használni egy névregisztrációs rendszer biztosításához, ahol a felhasználók a nevüket egy nyilvános adatbázisba regisztrálhatták több más adat mellett. A leggyakrabban idézett alkalmazási eset a [DNS](https://wikipedia.org/wiki/Domain_Name_System) rendszerre, a domain nevek, például „bitcoin.org” (vagy a Namecoin esetében „bitcoin.bit”) leképezése egy IP-címre. Egyéb alkalmazási esetek például az e-mail-hitelesítések és a potenciálisan haladóbb reputációs rendszerek. Nézzünk egy alap szerződést, amely Namecoin-féle névregisztrációt biztosít az Ethereumon: + +```py +def register(name, value): + if !self.storage[name]: + self.storage[name] = value +``` + +A szerződés nagyon egyszerű; gyakorlatilag egy adatbázis az Ethereum hálózatban, amelyhez hozzá lehet adni, de nem lehet módosítani vagy törölni belőle. Bárki regisztrálhat nevet valamilyen értékkel, majd a regisztráció örökre megmarad. Egy kifinomultabb névregisztrációs szerződésben szerepelne egy „függvényzáradék”, amely engedné a többi szerződésnek a lekérdezést, valamint a név „tulajdonosának” (azaz az első regisztrálónak) egy mechanizmust, az adat módosítására vagy a tulajdonjog átadására. Bárki hozzáadhat reputációt és digitális azonosító (web-of-trust) funkcionalitást az egész tetejére. + +### Decentralizált fájltárhely {#decentralized-file-storage} + +Az elmúlt években számos népszerű online tárhely startup tűnt fel, amelyek közül az egyik legkiemelkedőbb a Dropbox, akik lehetővé teszik ügyfeleiknek, hogy a merevlemezük biztonsági mentését feltöltsék, majd a szolgáltatással tároltassák azt, majd a felhasználó havidíj ellenében férhet hozzá az adataihoz. Azonban ezen a ponton a fájltárhely piac relatíve nem hatékony; ha megvizsgáljuk a különböző meglévő megoldásokat, láthatjuk, hogy különösen a „furcsa zónában”, a 20–200 GB szinten, ahol sem az ingyenes kvóták, sem a vállalati szintű kedvezmények nem jelennek meg, a mainstream fájltárolási költségek havi árszintje ott tart, hogy egy hónapért többet fizet az átlag felhasználó, mint egy teljes merevlemezért. Az Ethereum szerződések lehetővé teszik egy decentralizált fájltárolási ökoszisztéma fejlesztését, ahol az egyes felhasználók kis mennyiségű pénzt kereshetnek azzal, hogy bérbeadják saját merevlemezüket és a használaton kívüli tárhelyüket, ezzel is lefelé hajtva a tárolás költségeit. + +Az ilyen eszközök kulcsfontosságú megerősítő eleme az általunk „decentralizált Dropbox szerződésnek” elnevezett megoldás. A szerződés a következő módon működik. Először a kívánt adatokat blokkokra bontjuk, adatvédelmi okokból titkosítjuk, majd egy Merkle-fát építünk belőle. Ezután létrehozunk egy szerződést azzal a szabállyal, hogy minden N blokkban a szerződés egy véletlen indexet választ ki a Merkle-fában (az előző blokkhash segítségével a szerződés kódjából véletlenszerűen), majd X ethert adunk az első entitásnak, hogy egy egyszerűsített fizetéshitelesítéssel lássa el a tranzakciót, például a blokk tulajdonjogát bizonyító elemmel az adott indexen a fában. Amikor egy felhasználó újra le szeretné tölteni a fájlt, egy mikrofizetési csatornás protokollt használhat (például 1 szabo 32 kilobájt adatért) a fájl lekérésére; a leginkább költséghatékony megközelítés az, amikor a fizető félnek csak a legvégén kell publikálnia a tranzakciót, ahelyett, hogy a tranzakciót egy kissé jövedelmezőbbre cserélné le ugyanazzal a nonce-al 32 kilobájtonként. + +A protokoll egyik fontos jellemzője, hogy bár úgy tűnik, hogy valaki több véletlen csomópontot bíz meg azzal, hogy ne felejtse el a fájlt, a saját kockázatát a nullához közelire csökkentheti azzal, hogy a fájlt több részre bontja titkos megosztással, majd figyeli a szerződést, hogy lássa az egyes darabok továbbra is valamelyik csomópont birtokában maradnak. Ha egy szerződés továbbra is fizet, akkor kriptográfiai bizonyíték van arra, hogy valaki továbbra is tárolja a fájlt. + +### Decentralizált autonóm szervezetek {#decentralized-autonomous-organizations} + +A „decentralizált autonóm szervezetek” (DAO) általános koncepciója, hogy egy virtuális entitásnak, amely adott számú taggal vagy „részvényessel” rendelkezik, akár esetleg 67%-os többséggel, felhatalmazása lehet arra, hogy elköltse az entitás pénzeszközeit és módosítsa a kódját. A tagok együttesen dönthetik el, hogy a szervezet hogyan allokálja a pénzeszközöket. Egy DAO pénzeszközei allokálásának módszerei a pénzadománytól, fizetéseken át akár még egzotikusabb mechanizmusokig terjedhet, mint például egy belső valuta a munka elismerésére. Ez gyakorlatilag replikálja a hagyományos vállalatok vagy non-profit entitások jogi csapdáit, de a végrehajtásra kizárólag kriptográfiai blokklánc-technológiát használ. Eddig a DAO-kkal kapcsolatban leginkább a kapitalista „decentralizált autonóm vállalat” (DAC) modelljéről beszéltünk, ahol a részvényesek osztalékot vagy kereskedhető részvényeket kapnak; azonban van egy alternatív, talán a „decentralizált autonóm közösség” fogalommal leírható értelmezés is, ahol a tagok egyenlő mértékben vesznek részt a döntéshozatalban, és a tagok 67%-ának beleegyezése szükséges ahhoz, hogy felvegyenek vagy eltávolítsanak egy tagot. Azt a követelményt, hogy egy személy csak egy tagsággal rendelkezhet a csoportnak kollektíven kell érvényre juttatnia. + +A DAO-k kódolásának általános leírása a következő. A legegyszerűbb megoldás egy önmagát módosító kódelem alkalmazása, amely változik, ha a tagok kétharmada egyetért egy módosítással. Bár a kód elméletileg állandó, bárki megkerülheti, és de-facto megváltoztathatja, ha a kód darabjait külön szerződésekbe foglalja, majd a módosítható tárhelyen menti el azt a címet, amit a szerződéseknek meg kell hívni. Egy ilyen DAO-szerződés egyszerű implementációjában három tranzakciótípus lenne, amelyeket a tranzakcióban megadott adatok különböztetnek meg: + +- `[0,i,K,V]`, ahol a javaslatot az `i` index-szel regisztrálják, hogy módosítsa a címet a `K` tárolási indexen `V` értékre +- `[1,i]` egy szavazatot regisztrál az `i` javaslat előnyben részesítésére +- `[2,i]` az `i` javaslat véglegesítésére, ha elég szavazat érkezett be + +A szerződésben ezután mindegyikre szerepel egy záradék. Ezután rögzíti az összes nyitott tárolási módosítást, és azt a listát is, hogy ki szavazott rájuk. Tartalmazza a tagok listáját is. Amikor valamelyik tárolási módosításra a tagok kétharmada szavazott, a véglegesítési tranzakció hajtja végre a módosítást. Egy kifinomultabb vázban megvalósítható beépített szavazási lehetőség is olyan funkciókra, mint például tranzakció küldése, tagok hozzáadása vagy eltávolítása, valamint lehetővé kell tenni egy [likviddemokrácia](https://wikipedia.org/wiki/Liquid_democracy)-stílusú szavazási delegálást is (azaz egy valaki kijelölheti, hogy ki szavazzon helyette, majd a kijelölés átadható, tehát, ha A B-t bízza meg a szavazással, majd B C-t bízza meg, C határozza meg A szavazatát). A tervezés lehetővé teszi, hogy a DAO organikusan nőjön decentralizált közösségként, és a tagok végül delegálhassák azt a feladatot egy specialistának, hogy kiszűrjék a tagokat, szemben a specialisták „jelenlegi rendszerével”, akik a közösség egyes tagjait érintő változások függvényében könnyen ki- vagy beugorhatnak. + +Alternatív modell egy decentralizált vállalat részére, amikor valamelyik számlán nulla vagy több részvény van, és a döntéshozatalhoz a részvények kétharmadára van szükség. Egy teljes vázban ideális esetben benne van az eszközkezelő funkció, a lehetőség részvények vásárlására vagy eladására szóló ajánlattételre, valamint a lehetőség az ajánlatok elfogadására (lehetőség szerint a szerződésen belül egy ajánlategyeztető mechanizmussal). A delegálás szintén likvid demokrácia-stílusban létezik, általánosítva az „igazgatótanács” koncepcióját. + +### További alkalmazások {#further-applications} + +**1. Megtakarítási tárcák**. Tegyük fel, hogy Alice biztonságban szeretné tudni pénzeszközeit, azonban aggódik amiatt, hogy veszteség éri, vagy valaki feltöri a privát kulcsát. Ethert helyez el egy szerződésben Bobbal, egy bankkal, a következőképpen: + +- Alice egyedül naponta legfeljebb a pénzeszközök 1%-át tudja felvenni. +- Bob egyedül naponta a pénzeszközök legfeljebb 1%-át tudja felvenni, de Alice-nek lehetősége van arra, hogy tranzakciót végezzen a kulcsával és zárolja ezt a lehetőséget. +- Alice és Bob együtt bármennyit fel tud venni. + +Alice-nek általában elég naponta 1%, azonban, ha Alice-nek többre van szüksége, értesítheti Bobot, és segítséget kérhet. Ha Alice-t támadás éri, Bobhoz siethet, és a pénzeszközöket egy új szerződésbe tudja átmozgatni. Ha elveszíti a kulcsát, Bob tudja végül kivenni az eszközöket. Ha Bob rosszindulatúan kezd viselkedni, Alice ki tudja kapcsolni, hogy Bob pénzt vehessen fel. + +**2. Terménybiztosítás**. Bárki készíthet könnyedén származtatott szerződést, ha az árindexek helyett az időjárási adatokról érkező adatforrást használja. Ha egy iowai farmer olyan származtatott ügyletet vásárol, ami fordítottan fizet az Iowában esett csapadék alapján, majd, ha szárazság van, a farmer automatikusan pénzhez jut, ha pedig elég eső esik, a farmer szintén jól jár, mert jó termése lesz. Ez általánosságban kiterjeszthető természeti csapásra vonatkozó biztosítással. + +**3. Decentralizált adatforrás**. A pénzügyi CFD-k (nyitó- és záróérték közti különbség lekereskedése) esetében gyakorlatilag lehetőség van decentralizálni az adatforrást a [SchellingCoin](http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) protokollal. A SchellingCoin a következőképpen működik: N fél beteszi a rendszerbe egy adott bázis értékét (például ETH/USD árfolyam), az értékeket rendezik, és mindenki, aki 25–75% között van egy tokent kap jutalmul. Ez a rendszer mindenkit arra ösztönöz, hogy olyan választ adjon, mint a többiek, és az egyetlen érték, amiben a résztvevők nagy száma realisztikusan egyet tud érteni a nyilvánvaló alap: az igazság. Ez egy decentralizált protokollt hoz létre, amely elméletileg bármilyen számú értéket adhat, ideértve az ETH/USD árát, vagy a berlini hőmérsékletet vagy egy nehéz számítási feladat eredményét. + +**4. Okos, több aláírásos fedezet**. A Bitcoin többaláírásos tranzakciós szerződéseket is enged, ahol például öt kulcsból három tudja elkölteni a pénzeszközöket. Az Ethereum ennél részletesebb lehetőségeket is kínál; például ötből négy mindent el tud költeni, ötből három naponta 10%-ot, ötből kettő pedig csak napi 0,5%-ot. Továbbá az Ethereum több aláírásos megoldás aszinkron – két fél különböző időben tudja regisztrálni az aláírását a blokkláncon, az utolsó aláírás küldi el automatikusan a tranzakciót. + +**5. Felhőben történő számítás**. Az EVM technológia szintén használható hitelesíthető számítási környezet létrehozására, ahol a felhasználók megkérhetnek másokat számítások végzésére, majd opcionálisan kérhetnek bizonyítékot arra, hogy a számítások adott, véletlenszerűen kiválasztott ellenőrzési pontokon pontosan lettek elvégezve. Így létre lehet hozni egy felhőalapú számítási piacot, amelyen bármelyik felhasználó részt vehet az asztali gépével, laptopjával vagy speciális szerverével, és együtt ellenőrizhetik szúrópróbaszerűen, hogy mely biztonsági letétek használhatók annak biztosítására, hogy a rendszer megbízható (azaz a csomópontok nem tudnak nyereségesen csalni). Bár egy ilyen rendszer nem feltétlenül felel meg minden feladatra; például nehézkes olyan feladatokat elvégezni nagyméretű felhőalapú csomópontokon, amelyek magasszintű, folyamat közbeni kommunikációt igényelnek. Más feladatokat azonban sokkal könnyebb párhuzamosan végezni; például a SETI@home, folding@home és általános algoritmusokat könnyebben meg lehet valósítani ilyen platformokon. + +**6. Közvetítő nélküli (peer-to-peer) szerencsejáték**. Tetszőleges számú peer-to-peer szerencsejáték-protokollt, például Frank Stajano és Richard Clayton [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) protokollját, lehet megvalósítani Ethereum blokkláncon. A legegyszerűbb szerencsejáték protokoll egyszerűen egy CFD a következő blokkhashre, de ennél bonyolultabb protokollokat is lehet építeni, például szerencsejáték-szolgáltatásokat nullához közeli díjakkal, ahol ki lehet zárni a csalás lehetőségét. + +**7. Kimenetelre fogadó piacok**. Az Oracle vagy SchellingCoin környezetben futó kimenetelre fogadó piacokat könnyen meg lehet valósítani; ezek a piacok a SchellingCoin-nal együtt az első [futarchy](http://hanson.gmu.edu/futarchy.html) mainstream alkalmazássá nőhetik ki magukat a decentralizált szervezetek irányítási protokolljaként. + +**8. Láncon belüli decentralizált piacterek**, amelyek az azonosítási és elismerési rendszert használják alapként. + +## Egyebek és aggályok {#miscellanea-and-concerns} + +### Módosított GHOST implementáció {#modified-ghost-implementation} + +A „Greedy Heaviest Observed Subtree” (GHOST, „mohó legsúlyosabb részfa”) innovatív protokollt Yonatan Sompolinsky és Aviv Zohar vezette be [2013 decemberében](https://eprint.iacr.org/2013/881.pdf). A GHOST mögötti motiváció az volt, hogy azokon a blokkláncokon, ahol a megerősítési idő gyors, a magas elavulási aránynak köszönhetően csökken a biztonság – mivel a blokknak bizonyos időre van szüksége a hálózaton való terjedéshez, ha A bányász kibányász egy blokkot, majd B bányász még azelőtt kibányász egy blokkot, hogy A bányász blokkja eljutna B bányászhoz, ez utóbbi blokkja feleslegessé válik, és nem járul hozzá a hálózat biztonságához. Továbbá van egy centralizációs probléma is: ha A bányász egy 30% hasherejű bányászalap, és B bányásznak 10% hashereje van, akkor az A bányász elavult blokklétrehozási kockázata 70% (a fennmaradó 30%-ban az A bányász hozta létre az utolsó blokkot, így azonnal bányászati adathoz jut), míg B bányász az esetek 90%-ában fog létrehozni elavult blokkot. Ezért ha a blokkintervallum elég rövid ahhoz, hogy a lejárati arány magas legyen, az A bányász jelentősen hatékonyabb lesz pusztán a mérete miatt. A két hatás kombinálásával az a blokklánc, amely gyorsan gyárt blokkokat, valószínűleg vezetni fog egy bányászalapot, és elég nagy százalékot fog elfoglalni a hálózat hashteljesítményéből, hogy de facto átvegye az irányítást a bányászási folyamat fölött. + +Ahogy Sompolinsky és Zohar is leírta, a GHOST megoldja a hálózat biztonságának elvesztését érintő első problémát azzal, hogy lejárt blokkokat is belevesz annak kiszámításába, hogy melyik lánc a „leghosszabb”; azaz nem csak a blokk szülőit és elődjeit veszi figyelembe, hanem a blokk elődjeinek mellékes leszármazottjait is (Ethereum kifejezéssel élve uncle/nagybácsi) hozzáadja ahhoz a számításhoz, hogy melyik blokkon van a legtöbb proof-of-work. A centralizációval kapcsolatos második probléma megoldására túlhaladunk a Sompolinsky és Zohar által ismertetett protokollon, és blokkjutalmakat adunk az elavult blokkokra is: egy elavult blokk az alapjutalom 87,5%-át éri, míg az elavult blokkot tartalmazó unokaöccs megkapja a fennmaradó 12,5%-ot. A tranzakciós díjakat azonban nem kapják meg a nagybácsik. + +Az Ethereum a GHOST egy egyszerűsített verzióját implementálta, amely hét szintre megy le. Ez a következőképpen néz ki: + +- Egy blokknak meg kell határoznia egy szülőt, illetve 0 vagy több nagybácsit +- Egy B blokkban lévő nagybácsinak a következő tulajdonságokkal kell rendelkeznie: + - Közvetlen leszármazottnak kell lennie a k-adik generációs B ősnek, ahol `2 <= k <= 7`. + - Nem lehet a B őse + - Egy nagybácsinak érvényes blokkfejléccel kell rendelkeznie, de nem kell korábban hitelesített vagy érvényes blokknak lennie + - A nagybácsinak különböznie kell a korábbi blokkokban szereplő nagybácsiktól, illetve az ugyanabban a blokkban lévő más nagybácsiktól (nincs dupla szerepeltetés) +- Minden U nagybácsihoz a B blokkban, a B bányász további 3,125%-ot kap a jutalmához, és az U bányász 93,75% normál jutalomban részesül. + +A GHOST limitált verzióját, ahol legfeljebb 7 generációig szerepelhet nagybácsi, két ok miatt használtuk. Először is a korlátlan GHOST túl sok komplikációval járna annak kiszámításában, hogy egy adott blokkban mely nagybácsik érvényesek. Másodsorban a korlátlan GHOST, ahogy az Ethereumban használják, nem ösztönzi a bányászt, hogy a fő láncon bányásszon a nyilvános támadó által használt lánc helyett. + +### Díjak {#fees} + +Mivel a blokkláncban közzétett minden tranzakció költséget ró a hálózatra a letöltés és a hitelesítés miatt, szükség van valamilyen szabályozó mechanizmusra, általában tranzakciós díjak beiktatására, hogy meg lehessen akadályozni a rosszindulatú viselkedést. A Bitcoinban is alkalmazott alapértelmezett megközelítés szerint tisztán önkéntes díjakra van szükség, ami a bányászokra támaszkodik abban, hogy őrizzék a biztonságot és dinamikus minimumokat állítsanak be. Ezt a megközelítést nagyon kedvezően fogadták a Bitcoin közösségben, különösen azért, mert az „piaci alapú”, megengedi, hogy a bányászok és a tranzakciók küldői közötti keresletet és kínálatot határozza meg az árat. A probléma ezzel az érveléssel az, hogy a tranzakciók feldolgozása nem egy piac; bár intuitív módon vonzó a tranzakció feldolgozását olyan szolgáltatásként értelmezni, amelyet a bányász kínál küldőnek, a valóságban minden olyan tranzakciót, amelyhez bányász kell, a hálózat minden csomópontján fel kell dolgozni, így a tranzakció feldolgozási költségének jelentős részét külső felek fizetik, és nem a bányász hozza meg azt a döntést, hogy foglalkozik-e vele vagy sem. Így nagyon valószínű a „közlegelők tragédiája" típusú problémák előfordulása. + +Azonban úgy tűnik, hogy a piaci alapú mechanizmus ezen hibája, amikor pontatlan egyszerűsítő feltételezéssel élnek, mágikusan megszünteti saját magát. Az érvelés a következő. Tegyük fel, hogy: + +1. Egy tranzakció `k` művelethez vezet, `kR` jutalmat kínál minden olyan bányásznak, aki szerepel benne, ahol az `R` értéket a küldő állítja be, és a `k` és `R` (nagyjából) már előre látható a bányász oldalán. +2. Egy művelet feldolgozásához szükséges költség `C` bármely csomóponton (azaz az összes csomópont hatékonysága azonos) +3. `N` bányász csomópont van, mindegyik pontosan ugyanannyi feldolgozási teljesítménnyel (azaz `1/N` az összesből) +4. Nem létezik nem bányászó teljes csomópont. + +Egy bányász akkor hajlandó feldolgozni a tranzakciót, ha a várható jutalom nagyobb, mint a költség. Így a várható jutalom `kR/N` mivel a bányásznak `1/N` esélye van feldolgozni a következő blokkot, és a bányász feldolgozási költsége `kC`. Következésképpen a bányászok olyan tranzakciókban fognak részt venni, ahol `kR/N > kC`, vagy `R > NC`. Ne feledjük, hogy `R` a küldő által műveletenként biztosított díj, amely alulról korlátozza azt az előnyt, amit a küldő a tranzakcióból nyer, és az `NC` pedig a műveletet feldolgozó teljes hálózat költsége. Következésképpen a bányászok csak olyan tranzakcióban érdekeltek, amelyen a teljes haszonelvű előny nagyobb, mint a költség. + +Azonban a valóságban a feltételezésektől számos fontos eltérés mutatkozik: + +1. A bányász nagyobb költséget fizet a tranzakció feldolgozásáért mint a többi, hitelesítést végző csomópont, mivel az extra hitelesítéshez szükséges idő késlelteti a blokk terjedését, és növeli annak az esélyét, hogy a blokk elavulttá válik. +2. Tehát mégis létezik nem bányászó teljes csomópont. +3. A bányászati teljesítmény eloszlása a gyakorlatban radikálisan egyenlőtlenné válhat. +4. A spekulánsok, politikai ellenségek és őrültek, akiknek a használati függvényei a hálózatra nézve káros elemeket tartalmaznak okosan olyan szerződéseket készíthetnek, amelyekben a költségeik sokkal alacsonyabbak, mint a többi hitelesítő csomópont által fizetett költségek. + +(1) olyan tendenciát biztosít a bányásznak, hogy kevesebb tranzakcióba vonódjon bele, és (2) növeli az `NC` értékét; következésképpen ez a két hatás legalább részben kioltja egymást.[Hogyan?](https://github.com/ethereum/wiki/issues/447#issuecomment-316972260) A (3) és (4) a fő probléma; megoldásukra egy egyszerű lebegő limitet alkalmazunk: egyetlen blokkon sem lehet több művelet mint a hosszú távú exponenciális mozgóátlag `BLK_LIMIT_FACTOR`-szorosa. Különösképpen: + +```js +blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) + +floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR) +``` + +A `BLK_LIMIT_FACTOR` és az `EMA_FACTOR` állandó, beállításuk 65 536 és 1,5 van jelenleg, amely további elemzés után változhat. + +Van még egy faktor, ami megszünteti a nagy blokkméretek iránti elköteleződést a Bitcoinban: a nagy blokkok terjedési ideje hosszabb, és így nagyobb eséllyel válnak elavulttá. Az Ethereumban a sok gázt fogyasztó blokkoknak is több időre van szüksége a terjedéshez, mivel egyrészt fizikailag hosszabbak, másrészt több időbe telik a státuszváltozási tranzakciók feldolgozásának validálása. Ez a késleltetési negatív ösztönző jelentős tényező a Bitcoin esetében, az Ethereum világában azonban kevésbé jellemző a GHOST protokoll miatt; következésképpen a szabályozott blokklimitekre való támaszkodás stabilabb alapkonfigurációt tesz lehetővé. + +### Számítás és Turing-teljesség {#computation-and-turing-completeness} + +Fontos megjegyezni, hogy az Ethereum virtuális gép Turing-teljes; azaz az EVM-kód minden olyan számítást képes titkosítani, amelyet rejtve lehet elvégezni, ideértve a végtelen hurkokat is. Az EVM-kód a hurkokat kétféleképpen teszi lehetővé. Egyfelől a `JUMP` utasítás lehetővé teszi a programnak, hogy visszaugorjon egy korábbi pontra a kódban, míg a `JUMPI` utasítás feltételhez kötött ugrást hajt végre, lehetővé téve a `while x < 27: x = x * 2` típusú állításokat. Másodsorban a szerződések más szerződéseket is meghívhatnak, ami potenciálisan lehetővé teszi a rekurzión keresztül történő hurkok alkalmazását. Ez természetesen egy problémát eredményez: a kártékony felhasználók le tudják állítani a bányászokat és a teljes csomópontokat azzal, hogy végtelen hurokba lépésre kényszerítik őket? Ez a helyzet a számítástechnikában megakadásproblémaként ismert: általánosságban nem lehet megmondani, hogy egy adott program mikor akad meg. + +Mint azt a státuszváltozási részben is leírtuk, a megoldásunk úgy működik, hogy egy tranzakcióban be kell állítani a maximálisan engedélyezett számítási lépések számát, és ha a futtatás tovább tart, a számítást visszatérítik, azonban díjat kell fizetni. Az üzenetek hasonlóképpen működnek. A megoldás mögötti motiváció bemutatására nézzük az alábbi példákat: + +- Egy támadó létrehoz egy szerződést, amely végtelen hurkot futtat, majd egy tranzakciót küld a bányásznak, amely aktiválja a hurkot. A bányász feldolgozza a tranzakciót, futtatja a végtelen hurkot, majd megvárja, amíg elfogy a gáz. Bár a futtatás közben kifogy a gáz és félúton megáll, a tranzakció továbbra is érvényes, és a bányász bekéri a díjat a támadótól minden számítási lépésért. +- Egy támadó egy nagyon hosszú végtelen hurkot hoz létre azzal a szándékkal, hogy a bányász olyan sokáig végezze a számítást, hogy a számítás végére pár új blokk is kikerüljön, és így lehetetlenné váljon a bányásznak a tranzakció belefoglalása, hogy díjat számíthasson fel. Azonban a támadónak be kell küldenie egy `STARTGAS` értéket, amely korlátozza a futtatásban használható számítások számát, így a bányász már előre tudni fogja, hogy a számítás jelentősen több lépésből fog állni. +- Egy támadó valami ilyesmit kódot lát a szerződésben `send(A,contract.storage[A]); contract.storage[A] = 0`, és pont annyi gázzal küldi el a tranzakciót, hogy futtatni lehessen az első lépést, de a másodikat már ne (azaz meglegyen a levétel, de az egyenleg ne csökkenjen le). A szerződés létrehozójának nem kell azon aggódnia, hogy védekezzen az ilyen támadások ellen, mivel ha a futtatás félúton megáll, azok vissza lesznek térítve. +- Egy pénzügyi szerződés úgy működik, hogy kilenc tulajdonos adatforrásának középértékét veszi a kockáztok minimalizálása érdekében. Amikor egy támadó átvesz egy adatforrást, amelyet úgy terveztek, hogy módosítható legyen a DAO részben ismertetett változó-cím-meghívás mechanizmuson keresztül, átkonvertálja úgy, hogy végtelen hurokban fusson, és így megpróbálja kikényszeríteni azokat a próbálkozásokat, amelyek pénzeszközöket kérnek a pénzügyi szerződéstől, amíg ki nem fogy a gáz. Azonban a pénzügyi szerződésekben be lehet állítani gázkorlátozást az üzeneten, és így meg lehet előzni a problémát. + +A Turing-teljesség alternatívája a Turing-nem-teljesség, ahol a `JUMP` és `JUMPI` nem létezik, és egyszerre csak egy szerződéspéldány létezhet a hívás-stackben. Ezzel a rendszerrel a korábban ismertetett díjrendszer és a megoldásunk hatékonyságával kapcsolatos bizonytalanságok nem feltétlenül szükségesek, mivel a szerződés futtatásának költségét annak mérete korlátozza be. Továbbá a Turing-nem-teljesség nem túl nagy korlátozást jelent; az általunk kitalált összes szerződés példa közül csupán egyhez volt szükség hurokra, és még ez az egy hurok is eltávolítható egy 26-szor ismételt, egysoros kódrészlettel. A Turing-teljesség súlyos implikációi, valamint a korlátozott haszon alapján, miért nincs egy Turing-nem-teljesség nyelv? A valóságban a Turing-nem-teljesség messze van a probléma elegáns megoldásától. Nézzük meg a következő szerződéseket, hogy ennek okát megértsük: + +```sh +C0: call(C1); call(C1); +C1: call(C2); call(C2); +C2: call(C3); call(C3); +... +C49: call(C50); call(C50); +C50: (futtasson egy lépést a programból, majd rögzítse a változtatást a tárhelyen) +``` + +Küldjön egy tranzakciót A-nak. Így 51 tranzakcióban van egy olyan szerződésünk, amely akár 250 számítási lépést is magában foglalhat. A bányászok megpróbálhatják már előre kiszűrni ezeket a logikai bombákat, ha értéket tartanak minden szerződés mellett, amely meghatározza, hogy legfeljebb mennyi számítási lépést vehet fel, és kiszámítják ezt azokhoz a szerződésekhez, amelyek rekurzívan hívnak más szerződéseket. Ez azonban arra kényszerítené a bányászokat, hogy letiltsák azokat a szerződéseket, amelyek más szerződéseket hoznak létre (mivel a fenti 26 szerződés létrehozása és futtatása könnyedén egy szerződésbe gyúrható). Másik problematikus pont, hogy az üzenet címmezője egy változó, tehát általánosságban idő előtt nem lehet megmondani, hogy milyen más szerződést fog meghívni egy adott szerződés. Ezért összességében meglepő következtetésre jutottunk: a Turing-teljességet meglepően könnyű kezelni, valamint a Turing-teljesség hiányát hasonlóképpen meglepően nehéz kezelni, kivéve, ha ugyanazokat a kontrollokat alkalmazzuk – de ebben az esetben miért ne legyen a protokoll Turing-teljes? + +### Valuta és kibocsátás {#currency-and-issuance} + +Az Ethereum rendszerben a saját beépített valuta, az ether kettős célt szolgál, egyfelől egy elsődleges likviditási réteget biztosít a különböző digitális eszközök közötti hatékony váltáshoz, másfelől fontos mechanizmust biztosít a tranzakciós költségek fizetésére. Kényelmi szempontból, valamint elkerülve a későbbi vitákat (lásd a jelenlegi mBTC/uBTC/satoshi vitát a Bitcoin kapcsán), a névértékek előre felcímkézésre kerül: + +- 1: wei +- 1012: szabo +- 1015: finney +- 1018: ether + +Ez a „dollár” és „cent”, illetve a „BTC” és „satoshi” koncepció kibővített változataként értelmezhető. A közeljövőben az „ether” lesz használatos a hagyományos tranzakciókra, a „finney” a mikrotranzakciókra, a „szabo” és a „wei” pedig a díjakkal és protokollimplementációkkal kapcsolatos technikai értekezésekben; a fennmaradó címletek pedig később lehetnek hasznosak, és jelenleg nem szerepelnek a kliensekben. + +A kibocsátási modell a következő: + +- Az ether mint valuta egy BTC-hez viszonyítva 1000–2000 ether árfolyamon fog forogni; ez a mechanizmus az Ethereum szervezet forrásait biztosítja, valamint ezzel lehet fizetni a fejlesztésekért, amelyet más platformon, például a Mastercoinon és az NXT-n már sikerrel használtak. A korai vásárlók nagyobb kedvezményekben részesülnek. Az eladásból kapott BTC-ket teljes mértékben a fejlesztők fizetésére és javadalmazására fordítják, valamint különböző profitot célzó és non-profit projektekbe fektetik az Ethereum és kriptovaluta ökoszisztémában. +- A teljes értékesített összeg (60 102 216 ETH) 0,099-szeresét a szervezet kapja a korai hozzájárulók kompenzálására, valamint az ETH-ben denominált költségekre fordítják a genezisblokk előtt. +- A teljes értékesített összeg 0,099-szeresét hosszú távú tartalékba helyezik. +- A teljes értékesített összeg 0,26-szorosa a bányászokhoz kerül évente, örökre ezután a pont után. + +| Csoport | Indításkor | Egy év után | Öt év után | +| --------------------------------- | ---------- | ----------- | ---------- | +| Pénznemegységek | 1,198 X | 1,458 X | 2,498 X | +| Vevők | 83,5% | 68,6% | 40,0% | +| Eladás előtt felhasznált tartalék | 8,26% | 6,79% | 3,96% | +| Eladás után felhasznált tartalék | 8,26% | 6,79% | 3,96% | +| Bányászok | 0% | 17,8% | 52,0% | + +#### Hosszú távú kínálati növekedési ütem (százalék) + +![Ethereum-infláció](./ethereum-inflation.png) + +_A lineáris valutakibocsátások ellenére, a Bitcoinhoz hasonlóan, a kínálati növekedési ütem nulla felé tart._ + +A fenti modellben két fő választási lehetőség van: 1) egy felnagyítási alap megléte és mérete; és 2) egy állandóan növekvő lineáris kínálat megléte, szemben a Bitcoin esetében látható felső korlátos kínálattal. A felnagyítási alap indoklása a következő. Ha nincs felnagyítási alap, és a lineáris kibocsátás 0,217x-re csökken az azonos mértékű infláció biztosítására, akkor az ether teljes mennyisége 16,5%-kal lesz kevesebb, és így minden egység 19,8%-kal értékesebb lesz. Következésképpen az egyensúlyban 19,8%-kal több ethert vásárolnak az értékesítés folyamán, így minden egység megőrzi korábbi értékét. A szervezet ezután 1,198x BTC-vel rendelkezik, amelyet két szeletre lehet bontani: az eredeti BTC és a további 0,198x-es rész. Következésképpen a helyzet _pontosan megegyezik_ a nagyítással, van azonban egy fontos különbség: a szervezetnél csupán BTC van, és így nincs ösztönözve arra, hogy támogassa az ether mértékegység értékét. + +Az állandó lineáris keresletnövekedési modell csökkenti a Bitcoin esetében sokak által túlzónak tartott vagyonkoncentráció kockázatát, és lehetőséget biztosít a jelenlegi és jövőbeli vásárlóknak, hogy reális esélyük legyen valutaegységeket venni, ugyanakkor erősen ösztönöz arra, hogy még több ethert vegyenek és tartsanak, mivel a „keresletnövekedési ütem” százalékos értéke továbbra is idővel a nulla felé közelít. Azt is feltételezzük, hogy mivel óvatlanság, haláleset stb. miatt mindig van, aki elveszti az érméit, és ez százalékosan is modellezhető az éves kínálat függvényében, a forgalomban lévő teljes valutakészlet végül a veszteség arányával elosztott éves kibocsátás értékével azonos értéken stabilizálódik (például, ha a veszteség aránya 1%, akkor amint a kínálat eléri a 26X-t, évente 0,26X lesz bányászva és 0,26X veszik el, és létrejön az egyensúly). + +Ne feledjük, hogy a jövőben valószínű, hogy az Ethereum proof-of-stake modellre vált a biztonság érdekében, és évi nulla és 0,05X közé csökken a kibocsátásra vonatkozó követelmény. Abban az esetben, ha az Ethereum-szervezet elveszíti pénzeszközeit, vagy valamilyen más okból kifolyólag eltűnik, nyitva hagyunk egy „társadalmi szerződést”: mindenkinek joga van létrehozni egy jövőbeli Ethereum-verziót azzal a feltétellel, hogy az ether mennyisége legfeljebb `60102216 * (1,198 + 0,26 * n)` lehet, ahol az `n` a genezisblokk utáni évek számát jelöli. A létrehozók a proof-of-stake által hajtott kínálatnövekedés és a maximálisan engedélyezett kínálatbővülés különbségét részben vagy egészben szabadon értékesíthetik tömeges eladás (crowd-sell) formájában, illetve kioszthatják a fejlesztés költségeinek lefedésére. Azok a frissítések, amelyek nem felelnek meg a társadalmi szerződés követelményeinek, jogosan elágaztathatók a követelményeknek megfelelő verziókba. + +### A bányászat centralizálása {#mining-centralization} + +A Bitcoin bányászati algoritmusa úgy működik, hogy a bányászok SHA256-számításokat végeznek a blokkfejléc kissé módosított verzióin egymás után több milliószor, amíg végül egy csomópont egy verzióhoz ér, amelynek hashértéke kisebb mint a cél (jelenleg körülbelül 2192). Azonban ez a bányászati algoritmus a centralizáció két formájával szemben sérülékeny. Először is a bányászati ökoszisztémát az ASIC-ok (alkalmazásspecifikus integrált körök) az erre a célra tervezett számítógép-chipek dominálják, és ezért ezek többezerszer hatékonyabbak a Bitcoin-bányászat során. Ez azt jelenti, hogy a Bitcoin-bányászat már egyáltalán nem decentralizált és egyenlőségen alapuló tér, és több millió dolláros tőkére van szükség ahhoz, hogy hatékonyan részt lehessen venni benne. Másodsorban a legtöbb Bitcoin-bányász gyakorlatilag nem helyileg validálja a blokkokat; helyette egy centralizált bányászalapra támaszkodik a blokkfejlécek megadásakor. Ez a probléma azonban még rosszabb: a jelen tartalom írásakor a legjobb három bányászalap indirekt módon a feldolgozási teljesítmény körülbelül 50%-át birtokolja, bár ezt némiképp enyhíti az a tény, hogy a bányászok átválthatnak egy másik alapra, ha az alap vagy a koalíció 51%-os támadással próbálkozik. + +Az Ethereumban jelenleg az a szándék, hogy olyan bányászati algoritmust használjanak, amelyben a bányászoknak véletlenszerűen kell adatot lekérniük a státuszból, ki kell számítaniuk néhány véletlenszerűen kiválasztott tranzakciót a blokklánc utolsó N blokkjáról, és vissza kell adniuk az eredmény hashét. Ennek két fontos előnye van. Először is az Ethereum-szerződésekben bármilyen számítás lehet, így egy Ethereum ASIC lényegében egy általános számításra használt ASIC – azaz egy jobb CPU. Másodszor, a bányászathoz hozzá kell férni a teljes blokklánchoz, ami arra kényszeríti a bányászokat, hogy a teljes blokkláncot tárolják, és legalább képesnek kell lenniük minden tranzakció hitelesítésére. Emiatt nincs szükség centralizált bányászati alapokra; bár a bányászati alapok továbbra is betöltik azt a legitim szerepet, hogy kiegyenlítik a jutalomelosztás véletlenszerűségét – ezt a funkciót ugyanígy el tudják látni a peer-to-peer alapok központi irányítás nélkül. + +Ez a modell még nincs tesztelve, és szembesülhetünk még nehézségekkel az okos optimalizálások elkerülése okán, amikor a szerződésvégrehajtást bányászati algoritmusként használják. Azonban ennek az algoritmusnak egyik érdekes funkciója, hogy bárki „megmérgezheti a kutat”, ha nagyszámú szerződést vezet be a blokkláncra kifejezetten azért, hogy megakasszon bizonyos ASIC-okat. Az ASIC gyártók számára léteznek gazdasági ösztönzők arra, hogy ezzel a trükkel megtámadják egymást. Ezért az általunk fejlesztett megoldás végeredményben egy adaptív, gazdasági, humán megoldás, és nem pusztán technikai. + +### Méretezhetőség {#scalability} + +Az Ethereummal kapcsolatos gyakori aggály a skálázhatóság kérdése. A Bitcoinhoz hasonlóan az Ethereumnak is megvan az a hibája, hogy a hálózatban minden csomópontnak fel kell dolgoznia a tranzakciókat. A Bitcoin esetében a jelenlegi blokklánc mérete körülbelül 15 GB, ami óránként mintegy 1 MB-tal nő. Ha a Bitcoin hálózatnak másodpercenként 2000 Visa-tranzakciót kellene feldolgoznia, akkor három másodpercenként nőne 1 MB-tal (1 GB óránként, 8 TB évente). Az Ethereumon is hasonló növekedési tempó figyelhető meg, amelyet tovább nehezít az, hogy az Ethereum blokkláncán számos alkalmazást futtatnak, míg a Bitcoin egy valuta; ugyanakkor javítja a helyzetet, hogy az Ethereum teljes csomópontjainak csak a státuszt és nem a teljes blokkláncelőzményt kell tárolniuk. + +A nagyméretű blokklánccal a centralizáció kockázata a fő probléma. Ha a blokklánc mérete mondjuk 100 TB-ra nő, a legvalószínűbb forgatókönyv szerint csak nagyon kevés nagyvállalat tud majd teljes csomópontot futtatni, az összes hagyományos felhasználó pedig könnyű SPV-csomópontokat fog használni. Egy ilyen helyzetben felmerülhet a lehetséges aggály, hogy a teljes csomópontok összefoghatnak, és megállapodhatnak abban, hogy profitábilis módon csaljanak (például módosítsák a blokkok után járó jutalmat, vagy BTC-t adjanak maguknak). A könnyű csomópontok nem tudják ezt azonnal felismerni. Természetesen legalább egy becsületes teljes csomópont valószínűleg létezne, és a csalás kiderülése után néhány órával már a Reddit is tele lenne a hírrel, azonban ezen a ponton már túl késő: a normál felhasználókon múlna, hogy szervezetten tiltólistára tegyék az adott blokkokat, ez a koordinációs probléma jelentős és szinte megoldhatatlan helyzetet teremt, hasonlóan egy sikeres 51%-os támadáshoz. A Bitcoin esetében ez jelenleg probléma, de létezik rá egy blokkláncmódosítási [javaslat Peter Toddtól](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/), amely enyhít a problémán. + +Az Ethereum két további stratégiát fog használni a probléma megoldására. Először a blokkláncalapú bányászati algoritmusok miatt legalább minden bányász rá lesz kényszerítve, hogy teljes csomópont legyen, ami alacsonyabb korlátot hoz létre a teljes csomópontok viszonylatában. Másodszor, ami még fontosabb, egy közbenső státuszfagyökeret szerepeltetünk a blokkláncban a tranzakciók feldolgozása után. Még akkor is, ha a blokk validálása centralizált, amíg van becsületes hitelesítő csomópont, a centralizációs probléma megkerülhető a protokoll validálásával. Ha egy bányász érvénytelen blokkot tesz közzé, akkor a blokk nincs megfelelően formázva, vagy az `S[n]` státusz pontatlan. Mivel az `S[0]` kód pontos, kell lennie egy első `S[i]` státusznak, amely hibás ott, ahol az `S[i-1]` pontos. A hitelesítő csomópont megadja az `i` indexet egy érvénytelenségi bizonyítékkal (proof of invalidity), amely olyan Patricia-facsomópontokból áll, amelyeknek fel kell dolgozniuk az `APPLY(S[i-1],TX[i]) -> S[i]` kifejezést. A csomópontok használni tudják ezeket a Patricia-csomópontokat a számítás egy részének futtatásához, és látni fogják, ha a generált `S[i]`nem egyezik a megadott `S[i]` értékkel. + +Egy másik, kifinomultabb támadásban rosszindulatú bányászok félkész blokkokat publikálnak, így a teljes információ nem is létezik annak megállapítására, hogy a blokk érvényes-e. A megoldás egy kihívásra reagáló protokoll: az ellenőrző csomópontok céltranzakciós indexek formájában „kihívásokat” adnak ki, majd amikor visszakapnak egy csomópontot, egy könnyű csomópont mindaddig érvénytelennek tekinti a blokkot, amíg egy másik csomópont, egy bányász vagy egy másik hitelesítő, vissza nem ad Patricia-csomóponti alkészleteket, igazolva az érvényességet. + +## Következtetés {#conclusion} + +Az Ethereum protokollt eredetileg egy frissített kriptovaluta-verziónak tekintették, amely haladó funkciókat is kínált, például blokkláncon lévő fedezetet, kivételi korlátokat, pénzügyi szerződéseket, szerencsejátékpiacokat és hasonlókat egy nagyon általánosított programnyelven. Az Ethereum-protokoll nem „támogatná” közvetlenül az alkalmazásokat, azonban a Turing-teljes programnyelv megléte azt jelenti, hogy tetszőleges mennyiségű szerződés hozható létre bármilyen tranzakciótípushoz vagy alkalmazáshoz. Még érdekesebb az Ethereummal kapcsolatban, hogy az Ethereum-protokoll sokkal több puszta valutánál. A decentralizált fájltárolással, számításokkal és hírtőzsdei piacokkal kapcsolatos protokollok a több tucat hasonló koncepció mellett magukban rejtik a számítási ipar jelentős hatékonyságnövelésének potenciálját, és masszív lökést adnak más peer-to-peer protokolloknak egy korábban nem látott gazdasági réteg hozzáadásával. Végezetül pedig jelentős számú alkalmazás van, amely egyáltalán nem foglalkozik pénzzel. + +Az Ethereum-protokollban implementált tetszőleges státuszváltozási függvény koncepciója egyedi potenciált rejtő platformot kínál; szemben a zárt végű, egycélú protokollokkal, amelyeket egy bizonyos típusú alkalmazásra fejlesztenek az adattárolás, pénzügy vagy szerencsejáték világában, az Ethereum egy alapvetően nyílt végű koncepció, és hiszünk abban, hogy kiválóan szolgál sok pénzügyi és nem pénzügyi protokoll alaprétegeként az elkövetkező években. + +## Jegyzetek és további olvasnivaló {#notes-and-further-reading} + +### Jegyzetek {#notes} + +1. A kifinomult olvasó észreveheti, hogy gyakorlatilag egy Bitcoin-cím az elliptikus görbe nyilvános kulcs hashe, és nem a nyilvános kulcs maga. Azonban gyakorlatilag teljesen legitim kriptográfiai terminológia a pubkey hash nyilvános kulcsként történő hivatkozása. Ez azért van, mert a Bitcoin kriptográfiáját tekinthetjük egy egyedi digitális aláírás-algoritmusnak, ahol a nyilvános kulcs az ECC pubkey hashéből áll, az aláírás az ECC pubkey és az ECC aláírás együttesen, a hitelesítő algoritmusban pedig az aláírásban lévő ECC pubkeyt a nyilvános kulcsként rendelkezésre bocsátott ECC pubkey hashsel vetik összes, majd az ECC aláírást az ECC pubkey értékével hitelesítik. +2. Gyakorlatilag a 11 előző blokk mediánja. +3. Belső értelmezésben a 2 és a „CHARLIE” egy szám[fn3](#notes), ez utóbbi big-endian bázis 256-os reprezentációjában van. A számok 0-tól legfeljebb 2256-1-ig terjedhetnek. + +### További olvasnivaló {#further-reading} + +1. [Valódi érték](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/) +2. [Okos tulajdonság](https://en.bitcoin.it/wiki/Smart_Property) +3. [Okosszerződések](https://en.bitcoin.it/wiki/Contracts) +4. [B-money](http://www.weidai.com/bmoney.txt) +5. [Újrahasznosítható proof-of-work](https://nakamotoinstitute.org/finney/rpow/) +6. [Biztonságos tulajdonságcímek tulajdonosi rendelkezéssel](https://nakamotoinstitute.org/secure-property-titles/) +7. [Bitcoin fehérkönyv](http://bitcoin.org/bitcoin.pdf) +8. [Namecoin](https://namecoin.org/) +9. [Zooko háromszöge](https://wikipedia.org/wiki/Zooko's_triangle) +10. [Colored coins fehérkönyv](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) +11. [Mastercoin fehérkönyv](https://github.com/mastercoin-MSC/spec) +12. [Decentralizált autonóm vállalatok, Bitcoin Magazine](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) +13. [Egyszerűsített fizetéshitelesítés](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification) +14. [Merkle-fák](https://wikipedia.org/wiki/Merkle_tree) +15. [Patricia-fák](https://wikipedia.org/wiki/Patricia_tree) +16. [GHOST](https://eprint.iacr.org/2013/881.pdf) +17. [StorJ és Autonóm ügynökök, Jeff Garzik](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html) +18. [Mike Hearn az Okos tulajdonságokról a Turing Fesztiválon](https://www.youtube.com/watch?v=MVyv4t0OKe4) +19. [Ethereum RLP](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP) +20. [Ethereum Merkle-Patricia-fák](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree) +21. [Peter Todd a Merkle-összegfákról](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) + +_A fehérkönyv történetét tekintse meg ezen [a wiki](https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md) oldalon._ + +_Az Ethereum, hasonlóan sok más közösség által vezetett, nyílt forráskódú szoftverprojekthez, a kezdeti elindulás óta sokat fejlődött. Ha többet szeretnél megtudni az Ethereum legutóbbi fejlesztéseiről és az általunk elvégzett protokollváltoztatásokról, akkor ezt az [útmutatót](/learn/) ajánljuk._ diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/bridges/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/bridges/index.md new file mode 100644 index 00000000000..06f59eb954b --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/bridges/index.md @@ -0,0 +1,135 @@ +--- +title: Hidak +description: Fejlesztőknek szóló áttekintés a hidakról +lang: hu +--- + +Az L1 blokkláncok és az L2 [skálázási](/developers/docs/scaling/) megoldások elterjedésével, valamint az egyre növekvő számú, láncokon átívelő, decentralizált alkalmazással a hálózati infrastruktúra alapvető részévé vált a láncok közötti kommunikáció és eszközmozgás. Különböző típusú hidak léteznek, hogy ezt lehetővé tegyék. + +## A hidak szükségessége {#need-for-bridges} + +Léteznek hidak a blokklánc-hálózatok összekapcsolására. Lehetővé teszik a blokkláncok közötti összekapcsolhatóságot és átjárhatóságot. + +A blokkláncok elkülönült környezetben léteznek, ami azt jelenti, hogy a blokkláncok nem tudnak természetes módon kereskedni és kommunikálni más blokkláncokkal. Emiatt, bár egy ökoszisztémán belül jelentős tevékenység és innováció valósulhat meg, ezt mégis korlátozza a más ökoszisztémákkal való összekapcsolhatóság és interoperabilitás hiánya. + +A hidak lehetőséget nyújtanak arra, hogy az elszigetelt blokklánc-környezetek összekapcsolódjanak egymással. Olyan útvonalat hoznak létre a blokkláncok között, ahol tokenek, üzenetek, tetszőleges adatok és akár [okosszerződés](/developers/docs/smart-contracts/) meghívások is átvihetők egyik láncból a másikba. + +## A hidak előnyei {#benefits-of-bridges} + +A hidak számos felhasználási módot tesznek lehetővé azáltal, hogy a blokklánchálózatok számára az adatcserét és az eszközmozgatást biztosítanak. + +A blokkláncok egyedi erősségekkel, gyengeségekkel és megközelítésekkel rendelkeznek az alkalmazások építésében (például sebesség, tranzakcióátvitel, költségek stb.). A hidak azáltal is segítik a teljes kriptoökoszisztéma fejlődését, hogy a blokkláncok felhasználhatják egymás innovációit. + +A fejlesztők számára a hidak a következőket biztosítják: + +- bármely adat, információ és eszköz átadása a láncok között. +- új funkciók és felhasználási esetek bevezetése a protokollok számára, mivel a hidak kibővítik azok tervezési lehetőségeit. Például egy eredetileg az Ethereum fő hálózatra telepített hozamgyűtjő protokoll likviditási alapokat kínálhat az összes EVM-kompatibilis láncban. +- kihasználhatóvá válnak a különböző blokkláncok erősségei. A fejlesztők például kihasználhatják a különböző L2-megoldások által kínált alacsonyabb díjakat azáltal, hogy dappjaikat az összevont tranzakciókra építik, a mellékláncok és a felhasználók pedig a hidakkal használhatják ezeket. +- együttműködés a különböző blokklánc-ökoszisztémák fejlesztői között új termékek létrehozására. +- különböző ökoszisztémák felhasználóit és közösségeit vonzzák a dappjaikhoz. + +## Hogyan működnek a hidak? {#how-do-bridges-work} + +Bár számos [híddizájn](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/) létezik, az eszközök láncok közötti mozgatásának három módja kiemelkedik: + +- **Zárolás és mintelés – ** Eszközök zárolása a forrásláncon és kibocsátása (mintelése) a célláncon. +- **Elégetés és mintelés –** A forrásláncban lévő eszközök égetése és azok kibocsátása (mintelés) a célláncon. +- **Atomikus átváltás –** A forrásláncon lévő eszközök átváltása a célláncon lévő eszközökre egy másik féllel. + +## Hídtípusok {#bridge-types} + +A hidak általában a következő kategóriák egyikébe esnek: + +- **Natív hidak –** Ezeket jellemzően azért építik, hogy egy adott blokkláncon a likviditást beindítsák, megkönnyítve a felhasználók számára a pénzeszközök mozgatását az ökoszisztémába. Az [Arbitrum-híd](https://bridge.arbitrum.io/) például azért jött létre, hogy a felhasználók kényelmesen át tudjanak hidalni az Ethereum fő hálózatról az Arbitrumra. Hasonló még a Polygon PoS híd, az [Optimism Gateway](https://app.optimism.io/bridge) stb. +- **Validátor- vagy orákulumalapú hidak –** Ezek külső validátorkészletre vagy orákulumokra támaszkodnak a láncközi átvitelekhez. Például a Multichain és az Across. +- **Általános üzenettovábbító hidak –** Ezek képesek eszközök, üzenetek és tetszőleges adatok láncok közötti átvitelére. Például: Axelar, LayerZero és Nomad. +- **Likviditási hálózatok –** Ezek elsősorban az eszközök egyik láncból a másikba történő átvitelére összpontosítanak atomikus átváltások révén. Általában nem támogatják a láncok közötti üzenettovábbítást. Például a Connext és a Hop. + +## A kompromisszumok, melyeket figyelembe kell venni {#trade-offs} + +A hidakra vonatkozóan nincsenek tökéletes megoldások. Ehelyett olyan kompromisszumok léteznek, melyek adott célra irányulnak. A fejlesztők és a felhasználók a következő tényezők alapján értékelhetik a hidakat: + +- **Biztonság –** Kik biztosítják a rendszert? A külső validátorok által biztosított hidak általában kevésbé biztonságosak, mint a blokklánc validátorai által helyileg vagy natívan biztosítottak. +- **Kényelem –** Mennyi ideig tart végrehajtani egy tranzakciót, és mennyit kell aláírnia a felhasználónak? A fejlesztőnek az számít továbbá, hogy mennyi ideig tart integrálni a hidat, és mennyire bonyolult ez a folyamat? +- **Csatlakozási lehetőségek –** Az adott híd milyen láncokhoz tud kapcsolódni (például összevont tranzakciókhoz, mellékláncokhoz, más L1 blokkláncokhoz stb.), és mennyire bonyolult egy új blokkláncot integrálni rá? +- **Összetettebb adatok továbbítási lehetősége –** Tud esetleg a híd üzeneteket és összetettebb, tetszőleges adatokat továbbítani a láncokra, vagy csak láncok közötti eszköztranszfert támogat? +- **Költséghatékonyság –** Mennyibe kerül az eszközök láncok közötti átadása egy hídon keresztül? A hidak jellemzően fix vagy változó díjat számítanak fel a gázköltségektől és az egyes útvonalak likviditásától függően. Az is fontos, hogy értékeljük a híd költséghatékonyságát azon tőke alapján, amelyet a biztonságának biztosításához használnak. + +A hidakat kategorizálhatjuk aszerint, hogy igényelnek bizalmat vagy sem. + +- **Bizalomigényű –** Az ilyen hidakat külsődlegesen biztosítják. A láncok közötti adatátvitelhez külső biztosítókat használnak (többaláírásos, többszereplős számítási rendszerek, orákulumhálózat). Emiatt képesek jó kapcsolódási lehetőséget és általánosított üzenettovábbítást biztosítani láncok között. Emellett a sebesség és a költséghatékonyság szempontjából is jók. Ez a biztonság rovására megy, mivel a felhasználóknak a híd biztonságára kell hagyatkozniuk. +- **Bizalomigény nélküli –** Ezek a hidak az általuk összekötött blokkláncokra és azok validátoraira támaszkodnak az üzenetek és a tokenek átvitelében. Ezek bizalomigény nélküliek, mert nem adnak hozzá új bizalmi feltételezéseket (a blokkláncokon túl). Ennek eredményeképpen a bizalomigénymentes hidak biztonságosabbnak tekinthetők, mint a bizalomigénnyel működők. + +Ahhoz, hogy a bizalomigény nélküli hidakat más tényezők alapján értékelni tudjuk, általános üzenettovábbító hidakra és likviditási hálózatokra kell bontanunk azokat. + +- **Általános üzenettovábbító hidak –** Ezek jellemzője, hogy biztonságot és összetettebb adatok láncokon keresztüli továbbítását kínálják. Jellemzően költséghatékonyak is. Ezek az erősségek azonban hátrányt okoznak más fronton: a könnyű ügyfélhidaknál (mint az IBC) az összekapcsolhatóságban, a csalási bizonyítást használó optimista hidaknál (mint a Nomad) a sebességben. +- **Likviditási hálózatok –** Ezek atomikus átváltásokat használnak az eszközök átruházására, és helyileg ellenőrzött rendszerek (a tranzakciók ellenőrzésére a mögöttes blokkláncok validálóit használják). Ennek eredményeképpen a biztonság és a gyorsaság terén is kiemelkednek. Ráadásul viszonylag költséghatékonyak és jó csatlakozási lehetőségeket kínálnak. A legnagyobb kompromisszum azonban az, hogy nem képesek összetettebb adatok továbbítására, mivel nem támogatják a láncok közötti üzenetátvitelt. + +## A hidak használatának kockázata {#risk-with-bridges} + +A hidak felelősek a [decentralizált pénzügyek (DeFi) három legnagyobb meghackelését](https://rekt.news/leaderboard/), és még a fejlesztés korai szakaszában vannak. A hidak használata a következő kockázatokkal jár: + +- **Okosszerződés-kockázat –** Bár sok híd sikeresen átment az ellenőrzéseken, elég egyetlen hiba egy okosszerződésben, hogy az eszközök sebezhetővé váljanak a hackerekkel szemben (például a [Solana féreglyukhídja](https://rekt.news/wormhole-rekt/) esetében). +- **Szisztematikus pénzügyi kockázatok** – Számos híd használja a csomagolt eszközöket arra, hogy az eredeti eszköz kanonikus változatait egy új láncon bocsássa ki (minting). Ez rendszerszintű kockázatnak teszi ki az ökoszisztémát, mivel a tokenek csomagolt változatait kihasználhatják. +- **Partnerkockázat –** Egyes hidak olyan konstrukciót használnak, amelyben a felhasználóknak bízniuk kell abban, hogy a validátorok nem játszanak össze a pénzeszközök ellopásáért. Mivel a felhasználóknak meg kell bízniuk harmadik fél szereplőkben, olyan kockázatoknak teszi ki őket, mint a rug pull (az eszköz mögül eltűnik a csapat és a pénz), a cenzúra és más rosszindulatú tevékenységek. +- **Nyitott problémák –** Mivel a hidak a fejlesztés kezdeti szakaszában vannak, számos megválaszolatlan kérdés van azzal kapcsolatban, hogyan fognak teljesíteni különböző piaci körülmények között, például hálózati torlódások idején és előre nem látható események, mint a hálózati szintű támadásoknál vagy státuszok visszaállításakor. Ez a bizonytalanság bizonyos kockázatokat rejt magában, amelyek mértéke még nem ismert. + +## Hogyan tudják a dappok a hidakat használni? {#how-can-dapps-use-bridges} + +Íme néhány gyakorlati alkalmazás, amelyet a fejlesztők megfontolhatnak a hidakkal és a dappok láncok közötti használatával kapcsolatban: + +### Hidak integrálása {#integrating-bridges} + +A fejlesztők számos módon adhatnak hozzá hidakat: + +1. **Saját híd építése –** Biztonságos és megbízható hidat építeni nem könnyű, különösen, ha a bizalomigény minimalizálása fontos. Ezenkívül többéves tapasztalatot és műszaki szakértelmet igényel a skálázhatósági és interoperabilitási tanulmányok miatt. Továbbá egy gyakorlatias csapatra lenne szükség a híd fenntartásához, és elegendő likviditás bevonása is szükséges, hogy ez megvalósítható legyen. + +2. **Több hídválasztási lehetőség megjelenítése a felhasználóknak–** Számos [dapp](/developers/docs/dapps/) megköveteli, hogy a felhasználók rendelkezzenek natív tokennel, hogy kapcsolatba léphessenek velük. Annak érdekében, hogy a felhasználók hozzáférhessenek a tokenjeikhez, különböző áthidalási lehetőségeket kínálnak a weboldalukon. Ez a módszer átmeneti megoldás a probléma megoldására, mivel a felhasználót eltávolítja a dappfelülettől, de továbbra is kölcsönhatásban kell maradnia más dappokkal és hidakkal. Emiatt nehéz a belépés, és ezzel együtt a hibák lehetősége is megnő. + +3. **Híd integrálása –** Ekkor a dappnak nem kell egy külső hídra és DEX-interfészekre küldenie a felhasználókat. Így a dappok képesek javítani a felhasználói élményt. Ennek azonban megvannak a maga korlátai: + + - A hidak kiértékelése és karbantartása nehéz és időigényes. + - Egy adott híd kiválasztása egyetlen meghibásodási pontot és függőséget hoz létre. + - A dappot bekorlátozzák a híd képességei. + - A hidak magukban nem feltétlen elegek. Előfordulhat, hogy a dappoknak DEX-ekre is szükségük van, hogy olyan funkciókat is biztosíthassanak, mint a láncok közötti átváltások. + +4. **Több híd integrálása –** Ez a megoldás számos problémát megold, amelyek akkor merülnek fel, amikor egyetlen hidat integrálunk. Ugyanakkor ennek is vannak korlátai, mivel több híd integrálása erőforrásigényes, és technikai és kommunikációs többletköltséget is jelent a fejlesztők számára – ami a kriptográfia legszűkösebb erőforrása. + +5. **Hídaggregátor integrálása –** Egy másik lehetőség a dappok számára egy hídaggregációs megoldás integrálása, amely hozzáférést biztosít több hídhoz. A hídaggregátorok a hidak erősségeit öröklik, és nem korlátozzák őket egyetlen híd képességei sem. A hídaggregátorok jellemzően fenntartják a hídintegrációkat, így a dappnak nem kell a hídintegráció technikai és üzemeltetési szempontjaival is foglalkoznia. + +Ennek ellenére a hídaggregátoroknak is megvannak a maguk korlátai. Bár több áthidalási lehetőséget kínálnak, jellemzően sokkal több híd található a piacon az aggregátor platformján kínáltakon kívül. Ráadásul a hidakhoz hasonlóan a hídaggregátorok is ki vannak téve az okosszerződésekkel és a technológiával kapcsolatos kockázatoknak (több okosszerződés = több kockázat). + +Ha egy dapp egy híd vagy egy aggregátor integrációját választja, az integráció mélységétől függően különböző lehetőségek állnak rendelkezésre. Ha például csak egy front-end integrációról van szó, amely javítja a felhasználó belépési élményét, akkor a dapp a widgetet (eszközt) integrálja. Ha azonban az integráció célja a mélyebb, láncközi stratégiák, például a letétbe helyezés, a hozamgyűjtés stb. felfedezése, akkor a dapp az SDK-t vagy az API-t integrálja. + +### Egy dapp telepítése több láncra {#deploying-a-dapp-on-multiple-chains} + +Egy dapp több láncra történő telepítéséhez a fejlesztők olyan fejlesztési platformokat használhatnak, mint az [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/) stb. Ezek a platformok olyan összeállítható bővítményekkel rendelkeznek, amelyek lehetővé teszik a dappoknak a láncok közötti átjárhatóságot. A fejlesztők például használhatják a [hardhat-deploy plugin](https://github.com/wighawag/hardhat-deploy) által kínált determinisztikus telepítési proxyt. + +#### Példák: + +- [Hogyan építsünk láncok közötti dappokat](https://moralis.io/how-to-build-cross-chain-dapps/) +- [Láncközi NFT piactér létrehozása](https://youtu.be/WZWCzsB1xUE) +- [Moralis: Láncközi NFT dappok építése](https://www.youtube.com/watch?v=ehv70kE1QYo) + +### A szerződéses tevékenység nyomon követése a láncok között {#monitoring-contract-activity-across-chains} + +A láncok szerződéses tevékenységének nyomon követéséhez a fejlesztők algráfokat és fejlesztői platformokat, például a Tenderly-t használhatják az okosszerződések valós idejű megfigyelésére. Az ilyen platformok olyan eszközökkel is rendelkeznek, amelyek nagyobb adatfigyelési funkciókat kínálnak a láncközi tevékenységekhez, mint például a szerződések által kibocsátott [események ellenőrzése](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) stb. + +#### Eszközök + +- [The Graph](https://thegraph.com/en/) +- [Tenderly](https://tenderly.co/) + +## További olvasnivaló {#further-reading} + +- [Blokklánc-hidak](/bridges/) – ethereum.org +- [Blokklánc-hidak: Kriptohálózatok hálózatának kiépítése](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) 2021. szeptember 8. – Dmitriy Berenzon +- [Az interoperabilitási trilemma](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) 2021. október 1. – Arjun Bhuptani +- [Clusters: Hogyan alakítják a bizalomigénytől mentes és a minimális bizalomigényű hidak a többláncos képet?](https://blog.celestia.org/clusters/) 2021. október 4. – Mustafa Al-Bassam +- [LI.FI: A hidaknál a bizalomigény széles tartománya van jelen](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) 2022. április 28. – Arjun Chand + +Ezen kívül [James Prestwich](https://twitter.com/_prestwich) tanulságos előadásai segíthetnek a hidak mélyebb megértésében: + +- [Hidakat építsünk, ne fallal körülvett kerteket](https://youtu.be/ZQJWMiX4hT0) +- [A hidak részletes bemutatása](https://youtu.be/b0mC-ZqN8Oo) +- [Miért fontosak a hidak](https://youtu.be/c7cm2kd20j8) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..c7b8f49436f --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: Blokkláncadat-tárolási stratégiák +description: Többféle módon is lehet adatokat tárolni a blokklánc használatával. Ez a cikk összeveti a különféle stratégiákat, azok költségét és átváltásait, valamint a biztonságos használat feltételeit. +lang: hu +--- + +Többféle módon lehet információt tárolni vagy közvetlenül a blokkláncon, vagy olyan módon, hogy azt a blokklánc biztosítja: + +- EIP-4844 blobok +- Calldata +- Láncon kívül L1 mechanizmusokkal +- Szerződés „kódja” +- Események +- EVM-tárhely + +A módszer kiválasztása számos feltételtől függ: + +- Az információ forrása. A calldata mezőben lévő információ nem származhat közvetlenül a blokkláncról. +- Az információ célállomása. A calldata csak az általa kezdeményezett tranzakcióban érhető el. Az események egyáltalán nem érhetők el a láncon. +- Mekkora erőfeszítés elfogadható? A teljes csomópontot futtató számítógépek többet dolgoznak, mint egy könnyű kliens egy alkalmazásban, mely böngészőben fut. +- Szükséges, hogy minden csomópont könnyedén elérje az információt? +- Biztonsági követelmények. + +## Biztonsági követelmények {#security-requirements} + +Általánosságban az információs biztonság három jellemzővel bír: + +- _Titkosság_, vagyis a felhatalmazással nem rendelkező entitások nem olvashatják el az információt. Ez sok helyen fontos, de itt nem. _A blokkláncon nincsenek titkok_. A blokklánc működésének alapja, hogy bárki ellenőrzini tudja a státuszváltozásokat, ezért közvetlen módon nem használható titkok tárolására. Vannak módok, hogy bizalmas információkat tároljanak blokkláncon, de ezek valami láncon kívüli elemen alapulnak, hogy legalább egy kulcsot ott tároljanak. + +- _Integritás_, vagyis az információ korrekt, azt nem változtathatják meg olyanok, akik arra nincsenek felhatalmazva, vagy nem engedélyezett módokon (például [ERC-20 tokenek](https://eips.ethereum.org/EIPS/eip-20#events) küldése a „Transfer” esemény nélkül). A blokkláncon minden csomópont ellenőriz minden státuszváltozást, mely biztosítja az integritást. + +- _Elérhetőség_, vagyis az információ elérhető minden arra felhatalmazott entitásnak. A blokkláncon ezt úgy érik el, hogy az információ minden [teljes csomóponton](https://ethereum.org/developers/docs/nodes-and-clients#full-node) elérhető. + +Ezek a megoldások mind kiváló integritással bírnak, mert a hash-eket az L1-en rögzítik. De más elérhetőségi biztosítékaik vannak. + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértéséhez érdemes ismerni a [blokklánc alapjait](/developers/docs/intro-to-ethereum/). Ez az oldal azt is feltételezi, hogy az olvasó ismeri a [blokkokat](/developers/docs/blocks/), [tranzakciókat](/developers/docs/transactions/) és más kapcsolódó témákat. + +## EIP-4844 blobok {#eip-4844-blobs} + +[A Dencun végleges elágazás](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md) óta az Ethereum blokklánc tartalmazza az [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) változást, ami az Ethereumhoz adatblobokat illesztett, melyek rövid ideig, kb. [18 napig](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) elérhetőek. Ezeket a blobokat külön árazzák, a [végrehajtási gáztól](/developers/docs/gas) függetlenül, bár hasonló mechanizmussal. Ez egy olcsó megoldás átmeneti adatok tárolására. + +Az EIP-4844 blobok fő használati területe az összevont tranzakciók, hogy az általuk feldolgozott tranzakciók bekerüljenek az L1-re. Az [optimista rollupoknak](/developers/docs/scaling/optimistic-rollups) publikálni kell a tranzakciókat a blokkláncon. Ezeknek a tranzakcióknak elérhetőnek kell lenniük bárki számára a [megkérdőjelezési periódusban](https://docs.optimism.io/connect/resources/glossary#challenge-period), hogy a [validátorok](https://docs.optimism.io/connect/resources/glossary#validator) kijavíthassák a hibát, ha a rollup [szekvencer](https://docs.optimism.io/connect/resources/glossary#sequencer) rossz státuszgyökeret posztol. + +Ugyanakkor a megkérdőjelezési periódus után a státuszgyökér véglegessé válik, a tranzakciók további lényege az marad, hogy a lánc jelen státuszát újra lehessen alkotni. Ez a státusz elérhető a lánc csomópontjaiból is, melyhez kevesebb erőfeszítés szükséges. Így a tranzakciókról szóló információ megmarad néhány helyen, mint amilyenek a [blokkfelfedezők](/developers/docs/data-and-analytics/block-explorers), de nincs szükség arra a cenzúrának való ellenállásra, amit az Ethereum biztosít. + +A [zero-knowledge rollupok](/developers/docs/scaling/zk-rollups/#data-availability) is posztolják a tranzakciós adatokat, hogy más csomópontok replikálni tudják a státuszt és ellenőrizhessék az érvényességi bizonyítékokat, de ez is egy rövid távú igény. + +A jelen írás idején az EIP-4844-gyel a költség egy wei (10-18 ETH) bájtonként, ami elhanyagolható [a 21,000 végrehajtási gázhoz képest, amibe bármelyik tranzakció kerül, beleértve azt, ami blobokat is posztol](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). Az EIP-4844 árakat a következő oldalon tekintheti meg: [blobscan.com](https://blobscan.com/blocks). + +A következőben láthatók azok a címek, melyekre néhány ismert rollup posztolja a blobokat. + +| Rollup | Postafiók címe | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | + +## Calldata {#calldata} + +A calldata azokat a bájtokat jelenti, melyeket a tranzakció részeként küldenek. Ez a blokklánc állandó tárhelyének része a blokkban, amely az adott tranzakciót tartalmazza. + +Így lehet a legolcsóbban adatot tenni a blokkba állandó tárolásra. A bájtonkénti költsége 4 végrehajtási gáz (ha a bájt nulla) vagy 16 gáz (minden más értéknél). Ha az adat tömörítve van, ami egy bevett gyakorlat, akkor minden bájtérték ugyanolyan valószínű, így az átlagköltség kb. 15,95 gáz bájtonként. + +A jelen írás idején az ár 12 gwei/gáz és 2300 $/ETH, mely szerint a költség kb. 45 cent kilóbájtonként. Mivel az EIP-4844 előtt ez volt a legolcsóbb módszer, ezért a rollupok így tárolták a tranzakciós információkat, hogy azok elérhetők legyenek a [hiba kivizsgálásra](https://docs.optimism.io/stack/protocol/overview#fault-proofs), de nem kell azokat közvetlenül elérni a láncon. + +A következőben láthatóak azok a címek, melyekre néhány ismert rollup posztolja a tranzakciókat. + +| Rollup | Postafiók címe | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | +| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | +| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | +| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | + +## Láncon kívül L1 mechanizmusokkal {#offchain-with-l1-mechs} + +A biztonsági megfontolások alapján talán elfogadható, hogy az információ máshol található, és egy mechanizmus biztosítja az elérhetőségét. Ez két feltétellel működhet: + +1. Az adat [hashét](https://en.wikipedia.org/wiki/Cryptographic_hash_function) a blokkláncra kell posztolni, melyet _input rögzítésnek_ neveznek. Ez lehet egy 32 bájtos szó, ami nem kerül sokba. Amíg az input rögzítése elérhető, az integritás biztosítva van, mert nem lesz más adat, aminek a hashe ugyanarra mutatna. Ha a helyes adat elérhető, akkor azt meg lehet találni. + +2. Szükség van egy mechanizmusra, mellyel elérhetővé válik az adat. Például a [Redstone](https://redstone.xyz/docs/what-is-redstone) esetében bármelyik csomópont indíthat elérhetőségi kihívást. Ha a szekvencer nem válaszol online a határidőig, az inputrögzítést elvetik, így az információt úgy veszik, mintha sosem lett volna beposztolva. + +Ez elfogadható az optimista rollup esetén, mert arra támaszkodunk, hogy legalább egy jóhiszemű ellenőrző van a státuszgyökérre. Egy ilyen jóhiszemű ellenőrző azt is biztosítja, hogy az adat létezik a blokk feldolgozásához, és egy elérhetőségi kihívást ad ki, ha az információ nem elérhető a láncon kívül. Ezt a fajta optimista rollupot nevezik [plazmának](/developers/docs/scaling/plasma/). + +## Szerződéskód {#contract-code} + +Az információ, melyet csak egyszer kell rögzíteni, sosem lesz felülírva, és a láncon belül elérhetőnek kell lennie, szerződéskódként is tárolható. Tehát készítünk egy „okosszerződést” az adattal, majd a [EXTCODECOPY](https://www.evm.codes/#3c?fork=shanghai) paranccsal kiolvassuk az információt. Ennek előnye az, hogy a kód másolása viszonylag olcsó. + +A memória kibővítésének költségén kívül az EXTCODECOPY 2600 gázba kerül, amikor a szerződéshez először férnek hozzá (amikor az „hideg”) és 100 gázba kerülnek a további másolatok, plusz 3 gázba 32 bájtnyi szavanként. A calldata-hoz képes, ami 15,95-be kerül bájtonként, ez kevesebb kb. 200 bájttól kezdve. [A memória kibővéítés költségének képlete](https://www.evm.codes/about#memoryexpansion) alapján, amíg nincs szükség több mint 4 MB memóriára, ez a bővítési költség kisebb, mint a calldata hozzáadása. + +Természetesen ez csak az adat _kiolvasása_. A szerződés létrehozásánek költsége kb. 32 000 gáz + 200 gáz/bájt. Ez csak akkor éri meg, ha az adott információt többször kell kiolvasni különféle tranzakciók során. + +A szerződéskód lehet értelmetlen, amíg nem kezdődik 0xEF-fel. Ha a szerződés kezdete 0xEF, akkor az egy [ethereum objektum formátum](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), amelynek szigorúbb követelményeknek kell megfelelnie. + +## Események {#events} + +Az [eseményeket](https://docs.alchemy.com/docs/solidity-events) az okosszerződések adják ki, és a láncon kívüli szoftverek olvassák azokat. +Előnye az, hogy a láncon kívüli kód képes értelmezni az eseményeket. A költsége 375 [gáz](https://www.evm.codes/#a0?fork=cancun) plusz 8 gáz bájtonként. Ha 12 gwei/gáz és 2300 $/ETH, akkor ez 1 cent plusz 22 cent kilóbájtonként. + +## Tárhely {#storage} + +Az okosszerződések hozzáférnek az [állandó tárhelyhez](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory). Ez azonban nagyon drága. Egy 32 bájtos szó beírása egy üres helyre [belekerülhet akár 22 100 gázba is](https://www.evm.codes/#55?fork=cancun). Ha 12 gwei/gáz és 2300 $/ETH, akkor ez 61 cent minden írásra, vagy 19,5 $ kilóbájtonként. + +Ez a legdrágább tárolás az Ethereumon. + +## Összefoglaló {#summary} + +Ez a táblázat összefoglalja a különböző opciókat azok előnyeivel és hátrányaival együtt. + +| Tárolási típus | Adatforrás | Elérhetőségi garancia | Láncon belüli elérhetőség | További korlátozások | +| -------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- | ---------------------------------------------------------- | +| EIP-4844 blobok | Láncon kívüli | Az Ethereum garantálja [kb. 18 napig](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | Csak a hash elérhető | | +| Calldata | Láncon kívüli | Az Ethereum garantálja örökre (része a blokkláncnak) | Csak akkor elérhető, ha egy szerződésbe van írva, és abban az adott tranzakcióban | | +| Láncon kívül L1 mechanizmusokkal | Láncon kívüli | Legalább egy jóhiszemű ellenőrző garantálja a kihívási periódus alatt | Csak hash | A kihívási mechanizmus garantálja a kihívási időszak alatt | +| Szerződéskód | Láncon belüli vagy kívüli | Az Ethereum garantálja örökre (része a blokkláncnak) | Igen | Egy „véletlenszerű” címre van írva, nem kezdődhet 0xEF-fel | +| Események | Láncon belüli | Az Ethereum garantálja örökre (része a blokkláncnak) | Nem | | +| Tárhely | Láncon belüli | Az Ethereum garantálja örökre (része a blokkláncnak és a jelen státusznak addig, amíg felül nem írják) | Igen | | diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..bcf0000a064 --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: Adatelérhetőség +description: Az adatok elérhetőségével kapcsolatos problémák és megoldások áttekintése az Ethereumban +lang: hu +--- + +„Ne bízz, ellenőrizd!” – ez az Ethereumban elterjedt alapelv. Az elképzelés lényege, hogy a csomópont önállóan ellenőrizheti a kapott információk helyességét azáltal, hogy végrehajtja a társaitól kapott blokkok összes tranzakcióját, hogy megbizonyosodjon arról, a javasolt változások megegyeznek a csomópont által kiszámítottakkal. Ez azt jelenti, hogy a csomópontoknak nem kell abban bízniuk, hogy a blokk küldői őszinték. Ez nem lehetséges, ha az adatok hiányoznak. + +**Az adatelérhetőség** arra utal, hogy a felhasználó mennyire bízhat abban, hogy a blokk ellenőrzéséhez szükséges adatok valóban rendelkezésre állnak a hálózat minden résztvevőjének. Az Ethereumon L1 rétegén lévő teljes csomópontok esetében ez viszonylag egyszerű; a teljes csomópont letölti az adott blokk összes adatának másolatát – az adatoknak _meg kell lennie_ ahhoz, hogy a letöltés lehetséges legyen. A hiányzó adatokkal rendelkező blokkot ahelyett, hogy hozzáadnák a blokklánchoz, inkább elvetnék. Ez a „láncon belüli adatelérhetőség”, és a monolitikus blokkláncok jellemzője. A teljes csomópontokat nem lehet érvénytelen tranzakciók elfogadására rávenni, mivel minden tranzakciót saját maguk töltenek le és hajtanak végre. A moduláris blokkláncok, a második blokkláncréteget (L2) képviselő összevont tranzakciók és a könnyű ügyfelek esetében azonban az adatok elérhetősége sokkal összetettebb, ami kifinomultabb ellenőrzési eljárásokat igényel. + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértéséhez érdemes ismerni a [blokklánc alapjait](/developers/docs/intro-to-ethereum/), különösen a [konszenzusmechanizmusokat](/developers/docs/consensus-mechanisms/). Ez az oldal azt is feltételezi, hogy az olvasó ismeri a [blokkok](/developers/docs/blocks/), [tranzakciók](/developers/docs/transactions/), [csomópontok](/developers/docs/nodes-and-clients/), [skálázási megoldások](/developers/docs/scaling/) és kapcsolódó témáit. + +## Az adatelérhetőség problémája {#the-data-availability-problem} + +Az adatok elérhetőségének problémája azt jelenti, hogy az egész hálózat számára bizonyítani kell, hogy a blokkláncba felvett tranzakciós adatok összegzett formája valóban érvényes tranzakciókat képvisel, mindezt anélkül, hogy minden csomópontnak le kellene töltenie az összes adatot. A teljes tranzakciós adat szükséges a blokkok független ellenőrzéséhez, de ha minden csomópontnak le kell töltenie az összeset, az akadályozza a skálázást. Az adatelérhetőség problémájára adott megoldások célja, hogy biztosítékot nyújtsanak arra, hogy a teljes tranzakciós adatot ellenőrzés céljából elérhetővé tették azoknak a résztvevőknek is, akik nem töltik le és tárolják az adatokat saját maguk. + +A [könnyű csomópontok](/developers/docs/nodes-and-clients/light-clients) és az [L2 összevont tranzakciók](/developers/docs/scaling) fontos hálózati résztvevők, akiknek erős adatelérhetőségi biztosítékokra van szükségük, de nem tudják letölteni és feldolgozni a tranzakciós adatokat. A könnyű csomópontokat épp az teszi könnyűvé, az összevont tranzakciókat pedig hatékony skálázási megoldássá, hogy nem kell tranzakciós adatokat letölteniük. + +Az adatelérhetőség kritikus szempont a jövőbeli [„státuszmentes”](/roadmap/statelessness) Ethereum-kliensek számára, amelyeknek nem kell letölteniük és tárolniuk a státuszadatokat a blokkok ellenőrzéséhez. A státuszmentes klienseknek továbbra is biztosnak kell lenniük abban, hogy az adatok rendelkezésre állnak _valahol_, és hogy azokat megfelelően feldolgozták. + +## Adatelérhetőségi megoldások {#data-availability-solutions} + +### Adatelérhetőség-mintázás (DAS) {#data-availability-sampling} + +Az adatelérhetőség-mintázás (DAS) egy módja annak, hogy a hálózat ellenőrizze, hogy az adatok rendelkezésre állnak-e anélkül, hogy túl nagy terhelést jelentene az egyes csomópontoknak. Minden csomópont (beleértve azokat is, amelyek nem helyeznek letétbe) letölti az összes adat véletlenszerűen kiválasztott, kis részhalmazát. A minták sikeres letöltése nagy biztonsággal megerősíti, hogy az összes adat rendelkezésre áll. Ez adattörlési kódolásra támaszkodik, amely egy adott adatkészletet redundáns információkkal bővít (azáltal, hogy egy _polinomiális_ függvényt illesztünk az adatokra, és ezt a polinomiálist további pontokon értékeljük ki). Ez lehetővé teszi, hogy szükség esetén a redundáns adatokból vissza lehessen állítani az eredeti adatokat. Az adatlétrehozás következménye, hogy ha az eredeti adatok közül _bármi_ hiányzik, akkor a kibővített adatok _felét_ sem kapjuk meg! Az egyes csomópontok által letöltött adatminták mennyiségét be lehet úgy állítani, hogy _nagy valószínűséggel_ hiányozzon legalább egy a kliensek által mintavételezett adatfragmentumok közül, _ha_ a csomópont az összes adatnak csak kevesebb mint a felét tárolja. + +A DAS annak biztosítására fog szolgálni, hogy az összevonttranzakció-üzemeltetők a [teljes Danksharding](/roadmap/danksharding/#what-is-danksharding) bevezetését követően rendelkezésre bocsássák tranzakciós adataikat. Az Ethereum-csomópontok véletlenszerű mintát vesznek a blobokban megadott tranzakciós adatokból a fent ismertetett redundanciaséma segítségével, hogy az összes adat meglétét biztosítsák. Ugyanezt a technikát lehetne alkalmazni arra is, hogy a blokkgyártók minden adatukat elérhetővé tegyék, így biztosítsák a könnyű kliensek működését. Hasonlóképpen, a [ javaslattevő-építő szétválasztása](/roadmap/pbs) esetén csak a blokképítőnek kell feldolgoznia egy teljes blokkot, a validátorok az adatok elérhetőségét mintavételezéssel ellenőriznék. + +### Adatelérhetőségi bizottságok {#data-availability-committees} + +Az adatelérhetőségi bizottságok (DAC) olyan megbízható felek, amelyek az adatok rendelkezésre állását biztosítják vagy tanúsítják. A DAC-k használhatók DAS helyett, [vagy azzal kombinálva](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS). A bizottságokkal járó biztonsági garanciák a konkrét felállítástól függenek. Az Ethereum a validátorok véletlenszerűen kiválasztott részhalmazait használja például a könnyű csomópontok adatelérhetőségének igazolására. + +A DAC-ket egyes validiumok is használják. A DAC egy megbízható csomópontokból álló csoport, amely offline tárolja az adatok másolatait. A DAC köteles az adatokat vita esetén rendelkezésre bocsátani. A DAC tagjai láncon belüli tanúsítványokat is közzétesznek annak igazolására, hogy az említett adatok valóban rendelkezésre állnak. Egyes validiumok a DAC-k helyébe a proof-of-stake (PoS) validátorrendszert léptetik. Itt bárki validátorrá válhat, és tárolhatja az adatokat a láncon kívül. Ehhez azonban „kötvényt” kell nyújtaniuk, amelyet egy okosszerződésben helyeznek letétbe. Rosszindulatú viselkedés esetén, például ha a validátor visszatartja az adatokat, a kötvény mértékében megbüntethető a szereplő. A proof-of-stake adatelérhetőségi bizottságok lényegesen biztonságosabbak, mint a hagyományosak, mivel közvetlen módon ösztönznek jóhiszemű viselkedésre. + +## Adatelérhetőség és a könnyű csomópontok {#data-availability-and-light-nodes} + +[A könnyű csomópontoknak](/developers/docs/nodes-and-clients/light-clients) a blokkadatok letöltése nélkül kell ellenőrizniük a kapott blokkfejlécek helyességét. Ennek a könnyű jellegnek az az ára, hogy nem tudják függetlenül ellenőrizni a blokkfejléceket úgy, ahogy egy teljes csomópont teszi azáltal, hogy helyben újrafuttatja a tranzakciókat. + +Az Ethereum a könnyű csomópontok egy _szinkronizálási bizottsághoz_ rendelt 512 validátor véletlenszerű halmazára vannak utalva. A szinkronizálási bizottság DAC-ként működik, amely kriptográfiai aláírással jelzi a könnyű klienseknek, hogy a fejlécben szereplő adatok helyesek. A Szinkronizálási bizottság minden nap frissül. Minden blokkfejléc figyelmezteti a könnyű csomópontokat, hogy melyik validátoroktól várják a _következő_ blokk aláírását, így nem lehet őket rászedni, hogy megbízzanak egy rosszindulatú csoportban, amely szinkronizálási bizottságnak adja ki magát. + +Mi történik akkor, ha egy támadó valahogyan egy hamis blokkfejlécet _továbbít_ a könnyű klienseknek, és meggyőzi őket arról, hogy azt egy becsületes szinkronizálási bizottság írta alá? Ebben az esetben a támadó érvénytelen tranzakciókat is betehet, és a könnyű kliens elfogadja azokat, mivel nem ellenőrzi független módon a blokkfejlécbe foglalt összes státuszváltozást. Ez ellen a könnyű kliens csalási bizonyítékokat használhat. + +Ezek a csalási bizonyítékok úgy működnek, hogy egy teljes csomópont, ha látja, hogy egy érvénytelen státuszváltozásról pletykálnak a hálózatban, gyorsan létrehozhat egy kis adatot, amely bizonyítja, hogy a javasolt státuszváltozás nem származhat egy adott tranzakcióhalmazból, és ezt az adatot továbbítja a társainak. A könnyű csomópontok felkaphatják ezeket a csalási bizonyítékokat, és felhasználhatják azokat a rossz blokkfejlécek elvetésére, így biztosítva, hogy ugyanabban a helyes láncban maradjanak, mint a teljes csomópontok. + +Ennek feltétele, hogy a teljes csomópontok hozzáférjenek a teljes tranzakciós adatokhoz. Egy olyan támadó, aki rossz blokkfejlécet küld szét, és a tranzakciós adatokat sem teszi elérhetővé, képes lenne megakadályozni, hogy a teljes csomópontok csalási bizonyítékokat generáljanak. A teljes csomópontok képesek lennének figyelmeztetést adni egy rossz blokkról, de nem tudnák a figyelmeztetésüket bizonyítékkal alátámasztani, mert az adatok nem álltak rendelkezésre, hogy a bizonyítékot legenerálják! + +Erre az adatelérhetőségi problémára a DAS a megoldás. A könnyű csomópontok a teljes státuszadat kis véletlenszerű darabjait töltik le, és a minták segítségével ellenőrzik, hogy a teljes adatkészlet rendelkezésre áll-e. Kiszámítható annak tényleges valószínűsége, hogy N véletlenszerű darab letöltése után tévesen feltételezzük a teljes adatelérhetőséget ([100 darab esetén az esély 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), azaz hihetetlenül valószínűtlen). + +Még ebben a forgatókönyvben is előfordulhat, hogy a véletlenszerű adatkéréseket végző kliensek előtt észrevétlen marad az, ha csak néhány bájtot tartanak vissza a támadások során. A törléskódolás ezt úgy oldja meg, hogy rekonstruálja a hiányzó kis adatdarabokat, amelyek felhasználhatók a javasolt státuszváltozások ellenőrzésére. Ezután a rekonstruált adatok felhasználásával csalási bizonyítékot lehetne készíteni, amely megakadályozza, hogy a könnyű csomópontok rossz fejléceket fogadjanak el. + +**Megjegyzés:** A DAS és a csalási bizonyítékok még nem kerültek bevezetésre a proof-of-stake Ethereum könnyű kliensek számára, de szerepelnek az útitervben, valószínűleg ZK-SNARK alapú bizonyítékok formájában. A mai könnyű kliensek a DAC egy formájára támaszkodnak: ellenőrzik a szinkronizálási bizottság személyazonosságát, majd megbíznak a kapott aláírt blokkfejlécekben. + +## Adatelérhetőség és L2 összevont tranzakciók {#data-availability-and-layer-2-rollups} + +Az [L2 skálázási megoldások](/layer-2/), mint például az [összevont tranzakciók](/glossary/#rollups), csökkentik a tranzakciós költségeket és növelik az átvitelt az Ethereumon a tranzakciók láncon kívüli feldolgozásával. Az összevont tranzakciók tömörített formában és kötegekben kerülnek az Ethereumra. A kötegek több ezer egyedi, láncon kívüli tranzakciót jelentenek egyetlen tranzakcióban az Ethereumon. Ez csökkenti a torlódást az alaprétegen és a felhasználók díjait. + +Az Ethereumba küldött „összefoglaló” tranzakciókban azonban csak akkor lehet megbízni, ha a javasolt státuszváltozás független módon ellenőrizhető és megerősíthető, hogy az az összes láncon kívüli tranzakció alkalmazásának eredménye. Ha az összevonttranzakció-üzemeltetők nem teszik elérhetővé a tranzakciós adatokat ehhez az ellenőrzéshez, akkor hibás adatokat küldhetnek az Ethereumba. + +Az [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/) tömörített tranzakciós adatokat küldenek az Ethereumba, és várnak egy bizonyos ideig (általában 7 napig), hogy független ellenőrök ellenőrizhessék az adatokat. Ha valaki problémát észlel, létrehozhat egy csalási bizonyítékot, és azt felhasználhatja az összevont tranzakciók megkérdőjelzésére. Ez azt eredményezi, hogy a lánc visszafordul és elveti az érvénytelen blokkot. Ez csak akkor lehetséges, ha az adatok rendelkezésre állnak. Jelenleg az optimista rollupok kétféle módon vihetnek tranzakciós adatokat az L1-re. Néhány rollup az adatokat `CALLDATA` formában állandóan elérhetővé teszi, amelyek folyamatosan elérhetők a láncon belül. Az EIP-4844 bevezetése lehetővé teszi, hogy az összevont tranzakciók a tranzakciós adataikat az olcsóbb blobtárolóba tegyék. Ez nem állandó tárhely. A független ellenőröknek kb. 18 napon belül le kell kérdezniük a blobokat, és jelezniük kell az esetleges problémáikat, mielőtt az adatok törlődnek az Ethereum (L1) rétegről. Az adatok elérhetőségét az Ethereum-protokoll csak erre a rövid, rögzített időablakra garantálja. Ezután az időpont után az Ethereum ökoszisztémában más szereplők felelőssége lesz. Bármely csomópont ellenőrizheti az adatelérhetőséget a DAS segítségével, vagyis a blobadatok kis, véletlenszerű mintáinak letöltésével. + +A [zero-knowledge (ZK) összevont tranzakcióknak](/developers/docs/scaling/zk-rollups) nem kell tranzakciós adatokat közzétenniük, mivel a [zero-knowledge érvényességi igazolások](/glossary/#zk-proof) garantálják a státuszváltozások helyességét. Az adatok elérhetősége azonban még mindig probléma, mivel nem lehet garantálni a ZK összevont tranzakció működését (és nem is tudunk vele interakcióba lépni), ha nem ismerjük a releváns státuszadatokat. A felhasználók például nem ismerhetik meg egyenlegüket, ha az üzemeltető visszatartja az összevont tranzakciókból következő státusz részleteit. Emellett nem tudnak státuszfrissítéseket végrehajtani az újonnan hozzáadott blokk információival. + +## Az adatelérhetőség és az adatvisszakereshetőség összehasonlítása {#data-availability-vs-data-retrievability} + +Az adatelérhetőség különbözik az adatok visszakereshetőségétől. Az adatelérhetőség annak biztosítása, hogy a teljes csomópontok képesek hozzáférni és ellenőrizni az adott blokkhoz kapcsolódó tranzakciók teljes halmazát. Ebből nem feltétlenül következik, hogy az adatok örökre hozzáférhetők. + +Az adatok visszakereshetősége a csomópontok azon képessége, hogy _historikus információkat_ tudnak visszakeresni a blokkláncból. Ezekre a múltbeli adatokra nincs szükség az új blokkok ellenőrzéséhez, csak a teljes csomópontok szinkronizálásához a Genesis blokkból vagy bizonyos múltbeli kérések kiszolgálásához. + +Az Ethereum alapprotokollja elsősorban az adatelérhetőséggel foglalkozik, nem a visszakereshetőséggel. Az adatok visszakereshetőségét harmadik felek által üzemeltetett archiváló csomópontok kis halmaza is biztosíthatja, vagy a hálózaton belül decentralizált fájltárolás, mint például a [Portal Network](https://www.ethportal.net/). + +## További olvasnivaló {#further-reading} + +- [Mi az az adatelérhetőség?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [Mit jelent az adatelérhetőség?](https://coinmarketcap.com/alexandria/article/what-is-data-availability) +- [Az Ethereum-láncon kívüli adatelérhetőségi helyzete](https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/) +- [Az adatelérhetőség ellenőrzésére vonatkozó útmutató](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [A sharding + DAS javaslat magyarázata](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [Megjegyzés az adatelérhetőségről és a törlési kódolásról](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) +- [Adatelérhetőségi bizottságok.](https://medium.com/starkware/data-availability-e5564c416424) +- [Proof-of-stake típusú adatelérhetőségi bizottságok.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Megoldások az adatvisszakereshetőségi problémára](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [Adatelérhetőség vagy hogyan tanulták meg az összevont tranzakciók, hogy ne aggódjanak és szeressék az Ethereumot](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md new file mode 100644 index 00000000000..26b5b1372f3 --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md @@ -0,0 +1,220 @@ +--- +title: Decentralizált tőzsde (DEX) tervezésének bevált gyakorlatai +description: Útmutató a tokenátváltás UX/UI döntéseihez. +lang: hu +--- + +Az Uniswap 2018-as bevezetése óta százával jöttek létre decentralizált tőzsdék tucatnyi különböző láncon. +Számos új elemeket vezetett be vagy beletette a maga kis csavarját, de az interfész általában ugyanolyan maradt. + +Ennek egyik oka [Jakob törvénye](https://lawsofux.com/jakobs-law/): + +> A felhasználók a legtöbb időt ezeken az oldalakon töltik. Tehát azt preferálják, hogy minden oldal ugyanúgy működjön, ahogy azt már megismerték. + +A korai bevezetőknek, mint a Uniswap, Pancakeswap és Sushiswap köszönhetően a DeFifelhasználóknak van egy közös elképzelésük, hogyan néz ki egy DEX. +Emiatt meg tudunk fogalmazni bevált gyakorlatokat. Egyre több tervezési döntést kezelnek sztenderd módon a különböző oldalakon. A DEX-ek fejlődését úgy nézhetjük végig, mint egy nagy tesztelés, ami élőben folyik. A működő dolgok maradnak, a nem működőket kivetik. Van hely az egyéni megoldásokra, de bizonyos szabványoknak meg kell felelni. + +Ez a cikk összefoglalja: + +- mit tartalmazzon +- hogyan legyen a leginkább használható +- a személyreszabás főbb módjai + +A példák modelljei ehhez a cikkhez készültek, bár valódi projekteken alapulnak. + +A Figma eszközkészlet megtalálható a cikk alján – használja Ön is szabadon, és alkossa meg saját modelljét! + +## A DEX alapvető anatómiája {#basic-anatomy-of-a-dex} + +Az UI általában három elemet tartalmaz: + +1. Fő űrlap +2. Gomb +3. Részletek panel + +![Általános DEX UI a három fő elemmel](./1.png) + +## Variációk {#variations} + +Ez a közös téma, de ezeket az elemeket különféle módokon lehet elrendezni. A részletek panel lehet: + +- A gomb felett +- A gomb alatt +- Rejtve egy kinyíló panelben +- És/vagy egy előnézeti ablakban + +Megjegyzés: Az előnézeti ablak opcionális, de ha kevés adat van a fő felületen, akkor szükség lesz rá. + +## A fő űrlap struktúrája {#structure-of-the-main-form} + +Ez az a doboz, ahol kiválasztjuk, melyik tokent akarjuk átváltani. Egy beviteli mezőből és egy kis gombból áll, melyek egymás mellett találhatók. + +A DEX-ek általában további információkat közölnek a felette vagy alatta lévő sorban, de ezt másképp is be lehet állítani. + +![Beviteli sor a részletekkel felette és alatta](./2.png) + +## Variációk {#variations2} + +Két UI-variációt láthatunk itt; az egyiknek nincsenek szegélyei, nyitott dijáznt adva, a másiknál pedig a beviteli sora keretezve van, így fókusz kerül erre az elemre. + +![A fő űrlap két UI-variációja](./3.png) + +Ez az alapvető struktúra **négy fő információt** mutat a dizájban: egyet-egyet minden sarokban. Ha csak egy felső/alsó sor van, akkor két dolgot lehet megmutatni. + +A DeFi fejlődése mentén sokféle dolgot foglaltak bele ide. + +## Kulcsinformációk megmutatása {#key-info-to-include} + +- Egyenleg a tárcában +- Maximum gomb +- Fiat egyenérték +- Árhatás a „kapott” összeg esetén + +A korai megoldásoknál a fiat egyenérték sokszor hiányzott. Ha bármilyen web3-projekt készül, ez a fiat egyenérték elengedhetetlen. A felhasználók még helyi valutákban gondolkodnak, ezért szükséges, hogy ezzel a mentális modellel össze lehessen kapcsolni az információkat. + +A második mezőnél (ahol kiválasztja a tokent, amire váltani szeretne) az árhatást is meg lehet mutatni a fiat valuta összege mellett, kiszámolva a beadott és becsült visszakapott összeg különbségét. Ez egy igen hasznos részlet. + +A százalékos gombok (pl. 25%, 50%, 75%) hasznos funkciók, de több helyet igényelnek, több műveletet kell végrehajtani és több mentális terhet jelentenek. Ugyanez a helyzet a százalékos csúszkával. Ezek az UI döntések az adott márkán és a felhasználóin múlnak. + +További részleteket lehet megmutatni a fő űrlap alatt. Mivel ezek a profi felhasználóknak szólnak, érdemes: + +- minimálisra csökkenteni ezek mennyiségét, vagy +- elrejteni egy kinyíló panelben + +![A fő űrlap sarkaiban látható részletek](./4.png) + +## További információk megmutatása {#extra-info-to-include} + +- A tokenek ára +- Csúszás +- Minimum kapott összeg +- Várható eredmény +- Árhatás +- Gázköltség becslése +- Egyéb díjak +- Rendelés útvonala + +Ezek a részletek természetesen opcionálisak is lehetnek. + +A rendelés útvonala érdekes, de a legtöbb felhasználónak egyáltalán nem számít. + +Néhány másik részlet ugyanazt mondja el, csak másképpen. Például a minimum kapott összeg és a csúszás ugyanannak két oldala. Ha a csúszás 1%-ra van állítva, akkor a minimum várható összeg = várt eredmény-1%. Néhány UI várható összeget, minimum összeget és csúszást mutat… Ami hasznos, de talán túl sok. + +A legtöbb felhasználó általában az alapértelmezett csúszást használja. + +Az árhatás gyakran látszik zárójelekben a fiat egyenérték mellett, a „valamire” mezőben. Ez egy kiváló UX részlet, de ha itt megmutatjuk, akkor kell-e még alatta is megmutatni? Majd újra az előnézetben? + +Számos felhasználó (főleg ha kis összegeket vált) nem foglalkozik ezekkel a részletekkel; csak beírják a számot és megnyomják az átváltást. + +![Néhány részlet ugyanazt mutatja](./5.png) + +A részletek azon múlnak, hogy milyenek a felhasználók és milyen érzetet ad az alkalmazás. + +Ha a részletek panelban megmutatjuk a csúszási toleranciát, akkor ott szerkeszhetővé is kell tenni. Ez egy jó példa a „gyorsításra”; egy elegáns UX trükk, amely anélkül gyorsítja meg a flowt a tapasztalt felhasználók számára, hogy az az alkalmazás általános használatát érintené. + +![A csúszást állítani lehet a részletek panelben](./6.png) + +Érdemes végiggondolni a részleteket, és nem csak egy oldalon, hanem a teljes menetben: +A fő űrlapon beírjuk a számokat → A részleteket megmutatjuk → Rákattintunk az előnézetre (ha van). +A részletek panel mindig látható, vagy rá kell kattintani ahhoz, hogy kinyíljon? +Az előnézettel megtörjük a használat folytonosságát? Ez ráveszi a felhasználót, hogy lassítson és átgondolja a szándékát, ami hasznos lehet. De szükséges-e nekik még egyszer minden részlet? Ezen a ponton mi a hasznos számukra? + +## Tervezési opciók {#design-options} + +Ahogy említettük, ennek nagy része a személyes stíluson múlik +Ki a felhasználó? +Mi a márka? +Profi interfészt akar minden részlettel, vagy inkább minimalista elrendezést? +Még ha a profi felhasználóknak is készül, és minden információ elérhető, érdemes megfontolni meg Alan Cooper szavait: + +> Mindegy, milyen szép és menő az interfész, a kevesebb néha több. + +### Struktúra {#structure} + +- tokenek a bal vagy a jobb oldalon +- 2 vagy 3 sor +- részletek a gomb felett vagy alatt +- a részletek kinyithatók, minimalizáltak vagy nem jelennek meg + +### Komponensstílus {#component-style} + +- üres +- körvonalas +- kitöltött + +Tisztán UX szempontból az UI stílusok kevesebbet számítanak, mint gondolnánk. A vizuális divatok jönnek-mennek, és a legtöbb preferencia szubjektív. + +Ahhoz, hogy erre ráérezzen, és átlássa a különféle beállításokat, nézzen meg néhány példát és kísérletezzen maga. + +Az alábbi Figma eszközkészlet tartalmaz üres, körvonalas és kitöltött komponenseket is. + +Tekintse meg az alábbi példákat, hogyan lehet ezeket összeilleszteni különféle módokon: + +![3 sor kitöltött stílussal](./7.png) + +![3 sor körvonalas sílussal](./8.png) + +![2 sor üres stílussal](./9.png) + +![3 sor körvonalasan egy részletek panellel együtt](./10.png) + +![3 sor az input sorral körvonalasan](./11.png) + +![2 sor kitöltött stílussal](./12.png) + +## De melyik oldalra kerüljön a token? {#but-which-side-should-the-token-go-on} + +A lényeg, hogy valószínűleg nem okoz nagy különbséget a használatban. Néhány dologra érdemes figyelni, ami miatt egyik vagy másik lesz a jó megoldás. + +Érdekes megfigyelni, ahogy a divat változik az idővel. Uniswap eredetileg balra tette a tokent, de aztán átkerült jobbra. Sushiswap is megváltoztatta ugyanígy egy frissítésnél. A legtöbb protokoll követte a példát. + +A pénzügyi konvenciók szerint a valuta szimbóluma a szám elé kerül, például $50, €50, £50, de _szóban_ 50 dollár, 50 euró, 50 font hangzik el. + +Az átlagos felhasználónak – főleg aki balról jobbra, fentről lefelé olvas – a token a jobb oldalon természetesebben hat. + +![UI, ahol a token a bal oldalon van](./13.png) + +Ha a token a bal oldalon és a számok a jobb oldalon vannak, akkor kellemesen szimmetrikus az elhelyezés, de van ennek hátránya is. + +A közelség törvénye azt mondja, hogy a közeli dolgok összefüggőbbnek tűnnek. Eszerint a kapcsolódó tételeket közel akarjuk tenni egymáshoz. A tokenegyenleg közvetlenül kapcsolódik a tokenhez, és megváltozik, amikor új tokent választunk. Ezért a tokenegyenleg kerülhetne a token kiválasztógombja mellé. Ha a token alá tennénk, akkor megtörné a szimmetriát. + +Végülis mindkét megoldásnak vannak előnyei és hátrányai, de a trend szerint a token a jobb oldalra kerül. + +# Gombműködés {#button-behavior} + +Ne legyen külön gomb a jóváhagyásra. Ne is kelljen ehhez külön kattintani. A felhasználó átváltást akar, ezért legyen a gombon átváltás felirat és az első lépés maga a jóváhagyás. Az ablak mutathatja a haladást lépésekkel, vagy egyszerűen egy „2-ből 1 tranzakció jóváhagyása” figyelmeztetéssel. + +![UI, ahol külön gomb van a jóváhagyásra és az átváltásra](./14.png) + +![UI, ahol egy jóváhagyás gomb van](./15.png) + +## Gomb mint helyi segítség {#button-as-contextual-help} + +A gomb figyelmeztetésként is működhet! + +Ezt nem használják annyira web3-on kívül, de itt elterjedtté vált. Így kevesebb helyet foglal, és fenntartja a figyelmet. + +Ha a fő tevékenység, azaz az átváltás nem érhető el egy hiba miatt, akkor annak okát ki lehet írni a gombra, például + +- hálózatváltás +- tárca csatlakoztatása +- különféle hibák + +A gombot **hozzá is lehet kapcsolni az elvégzendő cselekvéshez**. Például, ha a felhasználó rossz hálózaton van, a gombon megjelenik, hogy „váltás Ethereumra”, és ha rákattint, akkor átváltja a hálózatot. Ez jelentősen meggyorsítja a használatot. + +![A fő akciók a fő CTA-ról indulnak](./16.png) + +![Hibaüzenet a fő CTA-n](./17.png) + +## Építse meg sajátját ezzel a figma fájllal {#build-your-own-with-this-figma-file} + +Számos protokoll kemény munkájának köszönhető, hogy a DEX dizájnja sokat fejlődött. Tudjuk, hogy a felhasználónak milyen információra van szüksége, hogyan mutassuk azt meg, és hogyan legyen könnyed a használat menete. +Remélhetőleg ez a cikk segített áttekinteni az UX elveket. + +Ha kísérletezne, akkor használja hozzá a Figma eszközkészletet. Egyszerű, mégis rugalmas ahhoz, hogy kedve szerint építse meg az alapstruktúrát. + +[Figma eszközkészlet](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit) + +A DeFi továbbfejlődik, és mindig van lehetőség az újításra. + +Sok szerencsét! diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md new file mode 100644 index 00000000000..a1f21c12236 --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md @@ -0,0 +1,138 @@ +--- +title: 7 heurisztika a web3-interfész dizájnjához +description: A web3 felhasználhatóságának fejlesztési elvei +lang: hu +--- + +A használhatósági heurisztikák amolyan ökölszabályok, melyekkel felmérhető egy oldal használhatósága. +Az itt felsorolt 7 heurisztikát kifejezetten web3-ra alakították ki és érdemes együtt használni Jakob Nielsen [10 általános elv az interakciós dizájnhoz](https://www.nngroup.com/articles/ten-usability-heuristics/) iránymutatásával. + +## Hét használati heurisztika web3-ra {#seven-usability-heuristics-for-web3} + +1. A visszajelzés a cselekvést követi +2. Biztonság és megbízhatóság +3. A legfontosabb információ egyértelmű legyen +4. Érthető szóhasználat +5. A műveletek a lehető legrövidebbek legyenek +6. A hálózati kapcsolódás látható és rugalmas legyen +7. Az alkalmazásból legyen irányítható, nem a tárcából + +## Definíciók és példák {#definitions-and-examples} + +### 1. A visszajelzés a cselekvést követi {#feedback-follows-action} + +**Egyértelmű legyen, amikor történt vagy éppen történik valami.** + +A felhasználók a következő lépéseiket az előzők eredménye alapján teszik meg. Ezért lényeges, hogy mindig ismerjék a rendszer jelen állapotát. Ez még fontosabb a web3-ban, mert a tranzakcióknak sokszor kevés idő kell, hogy véglegesedjenek a blokkláncban. Ha nincs visszajelzés, akkor elbizonytalanodnak, hogy megtörtént-e. + +**Tippek:** + +- Tájékoztassa a felhasználót üzenetek és figyelmeztetések révén. +- Egyértelműen közölje a várakozási időt. +- Ha egy akció néhány másodpercnél hosszabb ideig tart, biztosítson a felhasználónak egy számlálót vagy animációt, hogy tudja, éppen folyamatban van a kérése. +- Ha több lépésből áll a folyamat, akkor mutassa az összeset. + +**Például:** +Ha megmutatja a folyamat összes lépését, akkor a felhasználó tudja, hogy hol tart. A megfelelő ikonok segítenek megérteni, hogy milyen állapotban vannak a műveleteik. + +![Tájékoztassa a felhasználót minden lépésről, amikor tokeneket vált](./Image1.png) + +### 2. A biztonság és a megbízhatóság legyen beégetve itt: {#security-and-trust-are-backed-in} + +A biztonság alapvető prioritás, és ezt a felhasználóval is tudatni kell. +Az emberek számára fontosak az adataik. A biztonság mindig a legfontosabb a felhasználónak, ezért a dizájn minden szintjén figyelembe kell venni. Mindig el kell nyerni a felhasználók bizalmát, ami különféle alkalmazásoknál mást jelenthet. Ne utólag gondoljon rá, hanem tervezze bele tudatosan. A teljes felhasználói élmény során bizalmat kell kiépíteni, beleértve a közösségi csatornákat, a dokumentációt és a végső felhasználói felületet is. A decentralizáció szintje, a pénzeszközök többaláírásos kezelése és az, hogy a csapatot lenyomozták-e a nyilvános fórumokon, mind befolyásolják a felhasználók bizalmát. + +**Tippek:** + +- Mutassa meg büszkén az auditokat +- Tegyen szert több auditra +- Reklámozza a biztonsági jellemzőket, melyeket kialakított +- Jelezze a felmerülő kockázatokat, beleértve a mögöttes integrációkat is +- Kommunikálja a stratégiák összetett voltát +- Vegye figyelembe a nem felhasználói felülettel kapcsolatos gondokat, melyek befolyásolják a felhasználók biztonságérzetét + +**Példa:** +Tüntesse fel az auditot a láblécben, feltűnő méretben. + +![A honlap láblécében feltüntetett auditok](./Image2.png) + +### 3. A legfontosabb információk legyenek egyértelműk {#the-most-important-info-is-obvious} + +A bonyolult rendszerek esetében csak a legfontosabb adatokat mutassa. Határozza meg, hogy mi a legfontosabb, és azt vegye előre a bemutatásban. +A túl sok információ túlterheli a felhasználókat, akik általában egy információdarabot vesznek figyelembe a döntésnél. A DeFi esetében ez az információ valószínűleg a THM a jövedelmet hozó alkalmazásoknál, illetve a hitelfedezet (LTV) a kölcsönadó alkalmazásoknál. + +**Tippek:** + +- A felhasználókat megvizsgálva kiderül, mi a legfontosabb mérőszám +- Legyen a kulcsinformáció nagy, a többi pedig kicsi és diszkrét +- Az emberek nem olvassák el, hanem átfutják a dolgokat, ezért legyen a dizájn jól átfutható + +**Példa:** A nagy tokeneket színesben könnyebb megtalálni az átfutás közben. A THM legyen nagy és hangsúlyos színű. + +![Könnyű megtalálni a tokent és a THM-et](./Image3.png) + +### 4. Érthető szóhasználat {#clear-terminology} + +A szóhasználat legyen érthető és helyénvaló. +A technikai zsargon nagy akadály lehet, mert egy teljesen új gondolkodási módot igényel. A felhasználók ekkor nem tudják hozzákapcsolni a dizájnt az általuk már ismert szavakhoz, mondatokhoz és koncepciókhoz. Minden zavaró és ismeretlen, és a tanulási görbe nagyon meredek, mire eljutnak addig, hogy használni próbálják. A felhasználó azért fordul a DeFi-hoz, hogy megtakarítson egy kis pénzt, és azt látja, hogy: bányászat, gazdálkodás, letétbe helyezés, kibocsátás, vesztegetés, megőrzés, széfek, veTokenek, megszerzés, korszakok, decentralizált algoritmusok, protokoll által birtokolt likviditás… +Használjon egyszerű kifejezéseket, amelyeket bárki megérthet. Ne találjon ki teljesen új szavakat az adott projekthez. + +**Tippek:** + +- Használjon egyszerű és konzisztens terminológiát +- Használjon ismert szavakat, amennyire lehetséges +- Ne találjon ki új kifejezéseket +- Kövesse a koncenciókat, ahogy megjelennek +- Tanítsa a felhasználókat, amennyire csak lehetséges + +**Példa:** +„Az Ön jutalma” egy széles körben érthető, semleges kifejezés; nem egy új szó az adott projekthez. Ha a jutalmat USD-ben mutatja, akkor az kapcsolódni tud a meglévő gondolkodási sémákhoz, még akkor is, ha a jutalom másik tokenben van. + +![Token jutalmak, amerikai dollárban megmutatva](./Image4.png) + +### 5. A műveleteknek a lehető legrövidebbnek kell lenniük {#actions-are-as-short-as-possible} + +Gyorsítsa fel a felhasználó interakcióját azzal, hogy csoportosítja az műveleteket. +Ezt az okosszerződés szintjén, vagy akár a felhasználói felület szintjén is meg lehet tenni. A felhasználónak ne kelljen a rendszer egyik részéről a másikra navigálnia – vagy akár elhagynia azt –, hogy teljesítsen egy átlagos műveletet. + +**Tippek:** + +- Kombinálja a jóváhagyást más műveletekkel, ha lehet +- Csoportosítsa az aláírásokat közel egymáshoz + +**Példa:** A likviditás hozzáadása és a letétbe helyezés két olyan művelet, melyet összevonva felgyorsul a használat és egyszerre spórol időt és gázt a felhasználónak. + +![Átváltás, ahol kombinálni lehet a letéti és staking művelet](./Image5.png) + +### 6. A hálózati kapcsolódás látható és rugalmas {#network-connections-are-visible-and-flexible} + +Tájékoztassa a felhasználót, hogy milyen hálózathoz kapcsolódik, és adjon egyértelmű lehetősége ennek módosítására. +Ez rendkívül fontos a több láncon működő alkalmazásoknál. Az alkalmazás főbb funkciói akkor is legyenek láthatók, ha a felhasználó nem kapcsolódik hálózathoz, vagy olyanhoz kapcsolódik, ami nem támogatott. + +**Tippek:** + +- Mutasson meg az alkalmazásból annyit, amennyit csak lehet, miközben a felhasználó nincs hálózathoz kapcsolódva +- Mutassa meg, hogy a felhasználó melyik hálózathoz kapcsolódik +- Ne hagyja, hogy a felhasználónak a tárcához kelljen navigálnia a hálózat átváltásához +- Ha az alkalmazáshoz hálózatot kell váltani, akkor az tegye az alkalmazásból +- Ha az alkalmazás több piacot vagy helyet tartalmaz számos hálózattal, akkor legyen egyértelmű a felhasználónak, hogy éppen mit lát + +**Példa:** Mutassa meg a felhasználónak, hogy melyik hálózathoz kapcsolódik, és hogy ezt módosítani tudja az alkalmazásban. + +![Legördülő gomb mutatja a hálózati kapcsolatot](./Image6.png) + +### 7. Az alkalmazásból irányítható, nem a tárcából {#control-from-the-app-not-the-wallet} + +A felhasználói felület olyan legyen, hogy a felhasználó mindent tudjon és mindent irányíthasson, amire szükség van. +Web3-ban vannak bizonyos műveletek, amelyek a felhasználói felülethez, mások a tárcához tartoznak. Általában a felhasználói felület az, ahol a műveletek elindul, és a tárcában erősítik meg azt. A felhasználó összezavarodik, ha ez a kettő nincs jól összehangolva. + +**Tippek:** + +- Közölje a rendszer státuszát a felhasználói felületen visszajelzés formájában +- Mentse az előzményeket +- Legyen összekapcsolva a blokkfelfedezőkkel a korábbi tranzakciók miatt +- Legyen egyszerű a hálózat átváltása. + +**Példa:** Egy konténer mutatja a felhasználónak, hogy milyen tokenek vannak a tárcájában, a fő CTA pedig lehetőséget ad a hálózat átváltására. + +![Fő CTA feldobja a hálózat átváltásának lehetőségét](./Image7.png) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/index.md new file mode 100644 index 00000000000..737132fbe6f --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/index.md @@ -0,0 +1,92 @@ +--- +title: Dizájn és UX (felhasználói élmény) a web3-ban +description: Bevezetés az UX-tervezésbe és kutatásba a web3-ban és az Ethereumon +lang: hu +--- + +Ön még csak most ismerkedik az Ethereumon való tervezéssel? Akkor a megfelelő helyen jár. Az Ethereum-közösség olyan forrásokkal rendelkezik, amelyek segítenek elindulni a web3-tervezésben és -kutatásban. Megismerheti az alapvető fogalmakat, amelyek eltérhetnek más, ismert alkalmazások tervezésétől. + +Először a web3 alaposabb megértésére van szüksége? Tekintse meg a [**Tanulási központ**](/learn/) oldalt. + +## Kezdje a felhasználói kutatással {#start-with-user-research} + +A hatékony tervezés túlmutat a vizuálisan vonzó felhasználói felületek létrehozásán. Magában foglalja a felhasználó igényeinek, céljainak és mozgatórugóinak mélyreható megértését. Ezért erősen ajánljuk, hogy minden tervező alkalmazzon egy tervezési folyamatot, mint például a [**dupla gyémánt folyamat**](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)), hogy biztosítsa, munkája tudatos és szándékos. + +- [A web3-nak több UX kutatóra és tervezőre van szüksége](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) – A jelenlegi tervezési érettség áttekintése +- [Egyszerű útmutató az UX kutatáshoz a web3-ban](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) – Egyszerű útmutató a kutatáshoz +- [Hogyan közelítsük meg az UX-döntéseket a web3-ban](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) – A kvantitatív és kvalitatív kutatás rövid áttekintése, és a kettő közötti különbségek (videó, 6 perc) +- [UX-kutatónak lenni a web3-ban](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) – Személyes vélemény arról, milyen UX-kutatónak lenni a web3-ban + +## Kutatási tanulmányok a web3-ban {#research-in-web3} + +Ez a web3-ban végzett felhasználói kutatások válogatott listája, amely segíthet a tervezési és termékdöntésekben, vagy inspirációként szolgálhat saját tanulmányok készítéséhez. + +| Fókuszterület | Név | +|:----------------------------------------------------------------- |:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Bevezetés a kriptóba | [The WalletConnect Pulse 2024: Crypto fogyasztói hangulat & használat](https://walletconnect.com/pulse-2024-crypto-consumer-report) | +| Bevezetés a kriptóba | [CRADL: UX a kriptovaluták világában](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | +| Bevezetés a kriptóba | [CRADL: Bevezetés a kriptovaluták világába](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | +| Bevezetés a kriptóba | [Bitcoin UX riport](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | +| Bevezetés a kriptóba | [ConSensys: A web3 helyzete világszerte 2023-ban](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | +| Bevezetés a kriptóba | [NEAR: Az elfogadás felé vezető út felgyorsítása](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | +| Letétbe helyezés | [OpenUX: Rocket Pool csomópont-operátor UX](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | +| Letétbe helyezés | [Staking: Főbb trendek, tanulságok és előrejelzések – Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | +| Letétbe helyezés | [Többalkalmazásos letétbe helyezés](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | +| DAO | [2022-es DAO-kutatás frissítése: Mire van szüksége a DAO-építőknek?](https://blog.aragon.org/2022-dao-research-update/) | +| DeFi | [A DeFi helyzete 2024-ben](https://stateofdefi.org/) (folyamatos felmérés) | +| DeFi | [Fedezeti alapok](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | +| DeFi | [ConSensys: DeFi felhasználói kutatási riport 2022-ben](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | +| Metaverzum | [Metaverse: Felhasználói kutatási riport](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | +| Metaverzum | [Szafarira megyünk: Felhasználók kutatása a Metaverzumban](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (videó, 27 perc) | +| Az Ethereum.org UX-statisztikái | [Használhatósági és felhasználói elégedettségi felmérés – Ethereum.org](https://lookerstudio.google.com/reporting/0a189a7c-a890-40db-a5c6-009db52c81c9) | + +## Web3-tervezés {#design-for-web3} + +- [Web3 UX tervezési kézikönyv](https://web3ux.design/) - Gyakorlati útmutató a web3 alkalmazások tervezéséhez +- [Web3-tervezési alapelvek](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) – UX-szabályok keretrendszere a blokkláncalapú dappok számára +- [Blokklánc dizájnelvek](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) – Az IBM-blokklánc tervezői csapatának tanulságai +- [Web3 tervezési minták](https://www.web3designpatterns.io/) – Valódi web3 termékekből származó tervezési minták gyűjteménye +- [W3design.io](https://w3design.io/) – Az ökoszisztéma különböző projektjeinek UI-folyamataiból összeállított könyvtár +- [Neueux.com](https://neueux.com/apps) – UI-könyvtár felhasználói folyamatok változatos szűrési lehetőségekkel +- [A web3 használhatóságának válsága: Amit tudnia kell!](https://www.youtube.com/watch?v=oBSXT_6YDzg) – Panelbeszélgetés a fejlesztőközpontú projektépítés buktatóiról (videó, 34 perc) + +## Első lépések {#getting-started} + +- [Heurisztika a web3-hoz](/developers/docs/design-and-ux/heuristics-for-web3/) - 7 heurisztika a web3-interfész dizájnjához +- [DEX dizájn bevált gyakorlatok](/developers/docs/design-and-ux/dex-design-best-practice/) - Útmutató a decentralizált tőzsdék tervezéséhez + +## Web3-tervezési esettanulmányok {#design-case-studies} + +- [Deep Work Studio](https://deepwork.studio/case-studies/) +- [A Crypto UX kézikönyve](https://www.cryptouxhandbook.com/) +- [NFT eladás az OpenSea platformon](https://builtformars.com/case-studies/opensea) +- [Wallet UX-kibontás a tárcák megváltoztatásáról](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (videó, 20 perc) + +## Tervezési jutalmak {#bounties} + +- [Dework](https://app.dework.xyz/bounties) +- [Buildbox hackathons](https://app.buidlbox.io/) +- [ETHGlobal hackathonok](https://ethglobal.com/) + +## Tervezési DAO-k és közösségek {#design-daos-and-communities} + +Vegyen részt a szakmai közösség által irányított szervezetekben, vagy csatlakozzon tervezési csoportokhoz, hogy megvitassa a tervezéssel és kutatással kapcsolatos témákat és trendeket más tagokkal. + +- [Vectordao.com](https://vectordao.com/) +- [Deepwork.studio](https://www.deepwork.studio/) +- [Designer-dao.xyz](https://www.designer-dao.xyz/) +- [We3.co](https://we3.co/) +- [Openux.xyz](https://openux.xyz/) +- [Nyílt forráskódú Web3Design](https://www.web3designers.org/) + +## Tervezési rendszerek {#design-systems} + +- [Optimism Design](https://www.figma.com/@optimism) (Figma) +- [Ethereum.org tervezési rendszer](https://www.figma.com/@ethdotorg) (Figma) +- [Finity – a Polygon tervezési rendszere](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) +- [Kleros tervezési rendszer](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) +- [Safe Design System](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) +- [ENS tervezési rendszer](https://thorin.ens.domains/) +- [Mirror tervezési rendszer](https://degen-xyz.vercel.app/) + +**Az oldalon szereplő cikkek és projektek nem minősülnek az Ethereum által minősített termékeknek**, az itt megjelenő adataik tájékoztatási célt szolgálnak. A hivatkozásokat a [listázási szabályzatunkban](/contributing/design/adding-design-resources) szereplő kritériumok alapján adjuk hozzá ehhez az oldalhoz. Ha szeretne egy új projektet/cikket hozzáadni, szerkessze ezt az oldalt a [GitHubon](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md). diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/mev/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/mev/index.md new file mode 100644 index 00000000000..44c822f2089 --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/mev/index.md @@ -0,0 +1,221 @@ +--- +title: Maximálisan kinyerhető érték (MEV) +description: Bevezetés a maximálisan kinyerhető érték (MEV) lényegébe +lang: hu +--- + +A maximális kinyerhető érték (MEV) arra utal, hogy a blokk létrehozásából kapható sztenderd blokkjutalmon és a gázdíjakon felül plusz értéket lehet szerezni a tranzakciók blokkba helyezésével, kizárásával és a sorrendek megváltoztatásával. + +## Maximálisan kinyerhető érték (MEV) {#maximal-extractable-value} + +A maximálisan kinyerhető értéket először a [proof-of-work (munkaigazolás)](/developers/docs/consensus-mechanisms/pow/) kontextusában alkalmazták, és ezért „bányászattal kivonható értékként” emlegették. Mivel a proof-of-work esetében a bányászok ellenőrzik a tranzakciók felvételét, kizárását és sorrendjét. [A Beolvadás](/roadmap/merge) során áttértek a proof-of-stake (letéti igazolás) mechanizmusára, és ezeket a szerepeket a validátorok látják el, a bányászat pedig nem része az Ethereum protokolljának. Értékkinyerési módszerek azonban továbbra is léteznek, ezért jelenleg a „maximálisan kinyerhető érték” kifejezést használjuk. + +## Előfeltételek {#prerequisites} + +A téma könnyebb megértése érdekében érdemes megismeri a [tranzakciókkal](/developers/docs/transactions/), [blokkokkal](/developers/docs/blocks/), [proof-of-stake-kel](/developers/docs/consensus-mechanisms/pos) és [gázzal](/developers/docs/gas/) foglalkozó témákat. Emellett a [dappok](/dapps/) és a [DeFi](/defi/) ismerete szintén hasznos. + +## MEV kivonása {#mev-extraction} + +Elméletileg a MEV teljes egészében a validátoroknál keletkezik, mivel ők tudják garantálni a profitábilis MEV-lehetőségek végrehajtását. A gyakorlatban a MEV nagy részét független hálózati résztvevők, úgynevezett „keresők” nyerik ki. A keresők komplex algoritmusokat futtatnak a blokkláncadatokon, hogy felismerjék a profitábilis MEV-lehetőségeket, és botok révén automatikusan beküldik ezeket a nyereséges tranzakciókat a hálózatba. + +A validátorok megkapják a MEV-összeg egy részét, mivel a keresők hajlandók magas gázdíjat fizetni (a validátornak) azért, hogy a nyereséges tranzakcióik bekerülhessenek egy adott blokkba. Feltételezve, hogy a keresők gazdaságilag racionálisak, a kereső által fizetett gázdíj a kereső MEV-jének legfeljebb 100%-a (mert ha a gázdíj magasabb lenne, pénzt veszítene vele). + +Viszont az erősen versenyképes MEV-lehetőségeknél, mint a [DEX arbitrázs](#mev-examples-dex-arbitrage), a keresőknek a teljes MEV-bevétel 90%-át vagy többet kell gázdíjként kifizetniük a validátornak, mivel sokan akarják ugyanazt az arbitrázst lefuttatni. Mivel az arbitrázsügyletük lefutását csak úgy tudják garantálni, ha a legmagasabb gázárral rendelkező tranzakciót adják be. + +### Gázgolfozás {#mev-extraction-gas-golfing} + +A MEV-vel kapcsolatos dinamika versenyelőnnyé tette a „gázgolfozást” – amikor a tranzakciókat úgy programozzák, hogy a lehető legkevesebb gázt használják –, mivel a keresők magasabb gázárat tudnak megadni, miközben a teljes gázdíjuk állandó (gázdíj = gázár * felhasznált gáz). + +Néhány jól ismert gázgolfozási technika: olyan címek használata, amelyek hosszú nullasorozattal kezdődnek (például [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://etherscan.io/address/0x0000000000c521824eaff97eac7b73b084ef9306)), mivel ezek tárolása kevesebb helyet (így kevesebb gázt) igényel; kis [ERC-20](/developers/docs/standards/tokens/erc-20/) tokenegyenleg meghagyása a szerződésekben, mivel több gázba kerül egy tárolóhely inicializálása (ha az egyenleg 0), mint a frissítése. A gázfelhasználás csökkentésére irányuló technikák kutatása aktív témakörnek számít a keresők körében. + +### Általánosított frontrunnerök {#mev-extraction-generalized-frontrunners} + +Ahelyett, hogy komplex algoritmusokat programoznának a profitábilis MEV-lehetőségek felderítésére, egyes keresők általánosított frontrunneröket futtatnak. Ezek az általánosított frontrunnerök, amelyek figyelik a memóriakészletet, hogy felismerjék a profitábilis tranzakciókat. A frontrunner lemásolja a potenciálisan nyereséges tranzakció kódját, kicseréli a címeket a frontrunner címére, és helyben lefuttatja a tranzakciót, hogy ellenőrizze, a módosított tranzakció nyereséget eredményez-e. Ha a tranzakció valóban nyereséges, a frontrunner benyújtja a módosított tranzakciót a kicserélt címmel és magasabb gázárral, „megelőzve” az eredeti tranzakciót, és megkapja az eredeti kereső MEV-jét. + +### Flashbots {#mev-extraction-flashbots} + +A Flashbots egy független projekt, amely a végrehajtási klienseket egy olyan szolgáltatással bővíti, amely lehetővé teszi a keresők számára, hogy MEV-tranzakciókat nyújtsanak be a validátoroknak anélkül, hogy a nyilvános memóriakészlet számára felfednék azokat. Ez megakadályozza, hogy a tranzakciókat általánosított frontrunnerök futtassák. + +## Példák a MEV-re {#mev-examples} + +A MEV többféleképpen is megjelenik a blokkláncon. + +### DEX arbitrázs {#mev-examples-dex-arbitrage} + +[A decentralizált tőzsdei (DEX)](/glossary/#dex) arbitrázs a legegyszerűbb és legismertebb MEV-lehetőség. Ennek eredményeképpen a legnépszerűbb is. + +Ez a következőképpen működik: ha két DEX két különböző áron kínál egy tokent, valaki megveheti a tokent az alacsonyabb árú DEX-en, és eladhatja a magasabb árú DEX-en egyetlen, atomikus tranzakció keretében. A blokklánc mechanikájának köszönhetően ez valódi, kockázatmentes arbitrázs. + +[Íme egy példa](https://etherscan.io/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) egy nyereséges arbitrázs tranzakcióra, ahol egy kereső 1000 ETH-t 1045 ETH-re váltott, kihasználva az ETH/DAI pár eltérő árazását az Uniswapon és a Sushiswapon. + +### Likvidációk {#mev-examples-liquidations} + +A kölcsönzési protokollok likvidációja egy másik jól ismert MEV-lehetőség. + +Az olyan kölcsönzési protokollok, mint a Maker és az Aave megkövetelik, hogy a felhasználók letétbe helyezzenek némi biztosítékot (például ETH-t). Ezt a letétbe helyezett biztosítékot aztán arra használják, hogy kölcsönadják más felhasználóknak. + +A felhasználók ezután kölcsönözhetnek eszközöket és tokeneket másoktól attól függően, hogy mire van szükségük (például MKR-t kölcsönözhet, ha szavazni szeretne egy MakerDAO javaslatban), a letétbe helyezett biztosíték bizonyos százalékáig. Például, ha a kölcsönzési összeg legfeljebb 30%, akkor egy felhasználó, aki 100 DAI-t fizet be a protokollba, legfeljebb 30 DAI értékű másik eszközt vehet kölcsön. A protokoll határozza meg a pontos kölcsönzési teljesítmény százalékos arányát. + +Ahogy a hitelfelvevő biztosítékának értéke ingadozik, úgy változik a hitelfelvételi képessége is. Ha a piaci ingadozások miatt a kölcsönvett eszközök értéke meghaladja a biztosíték értékének 30%-át (a pontos arányt a protokoll határozza meg), a protokoll általában lehetővé teszi, hogy bárki felszámolja a biztosítékot, azonnal kifizetve a hitelezőknek (hasonló a [pótlólagos fedezetbekéréshez (margin call)](https://www.investopedia.com/terms/m/margincall.asp) a hagyományos finanszírozásban). Likvidáció esetén a hitelfelvevőnek általában magas likvidációs díjat kell fizetnie, amelynek egy része a felszámolóhoz kerül – itt jön a képbe a MEV-lehetőség. + +A keresők versenyeznek a blokkláncadatok gyors elemzésében, hogy meghatározzák, mely hitelfelvevőket lehet likvidálni, elsőként nyújtsanak be likvidációs tranzakciót, és szedjék be maguknak a likvidációs díjat. + +### Szendvicskereskedelem {#mev-examples-sandwich-trading} + +A szendvicskereskedelem a MEV-kivonás másik gyakori módszere. + +A szendvicshez a kereső figyeli a memóriakészletet a nagy DEX-üzletekre. Például valaki 10 000 UNI-t akar vásárolni DAI-jal a Uniswapon. Egy ilyen nagyságrendű kereskedés jelentős hatással lesz az UNI/DAI párra, és jelentősen megemelheti az UNI árfolyamát a DAI-hoz képest. + +A kereső kiszámíthatja ennek az UNI/DAI párra gyakorolt megközelítő árhatását, és közvetlenül a kereskedés _előtt_ optimális vételi megbízást adhat, olcsón megvásárolva az UNI-t, majd közvetlenül a kereskedés _után_ eladási megbízást adhat, eladva azt a megbízás által okozott magasabb áron. + +A szendvicselés azonban kockázatosabb, mivel nem atomikus (ellentétben a fenti DEX-arbitrázzsal), és hajlamos a [szalmonella-támadásra](https://github.com/Defi-Cartel/salmonella). + +### NFT MEV {#mev-examples-nfts} + +A MEV az NFT-k esetében egy kialakulóban lévő jelenség, és nem feltétlenül nyereséges. + +Mivel azonban az NFT tranzakciók ugyanazon a blokkláncon történnek, amelyet az összes többi Ethereum tranzakció megoszt, a keresők az NFT piacon is hasonló technikákat használhatnak, mint a hagyományos MEV-lehetőségeknél. + +Például, ha van egy népszerű NFT-kiadás, és egy kereső egy bizonyos NFT-t vagy NFT-készletet szeretne, akkor beprogramozhat egy tranzakciót úgy, hogy ő legyen az első a sorban, vagy egyetlen tranzakcióban megvásárolhatja az egész készletet. Vagy ha egy NFT [tévesen alacsony áron szerepel](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent), a kereső megelőzheti a többi vevőt, és olcsón megveheti. + +Az NFT MEV egyik kiemelkedő példája az volt, amikor egy kereső 7 millió dollárt költött arra, hogy [megvásárolja](https://etherscan.io/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5) az összes Cryptopunkot a legalacsonyabb áron. Egy blokklánckutató [magyarázta a Twitteren](https://twitter.com/IvanBogatyy/status/1422232184493121538), hogy a vevő egy MEV-szolgáltatóval dolgozott, hogy titokban tartsa a vásárlást. + +### Hosszú távú lehetőségek (long tail) {#mev-examples-long-tail} + +A DEX arbitrázs, a likvidációk és a szendvicskereskedelem nagyon jól ismert MEV-lehetőségek, és nem valószínű, hogy nyereségesek lennének az új keresők számára. Létezik azonban a kevésbé ismert MEV-lehetőségek esetében egy hosszú távú lehetőség (az NFT MEV is ilyen). + +Akik most kezdik a keresést, több sikert érhetnek el, ha a long tail szekcióban (kevésbé ismert, kisebb hozammal járó, hosszabb távon használható lehetőségek között) keresnek MEV-et. A Flashbot [MEV-állásbörzéje](https://github.com/flashbots/mev-job-board) felsorol néhány új lehetőséget. + +## A MEV hatásai {#effects-of-mev} + +A MEV nem feltétlen rossz, pozitív és negatív következményei is vannak az Ethereumban. + +### A pozitív hatásai {#effects-of-mev-the-good} + +Számos DeFi-projekt gazdaságilag racionális szereplőkre támaszkodik, hogy biztosítsa protokolljaik hasznosságát és stabilitását. Például a DEX arbitrázs biztosítja, hogy a felhasználók a legjobb, legkorrektebb árakat kapják a tokenjeikért, a hitelezési protokollok pedig a gyors likvidációra támaszkodnak, amikor a hitelfelvevők a fedezeti arányok alá esnek, hogy a hitelezők visszakapják a pénzüket. + +Ha a racionális keresők nem keresik és javítják a gazdasági hatástalanságokat, és nem használják ki a protokollok gazdasági ösztönzőit, a DeFi protokollok és általában a dappok nem lehetnek olyan erősek, mint jelenleg. + +### A negatív hatásai {#effects-of-mev-the-bad} + +Az alkalmazási rétegen a MEV egyes formái, mint például a szendvicskereskedelem, egyértelműen rosszabb felhasználói élményt eredményeznek. A szendvicsbe szorított felhasználóknak nagyobb csúszással és rosszabb teljesítéssel kell számolniuk a kereskedéseik során. + +A hálózati szinten az általánosított frontrunnerök és az általuk gyakran folytatott gázár-árverések (két vagy több frontrunner versenyez, hogy tranzakciójuk bekerüljön a következő blokkba a gázár fokozatos emelésével) a hálózat túlterheltségét és magas gázárakat eredményeznek másoknak is, akik szabályos tranzakciókat próbál végrehajtani. + +A _blokkon belüli_ eseményeken túl a MEV káros hatással lehet _blokkok között_ is. Ha a blokkban elérhető MEV jelentősen meghaladja a sztenderd blokkjutalmat, a validátorokat arra ösztönözhetik, hogy blokkokat szervezzenek át, és a MEV-et maguknak szerezzék meg, ami a blokklánc átrendeződését és a konszenzus instabilitását okozza. + +A blokklánc átszervezésének ezt a lehetőségét [a Bitcoin blokkláncon](https://dl.acm.org/doi/10.1145/2976749.2978408) már korábban is vizsgálták. Ahogy a Bitcoin blokkjutalma a felére csökken, és a tranzakciós díjak egyre nagyobb részét teszik ki a blokkjutalomnak, kialakulhat, hogy a bányászoknak gazdaságilag racionális lehet, ha lemondanak a következő blokk jutalmáról, és helyette magasabb díjakkal újrabányásszák a korábbi blokkokat. A MEV növekedésével ugyanez a helyzet állhat elő az Ethereumban is, ami veszélyezteti a blokklánc integritását. + +## A MEV jelenlegi helyzete {#state-of-mev} + +A MEV-kivonás 2021 elején felpörgött, ami az év első hónapjaiban rendkívül magas gázárakat eredményezett. A Flashbots MEV relay (közvetítő) megjelenése csökkentette az általános frontrunnerök hatékonyságát, és láncon kívülre vitte a gázár-árveréseket, csökkentve a gázárakat a hétköznapi felhasználók számára. + +Bár sok kereső még mindig jól keres a MEV-vel, de ahogy a lehetőségek egyre ismertebbek és több kereső versenyez ugyanazért, a validátorok egyre több MEV-bevételt fognak szerezni (a Flashbots-ban is ugyanolyan gázárverések zajlanak, mint a fenti, bár magánjelleggel, és a validátorok az ebből származó gázbevételt kapják meg). A MEV nem csak az Ethereumra jellemző, és mivel egyre nagyobb a verseny, a keresők alternatív blokkláncok, például a Binance Smart Chain felé mozdulnak el, ahol hasonló MEV-lehetőségek léteznek kevesebb versennyel. + +Másrészt a proof-of-work-ről a proof-of-stake-re való áttérés és az Ethereum összevont tranzakciókkal történő skálázása olyan módon változtatják meg a MEV-térképet, amely még nem világos. Még nem ismert, hogy a némileg előre ismert blokkelőterjesztők hogyan változtatják meg a MEV-kivonás dinamikáját a proof-of-work valószínűségi modelljéhez képest, vagy hogyan változik, amikor [egyetlen, titkos vezetőválasztás](https://ethresear.ch/t/secret-non-single-leader-election/11789) és [elosztott validátortechnológia](/staking/dvt/) kerül bevezetésre. Még az sem egyértelmű, milyen MEV-lehetőségek lesznek, amikor a felhasználói tevékenységek az Ethereumról áthelyeződnek a második blokkláncrétegre (L2), az összevont tranzakciókra és a szilánkokra. + +## MEV az Ethereum proof-of-stake (PoS) mechanizmusában {#mev-in-ethereum-proof-of-stake} + +Amint azt kifejtettük, a MEV negatív hatással van az általános felhasználói élményre és a konszenzusszintű biztonságra. Az Ethereumnak a proof-of-stake konszenzusra való áttérése („a Beolvadás”) potenciálisan új, MEV-hez kapcsolódó kockázatokat hoz létre: + +### Validátorcentralizáció {#validator-centralization} + +A Beolvadás utáni Ethereumban a validátorok (miután 32 ETH értékű letétet helyeztek el) konszenzusra jutnak a Beacon lánchoz hozzáadott blokkok érvényességéről. A 32 ETH sokak számára elérhetetlen lehet, ezért megvalósíthatóbb[ egy letéti alaphoz való csatlakozás ](/staking/pools/). Mindazonáltal az [önálló letétbe helyezők](/staking/solo/) egészséges eloszlása ideális, mivel enyhíti a validátorok centralizációját és javítja az Ethereum biztonságát. + +A MEV-kivonás vélhetően képes felgyorsítani a validátorok centralizációját. Ez részben azért van így, mert a validátorok [kevesebbet kapnak a blokkelőterjesztésért](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply), mint korábban a bányászatért, a MEV-kivonás jelentősen [befolyásolhatja a validátorok bevételeit](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb) a [Beolvadás](/roadmap/merge/) után. + +A nagyobb letéti alapok valószínűleg több erőforrással rendelkeznek ahhoz, hogy befektessenek a MEV-lehetőségek kihasználásához szükséges optimalizálásokba. Minél több MEV-t termelnek ki ezek a poolok, annál több erőforrásuk van ennek fejlesztésére (és a bevétel növelésére), ami [méretgazdaságosságot](https://www.investopedia.com/terms/e/economiesofscale.asp#) eredményez. + +Az önálló letétbe helyezők, akiknek kevesebb erőforrás áll a rendelkezésükre, nem feltétlen tudnak profitálni a MEV-lehetőségekből. Ez növelheti a független validátorokra nehezedő nyomást, hogy erős letéti alapokhoz csatlakozzanak, és így növeljék a bevételüket, ami csökkenti a decentralizációt az Ethereumban. + +### Engedélyhez kötött memóriakészletek {#permissioned-mempools} + +A szendvics és a frontrunning támadásokra válaszul a kereskedők a tranzakciók titkossága érdekében a láncon kívül is megegyezhetnek a validátorokkal. Ahelyett, hogy a kereskedő a nyilvános memóriakészletbe küldene egy potenciális MEV-tranzakciót, a kereskedő közvetlenül a validátornak küldi azt, aki beemeli egy blokkba, és osztozik a nyereségen a kereskedővel. + +Ennek az elrendezésnek egy nagyobb változatai a „sötét alapok”, melyek engedélyhez kötött, csak hozzáférést adó memóriakészletek, amelyek a fizetős felhasználók számára elérhetők. Ez a tendencia csökkentené az Ethereum engedélymentességét és a bizalomigény-mentességet, potenciálisan egy „pay-to-play” (fizetős játék) mechanizmussá alakítaná át, amely a legmagasabb ajánlattevőnek kedvez. + +Az engedélyhez kötött memóriakészletek az előző szakaszban leírt centralizációs kockázatokat is felgyorsítják. A több validátort működtető nagy alapok valószínűleg profitálni fognak abból, hogy a kereskedők és a felhasználók számára tranzakciós adatvédelmet kínálnak, növelve ezzel a MEV-bevételeiket. + +Ezeknek a MEV-hez kapcsolódó problémáknak a leküzdése a Beolvadás utáni Ethereumban a kutatás egyik fő területe. Két megoldás merült fel, hogy a MEV negatív hatását csökkentsék az Ethereum decentralizációja és biztonsága szempontjából a Beolvadás után: [**javaslattevő-építő szétválasztása (PBS)**](/roadmap/pbs/) és az [**építő API**](https://github.com/ethereum/builder-specs). + +### Javaslattevő-építő szétválasztása (PBS) {#proposer-builder-separation} + +Mind a proof-of-work, mind a proof-of-stake esetében egy csomópont építi a blokkot, majd javasolja azt a konszenzusban részt vevő többi csomópontnak a láncba való felvételre. Egy új blokk akkor válik a kanonikus lánc részévé, ha egy másik bányász ráépít (PoW esetén), vagy ha a validátorok többségétől tanúsítást kap (PoS esetén). + +A blokképítő és blokkajánló szerepek kombinációja az, ami a legtöbb MEV-hez kapcsolódó problémát okozza. A konszenzuscsomópontokat például arra ösztönzik, hogy a MEV-bevételek maximalizálása érdekében [időzített támadásokban](https://www.mev.wiki/attack-examples/time-bandit-attack) láncátrendezéseket indítsanak el. + +A [javaslattevő-építő szétválasztása (PBS)](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) a MEV hatásának mérséklésére szolgál, különösen a konszenzusrétegben. A PBS fő jellemzője a blokképítő és a blokkelőterjesztő szabályainak szétválasztása. A validátorok továbbra is felelősek a blokkok előterjesztéséért és az azokra vonatkozó szavazásért, de a tranzakciók elrendezése és a blokkok építése egy új, specializált entitás, a **blokképítő** feladata. + +A PBS keretében egy blokképítő létrehoz egy tranzakciócsomagot, és ajánlatot tesz arra, hogy egy Beacon lánc blokkba bekerüljön, mint végrehajtási csomag (payload). A következő blokk előterjesztésére kiválasztott validátor ezután ellenőrzi az ajánlatokat, és kiválasztja a legmagasabb díjú csomagot. A PBS lényegében egy aukciós piacot hoz létre, ahol az építők tárgyalnak a blokkterületet értékesítő validátorokkal. + +A jelenlegi PBS-tervek egy [elköteleződés-feltárás sémát](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/) használnak, amelyben az építők csak a blokk tartalmára vonatkozó kriptográfiai elköteleződést (blokkfejléc) teszik közzé az ajánlatukkal. A nyertes ajánlat elfogadása után az ajánlattevő egy aláírt blokkajánlatot készít, amely tartalmazza a blokkfejlécet. A blokképítőnek az aláírt blokkjavaslat megtekintése után közzé kell tennie a teljes blokkot, és a véglegesítés előtt elegendő [tanúsítást](/glossary/#attestation) kell kapnia a validátoroktól. + +#### Hogyan enyhíti a javaslattevő-építő szétválasztás a MEV hatását? {#how-does-pbs-curb-mev-impact} + +A protokollon belüli javaslattevő-építő szétválasztása csökkenti a MEV konszenzusra gyakorolt hatását azáltal, hogy a MEV-kivonás kikerül a validátorok hatásköréből. Ehelyett a speciális hardvert futtató blokképítők fogják megragadni a jövőben a MEV-lehetőségeket. + +Ez azonban nem zárja ki teljesen a validátorokat a MEV-hez kapcsolódó bevételekből, mivel az építőknek magas ajánlatot kell tenniük ahhoz, hogy blokkjaikat a validátorok elfogadják. Mindazonáltal, mivel a validátorok már nem összpontosítanak közvetlenül a MEV-bevételek optimalizálására, csökken az időzített támadások veszélye. + +A javaslattevő-építő szétválasztása csökkenti a MEV centralizációs kockázatait is. Például a elköteleződés-feltárás séma megszünteti azt a bizalomkényszert az építők részéről, hogy a validátorok nem lopják el a MEV-lehetőséget, vagy nem juttatják azt más építőnek. Ez csökkenti az akadályokat az önálló letétbe helyezők számára, hogy a MEV előnyeiből részesüljenek, máskülönben az építők inkább a nagy, a láncon kívüli hírnévvel rendelkező alapokat részesítenék előnyben, és láncon kívüli üzleteket kötnének velük. + +Hasonlóképpen, a validátoroknak nem kell attól tartani, hogy az építők visszatartanak blokkokat vagy érvényteleneket adnak, mivel a fizetés feltétel nélküli. A validátor díja akkor is feldolgozható, ha a javasolt blokk nem áll rendelkezésre, vagy egy másik validátor érvénytelennek nyilvánítja. Az utóbbi esetben a blokkot egyszerűen elvetik, így a blokképítő elveszíti a tranzakciós díjat és MEV-bevételt. + +### Építő API {#builder-api} + +Bár a javaslattevő-építő szétválasztás azt ígéri, hogy csökkenti a MEV-kivonás hatásait, a megvalósítása a konszenzusprotokoll módosítását igényli. Konkrétan a Beacon lánc [elágazásválasztási](/developers/docs/consensus-mechanisms/pos/#fork-choice) szabályát kell hozzá frissíteni. Az [építő API](https://github.com/ethereum/builder-specs) egy ideiglenes megoldás, amelynek célja a javaslattevő-építő szétválasztásának megvalósítása, bár magasabb bizalomigénnyel. + +Az építő API az [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) módosított változata, amelyet a konszenzusréteg kliensei használnak arra, hogy a végrehajtási réteg klienseitől végrehajtási csomagokat kérjenek. Az [őszintevalidátor-specifikáció](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md) szerint a blokkelőterjesztési feladatokra kiválasztott validátorok tranzakciócsomagot kérnek egy kapcsolódó végrehajtási klienstől, amelyet a javasolt Beacon lánc blokkjába foglalnak. + +Az építő API szintén közvetítőként működik a validátorok és a végrehajtási réteg kliensei között; de ez más, mivel lehetővé teszi a Beacon láncon lévő validátoroknak, hogy külső entitásoktól szerezzenek blokkokat (nem helyben építik fel a végrehajtási klienssel). + +Az alábbiakban látható az építő API működése: + +1. Az építő API összekapcsolja a validátort a blokképítők hálózatával, amely végrehajtási réteg klienseket futtat. A PBS-hez hasonlóan az építők olyan specializált felek, akik erőforrásigényes blokképítésbe fektetnek be, és különböző stratégiákat alkalmaznak a MEV + elsőbbségi díjak maximalizálására. + +2. A validátor (amely egy konszenzusréteg-klienst futtat) az építőhálózattól ajánlatokkal együtt kéri a végrehajtási csomagot. Az építők ajánlatai tartalmazzák a végrehajtási csomag fejlécét – ami a csomag tartalmára vonatkozó kriptográfiai elköteleződés – és a validátornak fizetendő díjat. + +3. A validátor megvizsgálja a beérkező ajánlatokat, és kiválasztja a legmagasabb díjjal rendelkező végrehajtási csomagot. Az építő API használatával a validátor létrehoz egy „vak” Beacon-blokk javaslatot, amely csak az aláírását és a végrehajtási csomag fejlécét tartalmazza, majd elküldi azt az építőnek. + +4. Az építő API-t futtató építőtől elvárható, hogy a teljes végrehajtási csomaggal válaszoljon, amikor meglátja a vak blokkjavaslatot. Ez lehetővé teszi a validátorok számára, hogy „aláírt” Beacon-blokkot hozzanak létre, amelyet az egész hálózatban elterjesztenek. + +5. Az építő API-t használó validátortól továbbra is elvárják, hogy helyben építsen blokkot, ha a blokképítő nem válaszol azonnal, így nem marad le a blokkjavaslatok jutalmáról. A validátor azonban nem hozhat létre egy másik blokkot a felfedett tranzakciókkal vagy egy másik adaggal, mivel ez _kétértelműség_ lenne (két blokk aláírása egy sloton belül), ami szabálysértésnek minősül. + +Az építő API egyik példája a [MEV Boost](https://github.com/flashbots/mev-boost), a [Flashbots aukciós mechanizmus](https://docs.flashbots.net/Flashbots-auction/overview/) továbbfejlesztése, amelynek célja a MEV negatív hatásainak csökkentése az Ethereumban. A Flashbots aukció lehetővé teszi a proof-of-stake mechanizmusban a validátorok számára, hogy a nyereséges blokkok építését specializált **keresőknek** adják ki. ![Egy diagram, amely a MEV áramlását mutatja be részleteiben](./mev.png) + +A keresők jövedelmező MEV-lehetőségeket keresnek, és tranzakciós csomagokat küldenek a blokkelőterjesztőknek egy [lepecsételt árú ajánlattal](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) együtt a blokkba való felvételre. A mev-geth-et, a go-ethereum (Geth) kliens elágaztatott változatát futtató validátornak csak ki kell választania a legnagyobb nyereséget hozó köteget, és azt az új blokk részévé kell tennie. A blokkelőterjesztők (validátorok) spamektől és érvénytelen tranzakcióktól való védelme érdekében a tranzakciókötegeket **közvetítők (relayer)** ellenőrzik, mielőtt azok eljutnak az előterjesztőhöz. + +A MEV Boost megtartja az eredeti Flashbots aukció működését, bár az Ethereum proof-of-stake-re való átállásához tervezett új funkciókkal. A keresők továbbra is találnak jövedelmező MEV-tranzakciókat a blokkokba való felvételhez, de a tranzakciók és kötegek blokkokká történő összevonásáért új, specializált szereplők, az **építők** felelősek. Az építő elfogadja a keresők lepecsételt-árú ajánlatait, és optimalizálásokat futtat a legjövedelmezőbb sorrend megtalálása érdekében. + +A közvetítő továbbra is felelős a tranzakciókötegek validálásáért, mielőtt továbbítja azokat a javaslattevőnek. A MEV Boost ugyanakkor bevezeti a **letéteket**, amelyek a [adatelérhetőség](/developers/docs/data-availability/) biztosításáért felelősek az építők által küldött blokkok és a validátorok által küldött blokkfejlécek tárolásával. Itt a közvetítőhöz (relay) csatlakozó validátor kéri az elérhető végrehajtási csomagokat, és a MEV Boost rendezési algoritmusát használja arra, hogy a legmagasabb ajánlatot és a MEV-borravalókat tartalmazó csomag fejlécét kiválassza. + +#### Hogyan csökkenti az építő API a MEV hatását? {#how-does-builder-api-curb-mev-impact} + +Az építő API alapvető előnye, hogy demokratizálja a MEV-lehetőségekhez való hozzáférést. A elköteleződés-feltárás sémák használata kiküszöböli a bizalmi feltételezéseket, és csökkenti a belépési korlátokat a MEV előnyeit kihasználni kívánó validálók számára. Ez csökkentené az önálló letétbe helyezőkön lévő nyomást, hogy a MEV-nyereség növelése érdekében nagy letéti alapokba integrálódjanak. + +Az építő API széles körű bevezetése nagyobb versenyt ösztönöz a blokképítők között, ami növeli a cenzúrával szembeni ellenállást. Mivel a validátorok több építő ajánlatát vizsgálják, az egy vagy több tranzakciót cenzúrázó építőnek túl kell licitálnia a nem cenzúrázók ajánlatait ahhoz, hogy sikeres legyen. Ez rendkívül megnöveli a felhasználók cenzúrázásának költségeit, és így elrettenti őket ettől a gyakorlattól. + +Egyes projektek, mint például a MEV Boost, az építő API-t egy olyan átfogó struktúra részeként használják, amelynek célja, hogy bizonyos felek, például a frontrunning/szendvicstámadásokat elkerülni próbáló kereskedők számára adatvédelmet biztosítson. Ezt úgy érjük el, hogy privát kommunikációs csatornát biztosítunk a felhasználók és a blokképítők között. A fenti engedélyhez kötött memóriakészletekkel ellentétben ez a megközelítés a következők miatt előnyös: + +1. Mivel a piacon több építő is jelen van, a cenzúrázás gyakorlatilag lehetetlen, ami előnyös a felhasználók számára. Ezzel szemben a centralizált és bizalomigényű „sötét alapok” létezése néhány blokképítő kezében összpontosítaná a hatalmat, és növelné a cenzúra lehetőségét. + +2. Az építő API szoftver nyílt forráskódú, ami lehetővé teszi, hogy bárki blokképítő szolgáltatásokat kínáljon. Eszerint a felhasználók nem kényszerülnek arra, hogy egy adott blokképítőt használjanak, és javítja az Ethereum semlegességét és engedélymentességét. Ráadásul a MEV-et kereső kereskedők nem járulnak hozzá akaratlanul a centralizációhoz azzal, hogy privát tranzakciós csatornákat használnak. + +## Kapcsolódó források {#related-resources} + +- [Flashbots-dokumentáció](https://docs.flashbots.net/) +- [Flashbots GitHub](https://github.com/flashbots/pm) +- [MEV-Explore](https://explore.flashbots.net/) – _Dashboard és tranzakciófelfedező a MEV tranzakciókhoz_ +- [mevboost.org](https://www.mevboost.org/) – _Tracker valós idejű statisztikákkal a MEV-Boost közvetítőkhöz és blokképítőkhöz_ + +## További olvasnivaló {#further-reading} + +- [Mi az a bányászattal kivonható érték (MEV)?](https://blog.chain.link/what-is-miner-extractable-value-mev/) +- [A MEV és én](https://www.paradigm.xyz/2021/02/mev-and-me) +- [Az Ethereum egy sötét erdő](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) +- [Kijutni a sötét erdőből](https://samczsun.com/escaping-the-dark-forest/) +- [Flashbots: megelőzni (frontrunning) a MEV-krízist](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) +- [@bertcmiller MEV írásai](https://twitter.com/bertcmiller/status/1402665992422047747) +- [MEV-Boost: A Beolvadásra kész Flashbots-architektúra](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) +- [Mi az a MEV Boost](https://www.alchemy.com/overviews/mev-boost) +- [Miért futtassunk MEV Boost-ot?](https://writings.flashbots.net/writings/why-run-mevboost/) +- [Ethereum útikalauz stopposoknak](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/oracles/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/oracles/index.md new file mode 100644 index 00000000000..4d5be1d51fb --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/oracles/index.md @@ -0,0 +1,433 @@ +--- +title: Orákulumok +description: Az orákulumok valós adatokhoz való hozzáférést biztosítanak az Ethereum okosszerződései számára, több felhasználási lehetőséget és nagyobb értéket teremtve a felhasználóknak. +lang: hu +--- + +Az orákulumok olyan alkalmazások, amelyek adatcsatornákat hoznak létre, hogy elérhetővé tegyék a láncon kívüli adatforrásokat a blokkláncon lévő okosszerződések számára. Erre azért van szükség, mert az Ethereum-alapú okosszerződések alapértelmezés szerint nem férhetnek hozzá a blokkláncon kívül tárolt információkhoz. + +Ha az okosszerződéseket a láncon kívüli adatok felhasználásával lehet végrehajtani, az kiterjeszti a decentralizált alkalmazások hasznosságát és értékét. A láncon belüli előrejelzési piacok például orákulumokra támaszkodnak, hogy információt szolgáltassanak az eredményekről, amelyet a felhasználók előrejelzéseinek validálására használnak. Tegyük fel, hogy Alice 20 ETH-t tesz fel arra, hogy ki lesz a következő amerikai elnök. Ebben az esetben az előrejelzési piac dappnak szüksége van egy orákulumra, amely megerősíti a választási eredményeket, és meghatározza, hogy Alice jogosult-e kifizetésre. + +## Előfeltételek {#prerequisites} + +Ezt az oldalt könnyebb megérteni, ha az olvasó ismeri az Ethereum alapjait, beleértve a [csomópontokat](/developers/docs/nodes-and-clients/), a [konszenzusmechanizmusokat](/developers/docs/consensus-mechanisms/) és az [EVM-et](/developers/docs/evm/). Érdemes ismerni a [okosszerződéseket](/developers/docs/smart-contracts/) és a [okosszerződések anatómiáját](/developers/docs/smart-contracts/anatomy/), különösen az [eseményeket](/glossary/#events). + +## Mi az a blokkláncorákulum? {#what-is-a-blockchain-oracle} + +Az orákulumok olyan alkalmazások, amelyek külső információkat (azaz a láncon kívül tárolt információkat) gyűjtenek, ellenőriznek és továbbítanak a blokkláncon futó okosszerződésekhez. Amellett, hogy az orákulumok a láncon kívüli adatokat hoznak be az Ethereumra és terjesztik szét azokat, a blokkláncról információkat is küldhetnek külső rendszerekbe, például feloldhatnak egy intelligens zárat, amint a felhasználó Ethereum-tranzakción keresztül elküldi a releváns díjat. + +Orákulum nélkül az okosszerződés kizárólag a láncon belüli adatokra korlátozódna. + +Az orákulumok eltérnek az adatforrás (egy vagy több forrás), a bizalomigény (centralizált vagy decentralizált) és a rendszer felépítése (azonnali olvasás, közzététel-feliratkozás és kérés-válasz) szerint. Az orákulumokat aszerint is megkülönböztethetjük, hogy külső adatokat kérnek le a láncon belüli szerződéseknek (bemeneti orákulumok), információt küldenek a blokkláncból a láncon kívüli alkalmazásoknak (kimeneti orákulumok), vagy számítási feladatokat végeznek a láncon kívül (számítási orákulumok). + +## Miért szükséges az okosszerződésekhez orákulum? {#why-do-smart-contracts-need-oracles} + +Sok fejlesztő úgy tekint az okosszerződésekre, mint a blokklánc adott címein futó kódokra. Az okosszerződések [általánosabb nézete](/smart-contracts/) azonban az, hogy ezek olyan önvégrehajtó szoftverprogramok, amelyek képesek a felek közötti megállapodások érvényesítésére, ha bizonyos feltételek teljesülnek – innen ered az okosszerződés kifejezés. + +De az okosszerződések használata az emberek közötti megállapodások érvényesítésére nem egyszerű, mivel az Ethereum determinisztikus. A [determinisztikus rendszer](https://en.wikipedia.org/wiki/Deterministic_algorithm) egy kezdeti állapot, amely egy adott bemenet mellett mindig ugyanazt az eredményt produkálja, vagyis nincs véletlenszerűség vagy variáció a bemenetekből származó kimenetek kiszámításának folyamatában. + +A determinisztikus végrehajtás elérése érdekében a blokkláncok a csomópontokat arra korlátozzák, hogy egyszerű bináris (igaz/hamis) kérdésekben konszenzusra jussanak _csak_ a blokkláncon tárolt adatok felhasználásával. Példák az ilyen kérdésekre: + +- „A (nyilvános kulccsal azonosított) számlatulajdonos aláírta ezt a tranzakciót a hozzá tartozó privát kulccsal?” +- „Van-e elegendő fedezet ezen a számlán a tranzakció fedezésére?” +- „Érvényes ez a tranzakció az adott okosszerződés keretében?” stb. + +Ha a blokkláncok külső forrásból (azaz a való világból) kapnának információt, a determinizmus megvalósítása lehetetlen lenne, ami megakadályozná, hogy a csomópontok megegyezzenek a blokklánc státuszában bekövetkezett változásokról. Vegyünk például egy olyan okosszerződést, amely egy tranzakciót hajt végre a hagyományos ár-API-ból kapott aktuális ETH-USD árfolyam alapján. Ez a szám valószínűleg gyakran változik (arról nem is beszélve, hogy az API-t elavulttá tehetik vagy feltörhetik), ami azt jelenti, hogy az azonos szerződéskódot végrehajtó csomópontok különböző eredményekre jutnának. + +Egy olyan nyilvános blokklánc esetében, mint az Ethereum, ahol világszerte több ezer csomópont dolgozza fel a tranzakciókat, a determinizmus kritikus fontosságú. Mivel nincs központi hatóság, amely az igazság forrásaként szolgálna, a csomópontoknak olyan mechanizmusokra van szükségük, amelyekkel ugyanazon tranzakciók feldolgozása után ugyanazt az státuszt érik el. Az az eset, amikor az A csomópont végrehajtja egy okosszerződés kódját, és 3-at kap eredményként, míg a B csomópont 7-et kap ugyanarra, a konszenzus felbomlásához vezetne, és megszüntetné az Ethereum mint decentralizált számítástechnikai platform értékét. + +Ez a forgatókönyv rávilágít arra a problémára is, hogy a blokkláncokat úgy tervezzük meg, hogy külső forrásokból nyerjenek információkat. Az orákulumok azonban úgy oldják meg ezt a problémát, hogy információkat vesznek a láncon kívüli forrásokból, és azt a blokkláncon tárolják, hogy az okosszerződések felhasználhassák azokat. Mivel a láncon belül tárolt információk megváltoztathatatlanok és nyilvánosan elérhetők, az Ethereum-csomópontok biztonságosan használhatják a láncon kívülről importált orákulum-adatokat a státuszváltozások kiszámításához anélkül, hogy a konszenzus megszakadna. + +Ehhez az orákulum egy láncon belüli okosszerződésből és néhány láncon kívüli komponensből áll. A láncon belüli szerződés más okosszerződésektől kap adatigényléseket, amelyeket a láncon kívüli komponensnek (az úgynevezett orákulum-csomópontnak) továbbít. Ez az orákulum-csomópont lekérdezhet adatforrásokat – például alkalmazás programozási felület (API) használatával –, illetve tranzakciókat küldhet arra, hogy a kért adatok az okosszerződés tárolójába kerüljenek. + +Lényegében egy blokklánc-orákulum áthidalja a blokklánc és a külső környezet közötti információs szakadékot, „hibrid okosszerződéseket” létrehozva. A hibrid okosszerződés a láncon belüli szerződéskód és a láncon kívüli infrastruktúra kombinációján alapul. A decentralizált előrejelzési piacok kiváló példái a hibrid okosszerződéseknek. További példák lehetnek a terménybiztosítási okosszerződések, amelyek akkor fizetnek, amikor az orákulumok egy csoportja megállapítja, hogy bizonyos időjárási jelenségek bekövetkeztek. + +## Mi az orákulumprobléma? {#the-oracle-problem} + +Az orákulumok fontos problémát oldanak meg, de némi bonyodalmat is okoznak, például: + +- Hogyan ellenőrizzük, hogy a bejuttatott információ a megfelelő forrásból származik-e, vagy nem manipulálták-e? + +- Hogyan biztosítsuk, hogy ezek az adatok mindig rendelkezésre álljanak és rendszeresen frissüljenek? + +Az úgynevezett „orákulumprobléma” azokat a nehézségeket mutatja be, amelyek abból adódnak, hogy a blokklánc orákulumai adatot szolgáltatnak az okosszerződéseknek. Az orákulumtól származó adatoknak helyesnek kell lenniük ahhoz, hogy egy okosszerződés helyesen teljesüljön. Továbbá az, hogy meg kell bízni az orákulumoperátorokban, hogy pontos információkat szolgáltassanak, aláássa az okosszerződések bizalomigény nélküli aspektusát. + +A különböző orákulumok különböző megoldásokat kínálnak az orákulumproblémára, amelyeket később vizsgálunk meg. Az orákulumokat általában aszerint értékelik, hogy mennyire képesek kezelni a következő kihívásokat: + +1. **Helyesség**: Egy orákulum nem okozhatja, hogy az okosszerződések állapotváltozásokat indítsanak el érvénytelen, láncon kívüli adatok alapján. Az orákulumnak garantálnia kell az adatok _hitelességét_ és _integritását_. A hitelesség azt jelenti, hogy az adatok a megfelelő forrásból származnak, az integritás pedig az, hogy az adatok sértetlenek maradtak (azaz nem változtatták meg őket), mielőtt továbbküldték a láncon belülre. + +2. **Elérhetőség**: Az orákulum nem késleltetheti vagy akadályozhatja meg az okosszerződések végrehajtását és a státuszváltozások kiváltását. Ez azt jelenti, hogy az orákulumtól származó adatoknak megszakítás nélkül kell _rendelkezésre állniuk kérés esetén_. + +3. **Ösztönzőkompatibilitás**: Az orákulumnak ösztönöznie kell a láncokon kívüli adatszolgáltatókat arra, hogy helyes információkat küldjenek az okosszerződéseknek. Az ösztönzőkompatibilitás magában foglalja a _hozzárendelhetőséget_ és az _elszámoltathatóságot_. A hozzárendelhetőség lehetővé teszi egy külső információ összekapcsolását a szolgáltatójával, míg az elszámoltathatóság az adatszolgáltatókat az általuk adott információhoz köti, így a szolgáltatott információ minősége alapján jutalmazhatók vagy büntethetők. + +## Hogyan működik a blokklánc orákulumszolgáltatás? {#how-does-a-blockchain-oracle-service-work} + +### Felhasználók {#users} + +A felhasználók olyan entitások (azaz okosszerződések), amelyeknek a blokkláncon kívüli információkra van szükségük bizonyos műveletekhez. Az orákulumszolgáltatás alapvető folyamata azzal kezdődik, hogy a felhasználó adatot kér az orákulumszerződéstől. Az adatkérések általában az alábbi kérdések némelyikére vagy mindegyikére választ adnak: + +1. Milyen forrásokból tájékozódhatnak a láncon kívüli csomópontok a kért információról? + +2. Hogyan dolgozzák fel a riportolók az adatforrásokból származó információkat, és hogyan vonják ki a hasznos adatpontokat? + +3. Hány orákulum-csomópont vehet részt az adatok lekérdezésében? + +4. Hogyan kell kezelni az orákulumjelentésekben szereplő eltéréseket? + +5. Milyen módszert kell alkalmazni a beérkezett kérések szűrésére és a jelentések egyetlen értékké történő összesítésére? + +### Orákulumszerződés {#oracle-contract} + +Az orákulumszerződés az orákulumszolgáltatás láncon belüli összetevője. Figyeli a más szerződésektől érkező adatkéréseket, továbbítja az adatkéréseket az orákulum-csomópontoknak, és a visszaküldött adatokat továbbítja az kliensszerződéseknek. Ez a szerződés végezhet számításokat is a visszaküldött adatpontokon, hogy egy összesített értéket állítson elő, amelyet elküldhet az adatot kérő szerződésnek. + +Az orákulumszerződés tartalmaz néhány függvényt, amelyeket a kliensszerződések hívnak meg adatigényléskor. Egy új lekérdezés fogadásakor az okosszerződés egy [naplóeseményt](/developers/docs/smart-contracts/anatomy/#events-and-logs) bocsát ki az adatkérés részleteivel. Ez értesíti a naplóra feliratkozott, láncon kívüli csomópontokat (általában a JSON-RPC `eth_subscribe` parancsot használva), amelyek lekérdezik a naplóeseményben meghatározott adatokat. + +Az alábbiakban egy [orákulumszerződéses példa](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) olvasható Pedro Costától. Ez egy egyszerű orákulumszolgáltatás, amely más okosszerződések kérésére lekérdezheti a láncon kívüli API-okat, és a kért információt a blokkláncon tárolja: + +```solidity +pragma solidity >=0.4.21 <0.6.0; + +contract Oracle { + Request[] requests; //list of requests made to the contract + uint currentId = 0; //increasing request id + uint minQuorum = 2; //minimum number of responses to receive before declaring final result + uint totalOracleCount = 3; // Hardcoded oracle count + + // defines a general api request + struct Request { + uint id; //request id + string urlToQuery; //API url + string attributeToFetch; //json attribute (key) to retrieve in the response + string agreedValue; //value from key + mapping(uint => string) answers; //answers provided by the oracles + mapping(address => uint) quorum; //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted) + } + + //event that triggers oracle outside of the blockchain + event NewRequest ( + uint id, + string urlToQuery, + string attributeToFetch + ); + + //triggered when there's a consensus on the final result + event UpdatedRequest ( + uint id, + string urlToQuery, + string attributeToFetch, + string agreedValue + ); + + function createRequest ( + string memory _urlToQuery, + string memory _attributeToFetch + ) + public + { + uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, "")); + Request storage r = requests[length-1]; + + // Hardcoded oracles address + r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1; + r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1; + r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1; + + // launch an event to be detected by oracle outside of blockchain + emit NewRequest ( + currentId, + _urlToQuery, + _attributeToFetch + ); + + // increase request id + currentId++; + } + + //called by the oracle to record its answer + function updateRequest ( + uint _id, + string memory _valueRetrieved + ) public { + + Request storage currRequest = requests[_id]; + + //check if oracle is in the list of trusted oracles + //and if the oracle hasn't voted yet + if(currRequest.quorum[address(msg.sender)] == 1){ + + //marking that this address has voted + currRequest.quorum[msg.sender] = 2; + + //iterate through "array" of answers until a position if free and save the retrieved value + uint tmpI = 0; + bool found = false; + while(!found) { + //find first empty slot + if(bytes(currRequest.answers[tmpI]).length == 0){ + found = true; + currRequest.answers[tmpI] = _valueRetrieved; + } + tmpI++; + } + + uint currentQuorum = 0; + + //iterate through oracle list and check if enough oracles(minimum quorum) + //have voted the same answer as the current one + for(uint i = 0; i < totalOracleCount; i++){ + bytes memory a = bytes(currRequest.answers[i]); + bytes memory b = bytes(_valueRetrieved); + + if(keccak256(a) == keccak256(b)){ + currentQuorum++; + if(currentQuorum >= minQuorum){ + currRequest.agreedValue = _valueRetrieved; + emit UpdatedRequest ( + currRequest.id, + currRequest.urlToQuery, + currRequest.attributeToFetch, + currRequest.agreedValue + ); + } + } + } + } + } +} +``` + +### Orákulum-csomópontok {#oracle-nodes} + +Az orákulum-csomópont az orákulumszolgáltatás láncon kívüli összetevője. Információkat szerez külső forrásokból, például harmadik fél szerverein tárolt API-okból, és a láncon belülre helyezi, hogy az okosszerződések felhasználhassák azokat. Az orákulum-csomópontok figyelik a láncon belüli orákulumszerződés eseményeit, és folytatják a naplóban leírt feladat elvégzését. + +Az orákulum-csomópontok gyakori feladata, hogy [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) kérést küldjenek egy API-szolgáltatáshoz, elemezzék a választ a releváns adatok kinyeréséhez, formázzák az adatokat a blokklánc által olvasható kimenetté, és elküldjék a láncon belül egy tranzakcióba foglalva az orákulumszerződéshez. Az orákulum-csomópontnak a benyújtott információk érvényességét és sértetlenségét „hitelességi bizonyítékok” segítségével is igazolnia kell, amelyeket később vizsgálunk meg. + +A számítási orákulumok a láncon kívüli csomópontokra is támaszkodnak olyan számítási feladatok elvégzésében, amelyeket a láncon belül nem lenne célszerű végrehajtani, tekintettel a gázköltségekre és a blokkméretkorlátokra. Az orákulum-csomópont feladata lehet például egy ellenőrizhetően véletlenszerű szám előállítása (például blokkláncalapú játékok esetében). + +## Orákulumtervezési minták {#oracle-design-patterns} + +Az orákulumoknak több különböző típusa létezik, beleértve az _azonnali olvasás_, _közzététel-feliratkozás_ és _kérés-válasz_ típusokat, amelyek közül az utóbbi kettő a legnépszerűbb az Ethereum-okosszerződések körében. Röviden ismertetjük a közzététel-feliratkozás és kérés-válasz modelleket. + +### A közzététel-feliratkozás orákulumok {#publish-subscribe-oracles} + +Az ilyen típusú orákulum egy „adatfolyamot” tesz közzé, amelyet a szerződések rendszeresen olvashatnak információkért. Ebben az esetben az adatok várhatóan gyakran változnak, ezért a kliensszerződéseknek figyelniük kell az orákulum tárolójában lévő adatok frissítésére. Például az az orákulum, mely a legfrissebb ETH-USD árinformációkat szolgáltatja a felhasználóknak. + +### Kérés-válasz orákulumok {#request-response-oracles} + +A kérés-válasz beállítás lehetővé teszi a kliensszerződés számára, hogy a közzététel-feliratkozás típusú orákulum által biztosított adatoktól eltérő, tetszőleges adatokat kérjen. A kérés-válasz orákulumok ideálisak, ha az adathalmaz túl nagy ahhoz, hogy az okosszerződés tárhelyén tárolják, és/vagy a felhasználóknak az adatoknak csak egy kis részére van szükségük egy adott időpontban. + +Bár a közzététel-feliratkozás típusú modelleknél összetettebbek, a kérés-válasz orákulumok alapvetően az előző szakaszban leírtaknak felelnek meg. Az orákulumnak van egy láncon belüli komponense, amely fogad egy adatkérést, és továbbítja azt egy láncon kívüli csomópontnak feldolgozásra. + +Az adatlekérdezést kezdeményező felhasználóknak kell fedezniük a láncon kívüli forrásból származó információk költségeit. A kliensszerződésnek biztosítania kell a fedezetet arra a gázköltségre, amikor az orákulumszerződés a választ visszakapja a callback függvényen keresztül. + +## A centralizált és a decentralizált orákulumok összehasonlítása {#types-of-oracles} + +### Centralizált orákulumok {#centralized-oracles} + +A centralizált orákulumot egyetlen szervezet irányítja, amely a láncon kívüli információk összesítéséért és az orákulumszerződés adatainak kérés szerinti frissítéséért is felelős. A centralizált orákulumok hatékonyak, mivel csak egyetlen igazságforrásra támaszkodnak. Jobban működhetnek azokban az esetekben, amikor a védett adatkészleteket közvetlenül a tulajdonos teszi közzé egy elfogadott aláírással. Ugyanakkor hátrányaik is vannak: + +#### Alacsony helyességi garanciák {#low-correctness-guarantees} + +A centralizált orákulumok esetében nem lehet megerősíteni, hogy a megadott információ helyes-e vagy sem. Még a „jó hírű” szolgáltatók is tévedhetnek vagy feltörhetik őket. Ha az orákulum hibássá válik, az okosszerződések rossz adatok alapján kerülnek végrehajtásra. + +#### Alacsony szintű elérhetőség {#poor-availability} + +A centralizált orákulumok nem garantálják, hogy mindig elérhetővé teszik a láncon kívüli adatokat az okosszerződések számára. Ha a szolgáltató úgy dönt, hogy kikapcsolja a szolgáltatást, vagy egy hacker eltéríti az orákulum láncon kívüli komponensét, akkor a rá támaszkodó okosszerződést a szolgáltatásmegtagadás (DoS-támadás) kockázata fenyegeti. + +#### Gyenge ösztöntzőkompatibilitás {#poor-incentive-compatibility} + +A centralizált orákulumok gyakran rosszul megtervezett ösztönzőket adnak az adatszolgáltatóknak vagy nem adnak semmit azért, hogy azok pontos/helyes információkat küldjenek. Ha egy orákulumnak fizetünk a helyességért, az még nem garantálja azt. Ez a probléma annál nagyobb lesz, minél nagyobb az okosszerződések által kezelt érték. + +### Decentralizált orákulumok {#decentralized-oracles} + +A decentralizált orákulumok célja a centralizáltak korlátainak kiküszöbölése azáltal, hogy kizárjuk az egyetlen meghibásodási pont lehetőségét. A decentralizált orákulumszolgáltatás egy egyenrangú hálózat több résztvevőjéből áll, akik konszenzust alakítanak ki a láncon kívüli adatokról, mielőtt elküldenék azokat egy okosszerződésnek. + +Egy decentralizált orákulum (ideális esetben) engedély nélküli, bizalomigénytől mentes és nem kezeli azt egy központi fél; a valóságban a decentralizáció egy spektrumon mozog. Vannak félig decentralizált orákulumhálózatok, amelyekben bárki részt vehet, de van egy „tulajdonos”, aki a korábbi teljesítmény alapján jóváhagyja és eltávolítja a csomópontokat. Léteznek teljesen decentralizált orákulumhálózatok is: ezek általában önálló blokkláncokként működnek, és meghatározott konszenzusmechanizmusokkal rendelkeznek a csomópontok koordinálására és a helytelen viselkedés szankcionálására. + +A decentralizált orákulumok használata a következő előnyökkel jár: + +### Magas szintű helyességi garanciák {#high-correctness-guarantees} + +A decentralizált orákulumok különböző megközelítésekkel próbálják elérni az adatok helyességét. Ez magában foglalja a visszaküldött információk hitelességét és integritását igazoló bizonyítékok használatát, valamint több szervezetnek együttesen meg kell állapodnia a láncon kívüli adatok érvényességéről. + +#### Hitelességi igazolások {#authenticity-proofs} + +A hitelességi bizonyítékok olyan kriptográfiai mechanizmusok, amelyek lehetővé teszik a külső forrásból származó információk független ellenőrzését. Ezek a bizonyítékok hitelesíthetik az információ forrását, és felismerhetik azt, hogy módosították-e az adatokat a lekérdezés után. + +Példák a hitelességi igazolásokra: + +**Transport Layer Security (TLS) bizonyítékok**: Az orákulum-csomópontok gyakran kérnek le adatokat külső forrásokból a Transport Layer Security (TLS) protokollon alapuló biztonságos HTTP-kapcsolat segítségével. Egyes decentralizált orákulumok hitelességi igazolásokat alkalmaznak a TLS-munkamenetek ellenőrzésére (azaz egy csomópont és egy adott kiszolgáló közötti információcsere megerősítésére), és arra, hogy a munkamenet tartalmát nem módosították. + +**Trusted Execution Environment (TEE) tanúsítványok**: A [megbízható végrehajtási környezet](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) egy olyan sandbox számítási környezet, amely elszigetelten működik a gazdarendszer folyamataitól. A TEE-k biztosítják, hogy a számítási környezetben tárolt/használt alkalmazáskód vagy adat megőrzi integritását, bizalmas jellegét és megváltoztathatatlanságát. A felhasználók tanúsítást is létrehozhatnak annak igazolására, hogy egy alkalmazáspéldány a megbízható végrehajtási környezetben fut. + +A decentralizált orákulumok bizonyos osztályai megkövetelik, hogy az orákulum-csomópontok üzemeltetői TEE-tanúsítványokat adjanak. Ez megerősíti a felhasználó felé, hogy a csomópont üzemeltetője egy megbízható végrehajtási környezetben futtatja az orákulumkliens egy példányát. A TEE-k megakadályozzák, hogy külső folyamatok megváltoztassák vagy elolvassák az alkalmazás kódját és adatait, ezért ezek az igazolások bizonyítják, hogy az orákulum-csomópont sértetlenül és bizalmasan őrzi az információkat. + +#### Az információk konszenzusalapú validálása {#consensus-based-validation-of-information} + +A centralizált orákulumok az igazság egyetlen forrására támaszkodnak, amikor adatokat szolgáltatnak az okosszerződéseknek, ami magában hordozza a pontatlan információk közzétételének lehetőségét. A decentralizált orákulumok úgy oldják meg ezt a problémát, hogy több orákulum-csomópontra támaszkodva kérdezik le a láncon kívüli információkat. A több forrásból származó adatok összehasonlításával a decentralizált orákulumok csökkentik azt a kockázatot, hogy az érvénytelen információkat adnak a láncon belüli szerződéseknek. + +A decentralizált orákulumoknak azonban kezelniük kell a több, láncon kívüli forrásból származó információk közötti eltéréseket. Az információkülönbségek minimalizálása és annak biztosítása érdekében, hogy az orákulumszerződéshez továbbított adatok az orákulum-csomópontok kollektív véleményét tükrözzék, a decentralizált orákulumok a következő mechanizmusokat használják: + +##### Szavazás/letétadás az adatok pontossága érdekében + +Egyes decentralizált orákulumhálózatok megkövetelik, hogy a résztvevők szavazzanak vagy letétet helyezzenek az adatkérdésekre adott válaszok pontosságára (például „Ki nyerte a 2020-as amerikai választásokat?”) a hálózat natív tokenjét használva. Ezután egy aggregációs protokoll összesíti a szavazatokat és letéteket, és a többség által támogatott választ tekinti érvényesnek. + +Azokat a csomópontokat, amelyek válaszai eltérnek a többségi választól, úgy büntetik, hogy a tokenjeiket szétosztják azok között, amelyek többször adnak helyes értéket. Ha a csomópontoknak az adatszolgáltatás előtt kötelezvényt kell adniuk, akkor ez őszinte válaszadásra ösztönzi őket, mivel feltételezzük, hogy a racionális gazdasági szereplők hozammaximalizálásra törekszenek. + +A letét adás/szavazás megvédi a decentralizált orákulumokat a [Sybil-támadásoktól](/glossary/#sybil-attack) is, amikor a rosszindulatú szereplők több személyazonosságot hoznak létre, hogy kijátsszák a konszenzusrendszert. A letétadás azonban nem tudja megakadályozni az „ingyenélést” (az orákulum-csomópontok másolnak információt másoktól) és a „lusta validálást” (a többséget követik anélkül, hogy maguk ellenőriznék az információt). + +##### Schelling-pont mechanizmusok + +A [Schelling-pont](https://en.wikipedia.org/wiki/Focal_point_(game_theory)) egy játékelméleti fogalom, amely feltételezi, hogy több entitás mindig egy közös problémamegoldásra jut, ha nincs kommunikáció. A Schelling-pont mechanizmusokat gyakran használják a decentralizált orákulumhálózatokban, hogy a csomópontok konszenzusra jussanak az adatkérésekre adott válaszokkal kapcsolatban. + +Ennek egyik korai ötlete volt a [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/), egy olyan adatfolyam, ahol a résztvevők „skaláris” kérdésekre (melyek nagyságrendekre vonatkoznak, például „mennyi az ETH ára?”) adnak válaszokat, egy letéttel együtt. Azok a felhasználók, akik a 25. és 75. [percentilis](https://en.wikipedia.org/wiki/Percentile) közötti értékeket adnak, jutalomban részesülnek, akiknek az értékei nagymértékben eltérnek a mediánértéktől, büntetést kapnak. + +Bár SchellingCoin ma még nem létezik, számos decentralizált orákulum – nevezetesen a [Maker Protocol's Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module) – használja a schelling-pont mechanizmust az orákulumadatok pontosságának javítására. Minden Maker Oracle csomópont két komponensből áll: a csomópontok („közvetítők” és „ellátók/betáplálók”) láncon kívüli peer-to-peer (P2P) hálózatból, amelyek a biztosítéki eszközök piaci árait megadják, valamint egy láncon belüli „Medianizer” szerződésből, amely kiszámítja a megadott értékek mediánját. A megadott késleltetési időszak lejártával ez a mediánérték lesz a kapcsolódó eszköz új referenciaára. + +További példák a Schelling-pont mechanizmusokat használó orákulumokra: [Chainlink Off-Chain Reporting](https://docs.chain.link/docs/off-chain-reporting/) és [Witnet](https://witnet.io/). Mindkét rendszerben a peer-to-peer hálózat orákulum-csomópontjaitól érkező válaszokat egyetlen összesített értékké, például átlagértékké vagy mediánná aggregálják. A csomópontokat aszerint jutalmazzák vagy büntetik, hogy válaszaik milyen mértékben igazodnak az összesített értékhez vagy térnek el attól. + +A Schelling-pont mechanizmusok azért vonzók, mert minimalizálják a láncon belüli lábnyomot (egy tranzakció kell hozzá), miközben garantálják a decentralizációt. Ez utóbbi azért lehetséges, mert a csomópontoknak alá kell írniuk a benyújtott válaszok listáját, mielőtt az bekerül az átlag/középértéket előállító algoritmusba. + +### Elérhetőség {#availability} + +A decentralizált orákulumszolgáltatások képesek biztosítani az okosszerződéseknek a láncon kívüli adatok magas szintű elérhetőségét. Ehhez decentralizálni kell mind a láncon kívüli információk forrását, mind az információk láncon belüli továbbításáért felelős csomópontokat. + +Ez biztosítja a hibatűrést, mivel az orákulumszerződés több csomópontra támaszkodhat (amelyek több adatforrásra támaszkodnak) a szerződések lekérdezéseinek végrehajtásában. A decentralizáció a forrás _és_ a csomópontüzemeltető szintjén döntő fontosságú – az orákulum-csomópontok hálózata, mely azonos forrásra támaszkodik, ugyanabba a problémába ütközik, mint egy centralizált orákulum. + +A letétalapú orákulumoknál lehetséges súlyos büntetést (slashing) adni a csomópont-üzemeltetőknek, ha nem reagálnak gyorsan az adatkérésekre. Ez jelentősen ösztönzi az orákulum-csomópontokat arra, hogy hibatűrő infrastruktúrába fektessenek, és időben szolgáltassanak adatokat. + +### Jó ösztöntzőkompatibilitás {#good-incentive-compatibility} + +A decentralizált orákulumok különböző ösztönzőket alkalmaznak, hogy megakadályozzák a [bizánci](https://en.wikipedia.org/wiki/Byzantine_fault) viselkedést a orákulum-csomópontok között. Az ösztönzőkompatibilitás magában foglalja a _hozzárendelhetőséget_ és az _elszámoltathatóságot_: + +1. A decentralizált orákulum-csomópontoknak gyakran alá kell írniuk az adatkérésekre adott adatokat. Ez az információ segít az orákulum-csomópontok teljesítményének értékelésében, így a felhasználók adatigényléskor kiszűrhetik a megbízhatatlan szereplőket. Ilyen például a Witnet [Algoritmikus reputációs rendszere (Algorithmic Reputation System)](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system). + +2. A decentralizált orákulumok megkövetelhetik a csomópontoktól, hogy az általuk benyújtott adatok helyességét letéttel is alátámasszák. Ha az adatszolgáltatás helyes, ez a letét a szolgálatért járó jutalmakkal együtt visszatérül. De büntetésképpen slashelhető is, ha az információ téves, ami bizonyos fokú elszámoltathatóságot biztosít. + +## Orákulumok alkalmazása az okosszerződésekben {#applications-of-oracles-in-smart-contracts} + +Az Ethereumon használt orákulumok gyakori felhasználási esetei a következők: + +### Pénzügyi adatok lekérdezése {#retrieving-financial-data} + +A [decentralizált pénzügyi](/defi/) (DeFi) alkalmazások lehetővé teszik a peer-to-peer hitelezést, kölcsönzést és az eszközök kereskedelmét. Ehhez gyakran különböző pénzügyi információk beszerzésére van szükség, beleértve az árfolyamadatokat (a kriptovaluták fiat-értékének kiszámításához vagy a tokenárak összehasonlításához) és a tőkepiaci adatokat (a tokenizált eszközök, például az arany vagy az amerikai dollár értékének kiszámításához). + +Egy DeFi kölcsönzési protokollnak például le kell kérdeznie a biztosítékként letétbe helyezett eszközök (például az ETH) aktuális piaci árait. Ez lehetővé teszi, hogy a szerződés meghatározza a fedezeti eszközök értékét, és ezáltal a felvehető kölcsön értékét is. + +A DeFi népszerű „ár-orákulumjai” közé tartozik a Chainlink Price Feeds, a Compound Protocol [Open Price Feed](https://compound.finance/docs/prices), az Uniswap [Time-Weighted Average Prices (TWAPs)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) és a [Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module). + +Az építőknek meg kell érteniük az ezekkel az ár-orákulumokkal járó fenntartásokat, mielőtt beépítenék őket a projektjükbe. Ez a [cikk](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) részletes elemzést nyújt arról, hogy mit kell figyelembe venni, ha az említett ár-orákulumok bármelyikét használni szeretnénk. + +Következzen egy példa arra, hogyan lehet lekérdezni a legfrissebb ETH árat az okosszerződésben a Chainlink árakra vonatkozó adatfolyamával: + +```solidity +pragma solidity ^0.6.7; + +import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol"; + +contract PriceConsumerV3 { + + AggregatorV3Interface internal priceFeed; + + /** + * Network: Kovan + * Aggregator: ETH/USD + * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331 + */ + constructor() public { + priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331); + } + + /** + * Returns the latest price + */ + function getLatestPrice() public view returns (int) { + ( + uint80 roundID, + int price, + uint startedAt, + uint timeStamp, + uint80 answeredInRound + ) = priceFeed.latestRoundData(); + return price; + } +} +``` + +### Ellenőrizhető véletlenszerűség generálása {#generating-verifiable-randomness} + +Bizonyos blokklánc-alkalmazások, mint például a játékok vagy a lottórendszerek, nagyfokú kiszámíthatatlanságot és véletlenszerűséget igényelnek a hatékony működéshez. A blokkláncok determinisztikus végrehajtása azonban kiküszöböli a véletlenszerűséget. + +Az eredeti megközelítés az álvéletlenszerű kriptográfiai függvények használata volt, mint például a `blockhash`, de ezeket [manipulálhatták a bányászok](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) a proof-of-work algoritmust megoldva. Továbbá, az Ethereum [proof-of-stake mechanizmusra való átváltása](/roadmap/merge/) azt jelenti, hogy a fejlesztők többé nem támaszkodhatnak a `blockhash`-re a láncon belüli véletlenszerűség tekintetében. A Beacon-lánc [RANDAO mechanizmusa](https://eth2book.info/altair/part2/building_blocks/randomness) azonban alternatív véletlenszerűségi forrást biztosít. + +Lehetséges a véletlen értéket a láncon kívül generálni és a láncon belül elküldeni, de ez nagy bizalmi követelményeket támaszt a felhasználókkal szemben. Azt kell hinniük, hogy az érték valóban kiszámíthatatlan mechanizmusok révén jött létre, és nem változott meg az átadás során. + +A láncon kívüli számításhoz tervezett orákulumok úgy oldják meg ezt a problémát, hogy biztonságosan generálnak véletlenszerű eredményeket, amelyeket a folyamat kiszámíthatatlanságát igazoló kriptográfiai bizonyítékokkal együtt továbbítanak a láncon belülre. Ilyen például a [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (Igazolható véletlenfüggvény/Verifiable Random Function), amely egy bizonyíthatóan igazságos és hamisításbiztos véletlenszám-generátor (RNG), hogy a kiszámíthatatlan eredményekre támaszkodó alkalmazásokhoz megbízható okosszerződéseket lehessen létrehozni. Egy másik példa az [API3 QRNG](https://docs.api3.org/explore/qrng/), amely a kvantum véletlenszám-generálást (QRNG) szolgálja ki, egy kvantumjelenségeken alapuló, Web3 RNG nyilvános módszert, amelyet az Ausztrál Nemzeti Egyetem (ANU) által elérhető. + +### Az események eredményeinek elérése {#getting-outcomes-for-events} + +Az orákulumok segítségével könnyű olyan okosszerződéseket létrehozni, amelyek valós eseményekre reagálnak. Az orákulumszolgáltatások ezt azáltal teszik lehetővé, hogy a szerződések külső API-okhoz kapcsolódhatnak a láncon kívüli komponenseken keresztül, és információkat vehetnek ezekből az adatforrásokból. Például a korábban említett előrejelző alkalmazás kérhet egy orákulumot, hogy küldje vissza a választási eredményeket egy megbízható, láncon kívüli forrásból (például az Associated Presstől). + +Az orákulumok valós adatok lekérdezésére való használata újszerű felhasználási területeket tesz lehetővé; például egy decentralizált biztosítási terméknek pontos információkra van szüksége az időjárásról, katasztrófákról stb. a hatékony működéshez. + +### Okosszerződések automatizálása {#automating-smart-contracts} + +Az okosszerződések nem futnak automatikusan, hanem egy externally owned account (EOA), azaz külső tulajdonú számlának vagy egy másik szerződéses számlának kell elindítania a funkciókat a szerződéskód végrehajtásához. A legtöbb esetben a szerződésfunkciók nagy része nyilvános, és az EOA-k és más szerződések által meghívhatók. + +De vannak olyan _privát funkciók_ is egy szerződésen belül, amelyek mások számára elérhetetlenek, de kritikusak a dapp általános funkcionalitása szempontjából. Ilyen lehet például egy `mintERC721Token()` függvény, amely rendszeresen új NFT-ket készít a felhasználók számára, egy függvény a kifizetések odaítélésére egy előrejelzési piacon, vagy egy függvény a feltett tokenek feloldására egy DEX-en. + +A fejlesztőknek időközönként ilyen funkciókat kell indítaniuk, hogy az alkalmazás zökkenőmentesen működjön. Ez azonban azt eredményezheti, hogy a fejlesztők több órát veszítenek a hétköznapi feladatokkal, ezért fontos az okosszerződések végrehajtásának automatizálása. + +Egyes decentralizált orákulumhálózatok automatizálási szolgáltatásokat kínálnak, amelyek lehetővé teszik a láncon kívüli orákulum-csomópontok számára, hogy a felhasználó által meghatározott paraméterek alapján okosszerződés-funkciókat indítsanak el. Ehhez általában „regisztrálni” kell a célszerződést az orákulumszolgáltatásnál, pénzeszközöket kell biztosítani az orákulumüzemeltető kifizetéséhez, és meg kell határozni a szerződést kiváltó feltételeket vagy időpontokat. + +A Chainlink [Keeper Network](https://chain.link/keepers) lehetőséget biztosít az okosszerződések számára a rendszeres karbantartási feladatok minimális bizalomigényű és decentralizált módon történő kiszervezésére. Tekintse meg a hivatalos [Keeper-dokumentációt](https://docs.chain.link/docs/chainlink-keepers/introduction/) a szerződés Keeper-kompatibilissé tételével és az Upkeep-szolgáltatással kapcsolatos információkért. + +## Hogyan használjuk a blokkláncorákulumokat {#use-blockchain-oracles} + +Többféle orákulumalkalmazást is integrálhat az Ethereum dappba: + +**[Chainlink](https://chain.link/)** – _A Chainlink decentralizált orákulumhálózatok hamisításbiztos bemeneteket, kimeneteket és számításokat biztosítanak a fejlett okosszerződések támogatásához bármely blokkláncon._ + +**[Chronicle](https://chroniclelabs.org/)** - _A Chronicle megoldja a láncon belüli adatátvitel jelenlegi korlátait azáltal, hogy valóban skálázható, költséghatékony, decentralizált és ellenőrizhető orákulumokat készít._ + +**[Witnet](https://witnet.io/)** – _A Witnet egy engedély nélküli, decentralizált és cenzúrának ellenálló orákulum, amely segíti az okosszerződéseket, hogy erős kriptogazdasági garanciákkal reagáljanak a valós világ eseményeire._ + +**[UMA Oracle](https://uma.xyz)** – _Az UMA optimista orákulum lehetővé teszi, hogy az okosszerződések gyorsan, mindenféle adatot megkapjanak különböző alkalmazásokhoz, beleértve a biztosítási, pénzügyi derivatívákat és előrejelzési piacokat._ + +**[Tellor](https://tellor.io/)** – _A Tellor egy átlátható és engedély nélküli orákulumprotokoll az okosszerződések számára, hogy könnyedén hozzájusson bármilyen adathoz, amikor csak szükség van rá._ + +**[Band Protocol](https://bandprotocol.com/)** – _A Band Protocol egy láncokon átívelő adatorákulum-platform, amely valós adatokat és API-okat aggregál és kapcsol össze okosszerződésekkel._ + +**[Paralink](https://paralink.network/)** – _A Paralink nyílt forráskódú és decentralizált orákulumplatformot biztosít az Ethereumon és más népszerű blokkláncokon futó okosszerződésekhez._ + +**[Pyth Network](https://pyth.network/)** – _A Pyth hálózat egy olyan pénzügyi orákulumhálózat, amely első kézből szerez információt, és folyamatosan valós adatokat tesz közzé a láncon belül egy hamisításnak ellenálló, decentralizált és önfenntartó környezetben._ + +**[API3 DAO](https://www.api3.org/)** – _Az API3 DAO olyan, első féltől származó orákulummegoldásokat kínál, amelyek nagyobb forrásátláthatóságot, biztonságot és skálázhatóságot biztosítanak egy decentralizált megoldásában az okosszerződések számára._ + +**[Supra](https://supra.com/)** - Egy vertikálisan integrált eszközrendszer a láncok közötti megoldások számára, amely összekapcsolja az összes blokkláncot, legyen az publikus (L1-ek és L2-k) vagy privát (vállalati), decentralizáltorákulum-árfolyamadatokat biztosítva, melyet láncon belüli és kívüli projektek is használhatnak. + +## További olvasnivaló {#further-reading} + +**Cikkek** + +- [Mi az a blokkláncorákulum?](https://chain.link/education/blockchain-oracles) – _Chainlink_ +- [Mi az a blokkláncorákulum?](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) – _Patrick Collins_ +- [Decentralizált orákulumok: részletes áttekintés](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) – _Julien Thevenard_ +- [Blokkláncorákulum bevezetése az Ethereumon](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_ +- [Az okosszerződések miért nem tudnak API-hívásokat kezdeményezni?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) – _StackExchange_ +- [Miért van szükség decentralizált orákulumokra](https://newsletter.banklesshq.com/p/why-we-need-decentralized-oracles) – _Bankless_ +- [Tehát Ön egy ár-orákulumot szeretne használni](https://samczsun.com/so-you-want-to-use-a-price-oracle/) – _samczsun_ + +**Videók** + +- [Orákulumok és a blokklánc-használat kiterjesztése](https://youtu.be/BVUZpWa8vpw) – _Real Vision Finance_ +- [A különbség az orákulumok között az első kézből vagy harmadik féltől szerezett adatok tekintetében](https://blockchainoraclesummit.io/first-party-vs-third-party-oracles/) – _Blockchain Oracle Summit_ + +**Oktatóanyagok** + +- [Hogyan lehet lekérni az Ethereum aktuális árát a Solidityben?](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) – _Chainlink_ +- [Orákulumadat felhasználása](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_ + +**Példaprojektek** + +- [Teljes Chainlink kezdőprojekt az Ethereumra Solidity nyelven](https://github.com/hackbg/chainlink-fullstack) – _HackBG_ diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/index.md new file mode 100644 index 00000000000..b98e7822867 --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/index.md @@ -0,0 +1,59 @@ +--- +title: Ethereum fejlesztési szabványok +description: +lang: hu +incomplete: true +--- + +## Szabványok áttekintése {#standards-overview} + +Az Ethereum közösség sok szabványt vezetett be, hogy a projektek (mint az [Ethereum kliensek](/developers/docs/nodes-and-clients/) és tárcák) interoperábilisek maradjanak különböző megvalósításokban, és biztosítsák, hogy az okosszerződések és a dappok összeilleszthetőek maradnak. + +Általában a szabványok [Ethereum-fejlesztési javaslatokként](/eips/) (EIP) kerülnek bevezetésre, melyeket a közösség tagjai vitatnak meg egy [sztenderd folyamat](https://eips.ethereum.org/EIPS/eip-1) során. + +- [Bevezetés az EIP-kbe](/eips/) +- [EIP-k listája](https://eips.ethereum.org/) +- [EIP GitHub mappa](https://github.com/ethereum/EIPs) +- [EIP vitafórum](https://ethereum-magicians.org/c/eips) +- [Bevezetés az Ethereum irányításába](/governance/) +- [Az Ethereum irányításának áttekintése](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _2019. március 31., Boris Mann_ +- [Ethereum protokollfejlesztés-irányítás és hálózatfrissítés-koordináció](https://hudsonjameson.com/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _2020. március 23., Hudson Jameson_ +- [Lejátszási lista az Ethereum protokollfejlesztőinek megbeszéléseiről](https://www.youtube.com/@EthereumProtocol) _(YouTube lejátszási lista)_ + +## Szabványtípusok {#types-of-standards} + +Az EIP-k 3 típusa: + +- Szabványok listája: minden olyan változást leír, amely a legtöbb vagy az összes Ethereum-implementációt érinti +- [Meta lista](https://eips.ethereum.org/meta): egy Ethereumhoz kapcsolódó folyamat leírása, vagy javaslat egy folyamat megváltoztatására +- [Információs lista](https://eips.ethereum.org/informational): egy Ethereum-tervezési problémát ír le, vagy általános iránymutatásokat nyújt az Ethereum közössége számára + +A szabványok listáját 4 kategóriára lehet felosztani: + +- [Központi](https://eips.ethereum.org/core): konszenzuselágazást igénylő fejlesztések +- [Hálózat](https://eips.ethereum.org/networking): fejlesztések a devp2p és a Light Ethereum alprotokoll körül, valamint javasolt fejlesztések a whisper és a swarm hálózati protokollspecifikációkhoz. +- [Interfész](https://eips.ethereum.org/interface): fejlesztések az ügyfél API/RPC specifikációk és szabványok, valamint bizonyos nyelvi szintű szabványok, például a metódusnevek és a szerződés ABI-k körül. +- [ERC](https://eips.ethereum.org/erc): alkalmazási szintű szabványok és konvenciók + +A különböző típusokról és kategóriákról részletesebb információ az [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) dokumentumban található + +### Token szabványok {#token-standards} + +- [ERC-20](/developers/docs/standards/tokens/erc-20/) – Egy sztenderd interfész a helyettesíthető (cserélhető) tokenekhez, például a szavazási és letéti tokenekhez vagy a virtuális valutákhoz. + - [ERC-223](/developers/docs/standards/tokens/erc-223/) - Egy helyettesíthető tokenszabvány, melynek révén a tokenek az etherrel azonosan működnek, és támogatja a tokenküldés kezelését a fogadó oldalán. + - [ERC-1363](https://eips.ethereum.org/EIPS/eip-1363) – Egy tokeninterfészt határoz meg az ERC-20 tokenek számára, amely támogatja a címzett kód végrehajtását a transfer vagy transferFrom után, illetve a feladó kódját a jóváhagyás után. +- [ERC-721](/developers/docs/standards/tokens/erc-721/) – Egy sztenderd interfész a nem helyettesíthető tokenekhez, például egy műalkotásról szóló okirathoz vagy egy dalhoz. + - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) – Egy szabványosított esemény, amelyet egy vagy több, egymást követő tokenazonosítókat használó, nem helyettesítő token létrehozásakor/átadásakor bocsátanak ki. + - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) – Az EIP-721 fogyasztói szerepkör interfészbővítése. + - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) – Korlátozott jogosultságú, időben korlátozott szerepkör hozzáadása az ERC-721 tokenekhez. +- [ERC-777](/developers/docs/standards/tokens/erc-777/) – **(NEM AJÁNLOTT)** Az ERC-20-hoz képest továbbfejlesztett tokenszabvány. +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) – Olyan tokenszabvány, amely egyaránt tartalmazhat helyettesíthető és nem helyettesíthető eszközöket. +- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) – A tokenizált trezorok technikai paramétereinek optimalizálására és egységesítésére tervezett tokenizált trezorszabvány. + +Tudjon meg többet a [tokenszabványokról](/developers/docs/standards/tokens/). + +## További olvasnivaló {#further-reading} + +- [Ethereum Fejlesztési Javaslatok (EIP-k)](/eips/) + +_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md new file mode 100644 index 00000000000..68404126db9 --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md @@ -0,0 +1,146 @@ +--- +title: ERC-1155 Multitoken szabvány +description: +lang: hu +--- + +## Bevezetés {#introduction} + +Egy sztenderd interfész olyan szerződésekhez, amelyek többféle tokentípust kezelnek. Egy telepített szerződés tartalmazhatja helyettesíthető és nem helyettesíthető tokenek vagy más konfigurációk (például félig helyettesíthető tokenek) bármilyen kombinációját. + +**Mit jelent a multitoken szabvány?** + +Az ötlet egyszerű, és egy olyan okosszerződéses interfész létrehozására irányul, amely bármilyen számú helyettesíthető és nem helyettesíthető tokentípust képes reprezentálni és irányítani. Ily módon az ERC-1155 token ugyanazokat a funkciókat tudja ellátni, mint egy [ERC-20](/developers/docs/standards/tokens/erc-20/) és [ERC-721](/developers/docs/standards/tokens/erc-721/) token, sőt mindkettő egyszerre. Javítja az ERC-20 és ERC-721 szabványok működését, hatékonyabbá teszi és kijavítja a nyilvánvaló végrehajtási hibákat. + +Az ERC-1155 token teljes körű leírását az [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155) tartalmazza. + +## Előfeltételek {#prerequisites} + +Az oldal jobb megértéséhez javasoljuk, hogy először olvassa el a [tokenszabványok](/developers/docs/standards/tokens/), [ERC-20](/developers/docs/standards/tokens/erc-20/) és [ERC-721](/developers/docs/standards/tokens/erc-721/) nevű dokumentumokat. + +## ERC-1155 funkciók és jellemzők: {#body} + +- [Csoportos transzfer](#batch_transfers): Több eszköz átvitele egyetlen hívással. +- [Csoportos egyenleglehívás](#batch_balance): Több eszköz egyenlegének lekérdezése egyetlen hívással. +- [Csoportos jóváhagyás](#batch_approval): Az összes token jóváhagyása egy címre. +- [Hook-ok](#receive_hook): Token-hook-ok fogadása. +- [NFT támogatás](#nft_support): Ha a kínálat csak 1, kezelje NFT-ként. +- [Biztonságos átviteli szabályok](#safe_transfer_rule): Szabályok a biztonságos átvitelre. + +### Csoportos transzferek {#batch-transfers} + +A csoportos transzfer nagyon hasonlóan működik, mint a hagyományos ERC-20-transzfer. Nézzük meg a normál ERC-20 `transferFrom` funkciót: + +```solidity +// ERC-20 +function transferFrom(address from, address to, uint256 value) external returns (bool); + +// ERC-1155 +function safeBatchTransferFrom( + address _from, + address _to, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external; +``` + +Az egyetlen különbség az ERC-1155-ben az, hogy az értékeket tömbként adjuk át, és az azonosítók tömbjét is átadjuk. Például `ids=[3, 6, 13]` és `values=[100, 200, 5]` esetén a kapott átutalások a következők lesznek: + +1. 100 darab 3-as azonosítójú token átvitele `_from` helyről `_to` helyre. +2. 200 darab 6-os azonosítójú token átvitele `_from` helyről `_to` helyre. +3. 5 darab 13-as azonosítójú token átvitele `_from` helyről `_to` helyre. + +Az ERC-1155-ben csak `transferFrom` van, `transfer` nincs. Ha normál `transfer` módjára akarja használni, csak állítsa be a „from” címet a függvényt hívó címre. + +### Csoportos egyenleglehívás {#batch-balance} + +A megfelelő ERC-20 `balanceOf` hívás szintén rendelkezik csoportos támogatású partnerfunkcióval. Emlékeztetőül, ez az ERC-20-as verzió: + +```solidity +// ERC-20 +function balanceOf(address owner) external view returns (uint256); + +// ERC-1155 +function balanceOfBatch( + address[] calldata _owners, + uint256[] calldata _ids +) external view returns (uint256[] memory); +``` + +Még egyszerűbb az egyenleghívásnál, hogy egyetlen hívással több egyenleget is lekérdezhetünk. Átadjuk a tulajdonosok tömbjét, majd a tokenazonosítók tömbjét. + +Ha például `_ids=[3, 6, 13]` és `_owners=[0xbeef..., 0x1337..., 0x1111...]`, a visszatérési érték a következő lesz: + +```solidity +[ + balanceOf(0xbeef...), + balanceOf(0x1337...), + balanceOf(0x1111...) +] +``` + +### Csoportos jóváhagyás {#batch-approval} + +```solidity +// ERC-1155 +function setApprovalForAll( + address _operator, + bool _approved +) external; + +function isApprovedForAll( + address _owner, + address _operator +) external view returns (bool); +``` + +A jóváhagyások némileg eltérnek az ERC-20-tól. Konkrét összegek jóváhagyása helyett a `setApprovalForAll` segítségével állíthat be egy jóváhagyási vagy nem jóváhagyási műveletet. + +Az aktuális státusz leolvasása az `isApprovedForAll` segítségével történhet. Amint látja, ez egy mindent vagy semmit művelet. Nem határozhatja meg, hogy hány tokent hagyjon jóvá, és azt sem, hogy melyik tokenosztályt hagyja jóvá. + +Ezt szándékosan az egyszerűség jegyében tervezték. Egy címre vonatkozóan hagyhat jóvá mindent. + +### Hook fogadása {#receive-hook} + +```solidity +function onERC1155BatchReceived( + address _operator, + address _from, + uint256[] calldata _ids, + uint256[] calldata _values, + bytes calldata _data +) external returns(bytes4); +``` + +Tekintettel az [EIP-165](https://eips.ethereum.org/EIPS/eip-165) támogatásra, az ERC-1155 csak az okosszerződésekre vonatkozó hook-okat fogadja. A hook-függvénynek egy mágikus, előre definiált bytes4-értéket kell visszaadnia, amely a következő formában van megadva: + +```solidity +bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) +``` + +Ha a fogadó szerződés visszaküldi ezt az értéket, akkor feltételezzük, hogy a szerződés elfogadja az átutalást, és tudja, hogyan kell kezelni az ERC-1155 tokeneket. Remek, nincs többé szerződésbe ragadt token! + +### NFT-támogatás {#nft-support} + +Ha a kínálat csak egy darab, akkor a token lényegében egy nem helyettesíthető token (NFT). Az ERC-721 szabványának megfelelően meghatározhat egy metaadat URL-címet is. Az ügyfelek képesek az URL-t olvasni és módosítani, ennek módját [itt](https://eips.ethereum.org/EIPS/eip-1155#metadata) tekintheti meg. + +### Biztonságos átutalási szabály {#safe-transfer-rule} + +Az előző magyarázatokban már érintettünk néhány biztonságos átutalási szabályt. De nézzük a szabályok közül a legfontosabbat: + +1. A hívónak engedélyeznie kell a `_from` címre vonatkozó tokenek elköltését, vagy a hívónak meg kell egyeznie a `_from` címmel. +2. Az átutalási hívásnak vissza kell fordulnia, ha + 1. a `_to` címe 0. + 2. az `_ids` hossza nem azonos a `_values` hosszával. + 3. az `_ids` paraméterben szereplő token(ek) birtokosának bármelyik egyenlege alacsonyabb, mint a `_values` paraméterben szereplő, a címzettnek küldött megfelelő összeg(ek). + 4. bármilyen más hiba előfordul. + +_Megjegyzés_: Minden csoportos funkció, beleértve a hook-ot is, egyéni változatban is létezik. Ez a gázhatékonyság érdekében történik, tekintve, hogy valószínűleg csak egy eszköz átadása lesz a leggyakrabban használt módszer. Ezeket az egyszerűség kedvéért kihagytuk a magyarázatokból, beleértve a biztonságos átutalási szabályokat is. A nevek megegyeznek, csak a „Batch” szót kell eltávolítani. + +## További olvasnivaló {#further-reading} + +- [ERC-1155: Multitoken szabvány](https://eips.ethereum.org/EIPS/eip-1155) +- [ERC-1155: Openzeppelin-dokumentációk](https://docs.openzeppelin.com/contracts/3.x/erc1155) +- [ERC-1155: GitHub mappa](https://github.com/enjin/erc-1155) +- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md new file mode 100644 index 00000000000..6f2bec84ebe --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md @@ -0,0 +1,172 @@ +--- +title: ERC-20 Tokenszabvány +description: +lang: hu +--- + +## Bevezetés {#introduction} + +**Mi is az a token?** + +A tokenek gyakorlatilag bármit képviselhetnek az Ethereumon: + +- reputációs pontokat egy online platformon +- egy karakter képességeit egy játékban +- pénzügyi eszközöket, mint például részesedést egy cégben +- fiat valutát, mint az USD +- egy uncia aranyat +- és még sok mást... + +Egy ilyen erős Ethereum funkciót egy szintén erős szabványnak kell kezelnie, igaz? És pontosan itt jön képbe az ERC-20 szerepe! Ez a szabvány lehetővé teszi a fejlesztők számára, hogy olyan tokenalkalmazásokat fejlesszenek, amelyek együttműködnek más termékekkel és szolgáltatásokkal. Az ERC-20 szabványt arra is használják, hogy további funkciókat biztosítsanak az [ether](/glossary/#ether) számára. + +**Mi az az ERC-20?** + +Az ERC-20 bevezeti a helyettesíthető tokenekre vonatkozó szabványt, vagyis minden egyes token pontosan ugyanaz (típusban és értékben), mint egy másik. Például egy ERC-20 token úgy viselkedik, mint az ETH, vagyis 1 token egyenlő és egyenlő is marad az összes többi tokennel. + +## Előfeltételek {#prerequisites} + +- [Számlák](/developers/docs/accounts) +- [Okosszerződések](/developers/docs/smart-contracts/) +- [Token szabványok](/developers/docs/standards/tokens/) + +## Törzs {#body} + +Az ERC-20 (Ethereum Request for Comments 20), melyet Fabian Vogelsteller javasolt 2015. novemberében, egy tokenszabvány, mely egy API-t implementál a tokenek számára az okosszerződéseken belül. + +Az ERC-20 által biztosított funkciók például: + +- tokenek átutalása egyik számláról a másikra +- egy számla aktuális tokenegyenlegének lekérdezése +- a hálózaton rendelkezésre álló tokenek teljes készlete +- jóváhagyja, hogy egy számláról származó token összegét elköltheti-e egy másik számla + +Ha egy okosszerződés implementálja a következő metódusokat és eseményeket, akkor egy ERC-20 tokenszerződésnek lehet nevezni, és a telepítés után a létrejött tokenek számontartásáért lesz felelős az Ethereumon. + +Az [EIP-20-ból](https://eips.ethereum.org/EIPS/eip-20): + +### Metódusok {#methods} + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) +function approve(address _spender, uint256 _value) public returns (bool success) +function allowance(address _owner, address _spender) public view returns (uint256 remaining) +``` + +### Események {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value) +event Approval(address indexed _owner, address indexed _spender, uint256 _value) +``` + +### Példák {#web3py-example} + +Nézzük meg, miért olyan fontos egy szabvány, hogy egyszerűbbé tegye számunkra azt, hogy bármely ERC-20 tokenszerződést megtekinthessük az Ethereumon. Csak a szerződés Alkalmazás bináris interfészére (ABI) lesz szükség, hogy egy felületet készítsünk bármely ERC-20 tokennek. Ahogy lentebb láthatja, egy egyszerűsített ABI-t használunk, hogy egyszerűbb példával éljünk. + +#### Web3.py példa {#web3py-example} + +Először győződjön meg arról, hogy a [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python könyvtár telepítve van: + +``` +pip install web3 +``` + +```python +from web3 import Web3 + + +w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) + +dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI +weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH) + +acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2 + +# Ez egy ERC-20 token szerződés egyszerűsített Application Binary Interface-e (ABI). +# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply() +simplified_abi = [ + { + 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}], + 'name': 'balanceOf', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'decimals', + 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'symbol', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'totalSupply', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + } +] + +dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi) +symbol = dai_contract.functions.symbol().call() +decimals = dai_contract.functions.decimals().call() +totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals +addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# DAI +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) + +weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi) +symbol = weth_contract.functions.symbol().call() +decimals = weth_contract.functions.decimals().call() +totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals +addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals + +# WETH +print("===== %s =====" % symbol) +print("Total Supply:", totalSupply) +print("Addr Balance:", addr_balance) +``` + +## Ismert problémák {#erc20-issues} + +### ERC-20-token-elfogadási problémák {#reception-issue} + +Amikor ERC-20 tokeneket küldenek olyan okosszerződésbe, amely nem tudja azokat kezelni, akkor ezek végleg elvesznek. Ennek az az oka, hogy a befogadó szerződésnek nincs olyan funkcionalitása, hogy felismerje vagy válaszoljon a bejövő tokenekre, és nincs olyan mechanizmus az ERC-20-szabványban, ami figyelmeztetné a szerződést az érkező tokenekről. Ez a probléma a következő módokon nyilvánul meg: + +1. Tokenátviteli mechanizmus + - Az ERC-20 tokeneket a transfer vagy a transferFrom függvényekkel lehet küldeni + - Amikor a felhasználó tokeneket küld egy szerződéscímre ezekkel a függvényekkel, a tokenek elmennek attól függetlenül, hogy a szerződés képes-e azokat fogadni +2. A figyelmeztetés hiánya + - A befogadó szerződés nem kap figyelmeztetést vagy visszahívást, hogy tokenek érkeztek hozzá + - Ha a befogadó szerződés nem tud tokeneket kezelni (például nincs egy fallback függvény vagy egy dedikált függvény, ami a tokent fogadná), akkor a tokenek beragadnak a szerződés címén +3. Nincs beépített kezelés + - Az ERC-20 szabvány nem köti ki a kötelező funkciót a befogadó szerződésnek, ezért számos szerződés képtelen a beérkező tokenek megfelelő kezelésére + +Néhány alternatív szabvány létezik ennek a problémának a kezelésére, mint az [ERC-223](/developers/docs/standards/tokens/erc-223) + +## További olvasnivaló {#further-reading} + +- [EIP-20: ERC-20 tokenszabvány](https://eips.ethereum.org/EIPS/eip-20) +- [OpenZeppelin – Tokenek](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) +- [OpenZeppelin – ERC-20-implementáció](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) +- [Alchemy – Útmutató a Solidity ERC-20 tokenekhez](https://www.alchemy.com/overviews/erc20-solidity) + + +## További helyettesíthető tokenekről szóló szabványok {#fungible-token-standards} + +- [ERC-223](/developers/docs/standards/tokens/erc-223) +- [ERC-777](/developers/docs/standards/tokens/erc-777) +- [ERC-4626 - Tokenizált értékmegőrzőre vonatkozó szabvány](/developers/docs/standards/tokens/erc-4626) \ No newline at end of file diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md new file mode 100644 index 00000000000..a779631bcb6 --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md @@ -0,0 +1,197 @@ +--- +title: ERC-223 tokenszabvány +description: Az ERC-223 helyettesíthető tokenszabvány áttekintése, működése és az ERC-20-szal való összevetése. +lang: hu +--- + +## Bevezetés {#introduction} + +### Mi az az ERC-223? {#what-is-erc223} + +ERC-223 a helyettesíthető tokenek szabványa, amely hasonlít az ERC-20-hoz. A fő különbség az, hogy az ERC-223 nemcsak a token API-t adja meg, hanem a küldési logikát is a küldő és a fogadó között. Egy kommunikációs modellt vezet be, amely alapján a fogadó képes kezelni a token fogadását. + +### Eltérések az ERC-20-hoz képest {#erc20-differences} + +Az ERC-223 kezeli az ERC-20 néhány korlátját, és egy új interakciós módszert vezet be a tokenszerződés és a tokent befogadó szerződés között. Néhány dolog lehetséges az ERC-223-mal, de az ERC-20-szal nem: + +- A tokenküldés kezelése a fogadó oldalán: a fogadó fél képes követni, hogy egy ERC-223-as token érkezett. +- A helytelenül küldött tokenek elutasítása: ha a felhasználó ERC-223-as tokent küld egy szerződésnek, amely nem fogad tokeneket, akkor el tudja utasítani azt, így nem veszik el. +- Metaadatok a küldés során: az ERC-223 token metaadatokat is tartalmaz, így bármilyen információt át lehet adni a tokenküldésnél. + +## Előfeltételek {#prerequisites} + +- [Számlák](/developers/docs/accounts) +- [Okosszerződések](/developers/docs/smart-contracts/) +- [Tokenszabványok](/developers/docs/standards/tokens/) +- [ERC-20](/developers/docs/standards/tokens/erc-20/) + +## Törzs {#body} + +Az ERC-223 egy tokenszabvány, ami API-t implementál a tokeneknek az okosszerződésekben. Emellett API-t határoz meg azoknak a szerződéseknek, melyek ERC-223 tokent fogadnak be. Azok a szerződések, amelyek nem támogatják az ERC-223-at befogadó API-t, nem fogadhatnak ilyen tokent, így megakadályozzák a hibát. + +Ha az okosszerződés implementálja a következő metódusokat és eseményeket, akkor egy ERC-223-kompatibilis tokenszerződésnek nevezhető. Amint telepítve van, trekkelnie kell a létrehozott tokeneket az Ethereumon. + +A szerződésnek nem kell csak ilyen funkciókkal bírnia, a fejlesztő más jellemzőket is használhat a többi tokenszabványból is. Például az „approve” és a „transferFrom” függvények nincsenek benne az ERC-223 szabványban, de implementálhatók. + +[EIP-223-ból](https://eips.ethereum.org/EIPS/eip-223): + +### Metódusok {#methods} + +Az ERC-223 tokennek a következő metódusokat kell implementálnia: + +```solidity +function name() public view returns (string) +function symbol() public view returns (string) +function decimals() public view returns (uint8) +function totalSupply() public view returns (uint256) +function balanceOf(address _owner) public view returns (uint256 balance) +function transfer(address _to, uint256 _value) public returns (bool success) +function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success) +``` + +A szerződésnek, mely ERC-223 tokent fogad be, a következő metódusokat kell implementálnia: + +```solidity +function tokenReceived(address _from, uint _value, bytes calldata _data) +``` + +Ha ERC-223 tokent küldenek egy olyan szerződésnek, amely nem implementálja a „tokenReceived(..)” függvényt, akkor az átadás elbukik és a token nem hagyja el a küldőt. + +### Események {#events} + +```solidity +event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data) +``` + +### Példák {#examples} + +Az ERC-223 token API-ja hasonlít az ERC-20-ashoz, ezért felhasználóifelület-fejlesztés szempontból nincs különbség. Az egyetlen kivételaz, hogy az ERC-223 tokenek nem ismerik az „approve” + „transferFrom” függvényeket, mert ezek opcionálisak. + +#### Solidity-példák {#solidity-example} + +A következő példa bemutatja, hogyan működik egy alap ERC-223 tokenszerződés: + +```solidity +pragma solidity ^0.8.19; +abstract contract IERC223Recipient { + function tokenReceived(address _from, uint _value, bytes memory _data) public virtual; +} +contract VeryBasicERC223Token { + event Transfer(address indexed from, address indexed to, uint value, bytes data); + string private _name; + string private _symbol; + uint8 private _decimals; + uint256 private _totalSupply; + mapping(address => uint256) private balances; + function name() public view returns (string memory) { return _name; } + function symbol() public view returns (string memory) {return _symbol; } + function decimals() public view returns (uint8) { return _decimals; } + function totalSupply() public view returns (uint256) { return _totalSupply; } + function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; } + function isContract(address account) internal view returns (bool) { + uint256 size; + assembly { size := extcodesize(account) } + return size > 0; + } + function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){ + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); + } + emit Transfer(msg.sender, _to, _value, _data); + return true; + } + function transfer(address _to, uint _value) public returns (bool success){ + bytes memory _empty = hex"00000000"; + balances[msg.sender] = balances[msg.sender] - _value; + balances[_to] = balances[_to] + _value; + if(isContract(_to)) { + IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); + } + emit Transfer(msg.sender, _to, _value, _empty); + return true; + } +} +``` + +Szeretnénk, ha egy másik szerződés „tokenA” letétet fogadna el, feltéve, hogy tokenA egy ERC-223 token. A szerződés csak tokenA-t fogadhat el, a többit el kell utasítsa. Amikor a szerződés tokenA-t kap, akkor „Deposit()” eseményt kell kiadnia, és megnöveli a belső „deposits” változót az adott értékkel. + +Íme a kód: + +```solidity +contract RecipientContract is IERC223Recipient { + event Deposit(address whoSentTheTokens); + uint256 deposits = 0; + address tokenA; // The only token that we want to accept. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + // It is important to understand that within this function + // msg.sender is the address of a token that is being received, + // msg.value is always 0 as the token contract does not own or send Ether in most cases, + // _from is the sender of the token transfer, + // _value is the amount of tokens that was deposited. + require(msg.sender == tokenA); + deposits += _value; + emit Deposit(_from); + } +} +``` + +## Gyakran ismételt kérdések {#faq} + +### Mi történik, ha tokenB-t küldünk a szerződésnek? {#sending-tokens} + +A tranzakció elbukik, a tokenátadás nem történik meg. A tokenek a küldő címére térnek vissza. + +### Hogyan lehet letétet elhelyezni ebbe a szerződésbe? {#contract-deposits} + +Meg kell hívni az ERC-223 token „transfer(address,uint256)” vagy „transfer(address,uint256,bytes)” függvényeit, megadva a „RecipientContract” címét. + +### Mi történik, ha ERC-20 tokent küldünk egy ilyen szerződésnek? {#erc-20-transfers} + +Ha ERC-20 tokent küldenek a „RecipientContract” szerződésnek, akkor az átadás megtörténik, de a szerződés nem ismeri fel (nem lesz „Deposit()” esemény, és az érték sem változik). A nem kívánt ERC-20 letéteket nem lehet kiszűrni vagy megakadályozni. + +### Mi van, ha szeretnénk függvényt végrehajtani, miután a token letét végbement? {#function-execution} + +Ennek többféle módja van. Ebben a példában megnézzük a metódust, amitől az ERC-223 átadás egyenértékű lesz az ether-küldéssel: + +```solidity +contract RecipientContract is IERC223Recipient { + event Foo(); + event Bar(uint256 someNumber); + address tokenA; // The only token that we want to accept. + function tokenReceived(address _from, uint _value, bytes memory _data) public override + { + require(msg.sender == tokenA); + address(this).call(_data); // Handle incoming transaction and perform a subsequent function call. + } + function foo() public + { + emit Foo(); + } + function bar(uint256 _someNumber) public + { + emit Bar(_someNumber); + } +} +``` + +Amikor a „RecipientContract” kap egy ERC-223 tokent, a szerződés a token tranzakció „_data” paramétereként kódolt függvényt hajt végre, ugyanúgy, ahogy az ether-tranzakciók kódolják a függvényhívásokat a tranzakció „data” paramétereként. Tekintse meg [az adatmezőt](https://ethereum.org/en/developers/docs/transactions/#the-data-field) további információért. + +A fenti példában az ERC-223 tokent a „RecipientContract” címre a „transfer(address,uin256,bytes calldata _data)” függvénnyel kell küldeni. Ha az adatparaméter „0xc2985578” (ami a „foo()” függvény jele), akkor a foo() függvény indul el a token letétbe helyezése után, és a Foo() eseményt adja. + +A paramétereket be lehet adni a token átadás „data” részébe is, például meghívhatjuk a bar() függvényt az 12345 értékkel „_someNumber” mezőben. Ekkor a „data” a következő „0x0423a13200000000000000000000000000000000000000000000000000000000000004d2”, ahol a „0x0423a132” a „bar(uint256)” függvény aláírása és „00000000000000000000000000000000000000000000000000000000000004d2” a 12345 érték uint256-ként. + +## Korlátok {#limitations} + +Miközben az ERC-223 megold néhány gondot az ERC-20 szabvány kapcsán, megvannak a maga korlátai: + +- Adaptáció és kompatibilitás: az ERC-223 még nincs széles körben adaptálva, ami miatt behatárolt a meglévő eszközökkel és platformokkal való kompatibilitása. +- Visszafelé ható kompatibilitás: az ERC-223 nem kompatibilis visszafelé az ERC-20-szal, tehát a meglévő ERC-20-as szerződések és eszközök nem fognak működni az ERC-223 tokenekkel változtatás nélkül. +- Gázköltségek: Az ERC-223 küldés extra ellenőrzései és funkciói nagyobb költségeket eredményezhetnek egy ERC-20 tranzakcióhoz képest. + +## További olvasnivaló {#further-reading} + +- [EIP-223: ERC-223 tokenszabvány](https://eips.ethereum.org/EIPS/eip-223) +- [Eredeti ERC-223 javaslat](https://github.com/ethereum/eips/issues/223) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md new file mode 100644 index 00000000000..7c566a69bcb --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md @@ -0,0 +1,211 @@ +--- +title: ERC-4626 Tokenizált értékmegőrzőre vonatkozó szabvány +description: A hozamtartó értékmegőrzőkre vonatkozó szabvány. +lang: hu +--- + +## Bevezetés {#introduction} + +Az ERC-4626 szabvány a hozamtartó értékmegőrzők műszaki paramétereinek optimalizálására és egységesítésére szolgál. Egy szabványos API-t biztosít ezen tokenizált értékmegőrzőkhöz, amelyek egyetlen, alapul szolgáló ERC-20 token részvényeit képviselik. Az ERC-4626 egy opcionális kiterjesztést is körvonalaz az ERC-20-at használó tokenizált értékmegőrzők számára, amely alapvető funkciókat kínál a tokenek letétbe helyezéséhez, kivonásához és az egyenlegek leolvasásához. + +**Az ERC-4626 szerepe a hozamtartó értékmegőrzőkben** + +A hitelpiacok, az aggregátorok és a kamatozó tokenek segítenek a felhasználóknak különböző stratégiák végrehajtásával megtalálni a legjobb hozamot a kriptotokenjeikre. Ezek a stratégiák enyhe eltérésekkel kerülhetnek végrehajtásra, ami hibás lehet, vagy pazarolja a fejlesztési erőforrásokat. + +Az ERC-4626 a hozamtartó értékmegőrzőkben csökkenti az integrációs erőfeszítéseket, és a konzisztensebb és robusztusabb végrehajtási minták létrehozásával a fejlesztők kis mértékű speciális erőfeszítései mellett lehetővé teszi a hozamhoz való hozzáférést a különböző alkalmazásokban. + +Az ERC-4626 token teljes körű leírását az [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626) tartalmazza. + +## Előfeltételek {#prerequisites} + +Az oldal könnyebben megértéséhez javasoljuk, hogy tekintse át a [Tokenszabványok](/developers/docs/standards/tokens/) és az [ERC-20](/developers/docs/standards/tokens/erc-20/) című cikkeket. + +## ERC-4626 funkciók és jellemzők: {#body} + +### Metódusok {#methods} + +#### asset {#asset} + +```solidity +function asset() public view returns (address assetTokenAddress) +``` + +Ez a függvény visszaadja az értékmegőrzőben a könyveléshez, befizetéshez és kivonáshoz használt token címét. + +#### totalAssets {#totalassets} + +```solidity +function totalAssets() public view returns (uint256) +``` + +Ez a függvény az értékmegőrzőben lévő fedezeti eszközök teljes összegét adja vissza. + +#### convertToShares {#convertoshares} + +```solidity +function convertToShares(uint256 assets) public view returns (uint256 shares) +``` + +Ez a függvény visszaadja a részvények (`shares`) mennyiségét, amelyet az értékmegőrző a megadott eszközök (`assets`) mennyiségéért cserélne. + +#### convertToAssets {#convertoassets} + +```solidity +function convertToAssets(uint256 shares) public view returns (uint256 assets) +``` + +Ez a függvény visszaadja az eszközök (`assets`) mennyiségét, amelyet az értékmegőrző a megadott részvények (`shares`) mennyiségéért cserélne. + +#### maxDeposit {#maxdeposit} + +```solidity +function maxDeposit(address receiver) public view returns (uint256 maxAssets) +``` + +Ez a függvény a `receiver` által egyetlen [`deposit`](#deposit) hívással letétbe helyezhető fedezeti eszközök maximális összegét adja vissza. + +#### previewDeposit {#previewdeposit} + +```solidity +function previewDeposit(uint256 assets) public view returns (uint256 shares) +``` + +Ez a függvény lehetővé teszi a felhasználók számára, hogy szimulálják a betétük hatásait az aktuális blokkban. + +#### letét {#deposit} + +```solidity +function deposit(uint256 assets, address receiver) public returns (uint256 shares) +``` + +Ez a függvény a mögöttes tokenek eszközeit (`assets`) helyezi el az értékmegőrzőben, és a részvények (`shares`) tulajdonjogát a fogadónak (`receiver`) adja. + +#### maxMint {#maxmint} + +```solidity +function maxMint(address receiver) public view returns (uint256 maxShares) +``` + +Ez a függvény visszaadja a `receiver` által egyetlen [`mint`](#mint) hívással kiadható részvények maximális mennyiségét. + +#### previewMint {#previewmint} + +```solidity +function previewMint(uint256 shares) public view returns (uint256 assets) +``` + +Ez a függvény lehetővé teszi a felhasználók számára, hogy szimulálják a mintelés hatásait az aktuális blokkban. + +#### mint (kibocsátás) {#mint} + +```solidity +function mint(uint256 shares, address receiver) public returns (uint256 assets) +``` + +Ez a függvény pontosan `shares` értékmegőrzői részvényeket ad ki a fogadónak (`receiver`) az alapul szolgáló tokenek eszközeinek (`assets`) letétbe helyezésével. + +#### maxWithdraw {#maxwithdraw} + +```solidity +function maxWithdraw(address owner) public view returns (uint256 maxAssets) +``` + +Ez a függvény az `owner` egyenlegéből egyetlen [`withdraw`](#withdraw) hívással kivehető fedezeti eszközök maximális összegét adja vissza. + +#### previewWithdraw {#previewwithdraw} + +```solidity +function previewWithdraw(uint256 assets) public view returns (uint256 shares) +``` + +Ez a függvény lehetővé teszi a felhasználók számára, hogy szimulálják a kivonásuk hatásait az aktuális blokkban. + +#### withdraw {#withdraw} + +```solidity +function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares) +``` + +Ez a függvény részvény (`shares`) elégetését végzi a tulajdonostól (`owner`), és pontosan ennyi `shares` tokent küld az értékmegőrzőből a fogadónak (`receiver`). + +#### maxRedeem {#maxredeem} + +```solidity +function maxRedeem(address owner) public view returns (uint256 maxShares) +``` + +Ez a függvény visszaadja az `owner` egyenlegéből [`redeem`](#redeem) hívással visszaváltható részvények maximális mennyiségét. + +#### previewRedeem {#previewredeem} + +```solidity +function previewRedeem(uint256 shares) public view returns (uint256 assets) +``` + +Ez a függvény lehetővé teszi a felhasználók számára, hogy szimulálják a beváltásuk hatásait az aktuális blokkban. + +#### redeem {#redeem} + +```solidity +function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets) +``` + +Ez a függvény meghatározott számú részvényt (`shares`) vált be a tulajdonostól (`owner`), és elküldi a mögöttes token eszközöket (`assets`) az értékmegőrzőből a fogadónak (`receiver`). + +#### totalSupply {#totalsupply} + +```solidity +function totalSupply() public view returns (uint256) +``` + +Visszaadja a forgalomban lévő, be nem váltott értékmegőrző-részvények teljes számát. + +#### balanceOf {#balanceof} + +```solidity +function balanceOf(address owner) public view returns (uint256) +``` + +Visszaadja az `owner` által jelenleg birtokolt értékmegőrző-részvények teljes mennyiségét. + +### Az interfész térképe {#mapOfTheInterface} + +![Az ERC-4626 interfész térképe](./map-of-erc-4626.png) + +### Események {#events} + +#### Letétbe helyezési esemény + +Akkor **KELL** kiadni, amikor tokeneket helyeznek el az értékmegőrzőben a [`mint`](#mint) és a [`deposit`](#deposit) metódusokon keresztül + +```solidity +event Deposit( + address indexed sender, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +Ahol a küldő (`sender`) az a felhasználó, aki eszközöket (`assets`) cserélt részvényre (`shares`), és átadta ezeket a részvényeket (`shares`) a tulajdonosnak (`owner`). + +#### Kivonási esemény + +Ki **KELL** adni, amikor a letétes a [`redeem`](#redeem) vagy [`withdraw`](#withdraw) módon részvényeket vesz ki az értékmegőrzőből. + +```solidity +event Withdraw( + address indexed sender, + address indexed receiver, + address indexed owner, + uint256 assets, + uint256 shares +) +``` + +Ahol a küldő (`sender`) az a felhasználó, aki a kivonást kezdeményezte és a tulajdonos (`owner`) tulajdonában lévő részvényeket (`shares`) eszközökre (`assets`) cserélte. A `receiver` az a felhasználó, aki a visszavont eszközöket (`assets`) megkapta. + +## További olvasnivaló {#further-reading} + +- [ERC-4626: Tokenizált értékmegőrzőre vonatkozó szabvány](https://eips.ethereum.org/EIPS/eip-4626) +- [ERC-4626: GitHub mappa](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md new file mode 100644 index 00000000000..29f4349a989 --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md @@ -0,0 +1,244 @@ +--- +title: ERC-721 Nem helyettesíthető tokenekről szóló szabvány +description: +lang: hu +--- + +## Bevezetés {#introduction} + +**Mi az a nem helyettesíthető token?** + +Egy nem helyettesíthető tokent (NFT) valami vagy valaki egyedi beazonosítására lehet használni. Ezt a tokentípust tökéletesen lehet használni olyan platformokon, melyek gyűjthető tárgyakat, hozzáférési kulcsokat, lottószelvényeket, sorszámozott koncertjegyeket vagy sporteseményjegyeket stb. árulnak. Ez a speciális tokentípus csodás lehetőségeket rejt magában, így megérdemel egy megfelelő szabványt, így az ERC-721 szolgál megoldásul! + +**Mi az az ERC-721?** + +Az ERC-721 bevezeti az NFT-szabványt, vagyis ez a tokentípus egyedi és különböző értékekkel rendelkezhet, mint egy másik token ugyanabból az okosszerződésből, ami esetleg a korából, ritkaságából vagy a kinézetéből származik. Egy pillanat, kinézet? + +Igen! Minden NFT-nek van egy `uint256` változója `tokenId` néven, így minden ERC-721 szerződéshez tartozó `contract address, uint256 tokenId` globálisan egyedi. Tehát egy dappnak lehet egy „konvertere”, amely a `tokenId` változót használja bemenetre, kimenetként pedig valami menő dolog képét adja vissza, például zombikat, fegyvereket, képességeket vagy csodás kiscicákat! + +## Előfeltételek {#prerequisites} + +- [Számlák](/developers/docs/accounts/) +- [Okosszerződések](/developers/docs/smart-contracts/) +- [Token szabványok](/developers/docs/standards/tokens/) + +## Törzs {#body} + +Az ERC-721 (Ethereum Request for Comments 721), melyet William Entriken, Dieter Shirley, Jacob Evans és Nastassia Sachs javasolt 2018. januárjában, egy nem helyettesíthető tokenre vonatkozó szabványt vezet be, mely egy token API-t implementál az okosszerződéseken belül. + +Olyan funkcionalitásokat tartalmaz, mint a tokenátutalás egyik számláról a másikra, a token jelenlegi egyenlegének lekérdezése az adott számlán, az adott token jelenlegi tulajdonosa, valamint a teljes elérhető tokenmennyiség a hálózaton. Emellett vannak más funkciók is, mint például annak jóváhagyása, hogy egy harmadik fél számlája átmozgasson egy bizonyos mennyiségű tokent az adott számláról. + +Ha egy okosszerződés implementálja a következő metódusokat és eseményeket, akkor egy ERC-721 nem helyettesíthető tokenszerződésnek lehet nevezni, és a telepítés után a létrejött tokenek számontartásáért lesz felelős az Ethereumon. + +Az [EIP-721-ből](https://eips.ethereum.org/EIPS/eip-721): + +### Metódusok {#methods} + +```solidity + function balanceOf(address _owner) external view returns (uint256); + function ownerOf(uint256 _tokenId) external view returns (address); + function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable; + function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; + function transferFrom(address _from, address _to, uint256 _tokenId) external payable; + function approve(address _approved, uint256 _tokenId) external payable; + function setApprovalForAll(address _operator, bool _approved) external; + function getApproved(uint256 _tokenId) external view returns (address); + function isApprovedForAll(address _owner, address _operator) external view returns (bool); +``` + +### Események {#events} + +```solidity + event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); + event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); + event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); +``` + +### Példák {#web3py-example} + +Nézzük meg, miért olyan fontos egy szabvány, hogy egyszerűbbé tegye számunkra azt, hogy bármely ERC-721 tokenszerződést megtekinthessük az Ethereumon. Csak a szerződés Alkalmazás bináris interfészére (ABI) lesz szükség, hogy egy felületet készítsünk bármely ERC-721 tokennek. Ahogy lentebb látni fogod, egy egyszerűsített ABI-t használunk, hogy egy egyszerűbb példával éljünk. + +#### Web3.py példa {#web3py-example} + +Először győződj meg arról, hogy a [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python könyvtár telepítve van: + +``` +pip install web3 +``` + +```python +from web3 import Web3 +from web3._utils.events import get_event_data + + +w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) + +ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract + +acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction + +# This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract. +# It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() +simplified_abi = [ + { + 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}], + 'name': 'balanceOf', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'name', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}], + 'name': 'ownerOf', + 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'symbol', + 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [], + 'name': 'totalSupply', + 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], + 'stateMutability': 'view', 'type': 'function', 'constant': True + }, +] + +ck_extra_abi = [ + { + 'inputs': [], + 'name': 'pregnantKitties', + 'outputs': [{'name': '', 'type': 'uint256'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + }, + { + 'inputs': [{'name': '_kittyId', 'type': 'uint256'}], + 'name': 'isPregnant', + 'outputs': [{'name': '', 'type': 'bool'}], + 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True + } +] + +ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi) +name = ck_contract.functions.name().call() +symbol = ck_contract.functions.symbol().call() +kitties_auctions = ck_contract.functions.balanceOf(acc_address).call() +print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}") + +pregnant_kitties = ck_contract.functions.pregnantKitties().call() +print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}") + +# Using the Transfer Event ABI to get info about transferred Kitties. +tx_event_abi = { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'from', 'type': 'address'}, + {'indexed': False, 'name': 'to', 'type': 'address'}, + {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}], + 'name': 'Transfer', + 'type': 'event' +} + +# We need the event's signature to filter the logs +event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex() + +logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [event_signature] +}) + +# Notes: +# - Increase the number of blocks up from 120 if no Transfer event is returned. +# - If you didn't find any Transfer event you can also try to get a tokenId at: +# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events +# Click to expand the event's logs and copy its "tokenId" argument +recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs] + +if recent_tx: + kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above + is_pregnant = ck_contract.functions.isPregnant(kitty_id).call() + print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}") +``` + +A CryptoKitties szerződésnek van egy pár érdekes eseménye, ami nem sztenderd. + +Nézzünk meg kettőt közülük: `Pregnant` és `Birth`. + +```python +# A Pregnant és a Birth esemény ABI-ok használata, hogy infókat kapjunk meg az új cicákról. +ck_extra_events_abi = [ + { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'owner', 'type': 'address'}, + {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, + {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, + {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}], + 'name': 'Pregnant', + 'type': 'event' + }, + { + 'anonymous': False, + 'inputs': [ + {'indexed': False, 'name': 'owner', 'type': 'address'}, + {'indexed': False, 'name': 'kittyId', 'type': 'uint256'}, + {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, + {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, + {'indexed': False, 'name': 'genes', 'type': 'uint256'}], + 'name': 'Birth', + 'type': 'event' + }] + +# We need the event's signature to filter the logs +ck_event_signatures = [ + w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(), + w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(), +] + +# Here is a Pregnant Event: +# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog +pregnant_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [ck_event_signatures[0]] +}) + +recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs] + +# Here is a Birth Event: +# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a +birth_logs = w3.eth.get_logs({ + "fromBlock": w3.eth.block_number - 120, + "address": w3.to_checksum_address(ck_token_addr), + "topics": [ck_event_signatures[1]] +}) + +recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs] +``` + +## Népszerű NFT-k {#popular-nfts} + +- [Etherscan NFT Tracker](https://etherscan.io/tokens-nft) legnagyobb forgalommal rendelkező NFT-k listája az Ethereumon. +- [CryptoKitties](https://www.cryptokitties.co/) egy játék, mely tenyészthető, gyűjthető és imádnivaló lényekről szól, melyeket CryptoKittiknek nevezünk. +- [Sorare](https://sorare.com/) egy globális fantáziafutball-játék, ahol korlátozott példányszámú gyűjthető dolgot lehet összeszedni, Ön irányíthatja a csapatait, és versenyezhet díjakért. +- [Az Ethereum Name Service (ENS)](https://ens.domains/) egy biztonságos & decentralizált módját kínálja az erőforrások kezelésére a blokkláncon vagy azon kívül egyszerű, emberek számára is olvasható nevek használatával. +- A [POAP](https://poap.xyz) ingyenes NFT-ket biztosít azoknak, akik részt vesznek eseményeken vagy meghatározott akciókat hajtanak végre. A POAP-ok létrehozása és terjesztése ingyenes. +- Az [Unstoppable Domains](https://unstoppabledomains.com/) egy San Francisco székhelyű vállalat, amely domainneveket fejleszt a blokkláncra. A blokklánc-domainek a kriptovalutacímeket ember által is olvasható nevekre cserélik, és cenzúraellenálló weboldalakhoz is használhatók. +- A [Gods Unchained Cards](https://godsunchained.com/) egy TCG (Trading Card Game) az Ethereum-blokkláncon, amely NFT-ket használ, hogy valódi tulajdonjogot biztosítson a játékon belüli eszközökre. +- A [Bored Ape Yacht Club](https://boredapeyachtclub.com) egy 10 000 egyedi NFT-ből álló gyűjtemény, amely amellett, hogy bizonyíthatóan ritka műalkotás, a klub tagsági zálogaként is szolgál, és a közösségi erőfeszítések eredményeként idővel növekvő tagsági kedvezményeket és előnyöket biztosít. + +## További olvasnivaló {#further-reading} + +- [ERC-721: Nem helyettesíthető tokenekről szóló szabvány](https://eips.ethereum.org/EIPS/eip-721) +- [OpenZeppelin - ERC-721 Dokumentáció](https://docs.openzeppelin.com/contracts/3.x/erc721) +- [OpenZeppelin - ERC-721 Implementáció](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) +- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md new file mode 100644 index 00000000000..69264f5cbbb --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md @@ -0,0 +1,77 @@ +--- +title: ERC-777 tokenszabvány +description: +lang: hu +--- + +## {#introduction} + +**** + +**** + +A hook vagy horog az okosszerződés kódjában leírt funkciót jelent. Akkor kerülnek meghívásra, amikor a szerződésen keresztül tokeneket küldenek vagy fogadnak. Ez lehetővé teszi, hogy az okosszerződés reagáljon a bejövő vagy kimenő tokenekre. + +## {#prerequisites} + +- []() +- []() +- []() + +## {#body} + +A horgokat az [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820)-as szabvány segítségével regisztrálják és fedezik fel. + +A szabvány megoldja az ERC-20-ban a `decimals` körül kialakult zavart is. Ez az egyértelműség javítja a fejlesztői élményt. + +Az ERC-777-es szerződésekkel úgy lehet interakcióba lépni, mintha ERC-20-as szerződések lennének. + +### {#methods} + +```solidity + +``` + +### {#events} + +```solidity + +``` + +### {#web3py-example} + +#### {#web3py-example} + +``` + +``` + +```python + + + + +``` + +```python + + +``` + +## {#popular-nfts} + +- +- +- +- +- +- +- +- + +## További olvasnivaló {#further-reading} + +- []() +- []() +- []() +- []() diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/index.md new file mode 100644 index 00000000000..864ff6f8d6b --- /dev/null +++ b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/index.md @@ -0,0 +1,39 @@ +--- +title: Tokenszabványok +description: +lang: hu +incomplete: true +--- + +## Bevezetés {#introduction} + +Sok Ethereum fejlesztési szabvány a tokeninterfészekre összpontosít. Ezek a szabványok segítenek abban, hogy az okosszerződések továbbra is összeilleszthetőek maradnak, így például amikor egy új projekt egy tokent bocsát ki, az továbbra is kompatibilis marad a meglévő decentralizált tőzsdékkel. + +## Előfeltételek {#prerequisites} + +- [Ethereum fejlesztési szabványok](/developers/docs/standards/) +- [Okosszerződések](/developers/docs/smart-contracts/) + +## Token szabványok {#token-standards} + +Itt van néhány az Ethereum legnépszerűbb tokenszabványaiból: + +- [ERC-20](/developers/docs/standards/tokens/erc-20/) – Egy sztenderd interfész a helyettesíthető (cserélhető) tokenekhez, például a szavazási és letéti tokenekhez vagy a virtuális valutákhoz. + +### NFT szabványok {#nft-standards} + +- [ERC-721](/developers/docs/standards/tokens/erc-721/) – Egy sztenderd interfész a nem helyettesíthető tokenekhez, például egy műalkotásról szóló okirathoz vagy egy dalhoz. +- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) – Az ERC-1155 hatékonyabb kereskedést és tranzakciókötést tesz lehetővé, ami költségmegtakarítást eredményez. Ez a tokenszabvány lehetővé teszi mind a közüzemi tokenek (például $BNB vagy $BAT), mind pedig a CryptoPunks-hoz hasonló, nem helyettesíthető tokenek létrehozását. + +Az [ERC](https://eips.ethereum.org/erc) javaslatok teljes listája. + +## További olvasnivaló {#further-reading} + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ + +## Kapcsolódó útmutatók {#related-tutorials} + +- [Tokenintegrációs ellenőrzési lista](/developers/tutorials/token-integration-checklist/) _– Egy ellenőrzési lista, melyet figyelembe kell venni tokenekkel történő interakcióknál_ +- [Az ERC-20 token okosszerződés megértése](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– Bevezetés az első okosszerződés telepítésébe egy Ethereum teszthálózaton._ +- [ERC-20 tokenek átvitele és jóváhagyása egy Solidity okosszerződésből](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– hogyan használjunk okosszerződést a Solidity nyelv használatával a tokenekkel való interakcióhoz._ +- [Útmutató az ERC-721 piacimplementációhoz](/developers/tutorials/how-to-implement-an-erc721-market/) _– Hogyan lehet tokenizált tárgyakat eladásra kínálni egy decentralizált és titkosított felületen._ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" new file mode 100644 index 00000000000..0b8d716bf50 --- /dev/null +++ "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" @@ -0,0 +1,114 @@ +--- +title: Méretezés +description: Bevezetés a különböző skálázási lehetőségekbe, melyet jelenleg az Ethereum közösség fejleszt. +lang: hu +sidebarDepth: 3 +--- + +## Skálázás áttekintése {#scaling-overview} + +Ahogy az Ethereumot használók száma nőtt, a blokklánc elért bizonyos kapacitáskorlátokat. Ez megemelte a hálózat használatának költségeit, és egyúttal igényt teremtett a „skálázási megoldásokra”. Többféle megoldást kutatnak, tesztelnek és vezetnek be, amelyek különböző megközelítésekkel érnek el hasonló célokat. + +A skálázhatóság fő célja a tranzakció sebességének növelése (gyorsabb véglegesség) és a nagyobb tranzakcióátvitel (több tranzakció másodpercenként) a decentralizáció vagy a biztonság feláldozása nélkül (bővebben az [Ethereum jövőképében](/roadmap/vision/)). Az Ethereum blokkláncon (L1) a nagy kereslet lassabb tranzakciókhoz és irracionális [gázárakhoz](/developers/docs/gas/) vezet. A hálózati kapacitás növelése a sebesség és a tranzakcióátvitel tekintetében alapvető fontosságú az Ethereum értelmes és tömeges használatához. + +Bár a sebesség és a tranzakcióátvitel fontos, mégis lényeges, hogy az ezeket lehetővé tevő skálázási megoldások decentralizáltak és biztonságosak maradjanak. A csomópontok üzemeltetői számára a belépési korlátok alacsonyan tartása kritikus, hogy ne mozduljon el a hálózat a centralizált és bizonytalan számítási teljesítmény felé. + +Koncepcionálisan a skálázást először a láncon belüli vagy kívüli kategóriájába sorolhatjuk. + +## Előfeltételek {#prerequisites} + +Jó alapokkal kell rendelkeznie az összes alapvető témakörről. A skálázási megoldások megvalósítása komoly feladat, a technológia még kevésbé kiforrott, folyamatosan kutatják és fejlesztik. + +## Láncon belüli skálázás {#on-chain-scaling} + +A láncon belüli skálázáshoz módosíttani kell az Ethereum protokollját (L1 [főhálózatot](/glossary/#mainnet)). Sokáig a blokklánc felosztásától (sharding) várták az Ethereum skálázását. Ehhez a blokkláncot különálló darabokra kellett volna osztani, amelyeket a validátorok részhalmazai ellenőriznek. A második blokkláncréteg (L2) összevont tranzakciókkal történő skálázása vált preferálttá. Ezt támogatja az Ethereum-blokkokhoz csatolt adatok egy új, olcsóbb formája, amelyet kifejezetten arra terveztek, hogy a felhasználók számára olcsóbbá tegye az összevont tranzakciókat. + +### Sharding {#sharding} + +A sharding egy adatbázis felosztásának folyamata. A validátorok részhalmazai az egyes shardokért lennének felelősek, ahelyett hogy az egész Ethereumot nyomon követnék. A sharding sokáig szerepelt az Ethereum [ütemtervében](/roadmap/), és egykor úgy tervezték, hogy még a proof-of-stake bevezetése (a Beolvadás) előtt leszállításra kerül. Az [L2 összevont tranzakciók](#layer-2-scaling) gyors fejlődése és a [Danksharding](/roadmap/danksharding) feltalálása (a validátorok által hatékonyan ellenőrizhető összevont tranzakciós adatblobok hozzáadása az Ethereum blokkokhoz) azonban arra késztette az Ethereum közösséget, hogy az összevonttranzakció-központú skálázást részesítse előnyben a sharding helyett. Ez segít abban is, hogy az Ethereum konszenzuslogikája egyszerűbb legyen. + +## Láncon kívüli skálázás {#off-chain-scaling} + +A láncon kívüli megoldásokat az L1 főhálózattól függetlenül valósítják meg, tehát nem igényelnek változtatásokat a meglévő Ethereum protokollban. Az L2 megoldások közvetlenül az Ethereum L1 konszenzusából származtatják biztonságukat, mint például a [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/), [a zero-knowledge összevont tranzakciók](/developers/docs/scaling/zk-rollups/) vagy [státuszcsatornák](/developers/docs/scaling/state-channels/). Más megoldások különböző formájú új láncok létrehozását foglalják magukban, amelyek a biztonságukat a főhálózattól elkülönítve kezelik, mint például [mellékláncok](#sidechains), [validiumok](#validium) vagy [plazmaláncok](#plasma). Ezek a megoldások kommunikálnak a főhálózattal, de más-más célok elérése érdekében másképp biztosítják a szükséges biztonságot. + +### L2 skálázás {#layer-2-scaling} + +A láncon kívüli megoldások ezen kategóriája az Ethereum főhálózatból meríti biztonságát. + +Az L2 azon megoldások gyűjtőfogalma, amelyek az alkalmazások skálázhatóságát úgy oldják meg, hogy a tranzakciókat a főhálózaton (L1) kívül végzik el, ugyanakkor felhasználják a főhálózat robusztus, decentralizált biztonsági modelljét. A hálózat leterheltségekor lassul a tranzakciók feldolgozása, ami rontja a felhasználói élményt bizonyos típusú dappoknál. Ahogy nő a hálózat forgalma, úgy nőnek a gázárak, mivel a tranzakció küldők próbálják egymást túllicitálni. Ez nagyon drágává teszi az Ethereum használatát. + +A legtöbb L2 megoldás egy szerver vagy egy szerverklaszter körül helyezkedik el, amelyek mindegyikét csomópontnak, validátornak, operátornak, szekvenszernek, blokkgyártónak vagy hasonlónak nevezhetjük. A megvalósítástól függően ezeket az L2 csomópontokat futtathatják egyének, felhasználóként működő vállalkozások vagy vállalatok, harmadik fél vagy egyének nagy csoportja (hasonlóan a főhálózathoz). Általánosságban elmondható, hogy a tranzakciókat ezekhez az L2 csomópontokhoz nyújtják be ahelyett, hogy közvetlenül az L1-be (főhálózat) adnák. Bizonyos megoldásoknál az L2 ezután csoportokba rendezi őket, mielőtt az L1 felé közvetítené azokat, majd az L1 rögzíti azokat, és nem módosíthatók. A részletek jelentősen eltérnek a különböző L2 technológiák és megvalósítások függvényében. + +Egy adott L2 lehet nyitott és több alkalmazás használja, vagy egy adott projekt üzemelteti a saját alkalmazásukhoz. + +#### Miért szükséges az L2? {#why-is-layer-2-needed} + +- A másodpercenkénti tranzakciók számának növekedése jelentősen javítja a felhasználói élményt, és csökkenti a hálózati torlódásokat az Ethereum főhálózaton. +- Sok tranzakciót vonnak össze, melyek egyetlen tranzakcióként jelennek meg az Ethereum főhálózaton, ezzel is csökkentve a felhasználók gázdíjait, így az Ethereum mindenhol befogadóbbá és elérhetőbbé válik. +- A skálázhatóság fejlesztése nem mehet a decentralizáció rovására – az L2 réteg az Ethereumra épül. +- Vannak alkalmazásspecifikus L2 hálózatok, amelyek hatékonysági előnyökkel járnak az eszközökkel való méretarányos munka során. + +[Bővebben az L2-ről](/layer-2/). + +#### Összevont tranzakciók {#rollups} + +Az összevont tranzakciók az L1-en kívül hajtják végre a tranzakciókat, majd az adatok az L1-be kerülnek, ahol konszenzusra jutnak. Mivel a tranzakciós adatok az L1 blokkokban szerepelnek, ez lehetővé teszi az összevont tranzakciók natív Ethereum-biztonsággal történő védelmét. + +Kétfajta összevont tranzakció létezik különböző biztonsági modellekkel: + +- **Optimista összevont tranzakció**: alapértelmezésben érvényes tranzakciókat feltételez, és csak kétely esetén végez számításokat egy [**csalási bizonyíték**](/glossary/#fraud-proof) révén. [Bővebben az optimista összevont tranzakciókról](/developers/docs/scaling/optimistic-rollups/). +- **Zero-knowledge összevont tranzakció**: számítást végez a láncon kívül, és [**érvényességi bizonyítékot**](/glossary/#validity-proof) ad a láncnak. [Bővebben a zero-knowledge összevont tranzakciókról](/developers/docs/scaling/zk-rollups/). + +#### Állapot csatornák {#channels} + +A státuszcsatornák többaláírásos szerződéseket használnak, hogy a résztvevők gyorsan és szabadon tudjanak tranzakciókat lebonyolítani a láncon kívül, majd a végleges elszámolást a főhálózattal végezzék. Ez minimalizálja a hálózati torlódásokat, díjakat és késedelmeket. Két típusa jelenleg a státuszcsatorna és a fizetési csatorna. + +Tudjon meg többet az [státuszcsatornákról](/developers/docs/scaling/state-channels/). + +### Mellékláncok {#sidechains} + +A melléklánc egy független, EVM-kompatibilis blokklánc, amely a főhálózattal párhuzamosan fut. Ezek kétirányú hidakon keresztül kompatibilisek az Ethereummal, és saját konszenzusszabályok és blokkparaméterek szerint működnek. + +Tudjon meg többet a [mellékláncokról](/developers/docs/scaling/sidechains/). + +### Plazma {#plasma} + +A plazmalánc egy külön blokklánc, amely a fő Ethereum-lánchoz van rögzítve, és csalásbizonylatokat (például [optimista rollup](/developers/docs/scaling/optimistic-rollups/)) használ a viták eldöntésére. + +Bővebben a [plazmáról](/developers/docs/scaling/plasma/). + +### Validium {#validium} + +A validiumlánc olyan érvényességi bizonyítékokat használ, mint a zero-knowledge összevont tranzakciók, de az adatokat nem az Ethereum L1-en tárolja. Ez másodpercenként 10 000 tranzakciót eredményezhet validiumlánconként, és több láncot lehet párhuzamosan futtatni. + +Bővebben a [validiumokról](/developers/docs/scaling/validium/). + +## Miért van szükség ennyi skálázási megoldásra? {#why-do-we-need-these} + +- A többféle megoldás segíthet csökkenteni a hálózat részeinek általános zsúfoltságát, és megakadályozza az egyetlen meghibásodási pont kialakulását is. +- Az egész több, mint a részek összege. Különböző megoldások létezhetnek és működhetnek együtt, ami exponenciális hatást gyakorolhat a jövőbeli tranzakciók sebességére és tranzakcióátvitelre. +- Nem minden megoldás igényli az Ethereum konszenzusalgoritmusának közvetlen használatát, és az alternatívák olyan előnyöket kínálhatnak, amelyeket egyébként nehéz lenne elérni. +- Egyetlen skálázási megoldás sem elegendő az [Ethereum víziójának](/roadmap/vision/) megvalósításához. + +## Ön inkább vizuális típus? {#visual-learner} + + + +_Vegye figyelembe, hogy a videóban szereplő magyarázat az L2 kifejezést használja az összes láncon kívüli skálázási megoldásra, míg mi olyan láncon kívüli megoldásként különböztetjük meg, amely biztonságát az L1 főhálózat konszenzusán keresztül nyeri._ + + + +## További olvasnivaló {#further-reading} + +- [Egy összevonttranzakció-központú Ethereum útiterv](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_ +- [Naprakész elemzések az L2 skálázási megoldásokról az Ethereum számára](https://www.l2beat.com/) +- [Ethereum L2 skálázási megoldások értékelése: összehasonlítási keretrendszer](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) +- [Egy nem teljeskörű útmutató az összevont tranzakciókhoz](https://vitalik.eth.limo/general/2021/01/05/rollup.html) +- [Ethereum-alapú ZK összevont tranzakciók: világverők](https://hackmd.io/@canti/rkUT0BD8K) +- [Az optimista összevont tranzakciók és a ZK összevont tranzakciók összehasonlítása](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) +- [Zero-knowledge blokklánc skálázhatósága](https://ethworks.io/assets/download/zero-knowledge-blockchain-scaling-ethworks.pdf) +- [Miért az összevont tranzakciók és az adatmegosztások (sharding) adják az egyetlen fenntartható megoldást a nagyfokú skálázhatósághoz](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) +- [Milyen L3 megoldásoknak van értelme?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) +- [Adatelérhetőség vagy hogyan tanulták meg az összevont tranzakciók, hogy ne aggódjanak és szeressék az Ethereumot](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups) + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" new file mode 100644 index 00000000000..522182424e0 --- /dev/null +++ "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" @@ -0,0 +1,269 @@ +--- +title: Optimista összevont tranzakciók +description: Bevezetés az optimista összevont tranzakciókba – az Ethereum közösség által használt skálázási megoldásba. +lang: hu +--- + +Az optimista összevont tranzakciók olyan L2 protokollok, amelyeket az Ethereum alapréteg tranzakcióátvitelének növelésére terveztek. A tranzakciók láncon kívüli feldolgozásával csökkentik a számításokat a fő Ethereum-láncon, ami jelentősen javítja a feldolgozási sebességet. A [mellékláncokhoz](/developers/docs/scaling/sidechains/) képest az optimistaz összevont tranzakciók a főhálózat biztonságát a tranzakciós eredmények láncon belüli közzétételével nyerik, a [plazmaláncokkal összevetve](/developers/docs/scaling/plasma/) ugyanúgy az Ethereumon ellenőrzik a tranzakciókat csalási bizonyítékokkal, de azok a tranzakciós adatokat máshol tárolják. + +Mivel a számítás az Ethereum használatának lassú és drága része, az optimista összevont tranzakciók akár 10-100-szoros javulást is kínálnak a méretezhetőségben. Az optimista összevont tranzakciók a tranzakciókat is `calldata` mezőként vagy a [blobokba](/roadmap/danksharding/) írják az Ethereumba, csökkentve a felhasználók gázköltségeit. + +## Előfeltételek {#prerequisites} + +Érdemes áttekinteni az [Ethereum skálázásról](/developers/docs/scaling/) és [L2 megoldásokról](/layer-2/) szóló oldalakat. + +## Mi az az optimista összevont tranzakció? {#what-is-an-optimistic-rollup} + +Az optimista összevont tranzakció az Ethereum skálázásának olyan megközelítése, amely a számítást és a státusztárolást láncon kívül végzi. Az optimista összevont tranzakciók a tranzakciókat az Ethereumon kívül hajtják végre, de a tranzakciós adatokat `calldata` mezőként vagy [blobokban](/roadmap/danksharding/) a főhálózatra küldik. + +Az optimista összevont tranzakciók operátorai több láncon kívüli tranzakciót kötegelnek össze nagy tételekben, mielőtt elküldik az Ethereumnak. Ez a megközelítés lehetővé teszi a fix költségek elosztását a kötegek tranzakcióira, csökkentve ezzel a végfelhasználók díjait. Az optimista összevont tranzakciók tömörítési technikákat is alkalmaznak, hogy csökkentsék az Ethereumban közzétett adatok mennyiségét. + +Az optimista összevont tranzakciók azért számítanak optimistának, mert feltételezik, hogy a láncon kívüli tranzakciók érvényesek, és nem tesznek közzé érvényességi bizonyítékokat a láncon közzétett tranzakciókötegekről. Ez a különbség az optimista és a [zero-knowledge összevont tranzakciók](/developers/docs/scaling/zk-rollups) között, mivel utóbbiak kriptográfiai [érvényességi bizonyítékokat](/glossary/#validity-proof) tesznek közzé a láncokon kívüli tranzakciókról. + +Az optimista összevont tranzakciók ehelyett egy csalásbizonyító rendszerre támaszkodnak, hogy felderítsék azokat az eseteket, amikor a tranzakciókat nem megfelelően számítják ki. Miután egy összevonttranzakció-köteget benyújtottak az Ethereumra, egy adott „megkérdőjelezési” időszakon belül bárki megtámadhatja az összevont tranzakció eredményét egy [csalási bizonyíték](/glossary/#fraud-proof) kiszámításával. + +Ha a csalási bizonyíték sikeres, az összevonttranzakció-protokoll újra végrehajtja a tranzakció(ka)t, és ennek megfelelően frissíti az összevont tranzakció státuszát. A sikeres csalási bizonyíték másik hatása az, hogy a hibásan végrehajtott tranzakció blokkba való felvételéért felelős szekvencer büntetést kap. + +Ha az összevonttranzakció-köteg a megkérdőjelezési időszak letelte után is kifogástalan marad (minden tranzakciót helyesen hajtottak végre), akkor azt érvényesnek és elfogadottnak tekintik az Ethereumon. Lehetséges egy meg nem erősített összevonttranzakció-blokkra építeni, de fontos tudni: a tranzakció eredményei megfordulnak, ha egy korábban közzétett, hibásan végrehajtott tranzakción alapulnak. + +## Hogyan működnek együtt az optimista összevont tranzakciók az Ethereummal? {#optimistic-rollups-and-Ethereum} + +Az optimista összevont tranzakciók [láncon kívüli skálázási megoldások](/developers/docs/scaling/#off-chain-scaling), amelyek az Ethereumra épülve működnek. Minden egyes optimista összevont tranzakció-ot az Ethereum-hálózaton telepített okosszerződések egy csoportja kezel. Az optimista összevont tranzakciók a tranzakciókat a fő Ethereum-láncon kívül dolgozzák fel, majd ezeket kötegekben egy láncon belüli összevont tranzakciós szerződésbe írják. Az Ethereum blokkláncához hasonlóan ez a tranzakciós rekord is megváltoztathatatlan, és az „optimista összevont tranzakció láncát” alkotja. + +Az optimista összevont tranzakció architektúrája a következő részekből áll: + +**Láncon lévő szerződések**: Az optimista összevont tranzakciók működését az Ethereumon futó okosszerződések irányítják. Ide olyan szerződések tartoznak, melyek tárolják az összevonttranzakció-blokkokat, követik a státuszfrissítéseket és a felhasználói befizetéseket. Így az Ethereum az optimista összevont tranzakció alaprétegeként vagy L1-ként szolgál. + +**Láncon kívüli virtuális gép (VM)**: Bár az optimista összevont tranzakciós protokollt kezelő szerződések az Ethereumon futnak, az összevont tranzakciós protokoll a számításokat és a státusztárolást egy másik virtuális gépen végzi, amely elkülönül az [Ethereum virtuális géptől](/developers/docs/evm/). A láncon kívüli VM az, ahol az alkalmazások élnek és a státuszváltozások végrehajtásra kerülnek; ez az optimista összevont tranzakció felső vagy második rétege (L2). + +Mivel az optimista összevont tranzakcióokat az EVM számára írt vagy lefordított programok futtatására tervezték, a láncon kívüli VM számos EVM tervezési specifikációt tartalmaz. Ezenkívül a láncban kiszámított csalási bizonyítékok lehetővé teszik az Ethereum-hálózat számára, hogy érvényre juttassa a láncon kívüli VM-ben kiszámított státuszváltozások érvényességét. + +Az optimista összevont tranzakciókat hibrid skálázási megoldásoknak nevezik, mert bár különálló protokollként léteznek, biztonsági tulajdonságaik az Ethereumból származnak. Az Ethereum többek között garantálja az összevont tranzakció láncon kívüli számítás helyességét és a számítás mögötti adatok elérhetőségét. Ezáltal az optimista összevont tranzakciók biztonságosabbak, mint a tisztán láncon kívüli skálázási protokollok (pl. [mellékláncok](/developers/docs/scaling/sidechains/)), amelyek nem támaszkodnak az Ethereum biztonságára. + +Az optimista összevont tranzakciók az Ethereum fő protokolljára támaszkodnak a következőkben: + +### Adatelérhetőség {#data-availability} + +Az optimista összevont tranzakciók a tranzakciós adatokat `calldata` mezőként vagy [blobokban](/roadmap/danksharding/) küldik az Ethereumba. Mivel az összevont tranzakció-lánc végrehajtása a benyújtott tranzakciókon alapul, bárki felhasználhatja ezt az Ethereum alaprétegén tárolt információt az összevont tranzakció státuszának végrehajtásához és a státuszváltozások helyességének ellenőrzéséhez. + +[Az adatelérhetőség](/developers/docs/data-availability/) kritikus fontosságú, mivel a státuszadatokhoz való hozzáférés nélkül azok, akik megkérdőjelezik az eredményt, nem tudnak csalási bizonyítékokat konstruálni az érvénytelen összevont tranzakciós műveletek vitatására. Mivel az Ethereum biztosítja az adatelérhetőséget, csökken annak kockázata, hogy az összevont tranzakció operátorai rosszindulatú cselekményeket követnek el (pl. érvénytelen blokkok beküldése). + +### Cenzúraálló kialakítás {#censorship-resistance} + +Az optimista összevont tranzakciók szintén az Ethereumra támaszkodnak a cenzúrának való ellenállás tekintetében. Egy optimista összevont tranzakció esetében egy centralizált entitás (az operátor) felelős a tranzakciók feldolgozásáért és az összevonttranzakció-blokkok Ethereumba való beküldéséért. Ennek van néhány következménye: + +- az összevont tranzakció operátorai cenzúrázhatják a felhasználókat azáltal, hogy teljesen offline állapotba kerülnek, vagy megtagadják az olyan blokkok előállítását, amelyek bizonyos tranzakciókat tartalmaznak. + +- az összevont tranzakció-operátorai megakadályozhatják, hogy a felhasználók az összevont tranzakciós szerződésben elhelyezett pénzeszközöket kivegyék, azáltal, hogy visszatartják a tulajdonlás Merkle-bizonyítékához szükséges státuszadatokat. A státuszadatok visszatartása az összevont tranzakció státuszát is elrejtheti a felhasználók elől, és megakadályozhatja őket abban, hogy interakcióba lépjenek vele. + +Az optimista összevont tranzakciók úgy oldják meg ezt a problémát, hogy az operátorokat arra kényszerítik, hogy az státuszfrissítésekhez kapcsolódó adatokat közzétegyék az Ethereumon. az összevont tranzakciós adatok láncon történő közzététele a következő előnyökkel jár: + +- Ha egy optimista összevont tranzakció operátora nem elérhető vagy leállítja a tranzakciós kötegek előállítását, egy másik csomópont a rendelkezésre álló adatok segítségével reprodukálhatja az összevont tranzakció utolsó státuszát, és folytathatja a blokkok előállítását. + +- A felhasználók a tranzakciós adatok segítségével Merkle-bizonyítékokat hozhatnak létre, amelyek igazolják a pénzeszközök tulajdonjogát, és kivehetik eszközeiket az összevont tranzakcióból. + +- A felhasználók a szekvenszer helyett az L1-en is benyújthatják tranzakcióikat, ebben az esetben a szekvenszernek egy bizonyos időn belül be kell vonnia a tranzakciót, hogy továbbra is érvényes blokkokat tudjon előállítani. + +### Elszámolás {#settlement} + +Egy másik szerep, amelyet az Ethereum az optimista összevont tranzakciókkal összefüggésben játszik, az elszámolási réteg szerepe. Az elszámolási réteg lehorgonyozza az egész blokklánc-ökoszisztémát, biztonságot teremt, és objektív véglegességet biztosít, ha egy másik láncon (ebben az esetben optimista összevont tranzakción) olyan vita merül fel, amely egyeztetést igényel. + +Az Ethereum főhálózat egy középpontot biztosít az optimista összevont tranzakciók számára a csalási bizonyítékok ellenőrzéséhez és a viták rendezéséhez. Ráadásul az összevont tranzakción végrehajtott tranzakciók csak _azután_ lesznek véglegesek, hogy az összevonttranzakció-blokkot az Ethereum elfogadta. Ha egy összevont tranzakciót egyszer már elkötelezettnek vettek az Ethereum alaprétegén, azt nem lehet visszavonni (kivéve a lánc átszervezésének igen valószínűtlen esetét). + +## Hogyan működnek az optimista összevont tranzakciók? {#how-optimistic-rollups-work} + +### Tranzakcióvégrehajtás és aggregáció {#transaction-execution-and-aggregation} + +A felhasználók tranzakciókat nyújtanak be az operátoroknak, amelyek az optimista összevont tranzakció tranzakcióinak végrehajtását végző csomópontok (node). Az operátor, akit validátornak vagy aggregátornak is nevezhetünk, összesíti a tranzakciókat, tömöríti a mögöttes adatokat, és közzéteszi a blokkot az Ethereumon. + +Habár bárki lehet validátor, az optimista összevont tranzakció validátoroknak kötelezvényt kell adniuk, mielőtt blokkokat állítanak elő, hasonlóan a [letétbe helyezési (proof-of-stake) rendszerhez](/developers/docs/consensus-mechanisms/pos/). Ez a kötelezvény csökkenthető vagy elvehető, ha a validátor érvénytelen blokkot tesz közzé, vagy egy régi, de érvénytelen blokkra épít (még ha a blokkja érvényes is). Az optimista összevont tranzakciók kriptogazdasági ösztönzőket alkalmaznak annak biztosítására, hogy a validátorok becsületesen járjanak el. + +Az optimista összevonttranzakció-lánc többi validátorának a benyújtott tranzakciókat az összevont tranzakció státusza másolatának felhasználásával kell végrehajtaniuk. Ha a validátor végső státusza eltér az operátor által javasolt állapottól, akkor megkérdőjelezheti azt, és kikalkulálhatja a csalási bizonyítékot. + +Bizonyos optimista összevont tranzakciók egy szekvenszert használnak a lánc végrehajtásához, és nem egy engedélymentes validáló rendszert. A szekvenszer a validátorhoz hasonlóan feldolgozza a tranzakciókat, összevonttranzakció-blokkokat hoz létre, és az összevont tranzakciókat az L1 láncba (Ethereum) küldi. + +A szekvencer különbözik a hagyományos rollup-operátortól, mert nagyobb befolyása van a tranzakciók sorrendjére. Emellett a szekvenszer elsőbbségi hozzáféréssel rendelkezik az összevonttranzakció-lánchoz, és ő az egyetlen olyan entitás, amely jogosult tranzakciókat benyújtani a láncon belüli szerződéshez. A nem szekvenszer csomópontoktól vagy a felhasználóktól származó tranzakciók egy külön tárolóban várakoznak, amíg a szekvenszer be nem illeszti azokat egy új kötegbe. + +#### Összevonttranzakció-blokkok beküldése az Ethereumra {#submitting-blocks-to-ethereum} + +Az optimista összevont tranzakció operátora a láncon kívüli tranzakciókat egy kötegbe gyűjti, és elküldi az Ethereumnak hitelesítésre. Ez a folyamat magában foglalja a tranzakciókkal kapcsolatos adatok tömörítését és közzétételét az Ethereumban `calldata` mezőként vagy blobokban. + +A `calldata` az okosszerződésben egy nem módosítható, nem állandó terület, amely a [memóriához](/developers/docs/smart-contracts/anatomy/#memory) hasonlóan viselkedik. A `calldata` a blokklánc [historikus naplóinak](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) részeként fennmarad a láncban, de az Ethereum státusz részeként nem tárolódik. Mivel a `calldata` nem érinti az Ethereum státuszát, ezért olcsóbb, mintha az adatokat a láncban kellene tárolni. + +A `calldata` kulcsszót a Solidityben arra is használják, hogy végrehajtáskor argumentumokat adjanak át egy okosszerződés-függvénynek. A `calldata` azonosítja a tranzakció során meghívott függvényt, és a függvény bemeneteit egy tetszőleges bájtsorozat formájában tartalmazza. + +Az optimista összevont tranzakciók a `calldata`-t arra használják, hogy a tömörített tranzakciós adatokat a láncon belüli szerződéshez küldik. az összevont tranzakció operátora úgy ad be új köteget, hogy az összevont tranzakciós szerződésben szereplő függvényt meghívja és a tömörített adatokat függvényargumentumként átadja. A `calldata` használata csökkenti a felhasználói díjakat, mivel az összevont tranzakciók legtöbb költsége az adatok láncban történő tárolásából származik. + +Itt megtekinthet egy [példát](https://etherscan.io/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) egy összevonttranzakció-köteg benyújtására, mely bemutatja a koncepció működését. A szekvenszer meghívta a `appendSequencerBatch()` metódust, és a tömörített tranzakciós adatokat a `calldata` segítségével adta át bemenetként. + +Néhány összevont tranzakció blobot használ, hogy a tranzakciókötegeket az Ethereumon letárolja. + +A blobok nem módosíthatók és nem állandóak (ahogy a `calldata` is), de kb. 18 nap múlva levágják azokat az előzményadatokról. A blobokkal kapcsolatos további információkért tekintse meg [Danksharding](/roadmap/danksharding) oldalt. + +### Státuszrögzítések {#state-commitments} + +Az optimista összevont tranzakció státusza (számlák, egyenlegek, szerződéskódok stb.) egy [Merkle-fa](/whitepaper/#merkle-trees) vagy státuszfa formájába szerveződik. Ennek a Merkle-fának a gyökerét (státuszgyökér), amely az összevont tranzakció legutóbbi státuszát mutatja, az összevont tranzakciós szerződés hash-eli és tárolja. A láncon minden státuszváltozás egy új összevonttranzakció-státuszt hoz létre, amelyet az operátor egy új státuszgyökér kiszámításával rögzít. + +Az operátornak a kötegek beküldésekor be kell nyújtania a régi és az új státuszgyökereket. Ha a régi státuszgyökér megegyezik a láncon lévő szerződésben lévő státuszgyökérrel, az utóbbit elvetik, és az új státuszgyökérrel helyettesítik. + +az összevont tranzakció operátorának a tranzakcióköteg Merkle-gyökerét is rögzítenie kell. Ez lehetővé teszi, hogy bárki bizonyítsa egy tranzakciónak a kötegbe való felvételét (L1-en) egy [Merkle-bizonyíték](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) bemutatásával. + +Egy optimista összevont tranzakcióban a státuszelköteleződések, különösen a státuszgyökerek szükségesek a státuszváltozások helyességének bizonyításához. az összevont tranzakciós szerződés azonnal elfogadja az új státuszgyökereket az operátoroktól, de később törölheti az érvényteleneket, hogy visszaállítsa az összevont tranzakció helyes állapotát. + +### Csalásbizonyítás {#fraud-proving} + +Az optimista összevont tranzakciók lehetővé teszik bárki számára, hogy blokkokat tegyen közzé az érvényesség igazolása nélkül. Annak érdekében azonban, hogy a lánc biztonságos maradjon, az optimista összevont tranzakciók meghatároznak egy időablakot, amely alatt bárki vitathatja a státuszváltozást. Ezért az összevonttranzakció-blokkokat „állításoknak” nevezik, mivel bárki vitathatja érvényességüket. + +Ha valaki vitatja az állítást, akkor az összevonttranzakció-protokoll elindítja a csalási bizonyíték kiszámítását. A csalási bizonyíték interaktív, valaki közzétesz egy állítást, majd egy másik személy megkérdőjelezi azt. A bizonyítéktípusok eltérhetnek abban, hogy hány körös interakcióra van szükség a csalási bizonyíték kiszámításához. + +Az egykörös interaktív bizonyítási rendszerek újra lejátsszák a vitatott tranzakciókat az L1-en az érvénytelen állítások felderítésére. az összevonttranzakció-protokoll a vitatott tranzakció újbóli végrehajtását versenyezteti az L1-en (Ethereum) egy hitelesítőszerződés segítségével, és a kiszámított státuszgyökér határozza meg, hogy ki nyeri a kihívást. Ha a kihívónak az összevont tranzakció helyes státuszára vonatkozó állítása helytálló, az operátort megbüntetik a kötelezvényének csökkentésével. + +A csalás felderítése érdekében a tranzakciók újbóli végrehajtása az L1-en megköveteli az egyes tranzakciók státuszelköteleződéseinek közzétételét, és növeli a láncban közzéteendő adatok számát. A tranzakciók újrajátszása jelentős gázköltségekkel is jár. Ezen okok miatt az optimista összevont tranzakciók áttérnek a többkörös interaktív bizonyításra, amely az érvénytelen összevonttranzakció-műveletek felderítését hatékonyabban éri el. + +#### Többkörös interaktív bizonyítás {#multi-round-interactive-proving} + +A többfordulós interaktív bizonyítás magában foglal egy oda-vissza kommunikáló protokollt az állító és a kihívó között, amelyet egy L1 hitelesítőszerződés felügyel, és amely végül eldönti, hogy kinek az állítása helytelen. Miután egy L2 csomópont megtámad egy állítást, az állítónak két egyenlő részre kell osztania a vitatott állítást. Ekkor minden állítás ugyanannyi számítási lépést tartalmaz, mint a többi. + +A kihívó ezután kiválasztja, hogy melyik állítást kívánja megtámadni. A felosztási folyamat, vagyis a kettéosztó protokoll addig folytatódik, amíg mindkét fél nem vitatja a végrehajtás _adott_ lépéséről szóló állítást. Ezen a ponton az L1 szerződés megoldja a vitát azzal, hogy kiértékeli az utasítást (és annak eredményét), hogy elkapja a vétkes felet. + +Az állítónak „egylépéses bizonyítékot” kell benyújtania, amely igazolja a vitatott lépés számításának érvényességét. Ha az állító nem tudja megadni az egylépéses bizonyítékot, vagy az L1-ellenőrző érvénytelennek ítéli azt, akkor elveszíti a kihívást. + +Néhány megjegyzés az ilyen típusú csalási bizonyítékról: + +1. A többfordulós interaktív csalási bizonyíték azért hatékony, mert minimálisra csökkenti az L1-lánc által a viták eldöntése során elvégzendő munkát. A teljes tranzakció újrajátszása helyett az L1-nek csak egy lépést kell elvégeznie az összevont tranzakció végrehajtásában. + +2. A kettéosztó protokollok csökkentik a láncban közzétett adatok mennyiségét (nem kell minden tranzakcióhoz státuszváltozást közzétenni). Az optimista összevont tranzakciókat nem korlátozza az Ethereum gázlimitje. Ehhez képest a tranzakciókat újra végrehajtó optimista összevont tranzakcióoknak meg kell győződniük arról, hogy egy L2 tranzakció alacsonyabb gázlimittel rendelkezik, hogy versenyeztetni tudják annak végrehajtását egy Ethereum tranzakción belül. + +3. A rosszhiszemű állító kötelezvényének egy részét a kihívó kapja, míg a másik részét elégetik. Az égetés megakadályozza a validátorok közötti összejátszást; ha két validátor összejátszik, hogy hamis kihívásokat kezdeményezzen, akkor is elveszítik a letét jelentős részét. + +4. A többfordulós interaktív bizonyítás megköveteli, hogy az állító és a kihívó a megadott időkereten belül lépéseket tegyen. Aki a határidő lejárta előtt nem cselekszik, az elveszíti a kihívást. + +#### Miért fontosak a csalási bizonyítékok az optimista összevont tranzakcióknál {#fraud-proof-benefits} + +A csalási bizonyítékok azért fontosak, mert megkönnyítik a _bizalomigény-mentes véglegességet_ az optimista összevont tranzakcióknál. A bizalomigény-mentes véglegesség az optimista összevont tranzakciók olyan tulajdonsága, amely garantálja, hogy egy tranzakció – amennyiben érvényes – végül visszaigazolásra kerül. + +A rosszhiszemű csomópontok hamis megkérdőjelezésekkel megpróbálhatják késleltetni egy érvényes rollup-blokk megerősítését. A csalási bizonyítékok azonban végül igazolni fogják az összevonttranzakció-blokk érvényességét, és megerősítik azt. + +Ez kapcsolódik az optimista összevont tranzakciók egy másik biztonsági tulajdonságához is: a lánc érvényessége azon múlik, hogy legyen (legalább) _egy_ jóhiszemű csomópont. A jóhiszemű csomópont a láncot megfelelően tovább tudja vinni azáltal, hogy érvényes állításokat tesz közzé, vagy vitatja az érvénytelen állításokat. Bárhogy is legyen, a jóhiszemű csomópontokkal vitába szálló rosszhiszemű csomópontok a csalási bizonyíték előállítása során elveszítik letétjeiket. + +### L1/L2 interoperabilitás {#l1-l2-interoperability} + +Az optimista összevont tranzakciókat az Ethereum főhálózattal való interoperabilitásra tervezték, és ezáltal a felhasználók üzeneteket és tetszőleges adatokat továbbíthatnak L1 és L2 között. Az EVM-mel is kompatibilisek, így a meglévő [alkalmazásokat](/developers/docs/dapps/) át lehet vinni az optimista összevont tranzakciókra, vagy új dappokat lehet létrehozni az Ethereum fejlesztői eszközeivel. + +#### 1. Eszközmozgás {#asset-movement} + +##### Belépés az összevont tranzakció-ba + +Egy optimista összevont tranzakció használatához a felhasználók ETH-t, ERC-20 tokeneket és más elfogadott eszközöket helyeznek el az összevont tranzakció [hídjának](/developers/docs/bridges/) szerződésében az L1-en. A hídszerződés továbbítja a tranzakciót az L2-hez, ahol a tranzakcióval megegyező mennyiségű eszközt bocsátanak ki és küldenek a felhasználó által az optimista összevont tranzakción kiválasztott címre. + +A felhasználó által generált tranzakciók (mint például egy L1 > L2 befizetés) bekerülnek a sorba, majd a szekvenszer elküldi azokat az összevont tranzakciós szerződésnek. A cenzúrával szembeni ellenállás megőrzése érdekében azonban az optimista összevont tranzakciók lehetővé teszik a felhasználók számára, hogy közvetlenül a láncon belüli összevont tranzakciós szerződéshez nyújtsanak be egy tranzakciót, ha az egy bizonyos ideig nem kerül feldolgozásra. + +Egyes optimista összevont tranzakciók egyszerűbb megközelítést alkalmaznak annak megakadályozására, hogy a szekvenszerek cenzúrázzák a felhasználókat. Ekkor egy blokkot az L1 szerződéshez az előző blokk óta benyújtott összes tranzakció (pl. befizetések) határoz meg, az összevonttranzakció-láncban feldolgozott tranzakciókon kívül. Ha egy szekvenszer figyelmen kívül hagy egy L1 tranzakciót, akkor (bizonyíthatóan) rossz státuszgyökeret fog közzétenni; ezért a szekvenszerek nem késleltethetik a felhasználó által generált üzeneteket, miután azokat az L1-en közzétették. + +##### Kilépés az összevont tranzakcióból + +Az optimista összevont tranzakcióból az Ethereumra való visszavétel a csalást bizonyító rendszer miatt nehezebb. Ha egy felhasználó L2 > L1 tranzakciót kezdeményez az L1-en letétbe helyezett pénzeszközök kivonására, akkor meg kell várnia, amíg a megkérdőjelezési időszak – amely nagyjából hét napig tart – letelik. Mindazonáltal maga a visszavonási folyamat egyszerű. + +Miután a kifizetési kérelmet az L2 összevont tranzakción kezdeményezték, a tranzakció bekerül a következő kötegbe, miközben a felhasználó összevont tranzakción lévő eszközei elégetésre kerülnek. Miután a köteget közzétették az Ethereumon, a felhasználó kiszámíthatja a Merkle-bizonyítékot, amely igazolja, hogy a kilépési tranzakciója bekerült a blokkba. Ezután csak ki kell várni a késleltetési időszakot, hogy véglegesedjen a tranzakció az L1-en, és kivehesse a pénzt a főhálózatra. + +Annak érdekében, hogy ne kelljen egy hetet várni az Ethereumba történő pénzkivonás előtt, az optimista összevont tranzakció felhasználói alkalmazhatnak egy **likviditási szolgáltatót** (LP). A likviditásszolgáltató átveszi a függőben lévő L2 kivonás tulajdonjogát, és fizet a felhasználónak az L1-en (díj ellenében). + +A likviditásszolgáltatók a pénzeszközök felszabadítása előtt ellenőrizhetik a felhasználó kifizetési kérelmének érvényességét (végrehajtják a láncot). Így biztosítékot kapnak arra, hogy a tranzakciót végül meg fogják erősíteni (a bizalomigény-mentes véglegesség miatt). + +#### 2. EVM-kompatibilitás {#evm-compatibility} + +A fejlesztők számára az optimista összevont tranzakciók előnye az, hogy kompatibilisek – vagy még jobb, hogyha egyenértékűek – a [Ethereum virtuális géppel (EVM)](/developers/docs/evm/). Az EVM-kompatibilis összevont tranzakciók megfelelnek az [Ethereum sárgakönyv](https://ethereum.github.io/yellowpaper/paper.pdf) specifikációinak, és bytecode szinten támogatják az EVM-et. + +Az EVM-kompatibilitás az optimista összevont tranzakcióknál a következő előnyökkel jár: + +i. A fejlesztők az Ethereumon meglévő okosszerződéseket optimista összevont tranzakció-láncokra migrálhatják anélkül, hogy a kódbázisokat nagy mértékben módosítaniuk kellene. Ez időt takaríthat meg a fejlesztőcsapatoknak az Ethereum okosszerződések L2-re történő telepítésekor. + +ii. Az optimista összevont tranzakciókat használó fejlesztők és projektcsapatok kihasználhatják az Ethereum infrastruktúrájának előnyeit. Ide tartoznak a programozási nyelvek, kódkönyvtárak, tesztelési eszközök, kliensszoftverek, telepítési infrastruktúra stb. + +A meglévő eszközök használata azért fontos, mert ezeket az évek során alaposan ellenőrizték és kijavították a hibáikat. Emellett az Ethereum fejlesztőknek nem kell megtanulniuk, hogyan kell egy teljesen új fejlesztői stackkel programot fejleszteni. + +#### 3. Láncok közötti szerződésmeghívások {#cross-chain-contract-calls} + +A felhasználók (külső tulajdonú számlák) úgy lépnek kapcsolatba az L2 szerződésekkel, hogy tranzakciót küldenek az összevont tranzakció-szerződésnek, vagy ugyanezt egy szekvenszerrel vagy validátorral végeztetik el. Az optimista összevont tranzakciók azt is lehetővé teszik, hogy az Ethereumon lévő szerződéses számlák interakcióba lépjenek az L2 szerződésekkel az L1 és L2 közötti üzenetek és adatok továbbítására szolgáló hídszerződések révén. Ez azt jelenti, hogy az Ethereum főhálózaton lévő (L1) szerződést úgy lehet programozni, hogy az L2 optimista összevont tranzakción lévő szerződésekhez tartozó funkciókat hívjon meg. + +A láncközi szerződéses hívások aszinkron módon történnek, vagyis a hívást először kezdeményezik, majd egy későbbi időpontban hajtják végre. Ez eltér az Ethereumon történő, két szerződés közötti hívásoktól, mivel annak azonnali eredménye van. + +A láncközi szerződéskötésre példa a korábban ismertetett token-letétbehelyezés. Az L1-en lévő szerződés letétbe helyezi a felhasználó tokenjeit, és üzenetet küld az L2 szerződésnek, hogy bocsásson ki ugyanannyi tokent az összevont tranzakción. + +Mivel a láncközi üzenethívások szerződésvégrehajtást eredményeznek, a feladónak fedeznie kell a számítás [gázköltségeit](/developers/docs/gas/). Ehhez célszerű magas gázhatárt beállítani, hogy elkerülje a tranzakció meghiúsulását a célláncon. A tokenek híddal való mozgatása jó példa erre, mert ha a tranzakció L1 oldala (a tokenek letétbe helyezése) működik, de az L2 oldal (új tokenek kibocsátása) az alacsony gázmennyiség miatt meghiúsul, a letét behajthatatlanná válik. + +Végül fontos tudni, hogy a szerződések közötti L2 > L1 üzenethívások néhány perc elteltével kerülnek végrehajtásra. Ennek az az oka, hogy az optimista összevont tranzakcióból a főhálózatra küldött üzeneteket nem lehet végrehajtani, amíg a megkérdőjelezési időszak le nem jár. + +## Hogyan működnek az optimista összevont tranzakciós díjak? {#how-do-optimistic-rollup-fees-work} + +Az optimista összevont tranzakciók az Ethereumhoz hasonlóan gázdíjrendszert használnak annak jelölésére, hogy a felhasználók mennyit fizetnek tranzakciónként. Az optimista összevont tranzakciók után felszámított díjak a következő összetevőktől függenek: + +1. **Státuszrögzítés**: Az optimista összevont tranzakciók a tranzakciós adatokat és a blokkfejléceket (amelyek az előző blokkfejléc hash-éből, a státuszgyökérből és a köteggyökérből állnak) `blobként` vagy egy „binárisan nagy objektumként” teszik közzé az Ethereumon. [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) bevezetett egy költséghatékony megoldást az adat láncon belüli tárolására. A `blob` egy új tranzakciós mező, mellyel az összevont tranzakciók képesek tömörített státuszváltozást rögzíteni az Ethereumon (L1). A `calldata` mezőhöz képest, mely állandóan elérhető a láncon, a blobok rövid életűek és levághatók a kliensekről [4096 korszak után](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (kb.18 nappal később). A blobok használatával, melyekbe a tömörített tranzakciós adatok kötegeit teszik, az optimista összevont tranzakciók jelentősen csökkentették annak költségét, hogy a tranzakciók bekerüljenek az L1-re. + +2. A **Blob gázhasználata**: a blobot igénylő tranzakciók egy dinamikus díjmechanizmust használnak, amely hasonlít az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) által bevezetetthez. A 3-as típusú tranzakciók gázdíja egy alap blobdíjjal számol, melyet a hálózat határoz meg a blobhelyre való kereslet és a küldött tranzakció blobhely használata alapján. + +3. **L2 operátordíjak**: Ezt az összevonttranzakció-csomópontnak fizetik a tranzakciók feldolgozása során felmerülő számítási költségek ellentételezéseként, hasonlóan az Ethereum gázdíjaihoz. az összevonttranzakció-csomópontok alacsonyabb tranzakciós díjakat számítanak fel, mivel az L2-k nagyobb feldolgozási kapacitással rendelkeznek, és nincsenek olyan hálózati torlódásaik, amelyek miatt az Ethereum validálói magasabb díjú tranzakciókat részesítenek előnyben. + +Az optimista összevont tranzakciók számos mechanizmust alkalmaznak a felhasználói díjak csökkentésére, beleértve a tranzakciók kötegelését és a `calldata` tömörítését az adatpublikálási költségek csökkentése érdekében. Az [L2 díjkövető](https://l2fees.info/) oldalon valós idejű áttekintést kaphat arról, hogy mennyibe kerül az Ethereum-alapú optimista összevont tranzakciók használata. + +## Hogyan skálázzák az optimista összevont tranzakciók az Ethereumot? {#scaling-ethereum-with-optimistic-rollups} + +Az optimista összevont tranzakciók az adatelérhetőség biztosítása érdekében tömörített tranzakciós adatokat tesznek közzé az Ethereumban. A láncban közzétett adatok tömörítésének képessége alapvető fontosságú ahhoz, hogy az Ethereumon skálázni lehessen a tranzakcióátvitelt az optimista összevont tranzakciókkal. + +Az Ethereum korlátozza, hogy mennyi adatot tartalmazhatnak a blokkok, gázegységekben kifejezve (az [átlagos blokkméret](/developers/docs/blocks/#block-size) 15 millió gáz). Bár ez korlátozza, hogy az egyes tranzakciók mennyi gázt használhatnak fel, azt is jelenti, hogy a tranzakciókhoz kapcsolódó adatok csökkentésével növelhetjük a blokkonként feldolgozott tranzakciók számát, ami közvetlenül javítja a skálázhatóságot. + +Az optimista összevont tranzakciók többféle technikát használnak a tranzakciós adatok tömörítésének elérésére és a másodpercenkénti tranzakciószám (TPS) javítására. Ez a [cikk](https://vitalik.eth.limo/general/2021/01/05/rollup.html) például összehasonlítja, hogy egy egyszerű felhasználói tranzakció (ether küldése) mennyi adatot generál a főhálózaton és az összevont tranzakció-on: + +| Paraméter | Ethereum (L1) | Összevont tranzakció (L2) | +| ------------ | ------------------------- | ------------------------- | +| Nonce | ~3 | 0 | +| Gázár | ~8 | 0–0,5 | +| Gáz | 3 | 0–0,5 | +| Címzett | 21 | 4 | +| Érték | 9 | ~3 | +| Aláírás | ~68 (2 + 33 + 33) | ~0,5 | +| Küldő | 0 (az aláírásból kinyeri) | 4 | +| **Összesen** | **~112 bájt** | **~12 bájt** | + +Néhány hozzávetőleges számítás ezekkel a számokkal segíthet megmutatni az optimista összevont tranzakció által biztosított skálázhatósági javulást: + +1. Az egyes blokkok célmérete 15 millió gáz, és egy bájt adat ellenőrzése 16 gázba kerül. Ha az átlagos blokkméretet elosztjuk 16 gázzal (15 000 000/16), akkor az átlagos blokkba **937 500 bájtnyi adat fér**. +2. Ha egy alap összevont tranzakció 12 bájtot használ, akkor egy átlagos Ethereum-blokk **78 125 összevont tranzakciót** (937 5000/12) vagy **39 összevonttranzakció-köteget** tud feldolgozni (ha minden egyes köteg átlagosan 2000 tranzakciót tartalmaz). +3. Ha az Ethereumon 15 másodpercenként keletkezik egy új blokk, akkor az összevont tranzakció feldolgozási sebessége nagyjából **5208 tranzakciót jelent másodpercenként**. Ez úgy történik, hogy az egy Ethereum-blokkban tárolható alap összevont tranzakciók számát (**78 125**) elosztjuk az átlagos blokkidővel (**15 másodperc**). + +Ez egy meglehetősen optimista becslés, tekintve, hogy az optimista összevont tranzakciók nem tudnak egy teljes blokkot alkotni az Ethereumon. Ugyanakkor nagyjából képet adhat arról, hogy az optimista összevont tranzakciók mekkora skálázhatósági nyereséget biztosíthatnak az Ethereum-felhasználóknak (a jelenlegi implementációk akár 2000 TPS-t is kínálnak). + +Az [adat sharding](/roadmap/danksharding/) bevezetése az Ethereumban várhatóan javítja a skálázhatóságot az optimista összevont tranzakciók esetén. Mivel az összevont tranzakcióknak más, nem összevont tranzakciókkal kell megosztaniuk a blokkteret, feldolgozási kapacitásukat az Ethereum adatátviteli kapacitása korlátozza. A Danksharding növeli az L2 láncok számára rendelkezésre álló helyet az adatok blokkonkénti közzétételéhez, a drága, állandó `CALLDATA` helyett olcsóbb, nem állandó „blob” tárhelyet használva. + +### Az optimista összevont tranzakciók előnyei és hátrányai {#optimistic-rollups-pros-and-cons} + +| Előnyök | Hátrányok | +| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Hatalmas javulást kínál a skálázhatóság terén a biztonság és a megbízhatóság csökkenése nélkül. | A tranzakció véglegesítésének késedelme a lehetséges csalási kihívások miatt. | +| A tranzakciós adatokat az L1-en tárolják, ami javítja az átláthatóságot, a biztonságot, a cenzúrával szembeni ellenállást és a decentralizációt. | A centralizált összevonttranzakció-operátorok (szekvenszerek) befolyásolhatják a tranzakciók sorrendjét. | +| A csalási bizonyíték garantálja a bizalomigény-mentes véglegességet, és lehetővé teszi, hogy kevés jóhiszemű résztvevő is biztosítani tudja a láncot. | Ha nincsenek jóhiszemű csomópontok, egy rosszhiszemű operátor ellophat pénzeszközöket érvénytelen blokkok és státuszelköteleződések közzétételével. | +| A csalási bizonyítékok kiszámítása a hagyományos L2 csomópontok számára is elérhető, ellentétben az érvényességi bizonyításokkal (amelyeket a ZK összevont tranzakciókat használnak), amelyekhez speciális hardverre van szükség. | A biztonsági modellhez szükséges legalább egy jóhiszemű csomópont, amely összevont tranzakciókat hajt végre és csalási bizonyítékokat nyújt be az érvénytelen státuszváltozások megtámadására. | +| az összevont tranzakciók a „bizalomigény-mentes elérhetőség” előnyeit élvezik (bárki működésre kényszerítheti a láncot a tranzakciók végrehajtásával és az állítások elküldésével). | A felhasználóknak meg kell várniuk az egyhetes kihívási időszak lejártát, mielőtt visszavennék a pénzüket az Ethereumba. | +| Az optimista összevont tranzakciók jól megtervezett kriptogazdasági ösztönzőkre támaszkodnak a lánc biztonságának növelése érdekében. | A összevont tranzakcióknak minden tranzakciós adatot a láncban kell közzétenniük, ami növelheti a költségeket. | +| Az EVM-mel és a Solidityvel való kompatibilitás lehetővé teszi a fejlesztők számára, hogy Ethereum-natív okosszerződéseket telepítsenek a összevont tranzakciókba, vagy a meglévő eszközöket használják új dappok létrehozásához. | | + +### Az optimista összevont tranzakciók vizuális bemutatása {#optimistic-video} + +Ön inkább vizuális típus? Nézze meg a videót, melyben a Finematics elmagyarázza az optimista összevont tranzakciók lényegét: + + + +### Optimista összevont tranzakciók használata {#use-optimistic-rollups} + +Az optimista összevont tranzakcióknak többféle megvalósítása létezik, amelyeket integrálhat a dappjaiba: + + + +## További információk az optimista összevont tranzakciókról + +- [Hogyan működnek az optimista összevont tranzakciók (teljes útmutató)](https://www.alchemy.com/overviews/optimistic-rollups) +- [Mi az a blokklánc összevont tranzakció? Technikai bevezetés](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction) +- [Az alapvető útmutató az Arbitrumhoz](https://newsletter.banklesshq.com/p/the-essential-guide-to-arbitrum) +- [Hogyan működik valójában az optimista összevont tranzakció?](https://www.paradigm.xyz/2021/01/how-does-optimisms-rollup-really-work) +- [Az OVM részletes bemutatása](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) +- [Mi az az optimista virtuális gép?](https://www.alchemy.com/overviews/optimistic-virtual-machine) diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" new file mode 100644 index 00000000000..5e53cd5d0bf --- /dev/null +++ "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" @@ -0,0 +1,175 @@ +--- +title: Plazmaláncok +description: Bevezetés a plazmaláncokba, az Ethereum közössége által használt skálázási megoldásba. +lang: hu +incomplete: true +sidebarDepth: 3 +--- + +A plazmalánc egy külön blokklánc, amely az Ethereum főhálózathoz van rögzítve, de a tranzakciókat a láncon kívül hajtja végre, saját blokkvalidálási mechanizmussal. A plazmaláncokat néha „gyerekláncoknak” is nevezik, mivel lényegében az Ethereum főhálózat kisebb másolatai. A plazmaláncok [csalási bizonyítékokat](/glossary/#fraud-proof) használnak (ahogy az [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/)), hogy így döntsék el a vitákat. + +A Merkle-fák lehetővé teszik ezen láncok végtelen halmazának létrehozását, amelyek képesek a szülői láncok (beleértve az Ethereum főhálózatot is) sávszélességének tehermentesítésére. Bár ezek a láncok az Ethereumból merítenek némi biztonságot (csalási bizonyítékokon keresztül), biztonságukat és hatékonyságukat számos tervezési korlát befolyásolja. + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértéséhez érdemes ismernie az alapvető témaköröket és az [Ethereum skálázását](/developers/docs/scaling/). + +## Mi az a plazma? + +A plazma egy keretrendszer a nyilvános blokkláncok, például az Ethereum skálázhatóságának javítására. Az eredeti [plazma fehérkönyv](http://plasma.io/plasma.pdf) leírása szerint a plazmaláncok egy másik blokkláncra (az úgynevezett „gyökérláncra”) épülnek. Minden „gyereklánc” a gyökérláncból indul ki, és általában a szülői láncra telepített okosszerződés kezeli. + +A plazmaszerződés többek között [hídként](/developers/docs/bridges/) működik, amely lehetővé teszi a felhasználók számára az eszközök mozgatását az Ethereum főhálózat és a plazmalánc között. Bár emiatt nagyon hasonlítanak a [mellékláncokhoz](/developers/docs/scaling/sidechains/), a plazmaláncok viszont – bizonyos mértékig – az Ethereum főhálózat biztonságából profitálnak. Ez ellentétben áll a mellékláncokkal, amelyek maguk felelnek a biztonságukért. + +## Hogyan működik a plazma? + +A plazmakeretrendszer alapvető összetevői a következők: + +### Láncon kívüli számítás {#off-chain-computation} + +Az Ethereum jelenlegi feldolgozási sebessége kb. 15–20 tranzakcióra korlátozódik másodpercenként, ami csökkenti annak lehetőségét, hogy rövid távon skálázásható legyen és több felhasználót tudjon kezelni. Ez a probléma elsősorban azért áll fenn, mert az Ethereum [konszenzusmechanizmusa](/developers/docs/consensus-mechanisms/) sok egyenrangú csomópontot igényel a blokklánc státuszváltozásainak ellenőrzéséhez. + +Bár az Ethereum konszenzusmechanizmusa szükséges a biztonsághoz, nem biztos, hogy minden felhasználási esetre alkalmazható. Például ha Alice naponta fizetett Bobnak egy csésze kávét, akkor ezeket az összegeket nem feltétlen kell az egész Ethereum-hálózatnak ellenőriznie, mivel a felek között fennáll némi bizalom. + +A plazma feltételezi, hogy az Ethereum főhálózatának nem kell minden tranzakciót ellenőriznie. Ehelyett a tranzakciókat a főhálózaton kívül is feldolgozhatjuk, így a csomópontoknak nem kell minden tranzakciót hitelesíteniük. + +Láncon kívüli számításra van szükség, hogy a plazmaláncok optimalizálhassák a sebességet és a költségeket. Például a plazmalánc alkalmazhat egy operátort a tranzakciók sorrendjének és végrehajtásának kezelésére – és a legtöbbször így is tesz. Mivel csak egy entitás ellenőrzi a tranzakciókat, a plazmalánc feldolgozási ideje gyorsabb, mint az Ethereum főhálózaté. + +### Státuszrögzítések {#state-commitments} + +Bár a plazma a tranzakciókat a láncon kívül hajtja végre, azok elszámolása az Ethereum fő végrehajtási rétegén történik – ellenkező esetben a plazmaláncok nem élvezhetik az Ethereum biztonsági garanciáit. De a láncon kívüli tranzakciók véglegesítése a plazmalánc státuszának ismerete nélkül megtörné a biztonsági modellt, és lehetővé tenné az érvénytelen tranzakciók elterjedését. Ezért az operátornak, aki a plazmalánc blokkjainak előállításáért felel, rendszeresen közzé kell tennie az Ethereumban a státuszelköteleződéseket. + +Az [elköteleződési séma](https://en.wikipedia.org/wiki/Commitment_scheme) egy olyan kriptográfiai technika, amellyel egy érték vagy állítás mellett elköteleződhetünk anélkül, hogy azt egy másik fél számára felfednénk. Az elköteleződések abban az értelemben köteleznek, hogy nem változtathatja meg az értéket vagy az állítást, ha már elkötelezte magát mellette. A státuszelköteleződések a plazmában Merkle-gyökerek formájában jelennek meg (egy [Merkle-fából](/whitepaper/#merkle-trees)), amelyeket az operátor időközönként elküld a plazmaszerződésnek az Ethereum-láncon. + +A Merkle-gyökerek olyan kriptográfiai primitívek, amelyek lehetővé teszik nagy mennyiségű információ tömörítését. Egy Merkle-gyökér (ebben az esetben „blokkgyökér”) egy blokkban lévő összes tranzakciót képviselhet. A Merkle-gyökerek megkönnyítik annak ellenőrzését is, hogy egy kis adatdarab része-e a nagyobb adathalmaznak. A felhasználó például előállíthat egy [Merkle-bizonyítékot](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content), hogy igazolja, egy tranzakció része egy adott blokknak. + +A Merkle-gyökerek fontosak, hogy az Ethereum számára információt adjanak a láncon kívüli státuszról. A Merkle-gyökerekre úgy is gondolhatunk, mint „mentési pontokra”: az operátor kijelenti, hogy „ez a plazmalánc státusza x időpontban, és ez a Merkle-gyökér a bizonyíték”. Az operátor a Merkle-gyökérrel elköteleződik a plazmalánc _aktuális státuszára_, ezért nevezik státuszelköteleződésnek. + +### Belépés és kilépés {#entries-and-exits} + +Ahhoz, hogy az Ethereum-felhasználók kihasználhassák a plazma előnyeit, szükség van egy olyan mechanizmusra, amely lehetővé teszi a pénzeszközök mozgatását a főhálózat és a plazmaláncok között. Nem küldhetünk tetszőlegesen ethert egy plazmaláncon lévő címre – ezek a láncok nem kompatibilisek, így a tranzakció vagy meghiúsulna, vagy elveszne a pénz. + +A plazma egy Ethereumon futó főszerződést használ a felhasználói belépések és kilépések feldolgozására. Ez a főszerződés felelős a státuszkötelezvények követéséért és a tisztességtelen viselkedés büntetéséért csalási bizonyítékok révén (erről később lesz még szó). + +#### Belépés a plazmaláncba {#entering-the-plasma-chain} + +A plazmaláncba való belépéshez Alice-nek (a felhasználónak) ETH-t vagy bármely ERC-20 tokent kell befizetnie a plazmaszerződésbe. A plazmaoperátor, aki figyeli a szerződésbefizetéseket, létrehoz egy összeget, mely megegyezik Alice kezdeti befizetésével, és felszabadítja azt a plazmaláncban lévő címére. Alice-nak tanúsítania kell, hogy a gyerekláncban megkapta a pénzeszközöket, majd ezeket tranzakciókra használhatja. + +#### Kilépés a plazmaláncból {#exiting-the-plasma-chain} + +A plazmaláncból való kilépés több okból is bonyolultabb, mint a belépés. A legnagyobb nehézség az, hogy bár az Ethereum rendelkezik információkkal a plazmalánc státuszáról, nem tudja ellenőrizni, hogy az információ igaz-e vagy sem. Egy rosszhiszemű felhasználó téves állításokat tehet (például: „van 1000 ETH-em”), és megúszhatja azzal, hogy hamis bizonyítékokkal támasztja alá az állítását. + +A hamis visszavonások megelőzése érdekében „megkérdőjelezési időszakot” vezetnek be. A megkérdőjelezési időszak alatt (általában egy hét) bárki megtámadhat egy kifizetési kérelmet csalási bizonyítékkal. Ha a megkérdőjelezés sikeres, akkor a visszavonási kérelmet elutasítják. + +Általában azonban az a helyzet, hogy a felhasználók őszinték, és helyes állításokat tesznek a tulajdonukban lévő pénzeszközökről. Ebben az esetben Alice kezdeményez egy kivételi kérelmet a gyökérláncon (Ethereum) egy tranzakció benyújtásával a plazmaszerződéshez. + +Emellett egy Merkle-bizonyítékot is be kell nyújtania, amely igazolja, hogy a plazmaláncban a pénzét létrehozó tranzakció bekerült egy blokkba. Erre a Plazma olyan iterációi esetében van szükség, mint például a [plazma MVP](https://www.learnplasma.org/en/learn/mvp.html), amelyek [el nem költött tranzakciós kimenet (UTXO/Unspent Transaction Output)](https://en.wikipedia.org/wiki/Unspent_transaction_output) modellt használnak. + +Mások, mint például a [plazma Cash](https://www.learnplasma.org/en/learn/cash.html), UTXO-k helyett [nem helyettesíthető tokenek (NFT)](/developers/docs/standards/tokens/erc-721/) formájában jelenítik meg a pénzalapokat. A pénzeszköz kivételéhez ebben az esetben a tokenek tulajdonjogának igazolása szükséges a plazmaláncon. Ez úgy történik, hogy a tokent érintő két legutóbbi tranzakciót benyújtja, és Merkle-bizonyítékkal igazolja, hogy ezek a tranzakciók bekerültek egy blokkba. + +A felhasználónak a tisztességes viselkedés garanciájaként a visszavonási kérelemhez biztosítékot is kell adnia. Ha a megkérdőjelező bebizonyítja, hogy Alice visszavonási kérelme érvénytelen, akkor a kötelezvényének értékét csökkentik, és annak egy része jutalomként a megkérdőjelezőhöz kerül. + +Ha a megkérdőjelezési időszak anélkül telik el, hogy valaki csalási bizonyítékot adna, Alice kifizetési kérelme érvényesnek minősül, és lehetővé teszi számára, hogy visszaszerezze a letéteket a plazmaszerződésből az Ethereumon. + +### Vitarendezés {#dispute-arbitration} + +Mint minden blokkláncnak, a plazmaláncoknak is szükségük van egy mechanizmusra a tranzakciók integritásának érvényesítésére, amennyiben a résztvevők rosszindulatúan cselekednek (pl. duplán költik el a pénzt). Ebből a célból a plazmaláncok csalási bizonyítékokat használnak a státuszváltozások érvényességével kapcsolatos viták eldöntésére és a rosszhiszemű viselkedés szankcionálására. A csalási bizonyítékok olyan mechanizmusként szolgálnak, amelyen keresztül egy plazma-gyereklánc panaszt nyújt be a szülői lánchoz vagy a gyökérlánchoz. + +A csalási bizonyíték egy olyan állítás, hogy egy adott státuszváltozás érvénytelen. Például ha egy felhasználó (Alice) kétszer próbálja elkölteni ugyanazt a pénzt. Talán elköltötte az UTXO-t egy tranzakcióban Bobbal, és ugyanazt az UTXO-t (ami most Bobé) egy másik tranzakcióban akarja elkölteni. + +A pénzkivétel megakadályozása érdekében Bob csalási bizonyítékot állít össze, hogy Alice az említett UTXO-t egy korábbi tranzakcióban elköltötte, és Merkle-bizonyítékkal bizonyítja, hogy a tranzakció bekerült egy blokkba. Ugyanez a folyamat működik a plazma Cash-ben is – Bobnak bizonyítania kell, hogy Alice korábban átutalta a tokeneket, amelyeket ki akar venni. + +Ha Bob megkérdőjelezése sikeres, akkor Alice visszavonási kérelmét elutasítják. Ez a megközelítés azonban Bob azon képességére támaszkodik, hogy figyelje a láncot a visszavonási kérelmek tekintetében. Ha Bob offline, akkor Alice feldolgozhatja a rosszhiszemű visszavonást, amint letelik a kihívási időszak. + +## A tömeges kilépési probléma a plazmánál {#the-mass-exit-problem-in-plasma} + +A tömeges kilépés problémája akkor jelentkezik, amikor nagyszámú felhasználó egyszerre próbál kilépni egy plazmaláncból. Hogy miért van ez a probléma, az a plazma egyik legnagyobb problémájával függ össze: az **adatok elérhetetlensége**. + +Az adatelérhetőség azt jelenti, hogy ellenőrizni lehet, hogy egy javasolt blokk információit valóban közzétették-e a blokklánc-hálózaton. Egy blokk „nem elérhető”, ha annak készítője magát a blokkot közzéteszi, de a blokk létrehozásához használt adatokat visszatartja. + +A blokkoknak elérhetőnek kell lenniük, hogy a csomópontok le tudják tölteni a blokkot, és ellenőrizni tudják a tranzakciók érvényességét. A blokkláncok biztosítják az adatok elérhetőségét azáltal, hogy a blokkkészítőket arra kényszerítik, hogy minden tranzakciós adatot a láncban tegyenek közzé. + +Az adatelérhetőség abban is segít, hogy az Ethereum alaprétegére épülő, láncon kívüli skálázási protokollok biztosítva legyenek. Azáltal, hogy az ilyen láncok üzemeltetőit arra kényszerítik, hogy tranzakciós adatokat tegyenek közzé az Ethereumban, bárki megtámadhatja az érvénytelen blokkokat a lánc helyes állapotára hivatkozó csalási bizonyítékokkal. + +A plazmaláncok elsősorban a tranzakciós adatokat tárolják az operátoroknál, és **nem tesznek közzé semmilyen adatot a főhálózaton** (csak időszakos státuszelköteleződéseket). Ez azt jelenti, hogy a felhasználóknak az operátorra kell hagyatkozniuk a blokkadatok biztosításában, ha csalási bizonyítékokat kell létrehozniuk, amelyek megkérdőjelezik az érvénytelen tranzakciókat. Ha ez a rendszer működik, akkor a felhasználók bármikor használhatják a csalási bizonyítékokat a pénzeszközök biztosítására. + +A probléma akkor kezdődik, amikor az operátor, nem pedig felhasználó az, aki rosszhiszeműen cselekszik. Mivel az operátor egyedül irányítja a blokkláncot, nagyobb motivációja lehet arra, hogy érvénytelen státuszváltozást hajtson végre, például ellopják a plazmalánc felhasználóihoz tartozó pénzeszközöket. + +Ebben az esetben a klasszikus csalási bizonyíték rendszere nem működik. Az operátor könnyen elvégezhet egy érvénytelen tranzakciót, amellyel Alice és Bob pénzét átutalja a saját tárcájába, és elrejtheti a csalási bizonyítékhoz szükséges adatokat. Ez azért lehetséges, mert az operátor nem köteles az adatokat a felhasználók vagy a főhálózat rendelkezésére bocsátani. + +Ekkor a legoptimistább megoldás az, ha megkíséreljük a felhasználók „tömeges kilépését” a plazmaláncból. A tömeges kilépés lelassítja a rosszhiszemű üzemeltető pénzlopási tervét, és bizonyos fokú védelmet nyújt a felhasználók számára. A kivételi kérelmek az egyes UTXO-k (vagy tokenek) létrehozásának időpontja alapján kerülnek sorrendbe, ami megakadályozza, hogy a rosszhiszemű operátorok a tisztességes felhasználókat megelőzzék. + +Ennek ellenére továbbra is szükségünk van egy olyan módszerre, amellyel a tömeges kilépés során ellenőrizhetjük a kilépési kérelmek érvényességét, hogy megakadályozzuk, hogy az opportunista egyének kihasználják az érvénytelen kilépéseket feldolgozó káoszt. A megoldás egyszerű: megköveteljük a felhasználóktól, hogy a pénzük kivételéhez **a lánc utolsó érvényes státuszát** tegyék közzé. + +Ennek a megközelítésnek azonban még mindig vannak problémái. Ha például egy plazmalánc összes felhasználójának ki kell lépnie (ami egy rosszhiszemű üzemeltető esetében lehetséges), akkor a plazmalánc teljes érvényes státuszát egyszerre kell kipublikálni az Ethereum alaprétegén. A plazmaláncok tetszőleges mérete (nagy tranzakcióátviel = több adat) és az Ethereum feldolgozási sebességének korlátai miatt ez nem ideális megoldás. + +Bár a kilépési játékok elméletben jól hangzanak, a valós életben a tömeges kilépések valószínűleg az egész hálózatra kiterjedő torlódást fognak okozni az Ethereumban. Amellett, hogy károsítja az Ethereum funkcionalitását, egy rosszul koordinált tömeges kilépés azt jelenti, hogy a felhasználók esetleg nem tudnak pénzt felvenni, mielőtt az operátor lemerít minden számlát a plazmaláncban. + +## A plazma előnyei és hátrányai {#pros-and-cons-of-plasma} + +| Előnyök | Hátrányok | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Nagy átvitelt és tranzakciónként alacsony költséget kínál. | Nem támogatja a számítást (nem tud okosszerződéseket futtatni). Csak alapvető token-átutalások, váltások és egy pár más tranzakciótípus támogatott az elsőrendű logika által. | +| Jól használható tetszőleges felhasználók közötti tranzakciókra (felhasználópárok között nincs költség, ha mindkettő a plazmán van). | A felhasználónak rendszeresen figyelni kell a hálózatot (elérhetőségi követelmény), vagy át kell ruházni ezt a felelősséget másra a pénzeszközök biztonsága érdekében. | +| A plazmaláncok a főlánctól független, speciális felhasználási esetekhez igazíthatók. Bárki, beleértve a vállalkozásokat is, testre szabhatja a plazma-okosszerződéseket, hogy skálázható infrastruktúrát biztosítson, amely különböző kontextusokban működik. | Egy vagy több operátorra támaszkodik az adatok tárolásában és kérésre történő kiszolgálásában. | +| Csökkenti az Ethereum főhálózat terhelését azáltal, hogy a számítást és a tárolást a láncon kívülre helyezi. | A kiutalások több napig is tarthatnak, hogy lehetővé tegyék a megkérdőjelezést vonást. A helyettesíthető eszközök esetében ezt a likviditásszolgáltatók enyhíthetik, de ez tőkeköltséggel jár. | +| | Ha túl sok felhasználó próbál egyszerre kilépni, az Ethereum főhálózat túlterheltté válhat. | + +## A plazma és az L2 skálázási protokollok összehasonlítása {#plasma-vs-layer-2} + +Míg a plazma egykor hasznos skálázási megoldásnak számított az Ethereum számára, azóta a [második blokkláncréteg (L2) skálázási protokollok](/layer-2/) javára elvetették. Az L2 skálázási megoldások a plazma számos problémáját orvosolják: + +### Hatékonyság {#efficiency} + +A [zero-knowledge összevont tranzakciók](/developers/docs/scaling/zk-rollups) kriptográfiai bizonyítékokat generálnak a láncon kívül feldolgozott tranzakciók minden tételének érvényességéről. Ez megakadályozza, hogy a felhasználók (és az operátorok) érvénytelen státuszváltozásokat kezdeményezzenek, így nem relevánsak a megkérdőjelezési időszakok és a kilépési játékok. Ez azt is jelenti, hogy a felhasználóknak nem kell rendszeresen figyelniük a láncot, hogy biztosítsák pénzeszközeiket. + +### Az okosszerződések támogatása {#support-for-smart-contracts} + +A plazma keretrendszer másik problémája az volt, hogy [nem tudta támogatni az Ethereum okosszerződések végrehajtását](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4). Ennek eredményeképpen a plazma legtöbb implementációja többnyire egyszerű fizetésekre vagy ERC-20 tokenek cseréjére készült. + +Ezzel szemben az optimista összevont tranzakciók, kompatibilisek az [Ethereum virtuális géppel](/developers/docs/evm/) és képesek Ethereum-natív [okosszerződések](/developers/docs/smart-contracts/) futtatására, így hasznos és _biztonságos_ megoldást jelentenek a [decentralizált alkalmazások](/developers/docs/dapps/) skálázására. Hasonlóképpen, tervben van az [EVM zero-knowledge implementációjának (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549) létrehozása, amely lehetővé tenné a ZK összevont tranzakciók számára, hogy tetszőleges logikát dolgozzanak fel és okosszerződéseket hajtsanak végre. + +### Az adatok elérhetetlensége {#data-unavailability} + +Amint azt már korábban kifejtettük, a plazmánál az adatelérhetőség nem megoldott. Ha egy rosszhiszemű operátor egy érvénytelen státuszt továbbítana a plazmaláncban, a felhasználók nem tudnák azt megtámadni, mivel az operátor visszatarthatja a csalási bizonyítékhoz szükséges adatokat. Az összevont tranzakciók úgy oldják meg ezt a problémát, hogy az operátoroknak közzé kell tenni a tranzakciós adatokat az Ethereumon, így bárki ellenőrizheti a lánc státuszát, és szükség esetén csalási bizonyítékokat hozhat létre. + +### A tömeges kilépés problémája {#mass-exit-problem} + +A ZK és az optimista összevont tranzakciók a maguk módján oldják meg a plazma tömeges kilépési problémáját. A ZK összevont tranzakció például olyan kriptográfiai mechanizmusokra támaszkodik, amelyek biztosítják, hogy az operátorok semmilyen esetben sem tudják ellopni a felhasználók pénzeszközeit. + +Hasonlóképpen, az optimista összevont tranzakciók késleltetési időszakot írnak elő a pénzkivételre, amely alatt bárki megkérdőjelezheti azt, és megakadályozhatja a rosszhiszemű kivételi kérelmeket. Bár ez hasonló a plazmához, a különbség az, hogy a hitelesítők hozzáférnek a csalási bizonyítékokhoz szükséges adatokhoz. Így a rollup-felhasználóknak nincs szükségük arra, hogy őrült, „elsőként kilépő” migrációba kezdjenek az Ethereum főhálózatra. + +## Miben különbözik a plazma a melléklánctól és a sharding-tól? {#plasma-sidechains-sharding} + +A plazma, a mellékláncok és a sharding hasonlóak, mivel mindannyian valamilyen módon kapcsolódnak az Ethereum főhálózathoz. E kapcsolatok szintje és erőssége azonban eltérő, ami befolyásolja az egyes skálázási megoldások biztonsági tulajdonságait. + +### A plazma és a mellékláncok összehasonlítása {#plasma-vs-sidechains} + +A [melléklánc](/developers/docs/scaling/sidechains/) egy önállóan működtetett blokklánc, amely egy kétirányú hídon keresztül kapcsolódik az Ethereum főhálózathoz. A [hidak](/bridges/) lehetővé teszik a felhasználók számára, hogy tokeneket cseréljenek a két blokklánc között, hogy a mellékláncon tranzakciókat bonyolíthassanak, csökkentve az Ethereum főhálózat zsúfoltságát és javítva a skálázhatóságot. A mellékláncok külön konszenzusmechanizmust használnak, és jellemzően sokkal kisebbek, mint az Ethereum főhálózat. Ennek eredményeképpen az eszközök áthidalása ezekbe a láncokba fokozott kockázatot jelent; az Ethereum főhálózatból örökölt biztonsági garanciák hiánya miatt az melléklánc-modellben a felhasználók a pénzeszközök elvesztését kockáztatják a mellékláncot érő támadás során. + +Ezzel szemben a plazmaláncok a főhálózatból merítik biztonságukat. Ez mérhetően biztonságosabbá teszi őket, mint a mellékláncokat. Mind a mellékláncok, mind a plazmaláncok különböző konszenzusprotokollokkal rendelkezhetnek, de a különbség az, hogy a plazmaláncok minden egyes blokkhoz Merkle-gyökereket tesznek közzé az Ethereum főhálózaton. A blokkgyökerek olyan kis információdarabok, amelyek segítségével ellenőrizhetjük a plazmaláncban zajló tranzakciókkal kapcsolatos információkat. Ha egy plazmaláncot támadás ér, a felhasználók a megfelelő bizonyítékok segítségével biztonságosan kivehetik pénzüket a főhálózatra. + +### A plazma és a sharding összehasonlítása {#plasma-vs-sharding} + +Mind a plazmaláncok, mind a shard-láncok rendszeresen közzéteszik a kriptográfiai bizonyítékokat az Ethereum főhálózatra. Azonban eltérő biztonsági tulajdonságokkal rendelkeznek. + +A shard-láncok „összevont fejléceket” küldenek a főhálózatnak, amelyek részletes információkat tartalmaznak az egyes adat-shardról. A főhálózat csomópontjai ellenőrzik és érvényesítik az adat-shardok érvényességét, csökkentve ezzel az érvénytelen shard-változások lehetőségét és védve a hálózatot a rosszindulatú tevékenységektől. + +A plazma azért más, mert a főhálózat csak minimális információt kap a gyerekláncok státuszáról. Ez azt jelenti, hogy a főhálózat nem tudja hatékonyan ellenőrizni a gyerekláncokon végrehajtott tranzakciókat, így azok kevésbé biztonságosak. + +**Fontos megjegyezni**, hogy az Ethereum blokklánc ütemtervében már nem szerepel a sharding. Ezt felváltotta a rollupok-on keresztül történő skálázás és a [Danksharding](/roadmap/danksharding). + +### A plazma használata {#use-plasma} + +Több projekt is kínál olyan plazmaimplementációkat, amelyeket Ön is beépíthet a dappjaiba: + +- [Polygon](https://polygon.technology/) (korábban Matic Network) + +## További olvasnivaló {#further-reading} + +- [Ismerje meg a plazmát](https://www.learnplasma.org/en/) +- [Gyors emlékeztető arról, hogy mit jelent a „megosztott biztonság” és miért olyan fontos ez a fogalom](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) +- [A mellékláncok, a plazma és a sharding összehasonlítása](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) +- [A plazma megértése, 1. rész: Az alapok](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) +- [A plazma élete és halála](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) + +_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" new file mode 100644 index 00000000000..1f92c6f05e6 --- /dev/null +++ "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" @@ -0,0 +1,73 @@ +--- +title: Mellékláncok +description: Bevezetés a mellékláncokba, az Ethereum közössége által használt skálázási megoldásba. +lang: hu +sidebarDepth: 3 +--- + +A melléklánc egy különálló blokklánc, amely az Ethereum hálózatától függetlenül működik, és az Ethereum főhálózatához egy kétirányú híddal csatlakozik. A mellékláncoknak eltérő blokkparaméterei és [konszenzusalgoritmusai](/developers/docs/consensus-mechanisms/) lehetnek, melyeket a tranzakciók hatékonyabb feldolgozására terveztek. A mellékláncok használata azonban kompromisszumokkal jár, mivel azok nem rendelkeznek az Ethereumra jellemző biztonsági tulajdonságokkal. A [második blokkláncréteg (L2) skálázási megoldásaival](/layer-2/) ellentétben a mellékláncok nem rögzítik állapotváltozásaikat és tranzakciós adataikat az Ethereum főhálózatán. + +A mellékláncok bizonyos mértékben feláldozzák decentralizáltságukat vagy biztonságukat, hogy nagyobb tranzakcióátvitelt érjenek el ([skálázhatósági trilemma](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). Az Ethereum azonban elkötelezett a skálázási megoldások mellett, anélkül hogy kompromisszumot kötne a decentralizáció és biztonság terén, ahogy azt a [vízió megfogalmazása](/roadmap/vision/) is mutatja a fejlesztésekre vonatkozóan. + +## Hogyan működnek a mellékláncok? {#how-do-sidechains-work} + +A mellékláncok független blokkláncok, eltérő történetekkel, fejlesztési tervekkel és tervezési megoldásokkal. Bár egy mellékláncnak a felszínen lehet néhány hasonlósága az Ethereummal, számos sajátossággal rendelkezik. + +### Konszenzusalgoritmus {#consensus-algorithms} + +A mellékláncokat egyedivé (Ethereumtól eltérővé) tevő egyik tulajdonság az alkalmazott konszenzusalgoritmus. Konzenzus tekintetében a mellékláncok nem támaszkodnak az Ethereumra, hanem az igényeiknek megfelelő alternatív konzenzusprotokollt választhatnak. Néhány példa a mellékláncokon alkalmazott konszenzusalgoritmusokra: + +- [Proof-of-authority (jogosultsági igazolás)](/developers/docs/consensus-mechanisms/poa/) +- [Delegált proof-of-stake (letéti igazolás)](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) +- [Bizánci hibatűrés](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained). + +Az Ethereumhoz hasonlóan a mellékláncok is rendelkeznek validáló csomópontokkal, amelyek ellenőrzik és feldolgozzák a tranzakciókat, blokkokat állítanak elő, és tárolják a blokklánc állapotát. A validátorok felelősek a konszenzus fenntartásáért a hálózaton belül és a rosszindulatú támadások elleni védelemért is. + +#### Blokkparaméterek {#block-parameters} + +Az Ethereum korlátozza a [blokkidőt](/developers/docs/blocks/#block-time) (azaz az új blokkok létrehozásához szükséges időt) és a [blokkméretet](/developers/docs/blocks/#block-size) (azaz a blokkokban tárolt adat mennyiségét gázban kifejezve). A mellékláncok ezzel szemben más paramétereket alkalmaznak, mint a gyorsabb blokkidők vagy a magasabb gázkorlátozások, annak érdekében, hogy nagyobb teljesítményt, gyorsabb tranzakciókat és alacsonyabb díjakat érjenek el. + +Habár ez bizonyos előnyökkel jár, kritikus következményei lehetnek a hálózat decentralizáltságát és biztonságát illetően. Az olyan blokkparaméterek, mint az alacsony blokkidők és a nagy blokkméretek növelik egy teljes csomópont fenntartásának nehézségeit, ami miatt csak néhány „szupercsomópont” felelhet a lánc biztonságáért. Egy ilyen forgatókönyv esetén megnő a validátorok összejátszásának vagy a lánc rosszindulatú átvételének lehetősége. + +Ahhoz, hogy a blokkláncok a decentralizáció csökkenése nélkül skálázódhassanak, a csomópontok működtetésének mindenki számára elérhetőnek kell lennie, nem csak a speciális hardverrel rendelkezőknek. Ezért folynak erőfeszítések annak biztosítására, hogy mindenki [futtasson egy teljes csomópontot](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) az Ethereum hálózaton. + +### EVM-kompatibilitás {#evm-compatibility} + +Egyes mellékláncok EVM-kompatibilisek, és képesek az [Ethereum virtuális gépre (EVM)](/developers/docs/evm/) fejlesztett szerződések végrehajtására. Az EVM-kompatibilis mellékláncok támogatják azokat az okosszerződéseket, melyeket [Solidity](/developers/docs/smart-contracts/languages/) vagy más EVM okosszerződés nyelveken írtak, tehát az Ethereum főhálózatra írt okosszerződések az EVM-kompatibilis mellékláncokon is működnek. + +Ha Ön a [dappját](/developers/docs/dapps/) egy mellékláncban szeretné használni, akkor csak az [okosszerződést](/developers/docs/smart-contracts/) kell telepíteni erre a mellékláncra. Úgy néz ki, olyan érzés, és úgy is működik, mint a főhálózat – a szerződéseket Solidityben írja, és a melléklánc RPC-jén keresztül lép kapcsolatba a lánccal. + +Mivel a mellékláncok EVM-kompatibilisek, hasznos [skálázási megoldásnak](/developers/docs/scaling/) számítanak az Ethereum-natív dappok számára. Ha a dapp egy mellékláncon van, a felhasználók alacsonyabb gázdíjakat és gyorsabb tranzakciókat élvezhetnek, különösen akkor, ha a főhálózat túlterhelt. + +Ugyanakkor a melléklánc használata jelentős kompromisszumokkal jár. Minden melléklánc maga felel a biztonságáért, és nem örökli az Ethereum biztonsági tulajdonságait. Ez növeli a rosszindulatú viselkedés lehetőségét, ami hatással lehet a felhasználókra vagy veszélyeztetheti pénzeszközeiket. + +### Eszközmozgás {#asset-movement} + +Ahhoz, hogy egy különálló blokklánc az Ethereum főhálózat mellékláncává váljon, kezelnie kell az eszközök átutalását az Ethereum főhálózatról el és vissza. Az Ethereummal való átjárhatóságot egy blokklánchíd segítségével érik el. A [hidak](/bridges/) az Ethereum főhálózatra telepített okosszerződéseket és egy mellékláncot használnak az alapok közötti áthidalásokra. + +Bár a hidak segítségével a felhasználók pénzeszközöket mozgathatnak az Ethereum és a melléklánc között, az eszközök fizikailag nem mozognak a két lánc között. Ehelyett olyan mechanizmusokat használnak a láncok közötti értékátvitelre, amelyek jellemzően kibocsátással és égetéssel járnak. További információ a [hidakról](/developers/docs/bridges/#how-do-bridges-work). + +## A mellékláncok előnyei és hátrányai {#pros-and-cons-of-sidechains} + +| Előnyök | Hátrányok | +| ---------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| A mellékláncok alapjául szolgáló technológia jól megalapozott, és kiterjedt kutatás és tervezési fejlesztések eredménye. | A mellékláncok a decentralizáció és a bizalomigény-mentesség bizonyos mértékét a skálázhatóságra cserélik. | +| A mellékláncok támogatják az általános számításokat és EVM-kompatibilitást kínálnak (Ethereum-natív dappokat futtathatnak). | Egy melléklánc külön konszenzusmechanizmust használ, és nem részesül az Ethereum biztonsági garanciáiból. | +| A mellékláncok különböző konszenzusmodelleket használnak a tranzakciók hatékony feldolgozása és a felhasználók tranzakciós díjainak csökkentése érdekében. | A mellékláncok magasabb szintű bizalmi feltételezést igényelnek (például a rosszindulatú melléklánc-validátorok határozatképes csoportja csalást követhet el). | +| Az EVM-kompatibilis mellékláncok lehetővé teszik a dappok számára, hogy bővítsék az ökoszisztémájukat. | | + +### Mellékláncok használata {#use-sidechains} + +Több projekt is kínál olyan melléklánc-implementációkat, amelyeket Ön is beépíthet a dappjaiba: + +- [Polygon PoS](https://polygon.technology/solutions/polygon-pos) +- [Skale](https://skale.network/) +- [Gnosis Chain (korábban xDai)](https://www.gnosischain.com/) +- [Loom Network](https://loomx.io/) +- [Metis Andromeda](https://www.metis.io/) + +## További olvasnivaló {#further-reading} + +- [Ethereum dappok skálázása mellékláncokkal](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _2018. február 8. – Georgios Konstantopoulos_ + +_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" new file mode 100644 index 00000000000..257a88b9257 --- /dev/null +++ "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" @@ -0,0 +1,67 @@ +--- +title: Státuszcsatornák +description: Bevezetés a státusz- és fizetési csatornákba, az Ethereum közössége által használt skálázási megoldásba. +lang: hu +sidebarDepth: 3 +--- + +A státuszcsatornák lehetővé teszik a résztvevők számára, hogy biztonságosan tranzakciókat bonyolítsanak le a láncon kívül, miközben minimálisra csökkentik az Ethereum főhálózattal való interakciót. A csatornát alkotó résztvevők tetszőleges számú, a láncon kívüli tranzakciót hajthatnak végre, melyhez csak két láncon belüli tranzakciót kell beküldeniük csatorna megnyitásához és lezárásához. Ez rendkívül nagy tranzakcióátvitelt tesz lehetővé, és alacsonyabb költségeket eredményez a felhasználók számára. + +## {#how-do-sidechains-work} + +A nyilvános blokkláncok, mint például az Ethereum, az elosztott architektúrájuk miatt skálázhatósági kihívásokkal küzdenek: a láncban végrehajtott tranzakciókat az összes csomópontnak végre kell hajtania. A csomópontoknak képesnek kell lenniük arra, hogy egy blokkban lévő tranzakciók mennyiségét szerény hardverrel kezeljék, hogy a hálózat decentralizált maradjon, de ez korlátozza a tranzakcióátviteli sebességet. + +### {#consensus-algorithms} + +A csatornák olyan egyszerű társközi (peer-to-peer) protokollok, amelyek lehetővé teszik, hogy két fél számos tranzakciót hajtson végre egymás között, és csak a végeredményt tegyék fel a blokkláncra. A csatorna kriptográfiát használ annak bizonyítására, hogy az általuk generált összesített adatok valóban érvényes köztes tranzakciók eredményei. Egy [több aláírásos](/developers/docs/smart-contracts/#multisig) okosszerződés biztosítja, hogy a tranzakciókat a megfelelő felek írják alá. + +- []() +- []() +- + +A csatornák segítségével a státuszváltozásokat az érdekelt felek hajtják végre és érvényesítik, minimalizálva az Ethereum végrehajtási rétegének számításait. Ez csökkenti a torlódásokat az Ethereumon, és növeli a tranzakciók feldolgozási sebességét a felhasználók számára. + +#### {#block-parameters} + +Minden csatornát egy [több aláírásos okosszerződés](/developers/docs/smart-contracts/#multisig) kezel, amely az Ethereumon fut. Egy csatorna megnyitásához a résztvevők telepítik a csatornaszerződést a láncban, és pénzt helyeznek el benne. + +A csatorna lezárásához a résztvevők elküldik a csatorna utolsó elfogadott státuszát a láncba. Ezt követően az okosszerződés a zárolt pénzeszközöket az egyes résztvevőknek a csatorna végső státuszában lévő egyenlege szerint osztja szét. + +A peer-to-peer csatornák különösen hasznosak olyan helyzetekben, amikor néhány előre meghatározott résztvevő nagy gyakorisággal kíván tranzakciókat lebonyolítani anélkül, hogy az többletterhekkel járna. A blokklánc-csatornák két kategóriába sorolhatók: **fizetési** és **státuszcsatornák**. + +### {#evm-compatibility} + +A fizetési csatornát leginkább úgy lehet leírni, mint két felhasználó által közösen vezetett „kétirányú főkönyvet”. A főkönyv kezdeti egyenlege a csatornanyitási fázisban a láncban lévő szerződésbe zárolt betétek összege. + +A főkönyv egyenlegének (azaz a fizetési csatorna státuszának) frissítéséhez a csatorna összes résztvevőjének jóváhagyása szükséges. A csatorna résztvevői által aláírt csatornaváltozás véglegesítettnek tekinthető, hasonlóan az Ethereumban végrehajtott tranzakciókhoz. + +A fizetési csatornák a legkorábbi skálázási megoldások közé tartoztak, amelyek célja az egyszerű felhasználói interakciók (pl. ETH átutalások, atomikus átváltások, mikrofizetések) költséges láncon belüli tevékenységének minimalizálása volt. A csatorna résztvevői korlátlan mennyiségű azonnali, illeték nélküli tranzakciót hajthatnak végre egymás között mindaddig, amíg az átutalások nettó összege nem haladja meg a letétbe helyezett tokeneket. + +A láncon kívüli fizetések támogatásán kívül a fizetési csatornák nem bizonyultak hasznosnak az általános státuszváltozási logika kezelésére. A státuszcsatornákat azért hozták létre, hogy megoldják ezt a problémát, és azok támogassák az általános célú számítások skálázását. + +### {#asset-movement} + +A státuszcsatornáknak sok közös vonásuk van a fizetési csatornákkal. A felhasználók például kriptográfiailag aláírt üzenetek (tranzakciók) cseréjével lépnek kapcsolatba egymással, amelyeket a csatorna többi résztvevőjének is alá kell írnia. Ha egy javasolt státuszváltozást nem ír alá minden résztvevő, az érvénytelennek minősül. + +## {#pros-and-cons-of-sidechains} + +| | | +| | | +| | | +| | | +| | | +| | | + +### {#use-sidechains} + +- []() +- []() +- []() +- []() +- []() + +## {#further-reading} + +- + +_ _ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" new file mode 100644 index 00000000000..696bd6c534c --- /dev/null +++ "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" @@ -0,0 +1,165 @@ +--- +title: Validium +description: Bevezetés a validiumba, az Ethereum közössége által használt skálázási megoldásba. +lang: hu +sidebarDepth: 3 +--- + +A validium egy [skálázási megoldás](/developers/docs/scaling/), amely érvényességi bizonylatok, például [ZK összevont tranzakciók](/developers/docs/scaling/zk-rollups/) segítségével érvényesíti a tranzakciók integritását, de nem tárolja a tranzakciós adatokat az Ethereum főhálózaton. Bár a láncon kívüli adatok elérhetősége kompromisszumokat eredményez, a skálázhatóság terén hatalmas javulást jelent (a validiumok másodpercenként [kb. 9000 tranzakciót vagy annál többet is képesek feldolgozni](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)). + +## Előfeltételek {#prerequisites} + +Érdemes áttekinteni az [Ethereum skálázásról](/developers/docs/scaling/) és [L2 megoldásokról](/layer-2) szóló oldalakat. + +## Mi az a validium? {#what-is-validium} + +A validiumok olyan skálázási megoldások, amelyek az Ethereum főhálózaton kívüli adatelérhetőséget és számítást használnak, és láncon kívül dolgozzák fel a tranzakciókat, így javítva a tranzakcióátvitelt. A zero-knowledge összevont tranzakciókhoz hasonlóan a validiumok is [zero-knowledge bizonyítékokat](/glossary/#zk-proof) tesznek közzé az Ethereumon kívüli tranzakciók ellenőrzésére. Ez megakadályozza az érvénytelen státuszváltozásokat, és növeli a validiumlánc biztonsági garanciáit. + +Ezek az érvényességi bizonyítékok ZK-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, vagyis zero-knowledge tömörített nem interaktív érv ismeretre) vagy ZK-STARK (Zero-Knowledge Scalable Transparent Argument of Knowledge, vagyis zero-knowledge skálázható transzparens érv ismeretre) formájában érkezhetnek. Bővebben a [zero-knowledge bizonyítékokról](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/). + +A validium-felhasználók pénzeszközeit egy Ethereum-alapú okosszerződés ellenőrzi. A validiumok a ZK összevont tranzakciókhoz hasonlóan szinte azonnali kifizetéseket kínálnak; miután a főhálózat ellenőrizte a kifizetési kérelem érvényességi bizonyítékát, a felhasználók [Merkle-bizonyítékok](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) benyújtásával tudnak pénzt felvenni. A Merkle-bizonyíték igazolja, hogy a felhasználó kifizetési tranzakciója bekerült egy ellenőrzött tranzakciókötegbe, így a láncon belüli szerződés feldolgozhatja a kifizetést. + +A validium felhasználók azonban befagyaszthatják pénzeszközeiket és korlátozhatják a pénzfelvételt. Ez akkor fordulhat elő, ha a validiumlánc adatelérhetőség-kezelői visszatartják a felhasználók elől a láncon kívüli állapotadatokat. A tranzakciós adatokhoz való hozzáférés nélkül a felhasználók nem tudják előállítani a pénzeszközök tulajdonjogának bizonyításához, illetve a kifizetések végrehajtásához szükséges Merkle-bizonyítékot. + +Ez a fő különbség a validiumok és a ZK összevont tranzakciók között, vagyis az adatelérhetőség spektrumán máshol helyezkednek el. Mindkét megoldás másképp közelíti meg az adattárolást, ami kihat a biztonságra, illetve a bizalomigény-mentességre. + +## Miként működnek együtt a validiumok az Ethereummal? {#how-do-validiums-interact-with-ethereum} + +A validiumok a meglévő Ethereum-láncra épülő skálázási protokollok. Bár a tranzakciókat a láncon kívül hajtja végre, a validium láncot a főhálózatra telepített okosszerződések gyűjteménye kezeli, beleértve a következőket is: + +1. **Hitelesítői szerződés**: A hitelesítői szerződés ellenőrzi a validium-üzemeltető által az státuszfrissítésekre benyújtott bizonylatok érvényességét. Ez két dolgot fed le a láncon kívül történő végrehajtással kapcsolatban: a tranzakciók helyességét igazoló érvényességi bizonyítékot és a tranzakciós adatok meglététről szóló adatelérhetőségi bizonyítékot. + +2. **Főszerződés**: A főszerződés tárolja a blokképítő által benyújtott státusz elköteleződést (Merkle-gyökerek), és frissíti a validium státuszát, amint egy érvényességi bizonyítékot a láncban ellenőriznek. Ez a szerződés kezeli a validiumláncba történő befizetéseket és az onnan történő kivonásokat is. + +A validiumok a fő Ethereum-láncra támaszkodnak a következő területeken is: + +### Elszámolás {#settlement} + +A validiumon végrehajtott tranzakciókat nem lehet teljes mértékben megerősíteni, amíg a szülőlánc nem ellenőrzi érvényességüket. Minden validiumon lebonyolított ügyletet végül a főhálózaton kell elszámolni. Az Ethereum-blokklánc „elszámolási garanciákat” is nyújt a validium-felhasználók számára, ami azt jelenti, hogy a láncot elhagyó tranzakciókat nem lehet visszafordítani vagy megváltoztatni, miután a láncba bevitték őket. + +### Biztonság {#security} + +Az Ethereum, mint elszámolási réteg, szintén garantálja az státuszváltozások érvényességét a validiumon. A validiumláncon végrehajtott, láncon kívüli tranzakciókat az Ethereum alaprétegén lévő okosszerződésen keresztül ellenőrzik. + +Ha a láncon belüli hitelesítő szerződés érvénytelennek ítéli a bizonyítékot, a tranzakciókat elutasítja. Ez azt jelenti, hogy az operátoroknak meg kell felelniük az Ethereum-protokoll által kikényszerített érvényességi feltételeknek, mielőtt frissítenék a validium státuszát. + +## Hogyan működik a validium? {#how-does-validium-work} + +### Tranzakciók {#transactions} + +A felhasználók tranzakciókat nyújtanak be az operátornak, amely egy csomópont, és ez felel a validiumlánc tranzakcióinak végrehajtásáért. Egyes validiumok egyetlen operátort használnak a lánc végrehajtására, vagy támaszkodhatnak egy [proof-of-stake (PoS)](/developers/docs/consensus-mechanisms/pos/) mechanizmusra is az operátorok rotációja érdekében. + +Az operátor a tranzakciókat egy kötegbe tömöríti, és a bizonyításhoz elküldi egy bizonyító programnak (circuit). A bizonyító program elfogadja a tranzakciós köteget (és más releváns adatokat) bemenetként, és kiad egy érvényességi bizonyítékot, amely igazolja a műveleteket helyes végrehajtását. + +### Státuszrögzítések {#state-commitments} + +A validium státuszát egy Merkle-fa formájában hash-elik, amelynek gyökere az Ethereum fő szerződésben van tárolva. A Merkle- vagy státuszgyökér a validiumon lévő számlák és egyenlegek aktuális státuszára vonatkozó kriptográfiai kötelezettségvállalás. + +A státuszfrissítéshez az operátornak ki kell számítania a tranzakciók végrehajtása utáni új státuszgyökeret, és el kell küldenie azt a láncon belüli szerződésnek. Ha az érvényesség igazolása rendben van, a javasolt státusz elfogadásra kerül, és a validium átvált az új gyökérstátuszra. + +### Letét elhelyezése és kivétele {#deposits-and-withdrawals} + +A felhasználók ETH-t (vagy bármely ERC-kompatibilis tokent) helyeznek letétbe a láncon belüli szerződésben, így tudnak pénzeszközt mozgatni az Ethereumról egy validiumba. A szerződés közvetíti a letéti eseményt a validiumnak a láncon kívülre, ahol a felhasználó címére jóváírják a letétnek megfelelő összeget. Az operátor ezt a befizetési tranzakciót is egy új kötegbe foglalja. + +A pénzeszközök főhálózatra történő visszautalásához a validium felhasználó kezdeményez egy kifizetési tranzakciót, és elküldi azt az operátornak, aki érvényesíti a kifizetési kérelmet, és felveszi azt egy kötegbe. A felhasználó validiumláncban lévő eszközei megsemmisülnek, mielőtt kiléphetnének a rendszerből. Miután a köteghez kapcsolódó érvényességi bizonyítékot ellenőrizték, a felhasználó meghívhatja a fő szerződést, hogy kivegye a befizetésének a fennmaradó részét. + +A validiumprotokoll cenzúraellenes mechanizmusként lehetővé teszi a felhasználók számára, hogy közvetlenül a validiumszerződésből lépjenek ki, anélkül hogy az operátoron keresztül mennének. Ebben az esetben a felhasználóknak Merkle-bizonyítékot kell szolgáltatniuk a hitelesítő szerződésnek, amely igazolja, hogy a fiók szerepel a státuszgyökérben. Ha a bizonyítékot elfogadják, a felhasználó meghívhatja a fő szerződés visszavonási funkcióját, hogy kivegye a pénzét a validiumból. + +### Kötegbenyújtás {#batch-submission} + +A tranzakcióköteg végrehajtása után az operátor benyújtja a kapcsolódó érvényességi bizonyítékot a hitelesítői szerződésnek, és új státuszgyökeret javasol a főszerződésnek. Ha a bizonylat érvényes, a főszerződés frissíti a validium státuszát, és véglegesíti a kötegben lévő tranzakciók eredményeit. + +A ZK összevont tranzakciókkal ellentétben a validium blokkgyártóinak nem kell közzétenniük a kötegek tranzakciós adatait (csak a blokkfejléceket). Ez teszi a validiumot egy tisztán láncon kívüli skálázási protokollá, szemben a „hibrid” megoldásokkal ([L2](/layer-2/)), amelyek a státuszadatokat `calldata` formájában közzéteszik a fő Ethereum-láncon. + +### Adatelérhetőség {#data-availability} + +A validiumok láncon kívüli adatelérhetőségi modellt használnak, ahol az operátorok az összes tranzakciós adatot az Ethereum főhálózaton kívül tárolják. A validium alacsony láncon belüli adatlábnyoma javítja a skálázhatóságot (a tranzakcióátvitelt nem korlátozza az Ethereum adatfeldolgozási kapacitása) és csökkenti a felhasználói díjakat (a `calldata` közzétételének költsége alacsonyabb). + +A láncon kívüli adatelérhetőség azonban problémát jelent: a Merkle-bizonyítékok létrehozásához vagy ellenőrzéséhez szükséges adatok nem állnak rendelkezésre. Ez azt jelenti, hogy a felhasználók nem tudnak pénzeszközt kivenni a láncon belüli szerződésből, ha az operátorok rosszhiszeműen cselekszenek. + +Számos validiummegoldás a státuszadatok tárolásának decentralizálásával próbálja megoldani ezt a problémát. Ez azt jelenti, hogy a blokkgyártókat arra kényszerítik, hogy a mögöttes adatokat elküldjék az „adatelérhetőség-kezelőknek”, akik felelősek a láncon kívüli adatok tárolásáért, és kérésre a felhasználók rendelkezésére bocsátják azokat. + +A validiumban az adatelérhetőség kezelői minden validiumköteg aláírásával tanúsítják az adatelérhetőséget a láncon kívüli tranzakciókhoz. Ezek az aláírások egyfajta „rendelkezésre állási bizonyítékot” jelentenek, amelyet a láncon lévő hitelesítői szerződés a státuszfrissítések jóváhagyása előtt ellenőriz. + +A validiumok eltérnek egymástól az adatelérhetőség kezelési módjában. Egyesek megbízható felekre támaszkodnak a státuszadatok tárolásában, míg mások véletlenszerűen kijelölt validátorokat használnak erre. + +#### Adatelérhetőségi bizottság (DAC) {#data-availability-committee} + +A láncon kívüli adatok elérhetőségének garantálása érdekében egyes validium-megoldások megbízható résztvevők egy csoportját, az úgynevezett adatelérhetőségi bizottságot (DAC) jelölik ki a státuszmásolat tárolására és az adatelérhetőség igazolására. A DAC-k könnyebben megvalósíthatók és kevesebb koordinációt igényelnek, mivel a taglétszám alacsony. + +A felhasználóknak azonban meg kell bízniuk a DAC-ben, hogy szükség esetén rendelkezésre bocsátja az adatokat (például a Merkle-bizonyítékok generálásához). Fennáll annak a lehetősége, hogy az adatelérhetőségi bizottságok [tagjait egy rosszindulatú szereplő megtámadja](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view), aki aztán visszatartja a láncon kívüli adatokat. + +[Bővebben az adatelérhetőségi bizottságokról a validiumokban](https://medium.com/starkware/data-availability-e5564c416424). + +#### Kötelezvényalapú adatelérhetőség {#bonded-data-availability} + +Más validiumok megkövetelik azoktól a résztvevőktől, akik az offline adatok tárolásáért felelnek, hogy feladatuk megkezdése előtt letétbe tegyenek (zároljanak) bizonyos értékű tokent egy okosszerződésben. Ez a letét „kötelezvényként” szolgál, amely garantálja az adatelérhetőség kezelőinek tisztességes viselkedését, és csökkenti a bizalmi feltételezéseket. Ha ezek a résztvevők nem bizonyítják az adatelérhetőséget, a kötelezvényt lecsökkentik. + +A kötelezvényalapú adatelérhetőség esetén bárki kijelölhető a láncon kívüli adatok tárolására, amint biztosítja a szükséges letétet. Ezáltal bővül a jogosult adatelérhetőségi kezelők köre, és csökken az adatelérhetőségi bizottságokat (DAC) érintő centralizáció. Ennél is fontosabb, hogy ez a megközelítés kriptogazdasági ösztönzőkre támaszkodik a rosszindulatú tevékenységek megakadályozására, ami lényegesen biztonságosabb, mintha megbízható feleket jelölnénk ki az offline adatok biztosítására a validiumban. + +[Bővebben a kötelezvényalapú adatelérhetőségről a validiumokban](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf). + +## Volitionok és a validium {#volitions-and-validium} + +A validiumok számos előnyt kínálnak, de kompromisszumokkal is járnak (leginkább az adatelérhetőségben). De mint sok más skálázási megoldás, a validiumok is speciális felhasználási esetekre alkalmasak – ezért hozták létre a volitionokat. + +A volitionok kombinálják a ZK összevont tranzakciókat és a validiumláncot, és teszik lehetővé a felhasználók számára a két skálázási megoldás közötti váltást. A volitionokkal a felhasználók bizonyos tranzakciók esetében választhatják a validium láncon kívüli adatelérhetőségét, ugyanakkor válthatnak láncon belüli adatelérhetőségi megoldásra (ZK összevont tranzakciók) is, amikor arra van szükségük. Ez lényegében megadja a felhasználóknak a szabadságot, hogy olyan kompromisszumot válasszanak, amely megfelel egyedi igényüknek. + +Egy decentralizált tőzsde (DEX) előnyben részesítheti a validium skálázható és privát infrastruktúrájának használatát a nagy értékű kereskedésekhez. ZK összevont tranzakciót is használhat azon felhasználók számára, akik magasabb biztonsági garanciákat és bizalomigény-mentességet szeretnék. + +## A validiumok és az EVM kompatibilitás {#validiums-and-evm-compatibility} + +A ZK összevont tranzakciók hasonlóan a validiumok egyszerű alkalmazásokhoz, például tokencserékhez és fizetésekhez alkalmasak. Az általános számítás és az okosszerződések végrehajtásának támogatása a validiumok között nehezen megvalósítható, tekintettel az [EVM](/developers/docs/evm/) utasítások bizonyításának jelentős többletköltségére egy zero-knowledge bizonyítékot készítő folyamatban. + +Egyes validium projektek ezt a problémát úgy próbálják megkerülni, hogy EVM-kompatibilis nyelveket (például Solidity, Vyper) fordítanak le, hogy egyedi, hatékony bizonyításra optimalizált bájtkódot hozzanak létre. Ennek a megközelítésnek az a hátránya, hogy az új, new zero-knowledge bizonyítéknak kedvező virtuális gépek (VM) nem feltétlenül támogatják a fontos EVM-műveleti kódokat, és a fejlesztőknek közvetlenül a magas szintű nyelven kell írniuk az optimális élmény érdekében. Ez még több problémát okoz: arra kényszeríti a fejlesztőket, hogy a dappokat egy teljesen új fejlesztői stackkel építsék meg, és megszakítja a kompatibilitást a jelenlegi Ethereum infrastruktúrával. + +Néhány csapat azonban megpróbálja optimalizálni a meglévő EVM opkódokat a ZK-bizonyítási folyamatok számára. Ennek eredménye egy zero-knowledge Ethereum virtuális gép (zkEVM) kifejlesztése lesz, egy EVM-kompatibilis VM, amely bizonyítékokat állít elő a programfuttatás helyességének ellenőrzésére. A zkEVM segítségével a validiumláncok okosszerződéseket hajthatnak végre a láncon kívül, és érvényességi bizonyítékokat nyújthatnak be egy láncon kívüli számítás ellenőrzésére (anélkül, hogy azt újra végre kellene hajtaniuk) az Ethereumon. + +[Bővebben a zkEVM-ekről](https://www.alchemy.com/overviews/zkevm). + +## Hogyan skálázzák a validiumok az Ethereumot? {#scaling-ethereum-with-validiums} + +### 1. Láncon kívüli adattárolás {#off-chain-data-storage} + +Az L2 skálázási projektek, mint például az optimista és ZK összevont tranzakciók, a tisztán láncon kívüli skálázási protokollok (például [plazma](/developers/docs/scaling/plasma/)) a végtelen skálázhatóságát a biztonságra cserélik azáltal, hogy bizonyos tranzakciós adatokat közzétesznek az L1-en. Ez azonban azt jelenti, hogy a összevont tranzakciók skálázhatósági tulajdonságait korlátozza az Ethereum főhálózat adatsávszélessége (emaitt az [adatsharding](/roadmap/danksharding/) az Ethereum adattárolási kapacitásának javítását célozza). + +A validiumok úgy érik el a skálázhatóságot, hogy minden tranzakciós adatot a láncon kívül tartanak, és csak akkor tesznek közzé státuszelköteleződéseket (és érvényességi bizonyítékokat), amikor az státuszfrissítéseket továbbítják a fő Ethereum-láncnak. Az érvényességi bizonyítékok megléte azonban nagyobb biztonsági garanciákat biztosít a validiumoknak, mint más, tisztán láncon kívüli skálázási megoldások, például a plazma és a [mellékláncok](/developers/docs/scaling/sidechains/). Azáltal, hogy csökkenti az adatmennyiséget, amelyet az Ethereumnak fel kell dolgoznia a láncon kívüli tranzakciók validálása előtt, a validiumdizájnok jelentősen növelik a tranzakcióátviteli sebességet a főhálózaton. + +### 2. Rekurzív bizonyítékok {#recursive-proofs} + +A rekurzív bizonyíték olyan érvényességi bizonyíték, amely más bizonyítékok érvényességét ellenőrzi. Ez a „bizonyítékok bizonyítéka” több bizonyíték rekurzív összevonásával jön létre, amíg kialakul egy végső bizonyíték, amely az összes korábbit ellenőrzi. A rekurzív bizonyítékok úgy skálázzák a blokklánc feldolgozási sebességét, hogy egy adott érvényességi bizonyíték által lefedett tranzakciók számát növelik. + +Jellemzően minden érvényességi bizonyíték, amelyet a validium üzemeltetője benyújt az Ethereumnak ellenőrzésre, egyetlen blokk integritását validálja. Egyetlen rekurzív bizonyíték azonban egyszerre több validiumblokk érvényességét is tudja igazolni – ez azért lehetséges, mert a bizonyító folyamat több blokkbizonyítékot rekurzív módon egyetlen végső bizonyítékká képes összevonni. Ha a láncon belüli hitelesítői szerződés elfogadja a rekurzív bizonyítékot, az összes mögöttes blokk azonnal véglegesítésre kerül. + +## A validium előnyei és hátrányai {#pros-and-cons-of-validium} + +| Előnyök | Hátrányok | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Az érvényességi bizonyítékok biztosítják a láncon kívüli tranzakciók integritását, és megakadályozzák, hogy az üzemeltetők érvénytelen státuszfrissítéseket véglegesítsenek. | Az érvényességi bizonyítékok előállításához speciális hardverre van szükség, ami centralizációs kockázatot jelent. | +| Növeli a tőkehatékonyságot a felhasználók számára (nincs késedelem a pénzeszközök Ethereumba való visszavételében). | Korlátozottan támogatja az általános számítást/okosszerződéseket; speciális nyelveket igényel a fejlesztése. | +| Nem sérülékeny bizonyos gazdasági támadásokkal szemben, melyekkel a csalási bizonyíték alapú rendszerek szembesülnek a nagy értékű alkalmazásoknál. | Nagy számítási kapacitást igényel a ZK bizonyítékok generálása; nem költséghatékony az alacsony tranzakcióátvitelű alkalmazásoknál. | +| Csökkenti a felhasználók gázdíját azáltal, hogy a hívásadatokat (calldata) nem küldi el az Ethereum főhálózatára. | Lassabb szubjektív véglegességi idő (10–30 perc egy ZK bizonyíték generálása) de gyorsabb a teljes véglegesség, mivel nincs felelősségre vonási idő. | +| Alkalmas olyan speciális felhasználási esetekre, mint a kereskedés vagy a blokkláncjátékok, amelyeknél a legfontosabb a tranzakciókra vonatkozó adatvédelem és a skálázhatóság. | Előfordulhat, hogy a felhasználók nem tudnak hozzájutni a pénzeszközeikhez, mert a tulajdonlásuk Merkle-bizonyítékaihoz a láncon kívüli adatoknak rendelkezésre kell állniuk. | +| A láncon kívüli adatelérhetőség nagyobb tranzakcióátvitelt biztosít és növeli a skálázhatóságot. | A biztonsági modell bizalmi feltételezésekre és kriptogazdasági ösztönzőkre támaszkodik, ellentétben a ZK összevont tranzakciókkal, amelyek kriptográfiai biztonsági mechanizmusokra támaszkodnak. | + +### Validiumok/volitionok használata {#use-validium-and-volitions} + +Több projekt is kínál olyan validium- és volitionimplementációkat, amelyeket Ön is beépíthet a dappjaiba: + +**StarkWare StarkEx** – _A StarkEx egy Ethereum L2 skálázási megoldás, amely érvényességi bizonyítékokon alapul. ZK összevont tranzakció vagy validium adatelérhetőségi módban is működhet._ + +- [Dokumentáció](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium) +- [Honlap](https://starkware.co/starkex/) + +**Matter Labs zkPorter** – _A zkPorter egy L2 skálázási protokoll, amely a zkRollup és a sharding ötleteit ötvöző hibrid megközelítéssel kezeli az adatelérhetőséget. Tetszőlegesen sok shardot támogathat, mindegyik saját adatelérhetőségi szabályzattal._ + +- [Blog](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [Dokumentáció](https://docs.zksync.io/zk-stack/concepts/data-availability) +- [Honlap](https://zksync.io/) + +## További információ {#further-reading} + +- [A validium és az L2 összevetése – 99. szám](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) +- [A ZK összevont tranzakciók és a validium összehasonlítása](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) +- [A volition és a kialakulóban lévő adatelérhetőségi spektrum](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) +- [Összevont tranzakciók, validiumok és volitionok: ismerje meg az Ethereum legfrissebb skálázási megoldásait](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" new file mode 100644 index 00000000000..4caff0bbfd0 --- /dev/null +++ "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" @@ -0,0 +1,259 @@ +--- +title: Zero-knowledge összegzők +description: Bevezetés a zero-knowledge összevont tranzakciókba – az Ethereum közösség által használt skálázási megoldásba. +lang: hu +--- + +A zero-knowledge (ZK) összevont tranzakciók olyan második blokkláncrétegbeli (L2) [skálázási megoldások](/developers/docs/scaling/), amelyek növelik az Ethereum főhálózat tranzakcióátviteli képességét azáltal, hogy a számítást és státusztárolást a láncon kívülre helyezik. A ZK összevont tranzakciók több ezer tranzakciót képesek feldolgozni egy kötegben, majd minimális összefoglalóadatot küldenek a főhálózatra. Ez az összefoglaló adat megadja az Ethereum státuszváltozásait és a kriptográfiai bizonyítékot arra, hogy ezek a változtatások helyesek. + +## Előfeltételek {#prerequisites} + +Érdemes áttekinteni az [Ethereum skálázásról](/developers/docs/scaling/) és [L2 megoldásokról](/layer-2) szóló oldalakat. + +## Mik azok a zero-knowledge összevont tranzakciók? {#what-are-zk-rollups} + +**Zero-knowledge (ZK/nullaismeret-alapú) összevont tranzakciók** a tranzakciókat kötegekbe gyűjtik (göngyölítik), amelyeket a láncon kívül hajtanak végre. A láncon kívüli számítás csökkenti a blokkláncra küldendő adatok mennyiségét. A ZK összevont tranzakció operátorai a kötegben lévő tranzakciók által okozott változásokról összefoglalót küldenek ahelyett, hogy minden egyes tranzakciót külön-külön elküldenének. Emellett [érvényességi bizonyítékokat](/glossary/#validity-proof) is készítenek, hogy bizonyítsák a változtatásaik helyességét. + +A ZK összevont tranzakció státuszát az Ethereum hálózatra telepített okosszerződés tartja fenn. Ennek a státusznak a frissítéséhez a ZK összevont tranzakciós csomópontoknak érvényességi bizonyítékot kell benyújtaniuk ellenőrzésre. Az érvényességi bizonyíték egy kriptográfiai biztosíték arra, hogy az összevont tranzakció által javasolt státuszváltozás valóban az adott tranzakcióköteg végrehajtásának eredménye. Ez azt jelenti, hogy a ZK összevont tranzakcióknak csak érvényességi bizonyítékokat kell szolgáltatniuk ahhoz, hogy az Ethereumon a tranzakciók véglegesedjenek, ahelyett hogy az összes tranzakciós adatot a láncon tennék közzé, mint az [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/). + +A ZK összevont tranzakcióból az Ethereumba történő pénzmozgás nem jár késedelemmel, mivel a kilépési tranzakciók akkor kerülnek végrehajtásra, amikor a ZK összevont tranzakciós szerződés ellenőrzi az érvényességi bizonyítékot. Ezzel szemben az optimista összevont tranzakciókból történő pénzkivonás késleltetett, hogy szükség esetén bárki megtámadhassa a kilépési tranzakciót egy [csalási bizonyítékkal](/glossary/#fraud-proof). + +A ZK összevont tranzakciók a tranzakciókat `calldata` adatként írják az Ethereumba. A `calldata` az a hely, ahol az okosszerződés-függvények külső hívásaiban szereplő adatok tárolódnak. A `calldata` információit közzéteszik a blokkláncon, így bárki önállóan rekonstruálhatja az összevont tranzakció státuszát. A ZK összevont tranzakciók tömörítési technikákat használnak a tranzakciós adatok csökkentésére – például a számlákat cím helyett index-szel jelölik, ami 28 bájtnyi adatot takarít meg. Az adatok közzététele a láncon jelentős költséget jelent az összevont tranzakciók esetében, így az adattömörítés csökkentheti a felhasználók díjait. + +## Hogyan működnek együtt a ZK összevont tranzakciók az Ethereummal? {#zk-rollups-and-ethereum} + +A ZK összevont tranzakciós lánc egy olyan láncon kívüli protokoll, amely az Ethereum blokklánc tetején működik, és a láncon belüli Ethereum okosszerződések kezelik. A ZK összevont tranzakciók a tranzakciókat a főhálózaton kívül hajtják végre, de a láncon kívüli tranzakciós kötegeket átadják a láncon belüli összevonttranzakció-szerződésnek. Ez a tranzakciós rekord, akárcsak az Ethereum blokklánc, megváltoztathatatlan, és a ZK összevont tranzakciós láncot alkotja. + +A ZK összevont tranzakció alapvető felépítése a következő összetevőkből áll: + +1. **Láncon lévő szerződések**: A ZK összevont tranzakciós protokollt az Ethereumon futó okosszerződések irányítják. Ez magában foglalja a fő szerződést, amely tárolja az összevont tranzakciós blokkokat, nyomon követi a letéteket és figyeli a státuszfrissítéseket. Egy másik láncon belüli szerződés (a hitelesítői szerződés) ellenőrzi a blokk készítői által benyújtott zero-knowledge bizonyítékokat. Így az Ethereum a ZK összevont tranzakciók alaprétegeként vagy L1-ként szolgál. + +2. **Láncon kívüli virtuális gép (VM)**: Míg a ZK összevont tranzakciós protokoll az Ethereumon él, a tranzakciók végrehajtása és a státusztárolás az [EVM-től](/developers/docs/evm/) független, külön virtuális gépen történik. Ez a láncon kívüli VM a ZK összevont tranzakciós tranzakciók végrehajtási környezete, és a ZK összevont tranzakciós protokoll másodlagos vagy második rétegeként szolgál. Az Ethereum főhálózaton ellenőrzött érvényességi bizonyítékok garantálják a láncon kívüli VM-ben történő státuszváltozások helyességét. + +A ZK összevont tranzakciók hibrid skálázási megoldások, mivel láncon kívüli, függetlenül működő protokollok, de biztonságukat az Ethereumból merítik. Konkrétan az Ethereum-hálózat érvényesíti a státuszváltozások érvényességét a ZK összevont tranzakción, és garantálja az összevont tranzakció státuszváltozásához tartozó adatelérhetőséget. Emiatt a ZK összevont tranzakciók biztonságosabbak, mint a tisztán láncon kívüli skálázási megoldások, mint például a [mellékláncok](/developers/docs/scaling/sidechains/), amelyek maguk felelnek a biztonsági tulajdonságaikért, vagy a [validiumok](/developers/docs/scaling/validium/), amelyek bár érvényességi bizonyítékokkal ellenőrzik a tranzakciókat az Ethereumon, de a tranzakciós adatokat máshol tárolják. + +A ZK összevont tranzakciók az Ethereum fő protokolljára támaszkodnak a következőkben: + +### Adatelérhetőség {#data-availability} + +A ZK összevont tranzakciók minden egyes, a láncon kívül feldolgozott tranzakció státuszadatait közzéteszik az Ethereumon. Ezekkel az adatokkal lehetővé válik, hogy magánszemélyek vagy vállalkozások reprodukálják az összevont tranzakció státuszát, és maguk hitelesítsék a láncot. Az Ethereum ezeket az adatokat `calldata` formájában a hálózat minden résztvevője számára elérhetővé teszi. + +A ZK összevont tranzakcióknak nem kell sok tranzakciós adatot közzétenniük a láncban, mivel az érvényességi bizonyítékok már most is ellenőrzik az státuszváltozások hitelességét. Mindazonáltal az adatok láncon belüli tárolása továbbra is fontos, mivel lehetővé teszi az L2-lánc státuszának engedély nélküli, független ellenőrzését, így bárki tranzakciókötegeket küldhet be, és ezzel elejét veszi annak, hogy rosszhiszemű szereplők cenzúrázzák vagy befagyasszák a láncot. + +A felhasználóknak szükségük van a láncon lévő dolgokra ahhoz, hogy az összevont tranzakcióval interakcióban legyenek. A státuszadatokhoz elérése nélkül a felhasználók nem tudják lekérdezni a számlaegyenlegüket, illetve nem tudnak státuszinformációkra támaszkodó tranzakciókat (pl. pénzfelvételt) kezdeményezni. + +### Tranzakcióvéglegesség {#transaction-finality} + +Az Ethereum a ZK összevont tranzakciók elszámolási rétegeként működik: az L2 tranzakciók csak akkor kerülnek véglegesítésre, ha az L1 szerződés elfogadja az érvényességi bizonyítékot. Ez kiküszöböli annak kockázatát, hogy a rosszindulatú szereplők megrongálják a láncot (pl. ellopják a pénzeszközöket), mivel minden tranzakciót jóvá kell hagyni a főhálózaton. Az Ethereum azt is garantálja, hogy a felhasználói műveleteket nem lehet visszafordítani, miután véglegesítették azokat az L1-en. + +### Cenzúraálló kialakítás {#censorship-resistance} + +A legtöbb ZK összevont tranzakció egy „szupercsomópontot” (az operátort) használ a tranzakciók végrehajtására, a kötegek előállítására és a blokkok L1-re küldésére. Ez biztosítja ugyan a hatékonyságot, de növeli a cenzúra kockázatát: a rosszindulatú ZK összevonttranzakció-üzemeltetők cenzúrázhatják a felhasználókat azáltal, hogy megtagadják a tranzakciók kötegekbe való felvételét. + +Biztonsági intézkedésként a ZK összevont tranzakciók lehetővé teszik a felhasználók számára, hogy tranzakciókat nyújtsanak be közvetlenül a főhálózat összevont tranzakciós szerződéshez, ha úgy gondolják, hogy az üzemeltető cenzúrázza őket. Ezzel a felhasználók átléphetnek a ZK összevont tranzakcióból az Ethereumra az üzemeltető engedélye nélkül. + +## Hogyan működnek a ZK összevont tranzakciók? {#how-do-zk-rollups-work} + +### Tranzakciók {#transactions} + +A ZK összevont tranzakció felhasználói aláírják a tranzakciókat, és elküldik az L2 operátoroknak feldolgozásra és a következő kötegbe való felvételre. Bizonyos esetekben az operátor egy centralizált résztvevő, az úgynevezett szekvenszer, amely végrehajtja a tranzakciókat, kötegekbe gyűjti azokat, és továbbítja az L1-nek. Ebben a rendszerben a szekvenszer az egyetlen olyan entitás, amely L2 blokkokat állíthat elő és összevont tranzakciókat adhat hozzá a ZK összevont tranzakciós szerződéshez. + +Más ZK összevont tranzakciók egy [proof-of-stake (letétigazolás)](/developers/docs/consensus-mechanisms/pos/) alapú validátorcsoport használatával rotálják az operátori szerepet. A leendő üzemeltetők pénzt helyeznek el az összevont tranzakciós szerződésben, és az egyes letétek nagysága befolyásolja a letétbe helyező esélyeit arra, hogy kiválasztják a következő köteg előállítására. Az operátort meg lehet büntetni a letétje mértékéig, ha rosszindulatúan cselekszik, ami arra ösztönzi, hogy érvényes blokkokat tegyen közzé. + +#### Hogyan teszik közzé a ZK összevont tranzakciók a tranzakciós adatokat az Ethereumon {#how-zk-rollups-publish-transaction-data-on-ethereum} + +A tranzakciós adatokat az Ethereumon `calldata` adatként publikálják. A `calldata` egy adatterület az okosszerződésben, amelyet arra használnak, hogy argumentumokat adjanak át egy függvénynek, és a [memóriához](/developers/docs/smart-contracts/anatomy/#memory) hasonlóan viselkedik. Bár a `calldata` nem az Ethereum státuszának részeként tárolódik, az Ethereum [historikus naplózásában](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) fennmarad a láncban. A `calldata` nem befolyásolja az Ethereum státuszát, így olcsó adattárolást tesz lehetővé a láncban. + +A `calldata` kulcsszó gyakran azonosítja a tranzakció által meghívott okosszerződés-metódust, és annak bemeneteit egy tetszőleges bájtsorozat formájában tartalmazza. A ZK összevont tranzakciók a `calldata` mezőt használják a tömörített tranzakciós adatok láncon belüli közzétételére; az összevonttranzakció-operátor új köteget ad hozzá az összevont tranzakciós szerződésben szereplő függvény meghívásával, és az adatokat a függvény argumentumaként adja át. Ez segít csökkenteni a felhasználók költségeit, mivel az összevont tranzakciós díjak nagy részét a tranzakciós adatok láncban történő tárolására fordítják. + +### Státuszrögzítések {#state-commitments} + +A ZK összevont tranzakció státusza, amely az L2 számlákat és egyenlegeket tartalmazza, egy [Merkle-fa](/whitepaper/#merkle-trees) formájában jelenik meg. A Merkle-fa gyökerének (Merkle-gyökér) kriptográfiai hash-e a láncon belüli szerződésben van tárolva, így az összevonttranzakció-protokoll nyomon követheti a ZK összevont tranzakció státuszában bekövetkező változásokat. + +Az összevont tranzakció egy új tranzakcióhalmaz végrehajtása után új státuszba lép. A státuszváltozást kezdeményező operátornak ki kell számolnia egy új státuszgyökeret, és be kell nyújtania azt a láncon belüli szerződésnek. Ha a köteghez tartozó érvényességi bizonyítékot a hitelesítő szerződés igazolja, az új Merkle-gyökér lesz a ZK összevont tranzakció kanonikus státuszgyökere. + +A státuszgyökerek kiszámítása mellett a ZK összevont tranzakciós operátor létrehoz egy köteggyökeret is, ami a kötegben lévő tranzakciókat tartalmazó Merkle-fa gyökere. Egy új köteg benyújtásakor az összevont tranzakciós szerződés tárolja a köteggyökeret, így a felhasználók bizonyítani tudják, hogy egy tranzakció (például egy kifizetési kérelem) szerepel a kötegben. A felhasználóknak meg kell adniuk a tranzakció adatait, a köteggyökeret és egy [Merkle bizonyítékot](/developers/tutorials/merkle-proofs-for-offline-data-integrity/), amely megmutatja a belefoglalás útvonalát. + +### Érvényességi bizonyítékok {#validity-proofs} + +Az új státuszgyökér, amelyet a ZK összevont tranzakció operátora az L1 szerződésnek benyújt, az összevont tranzakció státuszának frissítéséből származik. Tegyük fel, hogy Alice 10 tokent küld Bobnak, az operátor egyszerűen csökkenti Alice egyenlegét 10-zel, és növeli Bob egyenlegét 10-zel. Az operátor ezután a frissített számlaadatokat hash-eli, újjáépíti az összevont tranzakció Merkle-fáját, és az új Merkle-gyökeret elküldi a láncban lévő szerződésnek. + +Az összevont tranzakciós szerződés azonban nem fogadja el automatikusan a javasolt státuszelköteleződést, amíg az operátor nem bizonyítja, hogy az új Merkle-gyökér az összevont tranzakció státuszának helyes frissítéséből származik. A ZK összevont tranzakció operátora ezt úgy éri el, hogy érvényességi bizonyítékot állít elő, amely egy tömör kriptográfiai elköteleződés, amely a kötegelt tranzakciók helyességét igazolja. + +Az érvényességi bizonyítékok lehetővé teszik a felek számára, hogy igazolják egy állítás helyességét anélkül, hogy felfednék az állítást – ezért nevezik őket felfedés nélküli (zero-knowledge) bizonyításnak is. A ZK összevont tranzakciók érvényességi bizonyítékokat használnak a láncon kívüli státuszváltozások helyességének megerősítésére, és a tranzakciókat nem kell újra végrehajtani az Ethereumon. Ezek az érvényességi bizonyítékok [ZK-SNARK](https://arxiv.org/abs/2202.06877) (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, vagyis zero-knowledge tömörített nem interaktív érv ismeretre) vagy [ZK-STARK](https://eprint.iacr.org/2018/046) (Zero-Knowledge Scalable Transparent Argument of Knowledge, vagyis zero-knowledge skálázható transzparens érv ismeretre) formájában érkezhetnek. + +A SNARK-ok és a STARK-ok egyaránt segítenek igazolni a ZK összevont tranzakciókban a láncon kívüli számítás integritását, bár mindegyik típusnak vannak sajátos jellemzői. + +**ZK-SNARK-ok** + +A ZK-SNARK protokoll működéséhez szükség van a nyilvános paraméterek (közös hivatkozási karakterlánc/CRS) létrehozására: a CRS nyilvános paramétereket biztosít az érvényességi bizonyítékok igazolásához és ellenőrzéséhez. A bizonyítási rendszer biztonsága a CRS beállításától függ; ha a nyilvános paraméterek létrehozásához használt információk rosszindulatú szereplők birtokába jutnak, akkor képesek lehetnek hamis érvényességi bizonyítékokat generálni. + +Egyes ZK összevont tranzakciók úgy próbálják megoldani ezt a problémát, hogy egy [többszereplős számítási ceremóniát (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) használnak, melynek során megbízható személyekkel nyilvános paramétereket generálnak a ZK-SNARK folyamat számára. Mindegyik fél ad némi véletlenszerűséget (úgynevezett „mérgező hulladékot”) a CRS konstrukciójához, amelyet azonnal meg kell semmisíteniük. + +Ezt a bizalmat igénylő felállást azért használják, mert ez növeli a CRS-beállítás biztonságát. Amíg legalább egy becsületes résztvevő megsemmisíti a bemenetét, a ZK-SNARK rendszer biztonsága garantált. Ez a megközelítés azonban megköveteli, hogy az érintettek bízzanak abban, hogy törlik a mintavételezett véletlenszerűséget, és nem ássák alá a rendszer biztonsági garanciáit. + +A bizalmi feltételezésektől eltekintve a ZK-SNARK-ok népszerűek a kis bizonyítékméret és az állandó ellenőrzési idő miatt. Mivel a bizonyítékok L1-en történő ellenőrzése jelenti a ZK összevont tranzakció működtetésének nagyobb költségét, az L2-k ZK-SNARK-okat használnak a főhálózaton gyorsan és olcsón ellenőrizhető bizonyítékok létrehozására. + +**ZK-STARK-ok** + +A ZK-SNARK-okhoz hasonlóan a ZK-STARK-ok is a bemenetek felfedése nélkül bizonyítják a láncon kívüli számítás érvényességét. A ZK-STARK-ok azonban skálázhatóságuk és átláthatóságuk miatt a ZK-SNARK-okhoz képest előrelépésnek számítanak. + +A ZK-STARK-ok átláthatók, mivel a közös referenciasorozat (CRS) megbízható beállítása nélkül is működnek. Ehelyett a ZK-STARK-ok nyilvánosan ellenőrizhető véletlenszerűségre támaszkodnak a bizonyítások generálásához és ellenőrzéséhez szükséges paraméterek beállításához. + +A ZK-STARK-ok nagyobb skálázhatóságot is biztosítanak, mivel az érvényességi bizonyítékok igazolásához és ellenőrzéséhez szükséges idő _kvázilineárisan_ növekszik a mögöttes számítás bonyolultságához képest. A ZK-SNARK-okkal a bizonyítási és ellenőrzési idők _lineárisan_ skálázódnak a mögöttes számítás méretéhez képest. Ez azt jelenti, hogy a ZK-STARK-oknak kevesebb időre van szükségük a bizonyításhoz és ellenőrzéshez, mint a ZK-SNARK-oknak, amikor nagy adathalmazokról van szó, ami nagy volumenű alkalmazásokhoz teszi őket hasznossá. + +A ZK-STARK-ok a kvantumszámítógépek ellen is biztonságosak, míg a ZK-SNARK-okban használt elliptikus görbe kriptográfia (ECC) széles körben úgy vélik, hogy sebezhető a kvantumszámítógépekkel szemben. A ZK-STARK-ok hátránya, hogy nagyobb méretű bizonyítékokat készítenek, amelyeket drágább ellenőrizni az Ethereumon. + +#### Hogyan működnek az érvényességi bizonyítékok a ZK összevont tranzakciókban? {#validity-proofs-in-zk-rollups} + +##### Bizonyíték készítése + +A tranzakciók elfogadása előtt az operátor elvégzi a szokásos ellenőrzéseket. Ez magában foglalja annak ellenőrzését, hogy: + +- A küldő és a fogadó számlák a státuszfa részét képezik. +- A küldőnek elegendő fedezete van a tranzakció lebonyolításához. +- A tranzakció helyes, és egyezik a küldő összevont tranzakcióbeli nyilvános kulcsával. +- A küldő nonce-ja helyes stb. + +Amint a ZK összevont tranzakciós csomópont elegendő tranzakcióval rendelkezik, összegyűjti azokat egy kötegbe, és összeszedi a bemeneteket a bizonyító folyamat számára, hogy egy tömör ZK-bizonyítékká állítsa össze. Ezek a következők: + +- A kötegben lévő tranzakciókat tartalmazó Merkle-fa gyökere. +- Merkle-bizonyítékok a tranzakciókhoz a kötegbe való felvétel bizonyítására. +- Merkle-bizonyítékok a tranzakciókban szereplő minden küldő-fogadó párra annak bizonyítására, hogy ezek a számlák az összevont tranzakció státuszfájának részét képezik. +- Közbenső státuszgyökerek halmaza, amely a státuszgyökér frissítéséből származik, miután az egyes tranzakciókhoz státuszfrissítéseket alkalmaztak (azaz csökkentették a küldőszámlákat és növelték a fogadószámlákat). + +A bizonyító folyamat úgy számítja ki az érvényességi bizonyítékot, hogy minden tranzakción végigmegy, és elvégzi ugyanazokat az ellenőrzéseket, amelyeket az operátor a tranzakció feldolgozása előtt elvégzett. Először is a megadott Merkle-bizonyíték segítségével ellenőrzi, hogy a küldő számlája része a meglévő státuszgyökérnek. Ezután csökkenti a küldő egyenlegét, megnöveli a nonce-ját, a frissített számlaadatokat hash-eli, és a Merkle-bizonyítékkal kombinálva létrehoz egy új Merkle-gyökeret. + +Ez a Merkle-gyökér tükrözi a ZK összevont tranzakció státuszának egyetlen változását: a küldő egyenlegének és a nonce-nak a változását. Ez azért lehetséges, mert a számla létezésének bizonyítására használt Merkle-bizonyítékot használják az új státuszgyökér létrehozására. + +A bizonyító folyamat ugyanezt végzi a fogadó számláján. Ellenőrzi, hogy a fogadó számlája létezik-e a köztes státuszgyökér alatt (a Merkle-bizonyítékkal), növeli az egyenlegét, újra-hash-eli a számlaadatokat, és a Merkle-bizonyítékkal kombinálva létrehoz egy új státuszgyökeret. + +A folyamat minden tranzakciónál megismétlődik; minden ciklus új státuszgyökeret hoz létre a küldő számlájának frissítéséből, és egy következő új gyökeret a fogadó számlájának frissítéséből. A státuszgyökér frissítése azt mutatja, hogy az összevont tranzakció státuszfájának egy része megváltozik. + +A ZK bizonyító folyamat a teljes tranzakciós köteg felett iterál, és ellenőrzi a frissítések azon sorozatát, amely az utolsó tranzakció végrehajtása után egy végső státuszgyökeret eredményez. Az utolsó kiszámított Merkle-gyökér lesz a ZK-rollup legújabb kanonikus státuszgyökere. + +##### Bizonyíték-ellenőrzés + +Miután a bizonyító folyamat igazolja a státuszfrissítések helyességét, az L2 operátor benyújtja a kiszámított érvényességi bizonyítékot az L1-en lévő hitelesítő szerződésnek. A szerződés ellenőrző folyamata igazolja a bizonyíték érvényességét, és ellenőrzi a bizonyítás részét képező nyilvános bemeneteket is: + +- **Korábbi státuszgyökér**: A ZK összevont tranzakció régi státuszgyökere (a kötegelt tranzakciók végrehajtása előtt), amely az L2-lánc utolsó ismert érvényes státuszát tükrözi. + +- **Új státuszgyökér**: A ZK összevont tranzakció új státuszgyökere (a kötegelt tranzakciók végrehajtása után), amely az L2-lánc legújabb státuszát tükrözi. Az új státuszgyökér az a végső gyökér, amely a bizonyító folyamatban a státuszfrissítések után keletkezik. + +- **Köteggyökér**: A köteg Merkle-gyökere, amelyet a kötegben lévő tranzakciók _merkle-izálásával_ és a fa gyökerének hash-elésével kapunk. + +- **Tranzakciós bemenetek**: A benyújtott köteg részeként végrehajtott tranzakciókhoz kapcsolódó adatok. + +Ha a bizonyíték kielégíti a folyamatot (azaz érvényes), akkor létezik azon érvényes tranzakciók halmaza, amelyek az összevont tranzakciót az előző státuszából (a korábbi státuszgyökér által kriptográfiai ujjlenyomatokkal ellátva) egy új státuszba (az újstátuszgyökér által kriptográfiai ujjlenyomatokkal ellátva) vezetik át. Ha a korábbi státuszgyökér megegyezik az összevont tranzakciós szerződésben tárolt gyökérrel, és a bizonyíték érvényes, az összevont tranzakciós szerződés átveszi az új státuszgyökeret a bizonyítékból, és frissíti a státuszfáját, hogy tükrözze az összevont tranzakció megváltozott státuszát. + +### Belépés és kilépés {#entries-and-exits} + +A felhasználók úgy lépnek be a ZK összevont tranzakcióba, hogy tokeneket helyeznek el az összevont tranzakció L1-en lévő szerződésében. Ez a tranzakció bekerül a sorba, mivel csak az operátorok nyújthatnak be tranzakciókat az összevont tranzakciós szerződéshez. + +Ha a függőben lévő befizetési sor kezd megtelni, a ZK összevont tranzakció operátora átveszi a befizetési tranzakciókat, és benyújtja azokat az összevont tranzakciós szerződéshez. Amint a felhasználó pénzeszközei az összevont tranzakcióban vannak, elkezdheti használni azáltal, hogy tranzakciókat küld az operátornak feldolgozásra. A felhasználók ellenőrizhetik az egyenlegeket az összevont tranzakción a számlaadataik hash-elésével, a hash elküldésével az összevont tranzakció-szerződésnek, és egy Merkle-bizonyítékkal, amelyet az aktuális státuszgyökérrel szemben ellenőriznek. + +A ZK összevont tranzakcióból az L1-re való visszalépés egyszerű. A felhasználó kezdeményezi a kilépési tranzakciót azzal, hogy az összevont tranzakcióban lévő eszközeit egy megadott számlára küldi elégetés céljából. Ha az üzemeltető felveszi a tranzakciót a következő kötegbe, a felhasználó kivételi kérelmet nyújthat be a láncon belüli szerződéshez. Ez a kivételi kérelem a következőket tartalmazza: + +- Merkle bizonyíték, amely bizonyítja, hogy a felhasználó tranzakciója egy tranzakciókötegben szerepel az elégetési számlán + +- Tranzakciós adatok + +- Köteggyökér + +- L1 cím a befizetett pénzeszközök fogadására + +az összevont tranzakciós szerződés hash-eli a tranzakció adatait, ellenőrzi, hogy létezik-e a köteggyökér, és a Merkle-bizonyíték segítségével ellenőrzi, hogy a tranzakció hash része-e a köteggyökérnek. Ezt követően a szerződés végrehajtja a kilépési tranzakciót, és elküldi a pénzt a felhasználó által az L1-en kiválasztott címre. + +## A ZK összevont tranzakciók és az EVM kompatibilitása {#zk-rollups-and-evm-compatibility} + +Az optimista összevont tranzakciókkal ellentétben a ZK összevont tranzakciók nem kompatibilisek az [Ethereum virtuális géppel (EVM)](/developers/docs/evm/). Az általános célú EVM-számítás bizonyítási folyamata nehezebb és erőforrás-igényesebb, mint az egyszerű számítások bizonyítása (mint például a tokenátvitel). + +A [zero-knowledge technológia fejlődése](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) azonban újból felkeltette az érdeklődést az EVM-számítás zero-knowledge bizonyítékokba csomagolása iránt. Ezek az erőfeszítések egy olyan zero-knowledge EVM (zkEVM) implementáció létrehozására irányulnak, amely hatékonyan képes ellenőrizni a programvégrehajtás helyességét. A zkEVM újrateremti a meglévő EVM opkódokat a bizonyítási/ellenőrzési folyamathoz, lehetővé téve az okosszerződések végrehajtását. + +Az EVM-hez hasonlóan a zkEVM is státuszváltozást okoz, miután bizonyos bemeneteken számításokat végeztek. A különbség az, hogy a zkEVM zero-knowledge bizonyítékokat is készít, hogy ellenőrizze a programvégrehajtás lépéseinek helyességét. Az érvényességi bizonyítékok ellenőrizhetik a VM státuszát érintő műveletek helyességét (memória, stack, tárhely) és magát a számítást (a művelet a megfelelő opkódokat hívta meg és helyesen hajtotta végre). + +Az EVM-kompatibilis ZK összevont tranzakciók bevezetése várhatóan segít a fejlesztőknek kihasználni a zero-knowledge bizonyítékok skálázhatóságát és biztonsági garanciáit. Ami még fontosabb, a natív Ethereum infrastruktúrával való kompatibilitás azt jelenti, hogy a fejlesztők ZK-barát dappokat építhetnek ismerős (és kipróbált) eszközökkel és nyelvekkel. + +## Hogyan működnek a ZK összevont tranzakciós díjak? {#how-do-zk-rollup-fees-work} + +Az, hogy a felhasználók mennyit fizetnek a tranzakciókért a ZK összevont tranzakciókon, az Ethereum főhálózathoz hasonlóan a gázdíjtól függ. A gázdíjak azonban az L2 esetében másképp alakulnak, és a következő költségek befolyásolják: + +1. **Státuszfrissítés**: Az Ethereum státuszába való írás (azaz egy tranzakció benyújtása az Ethereum blokkláncán) fix költséggel jár. A ZK összevont tranzakciók a tranzakciók kötegelésével és a fix költségek több felhasználóra történő elosztásával csökkentik ezt a költséget. + +2. **Adatközzététel**: A ZK összevont tranzakciók minden tranzakció státuszadatait `calldata` mezőként teszik közzé az Ethereumban. A `calldata` költségeit jelenleg az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) szabályozza, amely a `calldata` nem nulla bájtjaira 16, nulla bájtjaira 4 gázköltséget ír elő. A tranzakció költségét az befolyásolja, hogy mennyi `calldata`-t kell a láncban közzétenni. + +3. **L2 operátordíjak**: Ezt az összevont tranzakció operátorának fizetik a tranzakciók feldolgozása során felmerülő számítási költségek ellentételezéseként, hasonlóan az Ethereum főhálózat [tranzakciós prioritási díjaihoz (borravaló)](/developers/docs/gas/#how-are-gas-fees-calculated). + +4. **Bizonyítéklétrehozás és ellenőrzés**: A ZK összevont tranzakció operátorainak érvényességi bizonyítékokat kell előállítaniuk a tranzakciókötegekhez, ami erőforrás-igényes. A zero-knowledge bizonyítékok ellenőrzése a főhálózaton szintén gázba kerül (kb. 500 000 gáz). + +A tranzakciók kötegelése mellett a ZK összevont tranzakciók a tranzakciós adatok tömörítésével csökkentik a felhasználók díjait. [Megtekinthet egy valós idejű kalkulációt](https://l2fees.info/) arról, hogy mennyibe kerül az Ethereum ZK összevont tranzakciók használata. + +## Hogyan skálázzák a ZK összevont tranzakciók az Ethereumot? {#scaling-ethereum-with-zk-rollups} + +### Tranzakciós adatok tömörítése {#transaction-data-compression} + +A ZK összevont tranzakciók növelik az Ethereum alaprétegének tranzakcióátvitelét azáltal, hogy a számításokat a láncon kívülre viszik, de a skálázás valódi lendületét a tranzakciós adatok tömörítése adja. Az Ethereum [blokkmérete](/developers/docs/blocks/#block-size) korlátozza az egyes blokkokban tárolható adatokat, és ezáltal a blokkonként feldolgozott tranzakciók számát. A tranzakciókkal kapcsolatos adatok tömörítésével a ZK összevont tranzakciók jelentősen növelik a blokkonként feldolgozott tranzakciókat. + +A ZK összevont tranzakciók jobban tudják tömöríteni a tranzakciós adatokat, mint az optimista összevont tranzakciók, mivel nem kell a tranzakciók érvényesítéséhez szükséges összes adatot elküldeniük. Minimális adatot kell elküldeniük, amellyel újra lehet építeni az összevont tranzakción lévő számlák és egyenlegek legfrissebb státuszát. + +### Rekurzív bizonyítékok {#recursive-proofs} + +A zero-knowledge bizonyítékok előnye, hogy azok más bizonyítékokat is ellenőrizhetnek. Például egy ZK-SNARK ellenőrizhet más ZK-SNARK-okat. Ezek a rekurzív bizonyítékok drámaian megnövelik a ZK összevont tranzakciók teljesítményét. + +Jelenleg az érvényességi bizonyítékokat blokkonként generálják, és az L1-szerződéshez nyújtják be ellenőrzésre. Az egy blokkra vonatkozó bizonyítékok ellenőrzése korlátozza a ZK összevont tranzakciók tranzakcióátvitelét, mivel csak egy blokk véglegesíthető, amikor az operátor benyújtja a bizonyítékot. + +A rekurzív bizonyítékok révén ugyanakkor egyetlen érvényességi bizonyítékkal több blokkot is véglegesíthetünk. Ennek az az oka, hogy a bizonyító folyamat rekurzív módon több blokkbizonyítékot aggregál, amíg egy végső bizonyíték létre nem jön. Az L2 operátor benyújtja ezt a rekurzív bizonyítékot, és ha a szerződés elfogadja azt, akkor az összes vonatkozó blokk azonnal véglegesítésre kerül. A rekurzív bizonyítékokkal nő az Ethereumon az adott időperiódusban véglegesíthető ZK összevont tranzakciók száma. + +### A ZK összevont tranzakciók előnyei és hátrányai {#zk-rollups-pros-and-cons} + +| Előnyök | Hátrányok | +| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Az érvényességi bizonyítékok biztosítják a láncon kívüli tranzakciók helyességét, és megakadályozzák, hogy az operátorok érvénytelen státuszváltozásokat hajtsanak végre. | Az érvényességi bizonyítékok kiszámításával és ellenőrzésével járó költségek jelentősek, és növelhetik az összevont tranzakciók felhasználóinak díjait. | +| Gyorsabb tranzakciós véglegesítést kínál, mivel a státuszfrissítések jóváhagyása az érvényességi bizonyítékok L1-en történő ellenőrzése után történik. | Az EVM-kompatibilis ZK összevont tranzakciók építése a zero-knowledge technológia összetettsége miatt nehéz. | +| Bizalomigény nélküli kriptográfiai mechanizmusokra támaszkodik a biztonság érdekében, nem pedig az ösztönzött szereplők őszinteségére, mint az [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons) esetében. | Az érvényességi bizonyítékok előállításához speciális hardverre van szükség, ami ösztönözheti a lánc néhány fél általi centralizált ellenőrzését. | +| A láncon kívüli státusz megállapításához szükséges adatokat az L1-en tárolja, ami garantálja a biztonságot, a cenzúraellenességet és a decentralizációt. | A centralizált operátorok (szekvencerek) befolyásolhatják a tranzakciók sorrendjét. | +| A felhasználók nagyobb tőkehatékonyságot élveznek, és késedelem nélkül vehetnek fel pénzt az L2-ről. | A hardver-követelmények csökkenthetik azon résztvevők számát, akik a láncot működésre kényszeríthetik, növelve annak kockázatát, hogy a rosszindulatú operátorok befagyasztják az összevont tranzakció státuszát és cenzúrázzák a felhasználókat. | +| Nem függ az elérhetőségi feltételezésektől, és a felhasználóknak nem kell validálniuk a láncot, hogy megvédjék pénzeszközeiket. | Egyes bizonyítási rendszerek (pl. a ZK-SNARK) megbízható beállításokat igényelnek, amelyek rossz kezelés esetén potenciálisan veszélyeztethetik az összevont tranzakció biztonsági modelljét. | +| A jobb adattömörítés segíthet csökkenteni a `calldata` közzétételének költségeit az Ethereumban, és minimalizálhatja a felhasználók összevonttranzakció-díjait. | | + +### A ZK összevont tranzakciók vizuális bemutatása {#zk-video} + +Nézze meg a videót, melyben a Finematics elmagyarázza a ZK összevont tranzakciók lényegét: + + + +### ZK összevont tranzakciók használata {#use-zk-rollups} + +A ZK összevont tranzakcióknak többféle megvalósítása létezik, amelyeket integrálhat a dappjaiba: + + + +## Kik dolgoznak zkEVM-en? {#zkevm-projects} + +Többek között az alábbi projektek dolgoznak zkEVM-en: + +- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _A zkEVM az Ethereum Alapítvány által finanszírozott projekt, amelynek célja egy EVM-kompatibilis ZK összevont tranzakció létrehozása és egy mechanizmus kifejlesztése az Ethereum blokkok érvényességi bizonyítékainak generálására._ + +- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _Egy decentralizált ZK összevont tranzakció az Ethereum főhálózaton, amely egy zero-knowledge Ethereum virtuális gépen (zkEVM) dolgozik, amely Ethereum tranzakciókat hajt végre átlátható módon, beleértve a zero-knowledge-bizonyíték igazolásásra alkalmas okosszerződéseket is._ + +- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scroll egy tech-központú vállalat, amely egy natív zkEVM L2 megoldás létrehozásán dolgozik az Ethereum számára._ + +- **[Taiko](https://taiko.xyz)** - _A Taiko egy decentralizált, Ethereum-egyenértékű ZK összevont tranzakció ([1-es típusú ZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))._ + +- **[ZKsync](https://docs.zksync.io/)** - _A ZKsync Era egy EVM-kompatibilis ZK összevont tranzakció, amelyet a Matter Labs készített a saját zkEVM-jével alátámasztva._ + +- **[Starknet](https://starkware.co/starknet/)** - _A StarkNet egy EVM-kompatibilis L2 skálázási megoldás, amelyet a StarkWare készített._ + +- **[Morph](https://www.morphl2.io/)** - _Morph egy olyan hibrid összevont tranzakció skálázási megoldás, mely zk-bizonyítékot használ, hogy kezelje az L2-höz kapcsolódó státuszmegkérdőjelezés problémáját._ + +## További olvasnivaló a ZK összevont tranzakciókról {#further-reading-on-zk-rollups} + +- [Mik azok a zero-knowledge összevont tranzakciók?](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) +- [Mik azok a zero-knowledge összevont tranzakciók?](https://alchemy.com/blog/zero-knowledge-rollups) +- [A STARK-ok és a SNARK-ok összehasonlítása](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) +- [Mi az a zkEVM?](https://www.alchemy.com/overviews/zkevm) +- [ZK-EVM típusok: Ethereum-egyenértékű, EVM-egyenértékű, 1. típus, 4. típus és egyéb rejtélyes kifejezések](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) +- [Bevezetés a zkEVM-be](https://hackmd.io/@yezhang/S1_KMMbGt) +- [Awesome-zkEVM dokumentációk](https://github.com/LuozhuZhang/awesome-zkevm) +- [A ZK-SNARK-ok működése](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) +- [Hogyan lehetséges a SNARK?](https://vitalik.eth.limo/general/2021/01/26/snarks.html) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..c982c906241 --- /dev/null +++ b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: Adatszerkezetek és kódolás +description: Az alapvető Ethereum adatstruktúrák áttekintése. +lang: hu +sidebarDepth: 2 +--- + +Az Ethereum nagy adatkötegeket hoz létre, tárol és mozgat. Az adatot standard és memóriahatékony módon kell formázni, hogy bárki tudjon [csomópontot futtatni](/run-a-node/) viszonylag szerény, fogyasztói szintű hardveren. Ehhez az Ethereum stackben számos speciális adatstruktúra található. + +## Előfeltételek {#prerequisites} + +Ehhez érdemes áttekinteni az Ethereum és a [kliensszoftver](/developers/docs/nodes-and-clients/) alapjait. Emellett javasoljuk, hogy a hálózati réteggel és az [Ethereum fehérkönyvvel](/whitepaper/) is ismerkedjen meg. + +## Adatstruktúrák {#data-structures} + +### Patricia Merkle-fák {#patricia-merkle-tries} + +A Patricia Merkle-fák olyan struktúrák, melyek kulcs-érték párokat kódolnak egy determinisztikus és kriptográfiailag hitelesített fastruktúrává. Ezeket kiterjedten használják az Ethereum végrehajtási rétegén. + +[Bővebben a Patricia Merkle-fákról](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### Rekurzív hosszúságú prefixum (RLP) {#recursive-length-prefix} + +A rekurzív hosszúságú prefixum (RLP) egy sorozatosítási módszer, melyet kiterjedten használnak az Ethereum végrehajtási rétegén. + +[További tudnivalók az RLP-ről](/developers/docs/data-structures-and-encoding/rlp) + +### Egyszerű sorosítás (SSZ) {#simple-serialize} + +Az egyszerű sorosítás (SSZ) a domináns sorosítási formátum az Ethereum konszenzus rétegén, mivel kompatibilis a merklelizációval. + +[További tudnivalók az SSZ-ről](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md new file mode 100644 index 00000000000..255ceabf37f --- /dev/null +++ b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -0,0 +1,263 @@ +--- +title: Merkle Patricia-fa +description: Bevezetés a Merkle Patricia-fa témájába. +lang: hu +sidebarDepth: 2 +--- + +Az Ethereum státusza (az összes számla, egyenleg és okosszerződés) bele van kódolva az informatikában Merkle-fa néven ismert adatszerkezet egy speciális változatába. Ez a struktúra számos kriptográfiai alkalmazásban hasznos, mert ellenőrizhető kapcsolatot hoz létre a fában összefonódott összes egyedi adat között, és egyetlen **gyökérértéket** eredményez, amely felhasználható az adatok bizonyítására. + +Az Ethereum adatszerkezete egy „módosított Merkle-Patricia-fa (trie)”, amely azért kapta ezt a nevet, mert a PATRICIA (Practical Algorithm To Retrieve Information Coded in Alphanumeric/gyakorlati algoritmus az alfanumerikusan kódolt információk visszakeresésére) néhány jellemzőjét kölcsönzi, továbbá az Ethereum státuszát alkotó elemek hatékony lekérdezésére (re**trie**val) tervezték. + +A Merkle-Patricia-fa determinisztikus és kriptográfiailag ellenőrizhető: a státusz gyökerét csak úgy lehet előállítani, ha azt a státusz minden egyes darabjából kiszámítjuk, és két azonos státusz könnyen bizonyítható a gyökér-hash és az ahhoz vezető hash-ek az összehasonlításával (_Merkle-bizonyíték_). Ezzel szemben nem lehet két különböző státuszt létrehozni ugyanazzal a gyökér-hash-értékkel, és minden olyan kísérlet, hogy a státuszt különböző értékekkel módosítsák, más státusz gyökér-hash-t eredményez. Elméletileg ez a struktúra biztosítja a `O(log(n))` hatékonyság „szent grálját” a beleírások, keresések és törlések esetében. + +A közeljövőben az Ethereum tervezi, hogy áttér a [Verkle-fastruktúrára](https://ethereum.org/en/roadmap/verkle-trees), amely új lehetőségeket nyit a jövőbeli protokollfejlesztések előtt. + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértése érdekben tekintse meg a [hashek](https://en.wikipedia.org/wiki/Hash_function), [Merkle-fák](https://en.wikipedia.org/wiki/Merkle_tree), [fák](https://en.wikipedia.org/wiki/Trie) és [sorosítás](https://en.wikipedia.org/wiki/Serialization) témákat. Ez a cikk egy alapvető [radix-fa](https://en.wikipedia.org/wiki/Radix_tree) leírásával kezdődik, majd lépésenként bemutatja az Ethereum optimalizáltabb adatszerkezetéhez szükséges módosításokat. + +## Alapvető radix-fák {#basic-radix-tries} + +Egy alapvető radix-fában minden csomópont a következőképpen néz ki: + +``` + [i_0, i_1 ... i_n, value] +``` + +Ahol `i_0 ... i_n` az ábécé (gyakran bináris vagy hexadecimális) szimbólumait jelöli, `value` a csomópontban lévő végérték, és az `i_0, i_1 ... i_n` a slotokban lévő értékek, melyek értéke `NULL` vagy más csomópontokra (itt hashekre) mutató mutatók. Ez egy alapvető `(key, value)` (kulcs, érték) tárolót alkot. + +Tegyük fel, hogy egy radixfa adatstruktúráját szeretnénk használni a kulcs-érték párosok halmaza feletti sorrend tárolására. Ahhoz, hogy megtaláljuk a `dog` kulcshoz jelenleg hozzárendelt értéket a fában, először a `dog` szót alakítjuk át az ábécé betűivé (amely `64 6f 67`), majd haladunk lefelé a fában, amíg meg nem találjuk az értéket. Ez azt jelenti, hogy a gyökérhash keresésével kezdjük egy kulcs/érték adatbázisban (DB), hogy megtaláljuk a fa gyökérpontját. Ez más (csomó)pontokra mutató kulcsok tömbjeként jelenik meg. Ehhez a `6`-os indexnél lévő értéket kulcsként használjuk, és ezt a kulcs-érték adatbázisban megkeressük, hogy megkapjuk az egy szinttel lejjebbi csomópontot. Ezután a `4`-es indexet választjuk a következő érték megkereséséhez, majd a `6`-os indexet, és így tovább, amíg egyszer végig nem követtük az utat: `gyökér -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, ekkor megnézzük a csomópont értékét, és visszaadjuk az eredményt. + +Különbség van aközött, hogy valamit a fában vagy az alapjául szolgáló kulcs-érték adatbázisban keresünk. Mindkettő kulcs-érték elrendezést definiál, de a mögöttes adatbázis képes a kulcsok hagyományos, egylépéses keresésére. Egy kulcs keresése a fában többszöri adatbáziskeresést igényel a végső érték eléréséhez. Az adatbáziskeresést nevezzük `path` néven, hogy kiküszöböljük a félreérthetőséget. + +A radix-fák frissítési és törlési műveletei a következőképpen definiálhatók: + +``` + def update(node,path,value): + curnode = db.get(node) if node else [ NULL ] * 17 + newnode = curnode.copy() + if path == '': + newnode[-1] = value + else: + newindex = update(curnode[path[0]],path[1:],value) + newnode[path[0]] = newindex + db.put(hash(newnode),newnode) + return hash(newnode) + + def delete(node,path): + if node is NULL: + return NULL + else: + curnode = db.get(node) + newnode = curnode.copy() + if path == '': + newnode[-1] = NULL + else: + newindex = delete(curnode[path[0]],path[1:]) + newnode[path[0]] = newindex + + if all(x is NULL for x in newnode): + return NULL + else: + db.put(hash(newnode),newnode) + return hash(newnode) +``` + +A „Merkle” radix-fa a csomópontok összekapcsolásával épül fel, determinisztikusan generált kriptográfiai hash digest-ek segítségével. Ez a tartalomcímzés (a kulcs-érték adatbázisban `key == keccak256(rlp(value))`) biztosítja a tárolt adatok kriptográfiai integritását. Ha egy adott fa gyökérhashe nyilvánosan ismert, akkor aki hozzáférhet a mögöttes levél szintű adatokhoz, bizonyítékot állíthat össze arra, hogy a fa egy adott értéket tartalmaz egy adott útvonalon, azáltal hogy megadja az egyes csomópontok hashét, amelyek egy adott értéket a fa gyökeréhez kapcsolnak. + +Egy támadó számára lehetetlen egy nem létező `(path, value)` pár bizonyítása, mivel a gyökérhash az összes alatta lévő hashre épül. A mögöttes adatok módosítása megváltoztatná a gyökérhasht. A hashre úgy is gondolhat, mint az adatok szerkezeti információinak tömörített reprezentációjára, amelyet a hashfüggvény előképvédelme (pre-image) biztosít. + +A radix-fa egy atomnyi egységére (például egyetlen hexadecimális karakter vagy 4 bites bináris szám) „nibble”-ként hivatkozunk. Miközben az útvonalat bejárjuk egy-egy nibble mentén, a csomópontnak legfeljebb 16 gyermeke lehet addig, amíg egy `value` értéket tartalmaz. Ezért ezeket 17 hosszúságú tömbként ábrázoljuk. Ezeket a 17 elemű tömböket „elágazási csomópontoknak” nevezzük. + +## Merkle Patricia-fa {#merkle-patricia-trees} + +A radix-fáknak egy fő korlátja van: nem hatékonyak. Ha egy `(path, value)` kötést szeretnénk tárolni, ahol az útvonal, mint az Ethereumban, 64 karakter hosszú (a `bytes32` nibble száma), akkor több mint egy kilobájtnyi extra helyre lesz szükségünk, hogy karakterenként egy szintet tároljunk, és minden keresés vagy törlés mind a 64 lépést megteszi. A bevezetett Patricia-fa megoldotta ezt a gondot. + +### Optimalizálás {#optimization} + +A Merkle Patricia-fa egy csomópontja az egyik a következőkből: + +1. `NULL` (egy üres string) +2. `branch` Egy 17 elemű csomópont `[ v0 ... v15, vt ]` +3. `leaf` Egy 2 elemű csomópont `[ encodedPath, value ]` +4. `extension` Egy 2 elemű csomópont `[ encodedPath, key ]` + +A 64 karakteres útvonalak esetén elkerülhetetlen, hogy a fa első néhány rétegének bejárása után olyan csomóponthoz érjünk, ahol legalább az út egy részén nem létezik elágazás. Annak elkerülése érdekében, hogy az útvonal mentén akár 15 ritka `NULL` csomópontot kelljen létrehozni, a lefelé haladást egy `extension` csomópont létrehozásával levágjuk, amely a `[ encodedPath, key ]` formájú, ahol `encodedPath` tartalmazza a „részleges útvonalat”, amelyet át kell ugrani (az alább ismertetett kompakt kódolással), és a `key` a következő DB-keresésre szolgál. + +Egy `level` (levél) csomópont esetében, amelyet a `encodedPath` első nibble-jében lévő jelölővel (flag) jelölhetünk, az útvonal kódolja az összes korábbi csomópont útvonalrészletét, és közvetlenül megnézhetjük a `value` mezőt. + +Ez az optimalizálás azonban kétértelműséget eredményez. + +A nibble-ekben történő útvonalak bejárásakor előfordulhat, hogy páratlan számú nibble-t kell bejárnunk, de minden adat `bytes` formátumban van tárolva. Nem lehet különbséget tenni például az `1` és a `01` nibble között (mindkettőt `<01>`-ként kell tárolni). A páratlan hosszúság megadásához a részleges útvonal elé egy jelölőt (flag) kell illeszteni. + +### Specifikáció: Hexadecimális szekvencia kompakt kódolása opcionális befejezővel {#specification} + +Mind a _páratlan és páros fennmaradó részleges útvonalhossz_, mind a _levél és bővítmény csomópont_ jelölése a fent leírtak szerint bármely 2 elemű csomópont részleges útvonalának első nibble-jében megtalálható. Az eredmény így néz ki: + + hex char bits | node type partial path length + ---------------------------------------------------------- + 0 0000 | extension even + 1 0001 | extension odd + 2 0010 | terminating (leaf) even + 3 0011 | terminating (leaf) odd + +A páros fennmaradó útvonalhossz (`0` vagy `2`) esetén mindig egy `0` „kitöltő” nibble következik. + +``` + def compact_encode(hexarray): + term = 1 if hexarray[-1] == 16 else 0 + if term: hexarray = hexarray[:-1] + oddlen = len(hexarray) % 2 + flags = 2 * term + oddlen + if oddlen: + hexarray = [flags] + hexarray + else: + hexarray = [flags] + [0] + hexarray + // hexarray now has an even length whose first nibble is the flags. + o = '' + for i in range(0,len(hexarray),2): + o += chr(16 * hexarray[i] + hexarray[i+1]) + return o +``` + +Példák: + +``` + > [ 1, 2, 3, 4, 5, ...] + '11 23 45' + > [ 0, 1, 2, 3, 4, 5, ...] + '00 01 23 45' + > [ 0, f, 1, c, b, 8, 10] + '20 0f 1c b8' + > [ f, 1, c, b, 8, 10] + '3f 1c b8' +``` + +Ez a Merkle Patricia-fa egy csomópontjának megadásához szükséges bővített kód: + +``` + def get_helper(node,path): + if path == []: return node + if node = '': return '' + curnode = rlp.decode(node if len(node) < 32 else db.get(node)) + if len(curnode) == 2: + (k2, v2) = curnode + k2 = compact_decode(k2) + if k2 == path[:len(k2)]: + return get(v2, path[len(k2):]) + else: + return '' + elif len(curnode) == 17: + return get_helper(curnode[path[0]],path[1:]) + + def get(node,path): + path2 = [] + for i in range(len(path)): + path2.push(int(ord(path[i]) / 16)) + path2.push(ord(path[i]) % 16) + path2.push(16) + return get_helper(node,path2) +``` + +### Példa fa {#example-trie} + +Tegyük fel, hogy egy olyan fát szeretnénk, amely négy út-érték párt tartalmaz `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. + +Először az elérési utakat és az értékeket `bytes` formába alakítjuk át. Az alábbiakban a _útvonalak_ tényleges bájt ábrázolását `<>` jelöli, bár a _values_ a könnyebb érthetőség érdekében továbbra is sztringként jelennek meg, `''` jelöléssel (ezek is `bytes` formában lennének): + +``` + <64 6f> : 'verb' + <64 6f 67> : 'puppy' + <64 6f 67 65> : 'coins' + <68 6f 72 73 65> : 'stallion' +``` + +Most létrehozunk egy ilyen fát a következő kulcs-érték párokkal a mögöttes adatbázisban: + +``` + rootHash: [ <16>, hashA ] + hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ] + hashB: [ <00 6f>, hashC ] + hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ] + hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] +``` + +Amikor egy csomópontra egy másik csomóponton belül hivatkozunk, akkor a `H(rlp.encode(node))` szerepel, ahol `H(x) = keccak256(x) if len(x) >= 32 else x` és `rlp.encode` az [RLP](/developers/docs/data-structures-and-encoding/rlp) kódolási függvény. + +Vegyük észre, hogy egy fa frissítésekor a kulcs-érték párt `(keccak256(x), x)` egy állandó keresőtáblában kell tárolni, _ha_ az újonnan létrehozott csomópont hossza >= 32. Ha a csomópont ennél rövidebb, nem kell tárolni, mivel az f(x) = x függvény megfordítható. + +## Fák az Ethereumban {#tries-in-ethereum} + +Az Ethereum végrehajtási rétegén minden Merkle-fa Merkle Patricia-fát használ. + +Egy blokk fejlécében 3 gyökér 3 fából származik. + +1. stateRoot (státuszgyökér) +2. transactionsRoot (tranzakciógyökér) +3. receiptsRoot (visszaigazolásgyökér) + +### Státuszfa {#state-trie} + +Egy globális státuszfa van, amely minden alkalommal frissül, amikor egy kliens feldolgoz egy blokkot. Ebben a `path` (útvonal) mindig `keccak256(ethereumAddress)` és a `value` (érték) mindig:`rlp(ethereumAccount)`. Tehát egy Ethereum `account` (számla) az egy 4 elemű tömb a következőkkel: `[nonce,balance,storageRoot,codeHash]`. Ezen a ponton érdemes megjegyezni, hogy ez a `storageRoot` (tárolási fa) egy másik Patricia-fa gyökere: + +### Tárolási fa {#storage-trie} + +A tárolási fa az, ahol _minden_ szerződésadat tárolódik. Minden számlához külön tárolási fa tartozik. Egy adott címen adott tárolási pozíción lévő értékek lekérdezéséhez szükség van a tárolási címre, a tárolt adat egész számú pozíciójára a tárolóban és a blokk azonosítójára. Ezek azután átadhatók a JSON-RPC API-ban definiált `eth_getStorageAt` paraméterként, például a 0 tárolóhelyén lévő adatok lekérdezéséhez erre a címre `0x295a70b2de5e3953354a6a8344e616ed314d7251`: + +``` +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} + +``` + +A tároló egyéb elemeinek visszakeresése bonyolultabb, mivel először ki kell számítani a tárolási fában elfoglalt pozíciót. A pozíciót a cím és a tárolási pozíció `keccak256` hasheként kell kiszámítani, mindkettőt balra nullákkal kitöltve 32 bájt hosszúságúra. Például az adatok pozíciója az 1-es tárolóhelyen erre a címre `0x391694e7e0b0cce554cb130d723a9d27458f9298`: + +``` +keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) +``` + +A Geth konzolban ez a következőképpen kalkulálható: + +``` +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +A `path` (útvonal) ezért `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. Ez már használható az adatok lekérdezésére a tároló fából: + +``` +curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 + +{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} +``` + +Megjegyzés: A `storageRoot` az Ethereum számlára alapvetően üres, ha az nem egy szerződéses számla. + +### Tranzakciófa {#transaction-trie} + +Minden blokkhoz külön tranzakciós fa tartozik, amely ismét `(key, value)` (kulcs, érték) párokat tárol. Az út `rlp(transactionIndex)`, amely azt a kulcsot jelöli, amely megfelel egy értéknek, amelyet a következők határoznak meg: + +``` +if legacyTx: + value = rlp(tx) +else: + value = TxType | encode(tx) +``` + +Bővebb információt az [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) dokumentációban talál. + +### Visszaigazolásfa {#receipts-trie} + +Minden blokknak saját visszaigazolásfája van. A `path` (útvonal): `rlp(transactionIndex)`. A `transactionIndex` az indexe a blokkban, melybe bekerült. A visszaigazolásfát sosem frissítik. A tranzakciófához hasonlóan vannak jelenlegi és régi visszaigazolások. Egy adott visszaigazolás lekérdezéséhez visszaigazolásfából szükség van a blokkban lévő tranzakció indexére, a visszaigazoláscsomagra (payload) és a tranzakciótípusra. A visszaigazolás lehet `Receipt` típusú, amely a `TransactionType` és a `ReceiptPayload` összeadása, vagy lehet `LegacyReceipt` típusú, amely `rlp([status, cumulativeGasUsed, logsBloom, logs])` kódként van meghatározva. + +Bővebb információt az [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) dokumentációban talál. + +## További olvasnivaló {#further-reading} + +- [Módosított Merkle Patricia-fa — Hogyan menti az Ethereum a státuszt](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [Merkle-használat az Ethereumban](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [Az Ethereum-fa megértése](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md new file mode 100644 index 00000000000..cbbebaeb807 --- /dev/null +++ b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md @@ -0,0 +1,163 @@ +--- +title: Rekurzív hosszúságú prefix (RLP) sorosítás +description: Az RLP-kódolás bemutatása az Ethereum végrehajtási rétegen. +lang: hu +sidebarDepth: 2 +--- + +A rekurzív hosszúságú prefixum (RLP) egy sorosítási módszer, melyet kiterjedten használnak az Ethereum végrehajtási rétegén. Az RLP a csomópontok közötti adatátvitelt szabványosítja helytakarékos formátumban. Az RLP célja a bináris adatok tetszőlegesen egymásba ágyazott tömbjeinek kódolása, és ez az elsődleges kódolási módszer, amelyet az Ethereum végrehajtási rétegén az objektumok sorosítására használnak. Az RLP fő célja a struktúra kódolása; a pozitív egész számok kivételével az RLP az egyes adattípusok (pl. karakterláncok, lebegőszámok) kódolását magasabb rendű protokollokra bízza. A pozitív egész számokat nagy endián bináris formában kell ábrázolni, vezető nullák nélkül (így az egész szám értéke nulla, ami üres bájttömbnek felel meg). A vezető nullákat tartalmazó, sorosított, pozitív egész számokat az RLP-t használó magasabb rendű protokolloknak érvénytelennek kell tekinteniük. + +További információkat talál [az Ethereum Sárgakönyvben (B függelék)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). + +Ahhoz, hogy az RLP-vel kódoljunk egy szótárt, a két javasolt kanonikus forma a következő: + +- a `[[k1,v1],[k2,v2]...]` kódot használjuk olyan kulcsokkal, melyek lexikográfiai sorrendben vannak +- a magasabb szintű Patricia-fa kódolást használjuk, mint az Ethereum + +## Definíció {#definition} + +Az RLP-kódolási funkció egy elemet vesz fel. Az elem a következő lehet： + +- egy sztring vagy karaktersorozat (bájttömb) az egy elem +- az elemek listája is egy elem +- egy pozitív egész szám egy tétel + +Például a következők mindegyike elem: + +- egy üres sztring; +- egy sztring, amely a „cat” (macska) szót tartalmazza; +- egy lista, melyben bármennyi sztring található; +- és az ennél bonyolultabb adatstruktúrák, mint `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. +- a szám `100` + +Érdemes megjegyezni, hogy az oldal további részében a sztring kifejezés a „bináris adat bizonyos számú bájtját” jelenti; nem használunk speciális kódolást, és a sztringek tartalmát nem ismerjük (kivéve a nem minimális pozitív egész számok elleni eseteknél). + +Az RPL kódolást a következő módon definiáljuk: + +- Pozitív egész szám esetén a legrövidebb bájttömbre konvertáljuk, amelynek nagy endián értelmezése az egész szám, majd az alábbi szabályok szerint sztringként kódoljuk. +- Egy bájt, amelynek értéke a `[0x00, 0x7f]` (decimális `[0, 127]`) tartományban van, annak RLP-kódolása önmaga. +- Máskülönben, ha a sztring 0–55 bájt hosszú, az RLP-kódolás egyetlen **0x80** (decimál 128) értékű bájtból és a sztring hosszából áll, amelyet a sztring követ. Az első bájt tartománya tehát `[0x80, 0xb7]` (dec. `[128, 183]`). +- Ha a sztring több mint 55 bájt hosszú, az RLP-kódolás egyetlen bájtból áll, amelynek értéke **0xb7** (dec. 183), valamint a sztring hossza bájtokban kifejezve bináris formában, ezt követi a sztring hossza, majd a sztring. Például egy 1024 bájt hosszú sztring kódolása `\xb9\x04\x00` (dec. `185, 4, 0`), amelyet a sztring követ. Itt `0xb9` (183 + 2 = 185) az első bájt, majd az a 2 bájt `0x0400` (dec. 1024) jön, amely az aktuális sztring hosszát jelöli. Az első bájt tartománya tehát `[0xb8, 0xbf]` (dec. `[184, 191]`). +- Ha egy sztring 2^64 bájt vagy hosszabb, akkor nem kódolható. +- Ha egy lista teljes payload-ja (azaz az összes RLP-kódolt elemének együttes hossza) 0–55 bájt hosszú, az RLP-kódolás egyetlen **0xc0** értékű bájtból és a payload hosszából áll, amelyet az elemek RLP-kódolásainak összekapcsolása követ. Az első bájt tartománya tehát `[0xc0, 0xf7]` (dec. `[192, 247]`). +- Ha egy lista teljes payload-ja több mint 55 bájt hosszú, az RLP-kódolás egyetlen **0xf7** értékű bájtból, valamint a payload hosszának bájtban kifejezett hosszából áll bináris formában, amelyet a payload hossza követ, majd az elemek RLP-kódolásainak összekapcsolása. Az első bájt tartománya tehát `[0xf8, 0xff]` (dec. `[248, 255]`). + +Ez kódban a következőképpen néz ki: + +```python +def rlp_encode(input): + if isinstance(input,str): + if len(input) == 1 and ord(input) < 0x80: + return input + return encode_length(len(input), 0x80) + input + elif isinstance(input, list): + output = '' + for item in input: + output += rlp_encode(item) + return encode_length(len(output), 0xc0) + output + +def encode_length(L, offset): + if L < 56: + return chr(L + offset) + elif L < 256**8: + BL = to_binary(L) + return chr(len(BL) + offset + 55) + BL + raise Exception("input too long") + +def to_binary(x): + if x == 0: + return '' + return to_binary(int(x / 256)) + chr(x % 256) +``` + +## Példák {#examples} + +- a „dog” sztring = [ 0x83, 'd', 'o', 'g' ] +- a [ "cat", "dog" ] lista = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` +- az üres sztring ('null') = `[ 0x80 ]` +- az üres lista = `[ 0xc0 ]` +- az integer 0 = `[ 0x80 ]` +- a '\\x00' bájt = `[ 0x00 ]` +- a '\\x0f' bájt = `[ 0x0f ]` +- a '\\x04\\x00' bájt = `[ 0x82, 0x04, 0x00 ]` +- a háromnak a [halmazelméleti ábrázolása](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- a „Lorem ipsum dolor sit amet, consectetur adipisicing elit” sztring = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` + +## RLP-dekódolás {#rlp-decoding} + +Az RLP-kódolás szabályai és folyamata szerint az RLP-dekódolás bemenete bináris adatok tömbjének tekinthető. Az RLP-dekódolási folyamat a következő: + +1. a bemeneti adatok első bájtja (azaz előtagja) alapján dekódolja az adattípust, a tényleges adat hosszát és az eltolást; + +2. az adatok típusának és eltolásának megfelelően dekódolja az adatokat, tiszteletben tartva a pozitív egész számokra vonatkozó minimális kódolási szabályt; + +3. folytatja a bemenet többi részének dekódolását; + +Ezek közül az adattípusok és az eltolás dekódolásának szabályai a következők: + +1. az adat egy sztring, ha az első bájt tartománya (az előtag) [0x00, 0x7f], és a sztring pontosan maga az első bájt; + +2. az adat egy sztring, ha az első bájt tartománya [0x80, 0xb7], és az első bájtot az a sztring követi, amelynek hossza egyenlő az első bájt mínusz 0x80; + +3. az adat egy sztring, ha az első bájt tartománya [0xb8, 0xbf], és a sztring hossza, amelynek hossza bájtokban egyenlő az első bájt mínusz 0xb7, követi az első bájtot, és a sztring követi a sztring hosszát; + +4. az adat egy lista, ha az első bájt tartománya [0xc0, 0xf7], és a lista minden olyan eleme RLP-kódolásának összekapcsolása, amelynek teljes payload-ja megegyezik az első bájttal mínusz 0xc0, az első bájtot követi; + +5. az adat egy lista, ha az első bájt tartománya [0xf8, 0xff], és a lista teljes payload-ja, amelynek hossza megegyezik az első bájttal mínusz 0xf7, követi az első bájtot, és a lista összes elemének RLP-kódolásának konkatenációja követi a lista teljes payload-ját; + +Ez kódban a következőképpen néz ki: + +```python +def rlp_decode(input): + if len(input) == 0: + return + output = '' + (offset, dataLen, type) = decode_length(input) + if type is str: + output = instantiate_str(substr(input, offset, dataLen)) + elif type is list: + output = instantiate_list(substr(input, offset, dataLen)) + output += rlp_decode(substr(input, offset + dataLen)) + return output + +def decode_length(input): + length = len(input) + if length == 0: + raise Exception("input is null") + prefix = ord(input[0]) + if prefix <= 0x7f: + return (0, 1, str) + elif prefix <= 0xb7 and length > prefix - 0x80: + strLen = prefix - 0x80 + return (1, strLen, str) + elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): + lenOfStrLen = prefix - 0xb7 + strLen = to_integer(substr(input, 1, lenOfStrLen)) + return (1 + lenOfStrLen, strLen, str) + elif prefix <= 0xf7 and length > prefix - 0xc0: + listLen = prefix - 0xc0; + return (1, listLen, list) + elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): + lenOfListLen = prefix - 0xf7 + listLen = to_integer(substr(input, 1, lenOfListLen)) + return (1 + lenOfListLen, listLen, list) + raise Exception("input does not conform to RLP encoding form") + +def to_integer(b): + length = len(b) + if length == 0: + raise Exception("input is null") + elif length == 1: + return ord(b[0]) + return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 +``` + +## További olvasnivaló {#further-reading} + +- [RLP az Ethereumon](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [Ethereum háttérműködése: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Coglio, A. (2020). Ethereum Rekurzív hosszúságú prefix (RLP) az ACL2-ben. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) + +## Kapcsolódó témák {#related-topics} + +- [Patricia Merkle-fa](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md new file mode 100644 index 00000000000..e66f02ea6eb --- /dev/null +++ b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md @@ -0,0 +1,149 @@ +--- +title: Egyszerű sorosítás (SSZ) +description: Az Ethereum egyszerű sorosítási (SSZ) formátumának magyarázata. +lang: hu +sidebarDepth: 2 +--- + +Az **egyszerű sorosítás (SSZ)** a Beacon láncon használt sorosítási módszer. Ezt használják a konszenzusrétegben, a végrehajtási rétegben használt RLP sorosítás helyett, kivéve a társak megkeresésének protokolljánál. Az SSZ determinisztikus és hatékonyan Merkle-szerűsít. Az SSZ két komponensből áll: egy sorosítási sémából és egy Merkle-szerűsítő sémából, amelyet úgy terveztek, hogy hatékonyan dolgozzon a sorosított adatstruktúrával. + +## Hogyan működik az SSZ? {#how-does-ssz-work} + +### Sorosítás {#serialization} + +Az SSZ egy olyan sorosítási séma, amely nem önleíró – inkább egy sémára támaszkodik, amelyet előre ismerni kell. Az SSZ sorosítás célja, hogy tetszőleges összetettségű objektumokat bájtsorozatként ábrázoljon. Ez egy egyszerű folyamat az alaptípusokra. Az elemet egyszerűen hexadecimális bájtokká alakítja. Az alaptípusok a következők: + +- nem aláírt egész számok +- Boolean-ek + +Az „összetett” típusok esetében a sorosítás bonyolultabb, mivel az összetett típus több elemet tartalmaz, amelyek különböző típusúak vagy különböző méretűek lehetnek, vagy mindkettő. Ha ezek az objektumok mind fix hosszúságúak (azaz az elemek mérete mindig állandó lesz, függetlenül a tényleges értékeiktől), akkor a sorosítás az összetett típus minden egyes elemének kis-endian bájtsztringekké történő átalakítása. Ezeket a bájtsztringeket összekapcsolják. A sorosított objektum a fix hosszúságú elemek bájtlista reprezentációját tartalmazza ugyanabban a sorrendben, ahogyan azok a deszerializált objektumban szerepelnek. + +A változó hosszúságú típusok esetében a tényleges adatok helyébe egy „eltolási” (offszet) érték lép az adott elem pozíciójában a sorosított objektumban. A tényleges adatok egy halomba kerülnek a sorosított objektum végén. Az eltolási érték a halomban lévő tényleges adatok kezdetének indexe, amely a megfelelő bájtokra mutató mutatóként szolgál. + +Az alábbi példa azt szemlélteti, hogyan működik az eltolás fix és változó hosszúságú elemeket tartalmazó konténer esetében: + +```Rust + + struct Dummy { + + number1: u64, + number2: u64, + vector: Vec, + number3: u64 + } + + dummy = Dummy{ + + number1: 37, + number2: 55, + vector: vec![1,2,3,4], + number3: 22, + } + + serialized = ssz.serialize(dummy) + +``` + +A `serialized` a következő szerkezetű lenne (itt 4 bitre van kitöltve, a valóságban 32 bitre van, és az áttekinthetőség kedvéért `int` ábrázolást használunk): + +``` +[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] +------------ ----------- ----------- ----------- ---------- + | | | | | + number1 number2 offset for number 3 value for + vector vector + +``` + +az áttekinthetőség érdekében sorokra osztva: + +``` +[ + 37, 0, 0, 0, # little-endian encoding of `number1`. + 55, 0, 0, 0, # little-endian encoding of `number2`. + 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16). + 22, 0, 0, 0, # little-endian encoding of `number3`. + 1, 2, 3, 4, # The actual values in `vector`. +] +``` + +Ez még mindig egyszerűsítés – a fenti ábrákon szereplő egész számok és nullák valójában bájtlistákként lennének tárolva, például így: + +``` +[ + 10100101000000000000000000000000 # little-endian encoding of `number1` + 10110111000000000000000000000000 # little-endian encoding of `number2`. + 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16). + 10010110000000000000000000000000 # little-endian encoding of `number3`. + 10000001100000101000001110000100 # The actual value of the `bytes` field. +] +``` + +Így a változó hosszúságú típusok tényleges értékei egy halomban tárolódnak a sorosított objektum végén, a mezők rendezett listájában a megfelelő pozíciókban tárolt eltolási értékeikkel együtt. + +A speciális esetek különleges kezelést igényelnek, mint például a `BitList` típus, amelyhez a sorosítás során hosszkorlátot kell hozzáadni, majd a deszerializáció során eltávolítani azt. További részletek az [SSZ specifikációban](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) találhatók. + +### Deszerializáció {#deserialization} + +Az objektum deszerializációjához szükség van a sémára. A séma meghatározza a sorosított adatok pontos elrendezését, hogy minden egyes elemet egy bájtblob-ból valamilyen értelmes objektummá lehessen deszerializálni, amelynek elemei a megfelelő típusúak, értékűek, méretűek és pozíciójúak. A séma az, amely megmondja a deszerializátornak, hogy mely értékek ténylegesek, és melyek az eltolási értékek. Az objektum sorosításakor minden mezőnév eltűnik, de a séma szerinti deszerializáláskor újra létrejön. + +Tekintse meg az [ssz.dev](https://www.ssz.dev/overview) oldalt egy interaktív magyarázatért. + +## Merkle-szerűsítés {#merkleization} + +Ez az SSZ sorosított objektum ezután Merkle-szerűsíthető, azaz átalakítható ugyanazon adatok Merkle-fa reprezentációjává. Először meg kell határozni a 32 bájtos darabok számát a sorosított objektumban. Ezek a fa levelei. A levelek teljes számának 2 hatványának kell lennie, hogy a levelek összevonása végül egyetlen hashfagyökeret eredményezzen. Ha ez magától nem így van, akkor további 32 bájtnyi nullát tartalmazó levelek kerülnek hozzáadásra. Ezt így ábrázolhatjuk: + +``` + hash tree root + / \ + / \ + / \ + / \ + hash of leaves hash of leaves + 1 and 2 3 and 4 + / \ / \ + / \ / \ + / \ / \ + leaf1 leaf2 leaf3 leaf4 +``` + +Vannak olyan esetek is, amikor a fa levelei nem egyenletesen oszlanak el, ahogy azt a fenti példa mutatja. A 4. levél például egy több elemet tartalmazó konténer lehet, amely további „mélységet” igényel a Merkle-fához, ami egy egyenetlen fát hoz létre. + +Ahelyett, hogy ezeket a faelemeket X. levélnek, X. csomópontnak stb. neveznénk, általános indexeket adhatunk nekik, kezdve a gyökérrel = 1 és balról jobbra számozva minden szinten. Ez a fentebb ismertetett általánosított index. A sorosított lista minden egyes elemének általános indexe `2**depth + idx`, ahol idx a nullával indexelt pozíciója a sorosított objektumban, a mélység (depth) pedig a Merkle-fa szintjeinek száma, amely az elemek (levelek) számának kettes bázisú logaritmusaként határozható meg. + +## Általánosított indexek {#generalized-indices} + +Az általánosított index egy egész szám, amely egy csomópontot jelöl egy bináris Merkle-fában, ahol minden csomópontnak van egy általánosított indexe `2 ** depth + index in row`. + +``` + 1 --depth = 0 2**0 + 0 = 1 + 2 3 --depth = 1 2**1 + 0 = 2, 2**1+1 = 3 + 4 5 6 7 --depth = 2 2**2 + 0 = 4, 2**2 + 1 = 5... + +``` + +Ez az ábrázolás a Merkle-fa minden egyes adatához egy csomópontindexet ad. + +## Többszörös bizonyítékok {#multiproofs} + +Az általánosított indexek listájának megadása, mely egy adott elemet reprezentál, lehetővé teszi, hogy ellenőrizzük azt a hashfa gyökerével szemben. Ez a gyökér az általunk elfogadott valóság. Bármelyik adatot ellenőrizhetjük ezzel a valósággal szemben, ha beillesztjük a Merkle-fa megfelelő helyére (amelyet az általánosított indexe határoz meg), és megfigyeljük, hogy a gyökér állandó marad-e. A [specifikációban](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) vannak olyan függvények, amelyek megmutatják, hogyan lehet kiszámítani a csomópontok minimális halmazát, amely egy adott általános indexkészlet tartalmának ellenőrzéséhez kell. + +Például az alábbi fa 9-es indexében lévő adatok ellenőrzéséhez szükségünk van a 8, 9, 5, 3, 1 indexben lévő adatok hashére. A (8,9) hashnek meg kell egyeznie a (4) hashsel, amely az 5-tel hashelve a 2-t adja, amely a 3-mal hashelve az 1-es fa gyökerét adja. Ha a 9-hez helytelen adatokat adnánk meg, a gyökér megváltozna – ezt észlelnénk, és nem tudnánk ellenőrizni az ágat. + +``` +* = data required to generate proof + + 1* + 2 3* + 4 5* 6 7 +8* 9* 10 11 12 13 14 15 + +``` + +## További olvasnivaló {#further-reading} + +- [Az Ethereum frissítése: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) +- [Az Ethereum frissítése: Merkle-szerűsítés](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [SSZ implementációk](https://github.com/ethereum/consensus-specs/issues/2138) +- [SSZ kalkulátor](https://simpleserialize.com/) +- [SSZ.dev](https://www.ssz.dev/) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md new file mode 100644 index 00000000000..0c5dca6215b --- /dev/null +++ b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md @@ -0,0 +1,189 @@ +--- +title: Web3 titkos tárhely meghatározása +description: A web3 titkos tárolás hivatalos definíciója +lang: hu +sidebarDepth: 2 +--- + +Ahhoz, hogy az Ön alkalmazása az Ethereumon működjön, használhatja a web3 objektumot, amit a web3.js könyvtár biztosít. A háttérben RPC híváson keresztül egy helyi csomóponttal kommunikál. A [web3](https://github.com/ethereum/web3.js/) bármelyik Ethereum csomóponttal működőképes, mely nyilvánossá tesz egy RPC réteget. + +A `web3` az `eth` objektumot tartalmazza: web3.eth. + +```js +var fs = require("fs") +var recognizer = require("ethereum-keyfile-recognizer") + +fs.readFile("keyfile.json", (err, data) => { + var json = JSON.parse(data) + var result = recognizer(json) +}) + +/** result + * [ 'web3', 3 ] web3 (v3) keyfile + * [ 'ethersale', undefined ] Ethersale keyfile + * null invalid keyfile + */ +``` + +Ez a dokumentum a web3 titkos tárolási definíciójának **3. verzióját** dokumentálja. + +## Definíció {#definition} + +A fájl tényleges kódolása és dekódolása nagyrészt változatlan marad az 1. verzióhoz képest, kivéve, hogy a titkosítási algoritmus már nem AES-128-CBC-hez van kötve (az AES-128-CTR a minimális követelmény). A legtöbb jelentés és algoritmus hasonló az 1. verzióhoz, kivéve a `mac`, amely a származtatott kulcs bal szélső második 16 bájtjának és a teljes `ciphertextnek` a SHA3 (keccak-256) kombinációjaként van megadva. + +A titkos kulcsfájlok közvetlenül a `~/.web3/keystore` (Unix-szerű rendszerekre) és a `~/AppData/Web3/keystore` (Windows esetén) mappákban vannak tárolva. A nevük bármi lehet, de egy jó elnevezési logika a `.json`, ahol `` a titkos kulcshoz adott 128 bites UUID (a titkos kulcs címének adatvédelmet biztosító proxy). + +Minden ilyen fájlhoz tartozik egy jelszó. Egy adott `.json` fájl titkos kulcsának létrehozásához először a fájl titkosítási kulcsát kell létrehozni; ez úgy történik, hogy a fájl jelszavát fogjuk és átadjuk a `kdf` kulcs által megadott kulcskészítő függvénynek. A KDF-től függő statikus és dinamikus paraméterek a `kdfparams` kulcsban vannak leírva. + +A PBKDF2-t minden minimálisan megfelelő implementációnak támogatnia kell az alábbi módon: + +- `kdf`: `pbkdf2` + +A PBKDF2-höz a kdfparams tartalmazza: + +- `prf`: `hmac-sha256` kell legyen (talán a jövőben ki lesz terjesztve); +- `c`: iterációk száma; +- `salt`: a PBKDF-nek átadott salt; +- `dklen`: a létrehozott kulcs hossza. Muszáj, hogy >= 32 legyen. + +Miután a fájl kulcsát létrehoztuk, azt a MAC származtatásával kell ellenőrizni. A MAC-et a származtatott kulcs bal szélső második 16 bájtjának és a `ciphertext` kulcs tartalmának összekapcsolásából képzett bájttömb SHA3 (keccak-256) hasheként kell kiszámítani: + +```js +KECCAK(DK[16..31] ++ ) +``` + +(ahol a `++` az összeadási művelet) + +Ezt az értéket össze kell hasonlítani a `mac` kulcs tartalmával; ha eltérnek, alternatív jelszót kell kérni (vagy a műveletet törölni). + +A fájl kulcsának ellenőrzése után a titkosított szöveg (a fájlban szereplő `ciphertext` kulcs) visszafejthető a `cipher` kulcs által meghatározott és a `cipherparams` kulcson keresztül paraméterezett szimmetrikus titkosítási algoritmus segítségével. Ha a származtatott kulcs mérete és az algoritmus kulcsmérete nem egyezik, akkor a származtatott kulcs nullával kitöltött, jobb szélső bájtjait kell használni az algoritmus kulcsaként. + +Minden minimálisan megfelelő implementációnak támogatnia kell az AES-128-CTR algoritmust, amelyet a következőkkel jelölnek: + +- `cipher: aes-128-ctr` + +Ez a titkosító a következő paramétereket veszi fel, amelyeket a cipherparams kulcshoz adott kulcsként kell megadni: + +- `iv`: 128 bites inicializálási vektor a titkosításhoz. + +A titkosítás kulcsa a származtatott kulcs bal szélső 16 bájtja, azaz `DK[0..15]` + +A titkos kulcs létrehozása vagy titkosítása lényegében ezen utasítások fordítottja. Győződjön meg arról, hogy a `uuid`, `salt` és `iv` valóban véletlenszerű. + +A `version` mezőn kívül, amelynek a verzió „kemény” azonosítójaként kell működnie, a megvalósítások használhatják a `minorversion` mezőt is a formátum kisebb, nem megszakított változásainak követésére. + +## Tesztvektorok {#test-vectors} + +Részletek: + +- `Address`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` +- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` +- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` +- `Password`: `testpassword` +- `Secret`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` + +### PBKDF2-SHA-256 {#PBKDF2-SHA-256} + +A tesztvektor `AES-128-CTR` és `PBKDF2-SHA-256` kódot használ: + +A `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json` fájltartalma: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "6087dab2f9fdbbfaddc31a909735c1e6" + }, + "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", + "kdf": "pbkdf2", + "kdfparams": { + "c": 262144, + "dklen": 32, + "prf": "hmac-sha256", + "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" + }, + "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Köztes értékek**: + +`Derived key`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` `MAC Body`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` `MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` `Cipher key`: `f06d69cdc7da0faffb1008270bca38f5` + +### Scrypt {#scrypt} + +A tesztvektor AES-128-CTR és Scrypt-et használ: + +```json +{ + "crypto": { + "cipher": "aes-128-ctr", + "cipherparams": { + "iv": "740770fce12ce862af21264dab25f1da" + }, + "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" + }, + "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" + }, + "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", + "version": 3 +} +``` + +**Köztes értékek**: + +`Derived key`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` `MAC Body`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` `MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` `Cipher key`: `7446f59ecc301d2d79bc3302650d8a5c` + +## Módosítások az 1. változathoz képest {#alterations-from-v2} + +Ez a verzió számos inkonzisztenciát javított ki az [itt](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst) publikált 1. verzióhoz képest. Ezek röviden: + +- A nagybetűs írásmód indokolatlan és következetlen (scrypt kisbetűs, Kdf vegyes, MAC nagybetűs). +- A cím felesleges és veszélyezteti az adatvédelmet. +- `Salt` eredendően a kulcslétrehozási függvény paramétere, és ahhoz kell hozzárendelni, nem pedig általában a kriptográfiához. +- _SaltLen_ fölösleges (a Salt-ból le lehet vezetni). +- A kulcslétrehozási függvény adott, de a titkosítási algoritmus nehezen meghatározott. +- `Version` eredendően numerikus, mégis egy sztring (a strukturált verziókezelés lehetséges lenne egy sztringgel, de egy ritkán változó konfigurációs fájlformátum esetében ez nem releváns). +- `KDF` és `cipher` fogalmilag testvérek, mégis másképp szerveződnek. +- `MAC` egy szóköz agnosztikus adatdarabon keresztül kerül kiszámításra(!) + +A formátumot úgy változtattuk meg, hogy a következő fájlt kapjuk, amely funkcionálisan megegyezik a korábban hivatkozott oldal példájával: + +```json +{ + "crypto": { + "cipher": "aes-128-cbc", + "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", + "cipherparams": { + "iv": "16d67ba0ce5a339ff2f07951253e6ba8" + }, + "kdf": "scrypt", + "kdfparams": { + "dklen": 32, + "n": 262144, + "p": 1, + "r": 8, + "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" + }, + "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", + "version": 1 + }, + "id": "0498f19a-59db-4d54-ac95-33901b4f1870", + "version": 2 +} +``` + +## Módosítások az 2. változathoz képest {#alterations-from-v2} + +A 2. verzió egy korai C++ implementáció volt számos hibával. Minden lényeges dolog változatlan maradt. diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/index.md new file mode 100644 index 00000000000..25cdf44a6cc --- /dev/null +++ b/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/index.md @@ -0,0 +1,155 @@ +--- +title: Hálózati réteg +description: Bevezetés az Ethereum hálózati rétegébe. +lang: hu +sidebarDepth: 2 +--- + +Az Ethereum egy peer-to-peer hálózat több ezer csomóponttal, amelyeknek szabványosított protokollokkal kommunikálnak egymással. A hálózati réteg azon protokollok halmaza, amelyek lehetővé teszik, hogy ezek a csomópontok megtalálják egymást és információt cseréljenek. Ez magában foglalja az információk pletykálását (egy a sokhoz kommunikáció) a hálózaton keresztül, valamint a kérések és válaszok cseréjét bizonyos csomópontok között (egy az egyhez kommunikáció). Minden csomópontnak be kell tartania bizonyos hálózati szabályokat, hogy biztosítsa a megfelelő információk küldését és fogadását. + +A kliensszoftver két részből áll (végrehajtási és konszenzusos kliensek), mindegyiknek különálló hálózati stackje van. A többi Ethereum-csomóponttal való kommunikáció mellett a végrehajtási és konszenzusos klienseknek egymással is kommunikálniuk kell. Ez az oldal magyarázatot ad a kommunikációs protokollokról. + +A végrehajtási kliensek tranzakciókat pletykálnak a végrehajtási réteg peer-to-peer hálózatán. Ehhez titkosított kommunikáció szükséges a hitelesített társak között. Amikor egy validátort kiválasztanak blokkelőterjesztésre, a csomópont helyi tranzakciógyűjtőjéből tranzakciókat ad át a konszenzusos kliensnek egy helyi RPC kapcsolaton, melyeket Beacon blokkokba csomagol. A konszenzusos kliensek ezután pletykálnak a Beacon blokkokról a saját p2p hálózatukon. Ehhez két elkülönített p2p hálózat kell: az egyik összeköti a végrehajtási klienseket a tranzakciópletykával, a másik a konszenzusos klienseket a blokkpletykával. + +## Előfeltételek {#prerequisites} + +E téma könnyebb megértéséhez tekintse meg az Ethereum [csomópontok és kliensek](/developers/docs/nodes-and-clients/) témáját. + +## A végrehajtási réteg {#execution-layer} + +A végrehajtási réteg hálózati protokolljai két részre oszlanak: + +- a felfedező stack: az UDP portra épül, és lehetővé teszi, hogy egy új csomópont megtalálja a társait, amelyekhez csatlakozhat + +- a DevP2P stack: a TCP port tetején helyezkedik el, és lehetővé teszi a csomópontok számára az információcserét + +A stackek párhuzamosan működnek. A felfedező stack új résztvevőket hoz a hálózatba, a DevP2P pedig lehetővé teszi ezek interakcióit. + +### Felfedezés {#discovery} + +A felfedezés a hálózatban lévő más csomópontok megtalálásának folyamata. Ez egy kis számú beöltő csomópont (bootnode) segítségével történik (amelyek címe [be van kódolva](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) a kliensbe, hogy azonnal megtalálhatók legyenek, és összekapcsolják a klienst a társaival). Ezek a betöltő csomópontok azért léteznek, hogy egy új csomópontot bemutassanak a társaiknak – nincs más céljuk, nem vesznek részt a normál kliensfeladatokban, például a lánc szinkronizálásában, és csak a kliens legelső indításakor használják őket. + +A betöltőcsomópont-csomópont interakció protokollja a [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) egy módosított formája, amely egy [elosztott hash táblát](https://en.wikipedia.org/wiki/Distributed_hash_table) használ a csomópontlista megosztására. Minden csomópont rendelkezik ezzel a táblával, hogy a szükséges információk birtokában legyen, amikor a legközelebbi társaihoz csatlakozik. A közelség nem földrajzi, hanem a csomópont azonosítójának hasonlósága határozza meg. A csomópontoknál lévő táblázat biztonsági okokból rendszeresen frissül. Például a [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) felfedezőprotokoll csomópontjai képesek „hirdetéseket” is küldeni, amelyek megjelenítik a kliens által támogatott alprotokollokat, lehetővé téve a társak számára, hogy tárgyaljanak a protokollokról, amelyeken keresztül mindketten kommunikálni tudnak. + +A felfedezés egy ping-pong-játékkal kezdődik. A sikeres ping-pong egy betöltő csomóponthoz „köti” az új csomópontot. A kezdeti üzenet, amely a betöltő csomópontot figyelmezteti a hálózatba belépő új csomópont létezésére, egy `PING`. Ez a `PING` hashelt információkat tartalmaz az új csomópontra, a betöltő csomópontra és a lejárati időre vonatkozóan. A betöltő csomópont fogadja a `PING`-et, és visszaküld egy `PONG`-ot, amely tartalmazza a `PING` hasht. Ha a `PING` és `PONG` hashek egyeznek, akkor az új csomópont és a betöltő csomópont közötti kapcsolat le van ellenőrizve, és „összekapcsolódtak”. + +Miután összekapcsolódott, az új csomópont küldhet egy `FIND-NEIGHBOURS` kérést a betöltő csomópontnak. A betöltő csomópont által visszaküldött adatok tartalmazzák azoknak a partnereknek a listáját, amelyekhez az új csomópont csatlakozhat. Ha a csomópontok nincsenek összekötve, a `FIND-NEIGHBOURS` kérés sikertelen lesz, így az új csomópont nem tud belépni a hálózatba. + +Amint az új csomópont megkapja a betöltő csomóponttól a szomszédok listáját, mindegyikükkel PING-PONG cserét kezd. A sikeres PING-PONG-ok összekötik az új csomópontot a szomszédjaival, lehetővé téve az üzenetváltást. + +``` +start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours +``` + +A végrehajtási kliensek jelenleg a [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) felfedezőprotokollt használják, és aktív erőfeszítéseket tesznek a [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) protokollra való áttérésre. + +#### ENR: Ethereum csomópontfeljegyzés {#enr} + +A [Ethereum csomópontrekord (ENR)](/developers/docs/networking-layer/network-addresses/) egy objektum, amely három alapvető elemet tartalmaz: egy aláírást (a rekord tartalmának egy elfogadott azonosítási séma szerinti hashe), egy sorszámot, amely a rekord változását követi, és kulcs-érték párok tetszőleges listáját. Ez egy jövőbiztos formátum, amellyel az azonosító adatok könnyebben cserélhetők az új társak között, valamint ez az Ethereum-csomópontok preferált [hálózati cím](/developers/docs/networking-layer/network-addresses) formátuma. + +#### Miért épül a felfedezés az UDP-re? {#why-udp} + +Az UDP nem támogatja a hibaellenőrzést, a sikertelen csomagok újraküldését vagy a kapcsolatok dinamikus megnyitását és lezárását – ehelyett egy folyamatos információáramlást küld a célpontnak, függetlenül attól, hogy sikeresen fogadja-e azt. Ez a minimális funkcionalitás minimális költséget is jelent, így ez a kapcsolat nagyon gyors. A felfedezéshez, amikor egy csomópont egyszerűen csak jelezni akarja jelenlétét, hogy aztán hivatalos kapcsolatot létesítsen egy társsal, elegendő az UDP. A hálózati stack többi része számára azonban az UDP nem felel meg a célnak. A csomópontok közötti információcsere meglehetősen összetett, ezért egy teljesebb funkciójú protokollra van szükség, amely támogatja az újraküldést, a hibaellenőrzést stb. A TCP-hez kapcsolódó többletköltség megéri a többletfunkciókat. Ezért a P2P stack nagy része TCP-n keresztül működik. + +### DevP2P {#devp2p} + +A DevP2P a protokollok egész halmaza, amelyet az Ethereum a peer-to-peer hálózat létrehozásához és fenntartásához implementál. Miután az új csomópontok belépnek a hálózatba, interakcióikat a [DevP2P](https://github.com/ethereum/devp2p) stack protokolljai szabályozzák. Ezek mind a TCP-re épülnek, és magukban foglalják az RLPx transzport protokollt, a vezetékes protokollt és számos alprotokollt. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) a csomópontok közötti munkamenetek kezdeményezését, hitelesítését és fenntartását szabályozó protokoll. Az RLPx az RLP (Rekurzív hosszúságú prefixum) segítségével kódolja az üzeneteket, ami egy helytakarékos módszer az adatok minimális struktúrába történő kódolására, hogy azokat a csomópontok közötti küldhessék. + +A két csomópont közötti RLPx kapcsolódás egy kezdeti kriptográfiai kézfogással kezdődik. Ennek során a csomópont hitelesítő üzenetet küld, amelyet a társ ellenőriz. Sikeres ellenőrzés esetén a társ egy hitelesítést igazoló üzenetet generál, amelyet visszaküld a kezdeményezőnek. Ez egy kulcscserélési folyamat, amely lehetővé teszi a csomópontok számára a privát és biztonságos kommunikációt. A sikeres kriptográfiai kézfogás után mindkét csomópont „hello” üzenetet küld egymásnak „a vezetéken”. A vezetékes protokollt a hello üzenetek sikeres cseréje indítja el. + +A helló üzenetek a következőt tartalmazzák: + +- protokoll verziója +- kliensazonosító +- port +- csomópont-azonosító +- a támogatott alprotokollok listája + +Ez a sikeres interakcióhoz szükséges információ, mivel meghatározza, hogy a két csomópont milyen képességeket oszt meg egymással, és konfigurálja a kommunikációt. Létezik egy alprotokoll-tárgyalási folyamat, amelynek során az egyes csomópontok által támogatott alprotokollok listáját összehasonlítják, és a két csomópont számára közös alprotokollok használhatók a kapcsolódásban. + +A hello üzenetek mellett a vezetékes protokoll „szétkapcsolási” üzenetet is küldhet, amely figyelmeztetést ad a társnak, hogy a kapcsolat lezárul. A vezetékes protokoll PING és PONG üzeneteket is tartalmaz, amelyeket időszakosan küld a munkamenet nyitva tartása érdekében. Az RLPx és a vezetékes protokollok cseréje tehát megteremti a csomópontok közötti kommunikáció alapjait, és biztosítja a hasznos információk cseréjének keretét egy adott alprotokoll szerint. + +### Alprotokollok {#sub-protocols} + +#### Vezetékes protokoll {#wire-protocol} + +Miután a partnerek csatlakoztak, és az RLPx kapcsolódás elindult, a vezetékes protokoll határozza meg, hogy a partnerek hogyan kommunikálnak egymással. Kezdetben a vezetékes protokoll három fő feladatot határozott meg: a láncszinkronizációt, a blokkelőterjesztést és a tranzakciók cseréjét. Miután azonban az Ethereum átállt a proof-of-stake-re, a blokkelőterjesztés és a láncszinkronizáció a konszenzusréteg részévé vált. A tranzakciók cseréje továbbra is a végrehajtási kliensek hatáskörébe tartozik. A tranzakciók cseréje a függőben lévő tranzakciók csomópontok közötti cseréjére utal, hogy a blokképítők kiválaszthassanak közülük néhányat a következő blokkba. Bővebb információk [itt](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) érhetők el ezekről a feladatokról. Az ezeket az alprotokollokat támogató kliensek a [JSON-RPC](/developers/docs/apis/json-rpc/) segítségével teszik közzé azokat. + +#### Les (könnyű Ethereum alprotokoll) {#les} + +Ez egy minimális protokoll a könnyű kliensek szinkronizálásához. Ezt a protokollt ritkán használják, mivel a teljes csomópontoknak ösztönzés nélkül kell adatokat szolgáltatniuk a könnyű klienseknek. A végrehajtási kliensek alapértelmezett viselkedése az, hogy nem szolgálják ki a könnyű klienseket a Les-en keresztül. Bővebb információ található a Les [specifikációban](https://github.com/ethereum/devp2p/blob/master/caps/les.md). + +#### Snap {#snap} + +A [snap protokoll](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) egy opcionális kiterjesztés, amely lehetővé teszi, hogy a társak pillanatfelvételeket cseréljenek a legutóbbi státuszokról, így anélkül ellenőrizhetik a számla- és tárolási adatokat, hogy közbenső Merkle-fa csomópontokat kellene letölteniük. + +#### Wit (tanúprotokoll) {#wit} + +A [tanúprotokoll](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) egy opcionális kiterjesztés, amely lehetővé teszi a státusztanúk cseréjét a társak között, hogy a kliensek szinkronizálva legyenek a lánc elejéhez. + +#### Whisper {#whisper} + +A Whisper egy olyan protokoll, amelynek célja a biztonságos üzenetváltás biztosítsa a társak között anélkül, hogy bármilyen információt írna a blokkláncra. A DevP2P vezetékes protokoll része volt, de már elavult. Más [kapcsolódó projektek](https://wakunetwork.com/) is léteznek hasonló célokkal. + +## A konszenzusréteg {#consensus-layer} + +A konszenzusos kliensek egy különálló, eltérő specifikációjú peer-to-peer hálózatban vesznek részt. A konszenzusos kliensek részt kell venniük a blokkpletykában, hogy új blokkokat kaphassanak a társaiktól, és továbbíthassák azokat, amikor rájuk kerül a sor, hogy blokkot javasoljanak. A végrehajtási réteghez hasonlóan ehhez is először egy felfedező protokollra van szükség, hogy a csomópont megtalálja a társait, és biztonságos kapcsolódásokat hozzon létre a blokkok, igazolások stb. cseréjéhez. + +### Felfedezés {#consensus-discovery} + +A végrehajtási kliensekhez hasonlóan a konszenzusos kliensek is [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5)-öt használnak UDP-n keresztül a társak megkereséséhez. A discv5 konszenzusréteg implementációja csak annyiban különbözik a végrehajtási kliensekétől, hogy tartalmaz egy illesztőt, amely a discv5-öt egy [libP2P](https://libp2p.io/) stackbe kapcsolja, elavulttá téve ezzel a DevP2P-t. A végrehajtási réteg RLPx kapcsolódásait elhagyták a libP2P zajmentes csatornáján való kézfogásért. + +### ENR-ek {#consensus-enr} + +A konszenzus csomópontok ENR-je tartalmazza a csomópont nyilvános kulcsát, IP-címét, UDP- és TCP-portjait, valamint két konszenzusspecifikus mezőt: a tanúsítást végző alhálózat bitmezőjét és az `eth2` kulcsot. Az előbbi megkönnyíti a csomópontok számára, hogy megtalálják az adott tanúsítási pletyka alhálózatokban részt vevő társaikat. Az `eth2` kulcs információt tartalmaz arról, hogy a csomópont melyik Ethereum elágazási (fork) verziót használja, így biztosítva, hogy a társak a megfelelő Ethereumhoz kapcsolódjanak. + +### libP2P {#libp2p} + +A libP2P stack a felfedezés után minden kommunikációt támogat. A kliensek tárcsázhatnak és hallgathatják az IPv4 és/vagy IPv6 protokollt az ENR-ben meghatározottak szerint. A libP2P réteg protokolljai feloszthatók a pletyka és a kérés/válasz (req/resp) domainekre. + +### Pletyka {#gossip} + +A pletyka domainbe tartozik minden információ, amelynek gyorsan kell terjednie a hálózaton. Ezek a Beacon-blokkok, bizonyítékok, tanúsítások, kilépések és kizárások. Ezt a libP2P gossipsub v1 segítségével továbbítják, ami a csomópontokon helyileg tárolt metaadatokra támaszkodik, beleértve a fogadható és továbbítandó pletykacsomagok maximális méretét. A pletyka domain további információt megtalálja [itt](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). + +### Kérés-válasz {#request-response} + +A kérés-válasz domain olyan protokollokat tartalmaz, amelyekkel a kliensek konkrét információkat kérhetnek a társaiktól. Például bizonyos Beacon blokkok lekérése, melyek bizonyos gyökérhasheknek megfelelnek vagy egy slottartományba esnek. A válaszok mindig snappy-tömörített SSZ-kódolt bájtként érkeznek vissza. + +## Miért részesíti előnyben a konszenzusos kliens az SSZ-t az RLP-vel szemben? {#ssz-vs-rlp} + +Az SSZ jelentése egyszerű sorosítás. Fix offszeteket használ, amelyek megkönnyítik a kódolt üzenet egyes részeinek dekódolását anélkül, hogy a teljes struktúrát dekódolni kellene, ami hasznos a konszenzusos kliens számára, mivel hatékonyan ki tudja venni a kódolt üzenetekből az információrészeket. Kifejezetten a Merkle protokollokkal való integrációra is tervezték, ami a Merkle-szerűsítés hatékonyságának növelésével jár. Mivel a konszenzusrétegben minden hash Merkle-gyök, ez jelentős javulást jelent. Az SSZ garantálja az értékek egyedi ábrázolását is. + +## A végrehajtási és konszenzusos kliensek kapcsolódása {#connecting-clients} + +A konszenzusos és végrehajtási kliensek párhuzamosan futnak. Össze kell kapcsolódniuk, hogy a konszenzusos kliens utasításokat adhasson a végrehajtási kliensnek, a végrehajtási kliens pedig tranzakciókötegeket adhasson át a konszenzusos kliensnek, hogy azok bekerülhessenek a Beacon blokkokba. A két kliens közötti kommunikáció helyi RPC-kapcsolat segítségével valósítható meg. Egy [Engine-API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) néven ismert API határozza meg a két kliens között küldött utasításokat. Mivel mindkét kliens egyetlen hálózati identitás mögött helyezkedik el, megosztanak egy ENR-t (Ethereum csomópontfeljegyzés), amely mindkét kliens számára külön kulcsot tartalmaz (eth1 és eth2 kulcs). + +A kontrollfolyamat összefoglalása az alábbiakban látható, zárójelben a vonatkozó hálózati stackkel. + +### Amikor a konszenzusos kliens nem terjeszt elő blokkot: {#when-consensus-client-is-not-block-producer} + +- A konszenzusos kliens blokkot kap a blokkpletyka-protokollon keresztül (konszenzus p2p) +- A konszenzusos kliens előzetesen validálja a blokkot, azaz biztosítja, hogy az érvényes feladótól érkezett, helyes metaadatokkal +- A blokkban lévő tranzakciókat a végrehajtási rétegnek küldik el végrehajtási csomagként (helyi RPC-kapcsolat) +- A végrehajtási réteg végrehajtja a tranzakciókat és ellenőrzi a blokkfejlécben lévő státuszt (azaz a hashek egyezését) +- A végrehajtási réteg visszaadja a validációs adatokat a konszenzus rétegnek, a blokk validáltnak tekinthető (helyi RPC kapcsolat) +- A konszenzus réteg hozzáadja a blokkot a saját blokkláncának fejéhez és tanúsítja azt, a tanúsítást a hálózaton keresztül küldi szét (konszenzus p2p) + +### Amikor a konszenzusos kliens blokkot terjeszt elő: {#when-consensus-client-is-block-producer} + +- A konszenzusos kliens értesítést kap arról, hogy ő a következő blokkelőterjesztő (konszenzus p2p) +- A konszenzusréteg meghívja a `blokk létrehozása` metódust a végrehajtási kliensben (helyi RPC) +- A végrehajtási réteg hozzáfér a tranzakciós memóriakészlethez, amelyet a tranzakciós pletykaprotokoll töltött fel (végrehajtási p2p) +- A végrehajtási kliens a tranzakciókat egy blokkba foglalja, végrehajtja a tranzakciókat és létrehoz egy blokk hasht +- A konszenzusos kliens átveszi a tranzakciókat és a blokk hasht a végrehajtási klienstől, és hozzáadja azokat a Beacon-blokkhoz (helyi RPC) +- A konszenzusos kliens a blokkot a blokkpletyka-protokollon keresztül továbbítja (konszenzus p2p) +- A többi kliens megkapja a javasolt blokkot a blokkpletyka-protokollon keresztül, és a fent leírtak szerint validálja (konszenzus p2p) + +Amint a blokkot elegendő validátor tanúsította, a lánc fejéhez adják, igazolják és végül véglegesítik. + +![](cons_client_net_layer.png) ![](exe_client_net_layer.png) + +A hálózati réteg sémája a konszenzus- és végrehajtási kliensek számára, az [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) honlapról + +## További olvasnivaló {#further-reading} + +[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [Konszenzusréteg hálózati specifikáció](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [Kademlia to discv5](https://vac.dev/kademlia-to-discv5) [Kademlia leírás](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [Bevezetés az Ethereum p2p-be](https://p2p.paris/en/talks/intro-ethereum-networking/) [Eth1 és eth2 kapcsolata](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [A Beolvadásról és eth2 kliensrészletekről szóló videó](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md new file mode 100644 index 00000000000..79417cf574c --- /dev/null +++ b/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md @@ -0,0 +1,38 @@ +--- +title: Hálózati címek +description: Bevezetés a hálózati címekbe. +lang: hu +sidebarDepth: 2 +--- + +Az Ethereum csomópontoknak azonosítaniuk kell magukat néhány alapvető információval, hogy a társaikhoz tudjanak kapcsolódni. Annak érdekében, hogy a lehetséges társak értelmezni tudják ezeket az információkat, három szabványosított formátumban továbbítják, amelyeket bármely Ethereum-csomópont megérthet: multiaddr, enode vagy Ethereum Node Records (ENRs). Az ENRs az Ethereum hálózati címek jelenlegi szabványa. + +## Előfeltételek {#prerequisites} + +A jelen téma könnyebb megértéséhez érdemes megtekinteni az Ethereum [hálózati rétegéről](/developers/docs/networking-layer/) szóló oldalt. + +## Multiaddr {#multiaddr} + +Az eredeti Ethereum csomópontcím formátuma a multiaddr (a multi-addresses rövidítése) volt. A multiaddr egy egyetemes formátum a peer-to-peer hálózatokhoz. A címek kulcs-érték párokként jelennek meg, a kulcsok és az értékek perjellel vannak elválasztva. Például a multiaddr értéke a `192.168.22.27` IPv4-címmel rendelkező csomópontnak, ami a `33000` TCP-portot figyeli: + +`/ip4/192.168.22.27/tcp/33000` + +Az Ethereum csomópont esetében a multiaddr tartalmazza a csomópont-azonosítót (a nyilvános kulcs hashe): + +`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` + +## Enode {#enode} + +Az enode az Ethereum-csomópontok azonosítására szolgál egy URL-címformátum segítségével. A hexadecimális csomópont-ID az URL felhasználónevet tartalmazó részében van kódolva, a hoszttól @ jellel elválasztva. A hosztnév csak IP-címként adható meg; DNS nevek nem engedélyezettek. A hosztnév szakaszban szereplő port a TCP figyelő port. Ha a TCP és UDP (felfedező) portok különböznek, az UDP portot a „discport” lekérdezési paraméterként kell megadni + +A következő példában a csomópont URL-címe egy olyan csomópontot ír le, amelynek IP-címe `10.3.58.6`, TCP-portja `30303` és UDP felfedezőportja `30301`. + +`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` + +## Ethereum Node Records (ENRs) {#enr} + +Az Ethereum Node Records (ENR) a hálózati címek szabványosított formátuma az Ethereumon. Ez váltotta fel a multiaddr és az enode használatát. Ezek különösen hasznosak, mert nagyobb információcserét tesznek lehetővé a csomópontok között. Az ENR tartalmaz egy aláírást, egy sorszámot és olyan mezőket, melyek az aláírások létrehozására és érvényesítésére használt azonosítási rendszert részletezik. Az ENR tetszőleges, kulcs-érték párokba rendezett adatokkal is feltölthető. Ezek a kulcs-érték párok tartalmazzák a csomópont IP-címét és a csomópont által használható alprotokollokra vonatkozó információkat. A konszenzus kliensek egy [specifikus ENR struktúrát](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) használnak a betöltőcsomópontok (bootnode) azonosítására, és tartalmaznak egy `eth2` mezőt is, amely az aktuális Ethereum elágazásról és a tanúsításpletyka alhálózatról tartalmaz információt (ez köti a csomópontot a társak egy adott csoportjához, akiknek tanúsításait aggregálják). + +## További olvasnivaló {#further-reading} + +[EIP-778: Ethereum Node Records (ENR)](https://eips.ethereum.org/EIPS/eip-778) [Hálózati címek az Ethereumban](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md new file mode 100644 index 00000000000..ef98d696462 --- /dev/null +++ b/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md @@ -0,0 +1,89 @@ +--- +title: Portal Network +description: Áttekintés a Portal Network-ről, egy fejlesztés alatt álló hálózatról, mely a kevés forrással bíró klienseket támogatja. +lang: hu +--- + +Az Ethereum egy számítógépekből álló hálózat, melyek az Ethereum kliensszoftvert futtatják. Minden ilyen számítógépet csomópontnak neveznek. A kliensszoftver lehetővé teszi, hogy a csomópont adatot tudjon küldeni és fogadni az Ethereum hálózaton, és hozzá tudja ellenőrizni az adatokat az Ethereum protokollszabályokhoz. A csomópontok rengeteg historikus adatot tárolnak a merevlemezen, és az új információs csomagokat, vagyis blokkokat hozzáadják ezekhez, melyeket a hálózat többi csomópontjától kapnak. Ez azért szükséges, hogy ellenőrizhető legyen, egy csomópont a hálózat többi részével konzisztens információkat tartalmaz. Tehát a csomópontok üzemeltetéséhez sok tárhelyre van szükség. Néhány csomópont működés sok RAM-ot is igényel emellett. + +A tárhely probléma megoldására fejlesztettek könnyű csomópontokat, amelyek nem maguk tárolják az információt, hanem lekérik azt a teljes csomópontoktól. Ez ugyanakkor azt is jelenti, hogy a könnyű csomópont nem független módon ellenőrzi az információt, hanem egy másik csomópontban bízik. Emellett a teljes csomópontoknak egy extra feladatot kell ellátni, amikor kiszolgálják ezeket a könnyű csomópontokat. + +A Portal Network egy új hálózati dizájn az Ethereumon, amely az adatelérhetőségi problémákat hivatott megoldani a könnyű csomópontok esetében anélkül, hogy bízniuk kellene másban vagy a teljes csomópontot terhelnénk vele, és ehhez a szükséges információt kis darabokban osztják meg a hálózaton. + +Bővebben a [csomópontokról és kliensekről](/developers/docs/nodes-and-clients/) + +## Miért van szükség Portal Networkre? {#why-do-we-need-portal-network} + +Az Ethereum csomópontok a saját teljes vagy részleges másolatukat tárolják az Ethereum blokkláncról. Ezt a helyi másolatot használják a tranzakciók validálására, és arra, hogy a csomópont a megfelelő láncot kövesse. Ez a helybeli másolat lehetővé teszi, hogy a csomópontok független módon ellenőrizzék a bejövő adatok érvényességét és helyességét, anélkül hogy egy másik entitásban kellene megbízniuk. + +A blokklánc, a kapcsolódó státusz és a visszaigazolási adatok a csomópont merevlemezén rengeteg helyet foglalnak. Például egy 2 TB merevlemez kell egy olyan csomópont futtatásához, mely [Geth-et](https://geth.ethereum.org) használ egy konszenzusos klienssel párban. A snap-szinkronizálás használatával, amely csak a viszonylag friss blokkok láncadatait tárolja, a Geth kb. 650 GB lemezterületet foglal el, de kb. 14 GB/hét sebességgel növekszik (a csomópontot időszakosan vissza lehet vágni 650 GB-ra). + +Tehát a csomópont futtatása költséges lehet, mert nagy tárhelyet kell dedikálni az Ethereumnak. Az Ethereum ütemterve számos megoldást kínál erre a problémára, beleértve az [előzményadatok lejáratát](/roadmap/statelessness/#history-expiry), [státuszlejáratot](/roadmap/statelessness/#state-expiry) és [státuszmentességet](/roadmap/statelessness/). Ugyanakkor ezek bevezetésére még kell várni néhány évet. Emellett működnek [könnyű csomópontok](/developers/docs/nodes-and-clients/light-clients/), amelyek nem mentenek saját adatot a láncról, hanem a teljes csomópontoktól kérdezik le a szükséges információkat. Ekkor azonban a könnyű csomópontnak meg kell bíznia a teljes csomópontban, hogy korrekt adatot szolgáltat, és még terhet is jelent a teljes csomópontnak. + +A Portal Network célja, hogy alternatív módot biztosítson a könnyű csomópontoknak, hogy hozzájussanak az adatokhoz bizalomigény nélkül, és nem növeli jelentősen a teljes csomópontok által elvégzendő munkát. Ennek módja az Ethereum csomópontok számára, hogy az adatot másképpen kell megosztani a hálózaton. + +## Hogyan működik a Portal Network? {#how-does-portal-network-work} + +Az Ethereum csomópontok szigorú protokollt követnek abban, hogyan kommunikálnak egymással. A végrehajtási kliensek a kommunikációhoz néhány alprotokollt használnak, mint a [DevP2P](/developers/docs/networking-layer/#devp2p), miközben a konszenzusos kliensek egy másik adagot, amit [libP2P](/developers/docs/networking-layer/#libp2p) néven neveznek. Ezek határozzák meg a csomópontok között átadható adattípusokat. + +![devP2P és libP2P](portal-network-devp2p-libp2p.png) + +A csomópontok emellett specifikus adatokat is tudnak adni a [JSON-RPC API](/developers/docs/apis/json-rpc/) révén, amely az a mód, ahogy az alkalmazások és tárcák cserélnek információt az Ethereum csomópontokkal. Ugyanakkor ezek egyike sem az ideális megoldás a könnyű kliensek kiszolgálására. + +A könnyű kliensek nem tudnak adatot szerezni a láncról a DevP2P vagy libP2p protokollok révén, mert ezeket szinkronizálásra és a blokkokról és tranzakciókról szóló pletykákhoz tervezték. A könnyű kliens nem akarja letölteni ezeket az információkat, mert akkor nem lenne könnyű súlyú. + +A JSON-RPC API azért nem jó, mert egy specifikus teljes csomóponton vagy egy közpinti RPC szolgáltatón múlik, hogy adatot adjon. Ekkor a könnyű kliensnek meg kellene bíznia a csomópontban vagy a szolgáltatóban, hogy az jóhiszemű, továbbá a teljes csomópontot is leterheli és nagyobb sávszélesség kell neki, ha egyszerre több könnyű kliens több kéréssel fordul hozzá. + +A Portal Network lényege, hogy újragondolja az egész dizájnt, kifejezetten a könnyedségre építve, a meglévő Ethereum-kliensek tervezési korlátain kívül. + +A Portal Network lényege, hogy a jelenlegi hálózati stack legjobb részeit használja ki azáltal, hogy lehetővé teszi, hogy a könnyű kliensek számára szükséges információkat, például az előzményadatokat és a lánc fejének beazonosítását egy könnyű, DevP2P stílusú peer-to-peer decentralizált hálózaton keresztül szolgáltassák ki, amely egy [DHT-t](https://en.wikipedia.org/wiki/Distributed_hash_table) használ (hasonlóan a Bittorrenthez). + +Az ötlet lényege, hogy minden egyes csomóponthoz hozzáadnák a teljes Ethereum előzményadatainak kis részét és néhány konkrét csomóponti feladatot. Ezután a kéréseket úgy szolgálnák ki, hogy megkeresik az adatokat tároló csomópontot és azoktól lekérdezik azt. + +Ez megfordítja azt a szokásos modellt, amelyben a könnyű csomópontok egyetlen csomópontot találnak, és felkérik őket nagy mennyiségű adat szűrésére és kiszolgálására; ehelyett gyorsan megszűrik a csomópontok nagy hálózatát, amelyek mindegyike kis mennyiségű adatot kezel. + +A cél az, hogy a könnyű súlyú Portal kliensek decentralizált hálózata a következőket tegye: + +- a lánc elejét, vagyis legfrissebb állapotát kövesse +- szinkronizálja a jelenlegi és a historikus láncadatokat +- státuszadatokat szerezzen +- tranzakciókat terjesszen el +- tranzakciókat hajtson végre az [EVM](/developers/docs/evm/) révén + +Ennek a hálózati dizájnnak az előnyei: + +- csökkenti a központi szolgáltatóktól való függést +- csökkenti az internet sávszélességi igényt +- minimális vagy nulla szinkronizálásra van szükség +- A kevés erőforrással bíró eszközök esetében is működőképes (<1 GB RAM, <100 MB merevlemez, 1 CPU) + +Az alábbi ábra a meglévő kliensek azon funkcióit mutatja be, amelyeket a Portal Network biztosíthat, lehetővé téve a felhasználók számára, hogy ezeket a funkciókat nagyon alacsony erőforrásigényű eszközökön is elérjék. + +### A Portal Network hálózatok + +| Beacon könnyű kliens | Státuszhálózat | Tranzakciópletyka | Előzményadatok hálózata | +| -------------------- | -------------------------- | --------------------- | ----------------------- | +| Beacon lánc könnyű | Számla- és szerződéstároló | Könnyű memóriakészlet | Fejlécek | +| Protokolladatok | | | Blokktestek | +| | | | Visszaigazolások | + +## Alapértelmezett kliensdiverzitás {#client-diversity-as-default} + +A Portal Network fejlesztői már eleve három elkülönült klienst építenek az első naptól fogva. + +A Portal Network kliensei a következők: + +- [Trin](https://github.com/ethereum/trin): Rust nyelven írva +- [Fluffy](https://nimbus.team/docs/fluffy.html): Nim nyelven írva +- [Ultralight](https://github.com/ethereumjs/ultralight): Typescript nyelven írva +- [Shisui](https://github.com/optimism-java/shisui): Go nyelven írva + +A több független kliensimplementáció növeli az Ethereum-hálózat rugalmasságát és decentralizációját. + +Ha az egyik kliensnél problémák vagy sebezhetőségek merülnek fel, a többi kliens zavartalanul működhet tovább, megelőzve az egyetlen hibapont kialakulását. Emellett az eltérő klienshasználat elősegíti az innovációt és a versenyt, ösztönzi a fejlesztéseket és csökkenti a monokultúra kockázatát az ökoszisztémán belül. + +## További olvasnivaló {#futher-reading} + +- [A Portal Network (Piper Merriam előadása a Devconon, Bogotában)](https://www.youtube.com/watch?v=0stc9jnQLXA). +- [A Portal Network Discord csatornája](https://discord.gg/CFFnmE7Hbs) +- [A Portal Network honlapja](https://www.ethportal.net/) diff --git a/public/content/translations/hu/26) Miscellaneous/about/index.md b/public/content/translations/hu/26) Miscellaneous/about/index.md new file mode 100644 index 00000000000..e4e973e3646 --- /dev/null +++ b/public/content/translations/hu/26) Miscellaneous/about/index.md @@ -0,0 +1,129 @@ +--- +title: Rólunk +description: A csapatról, közösségről és az ethereum.org küldetéséről +lang: hu +--- + +# Az ethereum.org-ról {#about-ethereumorg} + +Az ethereum.org egy nyilvános, nyílt forráskódú információs forrás az Ethereum közösségnek, amelyhez bárki hozzájárulhat. Egy kicsi központi csapat elhivatottan dolgozik az oldal fenntartásán és fejlesztésén, és ebben több ezer közösségi tag segíti őket a világ minden tájáról. + +**Az ethereum.org-tól senki sem lép Önnel kapcsolatba. Ne válaszoljon ilyesmire!** + +## Megjegyzés a nevekkel kapcsolatban {#a-note-on-names} + +Általános dolog, hogy az emberek összekeverik az Ethereum világába tartozó neveket, így nem tudnak az Ethereum működéséről valós képet kapni. Az alábbiakban gyorsan összefoglalnánk, hogy mi micsoda: + +### Ethereum {#ethereum} + +Az Ethereum egy nyilvános hálózat, egy blokklánc és egy nyílt forráskódú protokoll, melyet egy globális közösség sok tízezernyi tagja működtet, irányít, kezel és birtokol, és amely közösség fejlesztőkből, csomópont-üzemeltetőkből, ETH-szel rendelkezőkből és felhasználókból áll. + +[Bővebben az Ethereumról](/what-is-ethereum/) + +[Bővebben az Ethereum irányításáról](/governance/) + +### Ether (ETH) {#ether-or-eth} + +Az Ether (melyet ETH-ként is láthat) a natív valuta, mellyel az Ethereumon tranzakciókat hajtanak végre. Az Ethereum hálózat használatáért ETH-ben kell fizetni (tranzakciós díjak formájában). Az ETH-t arra is használják, hogy a letétbe helyezés révén biztosítsa a hálózatot. Amikor arról van szó, hogy mi az Ethereum ára, akkor az ETH-re gondolnak. + +[Bővebben az ETH-ről](/eth/) + +[Bővebben az ETH letétbe helyezéséről](/staking/) + +### Ethereum Alapítvány {#ethereum-foundation} + +Egy non-profit szervezet, melyet eredetileg az ETH tömeges eladásával alapítottak meg, és az Ethereum hálózat és ökoszisztéma dedikált támogatója. + +[Bővebben az Ethereum Alapítványról](/foundation/) + +### ethereum.org {#ethereum-org} + +Egy nyilvános, nyílt forráskódú weboldal és tudásbázis az Ethereum közössége számára. Az ethereum.org oldalt egy kicsi központi csapat vezeti, melyet az Ethereum Alapítvány hozott létre, és több ezer közösségi tag közreműködik benne a világ minden tájáról. + +Ez a cikk további információkat tartalmaz az ethereum.org-ról. + +## Küldetésünk {#our-mission} + +**Az ethereum.org küldetése, hogy a legjobb portál legyen az Ethereum egyre növekvő közössége számára** + +Arra törekszünk, hogy egy könnyen érthető tudástárat építsünk minden Ethereumhoz kapcsolódó témáról, hogy az új felhasználók megismerhessék az Ethereumot és fontos koncepcióit. Szeretnénk: + +- elmagyarázni az Ethereumot bárkinek, akinek új ez a technológia +- segíteni az új felhasználónak belekezdeni az ETH és az Ethereum használatába +- segíteni az új fejlesztőknek, hogy építésbe fogjanak +- bemutatni az Ethereum világának változásait, híreit +- bemutatni a közösség által készített anyagokat +- lehetővé tenni az Ethereum oktatást annyi nyelven, amennyin csak lehetséges + +E küldetést elérni, ezért a csapatunk a következő két elsődleges célra koncentrál az ethereum.org-on: + +### 1. Az ethereum.org látogatók felhasználó élményének javítása {#visitors} + +- A tartalom kiterjesztése új témákra, fejlesztése és frissítése +- A használhatóság és az elérhetőség fejlesztése a lokalizáció és a webfejlesztés bevált gyakorlatai által +- A felhasználói elköteleződés növelése olyan funkciókkal, mint a kérdőívek, kvízek és web3 integrációk +- A honlapot megőrizzék könnyűsúlyú és hatékonyan működő állapotában + +### 2. A közreműködők közössége növekedjen, erősödjön és alkalmas legyen {#community} + +- A honlaphoz hozzájárulók számának növelése +- A közreműködők megtartásának javítása a bevonás, elismerés és díjak révén +- A közösség tagjait alkalmassá tenni arra, hogy egyre növekvő, jelentős hozzájárulásokat tegyenek +- A közreműködés sokszínűségének elősegítése: kód, tartalom, dizájn, fordítás, moderálás +- A kódbázis modern, tiszta és jól dokumentált legyen + +## Alapelveink {#core-principles} + +A következő fő elvek segítenek nekünk teljesíteni a küldetést. + +### 1. Az ethereum.org egy portál az Ethereumra {#core-principles-1} + +Szeretnénk felkelteni a felhasználók érdeklődését és megválaszolni a kérdéseiket. Tehát portálunk egyszerre szolgáltat információkat, „varázslatos pillanatokat” és hozzáférést a közösség által létrehozott kiváló anyagokhoz. A honlap tartalma nem helyettesíti a már meglévő, kiterjedt forrásokat, hanem bevezeti a felhasználókat a témákba és elérhetővé teszi ezeket az anyagokat. Szeretnénk támogatni és integrálni a közösség által felépített tudásbázist, hogy azok láthatóbbak és felfedezhetőbbek legyenek. [Az Ethereum közösség](/community/) ennek a középpontjában áll: nemcsak a közösséget szolgáljuk, hanem együttműködünk a tagjaival és felhasználjuk a visszajelzéseiket. A weboldal nem csak a mostani közösségnek szól, hanem annak is, amelyhez reményeink szerint felfejlődhetünk. Emlékeznünk kell arra, hogy közösségünk globális, és sok nyelvből, régióból és kultúrából származó embereket tartalmaz. + +### 2. Az ethereum.org folyamatosan fejlődik {#core-principles-2} + +Az Ethereum és a közösség folyamatosan fejlődik, így az ethereum.org is fejlődni fog. Emiatt van az oldalnak egyszerű dizájnrendszere és moduláris struktúrája. Iteratív változtatásokat hajtunk végre az alapján, hogy az emberek hogyan használják a webhelyet, és mit akar tőle a közösség. Nyílt forráskóddal működünk, és a közreműködők közösségével dolgozunk, így Ön is tehet javaslatot változtatásokra vagy segíthet is nekünk a különféle feladatokban. [Bővebben a közreműködésről](/contributing/) + +### 3. Az ethereum.org nem egy tipikus termékről szóló weboldal {#core-principles-3} + +Az Ethereum egy nagy dolog: magában foglal egy közösséget, egy technológiát, egy sor elképzelést és ideológiát, és még sok mást. Ez azt jelenti, hogy a weboldalnak sok különböző felhasználói utat le kell fednie a „fejlesztőtől, aki egy bizonyos eszközt szeretne kifejleszteni” egészen az „újoncig, aki vett valamennyi ETH-et és még nem tudja, mi az a tárca”. „Melyik a legjobb blokklánc platform weboldal?” marad az örökérvényű kérdés – mi úttörők vagyunk. Egy ilyen felépítéséhez kísérletezés szükséges. + +## Az ethereum.org ütemterve {#roadmap} + +Az ethereum.org csapat negyedéves ütemtervet publikál az aktuális célokról, hogy a tevékenységét elérhetőbbé tegye és elősegítse a közösségi közreműködéseket. + +[Tekintse meg a 2024. 3. negyedévére vonatkozó ütemtervünket](https://github.com/ethereum/ethereum-org-website/issues/13399) + +**Hogy hangzik?** Nagyra értékeljük, ha visszajelzést ad az ütemtervükkel kapcsolatban! Ha bármivel kapcsolatban úgy véli, hogy foglalkoznunk kellene vele, tudassa velünk! Szívesen fogadjuk a közösség bármelyik tagjától az ötleteket és a beadott kérvényeket (PR, mint pull request). + +**Szeretne Ön is részt venni?** [Tudjon meg többet a közreműködésről](/contributing/), [kövessen minket Twitteren](https://twitter.com/ethdotorg), vagy csatlakozzon a közösségi megbeszélésekhez a [Discord szerveren](https://discord.gg/ethereum-org). + +## Tervezési elvek {#design-principles} + +A honlappal kapcsolatos tartalmi és dizájn jellegű megbeszéléseket a [dizájnelvek](/contributing/design-principles/) vezérlik. + +## Dizájnrendszer {#design-system} + +Egy [dizájnrendszert](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1) hoztunk létre és tettünk közzé, hogy az új jellemzőket gyorsabban be tudjuk vezetni, illetve a közösség tagjai is részt tudjanak venni az ethereum.org nyilvános dizájnjában. + +Szeretne Ön is részt venni?[Kövesse a témát a Figmában](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System), a [GitHub issue-knál](https://github.com/ethereum/ethereum-org-website/issues/6284) és csatlakozzon a [#design Discord csatornán](https://discord.gg/ethereum-org) folyó beszélgetésekhez. + +## Stílusútmutató {#style-guide} + +Elérhető egy [stílusútmutató](/contributing/style-guide/), hogy a tartalomírás bizonyos aspektusait összehangolja, és így a hozzájárulás folyamata is egyszerűbb lesz. + +Kérjük, hogy tekintse át az [elveinket](/contributing/design-principles/) és a [stílusútmutatót](/contributing/style-guide/), ha szeretne [hozzájárulni a honlaphoz](/contributing/). + +Ha bármi észrevétele van a dizájnelvekkel, dizájnrendszerrel és a stílusútmutatóval kapcsolatban, azt jelezze felénk. Ne feledje, az ethereum.org a közösségért van a közösség által. + +## Licenc {#license} + +Az ethereum.org honlap nyílt forráskódú és az [MIT License](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE) vonatkozik rá, hacsak másképp nincs megadva. Bővebben az ethereum.org [felhasználási feltételeiről](/terms-of-use/). + +## Álláslehetőségek {#open-jobs} + +Habár ez a honlap nyílt forráskódú és bárki dolgozhat rajta, egy dedikált csapat dolgozik az ethereum.org és más Ethereum Alapítványi webprojektek jobbá tételén. + +Itt megtalálhatja az aktuális álláslehetőségeket. Ha nem lát Önhöz illeszkedő pozíciót, akkor nézzen át a [Discord szerverünkre](https://discord.gg/ethereum-org) és mondja el nekünk, hogyan szeretne velünk dolgozni! + +Az ethereum.org csapaton túli lehetőségek is érdeklik? [Nézze meg az Ethereumhoz kapcsolódó további álláslehetőségeket](/community/get-involved/#ethereum-jobs/). diff --git a/public/content/translations/hu/26) Miscellaneous/enterprise/index.md b/public/content/translations/hu/26) Miscellaneous/enterprise/index.md new file mode 100644 index 00000000000..41f49c4ccac --- /dev/null +++ b/public/content/translations/hu/26) Miscellaneous/enterprise/index.md @@ -0,0 +1,161 @@ +--- +title: Vállalatok az Ethereum főhálózaton +description: Útmutatók, cikkek és eszközök a nyilvános Ethereum blokkláncon lévő vállalati alkalmazásokról +lang: hu +--- + +# Az Ethereum vállalatok számára {#ethereum-for-enterprise} + +Az Ethereum sokféle vállalkozásnak segíthet, beleértve a nagyvállalatokat is: + +- Növelni a bizalmat és csökkenteni az üzleti partnerek közötti koordináció költségét +- Javítani a felelősségre vonhatóságot és a működtetési hatékonyságot az üzleti hálózatokban +- Új üzleti modelleket és értékteremtő lehetőségeket kifejleszteni +- Versenyképesen jövőbiztossá tenni a szervezeteiket + +A korai években számos vállalati blokklánc-alkalmazást építettek privát, engedélyköteles, Ethereum-kompatibilis blokkláncokra vagy konzorciumláncokra. Manapság a technológiai fejlődésnek köszönhetően, mely nagyobb tranzakcióátvitelt, alacsonyabb tranzakciós költségeket és adatvédelmet tesz lehetővé, a legtöbb vállalati alkalmazás, mely Ethereum-technológiát használ, a publikus Ethereum főhálózatra vagy [L2](/layer-2) láncokra épül. + + +## Források {#enterprise-resources} + +### További olvasnivaló {#further-reading} + +Nem technikai információs anyagok annak megértéséhez, hogy a vállalkozások hogyan profitálhatnak az Ethereumból + +- [Miért hasznosak a blokkláncok az üzletben?](https://entethalliance.org/why-are-blockchains-useful-for-business/) - _A blokkláncok értékének megvitatása a kiszámíthatóság lencséjén keresztül_ +- [Enterprise Ethereum Alliance 2023 Business Readiness Report](https://entethalliance.org/eea-ethereum-business-readiness-report-2023/) - _felméri a nyilvános Ethereumban és a szélesebb Ethereum ökoszisztémában rejlő lehetőségeket és képességeket a vállalkozások számára_ +- [_Ethereum for Business_, írta Paul Brody](https://www.uapress.com/product/ethereum-for-business/) - _Egy közérthető útmutató azokról a felhasználási esetekről, amelyek a vagyonkezeléstől a fizetésen át az ellátási láncokig megtérülést hoznak_ + +### Szervezetek {#organizations} + +Különféle szervezetek számtalan együttműködésen alapuló erőfeszítést tettek azért, hogy az Ethereumot vállalkozásbarátabbá tegyék + +- [Enterprise Ethereum Alliance](https://entethalliance.org/) - Az EEA segíti a szervezeteket, hogy bevezessék és használják az Ethereum technológiáit mindennapi üzleti tevékenységükben. Célja az üzleti Ethereum felgyorsítása azáltal, hogy a szakmai és kereskedelmi támogatást, érdekérvényesítést és kutatást, szabványfejlesztést és ökoszisztéma-alapú bizalmi szolgáltatást nyújt. +- [Global Blockchain Business Council](https://www.gbbc.io/) - A GBBC a blokklánc-technológiai ökoszisztéma iparági szövetsége. A GBBC a politikai döntéshozók és a szabályozók bevonásával, rendezvények és mélyreható viták szervezésével, valamint a kutatás ösztönzésével elkötelezett a blokklánc további elfogadása mellett, hogy biztonságosabb, igazságosabb és működőképesebb társadalmakat hozzon létre. + + +## Vállati fejlesztői anyagok {#enterprise-developer-resources} + +### Termékek és szolgáltatások {#products-and-services} + +- [4EVERLAND](https://www.4everland.org/) - _ API-okat, RPC szolgáltatásokat és eszközöket kínál decentralizált alkalmazások működtetésére és az Ethereumon való decentralizált tároláshoz_ +- [Alchemy](https://www.alchemy.com/) - _API-szolgáltatásokat és -eszközöket szolgáltat az Ethereum alkalmazások fejlesztéséhez és monitorozásához_ +- [Blast](https://blastapi.io/) - _egy API-platform, amely RPC/WSS API-okat biztosít az Ethereum archív főhálózathoz és a teszthálózatokhoz._ +- [Blockapps](https://blockapps.net/) - _a vállalati Ethereum-protokoll, az eszközkészlet és az API-ok implementációja, melyek a STRATO platformot alkotják_ +- [Chainstack](https://chainstack.com/) - _az Ethereum főhálózatára és teszthálózataira biztosít infrastruktúrát, amelyet nyilvános és elkülönített vevői felhőkben hosztol_ +- [ConsenSys](https://consensys.io/) - _számos terméket és eszközt kínál az Ethereum fejlesztésére, valamint tanácsadási és egyedi fejlesztési szolgáltatásokat nyújt_ +- [Crossmint](http://crossmint.com/) – _Vállalati szintű web3-fejlesztési platform okosszerződések telepítéséhez, hitelkártyás és láncok közötti fizetések lehetővé tételéhez, valamint API-ok használatára NFT-k létrehozása, terjesztése, értékesítése, tárolása és szerkesztése érdekében._ +- [Envision Blockchain](https://envisionblockchain.com/) - _az Ethereum főhálózatra szakosodott, vállalati fókuszú, tanácsadási és fejlesztési szolgáltatásokat nyújt_ +- [EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _beszerzési munkafolyamatot biztosít, melynek során ajánlatbekéréseket (RFQ), szerződéseket, rendeléseket és számlákat bocsát ki az Ön megbízható üzleti partnereiből álló hálózatán keresztül_ +- [Hyperledger Besu](https://www.hyperledger.org/use/besu) - _egy vállalati fókuszú, nyílt forráskódú Ethereum-kliens Apache 2.0 licensszel fejlesztve és Java nyelven írva_ +- [Infura](https://infura.io/) - _skálázható API-hozzáférés az Ethereumhoz és az IPFS hálózatokhoz_ +- [Kaleido](https://kaleido.io/) - _egy vállalati fókuszú fejlesztési platform, amely egyszerűsített blokklánc- és digitáliseszköz-alkalmazásokat kínál_ +- [NodeReal](https://nodereal.io/) - _skálázható blokklánc-infrastruktúrát és API-szolgáltatókat biztosít a web3 ökoszisztémának_ +- [Moralis](http://moralis.io/) - _vállalati szintű API-ok és csomópontok egy SOC2 2-es típusú tanúsítással_ +- [Provide](https://provide.services/) - _vállalati zero-knowledge middleware_ +- [QuickNode](https://www.quicknode.com/) - _megbízható és gyors csomópontokat biztosít magas szintű API-okkal, mint amilyen az NFT API, Token API stb., miközben egy egységes termékcsomagot és vállalati szintű megoldásokat szállít_ +- [Tenderly](https://tenderly.co) - _egy web3-fejlesztői platform, amely okosszerződés-fejlesztéshez, -teszteléshez, -monitorozáshoz és -működtetéshez biztosít hibakeresési, megfigyelhetőségi és infrastruktúrához kapcsolódó építőelemeket_ +- [Unibright](https://unibright.io/) - _egy blokklánc-specialistákból, tervezőkből, fejlesztőkőből és szaktanácsadókból álló csapat, több mint 20 év tapasztalattal az üzleti folyamatok és az integráció területén_ +- [Zeeve](https://www.zeeve.io/) - _az Ethereumra való építéshez nyújt termékeket és eszközöket, valamint infrastruktúrát és API-okat biztosít vállalati web3 alkalmazásoknak._ + +### Eszközök és könyvtárak {#tooling-and-libraries} + +- [Baseline Project](https://www.baseline-protocol.org/) - _A Baseline Protocol egy olyan eszköz- és könyvtárkészlet, amely segít a vállalatoknak az összetett, többszereplős üzleti folyamatok és munkafolyamatok adatvédelmi szempontból történő koordinálásában, miközben az adatok a megfelelő nyilvántartási rendszerekben maradnak. A szabvány lehetővé teszi, hogy két vagy több állapotgép elérje és fenntartsa az adatok konzisztenciáját és a munkafolyamatok folytonosságát a hálózat közös referenciakeretként való használatával._ +- [Chainlens](https://www.chainlens.com/) - _SaaS és on-prem blokklánc adat- és elemzési platform a Web3 Labs-től_ +- [Ernst & Young 'Nightfall'](https://github.com/EYBlockchain/nightfall_3) - _egy alkalmazás az ERC-20, ERC-721 és ERC-1155 alkalmazások átvitelére zero-knowledge módon, optimista összesítés használatával_ + +### Skálázási megoldások {#scalability-solutions} + +A legtöbb új blokklánc-alkalmazás az [L2](/layer-2) láncokra épül. A második blokkláncréteget (L2) olyan technológiák vagy rendszerek alkotják, melyek az Ethereumon (L1) futnak, öröklik a biztonsági tulajdonságait az L1-től és nagyobb tranzakciófeldolgozási kapacitást (átvitelt) biztosítanak, alacsonyabb tranzakciós illetékkel (működési költség) és gyorsabb tranzakciómegerősítéssel, mint az L1 esetében. A 2. rétegű skálázási megoldások biztonságát az 1. réteg szolgáltatja, de a blokklánc alkalmazások számára elérhetővé teszik, hogy több felhasználót, tevékenységet vagy adatot kezeljenek, mint amire az 1. réteg képes lenne. A legtöbbjük a kriptográfiában és a zéró-tudású (ZK) bizonyíték kapcsán elért fejlődési eredményeket használja, hogy növelje a teljesítményt és a biztonságot, és néhányuk az adatvédelem újabb szintjét kínálja. + +## Vállalati alkalmazások a főhálózaton {#enterprise-live-on-mainnet} + +Íme néhány olyan vállalati alkalmazás, amelyet hagyományos, nem blokklánc alapú vállalatok építettek a nyilvános Ethereum főhálózatra és L2-re. + +### Fizetések {#payments} + +- A [Brave Browser](https://basicattentiontoken.org/) - _a felhasználóknak fizet, hogy hirdetéseket nézzenek, a felhasználók pedig fizetéssel támogathatják a kiadókat a Basic Attention Token segítségével._ +- [Lugano városa Svájcban](https://bitcoinsuisse.com/news/city-of-lugano-accepts-crypto-payments) - _adófizetés és egyéb önkormányzati szolgáltatások_ +- Az [EthereumAds](https://ethereumads.com/) - _lehetővé teszi a weboldal működtetőinek, hogy reklámhelyeket értékesítsenek és az Ethereumon keresztül kapjanak érte pénzt_ +- [hCaptcha](https://www.hcaptcha.com/) - _Botkizáró CAPTCHA rendszer, amely fizet a weboldal működtetőinek a felhasználók által végzett munkáért, akik a gépi tanulás számára jelölik az adatokat. Már telepítve van a Cloudflare-en is._ +- [Opera MiniPay](https://www.opera.com/products/minipay) - _megkönnyíti és biztonságosabbá teszi a mobilfizetést az Afrikában élők számára, akiknek egy saját felügyeletű tárcával és telefonszámokkal egyszerűbbé teszi a tranzakciókat_ +- [Roxpay](https://www.roxpay.ch/) - _automatizálja a használat alapú eszközszámlázást és fizetést_ +- [SAP Digital Currency Hub](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p/13560384) - _határokon átnyúló fizetések stabil érmékkel_ +- [Toku](https://www.toku.com/) - _bérszámfejtés, tokenalapú ösztöndíjak adminisztrációja, adózás, helyi alkalmazás, jövedelmezés és elosztott HR-megoldások_ +- [Xerof](https://www.xerof.com/) - _gyors és alacsony költségű nemzetközi (határokon átívelő) vállalatok közötti (B2B) fizetések intézése_ + +### Pénzügy {#finance} + +- [ABN AMRO](https://tokeny.com/tokeny-fuels-abn-amro-bank-in-tokenizing-green-bonds-on-polygon/) - _a Tokeny révén tokenizált, zöld kötvények_ +- [Crowdz](https://crowdz.io/) - _platform számlák/követelések pénzügyi kezelésére és faktoringjára_ +- [Mata Capital](https://consensys.io/blockchain-use-cases/finance/mata-capital) - _ingatlanbefektetések tokenizálása_ +- [Obligate](https://www.obligate.com/) - _szabályozott és ellenőrzött (KYC) láncon belüli kötvények és kereskedelmi papírok_ +- [Siemens](https://press.siemens.com/global/en/pressrelease/siemens-issues-first-digital-bond-blockchain) - _kötvénykibocsátás_ +- [Sila](https://silamoney.com/) - _bankolásra és ACH-fizetésre szolgáló infrastruktúra mint szolgáltatás egy stabil érmét használva_ +- [Societe Generale FORGE](https://www.sgforge.com/product/bonds/) - _kötvénykibocsátás_ +- [Taurus](https://www.taurushq.com/) - _tokenizált részvények kibocsátása_ + +### Eszköztokenizálás {#tokenization} + +- Az [AgroToken](https://agrotoken.io/en/) - _mezőgazdasági anyagokat tokenizál és kereskedik velük_ +- [Bitbond](https://www.bitbond.com/) - _tokenizálással javítja a pénzügyi eszközök kibocsátását, rendezését és őrzését_ +- [Blocksquare](https://blocksquare.io/) - _tokenizálási infrastruktúra ingatlanokhoz_ +- [Centrifuge](https://centrifuge.io/) - _tokenizált követelések finanszírozása, tartozások és eszközök kezelése_ +- [Clearmatics](https://www.clearmatics.com) - _decentralizált hálózati platformok építése a tokenizált értékek társközi (peer-to-peer) átváltásához_ +- [dClimate](https://www.dclimate.net/) - _decentralizált klímainformációs ökoszisztéma_ +- [Fabrica](https://www.fabrica.land/) - _platform az ingatlanok digitalizálására, beleértve a DeFi kölcsönzést és az ingatlanokkal való kereskedelmet_ +- A [Fasset](https://www.fasset.com/) - _egy platform a fenntartható infrastruktúráért_ +- [Nori](https://nori.com/) - _nyílt forráskódú piaci infrastruktúra a karboncsökkentési projektek számára, hogy mérhessék és monetizálhassák tevékenységüket_ +- [Propy](https://propy.com/) - _platform a lakossági ingatlanügyletek automatizálására okosszerződésekkel_ +- A [RealT](https://realt.co/) - _révén a befektetők a világ minden részéről vásárolhatnak az amerikai ingatlanpiacon a szabályozásnak megfelelő, tokenizált résztulajdont_ +- [Rubey](https://www.rubey.be/) - _platform a felsőfokú művészet tokenizálásához, hogy azok elérhetők legyenek a kiskereskedelmi befektetőknek_ +- [Swarm](https://swarm.com/) - _platform a fizikai eszközök digitalizálására és a szabályozásnak megfelelő kereskedelmére _ +- [Thallo](https://www.thallo.io/) - _platform a digitális karbon kreditek üzleti tranzakciókba való integrálására_ +- [Tokenchampions](https://tokenchampions.com/) - _tokenizálja az európai focijátékosok képeinek jogait_ + +### Adatok notarizációja {#notarization-of-data} + +- [ANSA](https://www.ansa.it/english/news/science_tecnology/2020/04/06/ansa-using-blockchain-to-help-readers_af820b4f-0947-439b-843e-52e114f53318.html) - _Olasz hírügynökség, mely az álhírek ellen küzd, és lehetővé teszi az olvasók számára, hogy a hírek eredetét a főhálózaton történő rögzítéssel ellenőrizzék_ +- [Breitling](https://www.coindesk.com/breitling-arianee-all-new-watches-ethereum) - _az órák származását és javítási történetét rögzíti az Ethereumon_ +- [BRØK](https://www.xn--brk-1na.no/) - _platform a tőzsdén nem jegyzett társaságoknak, melyet a norvég kormány biztosít_ +- [Certifaction](https://certifaction.com/) - _legálisan érvényes elektronikus aláírások, melynek eleve része az adatvédelem_ +- [EthSign](https://ethsign.xyz/) - _feljegyezi az Ethereum-blokkláncra az aláírt elektronikus dokumentumokat_ +- [Stacktical](https://stacktical.com/) - _szoftverfejlesztés, szolgáltatásiszint-megegyezés (SLA) digitális biztosítása és aláírása natív letétbe helyezési képességekkel_ +- [Verizon](https://decrypt.co/46745/verizon-news-press-releases-ethereum-full-transparency) - _Naplózza a sajtóközleményeket az Ethereumon a vállalati elszámoltathatóság és bizalom biztosítása érdekében_ +- [WolfTown](https://www.mef.net/edge-view-blog/automated-secure-timely-sla-reporting-is-finally-a-reality/) - _MEF és Sage Management által automatizált szolgáltatásiszint-megegyezés (SLA) riportálása a távközlési szolgáltatók között_ + +### Ellátási lánc {#supply-chain} + +- [Birra Peroni](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using-ey-opschain-traceability) _NFT-ket készít minden egyes új tétel sörhöz, ami nagyobb átláthatóságot és hatékonyságot tesz lehetővé az ellátási láncban_ +- [CargoX](https://cargox.io/) - _Elektronikus fuvarlevél- és okmánytovábbítási szolgáltató szállításhoz_ +- [Circularize](https://www.circularise.com/) - _elejétől a végéig lekövethető megoldás arra, ahogy a nyersanyagokból késztermékek lesznek_ +- [EY OpsChain Network Procurement](https://blockchain.ey.com/products/contract-manager) - _egy beszerzési munkafolyamatot biztosít a cégek számára, melynek során ajánlatbekéréseket (RFQ), szerződéseket, rendeléseket és számlákat bocsát ki az üzleti partnereiből álló hálózatán keresztül_ +- [Minespider](https://www.minespider.com/) - _ellátási lánc, eredet és Co2 kibocsátás nyomon követése_ +- [Morpheus.network](https://morpheus.network/) - _platform az ellátási lánc automatizálására_ +- [StaTwig](https://statwig.com/) - _ellátási lánc működtetése_ +- [TradeTrust](https://www.tradetrust.io/) - _az elektronikus fuvarleveleket (eBLs) ellenőrzi a nemzetközi szállításban_ +- [Transmute](https://transmute.industries/) - _adatcsereplatform a globális kereskedelem számára, amely támogatja az Ethereumon a decentralizált identitással való tranzakciókat_ + +### Biztosítás {#insurance} + +- [Arbol](https://www.arbolmarket.com/) - _egy parametrikus biztosítás az időjárásból eredő kockázatok fedezésére_ +- [Etherisc](https://etherisc.com/) - _decentralizált biztosítás különféle kockázatokra_ +- [Nayms](https://www.nayms.com/) - _az AON-nal együtt épített digitális tér arra, hogy biztosítási programokat hozzanak létre, tőkét gyűjtsenek és helyezzenek ki, kockázatot írjanak le, valamint díj- és kárigény-tranzakciók fizetését intézzék_ + +### Identitás, hitelesítőadatok és tanúsítványok {#credentials} + +- [BCdiploma](https://www.bcdiploma.com/) - _digitalizálja és ellenőrzi az okiratokat, tanúsítványokat és a mikro hitelesítési adatokat_ +- [Hyland Credentials](https://www.hylandcredentials.com) - _digitális diplomákat és más oktatási igazolványokat, engedélyeket és bizonyítványokat bocsát ki_ +- [Palau Digital Residency Program](https://rns.id/) - _a világpolgárok részére lehetővé teszi egy legális, a Palau kormány által kiadott igazolvány megszerzését_ +- [Spherity](https://www.spherity.com/) - _digitális identitáskezelési megoldásokat kínál, hogy az ökoszisztémában megalapozza a digitális bizalmat, fókuszálva a decentralizált identitásra és az ellenőrizhető hitelesítő adatokra_ +- [Zug Digital ID](https://ezug.ch/en/) - _egy blokkláncalapú identitásrendszer Svájcban, amely digitális hozzáférést biztosít a kormány által nyújtott szolgáltatásokhoz, és olyan a funkciókat is támogat, mint az online biciklikölcsönzés és a helyhatósági szavazás_ + +### Szórakozás, NFT-k és hűségprogramok + +- [Adidas Virtual Gear](https://www.adidas.com/metaverse) - _virtuális felszerelések NFT-gyűjteménye_ +- [The British Museum's Sandbox](https://decrypt.co/150405/british-museum-enter-metaverse-via-sandbox) - _egy NFT-gyűjtemény_ +- [Fruitlab](https://fruitlab.com/) - _platform a játékosoknak, hogy az online játékok megtekintése, megosztása és használata során jövedelemhez jussanak_ +- [Nike Swoosh](https://www.swoosh.nike/) - _egy NFT-platform_ +- [Sothbebys Metaverse](https://metaverse.sothebys.com/) - _egy digitális művészeti NFT-piactér a Sothebys által_ + +Ha szeretne valamit hozzáadni a listához, akkor tekintse át a [közreműködésre vonatkozó instrukciókat](/contributing/). diff --git a/public/content/translations/hu/26) Miscellaneous/foundation/index.md b/public/content/translations/hu/26) Miscellaneous/foundation/index.md new file mode 100644 index 00000000000..6ccb3fa997a --- /dev/null +++ b/public/content/translations/hu/26) Miscellaneous/foundation/index.md @@ -0,0 +1,40 @@ +--- +title: Ethereum Alapítvány +description: Ismerje meg az Ethereum Alapítványt (EF), amely egy non-profit szervezet, s célja az Ethereum és a hozzá kapcsolódó technológiák támogatása. +hideEditButton: true +lang: hu +--- + +# Az Ethereum Alapítványról {#about-the-ethereum-foundation} + + + +Az [Ethereum Alapítvány (EF)](http://ethereum.foundation/) egy non-profit szervezet, melynek célja az [Ethereum](/what-is-ethereum/) és a kapcsolódó technológiák támogatása. + +Az Ethereum Alapítvány (EF) nem egy cég, még csak nem is hagyományos non-profit. Feladatuk nem az Ethereum irányítása vagy vezetése, és nem is az egyetlen szervezetté válás, amely finanszírozza az Ethereumhoz kapcsolódó, fontos technológiák fejlesztését. Az EF egy sokkal nagyobb [ökoszisztémának](/community/) a része. + +## Ethereum Alapítvány Kezdeményezések {#ethereum-foundation-initiatives} + +### Ecosystem Támogatási Program {#ecosystem-support-program} + +Az [Ökoszisztéma Támogatási Program](https://esp.ethereum.foundation/) célja, hogy pénzügyi és nem pénzügyi támogatást nyújtson projekteknek és egyéneknek a tágabb Ethereum közösségen belül, hogy felgyorsítsa az ökoszisztéma növekedését. Az Ökoszisztéma Támogatási Program az eredeti Ethereum támogatási/ösztöndíj program kibővítése, amely főként a pénzügyi támogatásra összpontosított. + +Tudjon meg többet az Ökoszisztéma Támogatási Programról, korábbi ösztöndíjasokról és az ösztöndíj jelentkezési folyamatáról az [esp.ethereum.foundation](https://esp.ethereum.foundation/) oldalon. Ezenkívül megnézheti az [Ökoszisztéma Támogatási Program Blogját](https://blog.ethereum.org/category/ecosystem-support-program/) vagy követheti az [@EF_ESP](https://twitter.com/EF_ESP) oldalt a legfrissebb hírekért és bejelentésekért. + +### Devcon {#devcon} + +Az Ethereum Alapítvány 2014 óta szervezi a Devcont, az Ethereum éves konferenciáját, mely egy helyre gyűjti a fejlesztőket, kutatókat, gondolkodókat és alkotókat. + +Hozzáférhet az összes konferencián elhangzó előadás videójához a kezdetektől az [archive.devcon.org](https://archive.devcon.org/) oldalon. + +Tudjon meg többet a [devcon.org](https://devcon.org/) oldalon, tekintse meg a [Devcon blogot](https://devcon.org/en/blogs/), vagy kövesse a [@efdevcon](https://twitter.com/EFDevcon) csatornát a legfrissebb információkért. + +### Ösztöndíjas program {#fellowship-program} + +Az [Ethereum Alapítvány Ösztöndíjas Programja](https://fellowship.ethereum.foundation/) egy olyan kezdeményezés, mely a kulturális, nemzeti és gazdasági csoportok egyenlő arányú jelenlétét akarja elősegíteni. A program úgy akarja áthidalni a szakadékokat, hogy kivételes és tehetséges egyéneket keres és támogat, hogy felkeltsék e csoportok Ethereum iránti érdeklődését, elhárítsák azokat az akadályokat, amelyek miatt a távolmaradó emberek és közösségek nem tudnak csatlakozni az Ethereum világához, pedig ők jelentik a web3 jövőjét. + +[Tudjon meg többet a fellowship.ethereum.foundation oldalon](https://fellowship.ethereum.foundation/). + +
+ +További információkért az Alapítványról látogasson el az [ethereum.foundation](http://ethereum.foundation/) weboldalra, vagy nézze meg az [Ethereum Alapítvány Blogot](https://blog.ethereum.org/) a legfrissebb hírekért és bejelentésekért. diff --git a/public/content/translations/hu/27) Contributing/contributing/design-principles/index.md b/public/content/translations/hu/27) Contributing/contributing/design-principles/index.md new file mode 100644 index 00000000000..8a179086b72 --- /dev/null +++ b/public/content/translations/hu/27) Contributing/contributing/design-principles/index.md @@ -0,0 +1,93 @@ +--- +title: Dizájnelvek +lang: hu +description: Az ethereum.org dizájnhoz és tartalmi döntésekhez kapcsolódó elvei +--- + +# Dizájnelveink {#contributing-to-ethereumorg-} + + Üdvözlöm az ethereum.org dizánelvei oldalon. Ez szerves része annak a folyamatnak, amely során az ethereum.org-ot fejlesztjük. + +Az elveink adják a honlapnak és tartalmának kinézetét és érzetét. + +Kérjük, hogy tekintse át ezeket, mielőtt [közreműködik az ethereum.org-on](/contributing/). + +## Mik azok a dizájnelvek? {#ways-to-contribute} + +Ne aggódjon, nagyon egyszerűek! A **dizájnelvek** olyan útmutatások, melyekhez igazodunk a tervezésnél (amikor létrehozunk, fenntartunk vagy frissítünk valamit). + +Az ethereum.org-nál ezek az elvek adják meg, hogy mit képviseljen a honlap és mit mutasson a világnak. Egyaránt ösztönzők **és** gyakorlatiasak. Nemcsak az, ahogyan a honlap _kinéz_, hanem ahogy _működik_ és ahogy azt valaki _megtapasztalja_. Minden egyes dolog, a színektől kezdve az elrendezésig és hogyan beszélünk az Ethereumról, mind ezen elvek mentén történik. + +## Az elvek a gyakorlatban {#how-decisions-about-the-site-are-made} + +Vegyünk egy példát. Az egyik elv a „hiteles”, ami azt jelenti, hogy a látogatók _érezzék_ és _tudják_, hogy a honlap megbízható - ahogy a kiterjedt Ethereum ökoszisztéma is. Ezen belül található három gyakorlati „alelv”, amelyeket követve elérhetjük, hogy a honlap hiteles legyen: + +- _„Friss”_ vagyis a tartalom legyen frissítve. +- _„Közösségi bizonyíték”_ vagyis mutassuk meg az ökoszisztéma méretét, diverzitását és tevékenységeit (mint az Ethereum-frissítések, DeFi, játékok, hackathon-ok stb.) +- _„Konzisztens”_ vagyis egységes dizájn az oldalakon, valamint tónus és pontosság a tartalomban. + +Tehát amikor döntést akarunk hozni, akkor a hitelesség elve mentén feltehetjük a kérdést: + +- _„Tükrözi a honlap az aktuális információkat?”_ +- _„Hogyan és hol mutatjuk meg az ökoszisztéma méretét és tevékenységét?”_ +- _„A közösségi tag által javasolt hozzájárulás, amelyet átnézek, konzisztens a jelenlegi dizájnnal és írással?”_ + +## Az ethereum.org dizájnelvei {#contributors} + +### 1. Inspiráló {#1-inspirational} + +Ez a honlap arra inspirálja a felhasználókat, hogy elképzeljék, az Ethereum hogyan változtatja meg a világot. Arra ösztönözze az embereket, hogy az Ethereum ökoszisztémát felfedezzék, játszanak és bütyköljenek az eszközökkel és alkalmazásokkal. + +- **Radikális:** A honlap kifejezze az Ethereum ambíciózus célját, hogy értelmes módon megváltoztassa a világot. Legyen egyértelmű, hogy az Ethereum nem csak egy új technológiai stack - ez egy transzformációs technológia. +- **Az oktatás általi felhatalmazás:** Ez a honlap olyan tudást adjon az embereknek, hogy megértsék az Ethereumban rejlő potenciált, megtalálják a maguk helyét az ökoszisztémában, és azt érezzék, hogy képesek közreműködni benne. + +Vizuzális irány • Tartalom + +### 2. Univerzális {#2-universal} + +Az Ethereum egy globális, decentralizált projekt, és ez meghatározza a közönséget is. A honlap ezért legyen elérhető mindenkinek, és fogékony a világ számtalan kultúrájára. + +- **Elérhető:** A honlap kövesse az elérhetőségi iránymutatást - beleértve azt, hogy a kis sávszélességgel bíró emberek is kapcsolódhassanak hozzá. +- **Egyértelmű:** Legyen egyszerű és ellentmondásoktól mentes. Ne használjon olyan kifejezéseket, amelyeket félre lehet magyarázni vagy az értelme elveszik a fordításban. +- **Az Ethereum sokrétű:** Az Ethereum egy projekt, egy kódbázis, egy közösség, egy vízió. Különböző embereknek másféle okból értékes, és sokféle módon részt lehet venni benne. + +Írásrendszerek • Színhasználat • Vizuális irány • Tartalom + +### 3. Egy jó történet {#3-a-good-story} + +Az honlap legyen olyan, mint egy jó történet. A látogatók egy utazáson vesznek részt, és az a tartalom, melyhez Ön is hozzájárul, része ennek az útnak. A közreműködése egy egyértelmű történet része: melynek eleje van (bevezetés/belépési pont), közepe (tanulságok és rálátások) és vége (források vagy következő lépések). + +- **Hierarchikus**: Az egyértelmű, hierarchikusan rendezett információs architektúra segíti a látogatót, hogy az ethereum.org-on egy történetként haladjanak, ahogy a céljaik felé tartanak. +- **Egy lépcsőfok:** Ez egy lépcsőfok bárkinek, aki választ keres. Nem akarjuk helyettesíteni vagy lecserélni a már létező forrásokat. Választ adunk és megbízható következő lépéseket. + +Felhasználói utak • Tartalom + +### 4. Hiteles {#4-credible} + +Az emberek az Ethereum ökoszisztémába való bevezetést keresik, vagy szkeptikusok. Ezt a felelősséget el kell ismerni a kommunikáció módját illetően. Biztosítanunk kell, hogy mindannyian nagyobb magabiztossággal távoznak a honlapról. + +- **Friss:** Mindig aktuális. +- **Közösségi bizonyíték:** Mutassuk meg az ökoszisztéma méretét, diverzitását és tevékenységét. +- **Konzisztens:** A konzisztens dizájn és tartalom hitelességet sugall. + +Vizuzális irány • Tartalom + +### 5. Együttműködő fejlesztés {#5-collaborative-improvement} + +A honlap számtalan közreműködő terméke, ahogy az ökoszisztéma egésze is. + +- **Nyitott:** Értékeljük a forráskód, a folyamatok és projektek átláthatóságát az ökoszisztéma egészében. +- **Kiterjeszthető:** A modularitás az egyik fő fókuszunk, ezért a részvétel is legyen moduláris. A honlap fő dizájnja, komponenskódja és implementációja tegye lehetővé, hogy a jövőben könnyen kiterjeszthető legyen. +- **Kísérleti:** Állandóan kísérletezünk, tesztelünk és ismétlünk. +- **Együttműködő:** Ez a projekt mindannyiunkat összehoz. +- **Fenntartható:** Hosszú távú fenntartásra rendezkedünk be, melyet a közösség végez + +Láthatja a dizájnelveket a gyakorlatban [a honlap egészében](/). + +## Adjon visszajelzést {#give-feedback} + +**Ossza meg véleményét erről a dokumentumról!** Az egyik javasolt elvünk az **Együttműködő fejlesztés**, amely szerint ez a honlap számtalan résztvevő közös terméke legyen. Ennek szellemében osztjuk meg a dizájnelveket az Ethereum közösségével. + +Miközben ezek az elvek az ethereum.org honlapra fókuszálnak, reméljük, hogy számos elv az Ethereum ökoszisztéma értékeit képviseli (például észrevehető az [az Ethereum fehékönyv elveinek](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy) hatása). Talán Ön is szívesen követné ezeket a saját projektjében! + +Tudassa velünk gondolatait a [Discord szerveren](https://discord.gg/ethereum-org) vagy azáltal, hogy [létrehoz egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=). diff --git a/public/content/translations/hu/27) Contributing/contributing/design/index.md b/public/content/translations/hu/27) Contributing/contributing/design/index.md new file mode 100644 index 00000000000..0c136e5aa77 --- /dev/null +++ b/public/content/translations/hu/27) Contributing/contributing/design/index.md @@ -0,0 +1,77 @@ +--- +title: Közreműködés a dizájnban +description: Közreműködés a dizájnban az ethereum.org-on +lang: hu +--- + +# Közreműködés a dizájnban az ethereum.org-on {#design-contributions} + +Minden projekt kritikus eleme a dizájn, amennyiben az idejét és a dizájnképességeit az ethereum.org oldalon kamatoztatja, akkor segíti a látogatók felhasználói élményét. A nyílt forráskódú projektben való közreműködés lehetőséget ad arra, hogy releváns tapasztalatot szerezzen és készségeit együttműködő környezetben fejlessze. Együtt dolgozhat más tervezőkkel, fejlesztőkkel és közösségi tagokkal, akik mind saját perspektívával és rálátással rendelkeznek. + +Ez egy remek módja annak is, hogy egy sokszínű és hatásos portfóliót hozzon létre, mely bemutatja a dizájnképességeit. + +## Hogyan vehet részt? + +###  Adjon visszajelzést a korai dizájn prototípusairól {#design-critique} + +Néha szükséges a nyers ötleteket letesztelni. Ez egy remek lehetőség arra, hogy technikai tudás nélkül is részt vehessen. + +1. A dizájncsapat megoszt egy tervet a [Discord-on](https://discord.com/invite/ethereum-org) és a [GitHub-on](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). +2. Végigvezetik a dizájnon, hogy utána visszajelzést adjon a komment részben. +3. Ennek eredményét megosztják a GitHub issue-ban, majd lezárják azt. + +###  Vegyen részt kutatásban {#answer-surveys} + +Adjon visszajelzést a honlapról: + +1. Tekintse meg az ethereum.org-ot és olvasson el néhány oldalt. +2. Kattintson a visszajelzés funkcióra a jobb alsó sarokban, és válaszoljon a dizájnnal és tartalommal kapcsolatos kérdésekre. +3. Fókuszáljon a szabadon megválaszolható kérdésekre. + +###  Találjon dizájnnal kapcsolatos problémákat a honlapon és jelezze azokat {#report-design-issues} + +Az ethereum.org egy gyorsan fejlődő honlap, amely számtalan jellemzővel és tartalommal bír. A felhasználói felület bizonyos része már kivezethető lenne vagy fejleszteni kellene. Ha ilyet talál, akkor jelezze, hogy felkerüljön a radarunkra. + +1. Tekintse meg a honlapot és figyeljen oda a dizájnra. +2. Készítsen képernyőképeket és jegyzeteket, ha vizuális vagy UX problémát lát. +3. Jelezze a problémákat egy [hibariportban](https://github.com/ethereum/ethereum-org-website/issues/new/choose). + +###  Javasoljon dizájnváltozásokat {#propose-design-changes} + +Ha szereti a dizájnkihívásokat, akkor nézze meg a GitHub issue-kat, és szűrjön rá a [dizájnnal kapcsolatos tételekre](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). + +1. Tekintse meg a honlapot és figyelje meg a dizájnt, vagy keressen rá a GitHub könyvtárban azokra a jelzett hibákra, ahol [dizájnra van szükség (Design required)](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). +2. Ötleteljen a megoldáson és tervezze meg. (ideális esetben ezt a [dizájnrendszert](https://www.figma.com/community/file/1134414495420383395) használva). +3. Javasoljon megoldást a kapcsolódó GitHub issue-ban, vagy [hozzon létre újat](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request). +4. Várja meg, amíg a dizájncsapat átnézi. + +###  Építsünk dizájnrendszert együtt {#Contribute-to-design-system} + +A dizájnrendszerünk révén ethereum.org tervezése szórakoztató és könnyű. Ha Ön tapasztalt dizájner, akkor segíthet nekünk a honlap komponenseinek létrehozásában. + +1. Válasszon egy meglévő issue-t a GitHub-on a [dizájnrendszer tábláról](https://github.com/ethereum/ethereum-org-website/labels/design%20system) vagy hozzon létre újat. +2. Kérje meg, hogy az adott tételt Önnek adják. +3. Készítsen dizájnt Figmában a kért komponensről. +4. Ossza meg azt a dizájncsapattal a GitHub-on, amikor átnézésre vagy útmutatásra van szüksége. +5. A dizájncsapat átnézi azt. +6. A csapat átvezeti rajta a változásokat és megosztja azt a közösséggel. + +###  Írjon dizájnnal kapcsolatos tartalmat a honlapra {#write-design-articles} + +Az Ethereum fejlesztői közössége kellően erős, de a dizájnközösségnek még van hova fejlődnie. Ha Ön web3-tudással rendelkező dizájner, akkor ossza meg tapasztalatát a nagyobb közösséggel, hogy együtt fejlődhessünk; van egy [oldalunk az Ethereumra vonatkozó dizájnról](/developers/docs/design-and-ux/), amelyhez Ön is hozzájárulhat. Megtekintheti a [listázási szabályokat](/contributing/design/adding-design-resources) is. + +1. Ötleteljen a dizájntémákon az ethereum.org kapcsán, melyek a többi dizájnernek is hasznosak lehetnek. +2. A GitHub könyvtárban [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new), és javasoljon egy témát benne (még ne írja meg a tartalmat). +3. Várja meg, amíg a dizájncsapat jóváhagyja. +4. Amint jóváhagyták, írja meg a tartalmat. +5. Adja be a kapcsolódó GitHub issue-ban. + +###  Készítsen új illusztrációkat {#prepare-illustrations} + +A vizualizáció az egyik legerősebb eszköz az elvont témák elmagyarázásához. Nagy potenciál van a diagrammokban és infografikákban. Egy kép képes ezernyi dolgot elmondani. + +1. Tekintse meg a honlapot és azokat az oldalakat, amelyeken jól jönne néhány infografika. +2. Biztosítsa, hogy az illusztráció stílusa kapcsolódik a meglévő [eszközökhöz](/assets/). +3. A GitHub könyvtárban [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new), melyben felveti az adott illusztrációt. +4. A dizájcsapat átnézi. +5. Létrehozunk egy új issue-t, és felkérünk egy fejlesztőt, hogy létrehozza az adott képet. diff --git a/public/content/translations/hu/27) Contributing/contributing/index.md b/public/content/translations/hu/27) Contributing/contributing/index.md new file mode 100644 index 00000000000..e8d145dbd9b --- /dev/null +++ b/public/content/translations/hu/27) Contributing/contributing/index.md @@ -0,0 +1,117 @@ +--- +title: Közreműködők +description: Ismerje meg, hogyan tud különféle módokon közreműködni az ethereum.org kapcsán +lang: hu +--- + +# Hozzájárulás az ethereum.org-hoz 🦄 {#contributing-to-ethereumorg} + +Az ethereum.org egy nyílt forráskódú projekt **több mint 12 000** közreműködővel, akik segítenek fordítani, írni, tervezni és fenntartani a honlapot. + +Ez egy befogadó közösség, mely segít fejlődni és megismerni az Ethereum ökoszisztémát, miközben értelmes hozzájárulást tehet és gyakorlati tapasztalatot szerezhet! + +## Közreműködési módok {#ways-to-contribute} + +**Fordítás** +- [Csatlakozzon a fordítási programhoz](/contributing/translation-program/) – Segítsen abban, hogy az ethereum.org új nyelveken legyen elérhető + +**Fejlesztés** +- [Dolgozzon egy meglévő problémán](https://github.com/ethereum/ethereum-org-website/issues) – Olyan feladatot találhat, melyet szükségesnek látunk megoldani + +**Dizájn** +- [Segítsen a honlap dizájnjában](/contributing/design/) Bármilyen szinten is ért hozzá, be tud segíteni a honlap dizájnjába + +**Tartalom** +- [Hozzon létre vagy szerkessze a tartalmat](/contributing/#how-to-update-content) – Javasoljon új oldalakat vagy fejlessze a meglévőket +- [Javasoljon közösségi forrásokat](/contributing/content-resources/) – Adjon hasznos cikket vagy forrást egy adott oldalhoz +- [Javasoljon dizájnforrást](/contributing/design/adding-design-resources/) – Adjon hozzá, frissítsen és töröljön a dizájnforrások közül +- [Javasoljon kifejezést a szószedethet](/contributing/adding-glossary-terms/) – Segítsen kiterjeszteni az Ethereum [szószedetet](/glossary/) +- [Kvízek](/contributing/quizzes/) – Adjon hozzá, frissítse és töröljön a kvízkérdésekből, melyek egy adott oldalhoz tartoznak + +**Új jellemzőkre vonatkozó ötletek** +- [Javasoljon új jellemzőt](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – Ossza meg ötletét új jellemzőre vagy dizájnra vonatkozóan + +**Termékmegjelenítések** +- [Javasoljon tőzsdét](/contributing/adding-exchanges/) – Adjon egy új tőzsdét a [tőzsdekeresőhöz](/get-eth/#country-picker) +- [Javasoljon egy terméket](/contributing/adding-products/) – Adjon egy dappot vagy tárcát az adott oldalhoz +- [Javasoljon fejlesztői eszközt](/contributing/adding-developer-tools/) – Javasoljon fejlesztői eszközt a megfelelő oldalhoz +- [Javasoljon második blokkláncréteget (L2)](/contributing/adding-layer-2s/) – Adjon L2-t a megfelelő oldalhoz +- [Javasoljon letétbe helyezési terméket vagy szolgáltatást](/contributing/adding-staking-products/) – Adjon hozzá olyan projektet, ami elősegíti az önálló letétbe helyezést, a letéti alap vagy letéti szolgáltatás igénybevételét +- [Javasoljon tárcát](/contributing/adding-wallets/) – Adjon egy tárcát a [tárcakereső oldalra](/wallets/find-wallet/) +- [Javasoljon egy projektet a DeSci oldalra](/contributing/adding-desci-projects/) – Adjon hozzá egy Ethereumra épített projektet, mely hozzájárul a decentralizált tudományhoz + +Kérdése van? 🤔 Csatlakozzon a [Discord szerverünkhöz](https://discord.gg/ethereum-org) + +## Megfelelő első feladatok a hozzájárulás megkezdéséhez + +Ezek olyan jelenlegi feladatok, melyekbe besegíthet és felvállalhatja őket. Ehhez egy GitHub profilra lesz szükség, mert a változások nagy része azon keresztül zajlik. + + + +Tekintse meg az összes feladatot + +## Hogyan lehet az ethereum.org-on dolgozni {#how-to-update-content} + +Ha szeretne részt venni a [fordítási programban](/contributing/translation-program/), akkor hozzon létre egy [Crowdin](https://crowdin.com/project/ethereum-org) profilt. Minden máshoz, mint amilyen az új tartalom vagy vizualizáció, vagy a meglévő fejlesztése, hibajavítás, a meglévő feladatokon való munka, egy [GitHub](https://github.com/) profilra lesz szükség. + +Minden frissítés a GitHub PR folyamaton keresztül zajlik. Ez azt jelenti, hogy Ön készít a honlapról egy saját másolatot, végrehajtja a változtatásokat és megkéri, hogy azokat olvasszák be. Ha még nem csinált ilyet, akkor kövesse a [GitHub könvytár](https://github.com/ethereum/ethereum-org-website) alján lévő instrukciókat. + +Ehhez nincs szükség engedélyre, de mindenesetre tudassa velünk, hogy mit tervez. Ehhez: + +- Kommentáljon egy problémán vagy PR-on a [GitHub-ban](https://github.com/ethereum/ethereum-org-website) +- Küldjön üzenetet a [Discord szerveren](https://discord.gg/ethereum-org) + +Mielőtt nekilát, ismerkedjen meg: + +- az [ethereum.org fejlődő víziójával](/about/) +- a [tervezési elvekkel](/contributing/design-principles/) +- a [stílusútmutatóval](/contributing/style-guide/) +- a [viselkedési szabályzattal](/community/code-of-conduct) + + + +## Hogyan történik a döntéshozás a honlapról {#how-decisions-about-the-site-are-made} + +A PR-okról, dizájnfejlesztésről, főbb frissítésekről a döntéseket egy olyan csapat hozza, mely az Ethereum ökoszisztémához tartozik. Ebben a csapatban projekt menedzserek, fejlesztők, tervezők, marketingesek, kommunikációs szakemberek és szakértők vannak. Minden döntés alapja a közösségi input, ezért tegye fel a kérdését, adjon be PR-t vagy keresse meg a csapatot: + +- [website@ethereum.org](mailto:website@ethereum.org) +- [@ethdotorg](https://twitter.com/ethdotorg) +- [Discord szerver](https://discord.gg/ethereum-org) + +### Megjegyzés a plágiumról {#plagiarism} + +Amikor az ethereum.org tartalmához vagy alkotásaihoz hozzájárul, akkor csak a saját munkáját használja vagy azt, amire engedélye van. Az Ethereum ökoszisztéma számos projektje nyílt forráskódú licenccel működik, ami lehetővé teszi az információ ingyenes megosztását. Ugyanakkor, ha ezt az információt nem ismeri, akkor ne adja hozzá a honlaphoz az adott tartalmat. A plagizálásnak minősülő PR-okat elutasítjuk. + +## Most ismerkedik a nyílt forráskóddal? {#new-to-open-source} + +A GitHub könyvtárban megtalálja azokat a könnyen érthető feladatokat, melyeket az új fejlesztőknek szántunk, és elláttuk a [megfelelő első feladatok](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) címkével. + +## Kérje a láncon belüli eredménytokenjét (OAT) {#oat} + +Ha a munkáját beolvasztják az ethereum.org-ba, akkor kérhet egy különleges oklevelet a [Galxe-n](https://app.galxe.com/quest/ethereumorg) keresztül. A láncon belüli eredménytoken (OAT) egy tanúsítvány, hogy jobbá tette az ökoszisztémát. + +[Bővebben az OAT-okról](https://help.galxe.com/en/articles/7067290-galxe-oats-reward-and-celebrate-achievements) + +### Hogyan kell kérni +1. Csatlakozzon a [Discord szerverhez](https://discord.gg/ethereum-org). +2. Másolja be a közreműködését a ` #🥇 | proof-of-contribution` csatornába +3. Ezután csapatunk elküldi az OAT-hoz tartozó linket. +4. Szerezze meg az OAT-ot! + +Az OAT igényléséhez saját felügyeletű tárcát használjon. Ne használjon tőzsdei számlát vagy olyat, amelyhez nem rendelkezik privát kulccsal, mivel ezekkel nem lehet OAT-ot kezelni. + +## Igényeljen GitPOAP-ot {#claim-gitpoap} + +A GitPOAP automatikusan felismeri a beolvasztott hozzájárulást, és lehetővé teszi, hogy egy egyedi POAP-ot szerezzen a platformon! + + +### Hogyan kell kérni {#how-to-claim} + +1. Keresse fel a [GitPOAP](https://www.gitpoap.io) oldalt. +2. Kapcsolódjon a tárcájával vagy akár az e-mail-címével. +3. Használja GitHub felhasználói nevét, ETH-címét, ENS-nevét vagy bármilyen GitPOAP-ot, hogy a jogosultságát ellenőrizze. +4. Ha a GitHub-profilja jogosult, akkor készíthet magának egy GitPOAP-ot. + +## Hozzájárulók {#contributors} + + diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/faq/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/faq/index.md new file mode 100644 index 00000000000..726ef1860ab --- /dev/null +++ b/public/content/translations/hu/27) Contributing/contributing/translation-program/faq/index.md @@ -0,0 +1,119 @@ +--- +title: Fordítási program – gyakran ismételt kérdések (GYIK) +lang: hu +description: Gyakran ismételt kérdések az ethereum.org fordítási programról +--- + +# Útmutató az ethereum.org fordításához {#translating-ethereum-guide} + +Ha Önnek új a fordítási program és még kérdései vannak, akkor az alábbi gyakran ismételt kérdések segíthetnek a kezdésben. Ez az útmutató segít választ kapni a legjellemzőbb kérdésekre. + +## Kaphatok jutalmat az ethereum.org fordításáért? {#compensation} + +Az ethereum.org egy nyílt forráskódú honlap, ezért bárki részt vehet és hozzájárulhat. + +Az ethereum.org fordítási program ennek kiterjesztése és ugyanilyen elveken működik. + +A fordítási program célja, hogy az Ethereumhoz kapcsolódó tartalom mindenki számára elérhető legyen, függetlenül az általa beszélt nyelvektől. Azt is lehetővé teszi, hogy a több nyelvet beszélők részt vehessenek az Ethereum ökoszisztémájában és hozzájáruljanak ahhoz. + +Ezért a fordítási program nyitott és önkéntes, nem jár érte külön jutalom. Ha a lefordított szavak után fizetni kellene a fordítóknak, akkor a fordítási programba csak profi fordítók vehetnének részt. Emiatt a program kizárólagos lenne, és nem érné el a célját, azt, hogy bárki bevonódhasson és részt vehessen az ökoszisztémában. + +Mindent megteszünk, hogy a hozzájárulók sikeresek legyenek az Ethereum ökoszisztémában; számos nem pénzügyi ösztönző létezik, mint a [POAP-ok](/contributing/translation-program/acknowledgements/#poap) és a [fordítói igazolás](/contributing/translation-program/acknowledgements/#certificate), továbbá a [Fordítói ranglista](/contributing/translation-program/acknowledgements/) és [a fordítók megjelenítése a honlapon](/contributing/translation-program/contributors/). + +## Hogyan kell lefordítani a sztringeket, melyekben `` található? {#tags} + +Nem minden sztring jelenik meg egyszerű szövegként. Bizonyos sztringek tartalmaznak HTML tagokat (`<0>`, ``).Ezek lényege a hiperlinkek beillesztése, illetve a formázás. + +- A tagek közötti szöveget fordítsa le, de a tagekat ne. A `<` és `>` zárójelek között ne fordítson és ne változtasson semmit. +- A sztring egységessége érdekében használja az eredeti másolása (Copy Source) gombot balra lent. Ez átmásolja az eredeti sztringet és beilleszti a szövegdobozba. Ezzel a tagek egyértelműen a helyükön lesznek, és így nem fog semmi hiányozni. + +![Crowdin interfész, ahol az eredeti másolása gomb ki van emelve](./html-tag-strings.png) + +A sztingen belül mozgathatja a tagek helyét, hogy a fordításnak megfelelő helyen álljanak - csak egyszerre mozgassa minden részét. + +A tagek és kódrészletek kezeléséről többet megtudhat az [ethereum.org Fordítási stílusútmutatóból](/contributing/translation-program/translators-guide/#dealing-with-tags). + +## Hol élnek a sztringek? {#strings} + +Az eredeti sztring néha nem elég ahhoz, hogy pontos fordítást tudjon adni. + +- Nézze meg a „képernyőképeket” és a „kontextust” a további információkért. Az eredeti sztring szekciójában látható a képernyőkép, mely megmutatja, hogy milyen szövegkörnyezetben helyezkedik el a sztring. +- Ha mégis bizonytalan lenne, jelezze azt a „komment szekcióban”. [Nem tudja, hogyan írjon kommentet?](#comment) + +![Megmutatja, hogyan látszik a kontextus egy sztringnél a képernyőkép segítségével](./source-string.png) + +![Egy példa képernyőkép a kontextusban](./source-string-2.png) + +## Hogyan írjak kommentet vagy kérdezzek? Szeretnék jelezni valami gondot vagy elírást... {#comment} + +Ha egy adott sztring kapcsán jelezni szeretne valamit, írjon kommentet. + +- Kattintson a második gombra a jobb fenti menüsorban. Jobb oldalon megjelenik egy rejtett lap. Írja meg kommentjét vagy kattintson a „probléma” (issue) dobozra alul a bejelöléséhez. Kiválaszthatja a probléma típusát a legördülő menüből. +- Amint elküldi, az megjelenik a csapatunknál. Kijavítjuk a problémát, válaszolunk Önnek a kommentjére és lezárjuk azt. +- Ha egy helytelen fordítást jelez, akkor az adott fordítás és az új javaslat a következő átnézés során egy olyan személyhez kerül, aki beszéli az adott nyelvet. + +![Hogyan lehet kommenteket és kéréseket létrehozni](./comment-issue.png) + +## Mi az a fordítói memória (TM)? {#translation-memory} + +A fordítói memória (TM) egy Crowdin funkció, mely eltárolja a korábban fordított [ethereum.org](http://ethereum.org/) sztringeket. A sztring fordításkor automatikusan bekerül a projekt TM-jébe. Ez egy hasznos eszköz lehet, mellyel időt spórolhat! + +- Tekintse meg a „TM- és MT-javaslatokat”, és láthatja, hogy mások hogyan fordították az adott vagy hasonló kifejezést. Ha talál egy nagy mértékben illeszkedő megoldást, akkor úgy használhatja fel azt, hogy rákattint. +- Ha a lista üres, akkor kereshet a TM-ben korábbi fordításokat, hogy konzisztensen legyenek adott kifejezések használva. + +![A fordítói memóriáról készült képernyőkép](./translation-memory.png) + +## Hogyan használjam a Crowdin szószedetet? {#glossary} + +Az Ethereum terminológia egy másik fontos része a fordító tevékenységnek, mivel a legtöbb új technikai kifejezés még nem rendelkezik helyi megfelelővel. Emellett bizonyos kifejezések mást jelentenek a különböző kontextusokban. [Bővebben az Ethereum terminológiafordításáról](#terminology) + +A Crowdin szószedet jó hely arra, hogy a kifejezéseket és definíciókat tisztázzuk. Kétféleképpen lehet a szószedetet használni. + +- Először is, ha alá van húzva egy kifejezés az eredeti sztringben, akkor vigye oda az egeret és láthatja a rövid meghatározását. + +![Egy példa a szószedetben lévő definícióra](./glossary-definition.png) + +- Másodszor, ha lát egy ismeretlen kifejezést, de az nincs aláhúzva, akkor kereshet a szószedetben (harmadik gomb a jobb oszlopban). Itt megtalálja bizonyos kifejezések magyarázatát, melyek gyakran szerepelnek a projektben. + +![Képernyőkép, hogy hol található a Crowdin-ban a szószedet](./glossary-tab.png) + +- Ha nem találja, akkor adja hozzá! Keresse meg azt egy keresőben, és adja hozzá a meghatározást a szószedethez. Ezzel segítheti a többi fordítót is, hogy jobban megértsék a kifejezést. + +![Képernyőkép, hogyan lehet a Crowdin-ben új elemet felvinni a szószedetbe](./add-glossary-term.png) + +### Terminológiafordítási szabályzat {#terminology} + +_A nevek (márkák, cégek, emberek) és az új technológiai kifejezések (Beacon-lánc, shard láncok stb.) kapcsán_ + +Az Ethereum számtalan új kifejezést használ, melyeket nemrég találtak ki. Néhány kifejezés másképp fog megjelenni minden fordítónál, mert nincsen rá egy megoldás az adott nyelven. Az ilyen inkonzisztenciák félreértést okozhatnak és rontják az olvashatóságot. + +A nyelvi sokszínűség és a különféle sztenderdizációk miatt szinte lehetetlen egységesen hozzáállni a terminológia fordításához, mely mindenre használható lenne. + +Ezért a leggyakrabban használt kifejezéseket a fordítókra bízzuk. + +A következőket javasoljuk, ha ismeretlen kifejezéssel találkozik: + +- Tekintse meg a [szószedetet](#glossary), hogy más fordítók hogyan kezelték azt. Ha úgy véli, hogy a korábbi megoldások nem megfelelők, akkor adja hozzá a saját verzióját a szószedethez. +- Ha a szószedetben nincs semmi, nézze meg egy keresőben vagy a cikkekben, hogy a saját közössége hogyan használja azt. +- Ha nem talál ilyen előfordulást, akkor bízzon az intuíciójában és javasoljon egy megoldást! +- Ha bizonytalan lenne, akkor hagyja fordítás nélkül az adott kifejezést. Néha az angol kifejezések kellőképpen hordozzák a kifejezés értelmét. + +A márkák, cégek és emberek neveit hagyja meg, mert zavarhoz és SEO-nehézségekhez vezethet. + +## Hogyan működik az átnézés? {#review-process} + +A fordítások minőségének és konzisztenciájának érdekében az [Acolad](https://www.acolad.com/) végzi az átnézést, ami világ szinten az egyik legnagyobb nyelvi szolgáltató. Az Acolad 20 000 profi nyelvésszel dolgozik, akik szakmai átnézést biztosítanak minden nyelvre és tartalomra. + +Az átnézés folyamata egyértelmű; amint egy adott [tartalommappa](/contributing/translation-program/content-buckets) 100%-ban le van fordítva, akkor arra az adagra megrendeljük az átnézést. Az átnézés a Crowdin platformon történik. Amint az átnézéssel végeztek, a lefordított tartalom megjelenik a honlapon. + +## Hogyan adhatok hozzá tartalmat a saját nyelvemen? {#adding-foreign-language-content} + +Jelenleg a nem angol nyelvű tartalom közvetlenül angolból van fordítva, ezért olyan szöveg nem adható hozzá egy adott nyelvhez, amely nem létezik angolul. + +Ha szeretne az ethereum.org-ra új tartalmat javasolni, akkor [nyisson egy kérést](https://github.com/ethereum/ethereum-org-website/issues) a GitHub-on. Ha ezzel egyetértenek, az új tartalom angolul készül el, és a Crowdin platformon lesz lefordítva minden más nyelvre. + +A jövőben a tervek szerint nem angol nyelvű tartalom is bekerülhet majd. + +## Kapcsolatfevétel {#contact} + +Köszönjük, hogy áttekintette a fentieket. Reméljük, hogy ez segít bekapcsolódni a programba. Csatlakozzon a [Discord fordítási csatornához](https://discord.gg/ethereum-org), hogy választ kapjon a kérdéseire, egyeztessen a többi fordítóval, vagy írjon nekünk a translations@ethereum.org címre! diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/how-to-translate/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/how-to-translate/index.md new file mode 100644 index 00000000000..483e6474dfe --- /dev/null +++ b/public/content/translations/hu/27) Contributing/contributing/translation-program/how-to-translate/index.md @@ -0,0 +1,89 @@ +--- +title: Fordítási útmutató +lang: hu +description: Útmutató a Crowdin használatáról az ethereum.org fordítása kapcsán +--- + +# Fordítási útmutató {#how-to-translate} + +## Vizuális útmutató {#visual-guide} + +A vizuális tanulók tekintsék meg, ahogy Luka bemutatja a Crowdin használatát. Ugyanezeket a lépéseket találja meg írott formában alább. + + + +## Írott útmutató {#written-guide} + +### Csatlakozzon a projektünkhöz a Crowdin-ben {#join-project} + +Jelentkezzen be Crowdin-profiljába vagy készítsen egyet, ha még nem rendelkezik vele. A létrehozáshoz csak egy e-mail-címre és jelszóra lesz szüksége. + + + Csatlakozzon a projekthez + + +### Válassza ki a nyelvet {#open-language} + +Miután bejelentkezett a Crowdin-be, elolvashatja a projekt leírását és láthatja az elérhető nyelvek listáját. Minden nyelv információkat mutat arról, hogy mennyi lefordítandó szó van benne, mekkora tartalom van már lefordítva és jóváhagyva belőle. + +Nyissa meg a nyelvet, amelyre fordítani szeretne, így láthatja a fájlok listáját, melyek elérhetőek. + +![A nyelvek listája a Crowdin-ben](./list-of-languages.png) + +### Válasszon ki egy dokumentumot, amelyen dolgozni kíván {#find-document} + +A honlap tartalma fel van osztva dokumentumokra és tartalommappákra. A dokumentumok státuszát láthatja a jobb oldalon - ha a fordítási eredmény kisebb mint 100%, akkor segítsen be! + +Nem találja a nyelvet? [Nyisson egy kérést](https://github.com/ethereum/ethereum-org-website/issues/new/choose) vagy kérdezze meg a [Discord](/discord/) csatornán + +![A lefordított és még nem fordított fájlok a Crowdin-ban](./crowdin-files.png) + +Megjegyzés a tartalommappákról: ezekre azért van szükség Crowdin-ben, hogy a legfontosabb tartalom legyen kész a leghamarabb. Amikor megnyit egy nyelvet, például a [filipinót](https://crowdin.com/project/ethereum-org/fil#) , akkor tartalommappákat lát (1. Kezdőoldal, 2. Alapvető dolgok, 3. Felfedezés stb.). + +Kérjük, hogy fordítását ebben a sorrendben végezze (1 → 2 → 3 → ⋯), hogy a legfontosabb oldalak készüljenek el először. + +[Tudjon meg többet az ethereum.org tartalommappáiról](/contributing/translation-program/content-buckets/) + +### Fordítsás {#translate} + +Miután kiválasztotta a fordítani kívánt fájlt, az megnyílik az online szerkesztőben. Ha még nem használta a Crowdin-t korábban, ez az útmutató bemutatja az alapvető dolgokat. + +![A Crowdin online szerkesztője](./online-editor.png) + +**_1 – Bal oldali menü_** + +- Nincs lefordítva (piros) – olyan szöveg, amelyet még nem fordítottak le. Ezekkel a sztringekkel kell foglalkoznia. +- Le van fordítva (zöld) – ezeket a szövegeket már lefordították, de még nem lettek átnézve. Ezekhez javasolhat alternatív megoldásokat, vagy szavazhat a meglévőkre a szerkesztő + és - gombjaival. +- Jóváhagyott (pipa) – olyan szöveg, melyet átnéztek és már élőben látható a honlapon. + +A tetején található keresőben specifikus sztringeket is kereshet, illetve tud státusz alapján szűrni vagy átállítani a nézetet. + +**_2 – Szerkesztői terület_** + +A fő fordítási terület – a forrásszöveg felül jelenik meg, a releváns szövegkörnyezettel és képernyőképekkel, ha azok rendelkezésre állnak. A fordítás beviteléhez írja a szöveget az „Ide írja a fordítást” (Enter translation here) mezőbe és mentsen. + +A sztring meglévő fordításait és más nyelvekre való átültetését is itt láthatja, továbbá a fordítási memória találatai és a gépi fordítás javaslatai is itt jelennek meg. + +**_3 – Jobb oldali menü_** + +Itt találhatók a kommentek, a fordítási memória találatai és a szószedet tételei. Az alapnézet a kommenteket mutatja, ahol a fordítók kommunikálhatnak, jelezhetik a problémákat vagy a helytelen fordításokat. + +A tetején lévő gombokkal átválthat a fordítási memóriára, ahol a meglévő fordításokat találja, vagy megnézheti a szószedetet, mely a kulcsfogalmak definícióit és sztenderd fordításait mutatja. + +Szeretne többet megtudni? Tekintse meg a [dokumentációt a Crowdin online szerkesztőről](https://support.crowdin.com/online-editor/) + +### A fordítás átnézése {#review-process} + +Miután befejezte a fordítást (a tartalommappa összes fájlja 100%-ot mutat), a professzionális fordítási szolgáltatás ellenőrzi (és javítja) a tartalmat. Az átnézés után (vagyis az átnézés is 100%-ot mutat), bekerül a fordítás a honlapra. + + + Ne használjon gépi fordítást, az nem elfogadott. Minden fordítást átnézünk, mielőtt felkerülne a honlapra. Ha a javasolt fordításról kiderül, hogy gép végezte, akkor azokat elvetjük, és a gépi fordítást használó közreműködőket eltávolítjuk a projektből. + + +### Kapcsolatfevétel {#get-in-touch} + +Kérdése van? Vagy szeretne együttműködni a csapatunkkal és más fordítókkal? Írjon nekünk a #translations csatornán az [ethereum.org Discord szerveren](/discord/) + +Elérhet minket a translations@ethereum.org címen is + +Köszönjük, hogy részt vesz az ethereum.org fordítási programban! diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/index.md new file mode 100644 index 00000000000..f96ca43b5ca --- /dev/null +++ b/public/content/translations/hu/27) Contributing/contributing/translation-program/index.md @@ -0,0 +1,90 @@ +--- +title: Fordítási Program +lang: hu +description: Információk az ethereum.org fordítási programról +--- + +# Fordítási Program {#translation-program} + +A fordítási program egy közös erőfeszítés, hogy az ethereum.org mindenféle nyelvre le legyen fordítva, hogy a világon sok milliárdnyi nem angol anyanyelvű ember számára elérhetővé váljon. + +![](./enterprise-eth.png) + +## Segítsen a fordításban {#help-us-translate} + +Az ethereum.org fordítási program nyitott és bárki közreműködhet! + +1. Jelentkezzen be a Crowdin profiljába vagy regisztráljon. +2. Válassza ki a nyelvet, amelyre fordítani szeretne. +3. Mielőtt belekezd, tekintse meg a [fordítási útmutatót](/contributing/translation-program/how-to-translate/) a Crowdin használatának elsajátításához, valamint a [fordítási stílusútmutatót](/contributing/translation-program/translators-guide/) a tippek és bevált gyakorlatok érdekében. +4. A gépi fordítás nem elfogadható. +5. Minden fordítást átnéznek, mielőtt a honlapra felkerül, így a lefordított anyag bizonyos késéssel válik elérhetővé. + +_Csatlakozzon az [ethereum.org Discord](/discord/)-csatornájához, hogy megvitassa a fordítással kapcsolatos dolgokat, kérdezzen, visszajelzést adjon, megossza az ötleteit vagy csatlakozzon a fordítói csoporthoz._ + + + Kezdjen bele a fordításba + + +## A fordítási programról {#about-us} + +Az Ethereum-közösség célja, hogy globális és befogadó legyen, a tartalom nagy része ugyanakkor az angolul beszélőknek szól, ezzel kizárva a világ mintegy 6 milliárd nem angolul beszélő emberét. Ahhoz, hogy az ethereum.org legyen az Ethereumba vezető kapu egy világméretű közösség számára, a nem angolul beszélőknek a tartalmat anyanyelvükön szeretnénk átadni. + +Az ethereum.org fordítási program célja, hogy az Ethereum mindenkinek elérhető legyen, ezért az ethereum.org-ot és más Ethereum tartalmat a lehető legtöbb nyelvre le szeretnénk fordítani. + +Tudjon meg többet az ethereum.org fordítási program [missziójáról és víziójáról](/contributing/translation-program/mission-and-vision). + +### Eddigi eredményeink {#our-progress} + +- [**Több mint 6000** fordító](/contributing/translation-program/contributors/) +- **62** nyelv elérhető a honlapon +- [**3 millió** szó került lefordításra 2023-ban](/contributing/translation-program/acknowledgements/) + + + +### Köszönetnyilvánítások {#acknowledgements} + +Az ethereum.org-ot sok ezer közösségi tag fordítja, akik a fodítási program magját alkotják. Szeretnénk elismerni a fordítókat, és támogatni őket karrierjükben. Íme néhány elismerés a fordítóknak: + +#### Tanúsítvány {#certificate} + +Ha Ön közreműködött a fordítási programban és legalább 5000 szónyi fordítását jóváhagyták, akkor kérhet tanúsítványt. [Bővebben a tanúsítványokról](/contributing/translation-program/acknowledgements/#certificate) + +#### OAT-ok {#oats} + +A fodítási program résztvevői különféle OAT-okat (láncon belüli eredménytoken) kaphatnak a lefordított szavak száma alapján 2024-ben. Az OAT-ok olyan NFT-k, melyek igazolják a résztvételüket az ethereum.org fodítási programban. [Bővebben az OAT-okról](/contributing/translation-program/acknowledgements/#oats) + +#### Fordítói elismerések {#translator-acknowledgements} + +A legaktívabb fordítókat megjelenítjük a [ranglistákon](/contributing/translation-program/acknowledgements/), valamint az [összes közreműködőt is listázzuk](/contributing/translation-program/contributors/). + +#### Jutalmak {#rewards} + +Korábban visszamenőleg Ethereum-konferenciákra szóló jegyekkel jutalmaztuk a legaktívabb közreműködőket, mint amilyen a [Devcon](https://devcon.org/en/) és a [Devconnect](https://devconnect.org/), továbbá exkluzív ethereum.org ajándékokat kaptak. + +Folyamatosan törekszünk új és innovatív módon elismerni a résztvevőket, ezért mindenképpen maradjon velünk! + +### Útmutatók és anyagok {#guides-and-resources} + +Ha Ön is részt vesz a fodítási programban, vagy gondolkodik rajta, érdemes megnéznie az alábbi útmutatókat: + +- [Fordítási stílusútmutató](/contributing/translation-program/translators-guide/) _– instrukciók és tippek az ethereum.org fordítóinak_ +- [Fordítási GYIK](/contributing/translation-program/faq/) _– gyakran ismételt kérdések és válaszok az ethereum.org fordítási programjáról_ +- [Crowdin online szerkesztői útmutató](https://support.crowdin.com/online-editor/) _– részletes útmutató a Crowdin online szerkesztő és néhány haladóbb funkció használatáról_ +- [Tartalommappák](/contributing/translation-program/content-buckets/) _– az ethereum.org tartalommappáiba melyik oldalak tartoznak_ + +További hasznos fordítási eszközökért, fordítói közösségekért, illetve fordítási program blogbejegyzéseiért keresse fel az [Erőforrások oldalt](/contributing/translation-program/resources/). + +## Kapcsolatfevétel {#get-in-touch} + +Kérdése van? Vagy szeretne együttműködni a csapatunkkal és más fordítókkal? Írjon nekünk a #translations csatornán az [ethereum.org Discord szerveren](https://discord.gg/ethereum-org) + +Elérhet minket a translations@ethereum.org címen is + +## Kezdjen saját fordítási programba {#starting-a-translation-program} + +Arra törekszünk, hogy az Ethereum tartalom minél több nyelven olvasható legyen, és így az oktatási anyagok mindenki számára elérhetővé váljanak. Ezzel összhangban szeretnénk segíteni más Ethereum-projekteknek a saját fordításuk megszervezésében, kezelésében és fejlesztésében. + +Ezért létrehoztunk a [Fordítási program munkafüzetet](/contributing/translation-program/playbook/), amely tartalmazza azokat a tippeket és bevált gyakorlatot, amelyeket az ethereum.org fordítása során gyűjtöttünk. + +Szeretne közreműködni vagy használná a fordítási forrásokat? Van visszajelzése a munkafüzet kapcsán? Szívesen hallanánk róla a translations@ethereum.org címen. diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/mission-and-vision/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/mission-and-vision/index.md new file mode 100644 index 00000000000..670ed406c52 --- /dev/null +++ b/public/content/translations/hu/27) Contributing/contributing/translation-program/mission-and-vision/index.md @@ -0,0 +1,25 @@ +--- +title: Küldetés és vízió +lang: hu +description: Az ethereum.org fordítási program missziója és víziója +--- + +# Küldetés és vízió {#mission-and-vision} + +Az Ethereum-közösség célja, hogy globális és befogadó legyen, a tartalom nagy része ugyanakkor az angolul beszélőknek szól, ezzel kizárva a világ mintegy 6 milliárd nem angolul beszélő emberét. Ahhoz, hogy az ethereum.org legyen az Ethereumba vezető kapu egy világméretű közösség számára, a nem angolul beszélőknek a tartalmat anyanyelvükön szeretnénk átadni. + +Az ethereum.org fordítási program célja, hogy az Ethereum mindenkinek elérhető legyen, ezért az ethereum.org-ot és más Ethereum tartalmat a lehető legtöbb nyelvre le szeretnénk fordítani. + +## Küldetésünk {#our-mission} + +- Biztosítjuk a honlap lefordítását, hogy a világ bármely részéről érkező látogatók a saját nyelvükön ismerhessék meg az Ethereumot +- Segítjük, hogy bárki csatlakozhasson a globális Ethereum közösség tagjaihoz +- Elősegítjük az Ethereumról szóló információk és tudás könnyebb elérését és mindenkit felölelő megosztását +- Támogatjuk a közösség tagjait, hogy részt vegyenek az Ethereum lefordításában, és nyomot hagyjanak az ökoszisztémában +- Beazonosítjuk, kapcsolódunk és útmutatást adunk azoknak a lelkes közreműködőknek, akik részt szeretnének venni az ökoszisztémában + +## A jövőképünk {#our-vision} + +- Lefordítjuk a lényeges tartalmakat az Ethereum közösség tagjai számára, akik a világ lehető legtöbb országából és részéből származnak +- Támogatjuk a tudásmegosztást minden nyelven, hogy egy jól informált és tanult Ethereum közösség legyen +- Növeljük az Ethereumba való bevonást és annak elérhetőségét azzal, hogy a nyelvi akadályokat elhárítjuk, ami miatt az angolul nem beszélők esetleg ne tudjanak csatlakozni az ökoszisztémához diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/resources/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/resources/index.md new file mode 100644 index 00000000000..8f448dde469 --- /dev/null +++ b/public/content/translations/hu/27) Contributing/contributing/translation-program/resources/index.md @@ -0,0 +1,45 @@ +--- +title: Források a fordítóknak +lang: hu +description: Hasznos források az ethereum.org fordítóinak +--- + +# Források {#resources} + +Alább láthatja a hasznos útmutatókat és eszközöket az ethereum.org fordításához, továbbá fordítói közösségeket és híreket is találhat. + +## Útmutatók {#guides} + +- [Fordítási stílusútmutató](/contributing/translation-program/translators-guide/) _– instrukciók és tippek az ethereum.org fordítóinak_ +- [Fordítási GYIK](/contributing/translation-program/faq/) _– gyakran ismételt kérdések és válaszok az ethereum.org fordítási programjáról_ +- [Crowdin online szerkesztői útmutató](https://support.crowdin.com/online-editor/) _– részletes útmutató a Crowdin online szerkesztő és néhány haladóbb funkció használatáról_ +- [Tartalommappák](/contributing/translation-program/content-buckets/) _– az ethereum.org tartalommappáiba melyik oldalak tartoznak_ + +## Eszközök {#tools} + +- [Microsoft Language Portal](https://www.microsoft.com/en-us/language) _– megtalálhatja a technikai kifejezésekhez tartozó sztenderd fordításokat_ +- [Linguee](https://www.linguee.com/) _– fordításokhoz keresőmotor és szótár, mely szavak vagy kifejezések alapján is használható_ +- [Proz term search](https://www.proz.com/search/) _– adatbázis, melyben fordítói szótárak és speciális kifejezések szószedetei találhatók_ +- [Eurotermbank](https://www.eurotermbank.com/) _– európai kifejezések gyűjteménye 42 nyelven_ + +## Közösségek {#communities} + +- [Nyelvspecifikus Discord fordítói csoportok](/discord/) _– az ethereum.org fordítók összekapcsolása fordítói csoportokban_ +- [Kínai fordítói csoport](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) _– Notion oldal a kínai fordítók közötti koordinációhoz_ + +## Legfrissebb hírek {#latest-updates} + +A fordítási program legfrissebb híreihez tekintse meg az [Ethereum Alapítvány blogját](https://blog.ethereum.org/): + +- [2021. október – mérföldkövek frissítése](https://blog.ethereum.org/2021/10/04/translation-program-update/) +- [2020. december – mérföldkövek frissítése](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/) +- [2020. július – mérföldkövek frissítése](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/) +- [2019. augusztus – a fordítási program bevezetése](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/) + +## Fogadóóra a fordítóknak {#office-hours} + +Minden hónap második szerdáján tartunk fogadóórát a fordítóknak. Az #office-hours voice channel az [ethereum.org Discord](/discord/) csatornáján található, ahol pontos időpontokat és további részleteket is talál. + +A fogadóórák során a fordítók kérdezhetnek, visszajelzést adhatnak, megoszthatják elképzeléseiket, és beszélgethetnek az ethereum.org csapatával. Ezeket a megbeszéléseket arra is használjuk, hogy a legújabb dolgokat megosszuk a fordítási program kapcsán, illetve a fontos tippeket és útmutatásokat átadjuk a közreműködőknek. + +Csatlakozzon, amennyiben Ön is az ethereum.org fordítója vagy szeretne az lenni. diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/translators-guide/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/translators-guide/index.md new file mode 100644 index 00000000000..6682ee378d9 --- /dev/null +++ b/public/content/translations/hu/27) Contributing/contributing/translation-program/translators-guide/index.md @@ -0,0 +1,293 @@ +--- +title: Fordítási útmutató +lang: hu +description: Instrukciók és tippek az ethereum.org fordítóinak +--- + +# Ethereum.org fordítási stílusútmutató {#style-guide} + +Az ethereum.org fordítási stílusútmutató a legfontosabb iránymutatásokat, instrukciókat és tippeket tartalmazza a fordítók számára, hogy a honlapot helyi nyelveken tudjuk megjeleníteni. + +Ez egy általános útmutató, nem nyelvspecifikus. + +Ha bármilyen kérdése, javaslata vagy visszajelzése van, írjon nekünk a translations@ethereum.org-ra, üzenjen a @ethdotorg-ra a Crowdin-ban, vagy [csatlakozzon a Discord](https://discord.gg/ethereum-org) csatornához, ahol üzenhet a #translations beszélgetésben. + +## A Crowdin használata {#using-crowdin} + +A [fordítási program oldalon](/contributing/translation-program/#how-to-translate) találhat alapvető instrukciókat arról, hogyan csatlakozzon a Crowdin-ban a projekthez és hogyan kell az online szerkesztőt használni. + +Ha többet szeretne megtudni a Crowdin-ről és a haladóbb funkcióiról, akkor a [Crowdin tudástárban](https://support.crowdin.com/online-editor/) minden funkcióról részletes útmutatókat és áttekintéseket találhat. + +## Az üzenet lényegének megragadása {#capturing-the-essence} + +Amikor az ethereum.org tartalmát fordítja, ne ragaszkodjon a szó szerinti átültetéshez. + +Az üzenet lényegét ragadja meg. Ehhez talán át kell fogalmazni bizonyos mondatokat, vagy leírást kell alkalmazni a szavankénti fordítás helyett. + +A különféle nyelvek eltérő nyelvtani szabályokkal, konvenciókkal és szórenddel bírnak. A fordításnál vegye figyelembe a célnyelv logikáját, és ne ragaszkodjon az angol stuktúrájához, mert ennek gyenge megfogalmazás és olvashatóság lesz a következménye. + +Olvassa el az egész mondatot, és alakítsa úgy, hogy az a célnyelvnek megfeleljen. + +## Magázás vagy tegezés {#formal-vs-informal} + +Magázást használunk, mert az mindig udvarias és minden látogatónak megfelel. + +Ilyen megfogalmazással elkerülhetők a nem hivatalosnak vagy támadónak hangzó kifejezések, és a látogatók korától és nemétől függetlenül mindig alkalmas. + +A legtöbb indoeurópiai és afro-ázsiai nyelv nemspecifikus második személyű személyes névmásokat használ, amelyek megkülönböztetik a férfiakat és a nőket. A felhasználó megszólításakor vagy a birtokos névmások használatakor elkerülhetjük a látogató nemének feltételezését, mivel a formális megszólítási forma általánosan alkalmazható és következetes, függetlenül attól, hogy a látogató hogyan azonosítja magát. + +## Egyszerű és tiszta szóhasználat és jelentés {#simple-vocabulary} + +Az a célunk, hogy a honlapon lévő tartalom mindenki számára érthető legyen. + +Ez könnyen elérhető rövid és egyszerű szavak használatával. Ha több szó is rendelkezésre áll az adott nyelven, akkor a legjobb a legrövidebb kifejezés, amely visszaadja a jelentést. + +## Írásrendszerek {#writing-system} + +Az ethereum.org számos nyelven elérhető a latinhoz képest eltérő írásrendszerek (vagy írásjelek) használatával. + +A tartalom az adott nyelvnek megfelelő írásrendszeren kell megjelenjen, és ne tartalmazzon latin írásjeleket. + +A tartalom átültetésénél biztosítani kell, hogy a fordítás konzisztens legyen és nem tartalmazzon latin írásjeleket. + +Általános félreértés, hogy az Ethereum kifejezéseinek latin írásjelekkel kell megjelennie. Ez nem helyes, inkább a kiejtését használjuk minden helyi nyelven (például 以太坊 kínaiul, إيثيريوم arabul stb.). + +**Ez természetesen nem alkalmazható azokra a nyelvekre, ahol a tulajdonneveket nem fordítják le.** + +## Az oldal metaadatának fordítása {#translating-metadata} + +Néhány oldal tartalmaz metaadatokat, mint „title”, „lang”, „description”, „sidebar” stb. + +A Crowdin-ban el van rejtve az a szöveg, melyet nem kell lefordítani, tehát a látható metaadatokhoz is megfelelő fordításra van szükség. + +Legyen körültekintő, amikor a forrásszöveg „en” jelöléssel szerepel. Ez mutatja, hogy az oldal milyen nyelven elérhető, és a [helyi nyelv ISO-nyelvikódjára](https://www.andiamo.co.uk/resources/iso-language-codes/) kell fordítani. Ezeket a sztringeket latin írásjelekkel kell írni, nem más írásrendszerrel. + +A nyelvi kódokhoz nézze meg a Crowdin fordítási memóriáját, vagy az online szerkesztőben is láthatja az oldal URL-jében. + +Néhány példa a nyelvi kódokra: + +- Arab - ar +- Egyszerűsített kínai - zh +- Francia - fr +- Hindi - hi +- Spanyol - es + +## Külsős cikkek címei {#external-articles} + +Néhány sztring külsős cikkek címeit is tartalmazza. A legtöbb fejlesztői dokumentáció ajánl további olvasmányokat külsős cikkek formájában. Ezeket a címeket le kell fordítani a helyi nyelvre, hogy a látogató konzisztens módon tudja elolvasni a szöveget. + +Alább talál néhány példát arra, hogyan néznek ki ezek a sztringek, hogyan lehet ezeket azonosítani (a cikkekre mutató hivatkozások az oldalak alján, a További olvasnivalók részben találhatók): + +![Cikkcímek az oldalsó menüben](./article-titles-in-sidebar.png) ![Cikkcímek a szerkesztőben](./article-titles-in-editor.png) + +## Crowdin figyelmeztetések {#crowdin-warnings} + +A Crowdin beépített funkciója, hogy hibák esetén jelez a fordítónak. Automatikus figyelmeztet mentés előtt, ha lemaradt egy tag a forrás szerint, ha olyan elemet fordított le, melyet nem szabad, ha több szóköz van valahol, hiányzik a mondat végén az írásjel stb. Amikor ilyen figyelmeztetést lát, kérjük, hogy nézze meg még egyszer a fordítását. + +**Ezek mindig azt jelzik, hogy valami eltérés van vagy fontos rész hiányzik.** + +Így néz ki egy Crowdin figyelmeztetés, ha lemarad egy tag: ![Példák a Crowdin figyelmeztetéseire](./crowdin-warning-example.png) + +## Tagek és kódrészletek kezelése {#dealing-with-tags} + +Számos szöveg tartalmaz tageket és variánsokat, amelyeket a szerkesztőben sárgával láthatunk. Ezeknek funkciójuk van, ezért megfelelően kell kezelni őket. + +**Crowdin-beállítások** + +A tagek kezeléséhez és másolásához azt javasoljuk, hogy változtassa meg a beállítását. + +1. Beállítások megnyitása ![Hogyan kell a beállításokat megnyitni a szerkesztőben](./editor-settings.png) + +2. Gördítsen le a HTML-tagek megjelenítése pontig + +3. „Elrejtés” kiválasztása![Válassza ki az „Elrejtés” lehetőséget](./hide-tags.png) + +4. Kattintson a „Mentés” lehetőségre + +Ebben az eseten nem a teljes tag látszik, hanem egy szám lesz a helyén. A fordításnál ezekre a tagekre kattintva a teljes hivatkozást átmásolja a fordítói mezőbe. + +**Hivatkozások** + +Teljes hivatkozásokat is találhat az ethereum.org vagy más honlapokra vonatkozóan. + +Ezek maradjanak azonosak a forrással, ne változtassa meg őket. Ha bármit változtat a hivatkozásokon, akár egy perjelet is kivesz, akkor azok használhatatlanná válnak. + +A hivatkozásokat másolja át egyenesen a forrásból, kattintson rájuk vagy használja a „forrás másolása” (copy source) gombot (Ctrl+Shift+C). + +![Example of link.png](./example-of-link.png) + +A hivatkozások tagekkel formázva is megjelennek a forrásszövegben (vagyis <0> ). Ha a tagek fölé mozgatja a kurzort, akkor megnézheti a tartalmát - ezek sokszor hivatkozásokat tartalmaznak. + +A hivatkozásokat mindig másolja át a forrásból, ne változtassa meg a sorrendjüket. + +Ha a tagek megváltoznak, akkor az általuk képviselt hivatkozások használhatatlanok lesznek. + +![Example of links inside tags.png](./example-of-links-inside-tags.png) + +**Tagek és variánsok** + +A forrás sokféle taget tartalmaz, melyeket mindig másoljon át a forrásból. A sorrendjük is maradjon a forrásnak megfelelő. + +A tageknél mindig van nyitó és zárótag. Az ezek közé eső szöveget általában le kell fordítani. + +Például: ``Decentralizált`` + +`` - _Ez egy nyitótag, melytől félkövér lesz a szöveg_ + +Decentralizált - _Fordítandó szöveg_ + +`` - _Zárótag_ + +![Example of 'strong' tags.png](./example-of-strong-tags.png) + +A kódrészleteket másképp kell megközelíteni, mert ezek kódot tartalmaznak és nem szabad lefordítani. + +Például: ``nonce`` + +`` - _Nyitótag, melyben egy kódrészlet van_ + +nonce - _Nem fordítható szöveg_ + +`` - _Zárótag_ + +![Example of code snippets.png](./example-of-code-snippets.png) + +A forrás tartalmaz rövidített tagokat is, melyek csak számként jelennek meg, a tartalmuk nem egyértelmű ránézésre. Ha a kurzort fölé mozgatjuk, akkor látszik, hogy mit tartalmaznak. + +Az alábbi példában látszik, hogy a kurzort odamozgatva <0> azt mutatja, hogy `` és egy kódrészletet tartalmaz, így azt nem kell lefordítani. + +![Example of ambiguous tags.png](./example-of-ambiguous-tags.png) + +## Rövid és hosszú alakok/rövidítések {#short-vs-full-forms} + +Számos rövidítést használunk a honlapon, például dapp-ok, NFT, DAO, DeFi stb. Ezek elfogadott rövidítések az angolban és a legtöbb felhasználó számára ismerősek. + +Mivel ezeknek nem létezik más nyelvre való átültetése, ezért a legjobb módszer egy leíró fordítás használata, mely mellé bekerül zárójelbe az eredeti rövidítés. + +Ne fordítsa le a rövidítést, mert nem fogják felismerni a felhasználók és a helyi megoldás nem lesz számukra ismerős. + +Például a dapp-ok fordítása: + +- Decentralizált alkalmazások (dapp-ok) → _Teljes formában lefordítva (angol rövidítés zárójelben)_ + +## Kifejezések, melyekre nincs bevett fordítás {#terms-without-established-translations} + +Bizonyos kifejezéseknek nincs bevett fordítása az adott nyelven, és inkább angolul ismeri mindenki. Az ilyen kifejezések sokszor új koncepciókat fednek le, mint a proof-of-work, proof-of-stake, Beacon-lánc, staking stb. + +Bár a fordítás furcsán hathat, mégis érdemes lenne átültetni ezeket a helyi nyelvre. + +A fordításnál legyen kreatív, írja körül vagy egyszerűen írja át a saját nyelvére. + +**Azért érdemes lefordítani a helyi nyelvre és nem angolul használni, mert a jövőben ez az új terminológia sokkal elterjedtebb lesz, ahogy sokan kezdik el használni az Ethereumot és a kapcsolódó technológiákat. Az új emberek bevonásához érthető terminológiára van szükség minden nyelven, még ha azt nekünk is kell kitalálni.** + +## Gombok és CTA-k {#buttons-and-ctas} + +A honlapon számos gomb található, melyet másképpen kell lefordítani. + +A gomb szövegét úgy lehet beazonosítani, hogy a kontextusban található képernyőképen látható, vagy a szerkesztőben a „button” kifejezéssel szerepel. + +A fordítás legyen a lehető legrövidebb, hogy ne okozzon gondot a formázásnál. Emellett legyen felszólító módban, vagyis egy utasítást vagy kérést tükrözzön. + +![Hogyan lehet felismerni a gombot](./how-to-find-a-button.png) + +## Fordítás a befogadás szellemében {#translating-for-inclusivity} + +Az ethereum.org látogatói a világ minden tájáról jönnek és különféle háttérrel rendelkeznek. Ezért a honlap nyelve legyen semleges, mindenkit befogadó, nem kizáró jellegű. + +Ennek fontos szempontja a nemi semlegesség. Ehhez a formális megszólításokat érdemes használni, és elkerülni a nemre utaló kifejezéseket a fordításban. + +A bevonás másik szempontja a globális közönség figyelembe vétele, amely nem szűkül le semelyik országra, fajra vagy régióra. + +Végül a nyelve legyen megfelelő mindenféle közönségnek és korosztálynak. + +## Nyelvspecifikus fordítások {#language-specific-translations} + +A fordítás közben ügyeljen arra, hogy az adott nyelv nyelvtani szabályait, konvencióit és formázását kövesse, ne a forrást vegye figyelembe. A forrásszöveg az angol szabályokat követi, melyek nem feltétlen alkalmazhatók más nyelveknél. + +Ismerje és használja a saját nyelvének szabályait megfelelő módon. Ha segítségre van szüksége, akkor jelezze, és megpróbálunk információkat találni az adott nyelv szabályairól. + +Néhány példa, hogy mire kell különösen odafigyelni: + +### Írásjelek, formázás {#punctuation-and-formatting} + +**Nagybetüs írásmód** + +- A nagybetüs írásmód jelentősen eltér a különféle nyelvekben. +- Az angolban minden címet és nevet, a hónapokat és napokat, a nyelvek neveit, az ünnepeket stb. mind nagybetűvel írják. Más nyelvekben ez hibásnak minősül, mert más szabályokat követnek. +- Máshol jellemző a személyes névmások, főnevek és bizonyos melléknevek nagybetűvel való írása, ami az angolban másképp van. + +**Szóközhasználat** + +- A helyesírási szabályok megadják az adott nyelv szóközhasználatát. Mivel szóközt mindenhol használunk, ezért ezek a szabályok a legkülönfélébbek és könnyű elrontani a fordításban. +- Néhány jellemző különbség az angol és más nyelvek között: + - Szóköz a mértékegységek és valuták előtt (pl. USD, EUR, kB, MB) + - Szóköz a hőfokot jelző jel előtt (pl. °C, ℉) + - Szóköz néhány írásjel előtt, mint a szókihagyás (…) + - Szóköz a perjel (/) előtt és után + +**Listák** + +- Minden nyelvben eltérő szabályok vonatkoznak a listák írására. Melyek jelentősen eltérhetnek az angoltól. +- Néhány nyelvben az első szót nagybetűvel kell írni, máshol kisbetűvel kezdik. Számos nyelvben más szabály van a nagybetűvel való írásra attól függően, hogy milyen hosszúak a sorok. +- Ez igaz a mondatvégi írásjelekre is. A lista végén lehet pont (**.**), vessző (**,**) vagy pontosvessző (**;**) a nyelvtől függően. + +**Idézőjelek** + +- A nyelvek másféle idézőjeleket használnak. Az angol átmásolása általában nem helyes. +- A leggyakoribb példák: + - „példaszöveg“ + - ‚példaszöveg’ + - »példaszöveg« + - “példaszöveg” + - ‘példaszöveg’ + - «példaszöveg» + +**Kötőjelek és gondolatjelek** + +- Az angolban a kötőjelet (-) arra használják, hogy szavakat vagy szórészeket kapcsoljanak össze, miközben a gondolatjel (–) inkább tartományt vagy megállást jelöl. +- Sok nyelvben eltérő a használata a kötőjelnek és a gondolatjelnek, melyet figyelembe kell venni. + +### Formátumok {#formats} + +**Számok** + +- A számok írásában a legnagyobb eltérés a decimális és az ezres elválasztás jelölése. Az ezres elválasztás lehet pont, vessző vagy szóköz. Ehhez hasonlóan néhány nyelv pontot használ a decimálisnál, mások vesszőt. + - Néhány példa: + - Angol – **1,000.50** + - Spanyol – **1.000,50** + - Francia – **1 000,50** +- Másik fontos megfontolás lehet a százalékjel használata. Különféle módokon lehet írni: **100%**, **100 %** vagy **%100**. +- Végül a negatív számok írásmódja is eltérhet a nyelvtől függően: -100, 100-, (100) vagy [100]. + +**Dátumok** + +- A dátumok írásánál számos dolgot figyelembe kell venni a nyelvi eltérések miatt. A dátum formátuma, elválaszás, nagybetű használata és kezdő nullák használata. Különbség van a teljes hosszúságú és a számokkal írt dátum között is. + - Néhány példa a dátumformátumokra: + - Angol UK (dd/mm/yyyy) – 1st January, 2022 + - Angol US (mm/dd/yyyy) – January 1st, 2022 + - Kínai (yyyy-mm-dd) – 2022 年 1 月 1 日 + - Francia (dd/mm/yyyy) – 1er janvier 2022 + - Olasz (dd/mm/yyyy) – 1º gennaio 2022 + - Német (dd/mm/yyyy) – 1. Januar 2022 + +**Pénznemek** + +- A pénznemek fordítása nehézsége okozhat a különféle formátumok, konvenciók és átváltások miatt. Általános szabályként hagyjuk meg az eredeti szövegben lévő pénznemet. Az olvasó kedvéért hozzátehetjük zárójelben a helyi pénznemet és átváltást. +- Az írásbeli eltérés a szimbólumok elhelyezésében, a decimális jelölőkben, a szóközben, rövidítésekben vagy szimbólumok használatában áll. + - Szimbólum elhelyezése: $100 vagy 100$ + - Decimális vessző vagy pont: 100,50$ vagy 100.50$ + - Szóközhasználat: 100$ vagy 100 $ + - Rövidítések vagy szimbólumok: 100 $ vagy 100 USD + +**Mértékegységek** + +- Általános szabályként hagyjuk meg az eredeti szövegben lévő mértékegységeket. Ha más rendszert használ egy adott ország, akkor zárójelben meg lehet mutatni azt is. +- A helyi használat mellett vannak más eltérések is a nyelveknél. A fő különbség a szóközhasználat a szám és a mértékegység között van, mely eltérhet nyelvenként. Például 100kB vagy 100 kB, 50ºF vagy 50 ºF. + +## Következtetés {#conclusion} + +Az ethereum.org fordítása remek lehetőség arra, hogy az Ethereum különféle aspektusait megismerjük. + +A fordítás során próbáljon meg nem sietni. Élvezze a folyamatot, leljen benne örömet! + +Köszönjük, hogy részt vesz a fordítási programban, s lehetővé teszi, hogy a honlap mások számára is elérhető legyen. Az Ethereum közössége globális, örülünk, hogy Ön is a tagja! diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-desci-projects/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-desci-projects/index.md new file mode 100644 index 00000000000..8906c876f09 --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/adding-desci-projects/index.md @@ -0,0 +1,44 @@ +--- +title: DeSci projektek hozzáadása +description: Az az irányelv, amelyet követünk, amikor hivatkozást adunk hozzá a projektekhez a DeSci oldalon az ethereum.org webhelyen +lang: hu +--- + +# Projektek hozzáadása {#adding-projects} + +Szeretnénk biztosítani, hogy különböző projekteket mutassunk be, és jó áttekintést nyújtsunk a DeSci tájékozódásáról. + +Bárki szabadon javasolhat egy projektet, amelyet felsorolhatnak a DeSci oldalon az ethereum.org webhelyen. Ugyanúgy, bárki, aki észrevesz egy olyan projektet, amely már nem releváns, vagy nem felel meg a jogosultsági feltételeinknek, szabadon javasolhatja annak eltávolítását. + +## A döntési keretrendszer {#the-decision-framework} + +### A feltüntetés kritériumai: kötelezők {#the-must-haves} + +- **Nyílt forráskód/adat** - A kód és az adatok nyitottsága alapvető DeSci-elv, így a DeSci-projektek nem lehetnek zárt forráskódúak. A kódbázisnak hozzáférhetőnek kell lennie, és ideális esetben nyitottnak a pull requestek számára PR. +- **A DeSci projekteknek láthatóan decentralizáltnak kell lenniük** - Ehhez tartozhat egy DAO általi irányítás, vagy egy decentralizált technológiai rendszer felhasználása, ideértve a nem tároló pénztárcákat is. Valószínűleg az Ethereumon auditálható okosszerződéseket foglal magában. +- **Őszinte és pontos listázási információk** - A projektek által javasolt tételek őszinte és pontos információkkal érkezzenek. Azokat a termékeket eltávolítjuk, melyek hamis információkat adnak meg a listázáshoz, például a nyílt forráskódú megjelölés, amikor a kód nem érhető el. +- **Megmutatható elkötelezettség a tudományhoz való szélesebb hozzáférés mellett** - A DeSci-projekteknek képesnek kell lenniük megfogalmazni, hogyan bővíti ki a részvételt a tudományban a nagyközönség számára, nem csak a token-/NFT-tulajdonosoknak. +- **Világszerte elérhető** - A projektnek ne legyen földrajzi korlátozása vagy olyan „ismerd meg ügyfeled” (KYC) követelménye, amely kizár bizonyos embereket a szolgáltatás eléréséből. +- **Informatív weboldal és dokumentáció** - Fontos, hogy a projekt weboldalát látogatók megértsék, hogy a projekt valójában mit csinál, hogyan járul hozzá a tudomány infrastruktúrájának decentralizációjához, és hogyan lehet részt venni benne. +- **A projektnek az Ethereum ökoszisztémája részének kell lennie** - Az ethereum.org-nál úgy véljük, hogy az Ethereum (és annak Layer 2 megoldásai) megfelelő alapréteget jelentenek a DeSci-mozgalom számára. +- **A projekt elég jól kialakult** - A projektnek valós felhasználói vannak, akik hosszú hónapok óta hozzáférhetnek a projekt szolgáltatásaihoz. + +### Jó, ha van + +- **Több nyelven elérhető** - A projekt le van fordítva több nyelvre, lehetővé téve a világ minden tájáról származó felhasználók számára az elérését. +- **Oktatási források** - A terméknek jól kidolgozott bevezető élménnyel kell rendelkeznie, hogy segítse és oktassa a felhasználókat. Vagy legyenek elérhető cikkek vagy videók arról, hogyan kell azt használni. +- **Harmadik fél által végzett auditok** - A termékét egy megbízható harmadik fél szakemberei vizsgálták sebezhetőségek szempontjából. +- **Kapcsolattartási pont** - Egy kapcsolattartási pont a projekt számára (ez lehet egy DAO vagy közösség képviselője) nagyban segíti a pontos információk beszerzését a változások esetén. Ezzel az ethereum.org frissítése könnyebb, amikor a jövőben információt kell szerezni. + +## Karbantartás {#maintenance} + +Mivel az Ethereum természete gyorsan alakul, a csapatok és a termékek jönnek-mennek, és naponta történnek innovációk, ezért rutinszerűen ellenőrizzük a tartalmakat: + +- Győződjön meg arról, hogy az összes felsorolt projekt továbbra is teljesíti a kritériumainkat +- Ellenőrizze, hogy nincsenek-e olyan termékek, amelyek a jelenlegiekhez képest jobban megfelelnek a kritériumoknak + +Az ethereum.org-ot a nyílt forráskódú közösség tartja fenn, és így a közösségre támaszkodik ahhoz, hogy aktuális információkat mutasson. Ha észrevételeket tesz bármely felsorolt projekt információjával kapcsolatban, ami frissítésre szorul, kérjük, nyisson egy issuel-t vagy pull requestet a GitHub tárolónkban. + +## Felhasználási feltételek {#terms-of-use} + +Tekintse meg [használati feltételeinket](/terms-of-use/). Az ethereum.org-on található információk általános tájékoztatásul szolgálnak. diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-developer-tools/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-developer-tools/index.md new file mode 100644 index 00000000000..7de5321e7b7 --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/adding-developer-tools/index.md @@ -0,0 +1,61 @@ +--- +title: Fejlesztőeszközök hozzáadása +lang: hu +description: A fejlesztőeszközök felsorolásának kritériumai az ethereum.org weboldalon +--- + +# Fejlesztőeszközök hozzáadása {#contributing-to-ethereumorg-} + +Szeretnénk biztosítani, hogy a lehető legjobb fejlesztői erőforrásokat soroljuk fel, hogy az emberek magabiztosan építhessenek és rendelkezzenek a szükséges támogatással. + +Ha van olyan hasznos fejlesztői eszköz, amit elmulasztottunk, nyugodtan javasolja egy megfelelő helyen. + +Jelenleg a fejlesztőeszközöket a [fejlesztői portálunkon](/developers/) keresztül soroljuk fel. + +**Nyugodtan javasoljon új hozzáadásokat a megfelelő oldalakhoz.** + +## Hogyan döntünk {#ways-to-contribute} + +A fejlesztőeszköz-beküldéseket az alábbi kritériumok alapján értékeljük ki: + +**Jelentős mértékben különbözik-e a már felsorolt eszközöktől?** + +- Új kategóriák vagy típusú eszközök +- Új funkciók azonos típusú meglévő eszközökhöz képest +- Egy olyan felhasználási esetet célzott meg, amit a meglévő hasonló eszközök nem fednek le + +**Jól dokumentált-e az eszköz?** + +- Létezik dokumentáció? +- Elegendő-e az eszköz használatához? +- Frissítették-e az utóbbi időben? + +**Széles körben használták-e az eszközt?** + +- Fontolóra vesszünk olyan mutatókat, mint a GitHub csillagok, letöltési statisztikák, és azt, hogy ismert vállalatok vagy projektek használják-e + +**Megfelelő minőségű az eszköz?** + +- Vannak visszatérő hibák? +- Megbízható az eszköz? +- Aktívan karbantartják az eszközt? + +**Az eszköz nyílt forráskódú?** + +Az Ethereum térben sok projekt nyílt forráskódú. Valószínűbb, hogy olyan nyílt forráskódú projekteket sorolunk fel, amelyek lehetővé teszik a közösségi fejlesztők számára, hogy megvizsgálják a kódot, és hozzájáruljanak ahhoz. + +--- + +## Termékrendelés {#product-ordering} + +Hacsak a termékeket kifejezetten másként nem rendelték meg, például ábécé sorrendben, a termékek a lekorábbitól a legújabbig jelennek meg az oldalon. Más szóval, a legújabb termékek a lista aljára kerülnek. + +--- + +## Adjon hozzá fejlesztői eszközt {#how-decisions-about-the-site-are-made} + +Ha egy fejlesztői eszközt szeretne hozzáadni az ethereum.org-hoz, és az megfelel a feltételeknek, hozzon létre egy issue-t a GitHubon. + + + Issue létrehozása + diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-exchanges/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-exchanges/index.md new file mode 100644 index 00000000000..ea9ca0f12c2 --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/adding-exchanges/index.md @@ -0,0 +1,40 @@ +--- +title: Cserék hozzáadása +description: Az az irányelv, amelyet akkor használunk, amikor cseréket adunk hozzá az ethereum.org webhelyhez +lang: hu +--- + +# Ethereum cserék hozzáadása {#adding-ethereum-exchanges} + +Bárki szabadon javasolhat új cseréket az ethereum.org oldalon. + +Jelenleg ezeket soroljuk fel: + +- [ethereum.org/get-eth anyagai](/get-eth/) + +Ezen az oldalon a felhasználó megadhatja, hol él, és megnézheti, milyen cseréket használhat. Ez segít a földrajzi korlátozások korai feltárásában. + +Emiatt a kontextus miatt szükségünk van néhány konkrét információra, amikor cserét javasol. + +**MEGJEGYZÉS:** Ha decentralizált tőzsdét szeretne listázni, tekintse meg a [pénztárcák és dapps listára vonatkozó irányelveinket ](/contributing/adding-products/). + +## Amire szükségünk van {#what-we-need} + +- A cserére vonatkozó földrajzi korlátozások. A tőzsdéhez kapcsolódó földrajzi korlátozásokat részletezni kell a tőzsde webhelyének erre a célra szolgáló oldalán vagy szakaszában. +- Azok a pénznemek, amelyekkel a felhasználók ETH-t vásárolhatnak +- Annak bizonyítéka, hogy a tőzsde törvényes kereskedelmi társaság +- Bármilyen további információ, amivel rendelkezhet – ezek lehetnek a céggel kapcsolatos információk, például a működési évek, a pénzügyi háttér stb. + +Erre az információra azért van szükségünk, hogy pontosan [segíthessünk a felhasználóknak olyan tőzsdét találni, amelyet használhatnak](/get-eth/#country-picker). + +És azért, hogy az ethereum.org még biztosabb legyen abban, hogy a csere legitim és biztonságos szolgáltatás. + +--- + +## Adjon hozzá cserét {#add-exchange} + +Ha cserét szeretne hozzáadni az ethereum.org webhelyhez, hozzon létre egy issue-t a GitHubon. + + + Issue létrehozása + diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-glossary-terms/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-glossary-terms/index.md new file mode 100644 index 00000000000..5d304d76bfc --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/adding-glossary-terms/index.md @@ -0,0 +1,26 @@ +--- +title: Kifejezések hozzáadása a szószedethez +lang: hu +description: Kritériumaink új kifejezések hozzáadásához az ethereum.org szószedethez +--- + +# Kifejezések hozzáadása a szószedethez {#contributing-to-ethereumorg-} + +Ez a tér minden nap változik. Folyamatosan új kifejezések kerülnek be az Ethereum-felhasználók lexikonjába, és szükségünk van a segítségére, hogy pontos, naprakész referenciát biztosíthassunk minden Ethereum-hoz. Nézze meg az aktuális [szószedetet](/glossary/), és tekintse meg az alábbiakat, ha segíteni szeretne! + +## Kritériumok {#criteria} + +A szószedetbe felvett új kifejezéseket a következő kritériumok alapján értékeljük: + +- Naprakész és aktuális a kifejezés/definíció? +- Van már hasonló kifejezés a szótárban? (Ha igen, fontolja meg az új kifejezés előnyeit a meglévő kifejezés frissítésével szemben) +- A kifejezés/definíció nem vonatkozik termékreklámra vagy egyéb promóciós tartalomra? +- A kifejezés/definíció közvetlenül vonatkozik az Ethereumra? +- A meghatározás objektív, pontos, és nem tartalmaz szubjektív ítéletet vagy véleményt? +- A forrás hiteles? Hivatkoznak a forrásaikra? + +--- + +## Adjon hozzá kifejezést {#how-decisions-about-the-site-are-made} + +Ha egy szószedetet szeretne hozzáadni az ethereum.org webhelyhez, és az megfelel a feltételeknek, [probléma létrehozása a GitHubon](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+ %3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml). diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-layer-2s/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-layer-2s/index.md new file mode 100644 index 00000000000..a5d9176362d --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/adding-layer-2s/index.md @@ -0,0 +1,97 @@ +--- +title: Második blokkláncréteg (L2) hozzáadása +description: Szabályzat ahhoz, hogy második blokkláncréteget (L2) adjunk az ethereum.org webhelyhez +lang: hu +--- + +# Második blokkláncréteg (L2) hozzáadása {#adding-layer-2} + +Biztosítani szeretnénk, hogy a lehető legjobb erőforrásokat soroljuk fel, hogy a felhasználók biztonságosan és magabiztosan navigálhassanak az L2-k világában. + +Bárki szabadon javasolhatja egy L2 hozzáadását az ethereum.org webhelyen. Ha van olyan L2, amelyet kihagytunk, **[kérjük, javasolja](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!** + +Jelenleg ezeket az L2-ket soroljuk fel: + +- [Optimista összegzők](/developers/docs/scaling/optimistic-rollups/) +- [Zero-knowledge összegzők](/developers/docs/scaling/zk-rollups/) +- [2. réteg](/layer-2/) + +Az L2 egy viszonylag új és érdekes paradigma az Ethereumban. Az ethereum.org kapcsán próbáltunk kialakítani egy helyes keretrendszert, de a listázási kritériumok fejlődni fognak idővel. + +## A döntési keretrendszer {#decision-framework} + +### A feltüntetés kritériumai: kötelezők {#criteria-for-inclusion-the-must-haves} + +**Az L2BEAT oldalán listázott** + +- Ahhoz, hogy figyelembe tudjuk venni az adott projektet, annak listázva kell lennie az [L2BEAT](https://l2beat.com) oldalán. Az L2BEAT egy robosztus kockázati elemzést végez az L2-es projektekre, amelyre mi is támaszkodunk az adott L2 megítélésekor. **Ha a projekt nem szerepel az L2BEAT oldalán, akkor nem listázhatjuk az ethereum.org-on.** +- [Tudjon meg többet arról, hogy a projekt hogyan kerülhet fel az L2BEAT oldalra](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md). + +**Nyílt forráskódú** + +- A kódnak elérhetőnek kell lennie, s a széles közönségtől fogadhat be PR-okat. + +**L2 kategóriák** + +Jelenleg a következő L2 kategóriákat használjuk: + +- Optimista típusú összevont tranzakciók +- Nulla tudás alapú (ZK) összevont tranzakció + +_Más skálázási megoldásokat nem tekintünk L2-nek, melyek nem használják az Ethereumot adatelérhetőségi és biztonsági szempontból._ + +**Ethereum használata adatelérhetőségre** + +- Az adatelérhetőség fontos megkülönböztető faktor az L2-k és más skálázási megoldások között. A projektnek az Ethereum-főhálózatot **kell** használnia az adatelérhetőségre, hogy listázni lehessen. + +**Hidak** + +- Hogyan tudnak a felhasználók belépni az L2-be? + +**A projekt létrejöttének időpontja** + +- Az L2-nek élőnek kell lennie a főhálózaton legalább 6 hónapja + +- Ennél újabb projekteket, melyek még nincsenek igazán kitesztelve a felhasználók által, nem valószínű, hogy listázunk. + +**Külső biztonsági audit** + +- A termék biztonságát megbízható módon le kell tesztelni, akár audit, akár belső biztonsági csapat vagy más módszer révén. Ez csökkenti a felhasználók kockázatát, és megmutatja, hogy a projekt komolyan veszi a biztonságot. + +**Stabil felhasználói bázis** + +- Figyelembe vesszük a TVL-előzményeket, a tranzakciós statisztikákat, és azt, hogy használják-e ismert cégek vagy projektek + +**Aktív fejlesztői csapat** + +- Nem vesszük be a listába az olyan L2-t, melynek nincs aktív csapata, mely a projekten dolgozik. + +**Blokkfelfedező** + +- A listázott projektekhez működőképes blokkfelfedező szükséges, hogy a felhasználók könnyedén navigálhassanak a láncon. + +### Más kritériumok: jó, ha van kategória {#nice-to-haves} + +**Tőzsdei támogatás a projektre** + +- Tudnak a felhasználók letétet tenni vagy kivenni közvetlenül egy tőzsdéről? + +**Dapp-hivatkozások az L2 ökoszisztémában** + +- Szeretnénk információt adni a felhasználóknak, hogy ezen az L2-n mit tudnak csinálni. (pl. https://portal.arbitrum.io/, https://www.optimism.io/apps) + +**Tokenszerződések listái** + +- Mivel az eszközöknek új címük lesz az L2-n, ezért kérjük, hogy osszák meg a tokenlistát, ha elérhető. + +**Natív tárcatámogatás** + +- Van bármilyen beépített tárcatámogatás? + +## Adjon hozzá L2-t {#add-exchange} + +Ha egy L2-t szeretne hozzáadni az ethereum.org webhelyhez, hozzon létre egy problémát a GitHubon. + + + Issue létrehozása + diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-products/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-products/index.md new file mode 100644 index 00000000000..81ca0e5a093 --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/adding-products/index.md @@ -0,0 +1,100 @@ +--- +title: Termékek hozzáadása +description: Szabályzat az új dappok hozzáadásáról az ethereum.org webhelyhez +lang: hu +--- + +# Ethereum-termékek hozzáadása {#adding-products} + +Bárki szabadon javasolhat új dappokat az ethereum.org oldalra, ahol ez releváns. **Nem, nem fogjuk a dappot a főoldalra helyezni** 😜 + +A dappok jelenleg a következő helyeken vannak listázva: + +- ethereum.org/dapps +- ethereum.org/get-eth anyagai + +**Kérjük, hogy ezekhez a listákhoz javasoljon új tételt.** + +Bár nyitottan fogadunk minden javaslatot, a jelenlegi dappokat az alapján választottuk, hogy milyen élményt adnak a felhasználóknak. Ez a dizájnelveken alapszik: + +- _Inspiráló_: az ethereum.org-on megjelenő minden tétel valami újat adjon a felhasználóknak +- _Egy jó történet_: a feltüntetett tételek adjanak új felismerést vagy aha-élményt a felhasználóknak +- _Hiteles_: minden itt megjelenő törvényes üzlet/projekt, hogy minimalizálja a felhasználók kockázatát + +Összességében az **ethereum.org szeretné, ha a felhasználók problémamentesen tudnák használni ezeket a termékeket**. Ezért a dappokat a következők alapján választjuk ki: + +- egyszerű használat +- interoperábilis más termékekkel +- biztonság +- hosszú élettartam + +Íme a döntési keretrendszerünk részletesebben. Kérjük, ossza meg visszajelzését vagy javaslatait. + +## A döntési keretrendszer {#decision-framework} + +### A feltüntetés kritériumai: kötelezők {#criteria-for-inclusion-the-must-haves} + +- **Biztonsági szempontból tesztelt termék** – a termék biztonságát megbízható módon le kell tesztelni, akár audit, belső biztonsági csapat vagy más módszer révén. Ez csökkenti a felhasználók kockázatát, és megmutatja, hogy a projekt komolyan veszi a biztonságot. +- **A termék legalább 6 hónapja élesben működik** – ez is megmutatja a termék biztonságát. 6 hónap alatt a kritikus hibák és sebezhetőségek általában kiderülnek. +- **Egy aktív csapat dolgozik rajta** – ez biztosítja a minőséget és a felhasználók támogatását is. +- **Őszinte és pontos listázási információk** - a projekt által javasolt termék őszinte és pontos információkkal érkezik. Azokat a termékeket eltávolítjuk, melyek hamis információkat adnak meg a listázáshoz, például a nyílt forráskódú megjelölés, amikor a kód nem érhető el. + +### A rangsor kritériumai: jó, ha van kategória {#criteria-for-ranking-the-nice-to-haves} + +A javasolt dapp talán nem lesz olyan prominens módon megjelenítve az ethereum.org-on, mint mások, mely a következőkből fakad. + +**Dappok** + +- **Elérhető a listázott tárcák többségéből** – a dappoknak működniük kell a tárcák többségéből, melyeket az ethereum.org-on feltüntetünk. +- **A felhasználók kipróbálhatják** – a felhasználóknak tudniuk kell azt használni, és valami kézzelfoghatót elérni vele. +- **Belépési folyamat** – a termék használatához egy jól megtervezett belépési élmény kapcsolódik, mely segíti és tanítja a felhasználókat. Vagy legyenek elérhető cikkek vagy videók arról, hogyan kell azt használni. +- **Saját felügyeletű** – a felhasználók kezelik a saját pénzeszközeiket. Ha a termék eltűnik, a felhasználók akkor is elérik és használhatják az eszközeiket. +- **Világszerte elérhető** - A terméknek ne legyen földrajzi korlátozása vagy olyan ismerd meg ügyfeled (KYC) követelménye, amely kizár bizonyos embereket a szolgáltatás eléréséből. +- **Nyílt forráskódú** –a kódnak elérhetőnek kell lennie, és a széles közönségtől fogadhat be PR-okat. +- **Közösség** – dedikált közösséggel rendelkezik a termék, talán a Discord-on, ahol a felhasználók kapcsolódni tudnak a csapattal segítségért vagy javasolhatnak új funkciókat. + +## Kritériumok a gyakorlatban {#criteria-in-practice} + +Minél több kritériumnak felel meg, annál valószínűbb, hogy meglesz a helye az ethereum.org-on. + +Egy listázott termék, mely csak a kötelező kritériumoknak felel meg, talán lecserélésre kerül, amint jön egy olyan termék, mely több feltételt teljesít. + +Egyéb dolgok, melyek befolyásolják a döntést: + +- Ha újat adunk hozzá ahelyett, hogy lecserélnénk, megtöri az oldal UX-jét? + - az oldal elsősorban tájékoztatásul szolgál, elmagyarázza az Ethereumot és kapcsolódó koncepcióit. Ha túl sok opciót lát a felhasználó, akkor kevésbé olvasható az oldal, így kevésbé hasznos. +- Az oldalon túl sok a választási lehetőség, ami megbénítja a felhasználót? + - mint amikor valaki órákig böngészi a Netflixet, mert nem tudja milyen filmet nézzen. Az új felhasználók túl sok választási lehetőséggel való elárasztása kockázatot jelent. + +Ezt a dizájndöntést az ethereum.org hozza meg. + +De az biztos, hogy **megtalálhatók olyan oldalak hivatkozásai, amelyek több dappot sorolnak fel** + +### Termékrendelés {#product-ordering} + +Hacsak a termékeket kifejezetten másként nem rendelték, például ábécé sorrendben, az oldalon a legutóbb hozzáadottól láthatók a legrégebben bekerülőig. Más szóval, a legújabb termékek a lista aljára kerülnek. + +### Felhasználási feltételek {#terms-of-use} + +Tekintse meg [használati feltételeinket](/terms-of-use/). Az ethereum.org-on található információk általános tájékoztatásul szolgálnak. + +## Karbantartás {#maintenance} + +Mivel az Ethereum természete gyorsan alakul, a csapatok és a termékek jönnek-mennek, és naponta történnek innovációk, ezért rutinszerűen ellenőrizzük a tartalmakat: + +- biztosítjuk, hogy az összes felsorolt projekt továbbra is teljesíti a kritériumainkat +- ellenőrizzük, hogy nincsenek-e olyan termékek, amelyek a jelenlegiekhez képest jobban megfelelnek a kritériumoknak + +Segítségünkre lehet ebben, ha megnézi és értesít minket. [Nyisson egy hibajegyet](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) vagy küldjön e-mailt a [website@ethereum.org](mailto:website@ethereum.org) címre + +_Megvizsgáljuk a szavazási lehetőségeket is, hogy a közösség jelezhesse preferenciáit, és kiemelhesse a legjobb termékeket, amelyeket a honlapon ajánlhatunk._ + +--- + +## Adjon hozzá terméket {#add-your-product} + +Ha egy dappot szeretne hozzáadni az ethereum.org-hoz, és az megfelel a feltételeknek, hozzon létre egy issue-t a GitHubon. + + + Issue létrehozása + diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-staking-products/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-staking-products/index.md new file mode 100644 index 00000000000..f6e8e3aacba --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/adding-staking-products/index.md @@ -0,0 +1,176 @@ +--- +title: Letétbe helyezési termékek vagy szolgáltatások hozzáadása +description: Szabályzat az új letétbe helyezési termékek vagy szolgáltatások hozzáadásáról az ethereum.org webhelyhez +lang: hu +--- + +# Letétbe helyezési termékek vagy szolgáltatások hozzáadása {#adding-staking-products-or-services} + +Biztosítani szeretnénk, hogy a lehető legjobb forrásokat soroljuk fel, és a felhasználók biztonságosan és magabiztosan használhassák azokat. + +Bárki szabadon javasolhatja egy letétbe helyezési termék vagy szolgáltatás hozzáadását az ethereum.org webhelyen. Ha valamit kihagytunk, **[kérjük, javasolja](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!** + +Jelenleg a következő oldalakon listázunk letétbe helyezési termékeket vagy szolgáltatásokat: + +- [Egyéni staking](/staking/solo/) +- [Staking, mint szolgáltatás](/staking/saas/) +- [Letéti alapok](/staking/pools/) + +A letéti igazolásos (proof-of-stake) mechanizmus a Beacon-láncon 2020. december 1-én kezdődött el. Bár a letétbe helyezés még új, próbáltunk kialakítani egy helyes keretrendszert az ethereum.org-on való megjelenítésre, de a listázási kritérimok fejlődni fognak az idővel, és végső soron ez ethereum.org csapat megítélésétől fog függeni. + +## A döntési keretrendszer {#the-decision-framework} + +A termék megjelenítése az ethereum.org oldalon nem egy adott tényezőtől függ. Több kritériumot veszünk figyelembe egyszerre, hogy a döntést meghozzuk. Minél több kritériumnak felel meg valami, annál valószínűbb, hogy helye van a honlapon. + +**Először is, milyen jellegű termék vagy szolgáltatás ez?** + +- Csomópont vagy kliens eszközök +- Kulcskezelés +- Letétbe helyezés mint szolgáltatás (SaaS) +- Letéti alap + +Jelenleg ezek a kategóriák érhetők el. + +### A feltüntetés kritériumai {#criteria-for-inclusion} + +A letétbe helyezési termékek vagy szolgáltatások megjelenítését a következők alapján ítéljük meg: + +**Mikor került a projekt vagy szolgáltatás bevezetésre?** + +- Van rá bizonyíték, hogy a termék vagy szolgáltatás mikor vált nyilvánosan elérhetővé? +- Ez meghatározza a termék harcedzettségét. + +**A projektet aktívan karbantartják?** + +- Van olyan csapat, mely aktívan dolgozik rajta? Ki vesz részt ebben? +- Csak az aktívan karbantartott termékeket tudjuk figyelembe venni. + +**A termék vagy szolgáltatás megbízott/emberi közvetítők nélkül működik?** + +- A felhasználás közben mikor van szükség emberi beavatkozásra, akár a kulcsok felügyeletét vagy a jutalmak elosztását illetően? +- Ez meghatározza a termék vagy szolgáltatás bizalomigénymentességét. + +**A projekt pontos és megbízható információkat ad?** + +- Alapvető fontosságú, hogy a termék honlapja naprakész, pontos és nem félrevezető információkat tartalmazzon, különösen az Ethereum-protokollra vagy kapcsolódó technológiákra vonatkozóan. +- Azokat a termékeket elvetjük vagy eltávolítjuk, melyek félrevezető, elavult információkat és állításokat tartalmaznak az Ethereumról vagy kapcsolódó témákról. + +**Milyen platformokat támogat?** + +- azaz Linux, macOS, Windows, iOS, Android + +#### Szoftverek és okosszerződések {#software-and-smart-contracts} + +Ha valamilyen egyéni szoftver vagy okosszerződés van benne: + +**Minden nyílt forráskódú?** + +- A nyílt forráskódú projekteknek nyilvánosan elérhető könyvtárban kell tárolniuk a forráskódot +- Ez meghatározza a termék nyílt forráskódú mivoltát. + +**A termék túl van-e a _béta_ fejlesztésen?** + +- Hol tart a termék fejlesztési ciklusa? +- A béta fejlesztésnél tartó termékeket nem listázzuk az ethereum.org-on + +**A szoftver átment külső biztonsági auditon?** + +- Ha még nem, akkor vannak erre tervek? +- Ez meghatározza a termék auditáltságát. + +**Van a projektnek hibavadász programja?** + +- Ha még nincs, akkor vannak erre tervek? +- Ez meghatározza a termék hibavadász pontszámát. + +#### Csomópont vagy kliens eszközök {#node-or-client-tooling} + +Azokkal a szoftverekkel kapcsolatban, melyek csomópont- vagy kliensfelállítással, -kezeléssel vagy -migrációval kapcsolatosak: + +**Mely konszenzusréteg-kliensek (vagyis A Lighthouse, Teku, Nimbus, Prysm, Grandine) támogatott?** + +- Milyen klienseket támogat? Választhat a felhasználó? +- Ez meghatározza a termék több klienssel való használhatóságát. + +#### Staking, mint szolgáltatás {#staking-as-a-service} + +A [letétbe helyezés mint szolgáltatás (SaaS)](/staking/saas/) (vagyis delegált csomópontkezelés) kapcsán: + +**Milyen díjak kapcsolódnak a szolgáltatáshoz?** + +- Mi a díjstruktúra, például havi fizetés van? +- Van bármilyen további letétbe helyezési feltétel? + +**A felhasználóknak létre kell hozni egy számlát?** + +- Lehet használni a szolgáltatást engedély vagy ellenőrzés (KYC) nélkül? +- Ez meghatározza a termék engedélymentességét. + +**Kinél vannak az aláíró és visszavonó kulcsok?** + +- Milyen kulcsokat kell a felhasználónak tartania? Milyen kulcsokhoz fér hozzá a szolgáltatás? +- Ez meghatározza a termék bizalomigénymentességét. + +**Mi a csomópontok kliensdiverzitása?** + +- A validátorkulcsok mekkora aránya fut többségi konszenzus réteg (CL) klienssel? +- A legutóbbi állapot szerint a Prysm az a konszenzus réteg kliens, melyet a legtöbb csomópont-operátor használ, ezért veszélyes a hálózatra nézve. Ha bármelyik konszenzusréteg klienst a hálózat több mint 33%-a használja, akkor annak használatáról adatokat kell kérjünk. +- Ez meghatározza a termék kliensdiverzitását. + +#### Letéti alap {#staking-pool} + +A [letétialap-szolgáltatások](/staking/pools/) kapcsán: + +**Mi a minimális letétbe helyezés ETH-ben?** + +- például 0,01 ETH + +**Milyen díjak vagy letétbe helyezési feltételek vannak?** + +- A jutalom mekkora részét tartják meg díj formájában? +- Van bármilyen további letétbe helyezési feltétel? + +**Van likviditási token?** + +- Milyen tokenek szerepelnek? Hogyan működnek? Mik a szerződéscímek? +- Ez meghatározza a terméklikviditási token pontszámát. + +**A felhasználó részt vehet csomópont-operátorként?** + +- Mi szükséges egy validátorkliens futtatásához az összegyűjtött alapok használatával? +- Szükséges ehhez engedély egy egyéntől, cégtől vagy DAO-tól? +- Ez meghatározza a termék engedélymentes csomópont jellegét. + +**Mi a letéti alap csomópont-operátorainak kliensdiverzitása?** + +- A csomópont-operátorok mekkora aránya fut többségi konszenzus réteg (CL) klienssel? +- A legutóbbi állapot szerint a Prysm az a konszenzus réteg kliens, melyet a legtöbb csomópont-operátor használ, ezért veszélyes a hálózatra nézve. Ha bármelyik konszenzusréteg klienst a hálózat több mint 33%-a használja, akkor annak használatáról adatokat kell kérjünk. +- Ez meghatározza a termék kliensdiverzitását. + +### Más kritériumok: jó, ha van kategória {#other-criteria} + +**Milyen felhasználói felületeket támogat?** + +- azaz Böngészőalkalmazás, asztali alkalmazás, mobilalkalmazás, CLI + +**A csomóponti eszközökhöz ad a szoftver lehetőséget arra, hogy kliensek között lehessen váltani?** + +- A felhasználó könnyen és biztonsággal tud klienst váltani az eszközzel? + +**Az SaaS esetében a szolgáltatás mennyi validátort üzemeltet jelenleg?** + +- Ez segít megérteni a szolgáltatás kiterjedtségét. + +## Hogyan jelenítjük meg az eredményeket {#product-ordering} + +A fenti [felvételi kritériumok](#criteria-for-inclusion) alapján minden termékre vagy szolgáltatásra kumulatív pontszámot számítunk. Ezt az objektív kritériumoknak megfelelő termékek kiválogatására és bemutatására használjuk. Minél több kritériumra van bizonyíték, annál magasabbra soroljuk a terméket, a döntetlenek a használat alapján kerülnek sorrendbe. + +A kód logikája és a kritériumok súlyozása jelenleg ebben [a JavaScript komponensben](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350) található a könyvtárunkban. + +## Adja hozzá a termékét vagy szolgáltatását {#add-product} + +Ha egy letétbe helyezési terméket vagy szolgáltatást szeretne hozzáadni az ethereum.org webhelyhez, hozzon létre egy problémát a GitHubon. + + + Issue létrehozása + diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-wallets/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-wallets/index.md new file mode 100644 index 00000000000..a855259dc16 --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/adding-wallets/index.md @@ -0,0 +1,80 @@ +--- +title: Tárcák hozzáadása +description: Szabályzat a tárcák hozzáadásáról az ethereum.org webhelyhez +lang: hu +--- + +# Tárcák hozzáadása {#adding-wallets} + +Biztosítani szeretnénk, hogy sokféle tárcát megmutatunk, lefedve azok funkciógazdagságát, hogy a felhasználók magabiztosan navigálhassanak az Ethereumban. + +Bárki szabadon javasolhatja egy tárca hozzáadását az ethereum.org webhelyen. Ha van olyan tárca, amelyet kihagytunk, kérjük, javasolja! + +A tárcák jelenleg a következő helyen vannak listázva: + +- [ethereum.org/wallets/find-wallet/](/wallets/find-wallet/) + +A tárcák gyorsan változnak az Ethereumban. Az ethereum.org kapcsán próbáltunk kialakítani egy helyes keretrendszert, de a listázási kritériumok fejlődni fognak idővel. + +## A döntési keretrendszer {#the-decision-framework} + +### A feltüntetés kritériumai: kötelezők {#the-must-haves} + +- **Bizonsági szempontból tesztelt termék** – a tárca biztonságát megbízható módon le kell tesztelni, akár audit, belső biztonsági csapat vagy más módszer révén. Ez csökkenti a felhasználók kockázatát, és megmutatja, hogy a projekt komolyan veszi a biztonságot. +- **A tárca legalább 6 hónapja élesben működik VAGY olyan csoport adta ki, melynek megbízható reputációja van** – ez is megmutatja a termék biztonságát. Hat hónap alatt a kritikus hibák és sebezhetőségek általában kiderülnek. Azért is kérünk hat hónapot, mert így ki lehet szűrni azokat az elágazásokat, melyeket gyorsan magukra hagynak. +- **Egy aktív csapat dolgozik rajta** – ez biztosítja a minőséget és a felhasználók támogatását is. +- **Őszinte és pontos listázási információk** - a projekt által javasolt termék őszinte és pontos információkkal érkezik. Azokat a termékeket eltávolítjuk, melyek hamis információkat adnak meg a listázáshoz, például a nyílt forráskódú megjelölés, amikor a kód nem érhető el. +- **Kapcsolattartási pont** - Egy kapcsolattartási pont a tárca kapcsán nagyban segíti a pontos információk beszerzését változások esetén. Ezzel az ethereum.org frissítése könnyebb, amikor a jövőben információt kell szerezni. +- **EIP-1559 (2-es típusú) tranzakciók** - a tárcának támogatnia kell az EIP-1559 (2-es típusú) tranzakciókat az Ethereum főhálózatán. +- **Jó felhasználói élmény** - Bár a felhasználói élmény szubjektív, de ha a központi csapat tagjai tesztelik a terméket, és nehezen használhatónak találják, akkor elutasíthatjuk azt, és inkább javaslatokat teszünk a javításra. Ezzel szeretnénk védeni a felhasználókat, akik sokszor kezdők ezen a területen. + +### Termékeltávolítások {#product-removals} + +- **Frissített információk** - A tárcaszolgáltatók felelősek azért, hogy 6 havonta újra benyújtsák a tárcára vonatkozó információkat, hogy biztosítsák azok érvényességét és relevanciáját (akkor is, ha nem történt változás). Ha ezt nem teszi meg a termék csapata, akkor az ethereum.org eltávolíthatja azt a honlapról. + +### Más kritériumok: jó, ha van kategória {#the-nice-to-haves} + +- **Világszerte elérhető** - a tárcának ne legyen földrajzi korlátozása vagy olyan ismerd meg ügyfeled (KYC) követelménye, amely kizár bizonyos embereket a szolgáltatásból. +- **Több nyelven elérhető** - a tárca le van fordítva több nyelvre, így a világ minden tájáról származó felhasználók számára elérhető. +- **Nyílt forráskódú** –a teljes kódbázisnak (nem csak moduloknak) elérhetőnek kell lennie, és a széles közönségtől fogadhat be PR-okat. +- **Saját felügyeletű** – a felhasználók kezelik a saját pénzeszközeiket. Ha a termék eltűnik, a felhasználók akkor is elérik és használhatják az eszközeiket. +- **Hardveres tárca támogatása** - a felhasználók hozzákapcsolhatják a hardveres tárcájukat, hogy tranzakciókat írjanak alá. +- **WalletConnect** - a felhasználók kapcsolódhatnak olyan dappokhoz, melyek WalletConnect-et használnak. +- **Ethereum RPC végpontok importálása** - a felhasználók importálhatják a csomópontok RPC-adatait, így csatlakozhatnak egy kiválasztott csomóponthoz vagy más EVM-kompatibilis hálózatokhoz. +- **NFT-k** - a felhasználók láthatják és használhatják az NFT-iket a tárcában. +- **Kapcsolódás az Ethereum alkalmazásaihoz** - a felhasználók képesek kapcsolódni az Ethereum alkalmazásaihoz és használni azokat. +- **Letétbe helyezés** - a felhasználók képeseket letétbe helyezni pénzeszközeiket közvetlenül a tárcából. +- **Átváltások** - a felhasználók képesek tokeneket átváltani a tárcán keresztül. +- **Több blokklánchálózat** - a tárca támogatja több blokklánchálózat elérését. +- **L2 hálózatok** - a tárca támogatja, hogy a felhasználók L2 hálózatokat érjenek el. +- **Gázdíjak személyre szabása** - a tárca lehetővé teszi a felhasználóknak, hogy személyre szabják a tranzakciós díjaikat (alapdíj, prioritási díj, maximális díj). +- **ENS támogatása** - a tárca lehetővé teszi, hogy a felhasználó ENS nevekre küldjön tranzakciókat. +- **ERC-20 támogatása** - a tárca lehetővé teszi, hogy ERC-20 tokenszerződéseket importáljon a felhasználó, vagy automatikusan lekérdezi és megmutatja az ERC-20-tokeneket. +- **Kriptovásárlás** - a tárca támogatja, hogy a felhasználó közvetlenül vásárolhasson kriptót vagy kapcsolódjon azzal. +- **Fiatért eladás** - a tárca támogatja, hogy a felhasználók közvetlenül kártyára vagy bankszámlára adjanak el és vegyenek ki fiatot. +- **Több aláírás** - támogatja több aláíró meglétét a tranzakciók kezelésénél. +- **Hagyományos visszaállítás** - támogatja az őrzők meglétét, így a felhasználó akkor is vissza tudja állítani a tárcát, ha nincs meg a kulcsmondata. +- **Dedikált támogatócsapat** - a tárcának dedikált támogatócsapata van, amely segít a felhasználók problémáit megoldani. +- **Oktatási források/dokumentáció** - a terméknek jól kidolgozott bevezető élménnyel kell rendelkeznie, hogy segítse és oktassa a felhasználókat. Vagy legyenek elérhető cikkek vagy videók arról, hogyan kell azt használni. + +## Tárca hozzáadása {#adding-a-wallet} + +Ha egy tárcát szeretne hozzáadni az ethereum.org webhelyhez, hozzon létre egy problémát a GitHubon. + + + Issue létrehozása + + +## Karbantartás {#maintenance} + +Mivel az Ethereum természete gyorsan alakul, a csapatok és a termékek jönnek-mennek, és naponta történnek innovációk, ezért rutinszerűen ellenőrizzük a tartalmakat: + +- biztosítjuk, hogy az összes felsorolt tárca és dapp továbbra is teljesíti a kritériumainkat +- ellenőrizzük, hogy nincsenek-e olyan termékek, amelyek a jelenlegiekhez képest jobban megfelelnek a kritériumoknak + +az ethereum.org-ot a nyílt forráskódú közösség tartja fenn, és így a közösségre támaszkodik ahhoz, hogy aktuális információkat mutasson. Ha a listázott tárcáknál frissítésre van szükség, akkor [nyisson egy hibajegyet](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml) vagy [PR-t](https://github.com/ethereum/ethereum-org-website/pulls)! + + +## Felhasználási feltételek {#terms-of-use} + +Tekintse meg [használati feltételeinket](/terms-of-use/). Az ethereum.org-on található információk általános tájékoztatásul szolgálnak. diff --git a/public/content/translations/hu/28) Contributing 2/contributing/content-resources/index.md b/public/content/translations/hu/28) Contributing 2/contributing/content-resources/index.md new file mode 100644 index 00000000000..eef66c3d199 --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/content-resources/index.md @@ -0,0 +1,32 @@ +--- +title: Tartalmi források hozzáadása +lang: hu +description: A tartalmi források listázásának kritériumai az ethereum.org-on +--- + +# Tartalmi források hozzáadása {#adding-content-resources} + +Nem remélhetjük, hogy mindent le tudunk fedni az Ethereum kapcsán, ezért megpróbálunk bemutatni néhányat a közösség által létrehozott remek cikkekből, útmutatókból, hírlevelekből, álláshirdetésekből és különböző tartalmi forrásokból. Ezek részletes információkat adnak olyan témákról, melyek érdeklik a felhasználókat. + +Ha van olyan tartalmi forrás, melyet megjeleníthetnénk, javasolja a megfelelő helyen. + +## Hogyan döntünk {#how-we-decide} + +A tanulási forrásokat a következőképpen ítéljük meg: + +- A tartalom friss? +- A tartalom fizetős? +- Az információ pontos? Tényszerű vagy véleményalapú? +- A szerző hiteles? Hivatkoznak a forrásaikra? +- Ez a tartalom olyan értéket ad, melyet a meglévő források/hivatkozások nem fednek le? +- Ez a tartalom valamelyik [közösségi típust](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c) szolgálja? + +--- + +## Adjon hozzá tartalmi forrást {#add-your-content-resource} + +Ha egy tartalmi forrást szeretne hozzáadni az ethereum.org-hoz, és az megfelel a feltételeknek, hozzon létre egy issue-t a GitHubon. + + + Issue létrehozása + diff --git a/public/content/translations/hu/28) Contributing 2/contributing/design/adding-design-resources/index.md b/public/content/translations/hu/28) Contributing 2/contributing/design/adding-design-resources/index.md new file mode 100644 index 00000000000..0f7035b5490 --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/design/adding-design-resources/index.md @@ -0,0 +1,69 @@ +--- +title: Dizájnforrások hozzáadása +description: Útmutató és feltételek a minőségi dizájnanyagok megjelenítéséhez az ethereum.org-on +lang: hu +--- + +# Dizájnforrások hozzáadása {#adding-design-resources} + +Bárki javasolhat új dizájnanyagokat a [Dizájn és UX a web3-ban oldalra](/developers/docs/design-and-ux/). + +Ennek az oldalnak a lényege, hogy olyan értéket adjon, mely inspirálja a web3-dizájnereket. Nem arra szolgál, hogy reklámozzon bizonyos szolgáltatásokat, termékeket vagy platformokat. + +Annak érdekében, hogy biztosítsuk az információk magas színvonalát és az értékes meglátások népszerűsítését, a következő listázási szabályt használjuk: + +## Kutatási tanulmányok és irányítópultok {#Research-studies} + +1. Megbízható módszertan + +a. A módszertan egyértelműen határozza meg, hogyan gyűjtötték az adatokat. + +b. Adják, meg a kutatásban résztvevők számát. + +c. Adják meg a kutatási módszereket. + +2. A web3-dizájnerek számára mennyire releváns és általános használati esetek + +a. A kutatás témája legyen releváns a web3-dizájnereknek és célozzon meg általános használati eseteket. + +3. Fókuszáljon az információk nyújtására + +a. A szöveg adjon betekintéseket, ne promótáljon projekteket vagy cégeket. + +## Cikkek {#Articles} + +1. A web3-dizájnerek/-kutatók számára mennyire releváns és általános web3-használati esetek + +a. A cikk témája legyen releváns a web3-dizájnerek és -kutatók számára, és célozzon meg általános web3-használati eseteket. + +2. Alapvető írásminőség + +a. A cikk legyen nyelvtanilag rendben és helyesírási hibáktól mentes. + +b. A lényeg a kulcsfontosságú meglátások és tanulságok átadása legyen. + +c. Az írás legyen tömör és lényegre törő. + +3. A szöveg célja + +a. A szöveg adjon betekintéseket, ne promótáljon projekteket vagy cégeket. + +## Közösségek/DAO-k {#Communities-and-DAOs} + +1. A honlap egyértelműen adja meg, hogyan lehet csatlakozni a DAO-hoz/közösséghez + +2. A tagság előnyei legyenek egyértelműek + +a. A tagság előnyeit emeljék ki határozottan. + +**Például**: visszajelzést kaphat a munkájáról, hozzáférhet munkalehetőségekhez vagy jutalmakhoz, megoszthatja tervezési és kutatási meglátásait. + +3. A Discordon legyen aktív és élénk beszélgetés + +a. A Discord-közösség mutasson élő és elkötelezett kommunikációt. + +b. A moderátorok aktívan vegyenek részt a közösség fenntartásában és a beszélgetések irányításában. + +c. A közösség mutassa meg, hogy az elmúlt két hétben értékes és eredményes beszélgetéseket folytatott. + +Ezen kritériumok alapján szeretnénk egy virágzó és tudásmegosztó környezetet adni a közösségünknek. A listázási szabály mentén a felhasználók megbízható, releváns és betekintést engedő forrásokhoz férhetnek hozzá. Köszönjük a megértését és együttműködését abban, hogy a minőségi tartalom legyen a platformon. diff --git a/public/content/translations/hu/28) Contributing 2/contributing/quizzes/index.md b/public/content/translations/hu/28) Contributing 2/contributing/quizzes/index.md new file mode 100644 index 00000000000..52fdbd02b18 --- /dev/null +++ b/public/content/translations/hu/28) Contributing 2/contributing/quizzes/index.md @@ -0,0 +1,62 @@ +--- +title: Kvízkérdés hozzáadása +description: Szabályzat az új kvízkérdések hozzáadásáról az ethereum.org webhelyhez +lang: hu +--- + +# Kvízek {#quizzes} + +A kvíz remek lehetőség a felhasználónak, hogy tesztelje, mennyire érti az adott oldal tartalmát. A kvíz az adott oldal tartalmára támaszkodik, és csak olyanra hivatkozik, ami ott szerepel. + +A kérdések struktúrája a következő. Kérdésfeltevés, 1 helyes válasz és magyarázata, hogy miért helyes, 3 helytelen válasz és magyarázata, hogy miért helytelen. + +A jelenlegi kvízekből néhány példát itt láthat: + +- [Második blokkláncréteg (L2)](/layer-2) +- [NFT](/nft/) +- [Mi az Ethereum?](/what-is-ethereum/) +- [Mi az az ETH?](/eth/) + +## Kvíz hozzáadása + +Ha van olyan oldal, mely még nem tartalmaz kvízt, akkor [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml). + +Adja meg a következő információkat: + +- Az oldal, ahova a kvíz kerülne +- 5 kérdés a következő részletekkel: + - Az oldal szekciója, melyhez a kérdés kapcsolódik + - A kérdésfeltevés + - 1 helyes válasz és a magyarázata, hogy miért helyes + - 3 helytelen válasz és a magyarázata, hogy miért helytelen + +## Kvízkérdés hozzáadása + +Ha szeretne egy kérdést hozzáadni egy kvízhez, akkor [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml), és adja meg a következőket: + +- Az oldal, ahova a kvízkérdés kerülne +- A kérdéshez adja meg a következő információkat: + - Az oldal szekciója, melyhez a kérdés kapcsolódik + - A kérdésfeltevés + - 1 helyes válasz és a magyarázata, hogy miért helyes + - 3 helytelen válasz és a magyarázata, hogy miért helytelen + +## Kvízkérdés frissítése + +Ha szeretne egy kérdést frissíteni egy kvíznél, akkor [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml), és adja meg a következőket: + +- Az oldal, ahol a kvízkérdést frissítené +- A kérdéshez adja meg a következő információkat: + - Az oldal szekciója, melyhez a kérdés kapcsolódik + - A kérdésfeltevés, ahol a frissítést szeretné + - A frissített kérdésfeltevés + - 1 helyes válasz és a magyarázata, hogy miért helyes + - 3 helytelen válasz és a magyarázata, hogy miért helytelen + +## Kvízkérdés eltávolítása + +Ha a kvízkérdéshez tartozó tartalom már nem szerepel az oldalon és ezért el kell távolítani, [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) a törlésre, és adja meg a következőket: + +- Az oldal, ahol a kvízkérdést törölné +- A kérdés, melyet törölni szeretne +- Annak magyarázata, hogy miért nincs szükség a kérdésre diff --git a/public/content/translations/hu/about/index.md b/public/content/translations/hu/about/index.md index f0d39e2577c..e4e973e3646 100644 --- a/public/content/translations/hu/about/index.md +++ b/public/content/translations/hu/about/index.md @@ -8,6 +8,8 @@ lang: hu Az ethereum.org egy nyilvános, nyílt forráskódú információs forrás az Ethereum közösségnek, amelyhez bárki hozzájárulhat. Egy kicsi központi csapat elhivatottan dolgozik az oldal fenntartásán és fejlesztésén, és ebben több ezer közösségi tag segíti őket a világ minden tájáról. +**Az ethereum.org-tól senki sem lép Önnel kapcsolatba. Ne válaszoljon ilyesmire!** + ## Megjegyzés a nevekkel kapcsolatban {#a-note-on-names} Általános dolog, hogy az emberek összekeverik az Ethereum világába tartozó neveket, így nem tudnak az Ethereum működéséről valós képet kapni. Az alábbiakban gyorsan összefoglalnánk, hogy mi micsoda: diff --git a/public/content/translations/hu/bridges/index.md b/public/content/translations/hu/bridges/index.md index 8c10b4d79dc..4882abb8401 100644 --- a/public/content/translations/hu/bridges/index.md +++ b/public/content/translations/hu/bridges/index.md @@ -95,6 +95,15 @@ Számos hidat biztosító megoldás e két modell közötti módszert alakít ki +## Híd használata {#use-bridge} + +A hidak segítségével a felhasználók különböző blokkláncok között tudnak eszközöket mozgatni. Íme néhány forrás, amelyek hasznosak lehetnek a hidak megtalálásához és használatához: + +- **[L2BEAT hidakról szóló összefoglaló](https://l2beat.com/bridges/summary) & [L2BEAT hidak kockázati elemzése](https://l2beat.com/bridges/risk)**: Egy átfogó tanulmány a különféle hidakról, beleértve azok piaci részesedését, típusát és azokat a blokkláncokat, melyekkel összeköttetést biztosítanak. Az L2BEAT kockázati elemzést is készített a hidakról, hogy a felhasználók megfelelően tudjanak választani azok közül. +- **[DefiLlama hidakról szóló összefoglaló](https://defillama.com/bridges/Ethereum)**: Az Ethereum hálózatok közötti hidak forgalmi adatainak összefoglalója. + + + ## A hidak használatának kockázata {#bridge-risk} A hidak fejlesztése még a korai stádiumban van. Nagy valószínűséggel az optimális kialakítás még nem született meg. A hidakkal való interakció a következő kockázatokkal jár: diff --git a/public/content/translations/hu/community/online/index.md b/public/content/translations/hu/community/online/index.md index e61b0d97418..f93382c295f 100644 --- a/public/content/translations/hu/community/online/index.md +++ b/public/content/translations/hu/community/online/index.md @@ -8,6 +8,31 @@ lang: hu Ethereum rajongók százezrei gyűlnek össze ezeken az online fórumokon, hogy megosszák a híreket, megbeszéljék az új fejlesztéseket, megvitassák a technikai problémákat és elképzeljék a jövőt. +## Listázási szabály {#listing-policy} + +A felsorolt közösségek integritásának és értékének megőrzése érdekében az ethereum.org szigorú irányelveket követ a jogosultság meghatározásakor: + +### Jogosultsági kritériumok {#eligibility-criteria} + +- **Relevancia**: A közösségnek közvetlenül az Ethereumhoz és annak ökoszisztémájához kell kapcsolódnia. +- **Aktivitási szint**: A közösségnek aktívnak kell lennie, rendszeres interakciókkal, hozzászólásokkal vagy párbeszédekkel. A szunnyadó vagy inaktív közösségek eltávolíthatók. +- **Inkluzivitás**: A közösségnek olyan barátságos környezetet kell kialakítania, amely tiszteletben tartja a sokszínűséget, és ösztönzi a különböző hátterű emberek részvételét. +- **Nem kereskedelmi fókusz**: A listázás közösségi célú terek, nem kereskedelmi vagy promóciós platformok számára elérhető. + +### Tartalmi irányelvek {#content-guidelines} + +- **Megfelelő tartalom**: A közösségeknek saját moderálási irányelvekkel kell rendelkezniük, elkerülve a levélszemetet, a gyűlöletbeszédet, a zaklatást vagy bármilyen olyan tartalmat, amely illegális tevékenységet népszerűsít. +- **Nyelv**: Bár az angol az elsődleges nyelv, más nyelvű közösségeket is bátorítunk, hogy jelentkezzenek, amíg fenntartják a befogadó és tiszteletteljes légkört. +- **Átláthatóság**: A közösség céljáról, szabályairól és moderátorairól világos információknak kell a tagok számára elérhetőnek lenniük. + +### További javaslatok {#other-recommendations} + +- **Elérhetőség**: A közösségi fórumoknak mindenki számára elérhetőnek kell lenniük bejelentkezés vagy regisztráció nélkül. +- **Meghívók a Discord-szerverre**: Ajánlott, hogy csak megbízható Discord-szerver meghívók kerüljenek fel az ethereum.org-ra. Ideális esetben ezek a meghívók a weboldal közösségi oldalára (pl. [ethglobal.com/discord](https://ethglobal.com/discord)) vagy egy hivatalos URL-re (pl. [discord.gg/ethstaker](https://discord.gg/ethstaker) vagy [discord.com/invite/ethstaker](https://discord.com/invite/ethstaker)) mutatnak. + +Ha úgy gondolja, hogy egy közösséget hozzá kellene adni vagy el kellene távolítani ezen irányelvek alapján, kérjük, [nyisson egy problémát a GitHub könyvtárban](https://github.com/ethereum/ethereum-org-website/issues). + + ## Fórumok {#forums} r/ethereum – minden az Ethereumról diff --git a/public/content/translations/hu/community/support/index.md b/public/content/translations/hu/community/support/index.md index 4f2828b7ac0..707142b32f3 100644 --- a/public/content/translations/hu/community/support/index.md +++ b/public/content/translations/hu/community/support/index.md @@ -10,7 +10,7 @@ lang: hu Egy hivatalos Ethereum ügyfélszolgálatot keres? Tudnia kell, hogy az Ethereum decentralizált. Nincs központi szervezet, entitás vagy ember, aki birtokolná az Ethereumot, ezért nincs hivatalos ügyfélszolgálat vagy támogatói csapat sem. -Ezt azért is fontos megérteni, mert bárki jelentkezik Önnél, mint hivatalos ügyfélszolgálatos, az csak csaló lehet! A csalók ellen a legjobb védekezés az ismeretek szerzése és a biztonság komolyan vétele. +Ezt azért is fontos megérteni, mert **bárki jelentkezik Önnél, mint hivatalos ügyfélszolgálatos, az csak csaló lehet!** A csalókkal szemben a legjobb védekezés, ha Ön mindig jól informált és komolyan veszi a saját biztonságát. Ethereum-biztonság és átverés elleni védelem @@ -100,5 +100,6 @@ Az Ethereum klienseket építő csapatok is dedikált, nyilvános fórumokkal re - [Lighthouse](https://discord.gg/cyAszAh) - [Teku](https://discord.gg/7hPv2T6) - [Lodestar](https://discord.gg/aMxzVcr) +- [Grandine](https://discord.gg/H9XCdUSyZd) Tudja meg, hogy [futtathat csomópontot](/developers/docs/nodes-and-clients/run-a-node/). diff --git a/public/content/translations/hu/contributing/adding-exchanges/index.md b/public/content/translations/hu/contributing/adding-exchanges/index.md index b2499ec6b95..ea9ca0f12c2 100644 --- a/public/content/translations/hu/contributing/adding-exchanges/index.md +++ b/public/content/translations/hu/contributing/adding-exchanges/index.md @@ -16,7 +16,7 @@ Ezen az oldalon a felhasználó megadhatja, hol él, és megnézheti, milyen cse Emiatt a kontextus miatt szükségünk van néhány konkrét információra, amikor cserét javasol. -**MEGJEGYZÉS:** Ha decentralizált tőzsdét szeretne listázni, tekintse meg a [pénztárcák és dapps listára vonatkozó irányelveinket](/contributing/adding-products/). +**MEGJEGYZÉS:** Ha decentralizált tőzsdét szeretne listázni, tekintse meg a [pénztárcák és dapps listára vonatkozó irányelveinket ](/contributing/adding-products/). ## Amire szükségünk van {#what-we-need} diff --git a/public/content/translations/hu/contributing/adding-glossary-terms/index.md b/public/content/translations/hu/contributing/adding-glossary-terms/index.md index a07a43d9f82..5d304d76bfc 100644 --- a/public/content/translations/hu/contributing/adding-glossary-terms/index.md +++ b/public/content/translations/hu/contributing/adding-glossary-terms/index.md @@ -23,4 +23,4 @@ A szószedetbe felvett új kifejezéseket a következő kritériumok alapján é ## Adjon hozzá kifejezést {#how-decisions-about-the-site-are-made} -Ha egy szószedetet szeretne hozzáadni az ethereum.org webhelyhez, és az megfelel a feltételeknek, [probléma létrehozása a GitHubon](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml). +Ha egy szószedetet szeretne hozzáadni az ethereum.org webhelyhez, és az megfelel a feltételeknek, [probléma létrehozása a GitHubon](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+ %3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml). diff --git a/public/content/translations/hu/contributing/adding-staking-products/index.md b/public/content/translations/hu/contributing/adding-staking-products/index.md index a415a7fd1bf..f6e8e3aacba 100644 --- a/public/content/translations/hu/contributing/adding-staking-products/index.md +++ b/public/content/translations/hu/contributing/adding-staking-products/index.md @@ -87,7 +87,7 @@ Ha valamilyen egyéni szoftver vagy okosszerződés van benne: Azokkal a szoftverekkel kapcsolatban, melyek csomópont- vagy kliensfelállítással, -kezeléssel vagy -migrációval kapcsolatosak: -**Mely konszenzusréteg-kliensek (vagyis Lighthouse, Teku, Nimbus, Prysm) támogatottak?** +**Mely konszenzusréteg-kliensek (vagyis A Lighthouse, Teku, Nimbus, Prysm, Grandine) támogatott?** - Milyen klienseket támogat? Választhat a felhasználó? - Ez meghatározza a termék több klienssel való használhatóságát. diff --git a/public/content/translations/hu/contributing/design/index.md b/public/content/translations/hu/contributing/design/index.md index f230b23f6e0..0c136e5aa77 100644 --- a/public/content/translations/hu/contributing/design/index.md +++ b/public/content/translations/hu/contributing/design/index.md @@ -6,7 +6,7 @@ lang: hu # Közreműködés a dizájnban az ethereum.org-on {#design-contributions} -A dizájntervezés minden projekt kritikus eleme, és ha hajlandó az idejét és készségeit az Ethereum.org jobbá tételére szenteli, hozzájárulhat látogatóink felhasználói élményének javításához. A nyílt forráskódú projektben való közreműködés lehetőséget ad arra, hogy releváns tapasztalatot szerezzen és készségeit együttműködő környezetben fejlessze. Együtt dolgozhat más tervezőkkel, fejlesztőkkel és közösségi tagokkal, akik mind saját perspektívával és rálátással rendelkeznek. +Minden projekt kritikus eleme a dizájn, amennyiben az idejét és a dizájnképességeit az ethereum.org oldalon kamatoztatja, akkor segíti a látogatók felhasználói élményét. A nyílt forráskódú projektben való közreműködés lehetőséget ad arra, hogy releváns tapasztalatot szerezzen és készségeit együttműködő környezetben fejlessze. Együtt dolgozhat más tervezőkkel, fejlesztőkkel és közösségi tagokkal, akik mind saját perspektívával és rálátással rendelkeznek. Ez egy remek módja annak is, hogy egy sokszínű és hatásos portfóliót hozzon létre, mely bemutatja a dizájnképességeit. @@ -30,7 +30,7 @@ Adjon visszajelzést a honlapról: ###  Találjon dizájnnal kapcsolatos problémákat a honlapon és jelezze azokat {#report-design-issues} -Az Ethereum.org egy rendkívül gyorsan növekvő webhely számos funkcióval és megannyi tartalommal. A felhasználói felület bizonyos része már kivezethető lenne vagy fejleszteni kellene. Ha ilyet talál, akkor jelezze, hogy felkerüljön a radarunkra. +Az ethereum.org egy gyorsan fejlődő honlap, amely számtalan jellemzővel és tartalommal bír. A felhasználói felület bizonyos része már kivezethető lenne vagy fejleszteni kellene. Ha ilyet talál, akkor jelezze, hogy felkerüljön a radarunkra. 1. Tekintse meg a honlapot és figyeljen oda a dizájnra. 2. Készítsen képernyőképeket és jegyzeteket, ha vizuális vagy UX problémát lát. @@ -51,10 +51,10 @@ A dizájnrendszerünk révén ethereum.org tervezése szórakoztató és könny 1. Válasszon egy meglévő issue-t a GitHub-on a [dizájnrendszer tábláról](https://github.com/ethereum/ethereum-org-website/labels/design%20system) vagy hozzon létre újat. 2. Kérje meg, hogy az adott tételt Önnek adják. -3. Kezdje el a kívánt alkotóelem tervezését a figmában. +3. Készítsen dizájnt Figmában a kért komponensről. 4. Ossza meg azt a dizájncsapattal a GitHub-on, amikor átnézésre vagy útmutatásra van szüksége. 5. A dizájncsapat átnézi azt. -6. A dizájncsapat beépíti a változtatásokat a főfájlba, majd közzéteszi a fájlt a közösség számára. +6. A csapat átvezeti rajta a változásokat és megosztja azt a közösséggel. ###  Írjon dizájnnal kapcsolatos tartalmat a honlapra {#write-design-articles} @@ -64,7 +64,7 @@ Az Ethereum fejlesztői közössége kellően erős, de a dizájnközösségnek 2. A GitHub könyvtárban [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new), és javasoljon egy témát benne (még ne írja meg a tartalmat). 3. Várja meg, amíg a dizájncsapat jóváhagyja. 4. Amint jóváhagyták, írja meg a tartalmat. -5. Küldje be a kapcsolódó GitHub issue-ban. +5. Adja be a kapcsolódó GitHub issue-ban. ###  Készítsen új illusztrációkat {#prepare-illustrations} diff --git a/public/content/translations/hu/contributing/index.md b/public/content/translations/hu/contributing/index.md index 32d46ea9023..e8d145dbd9b 100644 --- a/public/content/translations/hu/contributing/index.md +++ b/public/content/translations/hu/contributing/index.md @@ -68,7 +68,7 @@ Mielőtt nekilát, ismerkedjen meg: - a [stílusútmutatóval](/contributing/style-guide/) - a [viselkedési szabályzattal](/community/code-of-conduct) - + ## Hogyan történik a döntéshozás a honlapról {#how-decisions-about-the-site-are-made} diff --git a/public/content/translations/hu/contributing/translation-program/how-to-translate/index.md b/public/content/translations/hu/contributing/translation-program/how-to-translate/index.md index 92257e40af2..483e6474dfe 100644 --- a/public/content/translations/hu/contributing/translation-program/how-to-translate/index.md +++ b/public/content/translations/hu/contributing/translation-program/how-to-translate/index.md @@ -18,7 +18,7 @@ A vizuális tanulók tekintsék meg, ahogy Luka bemutatja a Crowdin használatá Jelentkezzen be Crowdin-profiljába vagy készítsen egyet, ha még nem rendelkezik vele. A létrehozáshoz csak egy e-mail-címre és jelszóra lesz szüksége. - + Csatlakozzon a projekthez diff --git a/public/content/translations/hu/dao/index.md b/public/content/translations/hu/dao/index.md index 5c00953c1c9..24808b91146 100644 --- a/public/content/translations/hu/dao/index.md +++ b/public/content/translations/hu/dao/index.md @@ -18,7 +18,7 @@ A DAO egy közös tulajdonú szervezet, amely egy közös küldetésért dolgozi A DAO-k lehetőséget biztosítanak számunkra, hogy hozzánk hasonló elhivatottságú emberekkel dolgozzunk a világ minden tájáról anélkül, hogy egy központi vezetőre bíznánk a pénzügyi és operatív működtetést. Nincs olyan vezérigazgató, aki a kedve szerint költhetné el az alapokat, vagy olyan pénzügyi vezető, aki manipulálhatná a könyvelést. Helyette a kódba épített, blokkláncon alapuló szabályok határozzák meg, hogyan működik a szervezet és kerülnek elköltésre az alapok. -Beépített pénztárakkal rendelkeznek, amelyekhez a csoport jóváhagyása nélkül senkinek sincs jogosultsága hozzáférni. A döntéseket a javaslatok és a szavazás szabályozzák, így biztosítva, hogy a szervezetben mindenki megszólaljon, és minden átláthatóan, [on-láncon](/glossary/#on-chain) történjen. +Beépített pénztárakkal rendelkeznek, amelyekhez a csoport jóváhagyása nélkül senkinek sincs jogosultsága hozzáférni. A döntéseket a javaslatok és a szavazás szabályozzák, így biztosítva, hogy a szervezetben mindenki megszólaljon, és minden átláthatóan, [láncon belül](/glossary/#on-chain) történjen. ## Miért van szükségünk DAO-kra? {#why-dao} @@ -44,6 +44,8 @@ Annak érdekében, hogy még érthetőbbé tegyük a DAO-k működését, az al - **Közös tulajdonjog** – vásárolhat fizikai vagy digitális eszközöket, és a tagok szavazhatnak a használatukról. - **Kockázati tőke és támogatás** – létrehozhat egy kockázatitőke-alapot, mely befektetési tőkét gyűjt, és szavazással válaszhatók ki a támogatandó vállalkozások. A visszaérkező összegeket pedig később szétoszthatják a DAO tagjai között. + + ## Hogyan működnek a DAO-k? {#how-daos-work} A DAO gerincét az [intelligens szerződés](/glossary/#smart-contract) adja, amely meghatározza a szervezet szabályait és birtokolja a csoport pénztárát. Amint a szerződés életbe lép az Ethereumon, csakis szavazás útján lehet módosítani a szabályokat. Ha valaki olyat próbál tenni, ami nem szerepel a szabályokban és a programlogikában, az meghiúsul. Mivel a társaság pénzügyeit is az okosszerződés határozza meg, ezért a csoport jóváhagyása nélkül senki sem költheti el a pénzösszegeket. Tehát a DAO-nak nincs szüksége központi hatóságra. Ehelyett a csoport közösen hoz döntéseket, a kifizetések pedig automatikusan jóváhagyásra kerülnek a szavazás eredményeként. @@ -54,7 +56,7 @@ Mindez azért lehetséges, mert az okosszerződést nem lehet önkényesen megv Az Ethereum tökéletes alapot szolgáltat a DAO-knak számtalan okból kifolyólag: -- Az Ethereum saját konszenzusmechanizmusa kellőképpen kiterjedt és megalapozott ahhoz, hogy a szervezetek megbízzanak a hálózatban. +- Az Ethereum saját konszenzusa decentralizált és eléggé megalapozott ahhoz, hogy a szervezetek megbízhassanak a hálózatban. - Az okosszerződés tartalmát nem lehet módosítani, miután életbe lépett, még a tulajdonosok sem módosíthatják azt. Ennek következtében a DAO a meghatározott szabályok alapján fog működni. - Az okosszerződések képesek pénzeszközöket küldeni és fogadni. Enélkül szükség lenne egy megbízható közvetítőre, aki a csoport eszközeit kezelné. - Az Ethereum közössége bizonyítottan együttműködő, nem versenyszellemű, így a bevált gyakorlatok és a támogatórendszerek gyorsan kialakulnak. @@ -119,11 +121,11 @@ _Főleg a szorosabb szerveződésű, emberközpontú szervezetek használják, m A reputáció a részvételt igazolja és szavazati jogot biztosít a DAO-ban. A token- és részesedésalapú tagsággal ellentétben a reputációalapú DAO nem ad tulajdonjogot a közreműködőknek. A reputációt nem lehet megvenni, átadni vagy delegálni; a DAO tagok a részvételükkel nyerik el azt. A láncon belüli szavazás nem engedélyhez kötött, a leendő tagok szabadon kérvényezhetik a DAO-hoz való csatlakozást, illetve azt, hogy a közreműködésükért cserébe reputációt és tokent kapjanak. -_Jellemzően protokollok és [dapp-ok](/glossary/#dapp) decentralizált fejlesztésére és irányítására használják, de kiválóan alkalmas különféle szervezetek, például jótékonysági szervezetek, munkavállalói kollektívák, befektetési klubok stb._ +_Jellemzően protokollok és [dapp-ok](/glossary/#dapp) decentralizált fejlesztésére és irányítására használják, de kiválóan alkalmas különféle szervezetek, például jótékonysági szervezetek, munkavállalói kollektívák, befektetési klubok stb. számára is_ #### Egy híres példa {#reputation-example} -[DXdao](https://DXdao.eth.link) – A DXdao egy független globális csoportosulás, amely 2019 óta épít és irányít decentralizált protokollokat és alkalmazásokat. A hírnév alapú kormányzást és a [holografikus konszenzust](/glossary/#holographic-consensus) kihasználja az alapok koordinálásához és kezeléséhez, ami azt jelenti, hogy senki sem vásárolhatja meg magát a jövőjének befolyásolásában. +[DXdao](https://DXdao.eth.limo) – A DXdao egy független globális csoportosulás, amely 2019 óta épít és irányít decentralizált protokollokat és alkalmazásokat. A hírnév alapú kormányzást és a [holografikus konszenzust](/glossary/#holographic-consensus) használja az alapok koordinálásához és kezeléséhez, ami azt jelenti, hogy senki sem vásárolhatja meg a tagságot a szervezet jövőjének vagy irányításának befolyásolása céljából. ## Csatlakozás DAO-hoz / DAO indítása {#join-start-a-dao} @@ -158,3 +160,7 @@ _Jellemzően protokollok és [dapp-ok](/glossary/#dapp) decentralizált fejleszt - [Mit jelent a DAO a kripto világában?](https://youtu.be/KHm0uUPqmVE) - [Felépíthet egy várost egy DAO?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/) + + + + diff --git a/public/content/translations/hu/defi/index.md b/public/content/translations/hu/defi/index.md index cf5162bad44..c800034cc64 100644 --- a/public/content/translations/hu/defi/index.md +++ b/public/content/translations/hu/defi/index.md @@ -355,3 +355,7 @@ A DeFi egy nyílt forráskódú kezdeményezés. A kapcsolódó protokollok és - [DeFi Llama Discord-szerver](https://discord.defillama.com/) - [DeFi Pulse Discord-szerver](https://discord.gg/Gx4TCTk) + + + + \ No newline at end of file diff --git a/public/content/translations/hu/desci/index.md b/public/content/translations/hu/desci/index.md index 3c2747df82e..026acb08c2a 100644 --- a/public/content/translations/hu/desci/index.md +++ b/public/content/translations/hu/desci/index.md @@ -126,6 +126,7 @@ Fedezze fel a projekteket és csatlakozzon a DeSci közösségéhez. - [DeSci: a kutatás jövője – Samuel Akinosho](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec) - [A tudomány finanszírozása (Epilógus: a DeSci és az új kriptoalapok) – Nadia](https://nadia.xyz/science-funding) - [A decentralizáció megbontja a gyógyszerfejlesztést](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f) +- [Mi az a DeSci, azaz a decentralizált tudomány?](​https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/) ### Videók {#videos} @@ -134,3 +135,4 @@ Fedezze fel a projekteket és csatlakozzon a DeSci közösségéhez. - [A tudományos publikálás szét van szakítva. A web3 meg tudja vajon javítani?](https://www.youtube.com/watch?v=WkvzYgCvWj8) - [Juan Benet – DeSci, független laboratóriumok és a nagy adat tudománya](https://www.youtube.com/watch?v=zkXM9H90g_E) - [Sebastian Brunemeier – Hogyan tudja a DeSci átalakítani az orvosbiológiai kutatást és a kockázati tőkét](https://www.youtube.com/watch?v=qB4Tc3FcVbM) +- [Paige Donner - A nyitott tudomány eszközökkel való ellátása a web3 & a blokklánc révén](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s) diff --git a/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md index c686a96a185..fe0fed8b75a 100644 --- a/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md +++ b/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -4,160 +4,86 @@ description: Ismerje meg a proof-of-stake Ethereum elleni ismert támadási vekt lang: hu --- -A tolvajok és szabotőrök folyamatosan keresik a lehetőséget, hogy megtámadják az Ethereum kliensszoftverét. Ez az oldal ismerteti az Ethereum konszenzusrétegét érő ismert támadási vektorokat, és felvázolja, hogyan lehet ezeket a támadásokat kivédeni. Az ezen az oldalon található információk egy [hosszabb változatból](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) származnak. +A tolvajok és szabotőrök folyamatosan keresik a lehetőséget, hogy megtámadják az Ethereum kliensszoftverét. Ez az oldal ismerteti az Ethereum konszenzusrétegét érő ismert támadási vektorokat, és felvázolja, hogyan lehet ezeket a támadásokat kivédeni. ## Előfeltételek {#prerequisites} -A [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) alapszintű ismerete szükséges. Hasznos lesz továbbá, ha alapszintű ismeretekkel rendelkezik az Ethereum [ösztönzési réteg](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) és az elágazásválasztási algoritmus, az [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper) működéséről. - -## Mit akarnak a támadók? {#what-do-attackers-want} +## {#what-is-pos} Gyakori tévhit, hogy egy sikeres támadó képes új ethert generálni, vagy tetszőleges számlákról ethert lehívni. Egyik sem lehetséges, mivel minden tranzakciót a hálózat összes végrehajtási kliense hajtja végre. A tranzakcióknak meg kell felelniük az érvényesség alapvető feltételeinek (például a tranzakciókat a feladó privát kulcsa írja alá, a feladónak elegendő egyenleggel kell rendelkeznie stb. Az eredménynek három osztálya van, amelyet egy támadó reálisan megcélozhat: átszervezés, dupla véglegesség vagy a véglegesség késleltetése. +## {#validators} + Az **átszervezés** a blokkok új sorrendbe rendezése, esetleg a kanonikus láncban lévő blokkok hozzáadásával vagy kivonásával. Egy rosszindulatú átszervezés biztosíthatja, hogy bizonyos blokkok bekerüljenek vagy kikerüljenek, lehetővé téve a dupla költést vagy az értékkivonást előre és hátra futó tranzakciókkal (MEV). Az átszervezés arra is felhasználható, hogy bizonyos tranzakciókat ne lehessen felvenni a kanonikus láncba, ami a cenzúra egy formája. Az átszervezés legszélsőségesebb formája a „véglegesítés visszaállítása”, amely eltávolítja vagy helyettesíti a korábban véglegesített blokkokat. Ez csak akkor lehetséges, ha a támadó a teljes feltett ether több mint ⅓-át megsemmisíti – ez a garancia az úgynevezett „gazdasági véglegesség” (erről később még lesz szó). **Kettős véglegesség** az a valószínűtlen, de súlyos állapot, amikor két elágazás képes egyszerre véglegesedni, ami tartós szakadást okoz a láncban. Ez elméletileg lehetséges egy olyan támadó számára, aki hajlandó a teljes feltett ether 34%-át kockáztatni. A közösség kénytelen lenne a láncon kívül koordinálni és megegyezni arról, hogy melyik láncot kövesse, amihez a társadalmi réteg erejére lenne szükség. -A **véglegesség késleltetése** megakadályozza, hogy a hálózat elérje a szükséges feltételeket a lánc szakaszainak véglegesítéséhez. Véglegesség nélkül nehéz megbízni az Ethereumra épülő pénzügyi alkalmazásokban. A véglegességkésleltetéses támadás célja valószínűleg egyszerűen az Ethereum megzavarása, nem pedig a közvetlen haszonszerzés, kivéve, ha a támadónak stratégiai short pozíciói vannak. - -A szociális réteg elleni támadás célja lehet az Ethereumba vetett közbizalom aláásása, az ether leértékelése, az elfogadás csökkentése vagy az Ethereum-közösség gyengítése, hogy megnehezítse a sávon kívüli koordinációt. +## {#transaction-execution-ethereum-pos} -Miután megállapítottuk került, hogy egy ellenség miért támadhatja meg az Ethereumot, a következő szakaszok azt vizsgálják meg, hogy _hogyan_ lehet ezt megtenni. +1. +2. +3. +4. +5. +6. -## Támadási módszerek {#methods-of-attack} +A szociális réteg elleni támadás célja lehet az Ethereumba vetett közbizalom aláásása, az ether leértékelése, az elfogadás csökkentése vagy az Ethereum-közösség gyengítése, hogy megnehezítse a sávon kívüli koordinációt. -### 0. rétegbeli támadások {#layer-0} +## {#finality} Először is, azok a személyek, akik nem vesznek részt aktívan az Ethereumban (a kliensszoftver futtatásával), a társadalmi réteget (0. réteg) célozva támadhatnak. A 0. réteg az alap, amelyre az Ethereum épül, és mint ilyen, potenciális támadási felületet jelent, amelynek következményei a stack többi részére is kihatnak. Néhány példa: -- Egy félretájékoztató kampány alááshatja a közösség bizalmát az Ethereum ütemtervét, fejlesztőcsapatokat, alkalmazásokba stb. illetően. Ez pedig csökkentheti a hálózat biztosításában résztvevők számát, ami rontja a decentralizációt és a kriptogazdasági biztonságot. -- Célzott támadások és/vagy fenyegetés a fejlesztői közösség ellen. Ez a fejlesztők önkéntes kilépéséhez vezethet, és lelassíthatja az Ethereum fejlődését. - -- A túlbuzgó szabályozás a 0. réteg elleni támadásnak is tekinthető, mivel gyorsan visszavetheti a részvételt és az elfogadást. -- Hozzáértő, de rosszindulatú szereplők beszivárgása a fejlesztői közösségbe, akiknek célja a fejlődés lelassítása a megbeszélések megzavarásával, a fontos döntések késleltetésével, szemeteléssel (spam) stb. -- Az Ethereum ökoszisztéma kulcsszereplőinek adott kenőpénzek, hogy ezzel befolyásolják a döntéshozatalt. +## {#crypto-economic-security} Ezeket a támadásokat az teszi különösen veszélyessé, hogy sok esetben nagyon kevés tőkére vagy technikai tudásra van szükség. Egy 0. rétegbeli támadás egy kriptogazdasági támadás multiplikátora lehet. Ha például a cenzúrát vagy a véglegesség visszaállítását egy rosszindulatú többségi érdekelt fél érné el, a szociális réteg aláásása megnehezíthetné a sávon kívüli közösségi válaszlépések koordinálását. A 0. rétegbeli támadások elleni védekezés valószínűleg nem egyszerű, de néhány alapelvet fel lehet állítani. Az egyik az Ethereummal kapcsolatos nyilvános információk magas jel-zaj arányának fenntartása, amelyeket a közösség becsületes tagjai hoznak létre és terjesztenek blogokon, Discord szervereken, kommentált specifikációkon, könyveken, podcastokon és Youtube-on keresztül. Itt az ethereum.org-on is igyekszünk pontos információkat fenntartani és a lehető legtöbb nyelvre lefordítani. A tér minőségi információkkal és mémekkel való elárasztása hatékony védekezés a félretájékoztatás ellen. -Egy másik fontos megerősítés a társadalmi réteg támadásaival szemben az egyértelmű küldetésnyilatkozat és az irányítási protokoll. Az Ethereum a decentralizáció és a biztonság bajnokaként pozicionálta magát az L1-es okosszerződések között, miközben nagyra értékeli a skálázhatóságot és a fenntarthatóságot is. Bármilyen nézeteltérések merülnek fel az Ethereum közösségben, ezek az alapelvek minimálisan sérülnek. A narratíva értékelése ezen alapelvek alapján és a felülvizsgálat egymást követő fordulóin keresztül az EIP (Ethereum Fejlesztési Javaslatok) folyamatában segíthet a közösségnek megkülönböztetni a jó és a rossz szereplőket, illetve korlátozhatja a rosszindulatú szereplők lehetőségét az Ethereum jövőbeli irányának befolyásolására. - -Végezetül fontos, hogy az Ethereum-közösség nyitott és befogadó maradjon minden résztvevő számára. A zártkörű közösségek különösen sebezhetők a társadalmi támadásokkal szemben, mivel könnyű „mi és ők” narratívákat építeni. A törzsiség és a mérgező maximalizmus árt a közösségnek és aláássa a 0. réteg biztonságát. A hálózat biztonságában érdekelt Ethereum-tagoknak úgy kell tekinteni az online és személyes találkozásokra, mint ami közvetlenül hozzájárul az Ethereum 0. rétegének biztonságához. - -### A protokoll megtámadása {#attacking-the-protocol} - -Bárki, aki az Ethereum kliensszoftverét futtatja. Ahhoz, hogy egy validátor hozzáadjon egy klienshez, a felhasználónak 32 ethert kell betennie a letéti szerződésbe. A validátor lehetővé teszi a felhasználó számára, hogy aktívan részt vegyen az Ethereum hálózatának biztonságában azáltal, hogy új blokkokat javasol és tanúsít. A validátornak mostantól befolyásolhatja a blokklánc jövőbeli tartalmát is – teheti ezt becsületesen, és a jutalmak révén növelheti ether-egyenlegét, vagy megpróbálhatja a folyamatot a saját előnyére manipulálni, kockáztatva a letétjét. A támadás egyik módja az, hogy a teljes letét nagyobb hányadát halmozzák fel, majd ezt arra használják, hogy a becsületes validátorokat túlszavazzák. Minél nagyobb a támadó által ellenőrzött letét aránya, annál nagyobb a szavazóereje, különösen bizonyos gazdasági mérföldköveknél, amelyeket később megvizsgálunk. A legtöbb támadó azonban nem lesz képes elegendő ethert felhalmozni ahhoz, hogy ilyen módon támadjon, így ehelyett finom technikákat kell alkalmazniuk, hogy manipulálják a becsületes többséget, hogy egy bizonyos módon cselekedjen. - -Alapvetően minden kis letétes támadás a validátor kétféle hibás viselkedésének variációja: az aktivitáshiány (nem vagy későn tesznek javaslatot) vagy a túlaktivitás (túl sokszor tesznek javaslatot egy sloton belül). Legegyszerűbb formájukban ezeket a műveleteket az elágazásválasztó algoritmus és az ösztönző réteg könnyen kezeli, de vannak okos módszerek arra, hogy a támadók előnyére játszhassák ki a rendszert. - -### Kis mennyiségű ETH-t használó támadások {#attacks-by-small-stakeholders} - -#### Átszervezések (reorg) {#reorgs} - -Több cikk is ismertette az Ethereum elleni olyan támadásokat, amelyek a teljes feltett ether csak kis hányadával érnek el reorgokat vagy végleges késleltetést. Ezek a támadások általában arra épülnek, hogy a támadó visszatart valamilyen információt a többi validátor elől, majd valamilyen árnyalt módon és/vagy egy alkalmas pillanatban kiadja azt. Céljuk általában az, hogy kiszorítsanak egy vagy több becsületes blokkot a kanonikus láncból. Egy tanulmány, [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf), megmutatta, hogy egy támadó validátor hogyan hozhat létre és tanúsíthat egy blokkot (`B`) egy adott `n+1` slothoz, de tartózkodhat attól, hogy azt a hálózat más csomópontjainak továbbítsa. Ehelyett a következő `n+2` slotig megtartják az igazolt blokkot. Egy becsületes validátor egy blokkot (`C`) javasol az `n+2` slotba. Ezzel szinte egyidejűleg a támadó kiadhatja a visszatartott blokkját (`B`) és az arra vonatkozó visszatartott tanúsítványait, és az `n+2` slotra leadott szavazataival azt is tanúsíthatja, hogy `B` a lánc feje, ezzel gyakorlatilag tagadva a becsületes `C` blokk létezését. Amikor a becsületes `D` blokk felszabadul, az elágazásválasztó algoritmus úgy látja, hogy a `B` tetejére épülő `D` nehezebb, mint a `C`-re épülő `D`. A támadónak tehát sikerült eltávolítania az `n+2` slotban lévő becsületes `C` blokkot a kanonikus láncból egy 1 blokkos ex ante reorg segítségével. [Egy támadónak a tét 34%-ával](https://www.youtube.com/watch?v=6vzXwwk12ZE) nagyon jó esélye van arra, hogy sikerrel járjon ebben a támadásban, amint azt [ebben a jegyzetben](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) kifejtettük. Elméletileg azonban ezt a támadást kisebb letétekkel is meg lehetne kísérelni. [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf) leírta, hogy ez a támadás 30%-os letét mellett is működik, de később kimutatták, hogy [2%-os letét mellett is életképes](https://arxiv.org/pdf/2009.04987.pdf), majd [egyetlen validátor](https://arxiv.org/abs/2110.10086#) esetén is, a következő fejezetben vizsgált kiegyensúlyozási technikák segítségével. - -![ex-ante reorg](reorg-schematic.png) - -A fent leírt egyblokkos átszervezési támadás koncepcionális ábrája (a https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair oldalról átvéve) - -Egy kifinomultabb támadás a becsületes validátorok halmazát különálló csoportokra oszthatja, amelyeknek különböző nézeteik vannak a lánc fejéről. Ezt nevezik **kiegyenlítő támadásnak**. A támadó megvárja az esélyt, hogy egy blokkot javasoljon, és amikor az megérkezik, kétértelműsíti, és kettőt javasol. Az egyik blokkot a becsületes validátorok felének, a másik blokkot pedig a másik felének. Az elágazásválasztó algoritmus észlelné a kétértelműséget, és a blokkot javaslót megbüntetné és kidobná a hálózatból, de a két blokk továbbra is létezne, és a validátorok körülbelül fele tanúsítaná mindkét elágazást. Eközben a fennmaradó rosszindulatú validátorok visszatartják tanúsításaikat. Ezután az egyik vagy másik elágazást előnyben részesítő tanúsítások szelektív felszabadításával éppen elég validátornak adják át a tanúsítások felhalmozott súlyát az egyik vagy másik elágazás javára, amint az elágazásválasztó algoritmus lefut, így a tanúsítások felhalmozott súlyát az egyik vagy másik elágazás javára billentik. Ez a végtelenségig folytatódhat, a támadó validátorok pedig fenntartják a validátorok egyenletes elosztását a két elágazás között. Mivel egyik elágazás sem tud 2/3-os szupertöbbséget szerezni, a hálózat nem kerülne véglegesítésre. - -**A pattogó (bouncing) támadások** hasonlóak. A szavazatokat a támadó validátorok ismét visszatartják. Ahelyett, hogy a szavazatokat úgy adnák le, hogy a két elágazás között egyenletes legyen a felosztás, a megfelelő pillanatokban arra használják a szavazataikat, hogy olyan ellenőrzőpontokat igazoljanak, amelyek felváltva váltakoznak az A és a B elágazás között. A tanúsításnak ez a két elágazás közötti felcserélése megakadályozza, hogy olyan igazolt forrás- és célellenőrzési pontok párjai legyenek, amelyek bármelyik láncban véglegesíthetők, ami megállítja a véglegesítést. - - - -A pattogó (bouncing) és a kiegyenlítő (balancing) támadás is arra épül, hogy a támadó kifinomult irányítással rendelkezik az üzenetek időzítése felett a hálózaton keresztül, ami nem valószínű. Mindazonáltal a protokollba védelmet építettek be a gyors üzeneteknek a lassú üzenetekkel szemben adott többletsúlyozás formájában. Ez az úgynevezett [javaslattevő-súlynövelés (proposer-weight boosting)](https://github.com/ethereum/consensus-specs/pull/2730). A pattogó támadások elleni védekezés érdekében az elágazásválasztó algoritmust úgy frissítették, hogy a legutóbbi igazolt ellenőrzőpont csak [az adott korszak slotjainak első 1/3-ában](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) válthat át egy alternatív láncra. Ez a feltétel megakadályozza, hogy a támadó szavazatokat gyűjtsön a későbbi használatra – az elágazásválasztó algoritmus egyszerűen hű marad ahhoz az ellenőrzőponthoz, amelyet a korszak első 1/3-ában választott, amely idő alatt a legtöbb becsületes validátor szavazott volna. - -Együttesen ezek az intézkedések olyan forgatókönyvet hoznak létre, amelyben egy becsületes blokkajánló nagyon gyorsan kibocsátja blokkját a slot kezdete után, majd egy kb. 1/3 slotnyi (4 másodperc) időszak következik, amikor az új blokk miatt az elágazásválasztó algoritmus egy másik láncra válthat. Ugyanezen határidő után a lassú validátoroktól érkező tanúsításokat a korábban érkezett tanúsításokhoz képest lefelé súlyozzák. Ez nagymértékben kedvez a gyors ajánlattevőknek és a validátoroknak a lánc fejének meghatározásakor, és jelentősen csökkenti a sikeres kiegyenlítő (balancing) vagy pattogó (bouncing) támadás valószínűségét. - -Érdemes megjegyezni, hogy a javaslattevő erősítése önmagában csak az „olcsó reorgok” ellen véd, vagyis kis letétellel rendelkező támadó esetén. Valójában az előterjesztő-erősítés önmagában is kijátszható a nagyobb érdekeltek által. E [bejegyzés](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) szerzői leírják, hogy egy támadó, aki a letét 7%-ával rendelkezik, hogyan vetheti be a szavazatait stratégiailag, hogy becsületes validátorok becsapásával a saját elágazására építsen, és egy becsületes blokkot átszervezzen. Ezt a támadást ideális késleltetési feltételeket feltételezve dolgozták ki, ami nagyon valószínűtlen. A támadónak kedveznek az esélyek, de a nagyobb letét nagyobb tőkekockázatot és erősebb gazdasági visszatartó erőt is jelent. - -Javasoltak egy [kiegyenlítő támadást is, amely kifejezetten az LMD-szabályt célozza](https://ethresear.ch/t/balancing-attack-lmd-edition/11853), és amely a előterjesztő-erősítés ellenére is életképesnek bizonyult. Egy támadó két versengő láncot hoz létre úgy, hogy a blokkjavaslatát egyenlővé teszi, és minden egyes blokkot a hálózat egy-egy felére terjeszti el, így megközelítőleg egyensúlyt hoz létre az elágazások között. Ezután az összejátszó validátorok kiegyenlítik a szavazataikat, úgy időzítve, hogy a hálózat fele az `A` elágazásra kapja meg először a szavazatát, a másik fele pedig a `B` elágazásra. Mivel az LMD-szabály elveti a második tanúsítást, és csak az elsőt tartja meg minden egyes validátor számára, a hálózat egyik fele csak az `A`-ra adott szavazatokat látja, a `B`-re adottakat nem; a másik fele csak a `B`-re adott szavazatokat látja, az `A`-ra adottakat nem. A szerzők leírják, hogy az LMD-szabály „figyelemre méltó hatalmat” ad az ellenségnek a kiegyenlítő támadáshoz. - -Ezt az LMD támadási vektort a [az elágazásválasztó algoritmus frissítésével](https://github.com/ethereum/consensus-specs/pull/2845) zárták le úgy, hogy az elágazásválasztásnál az egyenlőtlen validátorokat teljesen kizárja a megfontolásból. Az egyenlőtlen validátorok jövőbeli befolyását az elágazásválasztó algoritmus kihagyja a számításból. Ez megakadályozza a fent vázolt kiegyenlítő támadást, miközben a lavinatámadásokkal szembeni ellenállóképességet is fenntartja. - -A támadások egy másik osztályát, az úgynevezett [**lavinatámadásokat**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3) egy [2022 márciusában megjelent tanulmányban](https://arxiv.org/pdf/2203.01315.pdf) írták le. A lavinatámadáshoz a támadónak több egymást követő blokkajánlót kell irányítania. A támadó minden egyes blokkjavaslati slotban visszatartja a blokkját, és addig gyűjti azokat, amíg az őszinte lánc el nem éri a visszatartott blokkokkal azonos részfa súlyát. Ezután a visszatartott blokkok felszabadulnak úgy, hogy maximálisan kiegyenlítődnek. A szerzők szerint a előterjesztő-erősítés – az elsődleges védelem a kiegyenlítő és pattogó támadások ellen – nem véd a lavinatámadás egyes változatai ellen. A szerzők azonban a támadást csak az Ethereum elágazásválasztó algoritmusának egy erősen idealizált változatán mutatták be (a GHOST-ot használták LMD nélkül). - -A lavinatámadást az LMD-GHOST elágazásválasztó algoritmus LMD része enyhíti. Az LMD jelentése a „legutolsó üzenet által vezérelt” (latest-message-driven), és az egyes validátorok által vezetett táblázatra utal, amely a többi validátortól kapott legfrissebb üzenetet tartalmazza. Ez a mező csak akkor frissül, ha az új üzenet későbbi időpontból származik, mint a táblázatban egy adott validátort illetően már szereplő üzenet. A gyakorlatban ez azt jelenti, hogy minden egyes slotban az első fogadott üzenet az, amelyet a rendszer elfogadott, és minden további üzenet kétértelműség, amelyet figyelmen kívül kell hagyni. Másképpen fogalmazva, a konszenzuskliensek nem veszik figyelembe a kétértelműséget – a validátoroktól elsőként érkező üzenetet használják, a kétértelműséget elvetik, megelőzve ezzel a lavinatámadásokat. +## {#fork-choice} -Az elágazásválasztási szabály számos más lehetséges jövőbeli frissítése is létezik, amelyek növelhetik a előterjesztő-erősítés által nyújtott biztonságot. Az egyik a [nézetösszevonás](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), ahol a tanúsítók `n` másodperccel egy slot kezdete előtt befagyasztják az elágazásválasztásról alkotott nézetüket, és a javaslattevő ezután segít szinkronizálni a lánc nézetét a hálózaton. Egy másik lehetséges fejlesztés az [ egy sloton belüli véglegesség (single-slot finality)](https://notes.ethereum.org/@vbuterin/single_slot_finality), amely az üzenet időzítésén alapuló támadások ellen véd azáltal, hogy a láncot egyetlen slot után véglegesíti. - -#### Véglegesség késleltetése {#finality-delay} - -[Az a cikk](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf), amely először írta le az alacsony költségű, egyetlen blokkot érintő reorg támadást, leírt egy végső késleltetés (liveness failure) nevű támadást is, amely arra támaszkodik, hogy a támadó egy korszakkal határos blokk javaslattevője. Ez azért kritikus, mert ezek a korszakhatárblokkok lesznek az ellenőrzőpontok, amelyeket a Casper FFG a lánc egyes részeinek véglegesítéséhez használ. A támadó egyszerűen visszatartja a blokkját, amíg elegendő becsületes validátor nem használja FFG-szavazatát az előző korszakhatárblokk javára, mint az aktuális véglegesítési cél. Ezután kiadja a visszatartott blokkot. Tanúsítja a blokkját, és a fennmaradó becsületes validátorok is ezt teszik, különböző célellenőrzési pontokkal rendelkező elágazásokat létrehozva. Ha jól időzített, akkor megakadályozza a véglegességet, mert nem lesz 2/3-os szupertöbbség, amely bármelyik elágazást tanúsítaná. Minél kisebb a letét, annál pontosabb időzítésre van szükség, mivel a támadó kevesebb tanúsítást ellenőriz közvetlenül, és annál kisebb az esélye annak, hogy a támadó ellenőrzi a validátort, amely a korszakhatárblokkot javasolja. - -#### Nagy hatótávolságú támadások {#long-range-attacks} - -Létezik egy, a proof-of-stake blokkláncokra jellemző támadási osztály is, amelynek lényege, hogy a genezisblokkban részt vevő validátor fenntartja a blokklánc egy különálló elágazását a helyes blokklánc mellett, és végül meggyőzi az őszinte validátorhalmazt, hogy később egy alkalmas időpontban váltson át rá. Ez a fajta támadás nem lehetséges az Ethereumon, mivel a véglegességi eszköz (finality gadget) biztosítja, hogy az összes validátor rendszeres időközönként (ellenőrzőpontok) megegyezzen a becsületes lánc állapotáról. Ez az egyszerű mechanizmus semlegesíti a nagy hatótávolságú támadókat, mivel az Ethereum kliensei egyszerűen nem fogják a véglegesített blokkokat újraszervezni. A hálózathoz csatlakozó új csomópontok úgy teszik ezt, hogy keresnek egy megbízható legutóbbi állapot hasht (egy [gyenge szubjektivitás](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) ellenőrzőpontot), és azt használják pszeudo-genezis blokk-ként, amelyre építkeznek. Ez egy „bizalmi bejáratot” hoz létre a hálózatba belépő új csomópont számára, mielőtt az elkezdené ellenőrizni az információkat saját maga számára. - -#### Szolgáltatásmegtagadás (DoS) {#denial-of-service} - -Az Ethereum proof-of-stake mechanizmusa minden egyes slotban egyetlen validátort választ ki a teljes validátorkészletből, aki blokkajánló lesz. Ezt egy nyilvánosan ismert függvény segítségével lehet kiszámítani, és egy támadó számára lehetséges, hogy a következő blokkelőterjesztőt beazonosítsa. Ezután a támadó eláraszthatja szeméttel (spam) a blokkelőterjesztőt, hogy megakadályozza, hogy információt cseréljen a társaival. A hálózat többi része számára úgy tűnne, hogy a blokkelőterjesztő offline, és a slot egyszerűen üresen marad. Ez egyfajta cenzúra lehet bizonyos validátorokkal szemben, megakadályozva őket abban, hogy információt adjanak hozzá a blokklánchoz. Az egyetlen, titkos vezetőválasztás (SSLE) vagy az egynél több titkos vezetőválasztás megvalósítása csökkenti a szolgáltatásmegtagadás (DoS) kockázatát, mivel mindig csak a blokkelőterjesztő tudja, hogy kiválasztották, és nem deríthető ki előre. Ez még nem valósult meg, de a [kutatás-fejlesztési](https://ethresear.ch/t/secret-non-single-leader-election/11789) terület aktívan foglalkozik vele. - -Mindezek alapján elmondható, hogy kis letétekkel nehéz sikeresen megtámadni az Ethereumot. Az itt leírt életképes támadásokhoz idealizált elágasztásválasztó algoritmusra, valószínűtlen hálózati körülményekre van szükség, vagy a támadási vektorokat már lezárták az kliensszoftver-javításokkal. Ez nem zárja ki a lehetőséget, de a kisebbségi letéttel rendelkező támadó hatékonyságát meghatározza az, hogy milyen szintű technikai képességekkel bír, a konszenzusréteg ismerete és a szerencse. A támadó szempontjából az lehet a legjobb megoldás, ha minél több ethert halmoz fel, és a teljes letét többségi hányadával próbál elérni valamit. - -### A támadók a teljes letét >=33%-át használják {#attackers-with-33-stake} - -Az eddig említett összes támadás sikerének valószínűsége megnő, ha a támadónak több letétbe helyezett ether áll rendelkezésére, amivel szavazhat, és több validátort választhat, akik blokkokat javasolhatnak az egyes slotokban. Egy rosszindulatú validátor ezért arra törekedhet, hogy minél több letétbe helyezett ethert irányítson. - -A feltett ether 33%-a egy támadó számára viszonyítási alap, mivel egy ennél nagyobb összeggel képesek megakadályozni a lánc véglegesítését anélkül, hogy a többi validátor tevékenységét irányítaniuk kellene. Egyszerűen mindannyian együtt eltűnhetnek. Ha a letétbe helyezett ether legalább 1/3-a rosszindulatúan vagy nem tanúsít, akkor a 2/3-os szupertöbbség nem állhat fenn, és a lánc nem véglegesíthető. Ez ellen az inaktivitás elszivárgással védekeznek. Az inaktivitás elszivárgás azonosítja azokat a validátorokat, akik nem vagy a többséggel ellentétesen tanúsítanak. A nem tanúsító validátorok által birtokolt letétbe helyezett ether fokozatosan elvezetésre kerül, míg végül együttesen a teljes mennyiség kevesebb mint 1/3-át képviselik, így a lánc újra véglegesedhet. - -Az inaktivitási elszivárgás célja, hogy a lánc ismét véglegesedjen. A támadó azonban a letétbe helyezett ether egy részét is elveszíti. A teljes letétbe helyezett ether 33%-át kitevő validátorok tartós inaktivitása nagyon drága, még akkor is, ha nem is kapnak súlyos és kizárással járó büntetést. - -Feltételezve, hogy az Ethereum-hálózat aszinkron (az üzenetek küldése és fogadása között késések vannak), egy támadó, aki a teljes letét 34%-át ellenőrzi, kétszeres véglegesítést okozhat. Ez azért van, mert a támadó kétértelművé teheti, ha őt választják blokkelőterjesztőnek, majd duplán szavazhat az összes validátorával. Ez olyan helyzetet teremt, amelyben a blokkláncnak egy olyan elágazása létezik, amely mellett a letétbe helyezett ether 34%-a szavazott. Mindkét elágazásra csak a fennmaradó validátorok 50%-ának kell szavaznia, hogy mindkét elágazást szupertöbbség támogassa, és így mindkét lánc véglegesíthető (mivel a támadó validátorok 34%-a + a fennmaradó 66% fele = 67% mindkét elágazásnál). Az egymással versengő blokkokat a becsületes validátorok kb. 50%-ának kellene megkapnia, így ez a támadás csak akkor életképes, ha a támadónak bizonyos fokú ellenőrzése van a hálózaton terjedő üzenetek időzítése felett, így a becsületes validátorok felét rá tudja kényszeríteni az egyes láncokra. A támadónak szükségszerűen el kellene pusztítania a teljes letétjét (kb. 10 millió ether 34%-a a mai validátorhalmazt figyelembe véve), hogy elérje ezt a kettős véglegességet, mivel a validátorok 34%-a egyszerre kétszer szavazna – ez egy súlyos és kizárással járó büntetés maximális korrelációval. Ezzel a támadással szemben az a magas költség áll, hogy a teljes letétbe helyezett ether 34%-át el kell pusztítani. A támadásból való kilábaláshoz az Ethereum közösségnek „sávon kívül” kell koordinálnia, és meg kellene állapodnia abban, hogy az egyik elágazást követi, a másikat pedig figyelmen kívül hagyja. - -### A támadók a teljes letét kb. 50%-át használják {#attackers-with-50-stake} - -A letétbe helyezett ether 50%-ánál a validátorok egy rosszindulatú csoportja elméletileg két egyforma méretű elágazásra oszthatná a láncot, majd egyszerűen felhasználhatná a teljes 50%-os letétjét arra, hogy a becsületes validátorok csoportjával ellentétesen szavazzon, így fenntartva a két elágazást és megakadályozva a véglegesítést. A két elágazáson az inaktivitási elszivárgás végül mindkét lánc véglegesítéséhez vezet. Ezen a ponton az egyetlen lehetőség a közösségi helyreállítás. - -Nagyon valószínűtlen, hogy a validátorok egy ellenséges csoportja következetesen ellenőrizni tudná a teljes letét pontosan 50%-át, mivel a becsületes validátorok száma, a hálózati késleltetés stb. változó mértékű – egy racionális támadó számára a támadás hatalmas költsége és a siker alacsony valószínűsége erős visszatartó erőnek tűnik, különösen ha a _több mint_ 50% megszerzése nagyobb hatalmat szabadít fel. - -A teljes letét >50%-ánál a támadó uralni tudta az elágazásválasztó algoritmust. Ebben az esetben a támadó képes lenne a többségi szavazattal tanúsítani, ami elegendő kontrollt adna neki ahhoz, hogy rövid átrendeződéseket hajtson végre anélkül, hogy becsületes klienseket kellene becsapnia. A becsületes validátorok követnék ezt a példát, mivel az ő elágazásválasztó algoritmusuk is a támadó által preferált láncot látná a legnehezebbnek, így a lánc véglegesedhetne. Ez lehetővé teszi a támadó számára, hogy bizonyos tranzakciókat cenzúrázzon, rövidtávú átszervezéseket végezzen, és a blokkok önérdekű átrendezésével maximális profitot (MEV) szerezzen. Ez ellen a többségi részesedés hatalmas költsége (az írás idején ez kb. 19 milliárd dollár) ad védelmet, amelyet egy támadó kockáztat, mivel a társadalmi réteg közbeléphet, és elfogadhat egy becsületes kisebbségi elágazást, ami drámaian leértékeli a támadó részesedését. - -### A támadók a teljes letét >=66%-át használják {#attackers-with-66-stake} - -Egy támadó, aki az összes letétbe helyezett ether 66%-ával vagy többel rendelkezik, véglegesítheti a preferált láncot anélkül, hogy a becsületes validátorokat kényszerítenie kellene. A támadók egyszerűen megszavazhatják a preferált elágazást, majd véglegesíthetik azt, mert tisztességtelen szupertöbbséggel szavazhatnak. A szupertöbbség birtokosaként a támadó irányítaná a véglegesített blokkok tartalmát, hatalmában állna költeni, visszatekerni és újrakölteni, cenzúrázni bizonyos tranzakciókat és tetszés szerint átszervezni a láncot. Azzal, hogy a támadó további ethert vásárol, hogy 51% helyett 66%-ot ellenőrizzen, megszerzi a képességet, hogy utólagos reorgokat és végleges visszafordításokat hajtson végre (azaz megváltoztassa a múltat és ellenőrizze a jövőt is). Az egyetlen igazi védekezés a hatalmas költség, a teljes letétbe helyezett ether 66%-a, és a közösségi rétegre támaszkodva egy alternatív elágazás elfogadásának koordinálása. Ezt a következő részben részletesebben is megvizsgáljuk. - -## Emberek: az utolsó védelmi vonal {#people-the-last-line-of-defense} - -Ha a tisztességtelen validátoroknak sikerül véglegesíteniük a lánc általuk preferált verzióját, az Ethereum-közösség nehéz helyzetbe kerül. A kanonikus lánc tartalmaz egy tisztességtelen szakaszt az előzményeibe égetve, míg a becsületes validátorok büntetést kaphatnak, ha egy alternatív (becsületes) láncot tanúsítanak. Vegye figyelembe, hogy egy véglegesített, de hibás lánc a többségi kliens hibájából is adódhat. Végül a végső megoldás az, hogy a közösségi (0.) rétegre hagyatkozunk. - -Az Ethereum proof-of-stake konszenzusának egyik erőssége, hogy a közösség számos [védekező stratégiát](https://youtu.be/1m12zgJ42dI?t=1712) alkalmazhat egy támadás esetén. A minimális válasz lehet a támadók validátorainak a hálózatból való kizárása további szankció nélkül. A hálózatba való újbóli belépéshez a támadó egy aktiválási sorba kerül, amely biztosítja, hogy a validátorok halmaza fokozatosan növekedjen. Például elegendő validátor hozzáadása ahhoz, hogy megduplázza a letétbe helyezett ether mennyiségét, körülbelül 200 napot vesz igénybe, így a becsületes validátorok 200 napot nyerhetnek, mielőtt a támadó újabb 51%-os támadást kísérelhet meg. A közösség azonban dönthet úgy is, hogy szigorúbban bünteti a támadót, visszavonva a korábbi jutalmakat, vagy elégetve a letéti tőke egy részét (vagy akár 100%-át). - -A támadóra kiszabott büntetéstől függetlenül a közösségnek közösen kell döntenie arról is, hogy a tisztességtelen lánc – annak ellenére, hogy az Ethereum-kliensekbe kódolt elágazásválasztó algoritmus előnyben részesíti – valójában érvénytelen, és a közösségnek inkább a tisztességes láncra kellene építenie. A becsületes validátorok megállapodhatnak, hogy az Ethereum blokklánc közösség által elfogadott elágazására építenek, amely például a támadás megkezdése előtt elágazhatott a kanonikus láncról, vagy a támadók validátorait eltávolíthatják. A becsületes validátorok ösztönzést kapnának arra, hogy erre a láncra építsenek, mert elkerülhetnék a büntetést, amit azért kapnának, ha (jogosan) nem tanúsítanák a támadó láncát. Az Ethereumra épülő tőzsdék, on-rampok és alkalmazások inkább a helyes láncon szeretnének lenni, és követnék a becsületes validátorokat a helyes blokkláncra. - -Ez azonban jelentős vezetési kihívást jelentene. Néhány felhasználó és validátor kétségtelenül veszítene a helyes láncra való visszaváltás következtében, a támadás után validált blokkokban lévő tranzakciókat potenciálisan visszavonnák, megzavarva az alkalmazási réteget, és ez aláássa egyes felhasználók etikai elképzeléseit, akik hajlamosak azt hinni, hogy „a kód a törvény”. A tőzsdék és az alkalmazások valószínűleg összekapcsolták a láncon kívüli műveleteket a láncon belüli tranzakciókkal, amelyeket most vissza lehet göngyölíteni, elindítva a visszavonások és felülvizsgálatok tömkelegét, amelyet nehéz lenne tisztességesen kibogozni, különösen, ha a jogtalanul szerzett nyereségeket összekeverték, DeFi-ba vagy más származékos termékekbe helyezték, amelyek másodlagos hatásokkal járnak a tisztességes felhasználók számára. Kétségtelen, hogy néhány felhasználó, talán még az intézményiek is, hasznot húztak volna a tisztességtelen láncból, ravaszságból vagy szerencsés véletlenből, és elleneznék az elágazást, hogy megvédjék a hasznukat. Elpróbálták a >51%-os támadásokra adott közösségi válaszlépéseket, hogy egy észszerű, összehangolt választ gyorsan végre lehessen hajtani. A témáról tekintse meg Vitalik hasznos eszmecseréit az ethresear.ch oldalon [itt](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) és [itt](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363), valamint a Twitteren [itt](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw). Az összehangolt társadalmi reakció célja a támadó megbüntetése és a többi felhasználóra gyakorolt hatások minimalizálása kell, hogy legyen. - -A vezetés már önmagában is bonyolult téma. Egy tisztességtelen véglegesítő láncra adott 0. rétegbeli vészreakció kezelése kihívást jelentene az Ethereum közösség számára, de ez már [megtörtént](/history/#dao-fork-summary) – [kétszer](/history/#tangerine-whistle) – az Ethereum történetében. +Egy másik fontos megerősítés a társadalmi réteg támadásaival szemben az egyértelmű küldetésnyilatkozat és az irányítási protokoll. Az Ethereum a decentralizáció és a biztonság bajnokaként pozicionálta magát az L1-es okosszerződések között, miközben nagyra értékeli a skálázhatóságot és a fenntarthatóságot is. Bármilyen nézeteltérések merülnek fel az Ethereum közösségben, ezek az alapelvek minimálisan sérülnek. A narratíva értékelése ezen alapelvek alapján és a felülvizsgálat egymást követő fordulóin keresztül az EIP (Ethereum Fejlesztési Javaslatok) folyamatában segíthet a közösségnek megkülönböztetni a jó és a rossz szereplőket, illetve korlátozhatja a rosszindulatú szereplők lehetőségét az Ethereum jövőbeli irányának befolyásolására. -Mindazonáltal van valami kielégítő abban, hogy a végső megoldás a való világban található. Végső soron, még e fenomenális technológiai rendszer ellenére is, ha a legrosszabb valaha is bekövetkezne, a valódi embereknek kellene koordinálniuk a kiutat. +## {#pos-and-security} -## Összegzés {#summary} +Végezetül fontos, hogy az Ethereum-közösség nyitott és befogadó maradjon minden résztvevő számára. A zártkörű közösségek különösen sebezhetők a társadalmi támadásokkal szemben, mivel könnyű „mi és ők” narratívákat építeni. A törzsiség és a mérgező maximalizmus árt a közösségnek és aláássa a 0. réteg biztonságát. A hálózat biztonságában érdekelt Ethereum-tagoknak úgy kell tekinteni az online és személyes találkozásokra, mint ami közvetlenül hozzájárul az Ethereum 0. rétegének biztonságához. -Ez az oldal azt vizsgálta, hogy a támadók milyen módon próbálhatják meg kihasználni az Ethereum proof-of-stake konszenzus protokollját. A reorgokat és a véglegesítés késleltetését a teljes letétbe helyezett ether növekvő arányú támadók esetében vizsgáltuk. Összességében a gazdagabb támadóknak nagyobb esélyük van a sikerre, mivel a letétjük szavazati joggal jár, amellyel befolyásolni tudják a jövőbeli blokkok tartalmát. Bizonyos küszöbértékeknél a támadó ereje növekszik: +- +- +- +- Hozzáértő, de rosszindulatú szereplők beszivárgása a fejlesztői közösségbe, akiknek célja a fejlődés lelassítása a megbeszélések megzavarásával, a fontos döntések késleltetésével, szemeteléssel (spam) stb. -33%: késleltetett véglegesség +## {#pros-and-cons} -34%: késleltetett véglegesség, kettős véglegesség +| | | +| | | +| | | +| | | +| | | +| | | -51%: késleltetett véglegesség, kettős véglegesség, cenzúra, a blokklánc jövőjének ellenőrzése +### {#comparison-to-proof-of-work} -66%: késleltetett véglegesség, kettős véglegesség, cenzúra, a blokklánc jövőjének és múltjának ellenőrzése +Több cikk is ismertette az Ethereum elleni olyan támadásokat, amelyek a teljes feltett ether csak kis hányadával érnek el reorgokat vagy végleges késleltetést. Ezek a támadások általában arra épülnek, hogy a támadó visszatart valamilyen információt a többi validátor elől, majd valamilyen árnyalt módon és/vagy egy alkalmas pillanatban kiadja azt. -Létezik egy sor kifinomultabb támadás is, amelyekhez kis mennyiségű letétbe helyezett ether is elég, de egy kifinomult támadó kell hozzá, aki az üzenet időzítése felett kontrollt gyakorol, hogy a saját javára befolyásolja a becsületes validátorok halmazát. +- +- +- +- +- +- -Összességében, ezen potenciális támadási vektorok ellenére a sikeres támadás kockázata alacsony, minden bizonnyal alacsonyabb, mint a proof-of-worknél. Mivel a támadó, aki a becsületes validátorok szavazati erejével elnyomja a becsületes validátorokat, a letétbe helyezett ether költségét kockáztatja. A beépített „jutalmazás-büntetés” ösztönző réteg megvéd a legtöbb visszaéléstől, különösen az alacsony letéttel rendelkező támadóktól. A kifinomultabb pattogó és kiegyenlítő támadások szintén nem valószínű, hogy sikerrel járnak, mivel a valós hálózati feltételek miatt nehéz elérni az üzenetek kézbesítésének szabályozását a validátorok meghatározott részhalmazaihoz, és a klienscsapatok egyszerű javításokkal lezárták az ismert pattogó, kiegyenlítő és lavinatámadási vektorokat. +## {#further-reading} -A 34%-os, 51%-os vagy 66%-os támadások sávon kívüli társadalmi koordinációt igényelnek a megoldásához. Bár ez valószínűleg fájdalmas lenne a közösség számára, a sávon kívüli válaszadás képessége erős visszatartó erőt jelent a támadóknak. Az Ethereum közösségi rétege a végső biztosíték – egy technikailag sikeres támadást még mindig ki lehet iktatni azzal, hogy a közösség elfogad egy becsületes elágazást. A támadó és az Ethereum közösség versenyt futna – a 66%-os támadásra költött dollármilliárdokat egy sikeres közösségi koordináció eltörölné, ha elég gyorsan végzik, így a támadó rengeteg nem likvid etherrel maradna egy tisztességtelen láncon, amelyet az Ethereum közösség figyelmen kívül hagy. Alacsony a valószínűsége, hogy ez a támadónak végül nyereséget hoz, ezért hatékony visszatartóerőt jelent. Ezért olyan fontos a szorosan összehangolt értékekkel rendelkező, összetartó közösségi réteg fenntartása. +- +- +- +- +- +- []() +- +- []() -## További olvasnivaló {#further-reading} +## {#related-topics} -- [A jelen írás részletesebb változata](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) -- [Vitalik az elszámolási véglegességről](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) -- [Az LMD GHOST leírása](https://arxiv.org/abs/2003.03052) -- [A Casper-FFG leírása](https://arxiv.org/abs/1710.09437) -- [A Gasper leírása](https://arxiv.org/pdf/2003.03052.pdf) -- [A javaslattevő-erősítéses konszenzus specifikációi](https://github.com/ethereum/consensus-specs/pull/2730) -- [Pattogó támadások az ethresear.ch oldalon](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) -- [SSLE-kutatás](https://ethresear.ch/t/secret-non-single-leader-election/11789) +- []() +- []() diff --git a/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/index.md index a90f0f9f578..dda68f89056 100644 --- a/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/index.md +++ b/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/index.md @@ -24,7 +24,7 @@ Amíg a proof-of-work esetében a blokkidőt a bányászati nehézség határozz Az alábbiakban egy teljes magyarázatot adunk arról, hogyan hajtanak végre egy tranzakciót az Ethereum proof-of-stake-ben. -1. A felhasználó létrehoz és aláír egy [tranzakciót](/developers/docs/transactions/) a privát kulcsával. Ezt általában egy tárca vagy egy könyvtár, például [ether.js](https://docs.ethers.io/v5/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) stb. kezeli, eközben a háttérben a felhasználó az Ethereum [JSON-RPC API](/developers/docs/apis/json-rpc/) segítségével kérést intéz egy csomóponthoz. A felhasználó meghatározza, hogy mennyi gázt fizet borravalóként a validátornak, hogy az felkapja az adott tranzakciót és betegye egy blokkba. A [borravalót](/developers/docs/gas/#priority-fee) megkapja a validátor, az [alapdíjat](/developers/docs/gas/#base-fee) pedig elégeti a rendszer. +1. A felhasználó létrehoz és aláír egy [tranzakciót](/developers/docs/transactions/) a privát kulcsával. Ezt általában egy tárca vagy egy könyvtár, például [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) stb. kezeli, eközben a háttérben a felhasználó az Ethereum [JSON-RPC API](/developers/docs/apis/json-rpc/) segítségével kérést intéz egy csomóponthoz. A felhasználó meghatározza, hogy mennyi gázt fizet borravalóként a validátornak, hogy az felkapja az adott tranzakciót és betegye egy blokkba. A [borravalót](/developers/docs/gas/#priority-fee) megkapja a validátor, az [alapdíjat](/developers/docs/gas/#base-fee) pedig elégeti a rendszer. 2. A tranzakciót beküldik az Ethereum [végrehajtási klienshez](/developers/docs/nodes-and-clients/#execution-client), hogy ellenőrizze az érvényességét. Ennek része, hogy a küldőnek van elég ETH összege, hogy végre legyen hajtva a tranzakció és a megfelelő kulccsal írta azt alá. 3. Ha a tranzakció érvényes, a végrehajtási kliens a helyi tranzakciógyűjtőjéhez (memóriakészlet, a függő tranzakciók listája) adja és előterjeszti a többi csomópontnak a végrehajtási réteg pletykahálózatán. Amikor a többi csomópont hall a tranzakcióról, akkor azok is beteszik a helyi memóriakészletbe. A haladó felhasználók úgy is dönthetnek, hogy nem a hálózaton terjesztik el a tranzakciójukat, hanem továbbíthatják azt speciális blokképítőknek, mint a [Flashbots aukció](https://docs.flashbots.net/flashbots-auction/overview). Ez lehetővé teszi számukra, hogy a tranzakciókat a következő blokkokba szervezzék a maximális profit érdekében ([MEV](/developers/docs/mev/#mev-extraction)). 4. A hálózat egyik validátor-csomópontja az aktuális slot blokkelőterjesztője, amelyet előzőleg a RANDAO segítségével álvéletlenszerűen kiválasztottak. Ez a csomópont felelős az Ethereum blokklánchoz hozzáadandó következő blokk létrehozásáért és továbbításáért, valamint a globális státusz frissítéséért. A csomópont három részből áll: végrehajtási kliens, konszenzusos kliens és validátorkliens. A végrehajtási kliens a tranzakciókat a helyi memóriakészletből egy végrehajtási csomagba rendezi, és helyben végrehajtja őket, hogy státusztváltozást generáljon. Ezt az információt továbbítják a konszenzusos kliensnek, ahol a végrehajtási csomagot egy Beacon-blokk részeként csomagolják be, amely jutalmakra, büntetésekre, súlyos büntetésekre, tanúsításokra stb. vonatkozó információkat is tartalmaz, amelyek lehetővé teszik a hálózat számára, hogy megállapodjon a lánc élén álló blokkok sorrendjében. A végrehajtási és a konszenzusos kliensek közötti kommunikáció részletesebb leírása a [A konszenzusos és a végrehajtási kliensek összekapcsolása](/developers/docs/networking-layer/#connecting-clients) című cikkben található. diff --git a/public/content/translations/hu/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/hu/developers/docs/design-and-ux/heuristics-for-web3/index.md index 4a78b6a2505..a1f21c12236 100644 --- a/public/content/translations/hu/developers/docs/design-and-ux/heuristics-for-web3/index.md +++ b/public/content/translations/hu/developers/docs/design-and-ux/heuristics-for-web3/index.md @@ -5,7 +5,7 @@ lang: hu --- A használhatósági heurisztikák amolyan ökölszabályok, melyekkel felmérhető egy oldal használhatósága. -Ezeket web3-ra alakították ki és érdemes együtt használni Jakob Nielsen [10 általános elv az interakciós dizájnhoz](https://www.nngroup.com/articles/ten-usability-heuristics/) iránymutatásával. +Az itt felsorolt 7 heurisztikát kifejezetten web3-ra alakították ki és érdemes együtt használni Jakob Nielsen [10 általános elv az interakciós dizájnhoz](https://www.nngroup.com/articles/ten-usability-heuristics/) iránymutatásával. ## Hét használati heurisztika web3-ra {#seven-usability-heuristics-for-web3} diff --git a/public/content/translations/hu/developers/docs/design-and-ux/index.md b/public/content/translations/hu/developers/docs/design-and-ux/index.md index 171beeb8d7b..737132fbe6f 100644 --- a/public/content/translations/hu/developers/docs/design-and-ux/index.md +++ b/public/content/translations/hu/developers/docs/design-and-ux/index.md @@ -23,11 +23,13 @@ Ez a web3-ban végzett felhasználói kutatások válogatott listája, amely seg | Fókuszterület | Név | |:----------------------------------------------------------------- |:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Bevezetés a kriptóba | [The WalletConnect Pulse 2024: Crypto fogyasztói hangulat & használat](https://walletconnect.com/pulse-2024-crypto-consumer-report) | | Bevezetés a kriptóba | [CRADL: UX a kriptovaluták világában](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | | Bevezetés a kriptóba | [CRADL: Bevezetés a kriptovaluták világába](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | | Bevezetés a kriptóba | [Bitcoin UX riport](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | | Bevezetés a kriptóba | [ConSensys: A web3 helyzete világszerte 2023-ban](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | | Bevezetés a kriptóba | [NEAR: Az elfogadás felé vezető út felgyorsítása](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | +| Letétbe helyezés | [OpenUX: Rocket Pool csomópont-operátor UX](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | | Letétbe helyezés | [Staking: Főbb trendek, tanulságok és előrejelzések – Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | | Letétbe helyezés | [Többalkalmazásos letétbe helyezés](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | | DAO | [2022-es DAO-kutatás frissítése: Mire van szüksége a DAO-építőknek?](https://blog.aragon.org/2022-dao-research-update/) | @@ -48,6 +50,11 @@ Ez a web3-ban végzett felhasználói kutatások válogatott listája, amely seg - [Neueux.com](https://neueux.com/apps) – UI-könyvtár felhasználói folyamatok változatos szűrési lehetőségekkel - [A web3 használhatóságának válsága: Amit tudnia kell!](https://www.youtube.com/watch?v=oBSXT_6YDzg) – Panelbeszélgetés a fejlesztőközpontú projektépítés buktatóiról (videó, 34 perc) +## Első lépések {#getting-started} + +- [Heurisztika a web3-hoz](/developers/docs/design-and-ux/heuristics-for-web3/) - 7 heurisztika a web3-interfész dizájnjához +- [DEX dizájn bevált gyakorlatok](/developers/docs/design-and-ux/dex-design-best-practice/) - Útmutató a decentralizált tőzsdék tervezéséhez + ## Web3-tervezési esettanulmányok {#design-case-studies} - [Deep Work Studio](https://deepwork.studio/case-studies/) diff --git a/public/content/translations/hu/developers/docs/gas/index.md b/public/content/translations/hu/developers/docs/gas/index.md index 63108600ca5..7d839ae7b4b 100644 --- a/public/content/translations/hu/developers/docs/gas/index.md +++ b/public/content/translations/hu/developers/docs/gas/index.md @@ -122,6 +122,7 @@ A második blokkláncréteggel (L2) kialakított skálázás a fő kezdeményez Ha Ön szeretné felügyelni a gázdíjakat azért, hogy kevesebbet kelljen fizetnie az ETH-tranzakciókért, akkor számos eszköz áll rendelkezésre: - [Etherscan](https://etherscan.io/gastracker) _ Tranzakció gázdíjának becslése_ +- [ETH Gas Tracker](https://www.ethgastracker.com/) _Figyeli és kövesti az Ethereum és az L2 gázárakat a tranzakciós díjak csökkentése és a pénzmegtakarítás érdekében_ - [Blocknative ETH gázbecslés](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Gázbecslő Chrome-kiterjesztés, amely támogatja az eredeti (0. típusú) és az EIP-1559 (2. típusú) tranzakciókat._ - [Cryptoneur gázdíjkalkulátor](https://www.cryptoneur.xyz/gas-fees-calculator) _Számolja ki a gázdíjat a saját pénznemében a különféle tranzakciókra az Ethereum főhálózatán, az Arbitrumon és a Polygonon._ diff --git a/public/content/translations/hu/developers/docs/intro-to-ether/index.md b/public/content/translations/hu/developers/docs/intro-to-ether/index.md index 2d9e3eaf271..12b283273ac 100644 --- a/public/content/translations/hu/developers/docs/intro-to-ether/index.md +++ b/public/content/translations/hu/developers/docs/intro-to-ether/index.md @@ -26,7 +26,7 @@ Az ether kriptovaluta segíti az árazási mechanizmust az Ethereum számítóg Ezért még ha egy rosszindulatú dapp egy végtelen körforgást indítana is el, a tranzakció végül kifogyna az etherből és leállna, így a hálózat visszatér a normális állapotba. -[Gyakori](https://www.reuters.com/article/us-crypto-currencies-lending-insight-idUSKBN25M0GP#:~:text=price%20of%20ethereum) [az, hogy](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845#:~:text=cryptocurrencies%20including%20ethereum) [összekapcsolják](https://www.cnn.com/2021/03/14/tech/nft-art-buying/index.html#:~:text=price%20of%20ethereum) az Ethereumot és az ethert – amikor az emberek az Ethereum árára gondolnak, akkor az ethernek az árát értik rajta. +[Gyakori az, hogy összekapcsolják](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) az Ethereumot és az ethert – amikor az emberek az Ethereum árára gondolnak, akkor az ethernek az árát értik alatta. ## Az ether létrehozása (minting) {#minting-ether} diff --git a/public/content/translations/hu/developers/docs/mev/index.md b/public/content/translations/hu/developers/docs/mev/index.md index 3006e43b4e8..44c822f2089 100644 --- a/public/content/translations/hu/developers/docs/mev/index.md +++ b/public/content/translations/hu/developers/docs/mev/index.md @@ -122,7 +122,7 @@ Amint azt kifejtettük, a MEV negatív hatással van az általános felhasznál A Beolvadás utáni Ethereumban a validátorok (miután 32 ETH értékű letétet helyeztek el) konszenzusra jutnak a Beacon lánchoz hozzáadott blokkok érvényességéről. A 32 ETH sokak számára elérhetetlen lehet, ezért megvalósíthatóbb[ egy letéti alaphoz való csatlakozás ](/staking/pools/). Mindazonáltal az [önálló letétbe helyezők](/staking/solo/) egészséges eloszlása ideális, mivel enyhíti a validátorok centralizációját és javítja az Ethereum biztonságát. -A MEV-kivonás vélhetően képes felgyorsítani a validátorok centralizációját. Ez részben azért van így, mert a validátorok [kevesebbet kapnak a blokkelőterjesztésért](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply), mint korábban a bányászatért, a MEV-kivonás jelentősen [befolyásolhatja a validátorok bevételeit](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb) a Beolvadás után. +A MEV-kivonás vélhetően képes felgyorsítani a validátorok centralizációját. Ez részben azért van így, mert a validátorok [kevesebbet kapnak a blokkelőterjesztésért](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply), mint korábban a bányászatért, a MEV-kivonás jelentősen [befolyásolhatja a validátorok bevételeit](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb) a [Beolvadás](/roadmap/merge/) után. A nagyobb letéti alapok valószínűleg több erőforrással rendelkeznek ahhoz, hogy befektessenek a MEV-lehetőségek kihasználásához szükséges optimalizálásokba. Minél több MEV-t termelnek ki ezek a poolok, annál több erőforrásuk van ennek fejlesztésére (és a bevétel növelésére), ami [méretgazdaságosságot](https://www.investopedia.com/terms/e/economiesofscale.asp#) eredményez. @@ -136,13 +136,13 @@ Ennek az elrendezésnek egy nagyobb változatai a „sötét alapok”, melyek e Az engedélyhez kötött memóriakészletek az előző szakaszban leírt centralizációs kockázatokat is felgyorsítják. A több validátort működtető nagy alapok valószínűleg profitálni fognak abból, hogy a kereskedők és a felhasználók számára tranzakciós adatvédelmet kínálnak, növelve ezzel a MEV-bevételeiket. -Ezeknek a MEV-hez kapcsolódó problémáknak a leküzdése a Beolvadás utáni Ethereumban a kutatás egyik fő területe. Két megoldás merült fel, hogy a MEV negatív hatását csökkentsék az Ethereum decentralizációja és biztonsága szempontjából a Beolvadás után: **javaslattevő-építő szétválasztása (PBS)** és az **építő API**. +Ezeknek a MEV-hez kapcsolódó problémáknak a leküzdése a Beolvadás utáni Ethereumban a kutatás egyik fő területe. Két megoldás merült fel, hogy a MEV negatív hatását csökkentsék az Ethereum decentralizációja és biztonsága szempontjából a Beolvadás után: [**javaslattevő-építő szétválasztása (PBS)**](/roadmap/pbs/) és az [**építő API**](https://github.com/ethereum/builder-specs). ### Javaslattevő-építő szétválasztása (PBS) {#proposer-builder-separation} Mind a proof-of-work, mind a proof-of-stake esetében egy csomópont építi a blokkot, majd javasolja azt a konszenzusban részt vevő többi csomópontnak a láncba való felvételre. Egy új blokk akkor válik a kanonikus lánc részévé, ha egy másik bányász ráépít (PoW esetén), vagy ha a validátorok többségétől tanúsítást kap (PoS esetén). -A blokképítő és blokkajánló szerepek kombinációja az, ami a legtöbb MEV-hez kapcsolódó problémát okozza. A konszenzuscsomópontokat például arra ösztönzik, hogy a MEV-bevételek maximalizálása érdekében időzített támadásokban láncátrendezéseket indítsanak el. +A blokképítő és blokkajánló szerepek kombinációja az, ami a legtöbb MEV-hez kapcsolódó problémát okozza. A konszenzuscsomópontokat például arra ösztönzik, hogy a MEV-bevételek maximalizálása érdekében [időzített támadásokban](https://www.mev.wiki/attack-examples/time-bandit-attack) láncátrendezéseket indítsanak el. A [javaslattevő-építő szétválasztása (PBS)](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) a MEV hatásának mérséklésére szolgál, különösen a konszenzusrétegben. A PBS fő jellemzője a blokképítő és a blokkelőterjesztő szabályainak szétválasztása. A validátorok továbbra is felelősek a blokkok előterjesztéséért és az azokra vonatkozó szavazásért, de a tranzakciók elrendezése és a blokkok építése egy új, specializált entitás, a **blokképítő** feladata. @@ -180,7 +180,7 @@ Az alábbiakban látható az építő API működése: 5. Az építő API-t használó validátortól továbbra is elvárják, hogy helyben építsen blokkot, ha a blokképítő nem válaszol azonnal, így nem marad le a blokkjavaslatok jutalmáról. A validátor azonban nem hozhat létre egy másik blokkot a felfedett tranzakciókkal vagy egy másik adaggal, mivel ez _kétértelműség_ lenne (két blokk aláírása egy sloton belül), ami szabálysértésnek minősül. -Az építő API egyik példája a [MEV Boost](https://github.com/flashbots/mev-boost), a [Flashbots aukciós mechanizmus](https://docs.flashbots.net/Flashbots-auction/overview/) továbbfejlesztése, amelynek célja a MEV negatív hatásainak csökkentése az Ethereumban. A Flashbots aukció lehetővé teszi a proof-of-stake mechanizmusban a validátorok számára, hogy a nyereséges blokkok építését specializált **keresőknek** adják ki. +Az építő API egyik példája a [MEV Boost](https://github.com/flashbots/mev-boost), a [Flashbots aukciós mechanizmus](https://docs.flashbots.net/Flashbots-auction/overview/) továbbfejlesztése, amelynek célja a MEV negatív hatásainak csökkentése az Ethereumban. A Flashbots aukció lehetővé teszi a proof-of-stake mechanizmusban a validátorok számára, hogy a nyereséges blokkok építését specializált **keresőknek** adják ki. ![Egy diagram, amely a MEV áramlását mutatja be részleteiben](./mev.png) A keresők jövedelmező MEV-lehetőségeket keresnek, és tranzakciós csomagokat küldenek a blokkelőterjesztőknek egy [lepecsételt árú ajánlattal](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) együtt a blokkba való felvételre. A mev-geth-et, a go-ethereum (Geth) kliens elágaztatott változatát futtató validátornak csak ki kell választania a legnagyobb nyereséget hozó köteget, és azt az új blokk részévé kell tennie. A blokkelőterjesztők (validátorok) spamektől és érvénytelen tranzakcióktól való védelme érdekében a tranzakciókötegeket **közvetítők (relayer)** ellenőrzik, mielőtt azok eljutnak az előterjesztőhöz. diff --git a/public/content/translations/hu/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/hu/developers/docs/networking-layer/portal-network/index.md index c9184037216..ef98d696462 100644 --- a/public/content/translations/hu/developers/docs/networking-layer/portal-network/index.md +++ b/public/content/translations/hu/developers/docs/networking-layer/portal-network/index.md @@ -59,7 +59,13 @@ Ennek a hálózati dizájnnak az előnyei: Az alábbi ábra a meglévő kliensek azon funkcióit mutatja be, amelyeket a Portal Network biztosíthat, lehetővé téve a felhasználók számára, hogy ezeket a funkciókat nagyon alacsony erőforrásigényű eszközökön is elérjék. -![portal network táblázat](portal-network-table2.png) +### A Portal Network hálózatok + +| Beacon könnyű kliens | Státuszhálózat | Tranzakciópletyka | Előzményadatok hálózata | +| -------------------- | -------------------------- | --------------------- | ----------------------- | +| Beacon lánc könnyű | Számla- és szerződéstároló | Könnyű memóriakészlet | Fejlécek | +| Protokolladatok | | | Blokktestek | +| | | | Visszaigazolások | ## Alapértelmezett kliensdiverzitás {#client-diversity-as-default} @@ -70,7 +76,7 @@ A Portal Network kliensei a következők: - [Trin](https://github.com/ethereum/trin): Rust nyelven írva - [Fluffy](https://nimbus.team/docs/fluffy.html): Nim nyelven írva - [Ultralight](https://github.com/ethereumjs/ultralight): Typescript nyelven írva -- [Shisui](https://github.com/GrapeBaBa/shisui): Go nyelven írva +- [Shisui](https://github.com/optimism-java/shisui): Go nyelven írva A több független kliensimplementáció növeli az Ethereum-hálózat rugalmasságát és decentralizációját. diff --git a/public/content/translations/hu/developers/docs/networks/index.md b/public/content/translations/hu/developers/docs/networks/index.md index 0e16c6f5cc0..7412237f931 100644 --- a/public/content/translations/hu/developers/docs/networks/index.md +++ b/public/content/translations/hu/developers/docs/networks/index.md @@ -91,7 +91,7 @@ A Goerli egy olyan teszthálózat, ahol a validálást és a letétbe helyezést - [Coinbase Wallet csap | Goerli](https://coinbase.com/faucets/ethereum-goerli-faucet) - [Chainstack Goerli csap](https://faucet.chainstack.com/goerli-faucet) -Ha szeretne egy validátort indítani a Goerli teszthálózaton, akkor használja az ethstaker [olcsó goerli validátor launchpad-et](https://holesky.launchpad.ethstaker.cc/en/). +Ha szeretne egy validátort indítani a Holesky teszthálózaton, akkor használja az ethstaker [„olcsó Holesky validátor” indítópultot](https://holesky.launchpad.ethstaker.cc/en/). ### Második blokkláncréteg (L2) teszthálózatok {#layer-2-testnets} diff --git a/public/content/translations/hu/developers/docs/nodes-and-clients/client-diversity/index.md b/public/content/translations/hu/developers/docs/nodes-and-clients/client-diversity/index.md index 46f69dc9e0a..5d4aefd9826 100644 --- a/public/content/translations/hu/developers/docs/nodes-and-clients/client-diversity/index.md +++ b/public/content/translations/hu/developers/docs/nodes-and-clients/client-diversity/index.md @@ -31,7 +31,7 @@ A kliensdiverzitás nagyobb ellenállást jelent a támadásokkal szemben. Péld Egy olyan hiba a konszenzusos kliensben, amely az Ethereum-csomópontok több mint 33%-át érinti, meg tudja akadályozni azt, hogy a konszenzusréteg véglegesedjen, tehát a felhasználók nem tudhatják, hogy a tranzakcióik nem lesznek visszaforgatva vagy megváltoztatva valamikor. Ez rendkívül problémás helyzet az Ethereumra épült alkalmazások számára, főleg a decentralizált pénzügy (DeFi) területén. - Még ennél is rosszabb, ha egy kétharmados többséggel bíró kliensben történik hiba, ami miatt a lánc hibásan szétválik és véglegesedik, így a validátorok egy jó része egy valótlan láncon ragad. Ha ezek a validátorok újra a helyes lánchoz akarnának csatlakozni, akkor súlyos büntetéssel, vagy egy lassú és költséges visszavonási és újraaktviálási folyamattal néznének szembe. A súlyos büntetés mértéke arányos a kétharmados többség hibás csomópontjainak számával, melynek a letétjét (32 ETH) teljesen megsemmisítik. + Még ennél is rosszabb, ha egy kétharmados többséggel bíró kliensben történik hiba, ami miatt a lánc hibásan szétválik és véglegesedik, így a validátorok egy jó része egy valótlan láncon ragad. Ha ezek a validátorok újra a helyes lánchoz akarnának csatlakozni, akkor súlyos büntetéssel, vagy egy lassú és költséges visszavonási és újraaktviálási folyamattal néznének szembe. A súlyos büntetés mértéke arányos a kétharmados többség hibás csomópontjainak számával, melynek a letétjét (32 ETH) teljesen megsemmisítik. Habár ezek nem valószínű szcenáriók, az Ethereum ökoszisztémája képes a kockázatot csökkenteni azzal, hogy az aktív csomópontokon keresztül egyenlően oszlanak el a kliensek. Ideális esetben a teljes csomópontok 33%-át nem dominálja egy adott konszenzusos kliens. diff --git a/public/content/translations/hu/developers/docs/nodes-and-clients/index.md b/public/content/translations/hu/developers/docs/nodes-and-clients/index.md index 33afa2268bb..96cae2ec293 100644 --- a/public/content/translations/hu/developers/docs/nodes-and-clients/index.md +++ b/public/content/translations/hu/developers/docs/nodes-and-clients/index.md @@ -46,6 +46,7 @@ Az Ethereum-hálózat csomópontjairól számos trekker biztosít valós idejű - [Csomóponttérkép](https://etherscan.io/nodetracker), készítette: Etherscan - [Ethercsomópontok](https://ethernodes.org/), készítette: Bitfly - [Nodewatch](https://www.nodewatch.io/), készítette: Chainsafe, konszenzuscsomópontok letapogatása +- [Monitoreth](https://monitoreth.io/) - a MigaLabs által biztosított megosztott hálózati ellenőrzési eszköz ## Csomóponttípusok {#node-types} @@ -197,6 +198,7 @@ Többféle konszenzusos kliens (korábbi nevén „Eth2” kliens) is létezik, | [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia, Ropsten stb. | | [Prysm](https://docs.prylabs.network/docs/getting-started/) | Go | Linux, Windows, macOS | Beacon Chain, Gnosis, Goerli, Pyrmont, Sepolia, Ropsten stb. | | [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | Beacon Chain, Gnosis, Goerli, Sepolia, Ropsten stb. | +| [Grandine](https://docs.grandine.io/) (béta) | Rust | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia és mások | ### Lighthouse {#lighthouse} @@ -230,6 +232,12 @@ A Teku nagyon rugalmas alkalmazási opciókat kínál. A Beacon-csomópont és a A Teku Java nyelven íródott és az Apache 2.0 licenc alatt fut. A ConsenSys Protocols csapata fejleszti, amely a Besu és a Web3Signer fejlesztője is. További információk a [Teku-dokumentációban](https://docs.teku.consensys.net/en/latest/) találhatók. +### Grandine {#grandine} + +A Grandine egy konszenzuskliens-implementáció, amelyet Rust nyelven írtak, és a GPL-3.0 licenc alatt adták ki. Fenntartója a Grandine központi csapata, továbbá gyors, nagy teljesítményre képes és könnyű. A letétbe helyezők széles skálájához illeszkedik, a kis erőforrásigényű eszközökön, például Raspberry Pi-n futó egyéni letétbe helyezőktől kezdve a több tízezer validálót futtató, nagy intézményi letétesekig. + +A dokumentációt a [Grandine Book](https://docs.grandine.io/) tartalmazza + ## Szinkronizálási módok {#sync-modes} Ahhoz, hogy az Ethereum-kliens az aktuális adatokat kövesse és hitelesítse a hálózaton, szinkronizálnia kell a legfrissebb hálózati státusszal. Ez úgy történik, hogy adatokat tölt le többi klienstől, kriptográfiailag ellenőrzi azok integritását, és felépít egy helyi blokkláncadatbázist. diff --git a/public/content/translations/hu/developers/docs/nodes-and-clients/light-clients/index.md b/public/content/translations/hu/developers/docs/nodes-and-clients/light-clients/index.md index 0a522b6b9a1..5ba397e43bf 100644 --- a/public/content/translations/hu/developers/docs/nodes-and-clients/light-clients/index.md +++ b/public/content/translations/hu/developers/docs/nodes-and-clients/light-clients/index.md @@ -44,7 +44,7 @@ Számos könnyű klienst fejlesztenek, beleértve a végrehajtási, konszenzusos - [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): konszenzusos könnyű kliens TypeScript-ben - [Helios](https://github.com/a16z/helios): kombinált végrehajtási és konszenzusos könnyű kliens Rust-ban -- [Geth](https://github.com/ethereum/go-ethereum/tree/master/light): a végrehajtási kliens könnyű módozata (fejlesztés alatt áll) Go-ban +- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): a végrehajtási kliens könnyű módozata (fejlesztés alatt áll) Go-ban - [Nimbus](https://nimbus.guide/el-light-client.html): konszenzusos könnyű kliens Nim-ben Tudomásunk szerint ezek még nem állnak készen az éles használatra. diff --git a/public/content/translations/hu/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/hu/developers/docs/scaling/optimistic-rollups/index.md index 441912d26df..522182424e0 100644 --- a/public/content/translations/hu/developers/docs/scaling/optimistic-rollups/index.md +++ b/public/content/translations/hu/developers/docs/scaling/optimistic-rollups/index.md @@ -253,6 +253,12 @@ Az [adat sharding](/roadmap/danksharding/) bevezetése az Ethereumban várhatóa +### Optimista összevont tranzakciók használata {#use-optimistic-rollups} + +Az optimista összevont tranzakcióknak többféle megvalósítása létezik, amelyeket integrálhat a dappjaiba: + + + ## További információk az optimista összevont tranzakciókról - [Hogyan működnek az optimista összevont tranzakciók (teljes útmutató)](https://www.alchemy.com/overviews/optimistic-rollups) diff --git a/public/content/translations/hu/developers/docs/scaling/state-channels/index.md b/public/content/translations/hu/developers/docs/scaling/state-channels/index.md new file mode 100644 index 00000000000..257a88b9257 --- /dev/null +++ b/public/content/translations/hu/developers/docs/scaling/state-channels/index.md @@ -0,0 +1,67 @@ +--- +title: Státuszcsatornák +description: Bevezetés a státusz- és fizetési csatornákba, az Ethereum közössége által használt skálázási megoldásba. +lang: hu +sidebarDepth: 3 +--- + +A státuszcsatornák lehetővé teszik a résztvevők számára, hogy biztonságosan tranzakciókat bonyolítsanak le a láncon kívül, miközben minimálisra csökkentik az Ethereum főhálózattal való interakciót. A csatornát alkotó résztvevők tetszőleges számú, a láncon kívüli tranzakciót hajthatnak végre, melyhez csak két láncon belüli tranzakciót kell beküldeniük csatorna megnyitásához és lezárásához. Ez rendkívül nagy tranzakcióátvitelt tesz lehetővé, és alacsonyabb költségeket eredményez a felhasználók számára. + +## {#how-do-sidechains-work} + +A nyilvános blokkláncok, mint például az Ethereum, az elosztott architektúrájuk miatt skálázhatósági kihívásokkal küzdenek: a láncban végrehajtott tranzakciókat az összes csomópontnak végre kell hajtania. A csomópontoknak képesnek kell lenniük arra, hogy egy blokkban lévő tranzakciók mennyiségét szerény hardverrel kezeljék, hogy a hálózat decentralizált maradjon, de ez korlátozza a tranzakcióátviteli sebességet. + +### {#consensus-algorithms} + +A csatornák olyan egyszerű társközi (peer-to-peer) protokollok, amelyek lehetővé teszik, hogy két fél számos tranzakciót hajtson végre egymás között, és csak a végeredményt tegyék fel a blokkláncra. A csatorna kriptográfiát használ annak bizonyítására, hogy az általuk generált összesített adatok valóban érvényes köztes tranzakciók eredményei. Egy [több aláírásos](/developers/docs/smart-contracts/#multisig) okosszerződés biztosítja, hogy a tranzakciókat a megfelelő felek írják alá. + +- []() +- []() +- + +A csatornák segítségével a státuszváltozásokat az érdekelt felek hajtják végre és érvényesítik, minimalizálva az Ethereum végrehajtási rétegének számításait. Ez csökkenti a torlódásokat az Ethereumon, és növeli a tranzakciók feldolgozási sebességét a felhasználók számára. + +#### {#block-parameters} + +Minden csatornát egy [több aláírásos okosszerződés](/developers/docs/smart-contracts/#multisig) kezel, amely az Ethereumon fut. Egy csatorna megnyitásához a résztvevők telepítik a csatornaszerződést a láncban, és pénzt helyeznek el benne. + +A csatorna lezárásához a résztvevők elküldik a csatorna utolsó elfogadott státuszát a láncba. Ezt követően az okosszerződés a zárolt pénzeszközöket az egyes résztvevőknek a csatorna végső státuszában lévő egyenlege szerint osztja szét. + +A peer-to-peer csatornák különösen hasznosak olyan helyzetekben, amikor néhány előre meghatározott résztvevő nagy gyakorisággal kíván tranzakciókat lebonyolítani anélkül, hogy az többletterhekkel járna. A blokklánc-csatornák két kategóriába sorolhatók: **fizetési** és **státuszcsatornák**. + +### {#evm-compatibility} + +A fizetési csatornát leginkább úgy lehet leírni, mint két felhasználó által közösen vezetett „kétirányú főkönyvet”. A főkönyv kezdeti egyenlege a csatornanyitási fázisban a láncban lévő szerződésbe zárolt betétek összege. + +A főkönyv egyenlegének (azaz a fizetési csatorna státuszának) frissítéséhez a csatorna összes résztvevőjének jóváhagyása szükséges. A csatorna résztvevői által aláírt csatornaváltozás véglegesítettnek tekinthető, hasonlóan az Ethereumban végrehajtott tranzakciókhoz. + +A fizetési csatornák a legkorábbi skálázási megoldások közé tartoztak, amelyek célja az egyszerű felhasználói interakciók (pl. ETH átutalások, atomikus átváltások, mikrofizetések) költséges láncon belüli tevékenységének minimalizálása volt. A csatorna résztvevői korlátlan mennyiségű azonnali, illeték nélküli tranzakciót hajthatnak végre egymás között mindaddig, amíg az átutalások nettó összege nem haladja meg a letétbe helyezett tokeneket. + +A láncon kívüli fizetések támogatásán kívül a fizetési csatornák nem bizonyultak hasznosnak az általános státuszváltozási logika kezelésére. A státuszcsatornákat azért hozták létre, hogy megoldják ezt a problémát, és azok támogassák az általános célú számítások skálázását. + +### {#asset-movement} + +A státuszcsatornáknak sok közös vonásuk van a fizetési csatornákkal. A felhasználók például kriptográfiailag aláírt üzenetek (tranzakciók) cseréjével lépnek kapcsolatba egymással, amelyeket a csatorna többi résztvevőjének is alá kell írnia. Ha egy javasolt státuszváltozást nem ír alá minden résztvevő, az érvénytelennek minősül. + +## {#pros-and-cons-of-sidechains} + +| | | +| | | +| | | +| | | +| | | +| | | + +### {#use-sidechains} + +- []() +- []() +- []() +- []() +- []() + +## {#further-reading} + +- + +_ _ diff --git a/public/content/translations/hu/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/hu/developers/docs/scaling/zk-rollups/index.md index 9e95a34dc42..4caff0bbfd0 100644 --- a/public/content/translations/hu/developers/docs/scaling/zk-rollups/index.md +++ b/public/content/translations/hu/developers/docs/scaling/zk-rollups/index.md @@ -222,6 +222,12 @@ Nézze meg a videót, melyben a Finematics elmagyarázza a ZK összevont tranzak +### ZK összevont tranzakciók használata {#use-zk-rollups} + +A ZK összevont tranzakcióknak többféle megvalósítása létezik, amelyeket integrálhat a dappjaiba: + + + ## Kik dolgoznak zkEVM-en? {#zkevm-projects} Többek között az alábbi projektek dolgoznak zkEVM-en: diff --git a/public/content/translations/hu/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/hu/developers/docs/standards/tokens/erc-777/index.md new file mode 100644 index 00000000000..69264f5cbbb --- /dev/null +++ b/public/content/translations/hu/developers/docs/standards/tokens/erc-777/index.md @@ -0,0 +1,77 @@ +--- +title: ERC-777 tokenszabvány +description: +lang: hu +--- + +## {#introduction} + +**** + +**** + +A hook vagy horog az okosszerződés kódjában leírt funkciót jelent. Akkor kerülnek meghívásra, amikor a szerződésen keresztül tokeneket küldenek vagy fogadnak. Ez lehetővé teszi, hogy az okosszerződés reagáljon a bejövő vagy kimenő tokenekre. + +## {#prerequisites} + +- []() +- []() +- []() + +## {#body} + +A horgokat az [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820)-as szabvány segítségével regisztrálják és fedezik fel. + +A szabvány megoldja az ERC-20-ban a `decimals` körül kialakult zavart is. Ez az egyértelműség javítja a fejlesztői élményt. + +Az ERC-777-es szerződésekkel úgy lehet interakcióba lépni, mintha ERC-20-as szerződések lennének. + +### {#methods} + +```solidity + +``` + +### {#events} + +```solidity + +``` + +### {#web3py-example} + +#### {#web3py-example} + +``` + +``` + +```python + + + + +``` + +```python + + +``` + +## {#popular-nfts} + +- +- +- +- +- +- +- +- + +## További olvasnivaló {#further-reading} + +- []() +- []() +- []() +- []() diff --git a/public/content/translations/hu/governance/index.md b/public/content/translations/hu/governance/index.md index 5eb94f3b7d5..dc047fa5bf4 100644 --- a/public/content/translations/hu/governance/index.md +++ b/public/content/translations/hu/governance/index.md @@ -48,7 +48,7 @@ Az [Ethereum-közösségben](/community/) számos érdekelt fél van, akik szere - **Csomópont-operátorok**: akik csomópontokat működtetnek, amelyek blokkokat és tranzakciókat javasolnak, illetve elutasítják az érvénytelen tranzakciókat vagy blokkokat. [Bővebben a csomópontokról](/developers/docs/nodes-and-clients/). - **EIP-szerzők**: ők javasolnak változásokat az Ethereum-protokollt illetően Ethereum fejlesztési javaslatok (EIP) formájában. [Bővebben az EIP-ekről](/eips/). - **Validátorok**: ők olyan csomópontokat futtatnak, melyek új blokkokat tudnak adni az Ethereum-blokklánchoz. -- **Protokollfejlesztők** (azaz „Magfejlesztők”): ők kezelik a különféle Ethereum-implementációkat (pl. go-ethereum, Nethermind, Besu, Erigon, Reth a végrehajtási rétegen; Prysm, Lighthouse, Nimbus, Teku, Lodestar a konszenzusrétegen). [Bővebben az Ethereum-kliensekről](/developers/docs/nodes-and-clients/). +- **Protokollfejlesztők** (azaz „Magfejlesztők” ): ők kezelik a különféle Ethereum-implementációkat (pl. go-ethereum, Nethermind, Besu, Erigon, Reth a végrehajtási rétegen; Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandine a konszenzusrétegen). [Bővebben az Ethereum-kliensekről](/developers/docs/nodes-and-clients/). _Megjegyzés: bárki lehet több csoport tagja is (pl. a protokollfejlesztő lehet EIP-bajnok is, futtathat Beaconlánc-validátort és használhat DeFi-alkalmazásokat). A koncepcionális egyértelműség miatt könnyebb, ha megkülönböztetjük őket._ diff --git a/public/content/translations/hu/nft/index.md b/public/content/translations/hu/nft/index.md index 5520f0b8f80..9784c538761 100644 --- a/public/content/translations/hu/nft/index.md +++ b/public/content/translations/hu/nft/index.md @@ -75,7 +75,7 @@ Ez a weboldal egy alternatív, NFT-k által működtetett domainnévvel is rende ## Hogyan működnek az NFT-k? {#how-nfts-work} -Az NFT-k, ahogy az Ethereum blokklánc többi digitális eszköze, egy speciális, Ethereum-alapú számítógépes program révén keletkeznek, amelyet okosszerződésnek neveznek. Ezek a szerződések bizonyos szabályokat követnek, például az [ERC-721](/glossary/#erc-721) vagy az [ERC-1155](/glossary/#erc-1155) szabványt, amelyek meghatározzák, hogy a szerződés mire képes. +Az NFT-k, ahogy az Ethereum-blokklánc többi digitális eszköze, egy speciális, Ethereum-alapú számítógépes program révén keletkeznek, amelyet okosszerződésnek neveznek. Ezek a szerződések bizonyos szabályokat követnek, például az [ERC-721](/glossary/#erc-721) vagy az [ERC-1155](/glossary/#erc-1155) szabványt, amelyek meghatározzák, hogy a szerződés mire képes. Az NFT-okosszerződésekkel számos fontos dolog végrehajtható: diff --git a/public/content/translations/hu/roadmap/verkle-trees/index.md b/public/content/translations/hu/roadmap/verkle-trees/index.md index c7e917c7fcc..2f608b229e9 100644 --- a/public/content/translations/hu/roadmap/verkle-trees/index.md +++ b/public/content/translations/hu/roadmap/verkle-trees/index.md @@ -49,9 +49,9 @@ A Verkle-fák `key, value` (kulcs, érték) párokból állnak, ahol a kulcsok 3 A Verkle-fa teszthálózatai már működnek, de jelentős mértékű kliensfrissítésre van még szükség ahhoz, hogy támogatni tudják ezt az adatstruktúrát. Ön is segíthet a fejlesztés meggyorsításában, ha szerződéseket hoz létre a teszthálózaton és klienseket működtet a teszthez. -[Fedezze fel a Verkle Gen Devnet 2 teszthálózatot](https://verkle-gen-devnet-2.ethpandaops.io/) +[Fedezze fel a Verkle Gen Devnet 6 teszthálózatot](https://verkle-gen-devnet-6.ethpandaops.io/) -[Tekintse meg, ahogy Guillaume Ballet bemutatja a Condrieu Verkle-teszthálózatot](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (a Condrieu teszthálózat még a proof-of-work mechanizmus szerint működött, és mára már Verkle Gen Devnet 2 teszthálózat váltotta fel). +[Nézze meg, ahogy Guillaume Ballet bemutatja a Condrieu Verkle-teszthálózatot](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (a Condrieu teszthálózat még a proof-of-work mechanizmus szerint működött, és mára már Verkle Gen Devnet 6 teszthálózat váltotta fel). ## További olvasnivaló {#further-reading} diff --git a/public/content/translations/hu/security/index.md b/public/content/translations/hu/security/index.md index d1a91fb5728..d339da19853 100644 --- a/public/content/translations/hu/security/index.md +++ b/public/content/translations/hu/security/index.md @@ -8,6 +8,8 @@ lang: hu A kriptopénzek iránti növekvő érdeklődés egyre nagyobb kockázatot jelent a csalók és a hackerek részéről. Ez a cikk néhány bevált gyakorlatot mutat be e kockázatok mérséklésére. +**Ne feledje: Az ethereum.org sosem lép Önnel kapcsolatba. Ne válaszoljon azokra az e-mailekre, amelyek azt állítják, hogy az Ethereum hivatalos támogatói csapatától érkeznek.** + ## Kriptobiztonság 101 {#crypto-security} diff --git a/public/content/translations/hu/staking/solo/index.md b/public/content/translations/hu/staking/solo/index.md index da1120dbd59..d011301a23b 100644 --- a/public/content/translations/hu/staking/solo/index.md +++ b/public/content/translations/hu/staking/solo/index.md @@ -1,6 +1,6 @@ --- -title: Önálló letétbe helyezés -description: Az önálló letétbe helyezés áttekintése +title: Egyéni letétbe helyezés +description: Az egyéni letétbe helyezés áttekintése lang: hu template: staking emoji: ":money_with_wings:" @@ -13,31 +13,31 @@ summaryPoints: - Nem kell másban megbíznia, és az eszközeihez tartozó kulcsok mindig az Ön kontrollja alatt állnak --- -## Mi az az önálló letétbe helyezés? {#what-is-solo-staking} +## Mi az az egyéni letétbe helyezés? {#what-is-solo-staking} -Az önálló letétbe helyezés (solo staking) során a felhasználó egy [Ethereum csomópontot működtet](/run-a-node/) az internethez csatlakozva, letétbe helyez 32 ETH-t, hogy aktiváljon egy [validátort](#faq), így közvetlenül részt tud venni a hálózat konszenzusfolyamatában. +Az egyéni letétbe helyezés során a felhasználó egy [Ethereum-csomópontot működtet](/run-a-node/) az internethez csatlakozva, letétbe helyez 32 ETH-t, hogy aktiváljon egy [validátort](#faq), így közvetlenül részt tud venni a hálózat konszenzusfolyamatában. -**Az önálló letétbe helyezés növeli az Ethereum hálózatának decentralizációját**, így az ellenállóbb lesz a cenzúrával és a támadásokkal szemben. A többi letétbe helyezési módszer nem feltétlen segíti a hálózatot ugyanilyen módon. Az önálló letétbe helyezés a legjobb letéti opció az Ethereum biztosítására. +**Az egyéni letétbe helyezés növeli az Ethereum hálózatának decentralizációját**, így az ellenállóbb lesz a cenzúrával és a támadásokkal szemben. A többi letétbe helyezési módszer nem feltétlen segíti a hálózatot ugyanilyen módon. Az egyéni letétbe helyezés a legjobb letéti opció az Ethereum biztosítására. Az Ethereum-csomópontot egy végrehajtási réteg (EL) klienst és egy konszenzus réteg (CL) klienst tartalmaz. Ezek a kliensek olyan szoftverek, amelyek együtt dolgoznak egy érvényes aláírókulcs-készlettel együtt, hogy érvényesítsék a tranzakciókat és a blokkokat, tanúsítsák a lánc státuszát, aggregálják a tanúsítványokat és blokkokat javasoljanak. -Az önálló letétbe helyezők azért felelnek, hogy a kliensek futásához szükséges hardvert működtetik. Azt javasoljuk, hogy erre egy dedikált gépet használjanak, melyet otthonról üzemeltetnek, mert ez rendkívül hasznos a hálózat egészsége szempontjából. +Az egyéni letétbe helyezők azért felelnek, hogy a kliensek futásához szükséges hardvert működtetik. Azt javasoljuk, hogy erre egy dedikált gépet használjanak, melyet otthonról üzemeltetnek, mert ez rendkívül hasznos a hálózat egészsége szempontjából. -Az önálló letétbe helyező közvetlenül a protokolltól kap jutalmakat azért, hogy a validátora megfelelően működik és online van. +Az egyéni letétbe helyező közvetlenül a protokolltól kap jutalmakat azért, hogy a validátora megfelelően működik és online van. -## Miért legyek önálló letétbe helyező? {#why-stake-solo} +## Miért legyek egyéni letétbe helyező? {#why-stake-solo} -Az önálló letétbe helyezés több felelősséggel jár, de teljes kontrollt biztosít a pénzeszközök és a staking felállítás felett. +Az egyéni letétbe helyezés több felelősséggel jár, de teljes kontrollt biztosít a pénzeszközök és a staking felállítás felett. - + -## Megfontolások, mielőtt belevágna az önálló stakingbe {#considerations-before-staking-solo} +## Megfontolandó dolgok, mielőtt belevágna az egyéni letétbe helyezésbe {#considerations-before-staking-solo} -Bármennyire is szeretnénk, hogy az önálló letétbe helyezés elérhető és kockázatmentes legyen mindenkinek, ez nem a valóság. Mielőtt belevágna, komoly gyakorlati megfontolásokkal kell szembenéznie. +Bármennyire is szeretnénk, hogy az egyéni letétbe helyezés elérhető és kockázatmentes legyen mindenkinek, ez nem lehet elérni. Mielőtt belevágna, komoly gyakorlati megfontolásokkal kell szembenéznie. @@ -93,7 +93,7 @@ A Staking Launchpad egy nyílt forráskódú alkalmazás, ami segít a letétbe ## Mit kell figyelembe venni a csomópont- és kliensbeállító eszközöknél {#node-tool-considerations} -Az önálló letétbe helyezést segítő eszközök és szolgáltatások száma egyre növekszik, de mindnél áll fent kockázat, és ugyanúgy mind előnyökkel is jár. +Az egyéni letétbe helyezést segítő eszközök és szolgáltatások száma egyre növekszik, de mindnél áll fenn kockázat, ugyanúgy mind előnyökkel is jár. Alább különböző jellemzők mentén mutatjuk be a jelentős erősségeket vagy gyengeségeket, melyekkel a listázott letéti eszközök rendelkezhetnek. Ez alapján Ön is megértheti, hogy e jellemzőket hogyan határoztuk meg, és így könnyebben választhat a szükséges eszközök közül. @@ -119,7 +119,7 @@ Ezek alternatív eszközök a [Staking Deposit CLI](https://github.com/ethereum/ Hiányolja valamelyik letétbe helyezési eszközt? Ha a [terméklistázó szabályzat](/contributing/adding-staking-products/) alapján úgy véli, hogy egy adott eszköz illeszkedne ide, akkor jelezze felénk. -## Nézze meg az önálló letétbe helyezés útmutatóit {#staking-guides} +## Nézze meg az egyéni letétbe helyezésre vonatkozó útmutatókat {#staking-guides} @@ -138,7 +138,7 @@ A validátorhoz tartozó kulcspár pontosan 32 ETH összeget igényel ahhoz, ho Egy validátorhoz ne kössön le többet, mint 32 ETH. Ez nem hoz több nyereséget. A validátor-ellenőrzés során a 32 ETH feletti rész automatikusan átkerül a visszavonási címre, ha az be van állítva a validátorhoz. -Ha az önálló letétbe helyezés túl nagy erőfeszítést igényelne Öntől, akkor nézze meg a letétbe helyezés, mint szolgáltatás opcióit, vagy ha kevesebb mint 32 ETH összegről van szó, akkor fontolja meg a letéti alapok szolgáltatást. +Ha az egyéni letétbe helyezés túl nagy erőfeszítést igényelne Öntől, akkor nézze meg a letétbe helyezés, mint szolgáltatás opcióit, vagy ha kevesebb mint 32 ETH összegről van szó, akkor fontolja meg a letéti alapok szolgáltatást. @@ -203,4 +203,4 @@ A teljes egyenleg visszavonásához végig kell menni a validátorkiléptetési - [Lépésről lépésre: hogyan kell csatlakozni az Ethereum 2.0 teszthálózathoz](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) – _Butta_ - [Eth2 Slashing elkerülési tippek](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) – _Raul Jordan 2020._ - + diff --git a/src/intl/hu/glossary-tooltip.json b/src/intl/hu/glossary-tooltip.json index 68dbece27c6..374751649b7 100644 --- a/src/intl/hu/glossary-tooltip.json +++ b/src/intl/hu/glossary-tooltip.json @@ -96,7 +96,7 @@ "multisig-term": "Több aláírás", "multisig-definition": "A Multisig (többszörös aláírás) olyan digitális tárcára vagy számlára utal, amely több aláírást vagy jóváhagyást igényel a tranzakciók végrehajtásához, növelve ezzel a biztonságot.", "nft-term": "Nem helyettesíthető token (NFT)", - "nft-definition": "A nem helyettesíthető token (NFT) egy egyedi digitális tárgy, amely a blokklánc technológiával ellenőrzött, például műtárgyak vagy gyűjthető tárgyak. További információ a nem helyettesíthető tokenekről (NFT).", + "nft-definition": "Egy egyedi digitális tárgy, amelyet Ön birtokolhat, például műtárgyak vagy gyűjthető tárgyak, és amelyet blokklánc-technológiával igazolnak. További információ a nem helyettesíthető tokenekről (NFT).", "node-term": "Csomópont", "node-definition": "Egy szoftverkliens, mely részt vesz a hálózatban. Bővebben a csomópontokról és a kliensekről.", "ommer-term": "Ommer (nagybácsi) blokk", diff --git a/src/intl/hu/glossary.json b/src/intl/hu/glossary.json index 0ac681d244a..ff35482c0bb 100644 --- a/src/intl/hu/glossary.json +++ b/src/intl/hu/glossary.json @@ -252,7 +252,7 @@ "network-hashrate-term": "Hálózati hashráta", "network-hashrate-definition": "A teljes bányászati hálózat által létrehozott hashráta. Az Ethereumon a bányászatot (proof-of-work, munkaigazolás) leváltotta a proof-of-stake (letéti igazolás) rendszere.", "nft-term": "Nem helyettesíthető token (NFT)", - "nft-definition": "A nem helyettesíthető token (NFT) egy egyedi digitális tárgy, amely a blokklánc technológiával ellenőrzött, például műtárgyak vagy gyűjthető tárgyak. További információ a nem helyettesíthető tokenekről (NFT).", + "nft-definition": "Egy egyedi digitális tárgy, amelyet Ön birtokolhat, például műtárgyak vagy gyűjthető tárgyak, és amelyet blokklánc-technológiával igazolnak. További információ a nem helyettesíthető tokenekről (NFT).", "node-term": "Csomópont", "node-definition": "Egy szoftverkliens, mely részt vesz a hálózatban. Bővebben a csomópontokról és a kliensekről.", "nonce-term": "Nonce", diff --git a/src/intl/hu/learn-quizzes.json b/src/intl/hu/learn-quizzes.json index 763c61fa455..87a9ad6ebcb 100644 --- a/src/intl/hu/learn-quizzes.json +++ b/src/intl/hu/learn-quizzes.json @@ -523,5 +523,95 @@ "run-a-node-6-prompt": "Egy csomópont működtetése hálózati jutalmakat eredményez", "run-a-node-6-a-label": "Igaz", "run-a-node-6-a-explanation": "A kliensszoftver futtatásáért nem jár jutalom. A jutalmak érdekében letétbe helyezésre van szükség.", - "run-a-node-6-b-label": "Hamis" + "run-a-node-6-b-label": "Hamis", + "stablecoins-1-prompt": "Mik azok a stabil érmék?", + "stablecoins-1-a-label": "Kriptovaluták alacsony árfolyam-ingadozással, értékük állandó és hasonló a hagyományos valutákéhoz", + "stablecoins-1-a-explanation": "Helyes! A stabilérméket arra tervezték, hogy megoldják a volatilitási problémát, mely sok kriptovalutára jellemző.", + "stablecoins-1-b-label": "Az arany digitális reprezentációi", + "stablecoins-1-b-explanation": "Ez téves. Bár egyes stabilérmék mögött nemesfémek is állhatnak, ugyanakkor fiat valuta vagy más kriptovaluták is.", + "stablecoins-1-c-label": "Újfajta hitelkártya", + "stablecoins-1-c-explanation": "Ez téves. A stabiérmék egyfajta kriptovaluták, nem hitelkártyák.", + "stablecoins-1-d-label": "Az ether helyettesítője", + "stablecoins-1-d-explanation": "Ez téves. A stabilérme nem helyettesíti az ethert (ETH). Ezek az Ethereum hálózaton lévő olyan tokenek, melyek lényege az értékstabilitás.", + "stablecoins-2-prompt": "Az alábbiak közül melyik a stabilérme?", + "stablecoins-2-a-label": "Amerikai dollár", + "stablecoins-2-a-explanation": "Ez téves. Bár a stabilérmék reprezentálhatnak amerikai dollárt, de a dollár attól még nem kriptovaluta.", + "stablecoins-2-b-label": "AAVE token", + "stablecoins-2-b-explanation": "Ez téves. Az AAVE egy irányítási token az Aave protokoll számára, amely piactereket biztosít a stabil érméknek, de az AAVE maga nem egy stabil érme.", + "stablecoins-2-c-label": "Dai", + "stablecoins-2-c-explanation": "Helyes! Valószínűleg a Dai a leghíresebb decentralizált stabil érme, melynek értéke nagyjából egy dollár.", + "stablecoins-2-d-label": "Ether", + "stablecoins-2-d-explanation": "Ez téves. Az ether az Ethereum hálózat natív valutája, de ennek nem célja a stabilitás.", + "stablecoins-3-prompt": "Mire lehet a stabil érméket használni?", + "stablecoins-3-a-label": "A felhasználók védelme a volatilis árváltozásoktól", + "stablecoins-3-a-explanation": "Nem egészen. Ez a válasz részben helyes, de csak egy a sok dolog közül, amire a stabil érmék felhasználhatók.", + "stablecoins-3-b-label": "Vásárlás az interneten bárhol a világon", + "stablecoins-3-b-explanation": "Nem egészen. Ez a válasz részben helyes, de csak egy a sok dolog közül, amire a stabil érmék felhasználhatók.", + "stablecoins-3-c-label": "Pénzt keresni másoknak történő kölcsönadással", + "stablecoins-3-c-explanation": "Nem egészen. Ez a válasz részben helyes, de csak egy a sok dolog közül, amire a stabil érmék felhasználhatók.", + "stablecoins-3-d-label": "Az összes fenti állítás", + "stablecoins-3-d-explanation": "Helyes! A stabil érmék segítségével kisebb volatilitású kriptopénzeket lehet tartani, globális tranzakciókat lehet lebonyolítani az interneten, és kamatot lehet keresni, amikor kölcsönadja azokat.", + "stablecoins-4-prompt": "Mitől különleges a stabil érme?", + "stablecoins-4-a-label": "Ez egy olyan token, mely a való világban lévő eszközhöz van kapcsolva", + "stablecoins-4-a-explanation": "Ez téves. Bár sok stabil érme valós eszközökhöz van kötve, ez a tulajdonság nem kizárólag ezekre jellemző (pl. ETH-szel fedezett tokenek).", + "stablecoins-4-b-label": "Ez egy kriptovaluta-token, amelyet kifejezetten arra terveztek, hogy stabilan tartsa az értékét", + "stablecoins-4-b-explanation": "Helyes! A stabil érméket úgy tervezték, hogy viszonylag stabilan tartsák az értéküket, jellemzően olyan eszközökhöz kötve, mint a valuták (pl. 1 USDC = 1 amerikai dollár), de nem minden stabil érme követi ezt a modellt (pl. RAI).", + "stablecoins-4-c-label": "El lehet küldeni az interneten keresztül", + "stablecoins-4-c-explanation": "Ez téves. Bár ez lehetséges, de nem egyedi jellemzője a stabil érméknek.", + "stablecoins-4-d-label": "Használhatóak az Ethereum hálózaton.", + "stablecoins-4-d-explanation": "Ez téves. Számtalan más kriptovaluta-token használható az Ethereum hálózaton.", + "stablecoins-5-prompt": "Hogyan NEM lehet stabil érmét szerezni?", + "stablecoins-5-a-label": "Más tokenekre való átváltással", + "stablecoins-5-a-explanation": "Helytelen, ez egy módja annak, hogy stabil érméket szerezzünk. Az egyik leggyakoribb módja a stabil érmék megszerezésének, hogy a meglévő kriptovalutát arra váltják át.", + "stablecoins-5-b-label": "Kölcsönzéssel", + "stablecoins-5-b-explanation": "Helytelen, ez egy módja a stabil érmék megszerzésének. Úgy lehet kölcsönvenni stabil érmét, hogy a meglévő kriptovalutát, például az ethert használják fedezetként. A kölcsönvett stabil érmét vissza kell fizetni, hogy visszakapja a zárolt biztosítékot.", + "stablecoins-5-c-label": "Tőzsdén való megvásárlás", + "stablecoins-5-c-explanation": "Helytelen, ez egy módja a stabil érmék megszerzésének. Sok tőzsdén és tárcában közvetlenül lehet stabil érmét vásárolni. A központosított tőzsdék esetében földrajzi korlátozások lehetnek érvényben.", + "stablecoins-5-d-label": "Bányászással", + "stablecoins-5-d-explanation": "Helyes! A bitcoin-tól eltérően a stabil érméket nem lehet kibányászni.", + "defi-1-prompt": "Mit jelent a DeFi kifejezés?", + "defi-1-a-label": "Decentralizált pénzügy", + "defi-1-a-explanation": "Helyes! A DeFi kifejezés jelentése decentralizált pénzügy, egy Ethereumra épített pénzügyi rendszer, mely közvetítők, vagyis bankok vagy pénzügyi intézmények nélkül működik.", + "defi-1-b-label": "Digitális pénzügy", + "defi-1-b-explanation": "Ez téves. A digitális pénzügyek olyan pénzügyi szolgáltatásokra utalnak, amelyeket digitális platformokon keresztül nyújtanak, de ez nem jelent decentralizációt.", + "defi-1-c-label": "Eloszott pénzügy", + "defi-1-c-explanation": "Ez téves. Miközben az eloszott jelenthet decentralizációt, az iparág a decentralizált pénzügy kifejezést használja, nem pedig az elosztott pénzügyet.", + "defi-1-d-label": "Fejlesztési pénzügy", + "defi-1-d-explanation": "Ez téves. A fejlesztési pénzügy jellemzően a gazdasági fejlődést célzó, gyakran fejlődő országokban megvalósuló projektekhez nyújtott pénzügyi támogatásra utal, és nincs köze a blokklánchoz vagy a DeFi-hoz.", + "defi-2-prompt": "Mit NEM lehet csinálni a DeFi-ban?", + "defi-2-a-label": "Pénzküldés a világ bármelyik pontjára.", + "defi-2-a-explanation": "Ez téves. A DeFi-ban korlátlanul küldhet értéket bárkinek bárhol a világon.", + "defi-2-b-label": "Megkérni az ügyfélszolgálatot, hogy javítsa ki a tévesen végrehajtott dolgokat.", + "defi-2-b-explanation": "Helyes! A DeFi-ban a tranzakciók véglegesek, és nem egy vállalat, hanem a kód irányítja azokat. Ha hiba történik, például rossz címre küldenek pénzt, nincs ügyfélszolgálat, amely segítene a hiba kijavításában. Különösen óvatosnak kell lennie.", + "defi-2-c-label": "Kölcsönfelvétel fedezettel.", + "defi-2-c-explanation": "Ez téves. A DeFi-ban azonnal kölcsönt vehet fel, elkerülve a hagyományos bankok napokig tartó jóváhagyási folyamatát.", + "defi-2-d-label": "Kereskedés tokenekkel a hét minden napján, egész nap.", + "defi-2-d-explanation": "Ez téves. A DeFi lehetővé teszi, hogy a nap 24 órájában tokenekkel kereskedjen. A piacok mindig nyitva vannak, és bármikor kereskedhet a rendelkezésére álló ETH-szel USDT vagy bármely más valuta ellenében.", + "defi-3-prompt": "Melyik DeFi platform ismert arról, hogy a felhasználók a tokeneket egymás között közvetlenül cserélhetik?", + "defi-3-a-label": "Uniswap", + "defi-3-a-explanation": "Helyes! Az Uniswap egy decentralizált tőzsde, amely lehetővé teszi a felhasználók számára, hogy közvetlenül egymással kereskedjenek tokenekkel (átváltsák azokat), automatizált piacképző mechanizmusok segítségével.", + "defi-3-b-label": "Aave", + "defi-3-b-explanation": "Ez téves. Az Aave egy DeFi protokoll, amely a hitelezésre és kölcsönzésre összpontosít, nem pedig a tokenátváltásra.", + "defi-3-c-label": "PoolTogether", + "defi-3-c-explanation": "Ez téves. A PoolTogether veszteségmentes lottójátékokat üzemeltet, amelyek új, innovatív módját kínálják a pénzmegtakarításnak.", + "defi-3-d-label": "MakerDao", + "defi-3-d-explanation": "Ez téves. A MakerDAO egy decentralizált platform, amely lehetővé teszi a felhasználók számára a DAI stabil érme kibocsátását és kezelését, de nem a tokenátváltásra összpontosít.", + "defi-4-prompt": "Amikor egy DeFi alkalmazást használ és tranzakciót hajt végre, hol tárolják a tranzakció adatait?", + "defi-4-a-label": "ETH", + "defi-4-a-explanation": "Ez téves. Az adatokat nem az etherben (ETH) tárolják. Az ETH az Ethereum blokklánc natív eszköze.", + "defi-4-b-label": "Tárcámban", + "defi-4-b-explanation": "Ez téves. A tárca egy olyan alkalmazás, amely az Ethereum számláját kezeli az Ethereum blokkláncához való csatlakozással. Nem tárol semmilyen adatot az Ön tranzakciós előzményeiről.", + "defi-4-c-label": "DeFi alkalmazásokban", + "defi-4-c-explanation": "Ez téves. A DeFi alkalmazások nem tárolják közvetlenül a tranzakciós előzményeket. Ehelyett a tranzakciók adatait az Ethereum blokkláncán rögzítik.", + "defi-4-d-label": "Ethereum blokkláncban", + "defi-4-d-explanation": "Helyes! Az Ethereum mint blokklánc tárolja a felhasználók és az alkalmazások által készített összes adatot. Ez lehetővé teszi a validátorok számára, hogy ugyanazt az állapotot tartsák fenn a P2P-hálózatban.", + "defi-5-prompt": "Mi teszi lehetővé a decentralizált pénzügy (DeFi) meglétét az Ethereumon?", + "defi-5-a-label": "Okosszerződések", + "defi-5-a-explanation": "Helyes! Az okosszerződések olyanok, mint az Ethereumba írt digitális „ha-akkor” utasítások. Ezek helyettesítik a hagyományos szerződéseket és a közvetítőket, és bizonyos feltételek teljesülése esetén automatikusan végrehajtják a tranzakciókat.", + "defi-5-b-label": "Közvetítők", + "defi-5-b-explanation": "Ez téves. Az Ethereumnak nincs szüksége közvetítőkre a tranzakciók lebonyolításához. Minden a láncon fut az okosszerződéseken keresztül.", + "defi-5-c-label": "Bitcoin", + "defi-5-c-explanation": "Ez téves. A Bitcoin egy egyszerű hálózat értékek tárolására, nem pedig fejlett programok futtatására. A DeFi egy rugalmasabb rendszert igényel, mint például az Ethereum, amely képes komplex programokat futtatni a kölcsönök és a kereskedések automatikus kezelésére.", + "defi-5-d-label": "Hagyományos pénzintézetek", + "defi-5-d-explanation": "Ez téves. A DeFi alkalmazásoknak nincs szükségük hagyományos pénzintézetekre. Okosszerződéseknek nevezett blokkláncprogramokat használnak a tranzakciók automatikus kezelésére." } diff --git a/src/intl/hu/page-bug-bounty.json b/src/intl/hu/page-bug-bounty.json index c9034dd4395..0240b720f65 100644 --- a/src/intl/hu/page-bug-bounty.json +++ b/src/intl/hu/page-bug-bounty.json @@ -8,9 +8,9 @@ "page-upgrades-bug-bounty-clients-type-1": "Specifikáció – megfelelőségi problémák", "page-upgrades-bug-bounty-clients-type-2": "Váratlan összeomlások, távoli kódfuttatással (RCE) vagy szolgáltatásmegtagadási (DOS) szembeni sérülékenységek", "page-upgrades-bug-bounty-clients-type-3": "Bármilyen probléma, amely javíthatatlan konszenzustörést okoz a hálózat többi részével szemben", - "page-upgrades-bug-bounty-misc-bugs": "Solidity-hibák", - "page-upgrades-bug-bounty-misc-bugs-desc": "A hatókör tartalmával kapcsolatos további részletekért tekintse meg a Solidity SECURITY.MD állományt.", - "page-upgrades-bug-bounty-misc-bugs-desc-2": "A Solidity nem tartalmaz biztonsági garanciákat a nem megbízható bemeneti adatok fordításával kapcsolatban, továbbá nem jár jutalom azért, ha a solc fordító rossz szándékkal generált adatok miatt leáll.", + "page-upgrades-bug-bounty-misc-bugs": "Nyelvátfordító hibák", + "page-upgrades-bug-bounty-misc-bugs-desc": "A Solidity és a Vyper átfordítók a hibavadász program hatálya alá tartoznak. Kérjük, adjon meg minden szükséges adatot a sebezhetőség reprodukálásához, például: A hibát kiváltó bemeneti programot, az érintett fordító verzióját, a cél EVM-verziót, adott esetben a keretrendszert/IDE-t, adott esetben az EVM végrehajtási környezetet/klienst és az operációs rendszert. A lehető legrészletesebben írja le a megtalált hiba reprodukálásához szükséges lépéseket.", + "page-upgrades-bug-bounty-misc-bugs-desc-2": "A Solidity és a Vyper nem tartalmaz biztonsági garanciákat a nem megbízható bemeneti adatok fordításával kapcsolatban, továbbá nem jár jutalom azért, ha a fordító rossz szándékkal generált adatok miatt leáll.", "page-upgrades-bug-bounty-deposit-bugs": "Letéti szerződés – hibák", "page-upgrades-bug-bounty-deposit-bugs-desc": "A Beacon lánc letéti szerződésének specifikációi és forráskódja része a hibavadász programnak.", "page-upgrades-bug-bounty-dependency-bugs": "Egymásra épülésből eredő hibák", @@ -59,7 +59,7 @@ "page-upgrades-bug-bounty-specs-docs": "Specifikációdokumentumok", "page-upgrades-bug-bounty-submit": "Hiba beküldése", "page-upgrades-bug-bounty-submit-desc": "Minden megtalált és érvényes hibáért jutalmat kap. A kapott jutalom összege a hiba súlyosságától függ. A hibák súlyosságát az OWASP kockázatminősítési modellel összhangban, az Ethereum-hálózatra gyakorolt hatás és bekövetkezés valószínűsége alapján számítjuk ki.", - "page-upgrades-bug-bounty-subtitle": "Keressen akár 250 000 USD-t, és kerüljön fel a ranglistára – találjon olyan hibát a protokollban, a kliensben vagy a Solidityben, amely hatással van az Ethereum-hálózatra.", + "page-upgrades-bug-bounty-subtitle": "Keressen akár 250 000 USD-t, és kerüljön fel a ranglistára – találjon olyan hibát a protokollban, a kliensben vagy a nyelvi fordítóban, amely hatással van az Ethereum-hálózatra.", "page-upgrades-bug-bounty-title": "Fogadjuk a beadványokat", "page-upgrades-bug-bounty-title-1": "Beacon lánc", "page-upgrades-bug-bounty-title-2": "Elágazásválasztás", diff --git a/src/intl/hu/page-community.json b/src/intl/hu/page-community.json index 49a3f6b409d..56c2440aa72 100644 --- a/src/intl/hu/page-community.json +++ b/src/intl/hu/page-community.json @@ -44,11 +44,18 @@ "page-community-try-ethereum": "Próbálja ki az Ethereumot", "page-community-upcoming-events-no-events": "Nincs a közeljövőben esemény. Ön esetleg tud ilyenről?", "page-community-upcoming-events-load-more": "Továbbiak betöltése", + "page-community-upcoming-events-view-event": "Esemény megtekintése", "page-community-why-get-involved-title": "Miért kapcsolódjon be?", "page-community-why-get-involved-card-1-title": "Találja meg a csoportját", "page-community-why-get-involved-card-1-description": "Mindenkinek van egy megfelelő csoport. Találjon hasonlóan gondolkodó embereket és kapcsolódjon velük, hogy megvitassa, átgondolja és ünnepelje az Ethereumot velük együtt.", "page-community-why-get-involved-card-2-title": "Találjon megélhetést", "page-community-why-get-involved-card-2-description": "Mindenkinek vannak kifizetendő számlái. Az Ethereum segít, hogy értelmes munkát végezzen és rendesen megfizessék ezért.", "page-community-why-get-involved-card-3-title": "Változtasson", - "page-community-why-get-involved-card-3-description": "A közreműködése az Ethereumon lehetővé teszi, hogy Ön aktív érdekeltje legyen egy olyan technológiának, mely pozitív hatást gyakorol milliónyi emberre." + "page-community-why-get-involved-card-3-description": "A közreműködése az Ethereumon lehetővé teszi, hogy Ön aktív érdekeltje legyen egy olyan technológiának, mely pozitív hatást gyakorol milliónyi emberre.", + "page-index-internet-image-alt": "Illusztráció egy futurisztikus számítógépről, amelyet Ethereum-kristályok táplálnak.", + "page-index-get-started-image-alt": "Illusztráció egy számítógépen dolgozó személyről.", + "page-index-get-started-wallet-image-alt": "Egy robot illusztrációja, melynek a teste egy kamra, és amely egy Ethereum-tárcát reprezentál.", + "page-index-get-started-eth-image-alt": "Egy ether (ETH) karaktert csodáló embercsoport képe.", + "page-index-get-started-dapps-image-alt": "Illusztráció egy számítógépet használó doge-kutyáról.", + "page-index-get-started-devs-image-alt": "Illusztráció egy kézről, amely egy ETH-logót épít LEGO-kockákból." } diff --git a/src/intl/hu/page-dapps.json b/src/intl/hu/page-dapps.json index d8254c84c5f..3ce67e0a451 100644 --- a/src/intl/hu/page-dapps.json +++ b/src/intl/hu/page-dapps.json @@ -7,7 +7,6 @@ "page-dapps-api3-logo-alt": "API3 logó", "page-dapps-arweave-logo-alt": "ARweave logó", "page-dapps-audius-logo-alt": "Audius logó", - "page-dapps-augur-logo-alt": "Augur logó", "page-dapps-axie-infinity-logo-alt": "Axie Infinity logó", "page-dapps-balancer-logo-alt": "Balancer logó", "page-dapps-brave-logo-alt": "Brave logó", @@ -69,7 +68,6 @@ "page-dapps-dapp-description-arweave": "Adattárolás folyamatosan, fenntartható módon egy előre kifizetett díj ellenében.", "page-dapps-dapp-description-async-art": "Alkosson, gyűjtsön és kereskedjen #ProgramozhatoMutaggyal –a digitális festmények „Rétegekre” bonthatók, amelyeket a teljes kép befolyásolására használhat. Minden Master és Layer egy-egy ERC721 token.", "page-dapps-dapp-description-audius": "Decentralizált streaming platform. Hallgatások = pénz az alkotóknak, nem a kiadóknak.", - "page-dapps-dapp-description-augur": "Fogadjon sporteseményekre, gazdasági vagy más eseményekre.", "page-dapps-dapp-description-axie-infinity": "Kereskedjen és harcoljon lényekkel, melyeket Axie-knek hívnak. Keressen pénzt játék közben – elérhető mobilon", "page-dapps-dapp-description-balancer": "A Balancer egy automatizált portfóliókezelő és kereskedési platform.", "page-dapps-dapp-description-brave": "Keress tokeneket böngészéskor és támogasd kedvenc alkotóidat.", @@ -123,7 +121,6 @@ "page-dapps-dapp-description-status": "Lehetővé teszi az információk szabad áramlását, biztosítja a bizalmas és biztonságos beszélgetéseket, és elősegíti az egyének szuverenitását.", "page-dapps-dapp-description-superrare": "Vásároljon digitális műtárgyakat közvetlenül a művészektől vagy másodlagos piacokról.", "page-dapps-dapp-description-synthetix": "A Synthetix egy szintetikus eszközöket létrehozó és azokkal kereskedő protokoll", - "page-dapps-dapp-description-token-sets": "Kripto befektetési stratégiák, melyek automatikusan kiegyensúlyozódnak.", "page-dapps-dapp-description-uniswap": "Cseréljen tokeneket egyszerűen, vagy biztosítson tokeneket egy bizonyos kamatért cserébe.", "page-dapps-dapp-description-xmtp": "Blokkláncszámlák közötti üzenetküldés, amelyben közvetlen üzenetek, figyelmeztetések, bejelentések és más jellegű közlések is lehetségesek.", "page-dapps-dapp-description-yearn": "A Yearn Finance egy hozamokat aggregáló projekt, mely lehetővé teszi, hogy egyének, DAO-k és más protokollok letétbe helyezzék digitális eszközeiket és arra hozamot kapjanak.", @@ -146,7 +143,7 @@ "page-dapps-editors-choice-pooltogether": "Vegyen veszteségmentes lottójegyet! Minden héten egy szerencsés nyertes megkapja a jegyalap által termelt egy heti kamat összegét. Kapja vissza a pénzét, amikor csak akarja.", "page-dapps-editors-choice-uniswap": "Cseréljen tokeneket könnyedén. Egy közösségi kedvenc, mely segít, hogy a többiekkel kereskedjen a hálózaton keresztül.", "page-dapps-ens-logo-alt": "Ethereum Name Service logo", - "page-dapps-explore-dapps-description": "Sok dapp még kísérleti fázisban van, és a decentralizált hálózatok lehetőségeit tesztelik. De ebben a technológiában is vannak sikeres korai projektek a pénzügyi, gaming vagy gyűjthető tárgyak kategóriában.", + "page-dapps-explore-dapps-description": "Sok dapp még kísérleti fázisban van, és a decentralizált hálózatok lehetőségeit tesztelik. De ebben a technológiában is vannak sikeres korai projektek a pénzügyi, gamer vagy gyűjthető tárgyak kategóriában.", "page-dapps-explore-dapps-title": "Fedezze fel a dappokat", "page-dapps-features-1-description": "Miután az Ethereumra felkerült, a dappkódot nem lehet leszedni. Bárki használhatja a dapp funkcióit. Még ha a dapp mögött álló csapat feloszlik, akkor is lehet használni. Amint felkerül az Ethereumra, ott marad.", "page-dapps-features-1-title": "Nincs tulajdonosa", @@ -261,7 +258,6 @@ "page-dapps-technology-button": "Technológia", "page-dapps-technology-description": "Ezek olyan alkalmazások, amelyek a fejlesztői eszközök decentralizálására, a kriptogazdasági rendszerek beépítésére a meglévő technológiára és a nyílt forráskódú fejlesztési munkák piactereinek létrehozására összpontosítanak.", "page-dapps-technology-title": "Decentralizált technológia", - "page-dapps-token-sets-logo-alt": "Token Sets logo", "page-dapps-uniswap-logo-alt": "Uniswap logo", "page-dapps-wallet-callout-button": "Tárca keresése", "page-dapps-wallet-callout-description": "A tárcák is dappok. Találjon egyet az Ön számára megfelelő funkciók alapján.", diff --git a/src/intl/hu/page-developers-docs.json b/src/intl/hu/page-developers-docs.json index 60beb767083..bdd39b76397 100644 --- a/src/intl/hu/page-developers-docs.json +++ b/src/intl/hu/page-developers-docs.json @@ -33,6 +33,7 @@ "docs-nav-development-networks-description": "Lokális blokklánc-környezetek a dappok tesztelésére a bevezetés előtt", "docs-nav-dex-design-best-practice": "Decentralizált tőzsdedizájn (DEX) bevált gyakorlatai", "docs-nav-dot-net": ".NET", + "docs-nav-elixir": "Elixír", "docs-nav-erc-20": "ERC-20: helyettesíthető tokenek", "docs-nav-erc-721": "ERC-721: NFT-k", "docs-nav-erc-777": "ERC-777", diff --git a/src/intl/hu/page-developers-learning-tools.json b/src/intl/hu/page-developers-learning-tools.json index 246c4a241ed..8da77b53e19 100644 --- a/src/intl/hu/page-developers-learning-tools.json +++ b/src/intl/hu/page-developers-learning-tools.json @@ -8,8 +8,6 @@ "page-learning-tools-capture-the-ether-logo-alt": "Capture the Ether-logó", "page-learning-tools-node-guardians-description": "A Node Guardians egy játékszerű oktatási felület, amely a web3-fejlesztőket fantáziakalandokba viszi, hogy elsajátítsák a Solidity, Cairo, Noir és Huff programozást.", "page-learning-tools-node-guardians-logo-alt": "Node Guardians logó", - "page-learning-tools-chainshot-description": "Távoktatásos, oktató által vezetett Ethereum fejlesztői bootcamp és további tanfolyamok.", - "page-learning-tools-chainshot-logo-alt": "ChainShot logo", "page-learning-tools-coding": "Tanulás programozással", "page-learning-tools-coding-subtitle": "Ezek az eszközök segítenek, hogy az Ethereummal kísérletezzen, ha interaktív tanulási élményt szeretne.", "page-learning-tools-consensys-academy-description": "Online Ethereum fejlesztő bootcamp.", @@ -52,11 +50,13 @@ "page-learning-tools-vyperfun-logo-alt": "Vyper.fun logo", "page-learning-tools-nftschool-description": "Fedezze fel a nem helyettesíthető tokenek, vagyis az NFT-k technikai oldalát.", "page-learning-tools-nftschool-logo-alt": "NFT school-logó", - "page-learning-tools-pointer-description": "Sajátítson el web3-fejlesztői készségeket szórakoztató interaktív oktatóanyagokon keresztül. Közben szerezzen kriptojutalmakat", - "page-learning-tools-pointer-logo-alt": "Pointer-logó", "page-learning-tools-platzi-description": "Sajátítsa el a decentralizált alkalmazások (dapp) Web3 platformon való építését, és fejlessze blokkláncfejlesztői képességeit.", "page-learning-tools-platzi-logo-alt": "Platzi-logó", "page-learning-tools-alchemy-university-description": "Lépjen előre a web3 karrierlétráján képzések, projektek és kódolás révén.", "page-learning-tools-alchemy-university-logo-alt": "Alchemy University-logó", + "page-learning-tools-learnweb3-description": "A LearnWeb3 egy ingyenes, magas színvonalú oktatási platform, amellyel nulláról indulva a web3-fejlesztés hősévé válhat.", + "page-learning-tools-learnweb3-logo-alt": "LearnWeb3 logó", + "page-learning-tools-cyfrin-updraft-description": "Ismerje meg az okosszerződés-fejlesztést minden képzettségi szinten, valamint a biztonsági ellenőrzéseket.", + "page-learning-tools-cyfrin-updraft-logo-alt": "Cyfrin Updraft logó", "alt-eth-blocks": "A blokkok ábrázolása úgy van elrendezve, hogy egy ETH-szimbólumot formázzon" } diff --git a/src/intl/hu/page-layer-2.json b/src/intl/hu/page-layer-2.json new file mode 100644 index 00000000000..24bb6693714 --- /dev/null +++ b/src/intl/hu/page-layer-2.json @@ -0,0 +1,139 @@ +{ + "layer-2-arbitrum-note": "A hibavizsgálat csak az engedélyezőlistán szereplő felhasználók számára elérhető, az engedélyezőlista még nincs megnyitva", + "layer-2-boba-note": "Az állapotvalidálás fejlesztés alatt áll", + "layer-2-optimism-note": "A hibavizsgálat fejlesztés alatt áll", + "layer-2-base-note": "A csalási bizonyítékok rendszere még fejlesztés alatt áll", + "layer-2-metadata-description": "Bevezetés az L2-be", + "layer-2-hero-title": "2. réteg", + "layer-2-hero-header": "Ethereum mindenkinek", + "layer-2-hero-subtitle": "Az Ethereum skálázása a tömeges használat érdekében.", + "layer-2-hero-alt-text": "Annak illusztrációja, ahogyan a tranzakciók a második blokkláncrétegen (L2) összevonódnak, majd felkerülnek az Ethereum főhálózatára", + "layer-2-hero-button-1": "Mi az a második blokkláncréteg (L2)", + "layer-2-hero-button-2": "A második blokkláncréteg (L2) használata", + "layer-2-hero-button-3": "Áthelyezés a második blokkláncrétegre (L2)", + "layer-2-statsbox-1": "A második blokkláncrétegen (L2) lévő teljes letétbe helyezett érték (USD)", + "layer-2-statsbox-2": "Átlagos ETH átviteli díj a második blokkláncrétegre (L2) (USD)", + "layer-2-statsbox-3": "A második blokkláncrétegen (L2) lévő teljes letétbe helyezett érték változása (30 nap)", + "layer-2-what-is-layer-2-title": "Mi az a második blokkláncréteg (L2)?", + "layer-2-what-is-layer-2-1": "A 2. réteg (L2) egy gyűjtőfogalom, amely az Ethereum skálázási megoldásainak meghatározott készletét írja le. A 2. réteg egy különálló blokklánc, amely kiterjeszti az Ethereumot, és örökli az Ethereum biztonsági garanciáit.", + "layer-2-what-is-layer-2-2": "Most ássuk bele egy kicsit jobban magunkat, amihez meg kell értenünk az első blokkláncréteget (L1).", + "layer-2-what-is-layer-1-title": "Mi az az első blokkláncréteg (L1)?", + "layer-2-what-is-layer-1-1": "Az L1 az alap blokklánc. Az Ethereum és a Bitcoin is L1 blokkláncok, mert ezek alkotják az alapot, amelyre a különböző, második blokkláncréteget (L2) képző hálózatok épülnek. L2-projektnek minősülnek például az összevont tranzakciók (rollup) az Ethereumon, illetve a Bitcoinonra épült Lighting Network. Minden felhasználói tevékenység, ami ezeken az L2 projekteken történik, végül felkerül az L1 blokkláncra.", + "layer-2-what-is-layer-1-2": "Az Ethereum a 2. rétegek adatelérhetőségi rétegeként is működik. A 2. rétegbeli projektek az Ethereumra támaszkodva teszik közzé tranzakciós adataikat az Ethereumban. Ezek az adatok felhasználhatók a 2. réteg állapotának lekérésére, vagy a 2. réteg tranzakcióinak vitatására.", + "layer-2-what-is-layer-1-list-title": "Az Ethereum, mint első blokkláncréteg (L1) a következőket foglalja magában:", + "layer-2-what-is-layer-1-list-1": "Csomópont-operátorok hálózata a hálózat biztonságossá tételéhez és érvényesítéséhez", + "layer-2-what-is-layer-1-list-2": "Blokk-készítők hálózata", + "layer-2-what-is-layer-1-list-3": "A blokklánc maga és az összes tranzakciós adat", + "layer-2-what-is-layer-1-list-4": "A konszenzusmechanizmus a hálózathoz", + "layer-2-what-is-layer-1-list-link-1": "Van még olyan dolog, ami nem egyértelmű az Ethereum kapcsán?", + "layer-2-what-is-layer-1-list-link-2": "Ismerje meg az Ethereumot.", + "layer-2-why-do-we-need-layer-2-title": "Miért van szükség második blokkláncrétegre (L2)?", + "layer-2-why-do-we-need-layer-2-1": "A blokkláncok három kívánatos tulajdonsága, hogy decentralizáltak, biztonságosak és skálázhatók legyenek. A blokklánc-trilemma szerint egy egyszerű blokklánc-architektúra csak kettőt képes egyszerre biztosítani a háromból. Biztonságos és decentralizált blokkláncot szeretne? Akkor fel kell áldoznia a skálázhatóságot.", + "layer-2-why-do-we-need-layer-2-2": "Az Ethereum jelenleg napi 1+ millió tranzakciót dolgoz fel. Az Ethereum használatának igénye magas tranzakciós díjakat okozhat. Itt jönnek be a 2. rétegű hálózatok.", + "layer-2-why-do-we-need-layer-2-scalability": "Skálázhatóság", + "layer-2-why-do-we-need-layer-2-scalability-1": "Az L2 fő célja a tranzakcióátvitel növelése (több tranzakció másodpercenként) a decentralizáció vagy a biztonság feláldozása nélkül.", + "layer-2-why-do-we-need-layer-2-scalability-2": "Az Ethereum Mainnet (1. réteg) csak nagyjából 15 tranzakciót képes feldolgozni másodpercenként. Ha nagy az igény az Ethereum használatára, a hálózat túlterheltté válik, ami növeli a tranzakciós díjakat, és kiárazza azokat a felhasználókat, akik nem engedhetik meg maguknak ezeket a díjakat. A 2. rétegek olyan megoldások, amelyek csökkentik ezeket a díjakat az 1. réteg blokkláncán kívüli tranzakciók feldolgozásával.", + "layer-2-why-do-we-need-layer-2-scalability-3": "Bővebben az Ethereum jövőképéről", + "layer-2-benefits-of-layer-2-title": "A második blokkláncréteg (L2) előnyei", + "layer-2-lower-fees-title": "Alacsonyabb díjak", + "layer-2-lower-fees-description": "Azáltal, hogy számos láncon kívüli tranzakciót összevonnak és egyetlen tranzakcióként kerül be az L1 blokkláncba, a tranzakciós díjak jelentősen csökkennek, így az Ethereum mindenki számára elérhetőbbé válik.", + "layer-2-maintain-security-title": "Biztonság fenntartása", + "layer-2-maintain-security-description": "Az L2 blokkláncok az Ethereum főhálózatára küldik be tranzakcióikat, így a felhasználók részesülnek az Ethereum-hálózat biztonságából.", + "layer-2-expand-use-cases-title": "Több felhasználási lehetőség", + "layer-2-expand-use-cases-description": "A másodpercenkénti több tranzakció, az alacsonyabb díjak és az új technológia révén a projektek jobb felhasználói élményt nyújtó alkalmazásokká bővülnek.", + "layer-2-how-does-layer-2-work-title": "Hogyan működik a második blokkláncréteg (L2)?", + "layer-2-how-does-layer-2-work-1": "Ahogy fentebb említettük, az L2 egy gyűjtőfogalom azokra az Ethereum-skálázási megoldásokra, amelyek az Ethereum L1-rétegén kívül kezelik a tranzakciókat, miközben továbbra is kihasználják annak szilárd decentralizált biztonságát. Az L2 egy különálló blokklánc, amely kiterjeszti az Ethereumot. Hogyan működik?", + "layer-2-how-does-layer-2-work-2": "Különféle L2-megoldások léteznek, egyedi kompromisszumokkal és biztonsági modellekkel. A második blokkláncrétegek (L2) átveszik a tranzakciókezelés terhét az L1-től, hogy az kevésbé legyen túlterhelt, így pedig minden sokkal inkább skálázhatóbbá válik.", + "layer-2-rollups-title": "Összegzők", + "layer-2-rollups-1": "Az összevont tranzakciók (rollup) sok száz tételt tudnak egyetlen L1 tranzakcióba összerendezni. Ezáltal az L1 tranzakciós díja eloszlik a felhasználók között, és minden ügylet olcsóbb lesz.", + "layer-2-rollups-2": "Az összevont tranzakciók bekerülnek az L1-re, azok végrehajtását ugyanakkor az L2 elkülönülten végzi. Ennek következtében az összevont tranzakció megörökli az Ethereum biztonságát. Amint az adat feltöltésre kerül az L1-be, az összevont tranzakció módosításához az Ethereumot kell megváltoztatni. Kétféle megoldás létezik: az optimista és a zero-knowledge (ZK, nulla tudású), melyek elsősorban abban különböznek, hogy miként adják át az adatot az L1-nek.", + "layer-2-optimistic-rollups-title": "Optimista összegzők", + "layer-2-optimistic-rollups-description": "A optimista rollupok lényege, hogy alapvetően azt feltételezik a tranzakciókról, hogy érvényesek, de szükség esetén kétségbe vonhatók. Érvénytelen tranzakció gyanúja esetén hibavizsgálatot hajtanak végre annak ellenőrzésére, hogy valóban erről van-e szó.", + "layer-2-optimistic-rollups-childSentance": "Bővebben az optimista rollupokról", + "layer-2-zk-rollups-title": "Zero-knowledge összegzők", + "layer-2-zk-rollups-description": "A zero-knowledge rollupok érvényességi igazolásokat használnak, amikor a tranzakciókat a láncon kívül számítják ki, majd tömörítve továbbítják az adatokat az Ethereum főhálózatának, hogy igazolják az ügyletek érvényességét.", + "layer-2-zk-rollups-childSentance": "Bővebben a ZK-rollupokról", + "layer-2-dyor-title": "Mindig nézzen utána Ön is: az L2-re vonatkozó kockázatok", + "layer-2-dyor-1": "Számos L2 projekt viszonylag újkeletű, és a felhasználóknak a működtetők őszinte magatartásában kell bízniuk, miközben azok igyekeznek decentralizálni a hálózataikat. Mindig mérlegelje, hogy az esetleges kockázatokat el tudja-e fogadni.", + "layer-2-dyor-2": "A 2. réteg technológiájával, kockázataival és bizalmi feltételezéseivel kapcsolatos további információkért javasoljuk, hogy tekintse meg az L2BEAT-et, amely minden projekthez átfogó kockázatértékelési keretet biztosít. .", + "layer-2-dyor-3": "Ugrás az L2BEAT oldalára", + "layer-2-use-layer-2-title": "2. réteg használata", + "layer-2-use-layer-2-1": "Most, hogy egyértelművé vált, miért létezik a második blokkláncréteg (L2) és hogyan működik, vágjunk bele a használatába!", + "layer-2-contract-accounts": "Ha okosszerződéses pénztárcát használ, mint például a Safe vagy Argent, akkor a 2. rétegben nem fogja tudni irányítani ezt a címet, amíg át nem helyezi szerződéses fiókját az a cím a 2. rétegen. A helyreállítási kifejezéssel rendelkező klasszikus fiókok automatikusan ugyanazt a fiókot fogják birtokolni a 2. réteg összes hálózatán.", + "layer-2-use-layer-2-generalized-title": "Általános L2 hálózatok", + "layer-2-use-layer-2-generalized-1": "Az általánosított 2. rétegek ugyanúgy viselkednek, mint az Ethereum – de olcsóbbak. Bármi, amit megtehet az Ethereum 1. rétegében, megteheti a 2. rétegben is. Sok dapp már megkezdte a migrációt ezekre a hálózatokra, vagy teljesen kihagyta a Mainnetet építsen projekteket közvetlenül egy 2. rétegre.", + "layer-2-use-layer-2-application-specific-title": "Alkalmazásspecifikus L2-hálózatok", + "layer-2-use-layer-2-application-specific-1": "Az alkalmazásspecifikus L2-projektek egy adott alkalmazási terület optimalizálására specializálódtak, és ezáltal jobb teljesítményt nyújtanak.", + "layer-2-sidechains-title": "Megjegyzés a mellékláncokról, validiumokról és alternatív blokkláncokról", + "layer-2-sidechains-1": "Az Oldalláncok és validiumok olyan blokkláncok, amelyek lehetővé teszik az Ethereumból származó eszközök áthidalását és egy másik blokkláncon való felhasználását. Az oldalláncok és a validiumok párhuzamosan futnak az Ethereummal, és hidak révén lépnek kapcsolatba az Ethereummal, de biztonsági vagy adatelérhetőségüket nem az Ethereumtól származtatják.", + "layer-2-sidechains-2": "Mindkettő skálázási képessége az L2-megoldásokhoz hasonló – alacsonyabb tranzakciós díjakat és nagyobb tranzakciós átviteli sebességet kínálnak –, de eltérő bizalmi feltételezésekkel járnak.", + "layer-2-more-on-sidechains": "További információk a mellékláncokról", + "layer-2-more-on-validiums": "További információk a validiumokról", + "layer-2-sidechains-4": "Néhány L1 blokklánc az Ethereumhoz képest magasabb tranzakcióátvitelt és alacsonyabb díjakat tud kínálni, de általában más területeken kompromisszumokra kényszerülnek (például a csomópontok futtatásához komolyabb hardverre van szükség).", + "layer-2-onboard-title": "Hogyan lehet átkerülni az L2-re", + "layer-2-onboard-1": "Két fő módja van annak, hogy eszközeit áthelyezze a második blokkláncrétegre (L2): egy okosszerződésen keresztül áthidalhatja a pénzeszközeit az Ethereumról, vagy egy kriptotőzsdéről közvetlenül egy L2 hálózatra utalja ki pénzeszközeit.", + "layer-2-onboard-wallet-title": "A pénzeszközei a tárcájában vannak?", + "layer-2-onboard-wallet-1": "Ha már van ETH a tárcájában, akkor egy híd vagy összekötő segítségével tudja áthelyezni az Ethereum-főhálózatról egy L2 hálózatra.", + "layer-2-more-on-bridges": "További információk a hidakról", + "layer-2-onboard-wallet-input-placeholder": "Válassza ki az L2-t, amelyikre szeretne áthelyezni", + "layer-2-onboard-wallet-selected-1": "A következőképpen tud kapcsolódni az L2-höz", + "layer-2-onboard-wallet-selected-2": "ezen tárcák használatával:", + "layer-2-bridge": "Híd", + "layer-2-onboard-exchange-title": "A pénzeszközei kriptotőzsdén vannak?", + "layer-2-onboard-exchange-1": "Egyes centralizált tőzsdéken már lehetséges a közvetlen pénzkiutalás és befizetés az L2 hálózatokra. Ellenőrizze, hogy melyik tőzsdék támogatják az L2-re való kiutalást, illetve hogy melyik L2-t támogatják.", + "layer-2-onboard-exchange-2": "Emellett szüksége van egy tárcára is, ahova a pénzeszközeit kiutaltatja.", + "layer-2-onboard-find-a-wallet": "Válasszon magának egy Ethereum-tárcát.", + "layer-2-onboard-exchange-input-placeholder": "Nézze meg az L2-t támogató tőzsdéket", + "layer-2-deposits": "Letétbe helyezés", + "layer-2-withdrawals": "Letétkivonás", + "layer-2-go-to": "Ugrás ide:", + "layer-2-tools-title": "Hasznos eszközök a második blokkláncrétegen (L2)", + "layer-2-tools-l2beat-description": "Az L2BEAT nagyszerű eszköz az L2 projektek technikai kockázatértékelésének tanulmányozására. Tekintse meg az oldalon található információkat, amikor bizonyos L2 projekteket vizsgál.", + "layer-2-tools-growthepie-description": "Válogatott elemzések az Ethereum L2 megoldásokról", + "layer-2-tools-ethereumecosystem-description": "Az Ethereum és a második blokkláncréteg (L2) nem hivatalos ökoszisztéma oldala, beleértve a Base, Optimism és Starknet rendszereket, melyek több száz dappot és eszközt kínálnak.", + "layer-2-tools-l2fees-description": "Az L2 Fees oldalon megnézheti a különböző L2 hálózatok aktuális tranzakciós díjait (USD-ban kifejezve).", + "layer-2-tools-chainlist-description": "A Chainlist nagyszerű eszköz a hálózati RPC-k támogatott tárcákba való importálásához. Itt találja az L2 projektekhez tartozó RPC-ket, melyek révén kapcsolatot tud létrehozni.", + "layer-2-tools-zapper-description": "Kezelje a teljes web3-portfólióját a DeFi-tól kezdve az NFT-kig, és bármit, ami ezután következik. Fektessen be a legújabb lehetőségekbe egyetlen kényelmes helyről.", + "layer-2-tools-zerion-description": "Építse fel és kezelje a teljes DeFi portfólióját egyetlen helyről. Fedezze fel a decentralizált pénzügyek világát még ma.", + "layer-2-tools-debank-description": "Kövesse nyomon a web3 világ minden fontos eseményét", + "layer-2-faq-title": "GYIK", + "layer-2-faq-question-1-title": "Miért nincs „hivatalos” Ethereum L2?", + "layer-2-faq-question-1-description-1": "Ahogyan nincs „hivatalos” Ethereum-kliens, úgy nincs „hivatalos” Ethereum L2 sem. Az Ethereum nem engedélyhez kötött – gyakorlatilag bárki létrehozhat L2 hálózatot! Számos csapat építi a második blokkláncréteg saját verzióját, és az ökoszisztéma egésze profitál a különféle felhasználási esetekre optimalizált tervezési megközelítések sokféleségéből. Hasonlóan ahhoz, ahogy több Ethereum-kliensünk is van, amelyet több csapat fejlesztett ki a hálózat sokszínűsége érdekében, a jövőben az L2 hálózatok is így fognak fejlődni.", + "layer-2-faq-question-2-title": "Mi a különbség az optimista és a zero-knowledge rollupok között?", + "layer-2-faq-question-2-description-1": "Mind az optimista, mind a zero-knowledge rollupok tranzakciók százait vonják össze egyetlen tranzakcióba az L1-en. Az összesített tranzakciók az L1-en kívül kerülnek végrehajtásra, de a tranzakciós adatok az L1-en is közzétételre kerülnek.", + "layer-2-faq-question-2-description-2": "Az elsődleges különbség az, hogy milyen adatok kerülnek az L1-be, és hogyan történik az adatok ellenőrzése. Az érvényességi igazolásokhoz (a zero-knowledge rollupok esetében) a láncon kívül futnak a számítások, melyek egy igazolást tesznek közzé, míg a hibabizonyításoknál (az optimista rollupoknál) csak akkor futtatják le a számításokat a láncon belül, ha hiba gyanítható, és ellenőrizni kell.", + "layer-2-faq-question-2-description-3": "Jelenleg a legtöbb zero-knowledge (ZK) rollup alkalmazásspecifikus, miközben az optimista rollupok nagyrészt általánosan alkalmazhatók.", + "layer-2-more-info-on-optimistic-rollups": "További információk az optimista rollupokról", + "layer-2-more-info-on-zk-rollups": "További információk a zero-knowledge rollupokról", + "layer-2-faq-question-4-title": "Milyen kockázatokkal jár az L2?", + "layer-2-faq-question-4-description-1": "A 2. rétegbeli projektek további kockázatokat rejtenek magukban az alapok birtoklásához és az Ethereum Mainnet-en történő közvetlen tranzakciókhoz képest. Például előfordulhat, hogy a sorrendezők leállnak, ami azt eredményezheti, hogy várnia kell az alapokhoz való hozzáféréshez.", + "layer-2-faq-question-4-description-2": "Mindenképpen érdemes megvizsgálni az adott projektet, mielőtt jelentős összegeket helyez át az L2-re. Az L2 hálózatok technológiájával, kockázataival és bizalmi feltételezéseivel kapcsolatban nézze meg az L2BEAT oldalát, amely minden projekthez átfogó kockázatelemzési keretrendszert biztosít.", + "layer-2-faq-question-4-description-3": "A blokklánchidak, melyek az eszközök L2-re való áthelyezését teszik lehetővé, még a fejlesztés korai szakaszában vannak, és valószínűleg még ki kell alakítani az optimális dizájnt. A közelmúltban történtek támadások a hidak ellen.", + "layer-2-faq-question-5-title": "Miért nem jelennek meg bizonyos L2 projektek itt?", + "layer-2-faq-question-5-description-1": "Szeretnénk a felhasználók számára a lehető legjobb eszközöket adni, hogy biztonságosan és magabiztosan tudjanak navigálni az L2 világában. Egy kritériumrendszer segítségével értékeljük a projekteket, hogy bekerülhetnek-e.", + "layer-2-faq-question-5-view-listing-policy": "Itt találja az L2-listázási szabályzatot.", + "layer-2-faq-question-5-description-2": "Bárki javasolhatja, hogy egy adott L2 megjelenjen az ethereum.org portálon. Ha Ön hiányolja valamelyik L2-t, akkor itt jelezze.", + "layer-2-further-reading-title": "További olvasnivaló", + "a-rollup-centric-ethereum-roadmap": "A rollupközpontú Ethereum ütemterve", + "an-incomplete-guide-to-rollups": "Hiányos útmutató a rollupokhoz", + "polygon-sidechain-vs-ethereum-rollups": "A Polygon melléklánc és az Ethereum-rollupok összehasonlítása: L2 skálázási megközelítések | Vitalik Buterin és Lex Fridman", + "rollups-the-ultimate-ethereum-scaling-strategy": "Rollupok – A Ethereum végső skálázási stratégiája? Az Arbitrum és Optimism bemutatása", + "scaling-layer-1-with-shard-chains": "Az L1 skálázása párhuzamos futtatású (shard) láncokkal", + "understanding-rollup-economics-from-first-principals": "A rollupok gazdasági vonatkozásainak megértése az alapelvektől kezdve", + "arbitrum-description": "Az Arbitrum One egy olyan optimista rollup, melynek célja, hogy az ügyletek során olyan érzése legyen a felhasználónak, mintha az Ethereumot használná. Ugyanakkor a tranzakció költsége az L1 díj töredéke.", + "optimism-description": "Az Optimism egy gyors, egyszerű és biztonságos, az Ethereum-virtuális géppel (EVM) ekvivalens optimista rollup. A Ethereum technológiáját skálázza, miközben annak értékét is növeli a visszamenőleges közjó-finanszírozással.", + "boba-description": "A Boba egy optimista rollup, mely eredetileg az Optimism projektből ágazott ki. Egy olyan skálázási megoldás, mely törekszik a díjak csökkentésére, a tranzakcióátvitel növelésére, és kiterjeszti az okosszerződések funkcióit.", + "base-description": "A Base egy biztonságos, alacsony költségű, fejlesztőbarát Ethereum L2, amelyet azért építettek, hogy a következő milliárdnyi felhasználó számára elérhetővé tegye a web3-t. Ez egy Ethereum L2, amelyet a Coinbase inkubált, és a nyílt forráskódú OP Stackre épül.", + "loopring-description": "A Loopring zero-knowledge rollup L2 megoldása arra törekszik, hogy az Ethereum főhálózatával megegyező biztonsági garanciákat nyújtsa rendkívüli skálázási növekménnyel együtt: a tranzakcióátvitel 1000-szeres megnövelésével és a költség csökkentésével, ami az L1 díjának 0,1%-a.", + "zksync-description": "A ZKsync egy olyan ZK összegző, amely méretezi az Ethereumot és annak értékeit, hogy mindenhol használható lehessen anélkül, hogy a biztonság vagy a decentralizáció csökkenne.", + "zkspace-description": "A ZKSpace platform három fő részből áll: az L2 AMM DEX (automatikus piackészítőként működő decentralizált tőzsde), mely ZK-rollup technológát használ, és ZKSwapnak nevezik; a kifizetési rendszer, melynek ZKSquare a neve; és az NFT-piactér, amely ZKSea néven fut.", + "aztec-description": "Az Aztec Network az első privát ZK-rollup az Ethereumon, mely lehetővé teszi, hogy a decentralizált alkalmazások élvezhessék az adatvédelmet és a skálázást.", + "starknet-description": "A Starknet egy validitáson alapuló összevont tranzakció (L2). Gyors tranzakcióátvitel, alacsony gázdíj jellemzi, miközben megtartja az Ethereum (L1) biztonsági szintjét.", + "layer-2-note": "Megjegyzés:", + "layer-2-ecosystem-portal": "Ökoszisztéma portál", + "layer-2-token-lists": "Tokenlisták", + "layer-2-explore": "Ugrás", + "page-dapps-ready-button": "Ugrás", + "layer-2-information": "Információ", + "layer-2-wallet-managers": "Tárcakezelők" +} diff --git a/src/intl/hu/page-staking.json b/src/intl/hu/page-staking.json index 6b12366d048..ee8fa223727 100644 --- a/src/intl/hu/page-staking.json +++ b/src/intl/hu/page-staking.json @@ -31,8 +31,8 @@ "page-staking-hero-header": "Szerezzen jutalmat azért, hogy biztosítja az Ethereumot", "page-staking-hero-subtitle": "Bármely felhasználó, aki bármilyen mennyiségű ETH-szel rendelkezik, segíthet a hálózat biztosításában, és közben jutalmakat is szerezhet.", "page-staking-dropdown-home": "Otthoni letétbe helyezés", - "page-staking-dropdown-solo": "Egyéni staking", - "page-staking-more-on-solo": "Bővebben az önálló letétbe helyezésről", + "page-staking-dropdown-solo": "Egyéni letétbe helyezés", + "page-staking-more-on-solo": "Bővebben az egyéni letétbe helyezésről", "page-staking-learn-more-solo": "Tudjon meg többet az önálló letétbe helyezésről", "page-staking-dropdown-saas": "Staking, mint szolgáltatás", "page-staking-saas-with-abbrev": "Letétbe helyezés mint szolgáltatás (SaaS)", @@ -50,15 +50,18 @@ "page-staking-guide-title-coincashew-ethereum": "CoinCashew Ethereum 2.0 útmutató", "page-staking-guide-title-somer-esat": "Somer Esat", "page-staking-guide-title-rocket-pool": "Rocket Pool csomópont-operátorok", + "page-staking-guide-title-stakewise": "StakeWise csomópont-operátorok", "page-staking-guide-description-linux": "Linux (CLI)", "page-staking-guide-description-mac-linux": "Linux, macOS (CLI)", - "page-staking-hierarchy-solo-h2": "Önálló, otthoni letétbe helyezés", + "page-staking-guide-description-mac-linux-windows": "Linux, Windows, MacOS (CLI)", + "page-staking-hierarchy-solo-h2": "Egyéni letétbe helyezés", "page-staking-hierarchy-solo-pill-1": "Leghatásosabb", "page-staking-hierarchy-solo-pill-2": "Teljes kontroll", "page-staking-hierarchy-solo-pill-3": "Teljes jutalom", "page-staking-hierarchy-solo-pill-4": "Bizalomigény nélküli", - "page-staking-hierarchy-solo-p1": "Az önálló letétbe helyezés az Ethereumon az aranyalap. Teljes részvételi jutalmat ad, javítja a hálózat decentralizálását, és senkire sem kell rábízni a pénzeszközöket.", - "page-staking-hierarchy-solo-p2": "Aki ezt fontolgatja, annak legalább 32 ETH-nek rendelkezésére kell állnia, illetve egy erre a célra dedikált számítógép, mely folyamatos internetkapcsolattal rendelkezik (24/7). Hasznos lehet némi technikai rálátás is, de manapság a már könnyen használható eszközök leegyszerűsítik ezt a folyamatot.", + "page-staking-hierarchy-solo-p1": "Az egyéni letétbe helyezés az Ethereumon az aranyalap. Teljes részvételi jutalmat ad, javítja a hálózat decentralizálását, és senkire sem kell rábízni a pénzeszközöket.", + "page-staking-hierarchy-solo-p2": "Aki ezt fontolgatja, annak szükséges némi ETH és egy erre a célra dedikált számítógép, amely folyamatos internetkapcsolattal rendelkezik (24/7). Hasznos lehet némi technikai rálátás is, de manapság a már könnyen használható eszközök leegyszerűsítik ezt a folyamatot.", + "page-staking-hierarchy-solo-p3": "Az egyéni letétbe helyezők másokkal együtt is összeadhatják a szükséges ETH mennyiségét, vagy legalább 32 ETH-re van szükségük, hogy önállóan végezzék azt. A likvid letétbe helyezési megoldások segítik a hozzáférést a decentralizált pénzügyekhez (DeFi).", "page-staking-hierarchy-saas-pill-1": "Az Ön 32 ETH-je", "page-staking-hierarchy-saas-pill-2": "Az Ön validátorkulcsa", "page-staking-hierarchy-saas-pill-3": "Megbízott csomópont-működtetés", @@ -71,7 +74,7 @@ "page-staking-hierarchy-pools-pill-4": "Népszerű", "page-staking-hierarchy-pools-p1": "Számos letétialap-megoldás létezik azon felhasználók számára, akik nem akarnak vagy nem tudnak 32 ETH-t letétbe helyezni.", "page-staking-hierarchy-pools-p2": "Számos megoldás tartalmazza a likvid letétbe helyezést, amely egy ERC-20 likviditási tokent használ, ami a letétbe helyezett ETH-t reprezentálja.", - "page-staking-hierarchy-pools-p3": "A likvid letétbe helyezés egyszerű, bármikor végezhető, és olyan egyszerű, akár egy tokenátváltás. Ekkor a felhasználó a saját Ethereum tárcájában, a saját felügyelete alatt tudhatja az eszközeit.", + "page-staking-hierarchy-pools-p3": "A likvid letétbe helyezés jelentősen leegyszerűsíti a letét elhelyezését és felszabadítását, akár egy tokenátváltás, a letétbe helyezett tőke pedig felhasználható a DeFi-ban. Ekkor a felhasználó a saját Ethereum-tárcájában, a saját felügyelete alatt tudhatja az eszközeit.", "page-staking-hierarchy-pools-p4": "A letéti alapok nem az Ethereum hálózatának részei. Harmadik felek építik ezeket a megoldásokat, és viselik az ezzel járó kockázatot.", "page-staking-hierarchy-cex-h2": "Centralizált tőzsdék", "page-staking-hierarchy-cex-pill-1": "Legkevésbé hatásos", @@ -84,8 +87,10 @@ "page-staking-comparison-solo-pools": "Az önálló letétbe helyezés magasabb szintű bevonódást igényel, mint egy letéti alap használata, de cserébe a teljes ETH-jutalom a felhasználót illeti, és teljes kontrollt biztosít a validátor működése és biztonsága felett. A letéti alap jelentősen kevesebb pénzeszközzel is igénybe vehető. A felhasználók kisebb összegeket adnak át, nem kell validátorkulcsokat létrehozniuk, és nincs komoly hardverszükséglet sem egy alapvető internetkapcsolaton kívül. A likviditási tokenek révén ki lehet szállni a letétből azelőtt is, hogy ez a funkció a protokoll szintjén életbe lép. Ha Önt ezek a funkciók érdeklik, akkor a letéti alap jó választás lehet.", "page-staking-comparison-saas-solo": "Mindkét esetben Ön rendelkezik a validátorkulcsokkal, anélkül hogy letéti alapot kellene használni, de az SaaS esetén egy harmadik félben bízik, aki talán visszaél ezzel, támadás célpontja lesz vagy változik a rá vonatkozó szabályozás. Ha Önt zavarják ezek a bizalmi vagy centralizációs felvetések, akkor a teljesen független letéti megoldás az önálló staking.", "page-staking-comparison-saas-pools": "Hasonlók abból a szempontból, hogy más futtatja Önnek a validátorklienst, de az SaaS-hez képest a letéti alapba kevesebb ETH lekötése is elég. Ha Ön 32 ETH-nél kevesebbet szeretne letétbe helyezni, akkor jó megoldás lehet a letéti alap.", - "page-staking-comparison-pools-solo": "A letéti alap jelentősen kevesebb pénzeszközt igényel az önálló stakinghez képest, de további kockázatokat is jelent, hogy egy harmadik fél üzemelteti a csomópontokat, és további díjazást igényel. Az önálló staking teljes függetlenséget és kontrollt biztosít. A letétesek nem adják át a kulcsaikat, és a teljes jutalom őket illeti közvetítő nélkül.", + "page-staking-comparison-pools-solo": "A letéti alap jelentősen kevesebb pénzeszközt igényel az otthoni letétbe helyezéshez képest, de további kockázatokat is rejt, ha egy harmadik fél üzemelteti a csomópontokat, és további díjazást igényel. Az otthoni letétbe helyezés teljes függetlenséget és kontrollt biztosít. A letétesek nem adják át a kulcsaikat, és a teljes jutalom őket illeti meg közvetítő nélkül.", "page-staking-comparison-pools-saas": "Hasonlók abban, hogy a letétes nem maga futtatja a validátorszoftvert, de a letéti alaphoz képest az SaaS esetében 32 ETH kell a validátor aktiválásához. A jutalmak a letétesnél gyűlnek, és általában egy havi díjat vagy más letétet kell adni a szolgáltatásért. Ha Ön szeretné a validátorkulcsait magánál tartani, és legalább 32 ETH-t letétbe helyezne, akkor az SaaS szolgáltatás jó opció lehet.", + "page-staking-considerations-dropdown-text": "Letétbe helyezési megfontolások", + "page-staking-considerations-dropdown-aria-label": "Letétbe helyezési megfontolások menüje", "page-staking-considerations-solo-1-title": "Nyílt forráskódú", "page-staking-considerations-solo-1-description": "A programkód lényegi része 100% nyílt forráskódú és bárki felhasználhatja", "page-staking-considerations-solo-1-warning": "Zárt forráskódú", @@ -157,6 +162,7 @@ "page-staking-launchpad-widget-p3": "Ennek megkönnyítésére, nézze meg az elérhető eszközöket és útmutatókat alább, melyek a Staking Launchpad használata mellett segítenek a kliens felállításában.", "page-staking-launchpad-widget-link": "Szoftvereszközök és útmutató", "page-staking-products-get-started": "Kezdjünk bele", + "page-staking-products-follow": "Tovább az oldalra", "page-staking-dropdown-staking-options": "Letétbe helyezési opciók", "page-staking-dropdown-staking-options-alt": "Letétbe helyezési opciók legördülő menüje", "page-staking-stats-box-metric-1": "A letétbe helyezett ETH teljes összege", @@ -168,8 +174,8 @@ "page-staking-section-comparison-subtitle": "Nincs olyan letétbe helyezési (staking) megoldás, mely mindenre jó lenne, mindegyik teljesen egyedi. Következzen a módszerek összevetése a fő kockázatok, jutalmak és feltételek mentén.", "page-staking-section-comparison-rewards-title": "Jutalmak", "page-staking-section-comparison-solo-rewards-li1": "Maximális jutalom – a jutalom teljes összegét megkapja közvetlenül a protokolltól", - "page-staking-section-comparison-solo-rewards-li2": "Jutalmat kap azért, a tranzakciókat egy új blokkba rendezze, illetve ellenőrizze más validátorok munkáját, hogy a lánc biztonságosan működhessen", - "page-staking-section-comparison-solo-rewards-li3": "A javasolt blokkok után azokat a tranzakciós díjakat is megkapja, melyeket nem égetnek el", + "page-staking-section-comparison-solo-rewards-li2": "A blokkelőterjesztésért járó jutalom, beleértve az el nem égetett díjakat is, valamint a hálózat státuszának rendszeres tanúsításáért járó díj", + "page-staking-section-comparison-solo-rewards-li3": "Likvid letétbe helyezési token kibocsátásának lehetősége az otthoni csomópontra vonatkozóan, melyet a DeFi-ban lehet felhasználni", "page-staking-section-comparison-saas-rewards-li1": "Általában a teljes protokoll jutalom mínusz a csomópont-üzemeltetés havi költsége", "page-staking-section-comparison-saas-rewards-li2": "A validátorkliens könnyebb monitorozásához gyakran elérhetők irányítópultok", "page-staking-section-comparison-pools-rewards-li1": "A letéti alapok esetén a jutalmak különféle módokon keletkeznek a választott módszer függvényében", @@ -178,7 +184,8 @@ "page-staking-section-comparison-risks-title": "Kockázatok", "page-staking-section-comparison-solo-risks-li1": "Az Ön ETH-je a tét", "page-staking-section-comparison-solo-risks-li2": "Ha a validátor offline, akkor ETH-be kerül a büntetés", - "page-staking-section-comparison-solo-risks-li3": "A rosszhiszemű viselkedés nagyobb ETH összeg elvételét (slashing) és a hálózatból való kizárást von maga után", + "page-staking-section-comparison-solo-risks-li3": "A rosszindulatú cselekedetekért járó súlyos büntetés és kizárás (slashing)", + "page-staking-section-comparison-solo-risks-li4": "A likvid letétbe helyezési token kibocsátása egy okosszerződéses kockázatottal jár, de ez teljesen opcionális", "page-staking-section-comparison-saas-risks-li1": "Ugyanazok a kockázatok, mint az önálló stakingnél, plusz a szolgáltatásnyújtóból eredő kockázatok", "page-staking-section-comparison-saas-risks-li2": "Az aláírókulcsokat egy másik személy kezeli, aki visszaélhet azokkal", "page-staking-section-comparison-pools-risks-li1": "A kockázat a választott módtól függ", diff --git a/src/intl/hu/page-wallets-find-wallet.json b/src/intl/hu/page-wallets-find-wallet.json index ee5552344b8..1de7b90849b 100644 --- a/src/intl/hu/page-wallets-find-wallet.json +++ b/src/intl/hu/page-wallets-find-wallet.json @@ -71,6 +71,7 @@ "page-find-wallet-finance-desc": "Tárcák DeFi alkalmazások gyakori használatára.", "page-find-wallet-developer-title": "Fejlesztő", "page-find-wallet-developer-desc": "Tárcák dappok fejlesztésére és tesztelésére.", + "page-find-wallet-active": "aktív", "page-find-wallet-footnote-1": "Az oldalon szereplő tárcák nem minősülnek az Ethereum által minősített termékeknek, az itt megjelenő adataik tájékoztatási célt szolgálnak.", "page-find-wallet-footnote-2": "A leírásokat a tárcákat biztosító projekt adta.", "page-find-wallet-footnote-3": "Erre az oldalra a listázási szabályzatban meghatározott kritériumok alapján veszünk fel új termékeket. Ha új termék megjelenítését szeretné, akkor kérje a GitHubon.", @@ -78,6 +79,7 @@ "page-find-wallet-desktop": "Asztali számítógép", "page-find-wallet-browser": "Böngésző", "page-find-wallet-device": "Eszköz", + "page-find-wallet-reset-filters": "Visszaállítás", "page-find-wallet-visit-website": "Látogasson el a webhelyre", "page-find-wallet-social-links": "Linkek", "page-find-wallet-empty-results-title": "Nincs találat", From 778d9bb2edd8482777c58a46869f0f9f6aa4d195 Mon Sep 17 00:00:00 2001 From: Corwin Smith Date: Mon, 6 Jan 2025 12:35:57 -0700 Subject: [PATCH 2/3] remove bad import --- .../hu/04) Exploring/nft/index.md | 114 -- .../hu/05) Use Ethereum Pages/dao/index.md | 166 -- .../hu/06) Use Cases/defi/index.md | 361 ---- .../hu/06) Use Cases/smart-contracts/index.md | 82 - .../hu/06) Use Cases/web3/index.md | 157 -- .../hu/07) Staking Pages/staking/dvt/index.md | 91 - .../07) Staking Pages/staking/pools/index.md | 86 - .../07) Staking Pages/staking/saas/index.md | 95 - .../07) Staking Pages/staking/solo/index.md | 206 -- .../staking/withdrawals/index.md | 218 -- .../decentralized-identity/index.md | 191 -- .../hu/08) Use cases 2/desci/index.md | 138 -- .../hu/08) Use cases 2/refi/index.md | 81 - .../08) Use cases 2/social-networks/index.md | 106 - .../hu/09) Learn Pages/bridges/index.md | 137 -- .../energy-consumption/index.md | 82 - .../hu/09) Learn Pages/governance/index.md | 182 -- .../hu/09) Learn Pages/security/index.md | 295 --- .../zero-knowledge-proofs/index.md | 214 -- .../index.md | 73 - .../guides/how-to-id-scam-tokens/index.md | 97 - .../how-to-revoke-token-access/index.md | 73 - .../guides/how-to-swap-tokens/index.md | 67 - .../guides/how-to-use-a-bridge/index.md | 70 - .../guides/how-to-use-a-wallet/index.md | 88 - .../hu/10) Guides and Quizzes/guides/index.md | 27 - .../translations/hu/11) Roadmap/eips/index.md | 79 - .../11) Roadmap/roadmap/beacon-chain/index.md | 75 - .../roadmap/future-proofing/index.md | 38 - .../hu/11) Roadmap/roadmap/index.md | 119 -- .../hu/11) Roadmap/roadmap/merge/index.md | 229 --- .../roadmap/merge/issuance/index.md | 134 -- .../hu/11) Roadmap/roadmap/scaling/index.md | 51 - .../hu/11) Roadmap/roadmap/security/index.md | 48 - .../roadmap/user-experience/index.md | 36 - .../roadmap/account-abstraction/index.md | 126 -- .../roadmap/danksharding/index.md | 95 - .../hu/12) Roadmap 2/roadmap/dencun/index.md | 120 -- .../hu/12) Roadmap 2/roadmap/pbs/index.md | 51 - .../roadmap/secret-leader-election/index.md | 44 - .../roadmap/single-slot-finality/index.md | 66 - .../roadmap/statelessness/index.md | 103 - .../roadmap/verkle-trees/index.md | 66 - .../developers/docs/accounts/index.md | 136 -- .../developers/docs/blocks/index.md | 152 -- .../developers/docs/dapps/index.md | 96 - .../developers/docs/evm/index.md | 78 - .../developers/docs/evm/opcodes/index.md | 174 -- .../developers/docs/gas/index.md | 140 -- .../developers/docs/index.md | 25 - .../developers/docs/intro-to-ether/index.md | 78 - .../docs/intro-to-ethereum/index.md | 116 -- .../developers/docs/networks/index.md | 149 -- .../developers/docs/transactions/index.md | 221 -- .../developers/docs/web2-vs-web3/index.md | 62 - .../developers/docs/wrapped-eth/index.md | 65 - .../community/code-of-conduct/index.md | 77 - .../community/events/index.md | 24 - .../community/get-involved/index.md | 135 -- .../community/grants/index.md | 47 - .../community/language-resources/index.md | 153 -- .../community/online/index.md | 75 - .../community/research/index.md | 399 ---- .../community/support/index.md | 105 - .../nodes-and-clients/archive-nodes/index.md" | 80 - .../nodes-and-clients/bootnodes/index.md" | 31 - .../client-diversity/index.md" | 109 - .../docs/nodes-and-clients/index.md" | 315 --- .../nodes-and-clients/light-clients/index.md" | 61 - .../node-architecture/index.md" | 57 - .../nodes-as-a-service/index.md" | 419 ---- .../nodes-and-clients/run-a-node/index.md" | 480 ----- .../docs/consensus-mechanisms/index.md" | 92 - .../pos/attack-and-defense/index.md" | 89 - .../pos/attestations/index.md" | 92 - .../pos/block-proposal/index.md" | 69 - .../consensus-mechanisms/pos/faqs/index.md" | 172 -- .../consensus-mechanisms/pos/gasper/index.md" | 52 - .../docs/consensus-mechanisms/pos/index.md" | 99 - .../consensus-mechanisms/pos/keys/index.md" | 96 - .../pos/pos-vs-pow/index.md" | 69 - .../pos/rewards-and-penalties/index.md" | 90 - .../pos/weak-subjectivity/index.md" | 39 - .../docs/consensus-mechanisms/poa/index.md" | 79 - .../docs/consensus-mechanisms/pow/index.md" | 109 - .../consensus-mechanisms/pow/mining/index.md" | 81 - .../dagger-hashimoto/index.md" | 334 ---- .../mining/mining-algorithms/ethash/index.md" | 1014 ---------- .../pow/mining/mining-algorithms/index.md" | 37 - .../developers/docs/apis/backend/index.md" | 207 -- .../developers/docs/apis/javascript/index.md" | 295 --- .../developers/docs/apis/json-rpc/index.md" | 1773 ----------------- .../block-explorers/index.md" | 258 --- .../docs/data-and-analytics/index.md" | 55 - .../docs/development-networks/index.md" | 73 - .../developers/docs/ethereum-stack/index.md" | 61 - .../developers/docs/frameworks/index.md" | 149 -- .../developers/docs/ides/index.md" | 64 - .../docs/programming-languages/dart/index.md" | 28 - .../programming-languages/delphi/index.md" | 56 - .../programming-languages/dot-net/index.md" | 86 - .../programming-languages/elixir/index.md" | 55 - .../programming-languages/golang/index.md" | 84 - .../docs/programming-languages/index.md" | 30 - .../docs/programming-languages/java/index.md" | 65 - .../javascript/index.md" | 73 - .../programming-languages/python/index.md" | 90 - .../docs/programming-languages/ruby/index.md" | 61 - .../docs/programming-languages/rust/index.md" | 63 - .../developers/docs/storage/index.md" | 216 -- .../hu/19) Learn Pages 2/glossary/index.md | 499 ----- .../hu/19) Learn Pages 2/history/index.md | 623 ------ .../docs/smart-contracts/anatomy/index.md" | 658 ------ .../docs/smart-contracts/compiling/index.md" | 282 --- .../docs/smart-contracts/deploying/index.md" | 81 - .../developers/docs/smart-contracts/index.md" | 112 -- .../docs/smart-contracts/languages/index.md" | 326 --- .../docs/smart-contracts/libraries/index.md" | 117 -- .../docs/smart-contracts/security/index.md" | 580 ------ .../smart-contracts/composability/index.md" | 76 - .../formal-verification/index.md" | 283 --- .../docs/smart-contracts/testing/index.md" | 308 --- .../docs/smart-contracts/upgrading/index.md" | 165 -- .../docs/smart-contracts/verifying/index.md" | 107 - .../hu/21) Whitepaper/whitepaper/index.md | 517 ----- .../developers/docs/bridges/index.md | 135 -- .../index.md | 118 -- .../docs/data-availability/index.md | 84 - .../dex-design-best-practice/index.md | 220 -- .../heuristics-for-web3/index.md | 138 -- .../developers/docs/design-and-ux/index.md | 92 - .../developers/docs/mev/index.md | 221 -- .../developers/docs/oracles/index.md | 433 ---- .../developers/docs/standards/index.md | 59 - .../docs/standards/tokens/erc-1155/index.md | 146 -- .../docs/standards/tokens/erc-20/index.md | 172 -- .../docs/standards/tokens/erc-223/index.md | 197 -- .../docs/standards/tokens/erc-4626/index.md | 211 -- .../docs/standards/tokens/erc-721/index.md | 244 --- .../docs/standards/tokens/erc-777/index.md | 77 - .../developers/docs/standards/tokens/index.md | 39 - .../developers/docs/scaling/index.md" | 114 -- .../docs/scaling/optimistic-rollups/index.md" | 269 --- .../developers/docs/scaling/plasma/index.md" | 175 -- .../docs/scaling/sidechains/index.md" | 73 - .../docs/scaling/state-channels/index.md" | 67 - .../docs/scaling/validium/index.md" | 165 -- .../docs/scaling/zk-rollups/index.md" | 259 --- .../data-structures-and-encoding/index.md | 32 - .../patricia-merkle-trie/index.md | 263 --- .../data-structures-and-encoding/rlp/index.md | 163 -- .../data-structures-and-encoding/ssz/index.md | 149 -- .../web3-secret-storage-definition/index.md | 189 -- .../developers/docs/networking-layer/index.md | 155 -- .../network-addresses/index.md | 38 - .../networking-layer/portal-network/index.md | 89 - .../hu/26) Miscellaneous/about/index.md | 129 -- .../hu/26) Miscellaneous/enterprise/index.md | 161 -- .../hu/26) Miscellaneous/foundation/index.md | 40 - .../contributing/design-principles/index.md | 93 - .../contributing/design/index.md | 77 - .../hu/27) Contributing/contributing/index.md | 117 -- .../translation-program/faq/index.md | 119 -- .../how-to-translate/index.md | 89 - .../contributing/translation-program/index.md | 90 - .../mission-and-vision/index.md | 25 - .../translation-program/resources/index.md | 45 - .../translators-guide/index.md | 293 --- .../adding-desci-projects/index.md | 44 - .../adding-developer-tools/index.md | 61 - .../contributing/adding-exchanges/index.md | 40 - .../adding-glossary-terms/index.md | 26 - .../contributing/adding-layer-2s/index.md | 97 - .../contributing/adding-products/index.md | 100 - .../adding-staking-products/index.md | 176 -- .../contributing/adding-wallets/index.md | 80 - .../contributing/content-resources/index.md | 32 - .../design/adding-design-resources/index.md | 69 - .../contributing/quizzes/index.md | 62 - 179 files changed, 27076 deletions(-) delete mode 100644 public/content/translations/hu/04) Exploring/nft/index.md delete mode 100644 public/content/translations/hu/05) Use Ethereum Pages/dao/index.md delete mode 100644 public/content/translations/hu/06) Use Cases/defi/index.md delete mode 100644 public/content/translations/hu/06) Use Cases/smart-contracts/index.md delete mode 100644 public/content/translations/hu/06) Use Cases/web3/index.md delete mode 100644 public/content/translations/hu/07) Staking Pages/staking/dvt/index.md delete mode 100644 public/content/translations/hu/07) Staking Pages/staking/pools/index.md delete mode 100644 public/content/translations/hu/07) Staking Pages/staking/saas/index.md delete mode 100644 public/content/translations/hu/07) Staking Pages/staking/solo/index.md delete mode 100644 public/content/translations/hu/07) Staking Pages/staking/withdrawals/index.md delete mode 100644 public/content/translations/hu/08) Use cases 2/decentralized-identity/index.md delete mode 100644 public/content/translations/hu/08) Use cases 2/desci/index.md delete mode 100644 public/content/translations/hu/08) Use cases 2/refi/index.md delete mode 100644 public/content/translations/hu/08) Use cases 2/social-networks/index.md delete mode 100644 public/content/translations/hu/09) Learn Pages/bridges/index.md delete mode 100644 public/content/translations/hu/09) Learn Pages/energy-consumption/index.md delete mode 100644 public/content/translations/hu/09) Learn Pages/governance/index.md delete mode 100644 public/content/translations/hu/09) Learn Pages/security/index.md delete mode 100644 public/content/translations/hu/09) Learn Pages/zero-knowledge-proofs/index.md delete mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md delete mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md delete mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md delete mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md delete mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md delete mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md delete mode 100644 public/content/translations/hu/10) Guides and Quizzes/guides/index.md delete mode 100644 public/content/translations/hu/11) Roadmap/eips/index.md delete mode 100644 public/content/translations/hu/11) Roadmap/roadmap/beacon-chain/index.md delete mode 100644 public/content/translations/hu/11) Roadmap/roadmap/future-proofing/index.md delete mode 100644 public/content/translations/hu/11) Roadmap/roadmap/index.md delete mode 100644 public/content/translations/hu/11) Roadmap/roadmap/merge/index.md delete mode 100644 public/content/translations/hu/11) Roadmap/roadmap/merge/issuance/index.md delete mode 100644 public/content/translations/hu/11) Roadmap/roadmap/scaling/index.md delete mode 100644 public/content/translations/hu/11) Roadmap/roadmap/security/index.md delete mode 100644 public/content/translations/hu/11) Roadmap/roadmap/user-experience/index.md delete mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/account-abstraction/index.md delete mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/danksharding/index.md delete mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/dencun/index.md delete mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/pbs/index.md delete mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/secret-leader-election/index.md delete mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/single-slot-finality/index.md delete mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/statelessness/index.md delete mode 100644 public/content/translations/hu/12) Roadmap 2/roadmap/verkle-trees/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/accounts/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/blocks/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/dapps/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/evm/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/evm/opcodes/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/gas/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ether/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/networks/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/transactions/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/web2-vs-web3/index.md delete mode 100644 public/content/translations/hu/13) Foundational Docs/developers/docs/wrapped-eth/index.md delete mode 100644 public/content/translations/hu/14) Community Pages/community/code-of-conduct/index.md delete mode 100644 public/content/translations/hu/14) Community Pages/community/events/index.md delete mode 100644 public/content/translations/hu/14) Community Pages/community/get-involved/index.md delete mode 100644 public/content/translations/hu/14) Community Pages/community/grants/index.md delete mode 100644 public/content/translations/hu/14) Community Pages/community/language-resources/index.md delete mode 100644 public/content/translations/hu/14) Community Pages/community/online/index.md delete mode 100644 public/content/translations/hu/14) Community Pages/community/research/index.md delete mode 100644 public/content/translations/hu/14) Community Pages/community/support/index.md delete mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" delete mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" delete mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" delete mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" delete mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" delete mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" delete mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" delete mode 100644 "public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" delete mode 100644 "public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" delete mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" delete mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" delete mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" delete mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" delete mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" delete mode 100644 "public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/elixir/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" delete mode 100644 "public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" delete mode 100644 public/content/translations/hu/19) Learn Pages 2/glossary/index.md delete mode 100644 public/content/translations/hu/19) Learn Pages 2/history/index.md delete mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" delete mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" delete mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" delete mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" delete mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" delete mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" delete mode 100644 "public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" delete mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" delete mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" delete mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" delete mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" delete mode 100644 "public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" delete mode 100644 public/content/translations/hu/21) Whitepaper/whitepaper/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/bridges/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/mev/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/oracles/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md delete mode 100644 public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/index.md delete mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" delete mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" delete mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" delete mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" delete mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" delete mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" delete mode 100644 "public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" delete mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md delete mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md delete mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md delete mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md delete mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md delete mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/index.md delete mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md delete mode 100644 public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md delete mode 100644 public/content/translations/hu/26) Miscellaneous/about/index.md delete mode 100644 public/content/translations/hu/26) Miscellaneous/enterprise/index.md delete mode 100644 public/content/translations/hu/26) Miscellaneous/foundation/index.md delete mode 100644 public/content/translations/hu/27) Contributing/contributing/design-principles/index.md delete mode 100644 public/content/translations/hu/27) Contributing/contributing/design/index.md delete mode 100644 public/content/translations/hu/27) Contributing/contributing/index.md delete mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/faq/index.md delete mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/how-to-translate/index.md delete mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/index.md delete mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/mission-and-vision/index.md delete mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/resources/index.md delete mode 100644 public/content/translations/hu/27) Contributing/contributing/translation-program/translators-guide/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-desci-projects/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-developer-tools/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-exchanges/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-glossary-terms/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-layer-2s/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-products/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-staking-products/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/adding-wallets/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/content-resources/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/design/adding-design-resources/index.md delete mode 100644 public/content/translations/hu/28) Contributing 2/contributing/quizzes/index.md diff --git a/public/content/translations/hu/04) Exploring/nft/index.md b/public/content/translations/hu/04) Exploring/nft/index.md deleted file mode 100644 index 9784c538761..00000000000 --- a/public/content/translations/hu/04) Exploring/nft/index.md +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Nem helyettesíthető tokenek (NFT-k) -description: Az NFT-k áttekintése az Ethereum hálózaton -lang: hu -template: use-cases -emoji: ":frame_with_picture:" -sidebarDepth: 2 -image: /images/infrastructure_transparent.png -alt: Egy Eth logó, amely hologram segítségével jelenik meg. -summaryPoint1: Egy módszer arra, hogy egyedi dolgokat Ethereum alapú javakként jelenítsünk meg. -summaryPoint2: Az NFT-k minden korábbinál nagyobb hatalmat adnak a tartalomgyártók kezébe. -summaryPoint3: Az Ethereum blokklánc okosszerződései által működtetve. ---- - -## Mik azok a nem helyettesíthető tokenek (NFT)? {#what-are-nfts} - -Az NFT-k olyan tokenek, amelyek **egyedileg egyediek**. Minden egyes NFT más jellemzőkkel bír (nem helyettesíthető) és bizonyítottan véges. Ez eltér az olyan tokenektől, mint például az [ETH](/glossary/#ether) vagy más Ethereum alapú tokenek, például az USDC, ahol minden token azonos és ugyanazokkal a tulajdonságokkal rendelkezik („cserélhető”). Nem számít, hogy az ember pénztárcájában konkrétan amelyik bankjegy (vagy ETH) található, mert mindegyik azonos és ugyanolyan értékű. Az azonban _valóban_ számít, hogy Ön melyik NFT-t birtokolja, mert egyedi jellemzőik megkülönböztetik azokat egymástól (nem helyettesíthető). - -Az NFT-k egyedisége révén akár műtárgyak, gyűjthető tárgyak vagy ingatlanok is tokenné alakíthatók. Ekkor egy adott egyedi NFT egy specifikus, egyedi, valós vagy digitális tárgyat képvisel. Egy eszköz tulajdonjoga nyilvánosan ellenőrizhető az Ethereum [blokkláncán](/glossary/#blockchain). - - - -## Az eszközök internete {#internet-of-assets} - -Az NFT-k és az Ethereum megoldást jelent néhány, napjainkban az interneten jelen lévő problémára. Ahogy minden egyre digitálisabbá válik, egyre inkább szükség van a fizikai tárgyak bizonyos tulajdonságainak replikálására, mint például a ritkaság, az egyediség és a tulajdonjog bizonyítása úgy, hogy azt nem egy központi szervezet irányítja. Az NFT-kkel például bárki birtokolhat egy mp3-formátumú zeneszámot egyszerre minden Ethereum-alapú alkalmazásban, és nincs hozzákötve egy adott vállalat zenei alkalmazásához, mint amilyen a Spotify vagy az Apple Music. Ön birtokolhat egy közösségi média fogantyút, amelyet eladhat vagy cserélhet, de **nem veheti el önkényesen** egy platformszolgáltató. - -Így néz ki az NFT-k internete ahhoz az internethez képest, amelyet a többségünk minden nap használ... - -### Összehasonlítás {#nft-comparison} - -| Az NFT-k internete | Az internet ma | -| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Ön birtokolja eszközeit!** Csak Ön adhatja el vagy cserélheti el azokat. | **Ön kikölcsönöz egy eszközt** valamely szervezettől, és azt el is vehetik Öntől. | -| Az NFT-k **digitálisan egyediek**, nincs két egyforma NFT. | **A másolat gyakran nem különböztethető meg** az eredetitől. | -| Az NFT tulajdonjogát a blokklánc tárolja, hogy bárki **nyilvánosan ellenőrizhesse**. | A digitális tételek tulajdonjogi nyilvántartásához való hozzáférést **intézmények ellenőrzik** – azaz szót kell fogadnia. | -| Az NFT-k [okosszerződések](/glossary/#smart-contract) az Ethereumon. Ez azt jelenti, hogy **így könnyen fel lehet azokat használni más okosszerződésekben** és alkalmazásokban az Ethereumon! | A digitális cikkekkel foglalkozó cégek általában **saját „falazott kerti” infrastruktúrát igényelnek**. | -| A tartalom **alkotói bárhol eladhatják munkáikat**, és hozzáférhetnek a globális piachoz. | Az alkotók csak annak a felületnek a hálózatára és disztribúciójára támaszkodhatnak, amelyet használnak. Ezekre gyakran használati feltételek és **földrajzi korlátozások** vonatkoznak. | -| Az NFT alkotói **megtarthatják a tulajdonjogot** saját munkáik felett, és a jogdíjakat közvetlenül az NFT-szerződésbe írhatják be. | A platformok, például a zenei **streaming szolgáltatások, megtartják az értékesítésből származó nyereség nagy részét**. | - -## Mire használják az NFT-ket? {#nft-use-cases} - -Az NFT-ket számtalan esetben használják, ilyen például: - -- egy eseményen való részvétel igazolása -- egy elvégzett képzés bizonyítványa -- a játékokban birtokolható dolgok -- digitális művészet -- valós tárgyak tokenizálása -- online személyazonosság bizonyítása -- hozzáférés bizonyos tartalmakhoz -- jegyek -- decentralizált internetes domainnevek -- biztosíték a [decentralizált finanszírozásban](/glossary/#defi) - -Tegyük fel, hogy Ön egy művész, aki szeretné NFT-ként megosztani az alkotását, anélkül hogy elveszítené az ellenőrzést felette és közvetítőkre áldozná a profitját. Létrehozhat egy új szerződést, amelyben megadja az NFT-k számát, jellemzőiket, és hozzákapcsolja az adott műalkotást. Művészként **beprogramozhatja az intelligens szerződésbe a fizetendő jogdíjakat** (pl. az eladási ár 5%-át utalja át a szerződés tulajdonosának minden alkalommal, amikor NFT-t utalnak át). Azt is mindig bizonyíthatja, hogy Ön hozta létre az NFT-ket, mert Ön a [pénztárca](/glossary/#wallet) tulajdonosa, amely a szerződést telepítette. Vásárlói könnyen igazolhatják, hogy egy **hiteles NFT-vel** rendelkeznek az Ön gyűjteményéből, mert pénztárcájuk [címe](/glossary/#address) az intelligens szerződésben szereplő tokenhez van társítva. Az egész Ethereum-ökoszisztémában használhatják az NFT-t, teljes bizonyossággal az eredetiségét illetően. - - -
Fedezzen fel, vásároljon vagy készítsen saját NFT-műalkotásokat/gyűjthető tárgyakat...
- - Fedezzen fel NFT-műalkotásokat - - - -Vagy vegyünk például egy sporteseményre szóló jegyet. Ahogy egy **egy esemény szervezője kiválaszthatja, hogy hány jegyet adjon el**, az NFT létrehozója eldöntheti, hogy hány replika létezik. Néha ezek pontos másolatok, mint például 5000 darab nem helyre szóló belépőjegy. Néha több olyan jegyet is kiállítanak, amelyek nagyon hasonlóak, de mindegyik kissé különbözik, mint például kijelölt ülőhelyekre szóló jegyek. Ezeket vehetik és adhatják egymás között (peer-to-peer módon) anélkül, hogy fizetni kellene a jegyárusoknak, a vevő pedig a szerződés címét ellenőrizve mindig meggyőződhet a jegyek eredetiségéről. - -Az ethereum.org webhelyen az **NFT-k segítségével demonstrálják, hogy az emberek érdemben hozzájárultak** a Github-tárhelyünkhöz (programozták a webhelyet, írtak vagy módosítottak egy cikket...), lefordították tartalmainkat vagy részt vettek közösségi felhívásainkon, és még saját NFT domain nevünk is van. Ha hozzájárul az ethereum.org oldalhoz, igényelhet [POAP](/glossary/#poap) NFT-t. Bizonyos kriptotalálkozók POAP-ot (részvételt tanúsító protokollt) használnak jegy gyanánt. [Tudjon meg többet a hozzájárulásról](/contributing/#poap). - -![ethereum.org POAP](./poap.png) - -Ez a weboldal egy alternatív, NFT-k által működtetett domainnévvel is rendelkezik: **ethereum.eth**. Az `.org` címünket központilag egy domainnévrendszer (DNS) szolgáltató kezeli, míg az ethereum`.eth` cím az Ethereum Name Service (ENS) szolgáltatáson keresztül van regisztrálva az Ethereumra. Ezt a mi tulajdonunkban van, és mi kezeljük. [Tekintse meg az ENS-adatainkat](https://app.ens.domains/name/ethereum.eth) - -[Bővebben az ENS-ről](https://app.ens.domains) - - - -## Hogyan működnek az NFT-k? {#how-nfts-work} - -Az NFT-k, ahogy az Ethereum-blokklánc többi digitális eszköze, egy speciális, Ethereum-alapú számítógépes program révén keletkeznek, amelyet okosszerződésnek neveznek. Ezek a szerződések bizonyos szabályokat követnek, például az [ERC-721](/glossary/#erc-721) vagy az [ERC-1155](/glossary/#erc-1155) szabványt, amelyek meghatározzák, hogy a szerződés mire képes. - -Az NFT-okosszerződésekkel számos fontos dolog végrehajtható: - -- **NFT-k létrehozása:** Új NFT-ket lehet alkotni. -- **Tulajdonjog meghatározása:** Követi, hogy amely NFT-nek ki a birtokosa azáltal, hogy azokat meghatározott Ethereum-címekhez köti. -- **Minden NFT-hez azonosítót rendel:** Az NFT-k egy egyedi számmal is el vannak látva. Emellett általában más információkat (metaadatokat) is hozzákapcsolnak az NFT-khez, amellyel feltárják, hogy mit is képviselnek. - -Amikor valaki létrehoz vagy „mintel” egy NFT-t, akkor gyakorlatilag arra kéri az okosszerződést, hogy adjon neki tulajdonjogot egy bizonyos NFT felett. Ez az információ biztos módon és nyilvánosan van tárolva a blokkláncon. - -Ezenkívül a szerződés létrehozója más szabályokat is megadhat. Meghatározhatja, hogy egy adott NFT-ből mennyit lehet létrehozni vagy megadhatja, hogy amikor az NFT tulajdonost vált, akkor egy kis összegű jogdíj járjon neki. - -### Az NFT-k biztonsága {#nft-security} - -Az Ethereum biztonsága a [tét igazolásából](/glossary/#pos) származik. A rendszert úgy tervezték, hogy gazdaságilag visszatartson a rosszindulatú cselekedetektől, így az Ethereum hamisíthatatlan. Ennek köszönhetően létezhetnek az NFT-k. Miután az NFT-tranzakciót tartalmazó [blokk](/glossary/#block) [végleges lesz](/glossary/#finality), a támadónak több millió ETH-jába kerülne annak megváltoztatása. Bárki, aki Ethereum-szoftvert futtat, azonnal képes lenne észlelni az NFT tisztességtelen manipulálását, és a csalárd szereplőt gazdaságilag megbüntetnék és kizárnák. - -Az NFT-kkel kapcsolatos biztonsági problémák leggyakrabban adathalász csalásokhoz, az okosszerződések sebezhetőségéhez vagy felhasználói hibákhoz (például a privát kulcsok véletlen felfedéséhez) kapcsolódnak, így a megfelelő tárcabiztonság kritikus fontosságú az NFT-tulajdonosok számára. - - - Bővebben a biztonságról - - -## További olvasnivaló {#further-reading} - -- [Útmutató az NFT-kről kezdőknek](https://linda.mirror.xyz/df649d61efb92c910464a4e74ae213c4cab150b9cbcc4b7fb6090fc77881a95d) – _Linda Xie, 2020. január _ -- [EtherscanNFT trekker](https://etherscan.io/nft-top-contracts) -- [ERC-721 tokenszabvány](/developers/docs/standards/tokens/erc-721/) -- [ERC-1155 tokenszabvány](/developers/docs/standards/tokens/erc-1155/) -- [Népszerű NFT-applikációk és -eszközök](https://www.ethereum-ecosystem.com/blockchains/ethereum/nfts) - -## Egyéb források {#other-resources} - -- [NFTScan](https://nftscan.com/) - - - - diff --git a/public/content/translations/hu/05) Use Ethereum Pages/dao/index.md b/public/content/translations/hu/05) Use Ethereum Pages/dao/index.md deleted file mode 100644 index 24808b91146..00000000000 --- a/public/content/translations/hu/05) Use Ethereum Pages/dao/index.md +++ /dev/null @@ -1,166 +0,0 @@ ---- -title: Decentralizált autonóm szervezetek (DAO-k) -description: Az Ethereumon működő DAO-k áttekintése -lang: hu -template: use-cases -emoji: ":handshake:" -sidebarDepth: 2 -image: /images/use-cases/dao-2.png -alt: Egy javaslatra történő DAO-szavazat ábrázolása. -summaryPoint1: Tagtulajdonú közösségek központi vezetők nélkül. -summaryPoint2: Biztonságos módja az interneten történő, ismeretlenekkel való együttműködésnek. -summaryPoint3: Egy biztonságos hely, ahol pénzét adott célokra fordíthatja. ---- - -## Mik azok a DAO-k? {#what-are-daos} - -A DAO egy közös tulajdonú szervezet, amely egy közös küldetésért dolgozik. - -A DAO-k lehetőséget biztosítanak számunkra, hogy hozzánk hasonló elhivatottságú emberekkel dolgozzunk a világ minden tájáról anélkül, hogy egy központi vezetőre bíznánk a pénzügyi és operatív működtetést. Nincs olyan vezérigazgató, aki a kedve szerint költhetné el az alapokat, vagy olyan pénzügyi vezető, aki manipulálhatná a könyvelést. Helyette a kódba épített, blokkláncon alapuló szabályok határozzák meg, hogyan működik a szervezet és kerülnek elköltésre az alapok. - -Beépített pénztárakkal rendelkeznek, amelyekhez a csoport jóváhagyása nélkül senkinek sincs jogosultsága hozzáférni. A döntéseket a javaslatok és a szavazás szabályozzák, így biztosítva, hogy a szervezetben mindenki megszólaljon, és minden átláthatóan, [láncon belül](/glossary/#on-chain) történjen. - -## Miért van szükségünk DAO-kra? {#why-dao} - -Egy pénzügyi forrásokat és pénzt igénylő szervezet indítása nagyon sok bizalmat igényel azon emberek vonatkozásában, akikkel együtt dolgozunk. Azonban nehéz megbízni valakiben, akivel csak az interneten keresztül léptünk kapcsolatba. A DAO-k esetében nem kell megbíznia a csoport többi tagjában, kizárólag a DAO kódjában, mely 100%-ban átlátható és bárki által ellenőrizhető. - -Ennek köszönhetően rengeteg lehetőség nyílik meg a globális együttműködésre és koordinációra. - -### Összehasonlítás {#dao-comparison} - -| DAO | Egy hagyományos szervezet | -| --------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | -| Általában lapos és teljesen demokratizált. | Rendszerint hierarchikus. | -| Bármely változtatás végrehajtásához a tagok szavazata szükséges. | A felépítésen alapszik, egyetlen tagtól is követelhető változás, vagy szavazásra is bocsátható a kérdés. | -| A szavazatokat összeszámolják, a szavazás eredményét pedig automatikusan végrehajtják egy megbízott közvetítő nélkül. | Ha megengedett a szavazás, akkor a szavazatokat a szervezeten belül összeszámolják, a szavazás eredményét pedig manuálisan végrehajtják. | -| A szolgáltatásokat automatikusan, decentralizált módon kezelik (például a humanitárius források elosztása). | Emberi közbenjárást igényel, vagy egy központilag irányított automata mechanizmus működteti, mely visszaélésre adhat lehetőséget. | -| Minden tevékenység átlátható és teljesen nyilvános. | A tevékenység jellemzően nem nyilvános, így korlátozott betekintést ad a nyilvánosság számára. | - -### Példák a DAO-ra {#dao-examples} - -Annak érdekében, hogy még érthetőbbé tegyük a DAO-k működését, az alábbiakban néhány példán keresztül bemutatjuk, mire is használhatók: - -- **Egy jótékonysági szervezet** – adományokat fogadhat el a világon bárkitől, és szavazhat arról, hogy mely célokat finanszírozza. -- **Közös tulajdonjog** – vásárolhat fizikai vagy digitális eszközöket, és a tagok szavazhatnak a használatukról. -- **Kockázati tőke és támogatás** – létrehozhat egy kockázatitőke-alapot, mely befektetési tőkét gyűjt, és szavazással válaszhatók ki a támogatandó vállalkozások. A visszaérkező összegeket pedig később szétoszthatják a DAO tagjai között. - - - -## Hogyan működnek a DAO-k? {#how-daos-work} - -A DAO gerincét az [intelligens szerződés](/glossary/#smart-contract) adja, amely meghatározza a szervezet szabályait és birtokolja a csoport pénztárát. Amint a szerződés életbe lép az Ethereumon, csakis szavazás útján lehet módosítani a szabályokat. Ha valaki olyat próbál tenni, ami nem szerepel a szabályokban és a programlogikában, az meghiúsul. Mivel a társaság pénzügyeit is az okosszerződés határozza meg, ezért a csoport jóváhagyása nélkül senki sem költheti el a pénzösszegeket. Tehát a DAO-nak nincs szüksége központi hatóságra. Ehelyett a csoport közösen hoz döntéseket, a kifizetések pedig automatikusan jóváhagyásra kerülnek a szavazás eredményeként. - -Mindez azért lehetséges, mert az okosszerződést nem lehet önkényesen megváltoztatni vagy meghamisítani, amikor már életbe lépett az Ethereumon. Senki sem tudja módosítani a programkódot (a DAO szabályait) anélkül, hogy mások azt észre ne vennék, mivel minden nyilvános. - -## Az Ethereum és a DAO-k {#ethereum-and-daos} - -Az Ethereum tökéletes alapot szolgáltat a DAO-knak számtalan okból kifolyólag: - -- Az Ethereum saját konszenzusa decentralizált és eléggé megalapozott ahhoz, hogy a szervezetek megbízhassanak a hálózatban. -- Az okosszerződés tartalmát nem lehet módosítani, miután életbe lépett, még a tulajdonosok sem módosíthatják azt. Ennek következtében a DAO a meghatározott szabályok alapján fog működni. -- Az okosszerződések képesek pénzeszközöket küldeni és fogadni. Enélkül szükség lenne egy megbízható közvetítőre, aki a csoport eszközeit kezelné. -- Az Ethereum közössége bizonyítottan együttműködő, nem versenyszellemű, így a bevált gyakorlatok és a támogatórendszerek gyorsan kialakulnak. - -## A DAO irányítása {#dao-governance} - -A DAO irányításakor számtalan szempontot figyelembe kell venni, mint például a szavazás menete és a javaslatok kezelése. - -### Delegáció {#governance-delegation} - -A delegáció vagy felhatalmazás a DAO verziója a képviselőalapú demokráciának. A tokenek birtokosai átadják szavazati jogaikat olyan felhasználóknak, akik vállalják, hogy felügyelik a protokollt és tájékozódnak az ügyeket illetően. - -#### Egy híres példa {#governance-example} - -[ENS](https://claim.ens.domains/delegate-ranking) – Az ENS-tulajdonosok átruházhatják szavazataikat a közösség elkötelezett tagjaira, hogy képviseljék őket. - -### Automatikus tranzakciókon alapuló irányítás {#governance-example} - -Számos DAO-nál a tranzakciók automatikusan végrehajtódnak, ha a tagok határozatképes létszámban megszavazzák azt. - -#### Egy híres példa {#governance-example} - -[Főnevek](https://nouns.wtf) – A Nouns DAO-ban a tranzakció automatikusan végrehajtásra kerül, ha a szavazatok határozatképessége teljesül, és a többség igennel szavaz, mindaddig, amíg az alapítók nem vétózzák meg. - -### Több aláírásos irányítás {#governance-example} - -Míg a DAO-k több ezer szavazati joggal rendelkező taggal rendelkezhetnek, az alapok egy [pénztárcában](/glossary/#wallet) élhetnek, amelyen 5-20 aktív közösségtag osztozik, akikben megbíznak és általában doxxelnek (a közösség által ismert nyilvános identitások). Szavazás után a [multisig](/glossary/#multisig) aláírók végrehajtják a közösség akaratát. - -## A DAO törvényei {#dao-laws} - -1977-ben Wyoming megalkotta a korlátolt felelősségű társasági formát, mely megvédi a vállalkozót és behatárolja a felelősségi körüket. Nemrég elsőként hozták létre a DAO-kra vonatkozó törvényt, mely jogi státuszt ad a DAO-knak. Jelenleg Wyoming, Vermont és a Virgin-szigetek rendelkeznek DAO-törvénnyel valamilyen formában. - -### Egy híres példa {#law-example} - -[CityDAO](https://citydao.io) – A CityDAO 40 hektár földet vett a Yellowstone Nemzeti Park közelében Wyoming DAO-törvényével élve. - -## DAO-tagság {#dao-membership} - -A DAO-tagságra különféle modellek léteznek. A tagság meghatározza a szavazás menetét, illetve a DAO más kulcsfontosságú részleteit. - -### Tokenalapú tagság {#token-based-membership} - -Általában teljesen [engedély nélküli](/glossary/#permissionless), a használt tokentől függően. Ezekkel az irányítási tokenekkel többnyire engedély nélkül lehet kereskedni [decentralizált tőzsdén](/glossary/#dex). Más tokenek megszerzéséhez likviditást kell biztosítani vagy más munkaigazolás (proof-of-work) szükséges. Bármelyik módon is jut hozzá, a token maga biztosítja a szavazati jogot. - -_Főleg arra használják, hogy kiterjedt, decentralizált protokollokat és/vagy magukat a tokeneket irányítsák ezáltal._ - -#### Egy híres példa {#token-example} - -[MakerDAO](https://makerdao.com) – A MakerDAO tokenje, az MKR, széles körben elérhető a decentralizált tőzsdéken, s bárki beszerezheti azokat, hogy szavazati jogot nyerjen a Maker protokoll jövőjére vonatkozóan. - -### Részesedésalapú tagság {#share-based-membership} - -A részesedésalapú DAO-k sokkal inkább engedélyhez kötöttek, de még mindig elég nyitottak. Bármelyik leendő tag beadhat egy csatlakozási kérvényt, melyben általában felajánl valamilyen értéket tokenek vagy elvégzendő munka (például számítási kapacitás) formájában. A részesedés közvetlen szavazati és tulajdonjogot jelent. A tagok bármikor kiléphetnek az arányos részesedésükkel együtt. - -_Főleg a szorosabb szerveződésű, emberközpontú szervezetek használják, mint az adománygyűjtők, munkaközösségek és befektetési klubok. Ezt is használhatják protokollok és tokenek irányítására._ - -#### Egy híres példa {#share-example} - -[MolochDAO](http://molochdao.com/) – A MolochDAO az Ethereum projektek finanszírozására összpontosít. A tagságot kérvényezni kell, melynek alapján a csoport eldönti, vajon az új tag rendelkezik a szükséges szakértelemmel és tőkével, hogy megfelelő döntést tudjon hozni a lehetséges támogatottakról. Nem lehetséges megvásárolni a DAO-tagságot a piacon. - -### Reputációalapú tagság {#reputation-based-membership} - -A reputáció a részvételt igazolja és szavazati jogot biztosít a DAO-ban. A token- és részesedésalapú tagsággal ellentétben a reputációalapú DAO nem ad tulajdonjogot a közreműködőknek. A reputációt nem lehet megvenni, átadni vagy delegálni; a DAO tagok a részvételükkel nyerik el azt. A láncon belüli szavazás nem engedélyhez kötött, a leendő tagok szabadon kérvényezhetik a DAO-hoz való csatlakozást, illetve azt, hogy a közreműködésükért cserébe reputációt és tokent kapjanak. - -_Jellemzően protokollok és [dapp-ok](/glossary/#dapp) decentralizált fejlesztésére és irányítására használják, de kiválóan alkalmas különféle szervezetek, például jótékonysági szervezetek, munkavállalói kollektívák, befektetési klubok stb. számára is_ - -#### Egy híres példa {#reputation-example} - -[DXdao](https://DXdao.eth.limo) – A DXdao egy független globális csoportosulás, amely 2019 óta épít és irányít decentralizált protokollokat és alkalmazásokat. A hírnév alapú kormányzást és a [holografikus konszenzust](/glossary/#holographic-consensus) használja az alapok koordinálásához és kezeléséhez, ami azt jelenti, hogy senki sem vásárolhatja meg a tagságot a szervezet jövőjének vagy irányításának befolyásolása céljából. - -## Csatlakozás DAO-hoz / DAO indítása {#join-start-a-dao} - -### Csatlakozzon egy DAO-hoz {#join-a-dao} - -- [Az Ethereum-közösséghez tartozó DAO-k](/community/get-involved/#decentralized-autonomous-organizations-daos) -- [DAOHaus által listázott DAO-k](https://app.daohaus.club/explore) -- [Tally.xyz által listázott DAO-k](https://www.tally.xyz) - -### DAO indítása {#start-a-dao} - -- [Indítson DAO-t a DAOHaus-szal](https://app.daohaus.club/summon) -- [Indítson irányító DAO-t a Tally-vel](https://www.tally.xyz/add-a-dao) -- [Hozzon létre egy Aragon által működtetett DAO-t](https://aragon.org/product) -- [Hozzon létre csoportot a Colony-val](https://colony.io/) -- [Indítson DAO-t a DAOstack által biztosított holografikus konszenzussal](https://alchemy.daostack.io/daos/create) - -## További információ {#further-reading} - -### DAO-ról szóló cikkek {#dao-articles} - -- [Mi az a DAO?](https://aragon.org/dao) – [Aragon](https://aragon.org/) -- [DAO-k háza](https://wiki.metagame.wtf/docs/great-houses/house-of-daos) – [Metagame](https://wiki.metagame.wtf/) -- [Mi az a DAO és mire jó?](https://daohaus.substack.com/p/-what-is-a-dao-and-what-is-it-for) – [DAOhaus](https://daohaus.club/) -- [Hogyan lehet létrehozni egy DAO által működtetett digitális közösséget](https://daohaus.substack.com/p/four-and-a-half-steps-to-start-a) – [DAOhaus](https://daohaus.club/) -- [Mi az a DAO?](https://coinmarketcap.com/alexandria/article/what-is-a-dao) – [Coinmarketcap](https://coinmarketcap.com) -- [Mi az a holografikus konszenzus?](https://medium.com/daostack/holographic-consensus-part-1-116a73ba1e1c) – [DAOstack](https://daostack.io/) -- [A DAO-k nem vállalatok: hol van a legnagyobb jelentősége a decentralizációnak az autonóm szervezetekben – Vitalik](https://vitalik.eth.limo/general/2022/09/20/daos.html) -- [DAO, DAC, DA és mások: egy nem teljes terminológiai útmutató](https://blog.ethereum.org/2014/05/06/daos-dacs-das-and-more-an-incomplete-terminology-guide) – [Ethereum Blog](https://blog.ethereum.org) - -### Videók {#videos} - -- [Mit jelent a DAO a kripto világában?](https://youtu.be/KHm0uUPqmVE) -- [Felépíthet egy várost egy DAO?](https://www.ted.com/talks/scott_fitsimones_could_a_dao_build_the_next_great_city) – [TED](https://www.ted.com/) - - - - diff --git a/public/content/translations/hu/06) Use Cases/defi/index.md b/public/content/translations/hu/06) Use Cases/defi/index.md deleted file mode 100644 index c800034cc64..00000000000 --- a/public/content/translations/hu/06) Use Cases/defi/index.md +++ /dev/null @@ -1,361 +0,0 @@ ---- -title: Decentralizált pénzügy (DeFi) -description: Az Ethereumon működő decentralizált pénzügyek (DeFi) áttekintése -lang: hu -template: use-cases -emoji: ":money_with_wings:" -image: /images/use-cases/defi.png -alt: Egy LEGO építőkockákból készült Ethereum-logó. -sidebarDepth: 2 -summaryPoint1: Egy globális és nyitott alternatívája a jelenlegi pénzügyi rendszernek. -summaryPoint2: Olyan termékek, melyek révén kölcsönözhet, megtakaríthat, befektethet, kereskedhet és ez még nem minden. -summaryPoint3: Nyíltforráskódú technológián alapszik, melyre bárki fejleszthet megoldásokat. ---- - -A decentralizált pénzügyek (DeFi) egy nyílt és globális pénzügyi rendszer, mely az internet korához igazodik – alternatívája annak, ami alig átlátható, szorosan kontrollált és sok évtizedes infrastruktúrák és folyamatok tartják össze. A DeFi kontrollt és átláthatóságot biztosít a pénzeszközök felett. Lehetőséget ad arra, hogy a globális piacokon működjön és alternatívát biztosít a helyi valuták vagy bankolási lehetőségek helyett. A DeFi termékek mindenki számára elérhetővé teszik a pénzügyi szolgáltatásokat, aki internetkapcsolattal rendelkezik, és nagy arányban maguk a felhasználók tulajdonolják és kezelik ezeket. Eddig több tízmilliárd dollárnyi kripto áramlott keresztül a DeFi alkalmazásokon, és ez minden egyes nappal növekszik. - -## Mi az a DeFi? {#what-is-defi} - -A DeFi egy gyűjtőfogalom azokra a pénzügyi termékekre és szolgáltatásokra vonatkozóan, melyek mindenki számára elérhetők az Ethereum hálózatát használva – bárkinek, aki rendelkezik internetkapcsolattal. A DeFi révén a piacok állandóan nyitva vannak és nincs olyan központi hatóság, amely megakadályozhatna egy kifizetést vagy megtilthatná a hozzáférést valamilyen termékhez. Azok a szolgáltatások, melyek korábban lassúak voltak és az emberi hiba kockázatát hordozták magukban, most automatikusak és biztonságokat, mivel egy olyan programkód üzemelteti azokat, melyet bárki megvizsgálhat. - -Egy gyorsan fejlődő kriptogazdaság található itt, ahol Ön is adhat és vehet fel kölcsönt, kereskedhet long/short pozíciókkal, kamatoztathat stb. A kriptóhoz értő argentinok arra használták a DeFi-t, hogy kilépjenek a bénító inflációs helyzetből. Bizonyos vállalatok elkezdték a munkavállalóik fizetést valós időben átutalni (streaming). Néhány személy több millió dollárt érő hitelt vett fel és fizetett vissza anélkül, hogy bármilyen módon igazolnia kellett volna a személyazonosságát. - - - -## A DeFi és a hagyományos pénzügyek összehasonlítása {#defi-vs-tradfi} - -A DeFi-ban rejlő lehetőségeket talán úgy lehet legjobban megragadni, ha megértjük a jelenlegi problémákat. - -- Az emberek egy bizonyos rétege nem nyithat bankszámlát vagy használhat pénzügyi szolgáltatásokat. -- Ha valaki nem fér hozzá a pénzügyi szolgáltatásokhoz, akkor nem is tud munkát vállalni. -- A pénzügyi szolgáltatások megakadályozhatják, hogy Ön hozzáférjen a pénzeszközeihez. -- A pénzügyi szolgáltatások egyik rejtett ára, hogy hozzáférnek a személyes adataihoz. -- A kormányok és központi hatóságok bármikor lezárhatják a pénzügyi piacokat. -- A kereskedés időszaka gyakran egy adott időzónában meghatározott munkaidőre korlátozódik. -- Az átutalások több napig is eltarthatnak a közbenső, manuális folyamatok miatt. -- A pénzügyi szolgáltatásokért extra díjat kell fizetni, mert a közvetítő intézmények is kiveszik a részüket. - -### Összehasonlítás {#defi-comparison} - -| DeFi | Hagyományos pénzügyek | -| ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -| Ön rendelkezik a saját pénzeszközei felett. | Az Ön pénze a vállalatok kezében van. | -| Ön dönti el, hogy a pénzét hol tartja és mire költi el. | Meg kell bíznia a vállalatokban, hogy nem élnek vissza a pénzeszközeivel, például nem adják kölcsön azokat kockázatos ügyfeleknek. | -| A pénzeszközök átutalása perceken belül megtörténik. | Az átutalás napokig is eltarthat a manuális lépések miatt. | -| A tranzakciók nem közvetlen módon köthetők a személyazonossághoz. | A pénzügyi tevékenységek szorosan kapcsolódnak az identitáshoz. | -| A DeFi mindenki előtt nyitva áll. | A pénzügyi szolgáltatásokat igényelni kell. | -| A pénzpiacok mindig nyitva vannak. | A pénzpiacok bezárnak, mert az alkalmazottaknak pihenésre van szükségük. | -| Az átláthatóságra épül – bárki megtekintheti az adott termék adatait és megvizsgálhatja, hogyan működik a rendszer. | A pénzügyi intézmények zárt könyvek számunkra: nem kérheti el senki a hitelezési feljegyzéseiket, az eszközeik leltárát stb. | - - - Fedezze fel a DeFi alkalmazásokat - - -## Minden a Bitcoinnal kezdődött... {#bitcoin} - -A Bitcoin több szempontból is az első DeFi alkalmazás volt. A Bitcoin lehetővé tette, hogy a felhasználó valóban birtokolja és kontrollálja az értéket, és elküldje azt a világon bárhova. Ehhez pedig egy olyan módszert adott egy nagy létszámú, egymásban nem bízó csoport kezébe, amellyel közvetítő megbízása nélkül egyezhetnek meg a számlafőkönyv tartalmán. A Bitcoin mindenki számára nyitott és senki sem tudja megváltoztatni a szabályait. A szabályai, ahogy a végessége és a nyitottsága is bele van kódolva a technológiába. Ez teljesen eltér a hagyományos pénzügyektől, ahol a kormány pénzt nyomtathat, mely csökkenti a megtakarítások értékét, a cégek pedig lezárhatják a pénzügyi piacokat. - -Az Ethereum is erre épít. A Bitcoinhoz hasonlóan a szabályokat nem változtathatja meg senki, és mindenkinek van hozzáférése. Ezen felül a digitális pénzt programozhatóvá teszi az [okosszerződések](/glossary/#smart-contract) által, így az értékek tárolásán és küldésén kívül sok másra is alkalmas. - - - -## Programozható pénz {#programmable-money} - -Ez furcsán hangzik... „miért akarnám programozni a pénzemet”? Ez azonban több, mint az Ethereum tokenjeinek alaptulajdonsága. Bárki programozhat valamilyen logikát a kifizetések kezelésébe. Így rendelkezhet a Bitcoin által nyújtott kontrollal és biztonsággal, a pénzügyi intézmények által nyújtott szolgáltatásokkal kombinálva azt. Lehetővé válik, hogy a kriptovalutával olyan műveleteket is véghezvigyen a felhasználó, amit a Bitcoin nem támogat, mint például kölcsön adás és kölcsön vétel, időzített kifizetések, indexalapokba való befektetés stb. - - -
Tekintse át azokat a DeFi alkalmazásokat, melyeket kipróbálásra javaslunk, amennyiben Ön most ismerkedik az Ethereummal.
- - Fedezze fel a DeFi alkalmazásokat - - - -## Mit lehet csinálni a DeFi-ban? {#defi-use-cases} - -A legtöbb pénzügyi szolgáltatásnak létezik decentralizált alternatívája. Az Ethereum emellett olyan lehetőségeket teremt, hogy teljesen új pénzügyi termékek is létrejöhessenek. Ez egy folyamatosan bővülő lista. - -- [Pénzküldés a világ bármelyik pontjára](#send-money) -- [Pénzáramoltatás (streaming) a világon bárhova](#stream-money) -- [Stabil pénznemek használata](#stablecoins) -- [Kölcsönfelvétel fedezettel](#lending) -- [Kölcsönfelvétel fedezet nélkül](#flash-loans) -- [Megtakarítás kriptóval](#saving) -- [Kereskedés tokenekkel](#swaps) -- [Portfóliófejlesztés](#investing) -- [Közösségi elképzelések finanszírozása](#crowdfunding) -- [Biztosítás vásárlása](#insurance) -- [Portfóliókezelés](#aggregators) - - - -### Azonnali pénzküldés a világ bármelyik pontjára {#send-money} - -Az Ethereum-blokklánc úgy van kialakítva, hogy biztonságosan és globálisan kezeljen tranzakciókat. A Bitcoinhoz hasonlóan az Ethereumon is olyan könnyen lehet pénzt utalni, akár egy e-mailt elküldeni. Csak írja be a fogadó fél [ENS-nevét](/glossary/#ens) (például bob.eth) vagy számlacímét a tárcájában, és az utalás közvetlenül megérkezik hozzá általában percek alatt. Az utalások küldéséhez vagy fogadásához szükség van egy [tárcára](/wallets/). - - - Tovább a fizetési dappokhoz - - -#### Pénzáramoltatás (streaming) a világon bárhova... {#stream-money} - -Az Ethereumon pénzáramoltatásra is lehetőség van. Ez lehetővé teszi, hogy valós időben kapja meg valaki a fizetését, így a pénzeszközei mindig rendelkezésre állnak. Vagy kölcsönözhet is valamit addig, amíg azt használja, mint egy tárolóhely vagy elektromos robogó. - -Ha pedig nem akar [ETH-t](/glossary/#ether) küldeni vagy áramoltatni, mert annak változhat az értéke, akkor alternatív valuták is rendelkezésre állnak az Ethereumon: ezek a [stabil érmék](/glossary/#stablecoin). - - - -### Stabil pénznemek használata {#stablecoins} - -A kriptovaluta változékonysága számos pénzügyi termék és általános költés esetén problémát okoz. A DeFi közösség ezt a stabil érmékkel oldotta meg. Ezek értéke hozzá van kötve egy másik eszközhöz, általában egy népszerű valutához, mint amilyen a dollár. - -Az olyan érmék értéke, mint a Dai vagy a USDC, csak néhány centtel változik. Ezért tökéletesen megfelelnek a munkabér kifizetésre vagy a kiskereskedelem számára. Dél-Amerikában számtalan ember használt stabil érméket, hogy megvédje a megtakarításait, amikor a kormányzat által kibocsátott valuták bizonytalan helyzetbe kerültek. - - - Bővebben a stabil érmékről - - - - -### Kölcsönfelvétel {#lending} - -A kölcsönfelvétel a decentralizált szolgáltatóktól kétféle módon valósulhat meg. - -- Peer-to-peer (P2P), amikor a kölcsön felvevője közvetlenül egy meghatározott kölcsönadótól kap pénzt. -- Gyűjtőszámlás (pool), amikor a kölcsönadó pénzeszközt biztosít (likviditás) a gyűjtőszámlának, amelytől a kölcsönvevők pénzt tudnak szerezni. - - - Tovább a kölcsönfelvételi dappokhoz - - -Számos előnye van annak, ha decentralizált kölcsönadót használunk... - -#### A kölcsönfelvétel magán jellegének megőrzése {#borrowing-privacy} - -Manapság a pénz kölcsönadása és -vétele az abban résztvevő egyének köré rendeződik. A bank tudni akarja, hogy vissza fogja-e fizetni a kölcsönt annak igénylője, mielőtt odaítélné neki. - -A decentralizált kölcsönzésnél a feleknek nem kell azonosítaniuk magukat. Ehelyett a kölcsönvevő fedezetet ad, melyet a kölcsönadó automatikusan megkap, ha a kölcsönt nem fizeti vissza. Néhány kölcsönadó [NFT-ket](/glossary/#nft) is elfogad fedezet gyanánt. Az NFT-k olyan okiratok, melyek egy egyedi eszközhöz kapcsolódnak, mint például egy festmény. [Bővebben az NFT-kről](/nft/) - -Így anélkül lehet pénzt kölcsönözni, hogy hitelellenőrzést kellene végezni vagy személyes információkat átadni. - -#### Globális alapokhoz való hozzáférés {#access-global-funds} - -Amikor valaki decentralizált kölcsönadóhoz fordul, akkor az egész világon letétbe helyezett alapok válnak számára elérhetővé, nem csak azok az eszközök, melyeket a kiválasztott bankban vagy intézményben elhelyeztek. Ez sokkal elérhetőbbé teszi a kölcsönt és jobb kamatozást is biztosít. - -#### Adóhatékonyság {#tax-efficiencies} - -A kölcsönfelvétel révén hozzáférhet a szükséges eszközökhöz, így nem kell eladnia a rendelkezésére álló ETH-t (melynek adóvonzata van). Ehelyett használhatja az ETH-t fedezetként egy stabilérme-kölcsönhöz. Így a szükséges pénz is rendelkezésére áll, és az ETH-t is megtarthatja. A stabil érmék olyan tokenek, melyek előnyösebbek, ha készpénzre van szüksége, mert az értékük nem változik annyira, mint az ETH esetében. [Bővebben a stabil érmékről](#stablecoins) - -#### Villámkölcsönök {#flash-loans} - -A villámkölcsön a decentralizált kölcsönzés kísérleti jellegű formája, amikor fedezet nélkül, illetve bármiféle személyes adat átadása nélkül tud valaki kölcsönt felvenni. - -Ezek jelenleg nem érhetők el kiterjedt körben a nem technikai felhasználók között, de arrafelé mutatnak, ami a jövőben mindenki számára rendelkezésre fog állni. - -Azon az alapon működik, hogy a kölcsönt ugyanabban a tranzakcióban veszik fel és fizetik vissza. Ha nem tudják visszafizetni, akkor a tranzakció visszafordul, mintha nem is történt volna semmi. - -A kölcsönzéshez használt pénzeszközök likviditási gyűjtőszámlákon találhatók (nagy mennyiségű pénzeszközök kölcsönzési célra). Ha egy adott pillanatban nem használják azokat, akkor egy személynek lehetősége van kölcsönvenni az eszközöket, üzletet hajtani végre azokkal, és egyszerre visszafizetni azokat, szinte a kölcsönzéssel azonos időben. - -Ily módon rengeteg logikát kell belefoglalni egy ilyen magáért beszélő tranzakcióba. Erre egy egyszerű példa az lehet, hogy valaki arra használja a villámkölcsönt, hogy egy adott eszközből a lehető legtöbbet beszerezze egy adott áron, és eladja azt egy másik tőzsdén, ahol az ár magasabb. - -Így egyetlen tranzakcióban a következők történnek: - -- X összegű $asset-et kölcsönöz 1,00 $ értéken az A tőzsdén -- Az X összegű $asset-et eladja 1,10 $ értéken a B tőzsdén -- Visszafizeti a kölcsönt az A tőzsdének -- A profit mínusz a tranzakciós költség az Ön nyeresége - -Ha a B tőzsdén lévő kínálat hirtelen lezuhan, és a felhasználó nem tudott eleget vásárolni ahhoz, hogy lefedje az eredeti kölcsönt, akkor a tranzakció egyszerűen visszafordul. - -Ha a hagyományos pénzügyi világban szeretne ugyanilyen ügyletet végrehajtani, akkor hatalmas pénzösszegre van szüksége. Ezek a pénzkereső stratégiák csak azoknak elérhetők, akik már most is vagyonosak. A villámkölcsön egy olyan jövőt fest elénk, melyben a pénzcsinálásnak nem előfeltétele az, hogy az ember vagyonos legyen. - - - Bővebben a villámkölcsönökről - - - - -### Kezdjen el pénzt megtakarítani a kriptóval {#saving} - -#### Kölcsönadás {#lending} - -A rendelkezésére álló kriptovaluta kölcsönadásával kamatot kaphat, így pénzeszközei folyamatosan növekednek. Jelenleg a kamatráták sokkal magasabbak, mint a helyi bankokban (ha egyáltalán van elérhető bank a közelében). Itt egy példa: - -- Kölcsönadja a rendelkezésére álló 100 Dai-t, ami egy [stabil érme](/stablecoins/), egy olyan termékért, mint az Aave. -- Kap 100 Aave Dai-t (aDai), mely egy token, és a kölcsönadott Dai-t reprezentálja. -- Az aDai növekedni fog a kamatráta alapján, így Ön láthatja, ahogy az egyenlege növekszik a tárcájában. Az [éves ráta (APR)](/glossary/#apr) függvényében az Ön tárcaegyenlege akár néhány napon vagy órán belül már 100,1234 összeget mutathat! -- Bármikor visszavonhat bármekkora Dai összeget, ami megegyezik az Ön aDai egyenlegével. - - - Tovább a kölcsönadási dappokhoz - - -#### Veszteség nélküli lottó {#no-loss-lotteries} - -A veszteség nélküli lottók, mint a PoolTogether, szórakoztató és innovatív módszerek a megtakarításokra. - -- Vásárol 100 jegyet 100 Dai tokenért. -- Kap 100 plDai-t, ami a 100 jegyet reprezentálja. -- Ha valamelyik jegyét kisorsolják, a plDai egyenlege megnövekszik a nyeremény összegével. -- Ha nem nyer, akkor a 100 plDai átgördül a következő heti sorsolásra. -- Bármikor visszavonhat bármekkora Dai összeget, ami megegyezik az Ön plDai egyenlegével. - -A rendelkezésre álló nyeremény abból a kamatból keletkezik, amit a jegyvásárláson összegyűjtött összeg kölcsönadásából szereznek, ahogy azt a fenti példa is mutatja. - - - Próbálja ki a PoolTogether lehetőséget - - - - -### Kereskedés a tokenekkel {#swaps} - -Az Ethereumon ezernyi token elérhető. A decentralizált tőzsdék (DEX) lehetővé teszik, hogy a felhasználók a különféle tokenekkel bármikor kereskedjenek. Eközben az eszközök feletti kontroll végig megmarad. Olyan, mint amikor az ember egy másik országba utazik és valutaváltót használ. Ugyanakkor a DeFi sosem zár be. A pénzpiacok folyamatosan nyitva vannak (az év 365 napján, napi 24 órában), a technológia pedig garantálja, hogy mindig van, aki elfogadja az ügyletet. - -Például, ha Ön szeretné használni a veszteség nélküli lottózást, a PoolTogether-t (ahogy fentebb írtuk), szüksége lesz Dai vagy USDC tokenre. A decentralizált tőzsdén átválthatja a kívánt ETH-összeget ezekre a tokenekre, majd vissza, amikor végzett az ügylettel. - - - Tovább a tokenes tőzsdékre - - - - -### Haladó szintű kereskedés {#trading} - -Haladóbb lehetőségek is rendelkezésre állnak azoknak a kereskedőknek, akik több kontrollt szeretnének. Lehetségesek a meghatározott áron történő vételi/eladási megbízások (limit order), határidős ügyletek, tőkeáttétes kereskedések és még sok más. A decentralizált kereskedés során Ön hozzáfér a globális likviditáshoz, a piac sosem zár be, az eszközök feletti kontroll pedig mindig az Ön kezében van. - -A centralizált tőzsdéken ehhez képest letétbe kell helyezni az eszközöket a kereskedés előtt, és meg kell bízni bennük, hogy azt megfelelően kezelik. Miközben az eszköz letétben van náluk, nincs biztonságban, mert a centralizált tőzsdék a hackerek kedvelt célpontjai. - - - Tovább a kereskedő dappokhoz - - - - -### Portfóliófejlesztés {#investing} - -Az Ethereumon találhatók olyan alapkezelő termékek, melyek az Ön által választott stratégia mentén megpróbálják megnövelni portfóliója értékét. Mindez automata, mindenki számára nyitott, és nem igényel kezelőt, aki a profitból levenné a saját részét. - -Egy jó példa erre a [DeFi Pulse Index fund (DPI)](https://defipulse.com/blog/defi-pulse-index/). Ez az alap automatikusan kiigazítja az Ön portfólióját, hogy az állandóan a legjobb DeFi-tokeneket tartalmazza az aktuális piaci értékük alapján. Önnek nem kell foglalkoznia a részletekkel, és bármikor visszavonhatja pénzeszközeit az alapból. - - - Tovább a befektetési dappokhoz - - - - -### Közösségi elképzelések finanszírozása {#crowdfunding} - -Az Ethereum egy tökéletes platform arra, hogy a közösség segítségével finanszírozzon bizonyos elképzeléseket: - -- A lehetséges finanszírozók bárhonnan jöhetnek – az Ethereum és a tokenjei mindenkinek elérhetők, a világon bárhol. -- Átlátható, így az adománygyűjtők igazolni tudják, hogy mennyi pénz jött össze. Azt is nyomon lehet követni, hogy a pénz hogyan lett elköltve. -- Az adománygyűjtők automatikus visszatérítést is be tudnak állítani, például ha egy adott határidőre nem jön össze a minimális összeg. - - - Tovább a közösségi finanszírozás dappokhoz - - -#### Kvadratikus finanszírozás {#quadratic-funding} - -Az Ethereum egy nyílt forráskódú program, és az eddigi fejlesztések nagy részét a közösség finanszírozta. Ez vezetett el egy érdekes és új modellhez: a kvadratikus finanszírozáshoz. Ennek lehetősége van azt a módot továbbfejleszteni, ahogy a közjavak finanszírozását kezelhetjük. - -A kvadratikus finanszírozás gondoskodik arról, hogy azok a projektek kapják a finanszírozást, amelyre tényleg a legnagyobb az igény. Tehát azokat támogatjuk, amelyek a leginkább magasabb szintre emelik az emberek életét. Így működik: - -1. Az adományozott pénzösszegek egy alapba (matching pool) kerülnek. -2. Megkezdődik a nyilvános adománygyűjtés. -3. Az emberek úgy jelezhetik, hogy számukra fontos egy adott projekt, hogy pénzt adományoznak rá. -4. Az adománygyűjtés lezártával az alapot szétosztják a projektek között. Ebből az alapból az a projekt kapja a legmagasabb összeget, amelyre a leginkább igényt tartanak az adományozók. - -Eszerint az A projekt, mely 100 adományt kapott, egyenként 1 $ értékben, több finanszírozást kaphat az alapból, mint a B projekt, mely egyetlen adományt kapott 10 000 $ értékben (a kapott összeg az alap méretén múlik). - - - Bővebben a kvadratikus finanszírozásról - - - - -### Biztosítások {#insurance} - -A decentralizált biztosítások célja, hogy azok olcsóbbak, sokkal átláthatóbbak legyenek, és gyorsabb legyen a kifizetés. Az automatizálásnak köszönhetően a biztosítás általi lefedettség megfizethetőbb, a kifizetések pedig gyorsabbak. Az igénybejelentéshez használt adatok teljesen transzparensek. - -Az Ethereum termékei, mint bármelyik szoftver, tartalmazhatnak hibákat és sebezhető pontokat. Emiatt jelenleg sok biztosítási megoldás a felhasználók eszközeinek elvesztése ellen ad védelmet. Ugyanakkor vannak olyan projektek, melyek elkezdtek kialakítani az élet többi eseményére vonatkozóan is biztosításokat. Egy jó példa erre az Etherisc's Crop biztosítása, melynek célja [a kisméretű, kenyai gazdálkodók védelme az aszály és az árvíz ellen](https://blog.etherisc.com/etherisc-teams-up-with-chainlink-to-deliver-crop-insurance-in-kenya-137e433c29dc). A decentralizált biztosítás olcsóbb megoldást tud kínálni a gazdálkodóknak, akiknek a hagyományos biztosítók általában megfizethetetlenek. - - - Tovább a biztosítási dappokhoz - - - - -### Gyűjtőhelyek és portfóliókezelők {#aggregators} - -Amikor ennyi minden zajlik, Önnek is szüksége lehet egy olyan megoldásra, mellyel a befektetéseit, kölcsöneit és kereskedéseit figyelemmel követheti. Rengeteg olyan termék elérhető, melyekkel egyetlen helyről tudja az összes DeFi tevékenységét koordinálni. Ez a DeFi nyílt architektúrájának szépsége. A csapatok olyan interface-eket építenek, melyekkel nemcsak az összes termék kapcsán láthatja az egyenlegét, hanem használhatja azok tulajdonságait is. Amint Ön is jobban elmélyül a DeFi világában, hasznosnak fogja ezt találni. - - - Tovább a portfóliós dappokhoz - - - - -## Hogyan működik a DeFi? {#how-defi-works} - -A decentralizált pénzügyek (DeFi) kriptovalutákat és okosszerződéseket használnak ahhoz, hogy közvetítő nélküli szolgáltatásokat adjanak. A mai pénzügyi világban a pénzintézetek garantálják a tranzakciókat. Ez nagy hatalmat ad az intézményeknek, mert a pénz rajtuk áramlik keresztül. Emellett emberek milliárdjai világszerte még bankszámlát sem tudnak nyitni maguknak. - -A DeFi-ban az okosszerződés helyettesíti a pénzintézetet a tranzakció során. Az okosszerződés egy olyan Ethereum-számla, mely pénzeszközöket tartalmaz és azokat elküldheti vagy visszaveheti bizonyos feltételek mentén. Miután az okosszerződés életbe lépett, már senki sem változtathatja meg – úgy fog működni, ahogy le lett programozva. - -Egy olyan szerződést, melynek lényege, hogy támogatást vagy zsebpénzt küldjön, le lehet programozni úgy, hogy A számláról B számlára rakjon pénzt minden pénteken. Ezt addig fogja csinálni, amíg az A számlán elegendő összeg található. Senki sem tudja megváltoztatni a szerződést úgy, hogy hozzáadja a C számlát és ellopja az összeget. - -A szerződések emellett teljesen nyilvánosak és bárki megvizsgálhatja azokat. Eszerint a rossz szerződések elég hamar a közösség vizsgálódása alá kerülnek. - -Ez valójában azt jelenti, hogy jelenleg az Ethereum-közösség technikailag képzettebb tagjaiban bízunk, akik el tudják olvasni a programkódot. A nyílt forráskódon alapuló közösség segít a fejlesztőket ellenőrzés alatt tartani, ami idővel szükségtelenné fog válni, ahogy az okosszerződéseket könnyebb lesz átlátni, és a programkód megbízhatóságára más igazolási módok is születnek. - -## Az Ethereum és a DeFi {#ethereum-and-defi} - -Az Ethereum tökéletes alapot biztosít a decentralizált pénzügyek (DeFi) számára: - -- Az Ethereumot és az azon működő okosszerződéseket senki sem birtokolja – tehát bárki használhatja a DeFi-t. Ebből adódik, hogy senki sem változtathatja meg a szabályokat. -- A DeFi termékek a háttérben ugyanazon a nyelven szólnak, ami az Ethereum. Emiatt a termékek nagy része zökkenőmentesen képes együttműködni. Az egyik platformon kölcsönadhat tokeneket, és kereskedhet a kamatozó tokenekkel egy teljesen másik piacon, teljesen másik alkalmazással. Ez olyan, mintha a bankjában a hűségpontokat készpénzre váltaná. -- A tokenek és kriptovaluták az Ethereum részei, mely egy megosztott főkönyv – fő jellemzője a tranzakciók és a tulajdonlás követhetősége. -- Az Ethereum tökéletes pénzügyi szabadságot ad – a legtöbb termék sosem fog felügyeletet gyakorolni az Ön eszközei felett, így a kontroll Önnél marad. - -A DeFi-t a következő rétegek szerint értelmezheti: - -1. A blokklánc – az Ethereum tartalmazza az összes tranzakciót és a számlák státuszát. -2. Az eszközök – [ETH](/eth/) és a többi token (valuták). -3. A protokollok – az [okosszerződések](/glossary/#smart-contract), melyek a műveleteket biztosítják, mint amilyen például egy szolgáltatás az eszközök decentralizált kölcsönadására. -4. [Az alkalmazások](/dapps/) – azok a termékek, melyek révén kezeljük és elérjük a protokollokat. - -Megjegyzés: a legtöbb DeFi alkalmazás az [ERC-20 szabványt](/glossary/#erc-20) használja. A DeFi alkalmazások beburkolják az ETH-t és így becsomagolt ethert (WETH) használnak. [Bővebben a becsomagolt etherről](/wrapped-eth). - -## Építse Ön is a DeFi-t {#build-defi} - -A DeFi egy nyílt forráskódú kezdeményezés. A kapcsolódó protokollok és alkalmazások mind nyitottak az Ön számára, hogy megvizsgálja azokat, elágazásokat készítsen azokból vagy továbbfejlessze azokat. A rétegezett struktúra következtében (melynek részei ugyanarra az alap blokkláncra épülnek és ugyanazokat az eszközöket használják) a protokollokat össze lehet kötni, hogy egyedi lehetőségeket aknázzunk ki. - - - Bővebben a dappok építéséről - - -## További olvasnivaló {#further-reading} - -### DeFi adatok {#defi-data} - -- [DeFi Prime](https://defiprime.com/) -- [DeFi Llama](https://defillama.com/) - -### Cikkek a DeFi-ról {#defi-articles} - -- [Útmutató kezdőknek a DeFi-ról](https://blog.coinbase.com/a-beginners-guide-to-decentralized-finance-defi-574c68ff43c4) – _Sid Coelho-Prabhu, 2020. január 6._ - -### Videók {#videos} - -- [Finematics – decentralizált pénzügyi oktatás](https://finematics.com/) – _Videók a DeFi-ról_ -- [The Defiant](https://www.youtube.com/playlist?list=PLaDcID4s1KronHMKojfjwiHL0DdQEPDcq) – _A DeFi alapjai: minden, amit tudnia kell, hogy elboldoguljon ebben a néha rejtélyes világban._ -- [Whiteboard Crypto](https://youtu.be/17QRFlml4pA) _Mi az a DeFi?_ - -### Közösségek {#communities} - -- [DeFi Llama Discord-szerver](https://discord.defillama.com/) -- [DeFi Pulse Discord-szerver](https://discord.gg/Gx4TCTk) - - - - \ No newline at end of file diff --git a/public/content/translations/hu/06) Use Cases/smart-contracts/index.md b/public/content/translations/hu/06) Use Cases/smart-contracts/index.md deleted file mode 100644 index b899e0b3968..00000000000 --- a/public/content/translations/hu/06) Use Cases/smart-contracts/index.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Okosszerződések -description: Egy nem technikai bevezetés az okosszerződésekbe -lang: hu ---- - -# Bevezetés az okosszerződésekbe {#introduction-to-smart-contracts} - -Az okosszerződések az Ethereum alkalmazási rétegének alapvető építőkockái. Ezek olyan számítógépes programok, melyek a [blokkláncon](/glossary/#blockchain) találhatók, feltételeket követve működnek (ha ez van, akkor ezt csinálom), és garantáltan a programkódja által definiált szabályok alapján végez műveleteket. E szabályokat nem lehet megváltoztatni, miután a szerződés életbe lépett. - -Az okosszerződés kifejezést Nick Szabo alkotta meg. 1994-ben írt egy cikket a [a koncepció lényegéről](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart.contracts.html), majd 1996-ban tovább taglalta, hogy [mire képes az okosszerződés](https://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/smart_contracts_2.html). - -Szabo egy olyan digitális piacteret képzelt el, ahol automatikus, [kriptográfiailag biztosított](/glossary/#cryptography) folyamatok lehetővé teszik tranzakciók és üzleti funkciók működését megbízott közvetítők nélkül. Az okosszerződések ezt a víziót valósítják meg az Ethereumon. - -Nézze meg a videót, melyben a Finematics elmagyarázza az okosszerződések lényegét: - - - -## Bizalom a hagyományos szerződésekben {#trust-and-contracts} - -A hagyományos szerződéssel az a legnagyobb gond, hogy meg kell bízni a résztvevőkben, hogy végrehajtják a szerződés tartalmát. - -Következzen egy példa: - -Alice és Bob kerékpáron versenyeznek. Tegyük fel, Alice arra fogad Bobbal 10 $-ban, hogy ő maga fog nyerni. Bob magabiztos a saját nyerését illetően, ezért belemegy a fogadásba. Végül Alice sokkal hamarabb ér célba Bobhoz képest, egyértelműen ő a győztes. Bob azonban nem fizeti ki a fogadás összegét, mert szerinte Alice csalt. - -Ez az egyszerű példa a „nem okos” megegyezések problémáját illusztrálja. Még a megegyezés feltételei teljesülnek is (tehát Ön a verseny győztese), még mindig meg kell bíznia egy másik személyben, hogy teljesítse a megállapodást (azaz kifizesse a fogadás összegét). - -## Egy digitális ételautomata {#vending-machine} - -Az okosszerződésre egy egyszerű metafora lehet az ételautomata működése, melynél bizonyos beviteli értékek előre meghatározott eredménnyel járnak. - -- Ön kiválaszt egy terméket -- Az ételautomata kiírja az árat -- Ön kifizeti az árát -- Az ételautomata ellenőrzi, hogy a megfelelő összeget kapta meg -- Majd az automata kiadja a kért árut - -Az ételautomata csak az Ön által kért terméket adja oda, miután a feltételek teljesültek. Ha Ön nem választ ki terméket vagy nem dob be elég pénzt, akkor az automata nem adja ki a terméket. - -## Automatikus végrehajtás {#automation} - -Az okosszerződés legfontosabb előnye, hogy bizonyos feltételek fennállásakor egyértelműen végrehajt egy meghatározott programkódot. Nem kell várni az emberi beavatkozásra, hogy értelmezze vagy kitalálja az eredményt. Így nincs szükség megbízott közvetítőkre. - -Például írhat egy olyan okosszerződést, mely letétben tart pénzeszközt egy gyermek számára, melyet egy bizonyos dátum után kaphat meg. Ha hamarabb akarná megkapni, akkor az okosszerződés nem hajtaná azt végre. Vagy olyan okosszerződést is írhat, mely automatikusan biztosítja egy autó forgalmi engedélyének digitális verzióját, amint Ön kifizeti azt a kereskedőnek. - -## Előre meghatározott kimenetel {#predictability} - -A hagyományos szerződések nem egyértelműek, mert emberek értelmezik és hajtják végre azokat. Például két bíró teljesen másképpen is értelmezhet egy szerződést, mely eltérő döntésekhez és egyenlőtlen kimenetelhez vezethet. Az okosszerződések kizárják ezt a lehetőséget. Ehelyett az okosszerződések a szerződés kódjában megadott feltétek mentén pontosan végrehajtásra kerülnek. A pontosság azt is jelenti, hogy ugyanolyan körülmények között az adott okosszerződés ugyanazt az eredményt adja. - -## Nyilvános dokumentálás {#public-record} - -Az okosszerződéseket könnyedén lehet auditálni és követni. Mivel az Ethereum okosszerződései egy nyilvános blokkláncon találhatók, ezért bárki azonnal megnézheti az eszközök mozgását és a kapcsolódó információkat. Például Ön megnézheti, hogy valaki pénzt utalt az Ön címére. - -## Adatvédelem {#privacy-protection} - -Az okosszerződések védik az Ön adatait. Mivel az Ethereum egy olyan hálózat, ahol a tranzakciók nem közvetlen módon köthetők az identitáshoz (nyilvánosan egy egyedi kriptográfiai címhez tartoznak), így Ön is megőrizheti valódi kilétét mások előtt. - -## Látható feltételek {#visible-terms} - -Végül a hagyományos szerződéshez hasonlóan Ön ellenőrizheti az okosszerződés tartalmát, mielőtt aláírná azt (vagy valamilyen interakcióba lépne azzal). Az okosszerződés transzparens volta biztosítja, hogy bárki megvizsgálhatja annak részleteit. - -## Az okosszerződés alkalmazási területei {#use-cases} - -Az okosszerződések lényegében mindent végre tudnak hajtani, amit egy számítógépes program tud. - -Többek között képesek számításokat végezni, valutát létrehozni, adatot tárolni, [NFT-ket](/glossary/#nft) kreálni (minting), üzeneteket küldeni és még ábrát vagy grafikont is tudnak készíteni. Következzen néhány népszerű példa a való életből: - -- [Stablecoin-ok](/stablecoins/) -- [Egyedi digitális eszközök létrehozása és szétosztása](/nft/) -- [Automatikus, nyílt valutaátváltás](/get-eth/#dex) -- [Decentralizált játékok](/dapps/?category=gaming#explore) -- [Biztosítási szerződés, mely automatikus kifizetést alkalmaz](https://etherisc.com/) -- [Szabvány, melyet alapul véve az emberek egyéni, interoperábilis valutákat hoznak létre](/developers/docs/standards/tokens/) - -## További olvasnivaló {#further-reading} - -- [Hogyan fogják az okosszerződések megváltoztatni a világot](https://www.youtube.com/watch?v=pA6CGuXEKtQ) -- [Okosszerződések: a blokklánc-technológia, mely leváltja az ügyvédeket](https://blockgeeks.com/guides/smart-contracts/) -- [Okosszerződések fejlesztőknek](/developers/docs/smart-contracts/) -- [Tanulja meg, hogyan kell okosszerződéseket írni](/developers/learning-tools/) -- [Ismerje meg Ethereumot – Mi az az okosszerződés?](https://github.com/ethereumbook/ethereumbook/blob/develop/07smart-contracts-solidity.asciidoc#what-is-a-smart-contract) diff --git a/public/content/translations/hu/06) Use Cases/web3/index.md b/public/content/translations/hu/06) Use Cases/web3/index.md deleted file mode 100644 index 383332ec940..00000000000 --- a/public/content/translations/hu/06) Use Cases/web3/index.md +++ /dev/null @@ -1,157 +0,0 @@ ---- -title: Mi az a Web3 és miért fontos? -description: Bevezetés a web3 világába, vagyis az internet következő evolúciójába, és abba, hogy miért is olyan fontos. -lang: hu ---- - -# Bevezetés a Web3 világába {#introduction} - -A centralizáció segített abban, hogy emberek milliárdjai használják az internetet, és megalapozta annak stabil, robosztus infrastruktúráját. Eközben néhány centralizált entitás tartja a kezében az internet nagy részét, és egyoldalúan eldönti, hogy mit szabad és mit nem. - -A Web3 a válasz erre a dilemmára. Ahelyett, hogy a web nagy technológiai cégek monopóliuma lenne, a web3 lényege a decentralizáció, így a felhasználók építik, működtetik és birtokolják. A Web3 az egyének kezébe helyezi a hatalmat a cégek helyett. Mielőtt mélyebben elmerülünk a Web3 világában, nézzük meg, hogyan jutottunk el idáig. - - - -## A web korai változatai {#early-internet} - -A legtöbben azt képzelik, hogy az internet egy folyamatos pillére a modern életnek – feltalálták és azóta létezik. Azonban a jelenlegi formája eléggé más, mint amit korábban elképzeltek. A web rövid történetében különböztessünk meg két időszakot: web 1.0 és web 2.0. - -### Web 1.0: csak olvasás (1990–2004) {#web1} - -1989-ben Genovában a CERN intézetében Tim Berners-Lee olyan protokollokon dolgozott, amelyek a web alapjaivá váltak. Mi volt az ő ötlete? Nyitott, decentralizált protokollok, melyek a világ egészén lehetővé teszik az információmegosztást. - -Berners-Lee alkotásának kezdeti értelmezése, melyet most web 1.0-ként ismerünk, nagyjából 1990 és 2004 között készült. A web 1.0 főleg statikus weboldalakból állt, melyeket cégek birtokoltak, szinte semmi interakció a felhasználók között – néha készítettek tartalmat –, ezért úgy ismert mint a „csak olvasási” időszak. - -![A web 1.0-t képviselő kliensszerver-architektúra](./web1.png) - -### Web 2.0: olvasás-írás (2004 – mostanáig) {#web2} - -A web 2.0 periódus 2004-ben indult, amikor megjelentek a közösségimédia-oldalak. A csak olvasás helyett kialakul az olvasás-írás kultúrája. Ahelyett, hogy a cégek adnának a felhasználónak tartalmat, olyan platformok keletkeztek, ahol a felhasználók adnak tartalmat és egymással lépnek interakcióba. Ahogy egyre több ember kezdte el használni, a cégek egy maroknyi csoportja aránytalanul nagy részét kezdte el kontrollálni a forgalomnak és a keletkező értéknek. A web 2.0 révén megszületett a reklámalapú bevételi modell. Miközben a felhasználók tartalmat készítenek, az nincs az ő birtokukban és nem is részesednek annak bevételéből. - -![A web 2.0-t képviselő kliensszerver-architektúra](./web2.png) - - - -## Web 3.0: olvasás-írás-tulajdonlás {#web3} - -A web3 kifejezést az [Ethereum](/what-is-ethereum/) társalapítója, Gavin Wood találta ki, röviddel az Ethereum 2014-es elindítása után. Gavin megfogalmazta azt a problémát, amit számos korai kriptobevezető érzett: a web túl sok bizalmat követel. Tehát a mai internet azon alapszik, hogy a felhasználó néhány vállalatra bízza, hogy azok a közösség érdeke szerint működjenek. - -![A Web3-at képviselő, decentralizált csomópont-architektúra](./web3.png) - -### Mi az a Web3? {#what-is-web3} - -A Web3 egy magával ragadó szóvá vált, amelyet minden olyanra értünk, ami újjá és jobbá teszi az internetet. A Web3 blokkláncokat, kriptovalutákat és nem helyettesíthető tokeneket (NFT) használ, hogy visszaadja a felhasználónak a tulajdonjogot. [Egy 2020-as Twitter-bejegyzés](https://twitter.com/himgajria/status/1266415636789334016) foglalta össze a legjobban: a web1 csak olvasás volt, a web2-nél az olvasásé és írásé a főszerep, a web3 az olvasás-írás-tulajdonlás világa lesz. - -#### A Web3 központi elképzelései {#core-ideas} - -Habár nehéz lenne egy pontos definíciót adni a Web3-ról, néhány központi elv irányítja a megalkotását. - -- **A Web3 decentralizált:** ahelyett, hogy nagy részét központi entitások uralnák és birtokolnák, a tulajdonlást elosztja az építői és felhasználói között. -- **A Web3 engedélymentes:** mindenkinek azonos joga van részt venni benne és senkit sem zárnak ki. -- **A Web3 saját fizetési móddal bír:** kriptovalutát használ a költésre és az online pénzküldésre ahelyett, hogy a bankok és fizetési szolgáltatások idejétmúlt infrastruktúráját használná. -- **A Web3 nem igényel bizalmat:** ösztönzők és gazdasági mechanizmusok révén működik, nem pedig megbízott harmadik feleken alapul. - -### Miért fontos a Web3? {#why-is-web3-important} - -Habár a Web3 lenyűgöző vonásai nem különülnek el ennyire és nem is tömörülnek egyértelmű kategóriákba, az egyszerűség kedvéért megpróbáljuk azokat külön bemutatni. - -#### Tulajdonlás {#ownership} - -A Web3 sosem látott módon ad a felhasználóknak képességet arra, hogy digitális eszközeiket saját maguk birtokolják. Tegyük fel, hogy Ön egy web2-es játékot játszik. Ha egy játékon belüli tételt megvásárol, akkor az közvetlenül a profiljához kapcsolódik. De ha a játék készítői törlik ezt a profilt, akkor elveszíti azokat a tételeket. Ha pedig nem játszik tovább, akkor elveszíti az értéket, amit azokba a tételekbe fektetett. - -A Web3 közvetlen tulajdonjogot ad [nem helyettesíthető tokenek (NFT)](/glossary/#nft) révén. Senki, még a játék készítői sem tudják elvenni ezt a jogot. Ha abbahagyja a játékot, akkor el tudja adni, kereskedni tud azokkal a nyitott piacokon és visszaszerezni az értékét. - - -
Tudjon meg többet az NFT-kről
- - Bővebben az NFT-kről - - - -#### Cenzúraálló kialakítás {#censorship-resistance} - -A platformok és a tartalomkészítők közötti hatalmi dinamika rettentő egyensúlytalan. - -Az OnlyFans oldal felnőtt tartalmat gyárt több mint 1 millió tartalomkészítővel, akik ebből szerzik jövedelmüket. 2021-ben a vezetés megtiltotta a túlzottan nyílt tartalmakat. Az alkotók felháborodtak, hogy az általuk felfutatott platform megfosztja őket a jövedelmüktől. Emiatt a döntést visszavonták. Ez is megmutatja a web2 fő problémáját: ha egy platformot el kell hagyjon egy alkotó, akkor elveszíti a reputációját és a követőit, amelyeket összegyűjtött. - -A Web3-ban az adat a blokkláncon él. Amikor valaki elhagyja a platformot, magával viheti a reputációját, akár egy másik felületre is, ami jobban megfelel az értékeinek. - -A web2-nél az alkotóknak meg kell bízni a platformban, hogy nem változtatja meg a szabályokat, ugyanakkor a Web3 alapvonása a cenzúrának való ellenállás. - -#### Decentralizált autonóm szervezetek (DAO-k) {#daos} - -Az adatok feletti tulajdonjog mellett a web3 a platformot is birtokolni lehet, mint egy gyűjthető dolgot, olyan tokenek révén, melyek egy cégben való részesedésként működnek. A DAO segít koordinálni a platform decentralizált tulajdonlását és döntéseket hozni a jövőt illetően. - -A DAO-kat technikailag úgy határozzák meg, mint megállapodás szerinti [intelligens szerződéseket](/glossary/#smart-contract), amelyek automatizálják a decentralizált döntéshozatalt egy erőforráskészlet (token) felett. A tokennel rendelkező felhasználók szavaznak, hogy hogyan költsék el a forrásokat, a programkód pedig automatikusan végrehajtja azt. - -Ugyanakkor számos Web3-közösséget is DAO-ként definiálnak. Ezek a közösségek más-más szintű decentralizációval és automatizációval rendelkeznek. Jelenleg még vizsgáljuk, hogy mi is az a DAO és hova fejlődik a jövőben. - - -
Tudjon meg többet a DAO-król
- - További információk a DAO-król - - - -### Identitás {#identity} - -Hagyományos módon minden platformra egy külön profilt kell létrehozni. Például Ön külön Twitter-, YouTube- és Reddit-profillal is rendelkezik. Meg szeretné változtatni a nevét vagy a képét? Minden egyes eszközön meg kell tennie. Használhat közösségimédia-alapú azonosítást néhány esetben, ez viszont visszamutat a korábbi témára, a cenzúrára. Ezek a platformok egyetlen kattintással kizárhatják Önt a teljes közösségi életéből. Ami még rosszabb, hogy ezek a platformok személyes azonosítókat kérnek el a profil létrehozásához. - -A Web3 megoldja ezeket a problémákat azáltal, hogy lehetővé teszi digitális személyazonosságának vezérlését Ethereum-címmel és [Ethereum névszolgáltatás (ENS)](/glossary/#ens) profillal. Az Ethereum-cím használata egyszerre biztosít hozzáférést az összes platformhoz, ami biztonságos, ellenáll a cenzúrának és anonim. - -### Saját fizetési rendszer {#native-payments} - -A web2 fizetési infrastruktúra a bankokra és fizetési szolgáltatókra támaszkodik, kizárva azokat, akik nem rendelkeznek bankszámlával, vagy éppen nem olyan országban élnek. A Web3 tokeneket használ, mint amilyen az [ETH](/glossary/#ether), hogy közvetlen módon tudjon pénzt küldeni, és nem kell hozzá harmadik fél. - - - Többet az ETH-ről - - -## Web3 korlátok {#web3-limitations} - -A Web3 számos előnye mellett még mindig vannak korlátok, amit az ökoszisztémának kezelnie kell, hogy virágozni tudjon. - -### Hozzáférhetőség {#accessibility} - -Az olyan fontos Web3-funkciók, mint a bejelentkezés az Ethereummal, már mindenki számára elérhetők ingyenesen. A tranzakciók költsége viszont még mindig sokakat kizár. A Web3-at a magas tranzakciós díjai miatt kevésbé tudják a szegényebb, fejlődő országok használni. Az Ethereumon ezeket a kihívásokat [az ütemterv](/roadmap/) és a [2. rétegbeli skálázási megoldások](/glossary/#layer-2) oldják meg. A technológia készen áll, az L2-n még magasabb felhasználási számot kell elérni ahhoz, hogy mindenkinek elérhető legyen a Web3. - -### Felhasználói tapasztalat {#user-experience} - -A Web3 használatának jelenleg túl nagy a technikai akadálya. A felhasználóknak meg kell érteni a biztonsági konszerneket, komplex technikai dokumentációkat, illetve nehézkes felhasználó felületeken kell navigálniuk. [A tárcaszolgáltatók](/wallets/find-wallet/) egyértelműen dolgoznak ennek megoldásán, de még ennél is több fejlesztésre van szükség a Web3 tömeges használatához. - -### Oktatás {#education} - -A Web3 új paradigmákat vezet be, melynek következtében más mentális modelleket kell elsajátítani, mint a web2 esetében. A web1 idején hasonló oktatás vette kezdetét az 1990-es években; a támogatók új oktatási technikákat használtak a nagy közönség tájékoztatására az egyszerű metaforák használatától (információs sztráda, böngészés, szörfölés) kezdve a [tévés programokig](https://www.youtube.com/watch?v=SzQLI7BxfYI). A Web3 nem bonyolultabb ennél, csak más. A web2-felhasználók tájékoztatása ezekről a Web3-as paradigmákról elengedhetetlen a sikerhez. - -Az Ethereum.org a [Fordítói program](/contributing/translation-program/) révén járul hozzá a Web3-oktatáshoz, hogy az Ethereum főbb tartalmai minél több nyelven elérhetők legyenek. - -### Centralizált infrastruktúra {#centralized-infrastructure} - -A Web3-ökoszisztéma fiatal és gyorsan fejlődik. Ennek következtében főleg centralizált infrastruktúrákon alapszik (GitHub, Twitter, Discord, etc.). Számos Web3-vállalat dolgozik azon, hogy ezt a hiányt betöltse, de a minőségi, megbízható infrastruktúra kiépítése időbe telik. - -## Egy decentralizált jövő {#decentralized-future} - -A Web3 egy fiatal és gyorsan fejlődő ökoszisztéma. Gavin Wood 2014-ben alkotta ezt a nevet, de számtalan elképzelés csak mostanában tudott valósággá válni. Jelentős növekedés tapasztalható a kriptovaluta, az L2 skálázási megoldások, az új irányítási formák és a digitális személyazonosság forradalmi újításainak világában. - -Ez még csak a kezdete annak, hogy az internet jobbá váljon a Web3-mal, és ahogy az alapot nyújtó infrastruktúra fejlődik, a web jövője igen bíztatónak tűnik. - -## Hogyan lehet részt venni {#get-involved} - -- [Tárca szerzése](/wallets/) -- [Találjon egy közösséget](/community/) -- [Fedezze fel a Web3-alkalmazásokat](/dapps/) -- [DAO-hoz csatlakozás](/dao/) -- [Építsen a Web3-ra](/developers/) - -## További olvasnivaló {#further-reading} - -A Web3 nincs szigorúan definiálva. A közösségek különböző résztvevői más-más perspektívával bírnak. Néhány ezek közül: - -- [Mi az a Web3? Áttekintés a jövő decentralizált internetéről](https://www.freecodecamp.org/news/what-is-web3/) – _Nader Dabit_ -- [A Web3 értelmezése](https://medium.com/l4-media/making-sense-of-web-3-c1a9e74dcae) – _Josh Stark_ -- [Miért számít a Web3](https://future.a16z.com/why-web3-matters/) — _Chris Dixon_ -- [Miért fontos a decentralizáció](https://onezero.medium.com/why-decentralization-matters-5e3f79f7638e) – _Chris Dixon_ -- [A Web3 világa](https://a16z.com/wp-content/uploads/2021/10/The-web3-Readlng-List.pdf) – _a16z_ -- [A Web3 vita](https://www.notboring.co/p/the-web3-debate?s=r) – _Packy McCormick_ - - diff --git a/public/content/translations/hu/07) Staking Pages/staking/dvt/index.md b/public/content/translations/hu/07) Staking Pages/staking/dvt/index.md deleted file mode 100644 index f9552e76140..00000000000 --- a/public/content/translations/hu/07) Staking Pages/staking/dvt/index.md +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: Elosztott validátor technológia -description: Az elosztott validátor technológia lehetővé teszi, hogy több entitás elosztva üzemeltessen egy Ethereum-validátort. -lang: hu ---- - -# Elosztott validátor technológia {#distributed-validator-technology} - -Az elosztott validátor technológia (DVT) a validátor biztonságát akarja megerősíteni, ezért több entitásra osztja fel a kulcsok kezelését és az aláírási jogosultságokat, így kizárja az egyetlen meghibásodási pont kockázatát, a rugalmasság pedig nő. - -Ennek érdekében **felosztja a validátort biztosító privát kulcsot** **több számítógépre**, melyeket klaszterbe rendez. Mivel a kulcs nem egyben van letárolva egyetlen gépen, ezért a támadóknak igen nehéz megszerezni azt. Még néhány csomópont is leállhat, a szükséges aláírás akkor is megtörténik a klaszterekben lévő gépek kisebb halmaza által. Ez lecsökkenti az egyetlen meghibásodási pont kockázatát a hálózatban, a validátorkészlet pedig megbízhatóbbá válik. - -![Az ábra azt mutatja, hogy a validátorkulcsot szétosztják kulcsrészekre és több csomópontnak elosztják, melyek különféle komponensekből állnak.](./dvt-cluster.png) - -## Miért van szükség az elosztott validátor technológiára (DVT)? {#why-do-we-need-dvt} - -### Biztonság {#security} - -A validátorok két nyilvános privát kulcspárt hoznak létre: a validátorkulcsot a konszenzusban való részvételhez, a visszavonási kulcsot ahhoz, hogy elérjék a pénzeszközöket. Miközben a visszavonási kulcsot tarthatja a validátor olyan helyen is, ahol lassabban éri el (cold storage), addig a privát kulcsnak folyamatosan online kell lennie (24/7). Ha a validátor privát kulcsa veszélybe kerül, akkor egy támadó átveheti felette a kontrollt, ami súlyos büntetéssel egybekötött kizáráshoz (slashing), illetve a letétbe helyezett ETH elvesztéséhez vezethet. A DVT segít ezt a kockázatot csökkenteni. A működése: - -A DVT használatával a letétbe helyező (staker) részt vehet a letétbe helyezésben, miközben a validátor privát kulcsát cold storage-ban tartja. Ehhez az eredeti, teljes validátorkulcsot titkosítják és azután darabokra osztják. A kulcs darabjai online vannak és több csomópont megkapja azokat, így a validátor működése elosztódik ezek között. Ez azért lehetséges, mert az Ethereum-validátorok BLS aláírást használnak, ami összeadódik, tehát a teljes kulcsot bármikor összerakják a részekből. Tehát a letétbe helyező a teljes, eredeti validátorkulcsát biztonságban tarthatja offline. - -### Nincs egyetlen meghibásodási pont sem {#no-single-point-of-failure} - -Amikor a validátor több operátorra és több gépre van elosztva, akkor lesz offline, ha az egyedi hardverek vagy szoftverek leállnak. A leállás kockázatát azzal is lehet csökkenteni, hogy a klaszterbe tartozó csatlakozási pontoknak eltérő hardver- és szoftverkonfigurációkat állítanak össze. A rugalmasság nem kézzelfogható az egyetlen csatlakozási pontot használó validátorkonfigurációnál – ez a DVT megoldásból származik. - -Ha a klaszter egyik gépének valamelyik komponense leáll (például a klaszter négy operátorából az egyik olyan klienst használ, amelyen hiba van), akkor a többiek biztosítják, hogy a validátor ugyanúgy működjön tovább. - -### Decentralizáció {#decentralization} - -Az Ethereum számára az az ideális szcenárió, ha annyi függetlenül üzemeltetett validátora van, amennyi csak lehetséges. Ugyanakkor néhány letétszolgáltató igen népszerű lett és a teljes letétbe helyezett ETH lényeges részét tudhatja magáénak a hálózaton. A DVT révén lehetséges ilyen operátorok működése, miközben a letétbe helyezett ETH megőrzi decentralizáltságát. Mivel a validátor kulcsai el vannak osztva több számítógépen, és a visszaéléshez sokkal komolyabb összejátszásra lenne szükség. - -A DVT nélkül a letétszolgáltatóknak könnyebb csak egy-két klienskonfigurációt támogatni az összes validátorra, ami megnöveli a kliensből eredő hibák hatását. A DVT-vel ez a kockázat elosztható több klienskonfigurációra és különböző hardverekre, így sokrétűség rugalmasságot teremt. - -**A DVT a következő előnyökkel jár az Ethereum számára:** - -1. **Decentralizálja** az Ethereum proof-of-stake (PoS) konszenzusát -2. Biztosítja a hálózat **aktív, élő állapotát (liveness)** -3. A validátor **toleránssá válik a hibákra** -4. **Minimalizált bizalomigény** jellemzi a validátor működését -5. **Minimalizált büntetéssel egybekötött kizárás (slashing)** és leállási kockázat -6. **Javítja a diverzitást** (kliens, adatközpont, hely, szabályozás stb.) -7. **Nagyobb biztonság** a validátorkulcs kezelését illetően - -## Hogyan működik a DVT? {#how-does-dvt-work} - -A DVT megoldás a következő komponensekből áll: - -- **[Shamir-féle titokmegosztás ](https://medium.com/@keylesstech/a-beginners-guide-to-shamir-s-secret-sharing-e864efbf3648)** – A validátorok [BLS-kulcsokat](https://en.wikipedia.org/wiki/BLS_digital_signature) használnak. Az egyéni BLS-kulcsrészeket össze lehet kapcsolni egy aggregált kulccsá (aláírás). A DVT esetén a validátor privát kulcsa a klaszter operátorainak összekapcsolt BLS-aláírása. -- **[Aláírási küszöb séma](https://medium.com/nethermind-eth/threshold-signature-schemes-36f40bc42aca)** – Meghatározza az egyéni kulcsrészek számát, melyekkel az aláírás meg tud történni, pl. 4-ből 3. -- **[Elosztottkulcs-generálás (DKG)](https://medium.com/toruslabs/what-distributed-key-generation-is-866adc79620)** – Egy kriptográfiai folyamat, ami létrehozza a kulcsrészeket és elosztja egy létező vagy új validátorkulcs részeit a klaszterben található csomópontoknak. -- **[Több résztvevős számítás (MPC)](https://messari.io/report/applying-multiparty-computation-to-the-world-of-blockchains)** – A teljes validátorkulcs titokban készül el a több résztvevős számítás révén. Egyetlen operátor sem ismeri a teljes kulcsot, ők csak a saját részüket ismerik. -- **Konszenzusprotokoll** – A konszenzusprotokoll kiválaszt egy csomópontot, hogy az javasoljon blokkot. Az megosztja a blokkot a klaszter többi csomópontjával, amelyek hozzáteszik a kulcsrészeiket az aggregált aláíráshoz. Amikor a kellő mennyiségű kulcsrészlet összeáll, megtörténhet a blokk előterjesztése az Ethereumon. - -Az elosztott validátorok ellenállóbbak a hibákkal szemben, és akkor is képesek működni, ha az egyéni csomópontok közül néhány leáll. A klaszter tehát ellenálló, még ha a benne lévő csomópontokról ki is derül, hogy ártalmasak vagy lusták. - -## A DVT alkalmazási területei {#dvt-use-cases} - -A DVT jelentős hatást gyakorol a kiterjedtebb letétszolgáltató iparágban: - -### Önálló letétesek {#solo-stakers} - -A DVT lehetővé teszi a nem felügyelt letétbe helyezést is, mivel a validátorkulcsot távoli csomópontok között is el lehet osztani, miközben a teljes kulcsot offline tárolják. Tehát az otthoni letéteseknek nem feltétlenül kell, hogy hardverre költsenek, mivel a kulcsrészek elosztása megerősítheti őket a lehetséges támadások ellen. - -### Letétbe helyezés mint szolgáltatás (SaaS) {#saas} - -Az operátorok (mint letéti alapok és intézményi letétesek), akik sok validátort kezelnek, a DVT révén csökkenthetik kockázatukat. Az infrastruktúra elosztásával a működésükhöz redundanciát (extra kapacitást) tudnak adni és diverzifikálják a hardvertípusok használatát is. - -A DVT megosztja a kulcskezelés felelősségét számod csomóponton keresztül, így az üzemeltetési költség is megosztható. A DVT csökkenti a letétszolgáltatók üzemeltetési kockázatát és biztosítási költségeit. - -### Letéti alapok {#staking-pools} - -A standard validátorbeállítás következtében a letéti alapok és a likvid letétbe helyezők kénytelenek egy operátorral működő validátorban változó szinten megbízni, mivel a nyereségek és a veszteségek az egész alapot érintik. Emellett bízniuk kell az operátorokban, hogy biztonságban tartják az aláírási kulcsokat, mert korábban nem volt erre másik megoldás. - -Habár hagyományos módon tettek erőfeszítéseket, hogy elosszák a kockázatot azáltal, hogy több operátor között elosztják a letétet, de az operátorok még így is jelentős letétet kezelnek független módon. Nagy kockázatot jelent, amikor egyetlen operátorra támaszkodik a folyamat, ha az alulteljesít, leáll, kompromittálódik vagy ártó módon cselekszik. - -A DVT kihasználásával az operátoroknak nem kell másban bízniuk. **Az alapok megengedik az operátoroknak, hogy letétet kezeljenek anélkül, hogy a validátorkulcsot felügyelet alá kellene helyezniük** (mivel csak a kulcsrészeket használják). A kezelt letéteket is több operátor között tudják elosztani (pl. egyetlen operátor helyett, aki 1000 validátort kezel, a DVT-vel ezeket a validátorokat több operátor együtt tudja működtetni). A különféle operátorkonfigurációk biztosítják, hogy az egyik operátor leállásával a többiek még mindig el tudják végezni a tanúsítást. Ennek eredményeként redundancia (extra kapacitás) és diverzifikáció jön létre, ami jobb teljesítményt és rugalmasságot hoz, miközben maximalizálja a nyereséget. - -Az egyoperátoros bizalom minimalizálása következtében a letéti alapok nyitottabb és külön engedélyhez nem kötött operátorrészvételt engedhetnek meg. A szolgáltatóknak így kevesebb kockázattal kell számolniuk, támogatja az Ethereum decentralizációt azáltal, hogy válogatott és külön engedély nélküli operátorcsoportokat is használ, például összepárosítva az otthoni vagy kisebb letéteseket a nagyobbakkal. - -## A DVT lehetséges hátrányai {#potential-drawbacks-of-using-dvt} - -- **Még egy komponens** – DVT-csomópont hozzáadásával még egy összetevő lehet hibás vagy sebezhető. Ennek minimalizálásához arra kell törekedni, hogy a DVT csomópontot többféle beállítással, vagyis több DVT-klienssel kell használni (ahogy a konszenzus és végrehajtási rétegre is többféle kliens létezik). -- **Működési költségek** – mivel a DVT elosztja a validátort több entitás között, ezért (egy helyett) több csomópontra van szükség a működéshez, ami nagyobb költséggel jár. -- **A késedelem lehetséges növekedése** – mivel a DVT konszenzusprotokollt használ ahhoz, hogy megegyezést érjen el a több csomópont között, melyek a validátort működtetik, ezért a késedelem megnövekedhet. - -## További olvasnivaló {#further-reading} - -- [Az Ethereum elosztott validátorának specifikációja (átfogó)](https://github.com/ethereum/distributed-validator-specs) -- [Az Ethereum elosztott validátorának technikai specifikációi](https://github.com/ethereum/distributed-validator-specs/tree/dev/src/dvspec) -- [Shamir titokmegosztási bemutató alkalmazás](https://iancoleman.io/shamir/) diff --git a/public/content/translations/hu/07) Staking Pages/staking/pools/index.md b/public/content/translations/hu/07) Staking Pages/staking/pools/index.md deleted file mode 100644 index 42389afe957..00000000000 --- a/public/content/translations/hu/07) Staking Pages/staking/pools/index.md +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Pooled staking -description: Áttekintés a letéti alapok használatáról -lang: hu -template: staking -emoji: ":money_with_wings:" -image: /images/staking/leslie-pool.png -alt: Leslie, a rinocérosz a medencében fürdik. -sidebarDepth: 2 -summaryPoints: - - Helyezzen letétbe bármennyi ETH-t és szerezzen jutalmakat másokkal együtt - - Hagyja a nehézségeket és bízza a validátor működtetését harmadik félre - - Tartsa a letétbe helyezett összegnek megfelelő tokeneket a saját tárcájában ---- - -## Mik azok a letéti alapok (staking pool)? {#what-are-staking-pools} - -A letéti alap egy olyan kollaboratív megközelítés, mely lehetővé teszi, hogy sok kis összegű ETH révén elérjék a 32 ETH küszöbértéket, ahol már fel tudnak állítani validátort. A letéti alap nem a protokoll része, más megoldások épültek ki, hogy ezt az igényt kielégítsék. - -Néhány letéti alap okosszerződéseket használ, ahol a pénzeszközöket a szerződésbe helyezik letétbe, így bizalomigény nélkül kezeli és követi a letét alakulását, és egy tokent ad, mely a letét értékét képviseli. Más alapok nem használnak okosszerződést, hanem a láncon kívül közvetítenek. - -## Miért jó a letéti alap használata? {#why-stake-with-a-pool} - -A [bevezetés a letétbe helyezésbe](/staking/) során elhangzott előnyök mellett a letéti alapok számos haszonnal járnak. - - - - - - - - - -## Mit kell figyelembe venni {#what-to-consider} - -A letéti alap vagy a delegáción alapuló letétbe helyezés nem része az Ethereum-protokollnak. Ugyanakkor a felhasználók igénye mentén, hogy 32 ETH-nál kisebb összeget adjanak letétbe, egyre több megoldás épül ki. - -Minden egyes alapot és az általuk használt eszközöket vagy okosszerződéseket különböző csapatok fejlesztik, így mind rendelkezik előnyökkel és kockázatokkal. Az alap lehetővé teszi, hogy a felhasználó egy tokent kapjon, ami a letétbe helyezett ETH-t reprezentálja. A token azért hasznos, mert a felhasználó bármennyi ETH-t átválthat egy azonos összegű, jövedelmet generáló tokenre, ami a háttérben lévő ETH letétbe helyezési jutalmaiból ad bevételt (és fordítva) a decentralizált tőzsdéken, még akkor is, ha az aktuális ETH a konszenzusrétegen van letétben. Eszerint a jövedelmet generáló, letétbe helyezett ETH-termék és az eredeti, nyers ETH között gyors és könnyű oda-vissza váltás lehetséges, és nem csak 32 ETH többszöröse érhető el. - -Ugyanakkor ezek a letétbe helyezett ETH tokenek kartellszerű viselkedésre hajlamosítanak, amikor ebből nagyobb összegek kevés centralizált szervezet kontrollja alá kerülnek, ahelyett hogy számtalan egyén között oszlanának el. Ez cenzúrára vagy értéklefölözésre ad lehetőséget. A letétbe helyezés aranyszabálya az, hogy egyének futtatják a validátorokat a saját hardverjükön. - -[A letétbe helyezést képviselő tokenek további kockázatairól](https://notes.ethereum.org/@djrtwo/risks-of-lsd). - -Alább különböző jellemzők mentén mutatjuk be a jelentős erősségeket vagy gyengeségeket, melyekkel a listázott letéti alapok rendelkezhetnek. Ez alapján Ön is megértheti, hogy e jellemzőket hogyan határoztuk meg, és így könnyebben választhat a letéti alapokból. - - - -## Fedezze fel a letéti alapokat {#explore-staking-pools} - -Számos olyan opció érhető el, amely biztosan kielégíti minden igényét. A fenti jellemzőket használva megértheti az alábbi eszközökben rejlő lehetőségeket. - - - - - -Olyan szolgáltatást válasszon, amely komolyan veszi a [kliensek diverzitását](/developers/docs/nodes-and-clients/client-diversity/), mert ez egyszerre javítja a hálózat biztonságát, és csökkenti az Ön kockázatát. Azok a szolgáltatók, akik korlátozzák a többségi klienseket használatát, a következő jellemzők alapján szűrhetők ki: végrehajtási kliens sokrétűsége és konszenzusos kliens sokrétűgése - -Hiányolja valamelyik letétbe helyezési eszközt? Ha a [terméklistázó szabályzat](/contributing/adding-staking-products/) alapján úgy véli, hogy egy adott eszköz illeszkedne ide, akkor jelezze felénk. - -## Gyakran ismételt kérdések {#faq} - - -A letétbe helyezők ERC-20 letéti tokeneket kapnak, és ezeket a letétbe adott ETH-t képviselik, megnövelve azt a jutalmakkal. A különféle alapok a letéti jutalmakat különböző módon adják át a felhasználóknak, a folyamat lényege ugyanakkor közös. - - - -Most azonnal! A Shanghai/Capella-hálózatfrissítés 2023. áprilisban végbement, mely elérhetővé tette a letétek visszavonását. A letéti alapokhoz tartozó validátorszámlák ki tudnak lépni a letétbe helyezésből és vissza tudják vonni az ETH-t a megadott visszavonási címükre. Ez lehetővé teszi, hogy visszavegye a letétrészt a mögöttes ETH-ért cserébe. Ellenőrizze, hogy az adott szolgáltató hogyan támogatja ezt a funkcionalitást. - -Alternatívaként a letéti alapok ERC-20 letéti tokeneket használnak, hogy a felhasználó kereskedni tudjon azokkal a nyitott piacon. Ezzel eladhatja a letéti helyzetét, visszavonva a letétet anélkül, hogy a letéti szerződésben lévő ETH bárhova is átkerülne. - -Bővebben a letétbe helyezés visszavonásáról - - - -Számos hasonló vonás van a letéti alapok opciói és a centralizált tőzsdék között, mivel kis összeggel is részt lehet venni, melyek együtt hoznak létre egy validátort. - -A centralizált tőzsdékhez képes számos letéti alap használ okosszerződést és/vagy letéti tokeneket, olyan ERC-20 tokeneket, melyeket a felhasználó a tárcájában tarthat, és bármikor vehet vagy adhat el azokból. Ez függetlenséget és biztonságot jelent, mivel a felhasználó kontrollálja a tokenjeit, de még mindig nem tudja irányítani a validátorklienst, ami az ő nevében készít tanúsítást a háttérben. - -Néhány letéti alap sokkal decentralizáltabb, amikor az általuk használt csomópontokról van szó. A hálózat egészséges állapota és decentralizációja érdekében a letétbe helyezők olyan letéti alapokat válasszanak, amelyek engedélymentes, decentralizált csomópont-operátorokkal működnek. - - -## További olvasnivaló {#further-reading} - -- [Ethereum letétbe helyezési jegyzék](https://www.staking.directory/) – _Eridian és Spacesider_ -- [Letétbe helyezés a Rocket Poollal – Áttekintés](https://docs.rocketpool.net/guides/staking/overview.html) – _RocketPool docs_ -- [Letétbe helyezés az Ethereumon a Lidoval](https://help.lido.fi/en/collections/2947324-staking-ethereum-with-lido) - _Lido help docs_ diff --git a/public/content/translations/hu/07) Staking Pages/staking/saas/index.md b/public/content/translations/hu/07) Staking Pages/staking/saas/index.md deleted file mode 100644 index c09a8e6c419..00000000000 --- a/public/content/translations/hu/07) Staking Pages/staking/saas/index.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Staking, mint szolgáltatás -description: Egy áttekintő a pooled ETH staking elkezdéséről -lang: hu -template: staking -emoji: ":money_with_wings:" -image: /images/staking/leslie-saas.png -alt: Leslie, a rinocérosz a felhőkön lebeg. -sidebarDepth: 2 -summaryPoints: - - Az Ön validátorkliensét harmadik fél működteti csomópontok kezelésével - - Kiváló lehetőség bárkinek, aki rendelkezik 32 ETH összeggel, de nem szívesen bajlódna a csomópont technikai komplexitásával - - A bizalomigénye kevesebb, a visszavonási kulcsok az Ön saját felügyelete alatt állnak ---- - -## Mi az a letétbe helyezés mint szolgáltatás? {#what-is-staking-as-a-service} - -A letétbe helyezés, mint szolgáltatás (SaaS) egy olyan lehetőség, amikor a felhasználó letétbe teszi a saját 32 ETH összegét, hogy validátort működtessen, de a csomópont üzemeltetését egy harmadik félre bízza. E folyamat során a felhasználót végigvezetik a kezdeti beállításokon, beleértve a kulcs létrehozását, a letét elhelyezését, majd az aláíró kulcsok feltöltését az operátornak. A szolgáltatás így a felhasználó nevében működteti a validátort, általában egy havi díjért cserébe. - -## Miért jó a letéti szolgáltatás használata? {#why-stake-with-a-service} - -Az Ethereum-protokoll eredendően nem támogatja a letétbe helyezés delegálását, így ezek a szolgáltatások képesek ellátni ezt az igényt. Ha Ön letétbe helyezne 32 ETH-t, de nem szeretne a hardveres részével foglalkozni, az SaaS lehetővé teszi, hogy ezt a részét átadja másnak, miközben részesül a blokkjutalmakból. - - - - - - - - - -## Mit kell figyelembe venni {#what-to-consider} - -Az SaaS szolgáltatók száma egyre növekszik, ugyanakkor mind saját előnnyel és kockázattal bír. Az önálló stakinghez képest ezek az opciók mind extra bizalmat igényelnek. Az SaaS opciók rendelkezhetnek olyan hozzáadott programkóddal, melybe az Ethereum-klienst csomagolják, ami nem nyilvános vagy auditálható. Emellett negatív hatást gyakorolnak a hálózat decentralizálására. A beállítások függvényében Ön talán nem is bír kontrollal a validátora felett – az operátor rosszhiszeműen is eljárhat az Ön ETH-ját használva fel. - -Alább különböző jellemzők mentén mutatjuk be a jelentős erősségeket vagy gyengeségeket, melyekkel a listázott SaaS szolgáltatók rendelkezhetnek. Ez alapján Ön is megértheti, hogy e jellemzőket hogyan határoztuk meg, és így könnyebben választhat a szolgáltatók közül. - - - -## Fedezze fel, hogy kik nyújtanak letétbe helyezési szolgáltatást {#saas-providers} - -Néhány elérhető SaaS-szolgáltatót soroltunk fel alább. A fenti jellemzőket használva megértheti az alábbi szolgáltatásokban rejlő lehetőségeket - - - -### SaaS-szolgáltatók - - - -Olyan szolgáltatót válasszon, aki támogatja a [kisebbségi klienseket](/developers/docs/nodes-and-clients/client-diversity/), mert ez egyszerre javítja a hálózat biztonságát, és csökkenti az Ön kockázatát. Azok a szolgáltatók, akik korlátozzák a többségi klienseket használatát, a következő jellemzők alapján szűrhetők ki: végrehajtási kliens sokrétűsége és konszenzusos kliens sokrétűgése - -### Kulcsgenerátorok - - - -Javasolna olyan SaaS-szolgáltatót, akit nem lát felsorolva? Ha a [terméklistázó szabályzat](/contributing/adding-staking-products/) alapján úgy véli, hogy egy adott eszköz illeszkedne ide, akkor jelezze felénk. - -## Gyakran ismételt kérdések {#faq} - - -Minden szolgáltatónál más elrendezés lehetséges, de általában végigvezetik a felhasználót az aláíró kulcsok létrehozásán (minden 32 ETH esetén egy kulcs), és feltöltik ezeket a szolgáltatónak, hogy a felhasználó nevében validáljon. Az aláíró kulcsok magukban nem teszik lehetővé, hogy a pénzeszközöket visszavonják, átutalják vagy elköltsék. Ugyanakkor lehetőséget adnak arra, hogy a konszenzust elősegítsék szavazással, amit ha nem végeznek megfelelően, akkor az kisebb büntetést vagy súlyos büntetéssel egybekötött kizárást von maga után. - - - -Igen. Minden számla tartalmaz BLS aláírási kulcsokat és BLS visszavonási kulcsokat. Annak érdekében, hogy egy validátor tanúsítani tudja a lánc státuszát, részt vehessen a szinkronizációs bizottságokban és blokkot javasoljon, az aláíró kulcsokat elérhetővé kell tenni a validátorkliensben. Valamilyen formában az internethez kell kapcsolódnia, ezért ezeket „forró” kulcsoknak tekinthetjük (online elérhetők). A validátor csak így tud tanúsításokat készíteni, ezért biztonsági okokból az a kulcs külön áll, amelyikkel a pénzeszközöket lehet átutalni vagy visszavonni. - -A BLS visszavonási kulcsok arra valók, hogy egy egyszeri üzenetet írjanak alá, melyik végrehajtási számlára kerüljön a letéti jutalom és a visszavont pénzeszköz. Amint ez az üzenet érvénybe lép, a BLS visszavonási kulcsokra többé nincs szükség. A kulcsok helyett a megadott cím gyakorol kontrollt a visszavont eszközök felett. Még ha valaki más is kontrollálja az aláíró kulcsokat, a visszavonási cím biztonságban van a felhasználó offline tárhelyén (cold storage), ami minimalizálja a validátor-pénzeszközök elvesztését. - -A visszavonási adatok megadása szükséges ahhoz, hogy a visszavonás lehetséges legyen\*. Ehhez létre kell hozni a visszavonási kulcsokat a felhasználó mnemonikus kulcsmondata segítségével. - -Ezt a kulcsmondatot mindig tartsa biztonságban, különben nem lesz képes létrehozni a visszavonási kulcsokat, amikor szükség lenne azokra. - -\*Azoknak a letéteseknek, akik már megadták a visszavonási címüket a folyamat kezdetén, nem kell ezt beállítani. Ellenőrizze az SaaS-szolgáltatójával, hogy hogyan kell a validátort beállítani. - - - -A letétek visszavonása a Shanghai/Capella frissítéssel vált elérhetővé 2023. áprilisban. A letéteseknek meg kell adniuk egy visszavonási címet (ha nem adták meg azt a letét kezdetekor), és a jutalmak automatikusan kiküldésre kerülnek néhány naponta. - -A validátorok ki is léphetnek a funkciójukból, ami felszabadítja a fennálló ETH-összeget a visszavonáshoz. Azok a számlák, amelyek megadták a visszavonási címet és teljesítették a kilépési folyamatot, a teljes egyenleget megkapják az adott címre a következő validátor-ellenőrzésnél. - -Bővebben a letétbe helyezés visszavonásáról - - - -Az SaaS-szolgáltatóval a felhasználó másra bízza a csomópontok üzemeltetését. Ez magába foglalja a gyenge csomópont-teljesítmény kockázatát, mivel az nem a felhasználó irányítása alá esik. Ha a validátor súlyos büntetést kap (slashing), akkor a validátor egyenlegéből elvonnak és kizárják a validálásból. - -A büntetés végrehajtása után a megmaradt pénzeszközök a validátor visszavonási címére kerülnek. Ehhez szükség van egy visszavonási címre. Előfordulhat, hogy ezt a letétbe helyezéskor már megadta. Ha nem, akkor a validátor-visszavonási kulcsokkal lehet aláírni egy üzenetet, amely közli a visszavonási címet. A pénzeszközök zárolva maradnak addig, amíg a visszavonási cím nem elérhető. - -Kérdezze meg az SaaS-szolgáltatóját a lehetséges garanciákról vagy biztosításokról, illetve arról, hogyan lehet a visszavonási címet megadni. Ha Ön szeretné teljes mértékben kontrollálni a validátor-beállításokat, akkor ismerje meg az önálló letétbe helyezést. - - -## További olvasnivaló {#further-reading} - -- [Ethereum letétbe helyezési jegyzék](https://www.staking.directory/) – _Eridian és Spacesider_ -- [A letétbe helyezési szolgáltatások értékelése](https://www.attestant.io/posts/evaluating-staking-services/) – _Jim McDonald 2020._ diff --git a/public/content/translations/hu/07) Staking Pages/staking/solo/index.md b/public/content/translations/hu/07) Staking Pages/staking/solo/index.md deleted file mode 100644 index d011301a23b..00000000000 --- a/public/content/translations/hu/07) Staking Pages/staking/solo/index.md +++ /dev/null @@ -1,206 +0,0 @@ ---- -title: Egyéni letétbe helyezés -description: Az egyéni letétbe helyezés áttekintése -lang: hu -template: staking -emoji: ":money_with_wings:" -image: /images/staking/leslie-solo.png -alt: Leslie, a rinocérosz a saját számítógépes chipjén. -sidebarDepth: 2 -summaryPoints: - - Szerezzen maximális jutalmat közvetlenül a protokolltól azért, hogy a validátorát megfelelően működteti és az folyamatosan online - - Működtessen az otthonából hardvert és támogassa személyesen az Ethereum hálózatának biztonságát és decentralizálását - - Nem kell másban megbíznia, és az eszközeihez tartozó kulcsok mindig az Ön kontrollja alatt állnak ---- - -## Mi az az egyéni letétbe helyezés? {#what-is-solo-staking} - -Az egyéni letétbe helyezés során a felhasználó egy [Ethereum-csomópontot működtet](/run-a-node/) az internethez csatlakozva, letétbe helyez 32 ETH-t, hogy aktiváljon egy [validátort](#faq), így közvetlenül részt tud venni a hálózat konszenzusfolyamatában. - -**Az egyéni letétbe helyezés növeli az Ethereum hálózatának decentralizációját**, így az ellenállóbb lesz a cenzúrával és a támadásokkal szemben. A többi letétbe helyezési módszer nem feltétlen segíti a hálózatot ugyanilyen módon. Az egyéni letétbe helyezés a legjobb letéti opció az Ethereum biztosítására. - -Az Ethereum-csomópontot egy végrehajtási réteg (EL) klienst és egy konszenzus réteg (CL) klienst tartalmaz. Ezek a kliensek olyan szoftverek, amelyek együtt dolgoznak egy érvényes aláírókulcs-készlettel együtt, hogy érvényesítsék a tranzakciókat és a blokkokat, tanúsítsák a lánc státuszát, aggregálják a tanúsítványokat és blokkokat javasoljanak. - -Az egyéni letétbe helyezők azért felelnek, hogy a kliensek futásához szükséges hardvert működtetik. Azt javasoljuk, hogy erre egy dedikált gépet használjanak, melyet otthonról üzemeltetnek, mert ez rendkívül hasznos a hálózat egészsége szempontjából. - -Az egyéni letétbe helyező közvetlenül a protokolltól kap jutalmakat azért, hogy a validátora megfelelően működik és online van. - -## Miért legyek egyéni letétbe helyező? {#why-stake-solo} - -Az egyéni letétbe helyezés több felelősséggel jár, de teljes kontrollt biztosít a pénzeszközök és a staking felállítás felett. - - - - - - - -## Megfontolandó dolgok, mielőtt belevágna az egyéni letétbe helyezésbe {#considerations-before-staking-solo} - -Bármennyire is szeretnénk, hogy az egyéni letétbe helyezés elérhető és kockázatmentes legyen mindenkinek, ez nem lehet elérni. Mielőtt belevágna, komoly gyakorlati megfontolásokkal kell szembenéznie. - - - -Saját csomópont működtetéséhez meg kell tanulni a választott szoftver használatát. El kell olvasni a rendelkezésre álló dokumentációt és ráhangolni a fejlesztői csapatok kommunikációs csatornáira. - -Minél többet tud a választott szoftverről és a proof-of-stake működéséről, annál kevésbé kockázatos a letétbe helyezés, illetve a felmerülő problémák kezelése a csomópont-operátor szerepében. - - - -A csomópont beállításához egy bizonyos szintű számítógépes gyakorlat szükséges, habár az új eszközök egyre inkább megkönnyítik ezt a feladatot is. A parancssoros felhasználói felület (command-line interface) ismerete hasznos, de nem elengedhetetlen. - -Alapvető hardverösszeállításra, illetve a javasolt minimális specifikáció megértésére van szükség. - - - -Ahogy a privát kulcs biztosítja az Ethereum-címet, úgy a validátorhoz is létre kell hozni kulcsokat. Tudnia kell, hogyan tartsa a kulcsmondatokat vagy privát kulcsokat biztos helyen.{' '} - -Ethereum biztonság és csalásmegelőzés - - - -A hardver néha leáll, a hálózati kapcsolat hibára fut, a kliensszoftvert néha frissíteni kell. A csomópont karbantartása elkerülhetetlen, ezzel foglalkozni kell. Muszáj naprakésznek lennie minden várható hálózati frissítésről vagy más kritikus kliensfrissítésről. - - - -A jutalmazás annak arányában történik, hogy a validátor mennyi időt van online és megfelelő módon végzi-e a tanúsítást. A leállás miatti büntetések annak függvényében vannak megállapítva, hogy ugyanakkor hány validátor volt még offline, ez azonban nem von maga után súlyos büntetést és kizárást (slashing). A sávszélesség is számít, mert a tanúsításért járó jutalmak csökkenek, ha azok nem érkeznek meg időben. A szükséges paraméterek változhatnak, de érdemes legalább 10 Mb/s fel- és letöltési sebességgel számolni. - - - -Az inaktív állapot miatti büntetéstől különbözik a súlyos büntetéssel egybekötött kizárás (slashing), ami rosszhiszemű vétségekért jár. Ha kisebbségi klienst használ és a kulcsokat csak egy gépre tölti fel, akkor a slashing kockázata minimális. Ettől függetlenül minden letétbe helyezőnek szembe kell néznie a slashing kockázatával. - -Bővebben a slashingről és a validátor életciklusáról - - - - - -## Hogyan működik {#how-it-works} - - - -Mialatt Ön aktív, ETH jutalmakat kap, melyeket rendszeresen elhelyeznek a visszavonási számlán. - -Bármikor kiléphet a validátor szerepéből, így nem kell online lennie, és leállnak a jutalmak. Ekkor a maradék egyenlege visszatér a visszavonási címre, melyet a felállításnál adott meg. - -[Bővebben a letétbe helyezés visszavonásáról](/staking/withdrawals/) - -## Induljon el a Staking Launchpad segítségével {#get-started-on-the-staking-launchpad} - -A Staking Launchpad egy nyílt forráskódú alkalmazás, ami segít a letétbe helyezés folyamatában. Végigvezeti Önt a szükséges lépéseken, mint a kliensek kiválasztása, a kulcsok létrehozása és az ETH letétbe helyezése a letéti szerződésbe. Egy ellenőrzőlistán is végigveheti, hogy minden a rendelkezésre áll, hogy biztonsággal működjön a validátora. - - - -## Mit kell figyelembe venni a csomópont- és kliensbeállító eszközöknél {#node-tool-considerations} - -Az egyéni letétbe helyezést segítő eszközök és szolgáltatások száma egyre növekszik, de mindnél áll fenn kockázat, ugyanúgy mind előnyökkel is jár. - -Alább különböző jellemzők mentén mutatjuk be a jelentős erősségeket vagy gyengeségeket, melyekkel a listázott letéti eszközök rendelkezhetnek. Ez alapján Ön is megértheti, hogy e jellemzőket hogyan határoztuk meg, és így könnyebben választhat a szükséges eszközök közül. - - - -## Fedezze fel a csomópont- és kliensbeállító eszközöket {#node-and-client-tools} - -Számos olyan opció érhető el, amely biztosan kielégíti minden igényét. A fenti jellemzőket használva megértheti az alábbi eszközökben rejlő lehetőségeket. - - - -### Csomóponteszközök - - - -Olyan szolgáltatót válasszon, aki komolyan veszi a [kliensek diverzitását](/developers/docs/nodes-and-clients/client-diversity/), mert ez egyszerre javítja a hálózat biztonságát, és csökkenti az Ön kockázatát. Azok az eszközök, amelyek a kisebbségi kliens beállítást támogatják, a többklienses jellemzővel vannak jelölve - -### Kulcsgenerátorok - -Ezek alternatív eszközök a [Staking Deposit CLI](https://github.com/ethereum/staking-deposit-cli/) mellett, hogy a kulcsok le legyenek generálva. - - - -Hiányolja valamelyik letétbe helyezési eszközt? Ha a [terméklistázó szabályzat](/contributing/adding-staking-products/) alapján úgy véli, hogy egy adott eszköz illeszkedne ide, akkor jelezze felénk. - -## Nézze meg az egyéni letétbe helyezésre vonatkozó útmutatókat {#staking-guides} - - - -## Gyakran ismételt kérdések {#faq} - -Ezek a leggyakrabban felmerülő kérdések a letétbe helyezés kapcsán, melyről érdemes Önnek is tudnia. - - - -A validátor egy virtuális entitás, ami az Ethereumon működik és a protokoll konszenzusfolyamatában vesz részt. A validátort az egyenleg, a nyilvános kulcs és más tulajdonságok jellemzik. A validátorkliens az a szoftver, ami a validátor nevében működik, tárolva és felhasználva annak privát kulcsát. Egy validátorkliens több kulcspárt is tárolhat, így több validátort is üzemelhet. - - - - -A validátorhoz tartozó kulcspár pontosan 32 ETH összeget igényel ahhoz, hogy aktívvá váljon. Ha a kulcsokhoz több ETH kerül letétbe, az nem növeli meg a jutalmak lehetőségét, mert a validátor érvényes egyenlege 32 ETH. Tehát a letétbe helyezés 32 ETH összegenként történik, melyekhez saját kulcs és egyenleg tartozik. - -Egy validátorhoz ne kössön le többet, mint 32 ETH. Ez nem hoz több nyereséget. A validátor-ellenőrzés során a 32 ETH feletti rész automatikusan átkerül a visszavonási címre, ha az be van állítva a validátorhoz. - -Ha az egyéni letétbe helyezés túl nagy erőfeszítést igényelne Öntől, akkor nézze meg a letétbe helyezés, mint szolgáltatás opcióit, vagy ha kevesebb mint 32 ETH összegről van szó, akkor fontolja meg a letéti alapok szolgáltatást. - - - -Nem vezet súlyos büntetéshez és kizáráshoz (slashing) az, ha a validátor offline, de a hálózat állapota megfelelő. Kis mértékű inaktivitási büntetések várhatók, ha a validátor nem elérhető a tanúsításhoz egy adott korszakban (mely 6,4 perc hosszú), ez azonban különbözik a súlyos büntetéssel járó kizárástól (slashing). A kis büntetések kicsit kevesebbek, mint az a jutalom, amit a validátor a tanúsításért kapott volna, az elvesztett pénzt pedig vissza lehet nyerni ugyanannyi online töltött idővel. - -Az inaktivitási büntetés mértéke függ attól, hogy ugyanabban az időben mennyi validátor van offline. Ha a hálózat nagy része mind egyszerre lesz offline, akkor a büntetés sokkal nagyobb ezen validátorok esetében, mintha csak egy validátor lenne elérhetetlen. - -Szélsőséges esetben, ha a hálózat nem tud állapotot frissíteni, mert a validátorok harmada offline van, akkor ezek a felhasználók a kvadratikus inaktivitási elszivárgást szenvedik el, vagyis a validátorszámlákról exponenciálisan kiáramlik az ETH. Ezzel a rendszer végül képes helyrebillenteni magát azáltal, hogy az inaktív validátorok ETH-jét elégeti, amíg az egyenlegük 16 ETH lesz és ezzel automatikusan kilökődnek a validátorok közül. A megmaradó online validátorok végül teljesítik a több mint 2/3 arányt, kielégítve a túlnyomó többség elvét, hogy a lánc állapota megint frissítve legyen. - - - -Röviden, bár nem lehet garantálni, de a slahing kockázata szinte nulla, hogy ha jóhiszeműen jár el, kisebbségi klienst használ, az aláíró kulcsokat pedig csak egy gépen tartja. - -Néhány specifikus eset van, amikor a validátor súlyos büntetést kap és kilökik a hálózatból. A korábbi eseteknél kizárólag redundáns hardver volt beállítva, és az aláíró kulcsokat két különböző gépen tárolták egyszerre. Ez akaratlanul is dupla szavazást eredményezhet a kulcsokkal, ami súlyos vétség. - -Egy többségi kliens használatával (amit a hálózat 2/3 használ) is nő a slashing kockázata, hogyha a kliensben hiba áll fenn, és emiatt egy láncelágazás jön létre. Hibás elágazást okozhat, ami a lánc állapotaként rögzítésre kerül. Ahhoz, hogy visszatérjen a valódi lánc állapotához, egy „surround” szavazatot kell leadni egy véglegesített blokk visszaállításával. Ez is egy súlyos vétség, és elkerülhető a kisebbségi kliensek használatával. - -A kisebbségi kliensben lévő hiba nem fog végleges állapotot eredményezni, így nem vezet ahhoz, hogy két különböző állapotra szavazzanak helyenként (surround szavazat), és egyszerű inaktivitási büntetéssel jár, nem slashinggel. - - - - - -Az egyéni kliensek esetében kicsit különböző a teljesítmény, a felhasználói felület, mivel mindet különböző csapatok fejlesztik, különböző programozási nyelveken. Így nincsen „legjobb” kliens. Az összes működő kliens kiváló szoftver, melyek működési elve azonos, hogy szinkronizáljanak és kapcsolódjanak a blokklánchoz. - -Mivel az összes kliens ugyanazokat az alapvető funkcionalitásokat kínálja, így fontos, hogy Ön egy kisebbségi klienst válasszon, tehát nem azokat, amelyeket a validátorok többsége használ. Ez talán ellentmond a logikus gondolkodásnak, de a többségi vagy szupertöbbségi kliensek használata miatt megnő a slaghing kockázata, ha a kliensben valamilyen hiba van. Ezt a kockázatot jelentősen lecsökkenti egy kisebbségi kliens használata. - -Tudjon meg többet arról, hogy kliensdiverzitás miért kritikus fontosságú - - - -Habár a virtuális privát szerver (VPS) használható az otthoni hardver helyett, a validátorkliens fizikai elérhetősége és helye igenis számít. A centralizált felhőszolgáltatások, mint az Amazon Web Services vagy a Digital Ocean, lehetővé teszik, hogy nem kell hardvert venni és működtetni, de ez hatással van a hálózat centralizáltságára. - -Minél több validátorkliens működik ugyanazon a centralizált felhőszolgáltatón, annál veszélyesebbé válik a felhasználóknak. Ha ezek a szolgáltatók bármilyen esemény miatt elérhetetlenné válnak, legyen akár támadás, szabályozási kötelezettség, áram- vagy internetleállás, az összes validátorkliens ugyanakkor lesz offline. - -Az offline büntetések arányosak azzal, hogy hány validátor van még offline ugyanakkor. A VPS használata megnöveli az offline büntetés várható mértékét, a kvadratikus elszivárgás vagy akár a slashing kockázatát is, ha a kimaradás kellően nagy mértékű. A saját és a hálózat kockázatát minimalizálandó a felhasználó jobban jár, ha saját hardvert szerez és üzemeltet. - - - - -A Beacon-láncról való visszavonáshoz be kell állítani a visszavonási adatokat. - -Az új letétesek ezt megtették a kulcsgenerálás és a letétbe helyezés során. A meglévő letétesek, akik még nem állították ezt be, frissíthetik a kulcsaikat ezzel a funkcióval. - -Amint a visszavonási adatok be vannak állítva, a jutalmak (a 32 ETH-en felüli rész) rendszeresen és automatikusan átkerülnek a visszavonási címre. - -A teljes egyenleg visszavonásához végig kell menni a validátorkiléptetési folyamaton. - -Bővebben a letétbe helyezés visszavonásáról - - -## További olvasnivaló {#further-reading} - -- [Ethereum letétbe helyezési jegyzék](https://www.staking.directory/) – _Eridian és Spacesider_ -- [Az Ethereum-kliens diverzitásának problémája](https://hackernoon.com/ethereums-client-diversity-problem) – _@emmanuelawosika 2022._ -- [A kliensdiverzitás támogatása](https://www.attestant.io/posts/helping-client-diversity/) – _Jim McDonald 2022._ -- [Kliensdiverzitás az Ethereum konszenzus rétegén](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) – _jmcook.eth 2022._ -- [Hogyan kell: Ethereum validátorhardver vásárlása](https://www.youtube.com/watch?v=C2wwu1IlhDc) – _EthStaker 2022._ -- [Lépésről lépésre: hogyan kell csatlakozni az Ethereum 2.0 teszthálózathoz](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) – _Butta_ -- [Eth2 Slashing elkerülési tippek](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) – _Raul Jordan 2020._ - - diff --git a/public/content/translations/hu/07) Staking Pages/staking/withdrawals/index.md b/public/content/translations/hu/07) Staking Pages/staking/withdrawals/index.md deleted file mode 100644 index 85c19d15b1d..00000000000 --- a/public/content/translations/hu/07) Staking Pages/staking/withdrawals/index.md +++ /dev/null @@ -1,218 +0,0 @@ ---- -title: A letétbe helyezés visszavonása -description: A letétvisszavonás működésének és a jutalmak megszerzésének áttekintése -lang: hu -template: staking -image: /images/staking/leslie-withdrawal.png -alt: Leslie, a rinocérosz a letétbe helyezésből származó jutalmaival -sidebarDepth: 2 -summaryPoints: - - A Shanghai/Capella frissítés lehetővé tette a letétek visszavonását az Ethereumon - - A validátor operátorainak meg kell adni ehhez egy visszavonási címet - - A jutalmakat néhány naponta automatikusan átkerülnek - - A validátorok, akik teljesen kiszállnak a letétből, a maradék egyenleget visszakapják ---- - - -A letétek visszavonását a 2023. április 12-i Shanghai/Capella frissítés tette lehetővé. Bővebben a Shanghai/Capella frissítésről - - -**A letétek visszavonása** azt jelenti, hogy a validátorszámla ETH-egyenlege, ami az Ethereum konszenzusrétegén található (Beacon-lánc), áthelyezésre kerül a végrehajtási rétegre, ahol fel lehet használni. - -**A jutalmak kifizetése** 32 ETH felett automatikusan és rendszeresen megtörténik az egyes validátorokhoz tartozó visszavonási címre, ahogy azt a felhasználó beállította. A felhasználó **teljesen kiszállhat a letétbe helyezésből**, felszabadítva a teljes validátoregyenleget. - -## A letétbe helyezésből eredő jutalmak {#staking-rewards} - -Az aktív validátorszámlákra a jutalmak kifizetése automatikusan megtörténik, és maximum 32 ETH egyenleg marad azokon. - -A 32 ETH feletti összeg nem adódik hozzá az alaphoz, nem növeli a validátor súlyát a hálózaton, így automatikusan visszavonásra kerül jutalomként néhány naponta. A visszavonási címet rögzíteni kell, de ezen kívül a validátor működtetőjének nincs több teendője. Ez a konszenzusrétegen zajlik, ezért nincs gáz/tranzakciós díj vonzata egyik lépésnél sem. - -### Hogyan jutottunk el idáig? {#how-did-we-get-here} - -Az elmúlt években az Ethereum számos hálózati fejlesztésen esett át, hogy a hálózatot az ETH biztosítsa, és ne az erőforrás-igényes bányászás (mining). A konszenzusban való részvétel az Ethereumon a letétbe helyezés (staking), mivel a tagok önként lekötötték az ETH-t, hogy a hálózatban részt tudjanak venni. A szabályokat követő felhasználók jutalmakat nyernek, a visszaélést pedig bünteti a rendszer. - -A letétbe helyezési szerződés létrehozásával (2020. november) néhány bátor Ethereum-úttörő önként zárolta a pénzeszközeit, hogy validátorokként működjenek – ezek olyan különleges számlák, melyek hivatalosan tanúsíthatnak és javasolhatnak blokkot a hálózat szabályait követve. - -A Shanghai/Capella frissítés előtt nem lehetett használni vagy elérni ezt a lekötött ETH-t. Most azonban automatikusan áthelyeződnek a jutalmak a kiválasztott számlára, és a lekötést is bármikor fel lehet oldani. - -### Hogyan tudok erre felkészülni? {#how-do-i-prepare} - - - -### Fontos figyelmeztetések {#important-notices} - -A visszavonási cím megadása szükséges ahhoz, hogy a validátorszámla egyenlegéből ETH visszavonás történjen. - - - Minden validátorszámlához egyszer, egyetlen visszavonási cím adható meg. Amint ezt a címet kiválasztották és elküldték a konszenzus rétegnek, nem lehet visszahívni vagy megváltoztatni. Ellenőrizze le a cím tulajdonosát és pontosságát, mielőtt elküldi azt. - - -Eközben a pénzeszközöket nem fenyegeti veszély, ha nem adja meg a címet, feltéve, hogy a mnemonikus/kulcsmondat biztonságban van offline, és nincs kitéve veszélynek. Amíg nem tudja megadni a visszavonási adatokat, addig az ETH egyszerűen a validátorszámlán marad. - -## A letétbe helyezés felbontása {#exiting-staking-entirely} - -A visszavonási számlára van szükség ahhoz, _bármilyen_ pénzeszközt ki lehessen utalni a validátorszámla egyenlegéből. - -Azoknak a felhasználóknak, akik teljesen ki akarnak lépni a letétbe helyezéből és a teljes egyenleget vissza akarják vonni, a validátorkulcsokkal alá kell írniuk és ki kell adniuk egy önként kiszállok üzenetet, ezzel elindul a lezárás folyamata. Ezt a validátorkliens végzi és a konszenzus csomópontjára küldi el, így nem kell hozzá gáz/díj. - -A kilépés változó ideig tart, attól függően, hogy hányan akarnak ugyanakkor kiszállni. Amint végbemegy, ez a számla már nem végez validátori feladatokat, nem jár neki ezért jutalom, és a kapcsolódó ETH nincs letétbe helyezve. Ekkora a számla teljesen „visszavonhatóként” lesz megjelölve. - -Ha a visszavonható jelölés megtörtént és a visszavonási adatok meg lettek adva, akkor nincs több teendő. A blokkot javaslók automatikusan és folyamatosan ellenőrzik, mondhatni söprik a számlákat a kilépő pénzeszközöket vizsgálva, így a számla egyenlege teljes mértékben átvezetésre kerül a következő söprésnél. - -## Mikortól elérhető a letétek visszavonása? {#when} - -A letétek visszavonása elérhető! A funkcionalitást a Shanghai/Capella frissítés tette elérhetővé 2023. április 12-én. - -Ennek következtében a korábban letétbe helyezett ETH-t vissza lehet vonni a normális Ethereum-számlákra. Ez lezárta a letétek likviditásának témáját, és az Ethereumot egy lépéssel közelebb vitte a céljához, ami egy fenntartható, skálázható, biztonságot, decentralizált ökoszisztéma. - -- [Bővebben az Ethereum történetéről](/history/) -- [Bővebben az Ethereum fejlesztési terveiről](/roadmap/) - -## Hogyan működik a visszavonási kifizetés? {#how-do-withdrawals-work} - -A validátorszámla státusza mondja meg, hogy egy validátor jogosult-e a visszavonásra vagy sem. Nincs szükség a felhasználó közreműködésére, hogy a számla visszavonásra kerül-e vagy sem – a teljes folyamat automatikusan üzemel a konszenzus réteg által, egy állandóan működő ciklusban. - -### Ön inkább vizuális típus? {#visual-learner} - -Nézze meg az Ethereum letétvisszavonásról szóló magyarázatát a Finematics-tól: - - - -### Validátor-ellenőrzés vagy söprés {#validator-sweeping} - -Amikor egy adott validátor be van ütemezve, hogy a következő blokkot ő fogja javasolni, akkor készítenie kell egy 16 tételből álló visszavonási listát. Kezdve a 0 validátorindexel, meghatározza, hogy az adott számla a protokoll szabályai szerint visszavonásra jogosult-e, és ha igen, akkor beteszi a listába. A validátorcsoport ott száll be, ahol az előző abbahagyta és a végtelenségig folytatja. - - -Képzeljen el egy analóg módon működő órát. Az óramutató egy irányba halad és sorban végigmegy minden számon, majd miután elérte az utolsó számot, visszaér a kezdőpontra.

-Tegyük fel 1–12 helyett 0-n található (ahol n a validátor számlák teljes száma, amelyek a konszenzus rétegen regisztrálva lettek; több mint 500 000 2023. januárjában).

-Az óramutató a következő validátorra mutat, hogy leellenőrizze azt visszavonás szempontjából. A 0-nál kezdi és végigmegy az összes számlán. Amikor eléri az utolsó validátort, akkor a ciklus újra elindul. - - -#### A számlák ellenőrzése visszavonási szempontból {#checking-an-account-for-withdrawals} - -Miközben a blokk javaslója a validátorokat ellenőrzi a lehetséges visszavonások miatt, minden validátornál néhány kérdéssel ellenőrzi, hogy kell-e visszavonást indítani, és mennyi ETH-t érint ez. - -1. **Van visszavonási cím megadva?** Ha nincs, akkor kihagyja a számlát, és nem lehet visszavonást kezdeményezni. -2. **A validátor kiszállt és visszavonható a számlája?** Ha a validátor kiszállt, és a számlája „visszavonhatóvá” vált, akkor egy teljes visszavonás történik. A teljes egyenlege átkerül a visszavonási címre. -3. **Az érvényes egyenleg 32 ETH?** Ha a számla rendelkezik visszavonási adatokkal, nem lépett ki a letétbe helyezésből, de jutalmak vannak a 32 ETH összegen túl, akkor egy részleges visszavonás indul, ami a 32 ETH feletti jutalmakat áthelyezi a visszavonási címre. - -Csak két döntés vagy cselekvés van, amit a validátor üzemeltetője meglép a validátor életciklusa során, és ezt a folyamatot közvetlenül befolyásolja: - -- A visszavonási adatok biztosítása, hogy bármit át lehessen vezetni -- A hálózatból való kilépés, ami egy teljes visszavonást indít el - -### Gáz/díjmentes {#gas-free} - -A letétek visszavonása anélkül zajlik, hogy a letétesnek tranzakciót kellene indítania, amiben adott mennyiségű ETH-t von ki. Ezért **nincs gáz/tranzakciós díj**, a visszavonások pedig nem versenyeznek, hogy bekerüljenek a végrehajtási réteg blokkjába. - -### Milyen gyakran kapom meg a letéti jutalmakat? {#how-soon} - -Egy blokkban maximum 16 visszavonást lehet végrehajtani. Ez alapján 115 200 validátor-visszavonást lehet egy nap alatt teljesíteni (ha minden slot eredményes). A visszavonásra nem jogosult validátárokat átugorják, ezért a teljes ellenőrzés kevesebb ideig tart. - -Ezt a kalkulációt kiterjesztve megbecsülhetjük, hogy egy adott számú visszavonást mennyi idő alatt lehet teljesíteni: - - - -| Visszavonások száma | Időszükséglet | -| :-------------------: | :--------------: | -| 400 000 | 3,5 nap | -| 500 000 | 4,3 nap | -| 600 000 | 5,2 nap | -| 700 000 | 6,1 nap | -| 800 000 | 7,0 nap | - - - -Ahogy látható, a feldolgozás lelassul, ahogy egyre több validátor van a hálózaton. A kihagyott slotok száma arányosan le tudja lassítani a folyamatot, de ez a lassabb verzióját mutatja a lehetséges kimenetnek. - -## Gyakran ismételt kérdések {#faq} - - -Nem, a visszavonási adatok megadása egyszeri, nem lehet változtatni azokon. - - - -A végrehajtási réteg visszavonási cím megadásával a validátor visszavonási adatai örökre megváltoztak. A korábbi adatok már nem működnek, az újak pedig a végrehajtási réteg számlájára mutatnak. - -A visszavonási cím lehet okosszerződés (melyet a programkódja irányít) vagy egy külső tulajdonú számla (EOA, melyet a privát kulcsa kontrollál). Ezek a számlák jelenleg nem tudnak üzenetet küldeni a konszenzusrétegnek, amely megváltoztatná a validátor hitelesítő adatait, ez a funkció pedig egy szükségtelen komplexitást adna a protokollhoz. - -Egy másik megoldás az adott validátorhoz tartozó visszavonási cím módosítására, ha a felhasználók okosszerződést választanak visszavonási címként, amely tudja kezelni a kulcsok rotálását, mint amilyen a Safe. Azok a felhasználók, akik a saját EOA számlájukra tették a pénzeszközöket, végezhetnek teljes kilépést, visszavonva az összes lekötött eszközt, majd újra letétbe helyezhetik az új hitelesítő adatokat használatával. - - - - -Ha Ön letéti alapokat vagy letéti tokeneket használ, ellenőrizze a szolgáltatójával, hogy hogyan kezelik a letétvisszavonást, mivel minden szolgáltatás másképp működik. - -Általánosságban a felhasználók szabadon visszavehetik a letétbe helyezett ETH-t vagy lecserélhetik a letéti szolgáltatójukat. Ha egy adott letéti alap túl nagy méretű lesz, akkor a pénzeszközöket ki lehet venni belőle és újra le lehet kötni egy kisebb szolgáltatóval. Ha pedig elég ETH gyűlt össze, akkor Önotthonról is végezhet letétbe helyezést. - - - - -Igen, ha a validátora megadta a visszavonási címet. Ezt egyszer kell megtenni, hogy a visszavonások teljesíthetők legyenek, utána a jutalmak automatikusan átkerülnek néhány naponta a validátorok ellenőrzésénél. - - - - -Nem, ha a validátor aktív a hálózaton, akkor a teljes visszavonás nem történik meg automatikusan. Az önkéntes kilépést manuálisan kell kezdeményezni. - -Amint a validátor végigvitte a kilépési folyamatot, a számlán pedig ott vannak a visszavonási adatok, akkor a maradék egyenleget átteszi a következő validátor-ellenőrzés. - - - - -A visszavonásokat úgy tervezték meg, hogy automatikusan minden olyan összeget áthelyezzenek, ami aktívan nem járul hozzá a letéthez. Ez érvényes a kilépő számlák teljes egyenlegére. - -Nem lehetséges manuálisan kérvényezni bizonyos mennyiségű ETH kivételét. - - - - -Javasoljuk, hogy a validátorműködtetők látogassanak el a Staking Launchpad Withdrawals oldalra, ahol további információkat találhatnak a letét kivonásához kapcsolódó felkészülésről, az események időzítéséről és arról, hogyan működik ez a kivonási funkció. - -Próbálja ki először a beállításait egy teszthálózaton, látogasson el a Holesky-teszthálózat Staking Launchpad oldalára. - - - - -Nem. Miután egy validátor kilépett, és a teljes egyenlegét kivette, az adott validátorra letétbe helyezett további összegek automatikusan átutalásra kerülnek a következő validátor-ellenőrzés során a visszavonási címre. Az ETH újbóli letétbe helyezéséhez egy új validátort kell aktiválni. - - -## További olvasnivaló {#further-reading} - -- [Staking Launchpad visszavonások](https://launchpad.ethereum.org/withdrawals) -- [EIP-4895: Beacon-lánc operációs műveletként intézi a visszavonásokat](https://eips.ethereum.org/EIPS/eip-4895) -- [Ethereum Cat Herders – Shanghai](https://www.ethereumcatherders.com/shanghai_upgrade/index.html) -- [PEEPanEIP #94: A letétbe helyezett ETH visszavonása (tesztelés) – Potuz & Hsiao-Wei Wang](https://www.youtube.com/watch?v=G8UstwmGtyE) -- [PEEPanEIP#68: EIP-4895: Beacon lánc operációs műveletként intézi a visszavonásokat – Alex Stokes](https://www.youtube.com/watch?v=CcL9RJBljUs) -- [A validátor valós egyenlegének megértése](https://www.attestant.io/posts/understanding-validator-effective-balance/) diff --git a/public/content/translations/hu/08) Use cases 2/decentralized-identity/index.md b/public/content/translations/hu/08) Use cases 2/decentralized-identity/index.md deleted file mode 100644 index 3b3d473c38d..00000000000 --- a/public/content/translations/hu/08) Use cases 2/decentralized-identity/index.md +++ /dev/null @@ -1,191 +0,0 @@ ---- -title: Nem központilag kibocsájtott identitás -description: Mi az a nem központilag kibocsátott identitás, és miért fontos? -lang: hu -template: use-cases -emoji: ":id:" -sidebarDepth: 2 -image: /images/eth-gif-cat.png -summaryPoint1: A hagyományos identitásrendszerek központosították az azonosítók kiadását, karbantartását és ellenőrzését. -summaryPoint2: A decentralizált identitás megszünteti a centralizált harmadik felektől való függőséget. -summaryPoint3: A kriptónak köszönhetően, a felhasználóknak újra van eszközük, hogy tárolják és kezeljék a saját azonosítójukat és tanúsítványaikat. ---- - -A virtuális identitás az életünk minden részét meghatározza napjainkban. Online szolgáltatások használata, bankszámla nyitás, szavazás a választásokon, ingatlan vásárlása, munkavállalás – mindegyikhez az identitás igazolása szükséges. - -Azonban a hagyományos azonosításkezelési rendszerek hosszú ideje központosított szereplőkre támaszkodtak, akik kibocsátják, tárolják és kezelik az azonosítóinkat és [tanúsítványainkat](/glossary/#attestation). Ez azt jelenti, hogy nem tudjuk irányítani az azonosítással kapcsolatos információinkat, és nem dönthetünk arról, hogy ki férhet hozzá a személyazonosító információinkhoz (PII), valamint hogy ezek a felek milyen mértékű hozzáférést kapnak. - -Ezen problémák megoldására decentralizált azonosítási rendszerek állnak rendelkezésre, amelyeket nyilvános blokkláncokon, például az Ethereumon, építettek. A decentralizált azonosítás lehetővé teszi az egyének számára, hogy kezeljék az azonosítással kapcsolatos információikat. A decentralizált azonosítási megoldásokkal _Ön is_ létrehozhat azonosítókat, illetve anélkül igényelhet és tárolhat tanúsítványokat, hogy központi hatóságokra, mint például szolgáltatók vagy kormányok, támaszkodna. - -## Mi az az identitás? {#what-is-identity} - -Az identitás az egyén önmagához való viszonyának értelmezése, egyedi jellemzők által meghatározva. Az identitás az _egyént_ jelenti, azaz egy különálló emberi entitást. Jelenthet még nem emberi entitást is, mint például egy szervezetet vagy hatóságot is. - - - -## Mik az azonosítók? {#what-are-identifiers} - -Az azonosító egy olyan információ, mely sajátos identitásra vagy identitásokra mutat rá. A hétköznapi azonosítók többek között: - -- Név -- Társadalombiztosítási szám / adószám -- Mobilszám -- Születési idő és hely -- Digitális azonosítók, mint e-mail-cím, felhasználói név, avatár - -Ezeket a hagyományos azonosítókat központi hatóságok bocsátják ki, tárolják és kontrollálják. Engedélyre van szükség a kormánytól ahhoz, hogy valaki megváltoztassa a nevét, vagy a közösségi média platformtól arra, hogy megváltoztassa a profilját. - -## A decentralizált identitás előnyei {#benefits-of-decentralized-identity} - -1. A decentralizált identitás növeli az egyénnek a saját azonosítói feletti kontrollját. A decentralizált azonosítók és tanúsítások anélkül igazolhatók, hogy egy központi hatóságra vagy egy harmadik fél által nyújtott szolgáltatásra kellene támaszkodni. - -2. A decentralizáltidentitás-megoldások úgy képesek igazolni és kezelni egy felhasználó identitását, hogy nem kell megbízni egy másik félben, zökkenőmentes és védi a magán jellegű információkat. - -3. A decentralizált identitás a blokklánc-technológiát felhasználva teremt bizalmat a különböző felek között és a tanúsítások érvényességét igazolva nyújt kriptográfiai garanciát. - -4. A decentralizált identitás átvihetővé, hordozhatóvá teszi a identitáshoz kapcsolódó adatokat. A felhasználók a mobil tárcájukban tárolják a tanúsításokat és azonosítókat, és eldönthetik, hogy kivel osztják meg azokat. A decentralizált azonosítók és tanúsítások nem az azokat kibocsátó szervezet adatbázisába vannak zárva. - -5. A decentralizált identitás jól illeszkedik a most kialakuló [nulla tudású (zero-knowledge)](/glossary/#zk-proof) technológiákhoz, mellyel az egyének anélkül tudják igazolni tulajdonukat vagy eredményeiket, hogy feltárnák, mi is az pontosan. Ez egy hatásos módja annak, hogy a bizalmat és a magán jelleget kombinálják olyan felhasználási módoknál, mint amilyen például a szavazás. - -6. A decentralizált identitás lehetővé teszi az [anti-Sybil](/glossary/#anti-sybil) mechanizmust, feltárva azt, amikor egyetlen ember több személynek adja ki magát egy adott játékban vagy azért, hogy teleszemetelje (spam) a rendszert. - -## A decentralizált identitás alkalmazásai {#decentralized-identity-use-cases} - -A decentralizált identitás számtalan esetben alkalmazható: - -### 1. Univerzális bejelentkezés (login) {#universal-dapp-logins} - -A decentralizált identitás segíthet, hogy a jelszóalapú bejelentkezésk helyett decentralizált hitelesítés legyen. A szolgáltatók tanúsításokat bocsáthatnak ki a felhasználóknak, amelyet az Ethereum-tárcájukban tárolnak. Például egy olyan tanúsítvány, ami egy [NFT](/glossary/#nft), és hozzáférést biztosít egy online közösséghez. - -Az [Ethereumba való bejelentkezés](https://login.xyz/) funkció ekkor lehető tenné a szervereknek, hogy megerősítsék a felhasználó Ethereum-számláját és lekérdezzék az ehhez szükséges tanúsításokat a számlacímükről. Ezáltal a felhasználónak nem kell hosszú jelszavakat megjegyeznie ahhoz, hogy különböző platformokat és weboldalakat érjen el, és így jobb felhasználói élményben lehet része. - -### 2. Ügyfél-azonosítás (KYC) {#kyc-authentication} - -Az online szolgáltatások használatakor a felhasználóknak tanúsításokat és hitelesítő adatokat kell megadniuk, mint például vezetői engedély vagy útlevél. Ez azonban aggodalomra adhat okot, mivel a magánjellegű információkkal visszaélhetnek, a szolgáltatók pedig nem tudják ellenőrizni a tanúsítások hitelességét. - -A decentralizált identitás révén a cégek elhagyhatják a hagyományos [ügyfél-azonosítást (KYC)](https://en.wikipedia.org/wiki/Know_your_customer), és ehelyett az ügyfelek identitását az igazolható bizonyítványok (VC) révén ellenőrizhetik. Ez csökkenti az azonosítások kezelésének költségét, és kivédi a hamis iratok használatát is. - -### 3. Szavazás és online közösségek {#voting-and-online-communities} - -Az online szavazás és a közösségi média két új alkalmazási területe a decentralizált identitásnak. Az online szavazások ki vannak téve a manipulációnak, főleg ha a rosszindulatú szereplők hamis identitásokat hoznak létre, hogy azokkal szavazzanak. A szavazás folyamatának integritását nagy mértékben növelné, ha az egyének a láncon belüli tanúsításokkal igazolnák magukat. - -A decentralizált identitás segít olyan online közösségek létrehozásában, melyek mentesek a hamis profiloktól. Például minden felhasználónak igazolnia kell a kilétét egy láncon belüli azonosítási rendszerrel, mint amilyen az Ethereum Névszolgáltatás (ENS), és így kizárhatók a nem emberi résztvevők (bot). - -### 4. Anti-Sybil védelem {#sybil-protection} - -A támogatást adó alkalmazások, melyek [kvadratikus szavazást](/glossary/#quadratic-voting) használnak, sebezhetők a [Sybil-támadásokkal](/glossary/#sybil-attack) szemben, mert a támogatás összege növekszik, ha több szavazat érkezik rá. Ez pedig arra ösztönzi a résztvevőket, hogy több identitással vegyenek részt a folyamatban. A decentralizált identitás megakadályozza ezt, mivel a résztvevők könnyedén igazolhatják, hogy valódi emberek, és nem kell hozzá specifikus, magán jellegű információkat feltárniuk magukról. - -## Mi az a tanúsítás? {#what-are-attestations} - -A tanúsítás egy olyan állítás, melyet az egyik entitás ad a másikról. Az Amerikai Egyesült Államokban a vezetői engedélyt a Gépjárművekkel foglalkozó hivatal (egyik entitás) bocsátja ki, mellyel tanúsítja, hogy az illető személy (másik entitás) autót vezethet. - -A tanúsítás nem azonos az azonosítókkal. A tanúsításhoz _szükség van_ azonosítókra, hogy egy sajátos identitásra hivatkozzanak, és az ehhez tartozó valamilyen jellemzőről adjanak egy állítást. Tehát a jogosítvány tartalmaz azonosítókat (név, születési idő, cím), ugyanakkor tanúsítja az autóvezetési jogosultságot. - -### Mik azok a decentralizált azonosítók? {#what-are-decentralized-identifiers} - -A hagyományos azonosítók, mint a hivatalos név vagy e-mail-cím, harmadik személyen múlnak – a kormányokon és az e-mail-szolgáltatókon. A decentralizált azonosítók (DID) különböznek ezektől – ezeket nem egy központi hatóság állítja ki, kezeli vagy kontrollálja. - -A decentralizált azonosítókat az egyének állítják ki, kezelik és kontrollálják. Az [Ethereum-számla](/glossary/#account) is egy decentralizált azonosító. A felhasználó annyi számlát hozhat létre, amennyit csak akar, anélkül hogy bárki engedélyére szükség lenne vagy egy központ nyilvántartásban kellene tárolni azokat. - -A decentralizált azonosítókat elosztott főkönyveken ([blokklánc](/glossary/#blockchain)) vagy [peer-to-peer hálózatokon](/glossary/#peer-to-peer-network) tárolják. Ennek okán a DID-ekre az jellemző, hogy [globálisan egyediek, sokrétűen felhasználhatók és kriptográfiával ellenőrizhetők](https://w3c-ccg.github.io/did-primer/). A decentralizált azonosító különféle entitásokhoz kapcsolódhat, mint emberek, szervezetek vagy kormányzati szervek. - -## Mi teszi lehetővé a decentralizált azonosítók használatát? {#what-makes-decentralized-identifiers-possible} - -### 1. Nyilvánoskulcs-kriptográfia {#public-key-cryptography} - -A nyilvánoskulcs-kriptográfia egy olyan információbiztonsági lépés, amely az entitás számára egy [nyilvános kulcsot](/glossary/#public-key) és egy [privát kulcsot](/glossary/#private-key) hoz létre. A nyilvános kulcson alapuló [kriptográfiát](/glossary/#cryptography) a blokklánchálózatok arra használják, hogy igazolják a felhasználók identitását és a digitális eszközök tulajdonjogát. - -Néhány decentralizált azonosító, mint amilyen az Ethereum-számla, egyaránt rendelkezik nyilvános és privát kulccsal. A nyilvános kulcs meghatározza a számla birtokosát, miközben a privát kulcs aláírhatja az adott számlához tartozó üzeneteket, illetve feloldhatja azok titkosítását. A nyilvánoskulcs-kriptográfia igazolja az entitások identitását, megakadályozza, hogy valaki más felöltse azt vagy hamisat használjon – mindezt a [kriptográfiai aláírás](https://andersbrownworth.com/blockchain/public-private-keys/) révén, amely minden állítást igazol. - -### 2. Decentralizált adattárolók {#decentralized-datastores} - -A blokklánc egy igazolható adatnyilvántartásként működik: az információk nyilvános, decentralizált tárhelye, melynek használatakor nem kell megbízni egy központi szereplő (jóhiszemű) magatartásában. A nyilvános blokkláncok létezése miatt nincs többé szükség arra, hogy az azonosítókat központi nyilvántartásokban tárolják. - -Ha valaki szeretné egy decentralizált azonosító érvényességét ellenőrizni, akkor a blokkláncon megkeresheti a hozzá tartozó nyilvános kulcsot. Ez különbözik a hagyományos azonosítóktól, ahol harmadik entitás tudja csak igazolni azt. - -## A decentralizált azonosítók és a tanúsítás hogyan teszi lehetővé a decentralizált identitást? {#how-decentralized-identifiers-and-attestations-enable-decentralized-identity} - -A decentralizált identitás az az elképzelés, hogy az identitáshoz kapcsolódó információkat mindenki maga kontrollálja, azok privátak és hordozhatók, átvihetők, melynek az elsődleges építőkövei a decentralizált azonosítók és a tanúsítások. - -A decentralizált identitás kontextusában a tanúsítások (más néven [Igazolható bizonyítványok vagy hitelesítő adatok / VC](https://www.w3.org/TR/vc-data-model/)) olyan hamisításmentes, kriptográfiailag igazolható állítások, melyeket a kibocsátó készít. Minden tanúsítás vagy igazolható bizonyítvány, amit egy entitás (például egy szervezet) kiállít, az kapcsolódik az ő decentralizált azonosítójukhoz (DID). - -Mivel a DID-ek a blokkláncon vannak tárolva, ezért bárki ellenőrizni tudja a tanúsítás érvényességét azáltal, hogy megnézi az Ethereumon a kiállító DID-jét. Lényegében az Ethereum-blokklánc olyan, mint egy globális könyvtár, ahol az adott entitásokhoz kapcsolódó decentralizált azonosítókat igazolni lehet. - -A decentralizált azonosítók teszik lehetővé, hogy a tanúsításokat a kiállító maga kontrollálja és azok igazolhatók legyenek. Ha a kiállító már nem is létezik, a tanúsítást kapó entitás mindig rendelkezik annak eredetének és érvényességének bizonyítékával. - -A decentralizált azonosítók elengedhetetlenek abban is, hogy megvédjék a személyes adatok magán jellegét a decentralizált identitás révén. Például, ha egy egyén beadja egy tanúsítás bizonyítékát (egy vezetői engedélyt), akkor az azt igazoló félnek nem kell ellenőrizni a bizonyítékban található adatok érvényességét. Ehelyett az ellenőrző félnek csak a tanúsítás eredetiségének kriptográfiai garanciáira, valamint a kiállító szervezet identitására van szükség ahhoz, hogy a bizonyíték érvényességét megállapítsa. - -## A tanúsítások típusai a decentralizált identitás esetében {#types-of-attestations-in-decentralized-identity} - -A tanúsítások tárolása és visszakeresése az Ethereumon alapuló, identitáshoz kötődő ökoszisztémában eltérően működik, mint a hagyományos identitáskezelés. Különféle megközelítések léteznek, hogyan állítják ki, tárolják és igazolják a tanúsításokat a decentralizált identitást biztosító rendszerekben: - -### Blokkláncon kívüli tanúsítások {#off-chain-attestations} - -A blokkláncon való tanúsítástárolással kapcsolatban felmerül az a konszern, hogy olyan információkat tartalmazhat, melyeket az egyének privát módon szeretnének kezelni. Az ilyen tanúsítások tárolása az Ethereum-blokkláncon, annak nyilvános természete miatt nem előnyös. - -Erre az a megoldás, hogy a kiállított tanúsításokat a felhasználók láncon kívül tartják digitális tárcákban, de azok alá vannak írva a kiállító decentralizált azonosítójával (DID), mely a láncon belül elérhető. Ezeket a tanúsításokat [JSON Web Tokenként](https://en.wikipedia.org/wiki/JSON_Web_Token) kódolják, és tartalmazzák a kiállító digitális aláírását – így a láncon kívüli azonosítási igényeket könnyedén igazolni tudja. - -A következő példa elmagyarázza a láncon kívüli tanúsításokat: - -1. Egy egyetem (kiállító) létrehoz egy tanúsítást (egy digitális egyetemi diplomát), aláírja azt a kulcsaival, és átadja Bobnak (az identitás tulajdonosának). - -2. Bob egy állásra jelentkezik és igazolni akarja iskolai tanulmányait a munkaadónak, ezért megosztja vele a tanúsítást a mobil tárcájából. A vállalat (ellenőrző) ekkor megbizonyosodhat a tanúsítás érvényességéről azáltal, hogy megnézi a kiállító DID-jét (pl. az Ethereumon lévő nyilvános kulcsát). - -### Blokkláncon kívüli tanúsítások állandó eléréssel {#offchain-attestations-with-persistent-access} - -Ebben az elrendezésben a tanúsításokat átalakítják JSON file-okká és a láncon kívül tárolják (ideálisan egy [decentralizált felhőben](/developers/docs/storage/), mint a IPFS vagy a Swarm). Azonban a JSON-fájl [hash-kódja](/glossary/#hash) a láncon van eltárolva és egy DID-hez kapcsolódik egy láncon belüli nyilvántartáson keresztül. A kapcsolódó DID lehet a tanúsítás kiállítójáé vagy azé, aki azt kapta. - -Ez a megközelítés lehetővé teszi, hogy a tanúsítások állandóan elérhetők legyenek a blokkláncon, miközben a kapcsolódó információk titkosítottak és igazolhatók. Mivel a privát kulcs tulajdonosa titkosítani tudja az információt, ezért képes szelektív módon nyilvánossá tenni azt. - -### Blokkláncon belüli tanúsítások {#onchain-attestations} - -A blokkláncon belüli tanúsítások [okosszerződésekben](/glossary/#smart-contract) vannak tárolva az Ethereum-blokkláncon. Az okosszerződés (ami nyilvántartásként működik) hozzáköti a tanúsítást egy kapcsolódó, láncon belüli decentralizált azonosítóhoz (egy nyilvános kulcshoz). - -A következő példa bemutatja, hogyan működik a láncon belüli tanúsítás a gyakorlatban: - -1. Egy cég (XYZ vállalat) azt tervezi, hogy egy okosszerződésen keresztül tulajdonosi részvényeket ad el, de csak olyan vásárlókat fogad el, akiknek a háttere ellenőrizve lett. - -2. XYZ vállalat a háttérellenőrzéssel megbízott cégtől láncon belüli tanúsításokat kap az Ethereumon. Ez a tanúsítás igazolja, hogy az egyén megfelelt az ellenőrzés során, de nem tárja fel semmilyen személyes adatát. - -3. A részvényeket eladó okosszerződés meg tudja nézni az átvilágított vevőkre vonatkozó nyilvántartási szerződést, így meghatározhatja, hogy kik vásárolhatnak részvényt. - -### Egyénhez kötött tokenek és identitás {#soulbound} - -Az [egyénhez kötött tokeneket](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) ([nem átadható NFT-k](/glossary/#nft)) arra lehet használni, hogy egy adott tárcához tartozó egyedi információkat gyűjtsenek. Ez gyakorlatilag létrehoz egy egyedi, láncon belüli identitást, amely egy adott Ethereum-címhez kötődik, és eredményeket (mint egy online tanfolyam elvégzése vagy egy játékban elért szint) vagy közösségi részvételt jelentő tokeneket foglal magába. - -## Használjon decentralizált identitást {#use-decentralized-identity} - -Számtalan ambiciózus projekt használja az Ethereumot a decentralizált identitási megoldások alapjaként: - -- **[Ethereum Névszolgáltatás (ENS)](https://ens.domains/)** – _Egy decentralizált névadó rendszer a láncon belüli, gép által kiolvasható azonosítókra, mint amilyenek az Ethereum-tárcacímek, a tartalomra vonatkozó hash-kódok és a metaadatok._ -- **[SpruceID](https://www.spruceid.com/)** – _Egy decentralizált identitási projekt, mely lehetővé teszi, hogy a felhasználók a digitális identitásukat Ethereum-számlákkal és ENS-profilokkal kontrollálják ahelyett, hogy harmadik személyre támaszkodnának._ -- **[Ethereum tanúsítási szolgáltatás (EAS)](https://attest.sh/)** – _Egy decentralizált főkönyv/protokoll láncon belüli vagy láncon kívüli tanúsítások készítésére._ -- **[Proof of Humanity](https://www.proofofhumanity.id)** – _Az emberség igazolása (PoH) egy közösségi identitás igazolására készült rendszer, mely az Ethereumra épül._ -- **[BrightID](https://www.brightid.org/)** – _Egy decentralizált, nyílt forráskódú, közösségi identitási hálózat, amely új módot keres az azonosításra egy közösségi gráf megalkotásával és elemzésével._ -- **[walt.id](https://walt.id)** – _Nyílt forráskódú, decentralizált identitás- és tárcainfrastruktúra, amely lehetővé teszi a fejlesztőknek és szervezeteknek, hogy kihasználják a szuverén identitást, valamint az NFT-ket/SBT-ket._ -- **[Veramo](https://veramo.io/)** – _Egy JavaScript keretrendszer, amellyel bárki könnyedén tud kriptográfiailag ellenőrizhető adatot használni az alkalmazásaiban._ - -## További olvasnivaló {#further-reading} - -### Cikkek {#articles} - -- [Blokklánc esettanulmányok: blokklánc a digitális identitás területén](https://consensys.net/blockchain-use-cases/digital-identity/) — _ConsenSys_ -- [Mi az az Ethereum ERC725? Független identitáskezelés a blokkláncon](https://cryptoslate.com/what-is-erc725-self-sovereign-identity-management-on-the-blockchain/) — _Sam Town_ -- [Hogyan tudja a blokklánc megoldani a digitális identitás problémáját](https://time.com/6142810/proof-of-humanity/) — _Andrew R. Chow_ -- [Mi az a decentralizált identitás és miért érdemes figyelembe venni?](https://web3.hashnode.com/what-is-decentralized-identity) — _Emmanuel Awosika_ -- [Bevezetés a decentralizált identitás világába](https://walt.id/white-paper/digital-identity) – _Dominik Beron_ - -### Videók {#videos} - -- [Decentralizált identitás (Bonus Livestream Session)](https://www.youtube.com/watch?v=ySHNB1za_SE&t=539s) — _Kiváló magyarázó videó a decentralizált identitásról Andreas Antonopoloustól_ -- [Az Ethereumba való bejelentkezés és a decentralizált identitás témája a Ceramic, IDX, React és 3ID Connect használatával](https://www.youtube.com/watch?v=t9gWZYJxk7c) — _YouTube útmutató a személyazonosítási rendszer kiépítéséről, mely az Ethereum-tárca alapján létrehozza, kiolvassa és frissíti a felhasználó profilját – Nader Dabit_ -- [BrightID – Decentralizált identitás az Ethereumon](https://www.youtube.com/watch?v=D3DbMFYGRoM) — _Bankless podcast epizód a BrightID-ról, ami egy decentralizált identitási megoldás az Ethereumon_ -- [A láncon kívüli internet: decentralizált identitás és igazolható bizonyítványok (VC)](https://www.youtube.com/watch?v=EZ_Bb6j87mg) — EthDenver 2022 Evin McMullen prezentációja -- [A hitelesítő adatok bemutatása](https://www.youtube.com/watch?v=ce1IdSr-Kig) – YouTube magyarázó videó példával Tamino Baumanntól - -### Közösségek {#communities} - -- [ERC-725 szövetség a GitHubon](https://github.com/erc725alliance) — _Az ERC725 szabvány támogatói, mely az Ethereum-blokkláncon való identitáskezelést célozza_ -- [SpruceID Discord-szerver](https://discord.com/invite/Sf9tSFzrnt) — _Rajongók és fejlesztők közössége, akik az Ethereumba való bejelentkezés funkcióján dolgoznak_ -- [Veramo Labs](https://discord.gg/sYBUXpACh4) — _Fejlesztői közösség, melynek célja az alkalmazásokhoz szükséges igazolható adatok keretrendszerének kidolgozása_ -- [walt.id](https://discord.com/invite/AW8AgqJthZ) – _Fejlesztők és építők közössége, akik a decentralizált identitás számtalan iparágban való felhasználási területeivel foglalkoznak_ diff --git a/public/content/translations/hu/08) Use cases 2/desci/index.md b/public/content/translations/hu/08) Use cases 2/desci/index.md deleted file mode 100644 index 026acb08c2a..00000000000 --- a/public/content/translations/hu/08) Use cases 2/desci/index.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -title: Nem központosított kutatás (DeSci) -description: A decentralizált tudomány áttekintése az Ethereumon -lang: hu -template: use-cases -emoji: ":microscope:" -sidebarDepth: 2 -image: /images/future_transparent.png -alt: "" -summaryPoint1: Egy globális és nyitott alternatívája a jelenlegi tudományos rendszernek. -summaryPoint2: Olyan technológia, mely lehetővé teszi a tudósok számára, hogy finanszírozási alapot gyűjtsenek, kísérleteket végezzenek, megosszák az adatokat, kommunikálják elképzeléseiket stb. -summaryPoint3: A nyitott tudomány mozgalomra épül. ---- - -## Mi az a decentralizált tudomány (DeSci)? {#what-is-desci} - -A decentralizált tudomány (DeSci) egy olyan mozgalom, melynek célja a nyilvános infrastruktúra létrehozása a tudományos eredmények korrekt és egyenlő finanszírozása, létrehozása, véleményezése, hitelesítése, tárolása és terjesztése érdekében a [web3](/glossary/#web3)-technológiára alapozva. - -A DeSci egy olyan ökoszisztémát akar megalkotni, ahol a tudósok ösztönözve vannak a kutatásaik nyilvános megosztására, munkájukért javadalmazásban részesülnek, miközben megengedik, hogy bárki könnyedén elérje és hozzájáruljon a kutatásukhoz. A DeSci azt az elképzelést váltja valósággá, hogy a tudományos ismeretek mindenkinek elérhetők, a tudományos kutatások pedig transzparensek legyenek. A DeSci egy decentralizáltabb és jobban elosztott tudományos kutatási modellt hoz létre, mely ellenállóbb a cenzúrával és a központi hatóságok irányításával szemben. A DeSci reményeink szerint egy olyan környezetet teremt, ahol az új és szokatlan elképzelések virágozni fognak azáltal, hogy a finanszírozáshoz, a tudományos eszközökhöz és a kommunikációs csatornákhoz való hozzáférést decentralizáljuk. - -A decentralizált tudomány sokrétűbb finanszírozási forrásokat (a [DAO-októl](/glossary/#dao) kezdve, [a kvadratikus adományozáson](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531) keresztül a közösség általi finanszírozásig és még tovább), sokkal elérhetőbb adatokat és módszereket tesz lehetővé, miközben ösztönzi a reprodukálhatóságot is. - -### Juan Benet – A DeSci mozgalom - - - -## Hogyan fejleszti a DeSci a tudományt {#desci-improves-science} - -Következzen egy hozzávetőleges felsorolás a tudomány területén tapasztalt fő problémákról, és arról, hogy a decentralizált tudomány hogyan segíthet ezeken - -| **Decentralizált tudomány** | **Hagyományos tudomány** | -| ------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -| A finanszírozási alapok elosztását a **nyilvánosság határozza meg** olyan módszerek alapján, mint a kvadratikus adományozás vagy a DAO-k. | Kicsi, zárt, **központosított csoportok** irányítják a finanszírozási források elosztását. | -| A tudósok dinamikus csapatokat alkotnak társaikkal, akik a **világ bármelyik pontján** lehetnek. | A finanszírozási alapok és a helyi intézmények **behatárolják** a kollaborációt. | -| A finanszírozási döntések online történnek és **transzparensek**. Új finanszírozási mechanizmusokat térképeznek fel. | A finanszírozási döntéseket hosszú átfutási idővel hozzák meg és **korlátolt transzparencia** jellemzi azokat. Kevés finanszírozási mechanizmus létezik. | -| A megosztott laboratóriumi szolgáltatások könnyebbek és átláthatóbbak a [web3](/glossary/#web3)-technológia révén. | A megosztott laboratóriumi erőforrások gyakran **lassúak és kevéssé átláthatók**. | -| A **publikálás új modelljei** alakíthatók ki, amelyek a web3-alapokat használják a bizalom, átláthatóság és univerzális hozzáférés biztosítására. | Ön a meglévő publikációs utakat használja, melyekről gyakran mondják, hogy **nem hatékonyak, elfogultak és kizsákmányolók**. | -| **Tokeneket és reputációt lehet szerezni a tudományos eredmények szakértői értékeléséért**. | A **szakértői értékelést nem fizetik meg**, csak a profitorientált kiadók javát szolgálja. | -| **A tudós birtokolja a szellemi tulajdont (IP)**, melyet ő hoz létre és transzparens feltételek szerint osztja meg azt. | **Az intézmény birtokolja a szellemi tulajdont**, amit a tudós létrehoz. Az ahhoz való hozzáférés nem egyértelmű. | -| **A kutatás teljes egészét megosztják**, beleértve a sikertelen erőfeszítések adatait is, mivel minden lépés a blokkláncon található. | **A publikációk részrehajlók**, mivel a kutatók nagyobb valószínűséggel osztják meg a sikeres eredményeket hozó kísérleteket. | - -## Az Ethereum és a DeSci {#ethereum-and-desci} - -A decentralizált tudományt kiszolgáló rendszer robosztus biztonságot, minimális pénzügyi és tranzakciós költséget, és az alkalmazásfejlesztést támogató gazdag ökoszisztémát igényel. Az Ethereum mindent megad ahhoz, hogy kialakuljon a decentralizált tudomány technológiája. - -## A DeSci alkalmazási területei {#use-cases} - -A DeSci egy olyan tudományos eszköztárat épít, amely be tudja vezetni a tradicionális akadémikus világát a digitális világba. Következzen néhány alkalmazási terület, amit a web3 ajánl a tudományos közösségnek. - -### Publikálás {#publishing} - -A tudományos publikálás közismerten problémás, mivel olyan kiadókon alapszik, amelyek a tudósok, szakértők és szerkesztők nem megfizetett munkájára építenek, hogy megszülessen a kézirat, utána pedig elképesztő kiadási díjakat számolnak fel érte. A nyilvánosság, aki általában közvetett módon fizet ezért a munkáért és a kiadási költségeiért az adózáson keresztül, sokszor nem éri el ugyanezt a munkát, csak ha a kiadónak újra fizet érte. Az egyéni tudományos munkák megjelentetésének teljes költsége sokszor öt számjegyű összeg (USD-ben kifejezve), amely aláássa a tudományos ismeret alapvető eszméjét, mint [közjó](/glossary/#public-goods), miközben hatalmas profitot generál a kiadók kis csoportjának. - -Ingyenes és nyílt hozzáférésű platformok állnak rendelkezésre pre-print szerverek (online könyvtárak) formájában, [mint amilyen az ArXiv is](https://arxiv.org/). Ugyanakkor ezek a platformok nem üzemeltetnek minőségi ellenőrzést, [anti-sybil mechanizmust](/glossary/#anti-sybil), és nem trekkelik a cikkszintű mérőszámokat, tehát csak valamilyen formában nyilvánosságra hozzák azt, amit utána átadnak a hagyományos kiadóknak. A SciHub a kiadott munkákat ingyen elérhetővé teszi, ugyanakkor nem legális módon, és csak azután, hogy a kiadók megkapták érte a fizetségüket és az adott munkát szigorú szerzői jogi szabályozásba csomagolják. Ez egy kritikus hiányosság az elérhető tudományos munkák és adatok terén, melyet egy beágyazott törvényességi mechanizmus és ösztönzési modell támaszt alá. Az ilyen rendszer megépítéséhez szükséges eszközök elérhetők a web3-ban. - -### Megismételhetőség és újbóli előállíthatóság {#reproducibility-and-replicability} - -A megismételhetőség és újbóli előállíthatóság a minőségi tudományos felfedezések alapkövei. - -- A megismételhető eredmények lényege, hogy egymás után többször elérhető ugyanaz az eredmény adott csapat által, adott módszertant használva. -- Az újbóli előállíthatóság lényege, hogy egy másik csapat is azonos eredményre jut ugyanazokat a kísérleti tényezőket használva. - -Az új web3 saját eszközei biztosítani tudják, hogy a megismételhetőség és újbóli előállíthatóság a felfedezés alapjaiként szolgálnak. Beleszőhetjük a minőségi tudományt az akadémikus világ technológiai szövetébe. A web3 képes minden egyes elemzési komponens esetében [tanúsítást](/glossary/#attestation) kreálni: a nyers adat, a számítási motor és az alkalmazás eredményei esetében. A konszenzuson alapuló rendszerek szépsége az, hogy amikor egy megbízható hálózat (trusted network) tartalmazza ezeket az összetevőket, akkor a hálózat minden egyes tagja felelős lehet azért, hogy újból előállítsa a számítást és validálja az eredményeket. - -### Finanszírozás {#funding} - -A jelenlegi elterjedt modell a tudományos tevékenységek finanszírozására az, hogy a tudósok egyénileg vagy csoportban írásos jelentkezést adnak be egy finanszírozással foglalkozó ügynökségnek. A megbízottak egy kis bizottsága pontozza a jelentkezéseket és interjút folytat a jelentkezőkkel, mielőtt finanszírozást biztosítana a jelentkezők egy kis részének. Amellett, hogy ez az eljárás szűk keresztmetszetet hoz létre, hiszen néha **évekig is várni kell** a jelentkezés és a támogatás elnyerése között, a módszer nagy mértékben **sebezhető a részrehajlás, az önérdek és a bizottság politikai beállítottsága miatt**. - -Az elemzések kimutatták, hogy ezek a bizottságok kvázi alkalmatlanok arra, hogy kiválasszák a jó minőségű jelentkezéseket, mivel ugyanazt a jelentkezést más-más bizottságok teljesen másképpen ítélik meg. Mivel a finanszírozási keretek szűkösek, ezért a tudományos tevékenység az idősebb kutatók kis csoportjára szűkül le, akik konzervatívabb projekteken dolgoznak. Ennek következtében egy szélsőségesen versenyző finanszírozási helyzet alakult ki, mely torz ösztönzésekkel és fullasztó innovációkkal jár. - -A web3 képes arra, hogy megbontsa ezt a megtört, torz finanszírozási modellt azáltal, hogy különféle ösztönzési módszereket tud alkalmazni, melyeket a DAO-k és a web3 résztvevők már széles körben alkalmaznak. [Retroaktív közjavak finanszírozása](https://medium.com/ethereum-optimism/retroactive-public-goods-funding-33c9b7d00f0c), [kvadratikus finanszírozás](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=2003531), [DAO-irányítás](https://www.antler.co/blog/daos-and-web3-governance-the-promise-implications-and-challenges-ahead) és [tokenizált ösztönző struktúrák](https://cdixon.org/2017/05/27/crypto-tokens-a-breakthrough-in-open-network-design) – néhány olyan Web3-eszköz, amely forradalmasíthatja a tudomány finanszírozását. - -### A szellemi tulajdon (IP) birtoklása és fejlesztése {#ip-ownership} - -A szellemi tulajdon (IP) nagy probléma a hagyományos tudomány területén: onnantól kezdve, hogy az beragad az egyetemekre vagy nem használják a biotechnológiai tevékenységben, odáig, hogy hírhedten nehéz meghatározni annak értékét. Ugyanakkor a digitális eszközök tulajdonlására (mint amilyenek a tudományos adatok vagy cikkek) a web3 rendkívül jól használja a [nem helyettesíthető tokeneket (NFT)](/glossary/#nft). - -Ugyanazon a módon, ahogy az NFT-k képesek a jövőbeli tranzakciók után is fizetni az eredeti alkotónak, lehetséges transzparens értékteremtő láncokat meghatározni arra, hogy a kutatókat, az irányító szerveket (mint a DAO) vagy akár a kutatási adatokat biztosító személyeket díjazzák. - -[Az IP-NFT-k](https://medium.com/molecule-blog/ip-nfts-for-researchers-a-new-biomedical-funding-paradigm-91312d8d92e6) arra is használhatók, hogy a kutatási kísérletek decentralizált adattárháza jöjjön létre, és bekerüljön az NFT- és [DeFi](/glossary/#defi)-alapú finanszírozásba (a töredékes forrásoktól a kölcsönalapok és az értékfelmérés felé mozdulva). Az eredetileg is láncon belül létező entitások, mint a DAO-k, például a [VitaDAO](https://www.vitadao.com/), végezhet kutatást közvetlenül a láncon. A nem átadható, [egyénhez kötött (soulbound) tokenek](https://vitalik.eth.limo/general/2022/01/26/soulbound.html) kifejlődése szintén fontos lehet a DeSci számára, hogy a decentralizált tudomány résztvevői az Ethereum-címükhöz kapcsoltan bizonyítani tudják munkásságukat és hitelesítő adataikat. - -### Adattárolás, adatelérés és architektúra {#data-storage} - -A tudományos adatok sokkal hozzáférhetőbbek a web3-sémák használatával, a megosztott tárolás révén pedig a kutatások nem tudnak megsemmisülni a különféle kataklizmaesemények esetén. - -A kiindulópont egy olyan rendszer, melyet bármelyik decentralizált identitás elér, aki a szükséges igazolható bizonyítványokkal (VC) rendelkezik. Ennek következtében az bizalmas adatokat biztonságos módon tudják a megbízott felek replikálni, ellenállóbbak a duplikációval és a cenzúrával szemben, lehetséges az eredmények újbóli előállítása, ráadásul több résztvevő is kollaborálhat és új adatokat adhat a meglévőkhöz. A bizalmas adatokat kezelő számítástechnikai módszerek, mint a [compute-to-data](https://7wdata.be/predictive-analytics/compute-to-data-using-blockchain-to-decentralize-data-science-and-ai-with-the-ocean-protocol), alternatív hozzáférési lehetőséget biztosítanak a nyers adatok replikálására, illetve megbízható kutatási környezetet (TRE) alakítanak ki a legbizalmasabb adatok számára. A megbízható kutatási környezetekre (TRE) [az Országos Egészségügyi Szolgálat (NHS)](https://medium.com/weavechain/whats-in-store-for-the-future-of-healthcare-data-b6398745fbbb) úgy hivatkozik, mint az adatok titkosságát figyelembe vevő és együttműködést támogató, innovatív megoldás, mivel egy olyan ökoszisztémát hoz létre, ahol a kutatók biztonságos módon dolgozhatnak az adatokkal helyben, és közben megoszthatják a programkódjaikat és gyakorlataikat. - -A rugalmas web3-adatkezelési megoldások támogatják ezeket a szcenáriókat, és egy valóban nyitott és nyilvános tudomány alapjait biztosítják, ahol a kutatók közjót hoznak létre, és nem kell hozzáférési engedélyeket vagy díjakat fizetniük. A web3 nyilvános adatmegoldásai, mint a IPFS, Arweave és Filecoin a decentralizációra vannak optimalizálva. A dClimate például univerzális hozzáférést biztosít a klíma- és időjárási adatokhoz, beleértve az időjárási állomásokat és a klíma-előrejelző modelleket. - -## Kapcsolódjon be {#get-involved} - -Fedezze fel a projekteket és csatlakozzon a DeSci közösségéhez. - -- [DeSci.Global: globális események és találkozók](https://desci.global) -- [Blockchain for Science Telegram](https://t.me/BlockchainForScience) -- [Molecule: Finanszírozás biztosítása és elnyerése a kutatási projektjére](https://www.molecule.xyz/) -- [VitaDAO: hosszútávú kutatások finanszírozása a szponzorált kutatási megállapodások alapján](https://www.vitadao.com/) -- [ResearchHub: tudományos eredmények publikálása és azok megvitatása munkatársaival](https://www.researchhub.com/) -- [LabDAO: fehérjék számítógépes szimulációja](https://alphafodl.vercel.app/) -- [dClimate API: keresés a decentralizált közösség által gyűjtött klímaadatokban](https://api.dclimate.net/) -- [DeSci Foundation: DeSci publikációs eszközfejlesztés](https://descifoundation.org/) -- [DeSci.World: itt minden megtudható a decentralizált tudományról](https://desci.world) -- [OceanDAO: az adattal kapcsolatos tudományok DAO által irányított finanszírozása](https://oceanprotocol.com/) -- [Opscientia: nyílt, decentralizált, tudományos munkafolyamatok](https://opsci.io/research/) -- [Bio.xyz: finanszírozás szerzése a biotechnológiai DAO-jához vagy decentralizált tudományos projektjéhez](https://www.bio.xyz/) -- [Fleming Protocol: nyílt forráskódú adatgazdaság, amely fűti a kollaboratív orvosbiológiai felfedezéseket](http://flemingprotocol.io/) -- [Active Inference Institute](https://www.activeinference.org/) -- [IdeaMarkets: decentralizált tudomány hitelességének támogatása](https://ideamarket.io/) -- [DeSci Labs](https://www.desci.com/) -- [ValleyDAO: egy nyitott, globális közösség, mely pénzügyi forrásokat és fordítási támogatást kínál a szintetikus biológiai kutatáshoz](https://www.valleydao.bio) -- [Cerebrum DAO: pénzügyi támogatást és gondoskodást kínál olyan megoldásoknak, melyek fejlesztik az agyi egészséget és megakadályozzák az idegsorvadást](https://www.cerebrumdao.com/) -- [CryoDAO: támogatást adnak a mélyhűtés területén működő innovatív kutatásoknak](https://www.cryodao.org) - -Örömmel vesszük, ha bárki új projektet javasol – kérjük, tekintsék meg a [listázási szabályzatot](/contributing/adding-desci-projects/)! - -## További olvasnivaló {#further-reading} - -- [DeSci Wiki Jocelynn Pearl és UltraRare által](https://docs.google.com/document/d/1aQC6zn-eXflSmpts0XGE7CawbUEHwnL6o-OFXO52PTc/edit#) -- [Útmutató a decentralizált biotechnológiához – Jocelynn Pearl (a16z future)](https://future.a16z.com/a-guide-to-decentralized-biotech/) -- [A DeSci ügye](https://gitcoin.co/blog/desci-the-case-for-decentralised-science/) -- [Útmutató a DeSci-hez](https://future.com/what-is-decentralized-science-aka-desci/) -- [A decentralizált tudomány forrásai](https://www.vincentweisser.com/decentralized-science) -- [Molecule Biopharma IP-NFT-k – technikai leírás](https://www.molecule.xyz/blog/molecules-biopharma-ip-nfts-a-technical-description) -- [Bizalom nélküli rendszer építése a tudomány számára – Jon Starr](https://medium.com/@jringo/building-systems-of-trustless-science-1cd2d072f673) -- [Paul Kohlhaas – DeSci: a decentralizált tudomány jövője (podcast)](https://anchor.fm/andrew-steinwold/episodes/Paul-Kohlhaas---DeSci-The-Future-of-Decentralized-Science---Zima-Red-ep-117-e1h683a) -- [Active Inference Ontology a decentralizált tudomány számára (a Situated Sensemaking-től az Epistemic Commons-ig)](https://zenodo.org/record/6320575) -- [DeSci: a kutatás jövője – Samuel Akinosho](https://lucidsamuel.medium.com/desci-the-future-of-research-b76cfc88c8ec) -- [A tudomány finanszírozása (Epilógus: a DeSci és az új kriptoalapok) – Nadia](https://nadia.xyz/science-funding) -- [A decentralizáció megbontja a gyógyszerfejlesztést](https://medium.com/id-theory/decentralisation-is-disrupting-drug-development-28b5ba5d447f) -- [Mi az a DeSci, azaz a decentralizált tudomány?](​https://usadailytimes.com/2022/09/12/what-is-desci-decentralized-science/) - -### Videók {#videos} - -- [Mi az a decentralizált tudomány?](https://www.youtube.com/watch?v=-DeMklVWNdA) -- [Beszélgetés Vitalik Buterin és a tudós Aubrey de Grey között a hosszútávú kutatás és a kripto találkozási pontjáról](https://www.youtube.com/watch?v=x9TSJK1widA) -- [A tudományos publikálás szét van szakítva. A web3 meg tudja vajon javítani?](https://www.youtube.com/watch?v=WkvzYgCvWj8) -- [Juan Benet – DeSci, független laboratóriumok és a nagy adat tudománya](https://www.youtube.com/watch?v=zkXM9H90g_E) -- [Sebastian Brunemeier – Hogyan tudja a DeSci átalakítani az orvosbiológiai kutatást és a kockázati tőkét](https://www.youtube.com/watch?v=qB4Tc3FcVbM) -- [Paige Donner - A nyitott tudomány eszközökkel való ellátása a web3 & a blokklánc révén](https://www.youtube.com/watch?v=nC-2QWQ-lgw&t=17s) diff --git a/public/content/translations/hu/08) Use cases 2/refi/index.md b/public/content/translations/hu/08) Use cases 2/refi/index.md deleted file mode 100644 index 28319b4667d..00000000000 --- a/public/content/translations/hu/08) Use cases 2/refi/index.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Regeneratív pénzügyek (ReFi) -description: A regeneratív pénzügyek (ReFi) áttekintése és jelenlegi használata. -lang: hu -template: use-cases -emoji: ":recycle:" -sidebarDepth: 2 -image: /images/future_transparent.png -alt: "" -summaryPoint1: Egy alternatív gazdasági rendszer, mely regeneratív elvekre épül -summaryPoint2: Az Ethereum kiaknázása a globális koordinációs krízisek megoldására, mint amilyen a klímaváltozás is -summaryPoint3: Az ökológiailag hasznos eszközök drasztikus skálázási lehetősége, mint amilyen az igazolt karbonkredit is ---- - -## Mik azok a regeneratív pénzügyek (ReFi)? {#what-is-refi} - -**A regeneratív pénzügyek (ReFi)** olyan [blokkláncra](/glossary/#blockchain) épülő eszközök és eszmék összessége, melyek célja a regeneratív gazdaságok kialakítása a kitermelési vagy kizsákmányolási helyett. A kizsákmányoláson alapuló rendszerek végül felélik a rendelkezésre álló erőforrásokat és összeomlanak; a regeneratív mechanizmusok nélkül nem bírnak kellő rugalmassággal. A ReFi azon a feltételezésen alapszik, hogy a pénzügyi érték létrehozását el kell választani a bolygó és a közösségek erőforrásainak nem fenntartható kizsákmányolásától. - -Ehelyett a ReFi arra törekszik, hogy regeneratív ciklusok létrehozásával környezeti, közösségi és szociális problémákat oldjon meg. Ezek a rendszerek egyszerre teremtenek értéket a résztvevőknek, valamint az ökoszisztéma és a közösségek javait szolgálják. - -A ReFi egyik alapköve a regeneratív gazdaság koncepciója, amelyet John Fullerton fogalmazott meg a Capital Institute intézettől. Az ő javaslata [nyolc egymással összefüggő elv,](https://capitalinstitute.org/8-principles-regenerative-economy/) amelyet egy rendszerszintű egészségi állapot támaszt alá: - -![A nyolc összefüggő elv](refi-regenerative-economy-diagram.png) - -A ReFi projektek ezeket az elveket valósítják meg az [okosszerződések](/glossary/#smart-contract) és [a decentralizált pénzügyek (DeFi)](/glossary/#defi) alkalmazásainak segítségével, hogy ösztönözzék a regeneratív viselkedéseket, mint amilyen a lepusztult ökoszisztémák visszaállítása, illetve a nagy léptékű együttműködés elősegítése olyan globális problémák esetén, mint a klímaváltozás és a biodiverzitás-csökkenés. - -A ReFi egyúttal átfedésben van a [decentralizált tudomány (DeSci)](/desci/) mozgalommal, mely az Ethereumot használja platformként a tudományos ismeretek finanszírozása, létrehozása, értékelése, hitelesítése, tárolása és terjesztése céljából. A DeSci eszközök hasznosak lehetnek ahhoz, hogy a regeneratív tevékenységek (faültetés, a műanyagok összegyűjtése az óceánból, lepusztult ökoszisztémák visszaállítása) bevezetését és monitorozását igazolható szabványokkal és gyakorlatokkal támasszák alá. - - - -## A karbonkreditek tokenizálása {#tokenization-of-carbon-credits} - -Az **[önkéntes karbonpiac (VCM)](https://climatefocus.com/so-what-voluntary-carbon-market-exactly/)** olyan projektek finanszírozási mechanizmusa, melyek igazolhatóan pozitív hatást gyakorolnak a szén-dioxid kibocsátásra, akár az aktuális kibocsátás csökkentésével vagy a más kibocsátott üvegházhatású gázok lekötésével. Ezek a projektek egy karbonkreditnek nevezett eszközt kapnak az igazolási eljárás után, melyet olyan egyéneknek és szervezeteknek adhatnak el, akik támogatni szeretnék a klímára ható intézkedéseket. - -Az önkéntes karbonpiac (VCM) mellett számos kormányzat által kötelezővé tett karbonpiac is létezik, hogy törvényekkel vagy szabályozásokkal egy adott joghatóságon belül (pl. ország vagy régió) bevezessenek egy olyan karbonárat, mellyel kontrollálnák a kiadott karbonkibocsátási engedélyeket. Ezek a kötelező karbonpiacok arra ösztönzik a kibocsátókat az adott joghatóságon belül, hogy csökkentsék kibocsátásukat, de a már kibocsátott üvegházhatású gázok lekötésére nincs ráhatásuk. - -Az elmúlt évtizedek fejlődése ellenére a VCM továbbra is számtalan problémával küzd: - -1. A likviditás, vagyis az elérhető pénzeszközök nagyon szétdaraboltak -2. A tranzakciók működése nem átlátható -3. Magas díjak -4. A kereskedési sebesség nagyon lassú -5. A skálázhatóság nem megoldott - -A VCM átvitele az új, blokkláncalapú **digitális karbonpiacra (DCM)** egy jó lehetőség arra, hogy továbbfejlesszük a karbonkreditek validálásának, adásvételének és felhasználásának meglévő technológiáját. A blokkláncok lehetővé teszik a nyilvánosan igazolható adatokat, hozzáférést biztosítanak a felhasználók széles körének és nagyobb likviditást tudnak adni. - -A ReFi-projektek blokklánc technológiát használnak arra, hogy a hagyományos piac problémáit enyhítsék: - -- **A likviditás néhány alapban koncentrálódik,** amelyekkel bárki szabadon kereskedhet. A nagy szervezetek és az egyéni felhasználók ugyanúgy hasznosíthatják ezeket az alapokat, és nem kell hozzá kereskedőt fogadniuk, részvételi díjat fizetniük vagy regisztrálniuk. -- **Az összes tranzakció nyilvános blokkláncokon kerül rögzítésre**. Minden egyes karbonkredit mozgása nyomon követhető onnantól kezdve, hogy a DCM-en elérhetővé válik. -- **A tranzakciósebesség szinte azonnali**. A hagyományos piacokon napokig vagy hetekig tartana nagyobb mennyiségű karbonkredit beszerzése, amit a DCM-en pillanatok alatt el lehet érni. -- **A kereskedés közvetítők nélkül zajlik**, akik nagy díjakat számolnának fel ezért. A digitális karbonkreditek jelentős költségcsökkentést jelentenek a hagyományos kreditekhez képest. -- **A DCM skálázható** és képes egyaránt kielégíteni az egyének és a multinacionális vállalatok igényeit. - -### A digitális karbonpiac (DCM) fő komponensei {#key-components-dcm} - -A DCM jelenlegi struktúrája négy fő elemből áll: - -1. Nyilvántartások, mint a [Verra](https://verra.org/project/vcs-program/registry-system/) és a [Gold Standard](https://www.goldstandard.org/), biztosítják, hogy a projektek karbonkreditjei hitelesek legyenek. Emellett üzemeltetik az adatbázist, melyben a digitális karbonkreditek létrejönnek, és ezek átadhatók és felhasználhatók. - -A blokkláncra épülő, innovatív projektek egy újabb hulláma próbálja megbontani, újraalkotni a szektor hivatalnoki funkcióit is. - -2. Karbonhidak, vagyis tokenizálók, akik a hagyományos nyilvántartásokban tárolt karbonkrediteket megjelenítik vagy áttranszferálják a DCM-re. Ismert példa többek között a [Toucan Protocol](https://toucan.earth/), a [C3](https://c3.app/) és a [Moss.Earth](https://moss.earth/). -3. Integrált szolgáltatások, melyek karbonelkerülési és/vagy -eltávolítási krediteket ajánlanak a végfelhasználóknak, így nyilvánvaló a környezetre gyakorolt jótékony hatásuk és megoszthatják a világgal azt, hogy támogatják a klímával kapcsolatos intézkedéseket. - -Néhányan, mint amilyen a [Klima Infinity](https://www.klimadao.finance/infinity) és a [Senken](https://senken.io/), a projektek széles választékát kínálják, melyeket harmadik fél készített és olyan szabványok mentén bocsátott ki, mint a Verra. Mások, mint amilyen a [Nori](https://nori.com/) is, csak specifikus projekteket fejlesztenek a saját karbonkredit-szabványuk alapján, melyet ők bocsátanak ki és saját, erre specializált piacterükön kezelik. - -4. Infrastruktúra, amely lehetővé teszi a karbonpiac teljes ellátási láncának skálázhatóságát hatás és hatékonyság szempontjából. A [KlimaDAO](http://klimadao.finance/) likviditást biztosít közjó gyanánt (bárki vehet vagy adhat karbonkreditet transzparens áron), ösztönzi a karbonpiacok tranzakcióátvitelének növekedését és a karbonkreditek felhasználását, továbbá felhasználóbarát és interoperábilis eszközrendszert biztosít, hogy a tokenizált karbonkreditek széles választékáról elérhetők legyenek az adatok, illetve beszerzi és felhasználja azokat. - -## ReFi a karbonpiacokon túl {#refi-beyond} - -Bár jelenleg nagy hangsúlyt a karbonpiacokra általánosságban, valamint a VCM transzferálásáról a DCM-re, ugyanakkor a regeneratív pénzügyek (ReFi) nem korlátozódnak erre a területre. Más környezeti eszközöket is létre lehet hozni és tokenizálni, hogy újabb negatív externáliákat is be lehessen árazni a jövő gazdasági rendszerének részeként. Emellett e gazdasági modell regeneratív aspektusát fel lehet használni más területeken is, mint a közjavak finanszírozása kvadratikus finanszírozási platformokon, amilyen a [Gitcoin](https://gitcoin.co/) is. Azok a szervezetek, melyek a nyitott részvétel és az erőforrások egyenlő elosztásának eszméjére épültek, lehetővé teszik, hogy az emberek nyílt forráskódú szoftverprojekteknek, valamint oktatási, környezeti és közösség által irányított projekteknek juttassanak pénzt. - -Azzal, hogy a tőkét átirányítják a kizsákmányoló gyakorlatokból a regeneratív kezdeményezésekbe, elindulhatnak olyan projektek és cégek, melyek szociális, környezeti és közösségi előnyöket adnak – és valószínűleg a hagyományos pénzügyi rendszerben nem jutnának pénzhez –, így gyorsan és könnyedén pozitív externáliákat hozhatnak létre a társadalom számára. A finanszírozás ezen modelljére való átállás lehetőséget ad a sokkal befogadóbb gazdasági rendszerek számára, melyekben mindenféle demográfiai jellemzővel bíró ember aktív résztvevő lehet, nem csak passzív szemlélő. A ReFi az Ethereum vízióját kínálja arra vonatkozólag, hogy miként lehet összehangoltan cselekedni a lét kihívásait illetően, mely az emberi fajt és a bolygó minden élőlényét érinti – egy új gazdasági paradigma alaprétege, mely befogadóbb és fenntarthatóbb jövőt teremt. - -## További cikkek a ReFi-ról - -- [A karbonvaluták áttekintése és helyük a gazdaságban](https://www.klimadao.finance/blog/the-vision-of-a-carbon-currency) -- [A Jövő Minisztériuma, egy regény a karbonalapú valuta szerepéről a klímaváltozás elleni harcban](https://en.wikipedia.org/wiki/The_Ministry_for_the_Future) -- [Részletes jelentés az önkéntes karbonpiacok skálázását megcélzó munkacsoporttól (TSVCM)](https://www.iif.com/Portals/1/Files/TSVCM_Report.pdf) -- [Kevin Owocki és Evan Miyazono CoinMarketCap glosszáriumbejegyzése a ReFi-ről](https://coinmarketcap.com/alexandria/glossary/regenerative-finance-refi) diff --git a/public/content/translations/hu/08) Use cases 2/social-networks/index.md b/public/content/translations/hu/08) Use cases 2/social-networks/index.md deleted file mode 100644 index 67fa29ce2f2..00000000000 --- a/public/content/translations/hu/08) Use cases 2/social-networks/index.md +++ /dev/null @@ -1,106 +0,0 @@ ---- -title: Nem központosított közösségi hálózatok -description: A decentralizált közösségi hálózatok áttekintése az Ethereumon -lang: hu -template: use-cases -emoji: ":mega:" -sidebarDepth: 2 -image: /images/ethereum-learn.png -summaryPoint1: Blokkláncalapú platformok a közösségi kapcsolódás, tartalom-létrehozás és -terjesztés céljából. -summaryPoint2: A decentralizált közösségimédia-hálózatok megvédik a felhasználók privát adatait és növelik az adatbiztonságot. -summaryPoint3: A tokenek és NFT-k új lehetősége adnak a tartalom fizetőeszközzé alakításához. ---- - -A közösségi hálózatok komoly szerepet töltenek be a napi kommunikációban és kapcsolódásban. Ugyanakkor ezen platformok centralizált irányítása számos problémát teremtett: adatlopás, szerverleállás, kizárás a platformról, cenzúra és a magán jelleg megsértése csak néhány kompromisszum, amit a közösségi média gyakran elszenved. E problémák megoldása érdekében a fejlesztők az Ethereumon építenek közösségi hálózatokat. A decentralizált közösségi hálózatok a hagyományos platformok számtalan problémájára megoldást nyújtanak, ás javítják a felhasználói élményt is. - -## Mik azok a decentralizált közösségi hálózatok? {#what-are-decentralized-social-networks} - -A decentralizált közösségi hálózatok olyan [blokkláncalapú](/glossary/#blockchain) platformok, melyeken a felhasználók kommunikálnak egymással, illetve tartalmat publikálnak és terjesztenek. Mivel ezek az alkalmazások a blokkláncon működnek, ezért képesek decentralizáltan üzemelni, ellenállnak a cenzúrának és a jogtalan kontrollnak. - -Számos decentralizált közösségi hálózat létezik az olyan közösségimédia-szolgáltatások alternatívájaként, mint a Facebook, LinkedIn, Twitter és Medium. Ugyanakkor a blokkláncon működtetett közösségi hálózatok olyan jellemzőkkel is bírnak, melyek a hagyományos platformok fölé helyezik őket. - - - -### Hogyan működnek a decentralizált közösségi hálózatok? {#decentralized-social-networks-overview} - -A decentralizált közösségi hálózatok valójában [decentralizált alkalmazások (dapp)](/dapps/), melyeket a blokkláncon létrehozott [okosszerződések](/glossary/#smart-contract) működtetnek. A szerződés programkódja adja ezen alkalmazások hátterét és meghatározza azok üzleti logikáját. - -A hagyományos közösségimédia-platformok adatbázisokon alapulnak, melyek tárolják a felhasználói információkat, a programkódot és egyéb adatokat. Ez azonban bármilyen leállás esetén egy sebezhető pontot jelent és komoly kockázatot hordoz magában. Tavaly például a Facebook szerverei [órákra leálltak](https://www.npr.org/2021/10/05/1043211171/facebook-instagram-whatsapp-outage-business-impact), és elvágták a felhasználókat a platformtól. - -A decentralizált közösségi hálózatok egy [peer-to-peer (P2P) hálózaton](/glossary/#peer-to-peer-network) működnek, mely ezernyi csomópontot (node) tartalmaz szerte az egész világon. Ha néhány csomópont le is áll, a hálózat zavartalanul működik tovább, így az alkalmazásokat nem érintik a leállások és kimaradások. - -A decentralizált tárhelyek használatával, mint amilyen az [InterPlanetary File System (IPFS)](https://ipfs.io/), az Ethereumra épített decentralizált közösségi hálózatok képesek megvédeni a felhasználók adatait azok kihasználása és rosszindulatú felhasználása ellen. Senki sem tudja eladni a felhasználók személyes adatait a reklámcégeknek, és a hackerek sem tudják ellopni a bizalmas információkat. - -Számos blokkláncalapú közösségi platform rendelkezik saját tokenekkel, hogy a reklámbevétel helyett ezzel biztosítsa a pénzforrások létrehozását. A felhasználók megvehetik ezeket a tokeneket, hogy bizonyos funkciókat használhassanak, vásárolhassanak az alkalmazáson belül, vagy akár ezzel díjazzák a kedvenc tartalomkészítőiket. - -## A decentralizált közösségi hálózatok előnyei {#benefits} - -1. A decentralizált közösségi hálózatok ellenállnak a cenzúrának és bárki számára elérhetők. Tehát a **felhasználókat nem lehet letiltani**, kizárni a platformról vagy önkényesen korlátozni. - -2. A decentralizált közösségi hálózatok **nyílt forráskódú elképzelésekre** épülnek, az alkalmazások programkódját bárki megvizsgálhatja. A hagyományos közösségi médiára jellemző, nem átlátható algoritmusokat kizárva a blokkláncalapú közösségi hálózatok képesek összehangolni a felhasználók igényeit és a platform működtetőit. - -3. A decentralizált közösségi hálózatokban nincs szükség közvetítőre. **A tartalomkészítők közvetlen tulajdonjoggal bírnak a tartalom felett**, és közvetlenül kapcsolódnak a követőkkel, rajongókkal, vevőkkel és más résztvevőkkel, csupán egy okosszerződés van közöttük. - -4. Mivel a decentralizált alkalmazások (dapp) az Ethereum hálózatán működnek, melyet a csomópontok egy globális, peer-to-peer hálózata tart fenn, így a decentralizált közösségi hálózatok **kevésbé vannak kitéve a szerverleállásnak** vagy bármilyen kiesésnek. - -5. A decentralizált közösségi platformok egy **fejlett bevételszerzési** keretrendszert kínálnak a tartalomkészítőknek a [nem helyettesíthető tokenek (NFT)](/glossary/#nft), az alkalmazáson belüli kriptofizetés és más eszközök révén. - -6. A decentralizált közösségi hálózatok **magas fokú adatbiztonságot és anonimitást** kínálnak a felhasználóknak. Például egy személy bejelentkezhet az Ethereumon alapuló közösségi hálózatra az [ENS](/glossary/#ens)-profilja vagy a [tárcája](/glossary/#wallet) révén – anélkül, hogy bármilyen személyazonosításra alkalmas információt (PII) megosztana, mint a neve, e-mail-címe stb. - -7. A decentralizált közösségi hálózatok decentralizált adattároláson alapulnak, nem centralizált adatbázisokon, így jobban meg tudják védeni a felhasználók adatait. - -## A decentralizált közösségi hálózatok az Ethereumon {#ethereum-social-networks} - -Az Ethereum-hálózat lett a decentralizált közösségi média fejlesztőinek kedvelt helye, mivel népszerű tokenekkel és masszív felhasználói bázissal rendelkezik. Néhány Ethereumon alapuló közösségi hálózat: - -### Mirror {#mirror} - -A [Mirror](https://mirror.xyz/) egy web3-alapú, decentralizált és a felhasználók által üzemeltetett íróplatform. A felhasználók ingyen olvashatnak és írhatnak azáltal, hogy a saját tárcáikkal kapcsolódnak. Emellett gyűjthetnek írásokat és feliratkozhatnak a kedvenc íróikra is. - -Az itt publikált írások állandóan elérhetők az Arweave révén, ami egy decentralizált tárhely, és gyűjthető [NFT (nem helyettesíthető token)](/nft/) készíthető belőlük, más néven szöveg NFT. A szöveg NFT-t az írók teljesen ingyen hozhatják létre, a gyűjtés pedig az Ethereumra épülő [második blokkláncrétegen (L2)](/glossary/#layer-2) történik, így a tranzakciók olcsók, gyorsak és környezetbarátak. - -### MINDS {#minds} - -A [MINDS](https://www.minds.com/) az egyik legnépszerűbb decentralizált közösségi hálózat. A Facebookhoz hasonlóan működik, és milliónyi felhasználója van. - -A felhasználók a platform saját [ERC-20](/glossary/#erc-20) tokenjével $MIND fizetnek a dolgokért. A felhasználók szerezhetnek azáltal is $MIND tokent, hogy népszerű tartalmat publikálnak, hozzájárulnak az ökoszisztémához és ajánlják a platformot másoknak. - -## A decentralizált közösségi hálózatok használata {#use-decentralized-social-networks} - -- **[Status.im](https://status.im/)** – _A Status egy biztonságos üzenetküldő alkalmazás, mely nyílt forráskódú, peer-to-peer protokollt használ, és elejétől a végéig titkosítva van, hogy megvédje az üzeneteket._ -- **[Mirror.xyz](https://mirror.xyz/)** – _A Mirror egy decentralizált, felhasználók által működtetett publikáló platform az Ethereumon, hogy a felhasználók finanszírozást gyűjtsenek az ötleteiknek, bevételt kapjanak a tartalom után és értékes közösségeket építsenek._ -- **[Lens Protocol](https://lens.xyz/)** – _A Lens Protocol egy decentralizált közösségi gráf, ahol a tartalomkészítők tulajdonolják az általuk létrehozott tartalmat a decentralizált internet teljes hosszában._ -- **[Farcaster](https://farcaster.xyz/)** – _A Farcaster egy kellően decentralizált közösségi hálózat. Egy nyitott protokoll, amely több klienst is támogat, mint például az e-mail-funkció._ - -## Web2 közösségi hálózatok az Ethereumon {#web2-social-networks-and-ethereum} - -Nem csak a [web3](/glossary/#web3) közösségi platformok használják a blokklánc-technológiát a közösségi médiához. Számos centralizált platform is integrálni szeretné az Ethereumot a saját infrastruktúrájába: - -### Reddit {#reddit} - -A Reddit [közösségi pontokat](https://cointelegraph.com/news/reddit-to-reportedly-tokenize-karma-points-and-onboard-500m-new-users) hirdetett meg, amelyek olyan ERC-20 tokenek, amelyeket a felhasználók minőségi tartalmak közzétételével és az online közösségekhez (subredditekhez) való hozzájárulással szerezhetnek. Ezeket a tokeneket a felhasználó egy subreddit fórumon belül be tudja váltani, hogy különleges jogokat vagy bevételt szerezzen. A Reddit az Arbitrummal működik együtt, amely egy [második blokkláncréteg (L2)](/glossary/#layer-2) megoldás az Ethereum-tranzakciók skálázására. - -A program már elérhető, az r/CryptoCurrency subreddit [a „Moons”-nak nevezett közösségi pontokkal üzemel](https://www.reddit.com/r/CryptoCurrency/wiki/moons_wiki). A hivatalos leírás szerint a Moons „a posztok készítőit, kommentálóit és a moderátorokat díjazza a subreddithez való hozzájárulásukért”. Mivel ezek a tokenek a blokkláncon vannak (a felhasználók tárcákba kapják azokat), ezért függetlenek a Reddittől, és nem lehet azokat elvenni. - -A felhasználók nemcsak különleges funkciókra használhatják pontjaikat, hanem eladhatják azokat hagyományos valutáért is a tőzsdéken. Emellett az adott felhasználó közösségi pontjainak összege meghatározza, hogy a közösségen belül milyen mértékben vehetnek részt a döntésekben. - -## További olvasnivaló {#further-reading} - -### Cikkek {#articles} - -- [A decentralizált közösségi média: útmutató a web3 közösségi alkalmazásokhoz](https://www.coinbase.com/blog/decentralizing-social-media-a-guide-to-the-web3-social-stack) - _Coinbase Ventures_ -- [A közösségi hálózatok világa a következő nagy decentralizálási lehetőség](https://www.coindesk.com/tech/2021/01/22/social-networks-are-the-next-big-decentralization-opportunity/) — _Ben Goertzel_ -- [A web3 megtartja ígéretét a decentralizált, közösség által működtetett közösségi hálózatokról](https://venturebeat.com/2022/02/26/web3-holds-the-promise-of-decentralized-community-powered-social-networks/) — _Sumit Ghosh_ -- [A blokklánc közösségi média alkalmazásainak áttekintése](https://www.gemini.com/cryptopedia/blockchain-social-media-decentralized-social-media) — _Gemini Cryptopedia_ -- [Hogyan tudja a blokklánc megoldani a közösségi médiához kapcsolódó adatvédelmet](https://www.investopedia.com/news/ethereum-blockchain-social-media-privacy-problem-linkedin-indorse/) — _Prableen Bajpai_ -- [Elégséges decentralizáció a közösségi hálózatok számára](https://www.varunsrinivasan.com/2022/01/11/sufficient-decentralization-for-social-networks) — _Varun Srinivasan_ - -### Videók {#videos} - -- [A decentralizált közösségi média bemutatása](https://www.youtube.com/watch?v=UdT2lpcGvcQ) — _Coinmarketcap_ -- [DeSo a blokklánc decentralizálja a közösségi médiát](https://www.youtube.com/watch?v=SG2HUiVp0rE) — _Bloomberg Technology_ -- [A decentralizált közösségi média jövője – Balaji Srinivasan, Vitalik Buterin, Juan Benet](https://www.youtube.com/watch?v=DTxE9KV3YrE) — _ETHGlobal_ - -### Közösségek {#communities} - -- [r/CryptoCurrency subreddit](https://www.reddit.com/r/CryptoCurrency/) diff --git a/public/content/translations/hu/09) Learn Pages/bridges/index.md b/public/content/translations/hu/09) Learn Pages/bridges/index.md deleted file mode 100644 index 4882abb8401..00000000000 --- a/public/content/translations/hu/09) Learn Pages/bridges/index.md +++ /dev/null @@ -1,137 +0,0 @@ ---- -title: Bevezetés a blokklánchidak működésébe -description: A hidak segítségével a felhasználók különböző blokkláncok között tudnak eszközöket mozgatni -lang: hu ---- - -# Blokkláncösszekötők {#prerequisites} - -_A Web3 egy olyan ökoszisztémává fejlődött, ahol L1 blokkláncok és L2 skálázási megoldások találhatók, mind egyedi képességekkel és kompromisszumokkal. Ahogy növekszik a blokkláncprotokollok száma, úgy nő a kereslet is, hogy az eszközöket láncok között lehessen mozgatni. Az igény kielégítéséhez összekötőkre vagy hidakra van szükségünk._ - - - -## Mik azok az összekötők vagy hidak? {#what-are-bridges} - -A blokklánchidak épp olyanok, mint a fizikai világban. A fizikai híd két helyet köt össze, a blokklánchíd két blokklánc-ökoszisztémát. **A hidak kommunikációs lehetőséget teremtenek a blokkláncok között az információk és eszközök transzferálásával**. - -Vegyünk egy példát: - -Ön az Amerikai Egyesült Államokból való és Európába utazik. Amerikai dollárral (USD) rendelkezik, de az utazáson euróra (EUR) van szüksége. Az átváltáshoz használhat egy valutaváltót egy kis díj ellenében. - -De mit csináljunk, ha egy ilyen átváltást két különböző [blokkláncon](/glossary/#blockchain) akarunk véghezvinni? Tegyük fel, hogy Ön az Ethereum-főhálózatán lévő [ETH-t](/glossary/#ether) akarja váltani az  [Arbitrumon](https://arbitrum.io/) lévő ETH-re. Ahogy a fenti példában EUR-t váltottunk, szükség van egy olyan mechanizmusra, mely az ETH összegünket átviszi az Ethereumról az Arbitrumra. A hidak teszik lehetővé az ilyen tranzakciókat. Ebben az esetben az [Arbitrum rendelkezik egy saját híddal](https://bridge.arbitrum.io/), ami átviszi az ETH-t a főhálózatról az Arbitrumra. - -## Miért van szükség hidakra? {#why-do-we-need-bridges} - -Minden blokkláncnak megvannak a maga korlátai. Az Ethereum skálázásához és hogy ki bírja szolgálni a keresletet, [tranzakcióösszegzőkre (rollup)](/glossary/#rollups) van szüksége. Más L1 blokkláncok, mint a Solana és az Avalanche, másképpen vannak összerakva, így magasabb tranzakcióátvitelt bírnak, de a decentralizációt áldozzák fel cserébe. - -Ugyanakkor minden blokkláncot elkülönült környezetben fejlesztenek, más szabályok és más [konszenzusmechanizmus](/glossary/#consensus) alapján. Emiatt maguktól nem tudnak egymással kommunikálni, a tokeneket pedig nem lehet szabadon átvinni az egyikről a másikra. - -A hidak kötik össze a blokkláncokat, lehetővé téve az információ és a tokenek áramlását közöttük. - -**A hidak lehetővé teszik**: - -- az eszközök és az információk a láncok között mozogjanak. -- a [decentralizált alkalmazások (dapp)](/glossary/#dapp) hozzáférjenek a különféle blokkláncok erősségeihez – így azok képességeit fejleszteni tudják (mivel a protokollok esetében manapság több tér van az innovációra). -- a felhasználók új platformokat érjenek el és hasznosítsák a különböző láncok előnyeit. -- a fejlesztők a különböző blokklánc-ökoszisztémákon együttműködjenek és új platformokat építsenek a felhasználók számára. - -[Hogyan lehet áthelyezni a tokeneket a második blokkláncrétegbe (L2)](/guides/how-to-use-a-bridge/) - - - -## A hidak alkalmazási területei {#bridge-use-cases} - -A következő szcenáriók esetében lehet hidat használni: - -### Alacsonyabb tranzakciós költségek {#transaction-fees} - -Tegyük fel, hogy Ön rendelkezik ETH-szel az Ethereum főhálózatán, de olcsóbb tranzakciós díjat szeretne, hogy különféle alkalmazásokat tudjon használni. Ha a főhálózatról az ETH-t áthelyezi egy L2 rollupmegoldásra, akkor alacsonyabb díjakat élvezhet. - -### Decentralizált alkalmazások (dapp) más blokkláncokon {#dapps-other-chains} - -Tegyük fel, hogy Ön az Aave alkalmazást használja az Ethereum főhálózatán arra, hogy USDT-t kölcsönözzön, de a Polygonon ugyanez az alkalmazás magasabb kamatot ad. - -### A blokklánc-ökoszisztémák felfedezése {#explore-ecosystems} - -Ha Ön ETH összeggel rendelkezik az Ethereum-főhálózaton, de fel szeretne fedezni egy alternatív L1 hálózatot, hogy kipróbálja annak alkalmazásait. A hídon keresztül átviheti az ETH-t a kiválasztott L1-re. - -### Saját kriptoeszközök {#own-native} - -Amennyiben Ön szeretne bitcoint (BTC) birtokolni, de a pénzeszközei az Ethereum főhálózatán vannak. Az Ethereumon becsomagolt formában szerezhet bitcoint (WBTC). Ugyanakkor a WBTC egy [ERC-20](/glossary/#erc-20) token az Ethereum hálózatán, tehát egy Ethereum verziójú bitcoin, és nem az eredeti eszköz a Bitcoin-blokkláncon. Az eredeti BTC megszerzéséhez egy hídon keresztül át kell vinnie a pénzeszközeit a Bitcoin hálózatára. Ezzel áthelyezi a WBTC-t és átváltja BTC-re. Másik irányból, ha Ön rendelkezik BTC-vel, de azt az Ethereum [decentralizált pénzügyi (DeFi)](/glossary/#defi) protokolljában akarja használni. Ekkor a hídon a másik irányba mozgatja az eszközeit, BTC-ről WBTC-re váltja, majd azt áthelyezi az Ethereumra. - - - Mindezt megteheti egy centralizált tőzsde segítségével is. Ha azonban az eszközei már a tőzsdén vannak, akkor több lépést kell végrehajtani, és akkor már egyszerűbb a hidat használni. - - - - -## A hidak típusai {#types-of-bridge} - -A hidak többféle kialakításúak és összetettségűek. Általánosságban kétféle lehet: bizalmat igénylő és bizalomigénytől mentes. - -| Bizalmat igénylő (trusted) hidak | Bizalomigénytől mentes (trustless) hidak | -| ------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | -| A bizalmat igénylő hidak működése egy központi entitáson vagy rendszeren múlik. | A bizalomigénytől mentes hidak működését okosszerződések és algoritmusok vezérlik. | -| A pénzeszközök felügyelete és a híd biztonsága terén bizalmi feltételezések vannak. A felhasználó a híd működtetőjének reputációjára támaszkodik. | A bizalommentessége azt jelenti, hogy a híd biztonsága megegyezik a mögötte álló blokkláncéval. | -| A felhasználónak át kell engednie a kriptoeszközök feletti kontrollját. | Az [okosszerződések](/glossary/#smart-contract) révén a felhasználók kontrollja alatt maradnak az eszközök. | - -Röviden, a bizalmat igénylő hidaknál bizalmi feltételezésekkel kell élnünk, míg a bizalomigénytől mentes hidaknál ez minimális és nem merül fel más, mint a mögöttes blokklánc kapcsán. Ezeket a kifejezéseket a következőképpen kell érteni: - -- **Bizalomigénytől mentes (trustless)**: a mögötte található rendszerrel megegyező biztonsági szintje van. Olvassa el [Arjun Bhuptani erről szóló cikkét.](https://medium.com/connext/the-interoperability-trilemma-657c2cf69f17) -- **Bizalmat igénylő (trusted)**: a mögöttes rendszer biztonságától eltávolodik azzal, hogy külső igazolókat von be a rendszerbe, így kriptogazdasági szempontból kevésbé biztonságos. - -A két megkülönböztetés fő különbségeinek jobb megértése érdekben vegyünk egy példát: - -Tegyük fel, hogy Ön a reptéren a check-in előtt áll. Kétféle ellenőrzés van: - -1. Manuális chek-in – ahol a hivatalnokok manuálisan ellenőrzik a jegyét és a személyazonosságát, mielőtt a belépőkártyát átadnák. -2. Self check-In – ahol egy gép ellenőrzi ezeket és adja ki a belépőkártyát, ha mindent rendben talál. - -A manuális ellenőrzés hasonló a bizalmat igénylő modellhez, mert egy harmadik félen múlik a működése, például a hivatalnokokon. Felhasználóként abban bízunk, hogy a hivatalnokok a megfelelő döntést hozzák és helyesen kezelik a privát információkat. - -A self check-in hasonlít a bizalomigénytől mentes modellhez, mivel kiveszi az operátor szerepét, és a technológia működteti. A felhasználónak mindvégig megmarad a kontroll az adatai felett, és nem kell azokat egy harmadik félre bíznia. - -Számos hidat biztosító megoldás e két modell közötti módszert alakít ki változó bizalmi fokozattal. - - - -## Híd használata {#use-bridge} - -A hidak segítségével a felhasználók különböző blokkláncok között tudnak eszközöket mozgatni. Íme néhány forrás, amelyek hasznosak lehetnek a hidak megtalálásához és használatához: - -- **[L2BEAT hidakról szóló összefoglaló](https://l2beat.com/bridges/summary) & [L2BEAT hidak kockázati elemzése](https://l2beat.com/bridges/risk)**: Egy átfogó tanulmány a különféle hidakról, beleértve azok piaci részesedését, típusát és azokat a blokkláncokat, melyekkel összeköttetést biztosítanak. Az L2BEAT kockázati elemzést is készített a hidakról, hogy a felhasználók megfelelően tudjanak választani azok közül. -- **[DefiLlama hidakról szóló összefoglaló](https://defillama.com/bridges/Ethereum)**: Az Ethereum hálózatok közötti hidak forgalmi adatainak összefoglalója. - - - -## A hidak használatának kockázata {#bridge-risk} - -A hidak fejlesztése még a korai stádiumban van. Nagy valószínűséggel az optimális kialakítás még nem született meg. A hidakkal való interakció a következő kockázatokkal jár: - -- **Okosszerződéses kockázat —** a programkódban lévő hiba miatt a felhasználó pénzeszközei elveszhetnek -- **Technológiai kockázat —** szoftverhiba, hibás kód, emberi hiba, spam és rosszindulatú támadás valószínűleg megakaszthatja a működést - -Emellett, mivel a bizalmat igénylő (trusted) hidak még több bizalmi feltételt jelentenek, ezért több kockázatot is hordoznak magukban: - -- **Cenzúra kockázata —** a hidak működtetői elméletileg meg tudják akadályozni a felhasználót az eszközeinek áthelyezésében -- **Felügyeleti kockázat —** a hidak működtetői összefoghatnak abban, hogy ellopják a felhasználók eszközeit - -A felhasználó eszközei veszélyben vannak, ha: - -- hiba van az okosszerződésben -- a felhasználó hibázik -- a mögöttes blokkláncot megtámadják -- a híd kezelői a bizalmat igénylő (trusted) hidak esetében rosszhiszeműek -- a hidat megtámadják - -Az egyik korábbi, Solana Wormhole híd elleni támadásnál [ 120k wETH-t (325 millió USD) lopott el a támadó](https://rekt.news/wormhole-rekt/). A [blokkláncok elleni legnagyobb támadások hidakat is érintenek](https://rekt.news/leaderboard/). - -A hidak elengedhetetlenek az Ethereum L2 használatához, illetve ha a felhasználók más ökoszisztémákat is fel szeretnének fedezni. Ugyanakkor az ebben rejlő kockázatok miatt meg kell érteni a hidak által hozott kompromisszumokat. Íme néhány [stratégia a láncok közötti biztonság](https://blog.debridge.finance/10-strategies-for-cross-chain-security-8ed5f5879946) témájában. - - - -## További olvasnivaló {#further-reading} - -- [EIP-5164: Láncok közötti műveletek végrehajtása](https://ethereum-magicians.org/t/eip-5164-cross-chain-execution/9658) _2022. június 18. – Brendan Asselstine_ -- [L2 hidak kockázati keretrendszere](https://gov.l2beat.com/t/l2bridge-risk-framework/31) _2022. július 5. – Bartek Kiepuszewski_ -- [A jövő miért inkább többláncú, mint láncok közötti](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) _2022. január 8. – Vitalik Buterin_ diff --git a/public/content/translations/hu/09) Learn Pages/energy-consumption/index.md b/public/content/translations/hu/09) Learn Pages/energy-consumption/index.md deleted file mode 100644 index 133be2fd013..00000000000 --- a/public/content/translations/hu/09) Learn Pages/energy-consumption/index.md +++ /dev/null @@ -1,82 +0,0 @@ ---- -title: Az Ethereum energiafogyasztása -description: Alapvető információk az Ethereum energiafogyasztásának megértéséhez. -lang: hu ---- - -# Az Ethereum energiafogyasztása {#proof-of-stake-energy} - -Az Ethereum egy környezetbarát blokklánc. Az Ethereum [proof-of-stake](/developers/docs/consensus-mechanisms/pos) konszenzus mechanizmusa ETH-t használ [az energia helyett, hogy biztosítsa a hálózatot](/developers/docs/consensus-mechanisms/pow). Az Ethereum energiafogyasztása [~0,0026 TWh/év](https://carbon-ratings.com/eth-report-2022) a teljes globális hálózaton. - -Az Ethereum energiafogyasztásának becsült adata egy [CCRI (Crypto Carbon Ratings Institute)](https://carbon-ratings.com) tanulmányból származik. Ez egy lentről felfelé építkező becslés az Ethereum-hálózat áramfogyasztásáról és karbonlábnyomáról ([nézze meg a reportot](https://carbon-ratings.com/eth-report-2022)). A különféle csomópontok áramfogyasztását mérték, melyek különböző hardverekkel és kliensszoftverekkel működnek. A becsült **2601 MWh** (0,0026 TWh), mint a hálózat teljes éves áramfogyasztása, megfelel **870 tonna CO2e** szén-dioxid kibocsátásnak, regionális tényezőket figyelembe véve. Ez az érték változik, ahogy a csomópontok belépnek a hálózatra és kilépnek a hálózatról – Ön is ellenőrizheti egy gördülő 7 napos átlagbecsléssel: [Cambridge-blokklánchálózat fenntarthatósági indexe](https://ccaf.io/cbnsi/ethereum) (a módszer kicsit más, nézze meg a részleteket az oldalukon). - -Az Ethereum energiafogyasztását összevethetjük más termékek és iparágak éves becsléseivel, hogy kontextusban lássuk azt. Így jobban megértjük, hogy Ethereum fogyasztása magas vagy alacsony. - - - -Az ábra az Ethereum becsült fogyasztását mutatja TWh/év formájában, más termékekkel és iparágakkal összevetve. A becslések nyilvános adatokból származnak 2023. júliusából, a forrásokat megtalálja a táblázat alatt. - -| | Éves energiafogyasztás (TWh) | Összevetve a PoS Ethereummal | Forrás | -|:--------------------------- |:----------------------------:|:----------------------------:|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:| -| Globális adatközpontok | 190 | 73 000x | [forrás](https://www.iea.org/commentaries/data-centres-and-energy-from-global-headlines-to-local-headaches) | -| Bitcoin | 149 | 53 000x | [forrás](https://ccaf.io/cbnsi/cbeci/comparisons) | -| Aranybányászat | 131 | 50 000x | [forrás](https://ccaf.io/cbnsi/cbeci/comparisons) | -| Számítógépes játékok (USA)* | 34 | 13 000x | [forrás](https://www.researchgate.net/publication/336909520_Toward_Greener_Gaming_Estimating_National_Energy_Use_and_Energy_Efficiency_Potential) | -| PoW Ethereum | 21 | 8100x | [forrás](https://ccaf.io/cbnsi/ethereum/1) | -| Google | 19 | 7300x | [forrás](https://www.gstatic.com/gumdrop/sustainability/google-2022-environmental-report.pdf) | -| Netflix | 0,457 | 176x | [forrás](https://assets.ctfassets.net/4cd45et68cgf/7B2bKCqkXDfHLadrjrNWD8/e44583e5b288bdf61e8bf3d7f8562884/2021_US_EN_Netflix_EnvironmentalSocialGovernanceReport-2021_Final.pdf) | -| PayPal | 0,26 | 100x | [forrás](https://s202.q4cdn.com/805890769/files/doc_downloads/global-impact/CDP_Climate_Change_PayPal-(1).pdf) | -| AirBnB | 0,02 | 8x | [forrás](https://s26.q4cdn.com/656283129/files/doc_downloads/governance_doc_updated/Airbnb-ESG-Factsheet-(Final).pdf) | -| **PoS Ethereum** | **0,0026** | **1x** | [forrás](https://carbon-ratings.com/eth-report-2022) | - -\*Beleértve a felhasználói eszközök fogyasztását, mint asztali számítógépek, laptopok és játékkonzolok. - -Bonyolult pontos becsléseket készíteni az energiafogyasztásról, főleg ha a vizsgált entitás összetett ellátási lánccal bír, ami befolyásolja a hatékonyságát. A Netflix és a Google esetében például a fogyasztás becslése attól függően változik, hogy a rendszer fenntartását és a tartalomnak a felhasználóhoz való eljutását nézik (_közvetlen fogyasztás_), vagy beleveszik azt is, amit a tartalom előállítása, irodák fenntartása, reklámozás stb. jelent (_közvetett fogyasztás_). A közvetett fogyasztásba az is beleszámíthat, hogy mennyi energiát vesz igénybe elfogyasztani a kínált tartalma a felhasználó oldalán, a tévék, számítógépek és mobilok használata során. - -A fenti becslések nem tökéletes összehasonlítások. A közvetett fogyasztás mennyisége, amivel számolnak, különbözik a források szerint és ritkán tartalmazza a felhasználók eszközeit is. Minden mögöttes információforrás több részletet közöl arról, hogy pontosan mit mérnek. - -Az összehasonlítás a Bitcoint és a proof-of-work Ethereumot feltünteti. Fontos megérteni, hogy a proof-of-work hálózatok fogyasztása nem statikus, és napról napra változik. A becslések nagy mértékben eltérhetnek a források szerint is. A téma árnyalt [vitát](https://www.coindesk.com/business/2020/05/19/the-last-word-on-bitcoins-energy-consumption/) generál, nemcsak a felhasznált energia mennyiségéről, hanem annak forrásáról és etikájáról is. Az energiafogyasztás nem feltétlenül pontosan kapcsolódik a környezeti hatásokhoz, mert különböző projektek különféle energiaforrásokat használnak, beleértve a kisebb vagy nagyobb arányú megújuló forrásokat is. Például a [Cambridge Bitcoin elektromosáram-fogyasztási index](https://ccaf.io/cbnsi/cbeci/comparisons) azt mutatja, hogy a Bitcoin hálózati igénye elméletileg kielégíthető lenne abból a gázból vagy áramból, ami a szállítás során amúgy is elveszne. Az Ethereum a fenntarthatóság miatt cserélte le a rendszer energiaéhes részét egy környezetbarát alternatívára. - -Számtalan iparág energiafogyasztását és szén-dioxid-kibocsátását megtekintheti a [Cambridge-blokklánchálózat fenntarthatósági index oldalán](https://ccaf.io/cbnsi/ethereum). - -## Tranzakciónkénti becslés {#per-transaction-estimates} - -Számos cikk tranzakciónkénti becslésről beszél a blokkláncok esetén. Ez félrevezető, mert a blokkjavaslat és validálás független a benne található tranzakciók számától. A tranzakciónkénti felhasználás azt jelentené, hogy kevesebb tranzakció kevesebb energiát fogyaszt és fordítva, de ez nem igaz. Emellett a tranzakciónkénti becslés érzékeny arra, hogy a blokklánc tranzakcióátvitelét hogyan definiálják, amelynek megcsavarásával látszólag nagyobb vagy kisebb érték jön ki. - -Az Ethereumon például a tranzakcióátvitel nemcsak az alapréteget tartalmazza, hanem a [második blokkláncréteg (L2)](/layer-2/) összevont tranzakcióit is. Az L2 általában nincs benne a kalkulációkban, de ha hozzávennénk a szekvenszer általi fogyasztást (kevés) és a kezelt tranzakciókat (sok), akkor jelentősen lecsökkenne a tranzakciónkénti becslés. Ez az egyik oka annak, hogy a platformok tranzakciónkénti energiafogyasztásának összehasonlítása félrevezető lehet. - -## Az Ethereum karbonadóssága {#carbon-debt} - -Az Ethereum energiafelhasználása igen alacsony, de nem mindig volt így. Az Ethereum eredetileg a proof-of-work mechanizmust használta, ami nagyobb környezeti költségekkel járt, mint a jelenlegi proof-of-stake. - -Az Ethereum eleve a proof-of-stake-alapú konszenzusmechanizmust tervezte, anélkül hogy feláldozná a biztonságot vagy a decentralizáltságot, ezért többéves fókuszált kutatás és fejlesztés kellett hozzá. Emiatt a hálózat felállításához a proof-of-work mechanizmusra volt szükség. Ennél a bányászok a számítógépeiket használják az érték kiszámolására, energiát fogyasztva eközben. - -![Az Ethereum energiafogyasztásának összehasonlítása a Beolvadás előtt és után, ahol az Eiffel torony (330 méter magas) a bal oldalon jelenti a korábbi állapotot, vagyis a nagy energiafogyasztást, a jelentős csökkenést pedig a 4 cm-es LEGO-figura képviseli](energy_consumption_pre_post_merge.png) - -A CCRI becslése szerint a Beolvadás több mint **99,988%-kal** lecsökkentette az Ethereum éves áramfogyasztását. Ugyanígy az Ethereum karbonlábnyoma is csökkent **99,992%-kal** (11 016 000 tonna helyett 870 tonna CO2e lett). Ez a változás olyan, mint az Eiffel torony magaságáról egy kis bábu méretére csökkent fogyasztás, ahogy az ábra illusztrálja. Ennek következtében a hálózat biztosításának környezeti költsége drasztikusan lecsökkent. A hálózat biztonsága pedig növekedett. - -## Környezetbarát alkalmazási réteg {#green-applications} - -Miközben az Ethereum energiafogyasztása nagyon alacsony, egy jelentős, fejlődő és igen aktív [**regeneratív pénzügyi (ReFi)**](/refi/) közösség épült a hálózaton. A ReFi alkalmazások a decentralizált pénzügyek (DeFi) komponenseit használják, hogy olyan pénzügyi alkalmazásokat építsenek, amelyek pozitív externáliákat teremtenek. A ReFi része egy kiterjedtebb[„solarpunk”](https://en.wikipedia.org/wiki/Solarpunk) mozgalomnak, ami szorosan kötődik az Ethereumhoz, és a technológiai fejlődést a környezetről való gondoskodással párosítja. Az Ethereum decentralizált, engedélymentes és egymásra építhető jellege miatt ideális alap a ReFi és a solarpunk közösségeknek. - -A web3 közjó-finanszírozási platformjai, mint a [Gitcoin](https://gitcoin.co) klímaköröket működtetnek, hogy elősegítsék az Ethereum alkalmazási rétegének környezettudatos építését. Ezen kezdeményezések (és mások, mint a [decentralizált tudomány / DeSci](/desci/)) kialakulása által az Ethereum egy környezeti és közösségi szempontból pozitív technológia. - - - Ha szeretne az oldallal kapcsolatban fejlesztést javasolni, akkor naplózzon egy kérést (issue) vagy PR-t. A statisztikák nyilvánosan elérhető adatokból készült becslések, nem hivatalos állítások vagy ígéretek az ethereum.org csapat vagy az Ethereum Alapítvány részéről. - - -## További olvasnivaló {#further-reading} - -- [Cambridge-blokklánchálózat fenntarthatósági indexe](https://ccaf.io/cbnsi/ethereum) -- [Fehérházi jelentése a proof-of-work alapú blokkláncokról](https://www.whitehouse.gov/wp-content/uploads/2022/09/09-2022-Crypto-Assets-and-Climate-Report.pdf) -- [Ethereum-kibocsátás: egy alulról építkező becslés](https://kylemcdonald.github.io/ethereum-emissions/) – _Kyle McDonald_ -- [Ethereum energiafelhasználási index](https://digiconomist.net/ethereum-energy-consumption/) – _Digiconomist_ -- [ETHMerge.com](https://ethmerge.com/) – _[@InsideTheSim](https://twitter.com/InsideTheSim)_ -- [Az egyesítés (The Merge) – az Ethereum-hálózat áramfogyasztására és karbonlábnyomára gyakorolt hatása](https://carbon-ratings.com/eth-report-2022) – _CCRI_ -- [Az Ethereum energiafogyasztása](https://mirror.xyz/jmcook.eth/ODpCLtO4Kq7SCVFbU4He8o8kXs418ZZDTj0lpYlZkR8) - -## Kapcsolódó témák {#related-topics} - -- [Az Ethereum jövőképe](/roadmap/vision/) -- [A Beacon Chain](/roadmap/beacon-chain) -- [Az egyesítés](/roadmap/merge/) diff --git a/public/content/translations/hu/09) Learn Pages/governance/index.md b/public/content/translations/hu/09) Learn Pages/governance/index.md deleted file mode 100644 index dc047fa5bf4..00000000000 --- a/public/content/translations/hu/09) Learn Pages/governance/index.md +++ /dev/null @@ -1,182 +0,0 @@ ---- -title: Az Ethereum irányítása -description: Annak bemutatása, hogy az Ethereummal kapcsolatos döntések hogyan születnek meg. -lang: hu ---- - -# Bevezetés az Ethereum irányításába {#introduction} - -_Ha senki sem birtokolja az Ethereumot, akkor a döntéseket hogyan hozzák meg az Ethereum kapcsán? Az Ethereum irányítása (governance) egy olyan folyamat, mely lehetővé teszi a döntések meghozatalát._ - - - -## Mi az az irányítás (governance)? {#what-is-governance} - -Az irányítás az a rendszer, amely lehetővé teszi a döntéshozást. Egy tipikus szervezeti struktúrában a végrehajtó csapat vagy az igazgatótanács szava az utolsó a döntéshozásban. Vagy talán a részvényesek szavaznak a javaslatokra, hogy változást indítsanak el. A politikai rendszerben a választott hivatalnokok olyan törvényt hoznak, ami a választóik javát szolgálja. - -## Decentralizált irányítás {#decentralized-governance} - -Az Ethereum protokollt nem birtokolja vagy kontrollálja senki, ugyanakkor a változásokról dönteni kell, hogy a hálózat hosszú életét és prosperitását a leginkább biztosítsák. A tulajdonlás hiánya miatt a hagyományos szervezeti irányítás nem működő megoldás. - -## Ethereum-felügyelet {#ethereum-governance} - -Az Ethereum irányítása (governance) az a folyamat, amely által a protokoll megváltoztatható. Fontos kiemelni, hogy ez nem kapcsolódik ahhoz, hogy az emberek és az alkalmazások hogyan használják a protokollt, mert az Ethereum egy engedélymentes hálózat. A világon bárki bárhonnan részt vehet a láncon zajló tevékenységekben. Nincsenek olyan szabályok, hogy ki csinálhat vagy nem csinálhat alkalmazást vagy indíthat tranzakciókat. Ugyanakkor van egy folyamat, mellyel változásokat lehet kezdeményezni a protokollban, amelyre a decentralizált alkalmazások épülnek. Mivel sok ember függ az Ethereum stabilitásától, ezért a kulcsváltozások koordinációs küszöbe nagyon magas, beleértve a közösségi és technikai folyamatokét is, hogy az Ethereum módosítása biztonságos és a közösség által széles körben támogatott legyen. - -### A láncon belüli és kívüli irányítás összehasonlítása {#on-chain-vs-off-chain} - -A blokklánc-technológiával új irányítási képességek jelentek meg, mint amilyen a láncon belüli irányítás is. A láncon belüli irányítás az, amikor a javasolt protokollváltoztatásokat az érdekeltek megszavazzák, általában egy irányítási token birtokában, a szavazás pedig a láncon zajlik. A láncon belüli irányítás néhány esetében a javasolt változások már bele vannak írva a kódba és automatikusan végrehajtásra kerülnek, ha az érdekeltek jóváhagyják azt, aláírva a tranzakciót. - -A másik megközelítés, a láncon kívüli irányítás az, amikor a protokoll változtatásait egy közösségi megvitatás informális folyamata vezérli, amit ha jóváhagynak, akkor teszik bele a kódba. - -**Az Ethereum-irányítás láncon kívül történik** az érdekeltek széles körét bevonva. - -_Miközben a protokollszintű Ethereum-irányítás láncon kívül zajlik, addig számos alkalmazási területe van a láncon belüli irányításnak, mint például a decentralizált autonóm szervezetek (DAO) működése._ - - - Bővebben a DAO-król - - - - -## Ki vesz részt ebben? {#who-is-involved} - -Az [Ethereum-közösségben](/community/) számos érdekelt fél van, akik szerepet játszanak az irányítási folyamatban. A protokolltól távolabb lévőktől kezdve így néz ki az érdekeltek köre: - -- **Ether-használók**: olyan emberek, akik egy tetszőleges összegű ETH-t birtokolnak. [Bővebben az ETH-ről](/eth/). -- **Az alkalmazások felhasználói**: akik az Ethereum blokkláncán lévő alkalmazásokat használják. -- **Alkalmazások/eszközök fejlesztői**: akik alkalmazásokat írnak az Ethereum blokkláncra (pl. DeFi, NFT-k stb.), vagy eszközöket építenek, amelyek az Ethereummal lépnek interakcióba (pl. tárcák, tesztcsomagok stb.). [Bővebben a dapp-okról](/dapps/). -- **Csomópont-operátorok**: akik csomópontokat működtetnek, amelyek blokkokat és tranzakciókat javasolnak, illetve elutasítják az érvénytelen tranzakciókat vagy blokkokat. [Bővebben a csomópontokról](/developers/docs/nodes-and-clients/). -- **EIP-szerzők**: ők javasolnak változásokat az Ethereum-protokollt illetően Ethereum fejlesztési javaslatok (EIP) formájában. [Bővebben az EIP-ekről](/eips/). -- **Validátorok**: ők olyan csomópontokat futtatnak, melyek új blokkokat tudnak adni az Ethereum-blokklánchoz. -- **Protokollfejlesztők** (azaz „Magfejlesztők” ): ők kezelik a különféle Ethereum-implementációkat (pl. go-ethereum, Nethermind, Besu, Erigon, Reth a végrehajtási rétegen; Prysm, Lighthouse, Nimbus, Teku, Lodestar, Grandine a konszenzusrétegen). [Bővebben az Ethereum-kliensekről](/developers/docs/nodes-and-clients/). - -_Megjegyzés: bárki lehet több csoport tagja is (pl. a protokollfejlesztő lehet EIP-bajnok is, futtathat Beaconlánc-validátort és használhat DeFi-alkalmazásokat). A koncepcionális egyértelműség miatt könnyebb, ha megkülönböztetjük őket._ - - - -## Mi az az Ethereum fejlesztési javaslat (EIP)? {#what-is-an-eip} - -Az egyik fontos Ethereum-irányítási eszköz az **Ethereum fejlesztési javaslatok (EIP)** kezelése. Az EIP olyan szabvány, amely egy lehetséges új funkciót vagy folyamatot specifikál az Ethereum számára. Az Ethereum-közösség bármelyik tagja létrehozhat EIP-t. Ha Önt érdekli az EIP írása, értékelése vagy irányítása, akkor: - - - Bővebben az EIP-kről - - - - -## A hivatalos folyamat {#formal-process} - -Az Ethereum-protokollt érintő változásokat a következő módon lehet kezdeményezni: - -1. **Javasoljon egy alapvető (core) EIP-et**: ahogy az [EIP-1](https://eips.ethereum.org/EIPS/eip-1#core-eips) részletezi, az első lépés egy Ethereum változtatáshoz az, hogy egy alapvető EIP-ben kidolgozzák azt. Ez lesz a hivatalos specifikációja egy EIP-nek, amit a protokollfejlesztők implementálnak, ha elfogadásra kerül. - -2. **Mutassa be az EIP-et a protokollfejlesztőknek**: amint egy alapvető EIP-vel rendelkezik, amelyhez közösségi adatokat is gyűjtött, mutassa be azt a fejlesztőknek. Ehhez javasolja, hogy vitassák azt meg egy [AllCoreDevs konferenciabeszélgetésen](https://github.com/ethereum/execution-specs/tree/master/network-upgrades#getting-the-considered-for-inclusion-cfi-status). Valószínűleg valamilyen beszélgetés már történt róla az [Ethereum Magician fórumon](https://ethereum-magicians.org/) vagy az [Ethereum R&D Discord csatornán](https://discord.gg/mncqtgVSVw). - -> E fázis lehetséges kimenetelei: - -> - Az EIP megfontolásra kerül egy következő hálózati fejlesztésnél -> - Technikai változásokat kérhetnek -> - Elutasításra kerülhet, ha nem prioritás vagy a fejlődés nem elég nagy a fejlesztési erőfeszítéshez képest - -3. **A javaslat iteratív további fejlesztése a végső verzió felé:** a releváns érdekeltektől jövő visszajelzések alapján valószínűleg változásokat kell eszközölni a kezdeti javaslaton, hogy biztonságosabb legyen vagy a felhasználók igényeit jobban kielégítse. Amint ezek a változások megvalósultak, újra be kell mutatni azt a protokollfejlesztőknek. Ekkor vagy tovább lehet lépni, vagy új kérdések merülnek fel, így tovább kell dolgozni a javaslaton. - -4. **Az EIP bekerül a hálózati frissítésbe**: feltéve, hogy a javaslat addigra átesik a jóváhagyáson, tesztelésen és bevezetésen, bele fog kerülni a következő rendszerfrissítésbe. Mivel ezeknek elég komoly a koordinációs költsége (mindenkinek egyszerre kell frissíteni), ezért az EIP-k csomagba kerülnek. - -5. **A hálózati frissítés aktiválása**: az aktiválás után az EIP élesedik az Ethereum hálózaton. _Megjegyzés: a hálózati frissítéseket általában a teszthálózaton aktiválják, mielőtt az Ethereum-főhálózatra kerülnének._ - -Ez az egyszerűsített folyamat betekintést ad a protokollváltoztatások főbb állomásaiba. Most nézzük meg az informális tényezőket, melyek mindezt befolyásolják. - -## Az informális folyamat {#informal-process} - -### A korábbi munkák megértése {#prior-work} - -Az EIP-bajnokoknak ismerni kell a korábbi munkákat és javaslatokat, mielőtt egy újat készítenek, hogy azt komolyan megfontolják egy Ethereum-fejlesztéseként. Így az EIP javaslat újdonságot hozhat, nem pedig egy korábban már elutasított dolgot. Három fő helyen kell átnézni az anyagokat: [EIP-könyvtár](https://github.com/ethereum/EIPs), [Ethereum Magicians](https://ethereum-magicians.org/) és [ethresear.ch](https://ethresear.ch/). - -### Munkacsoportok {#working-groups} - -Az EIP kezdeti javaslata változtatások nélkül nem valószínű, hogy végigmegy a bevezetésig. Általában az EIP-bajnokok a protokollfejlesztők egy kis csoportjával dolgoznak együtt, hogy specifikálják, létrehozzák, teszteljék és véglegesítsék a javaslatot. Korábban ezek a munkacsoportok számos hónapot (néha éveket) dolgoztak a javaslatokon. Az EIP-bajnokok emellett be kell vonják a releváns alkalmazás- vagy eszközfejlesztőket, hogy a felhasználóktól is tudjanak visszajelzést kapni, illetve csökkentsék a megvalósítás kockázatát. - -### Közösségi konszenzus {#community-consensus} - -Miközben néhány EIP egyértelmű technikai fejlesztés, addig mások komplexek és olyan kompromisszumokat kívánnak meg, melyek a különféle érdekeltek másképpen érintik. Tehát néhány javaslat több vitát vált ki. - -Nincs egyértelmű kézikönyv, hogy a vitás javaslatokat hogyan kezeljék. Az Ethereum decentralizált dizájnjának eredménye, hogy egyetlen érdekcsoport sem nyomhat el egy másikat: a protokollfejlesztők dönthetnek úgy, hogy nem fejlesztenek le egy kódváltoztatást; a csomópont-operátorok nem használják a legújabb Ethereum-klienst; az alkalmazásokat készítő csoportok és felhasználók pedig nem használják a hálózatot. Mivel a protokollfejlesztők nem tudják kényszeríteni az embereket a hálózati frissítések használatára, ezért általában elkerülik azokat a javaslatokat, ahol a vitatottság nagyobb, mint a nyilvánvaló előnyök. - -Az EIP-bajnokoknak minden releváns érdekelttől visszajelzést kell kérniük. Ha egy vitatottabb EIP-ről van szó, akkor meg kell próbálni az ellenvetéseket sorban átbeszélni, hogy konszenzus tudjon kialakulni. Az Ethereum-közösség méretét és diverzitását tekintve nincs egy mértéke a közösség konszenzusának, ezért a fejlesztési javaslatot a körülményekhez igazítva kell kezelni. - -Az Ethereum-hálózat biztonságán túl rendkívül fontos az, hogy miként vélekednek a protokollfejlesztők, az alkalmazás-/eszközfejlesztők és az alkalmazások felhasználói, mert az ő közreműködésük és munkájuk teszi vonzóvá ezt az ökoszisztémát. Emellett az EIP-ket az összes kliensen végig kell vezetni, amit különböző csapatok végeznek. Tehát meg kell győzni a protokollfejlesztők számos csapatát, hogy az adott változás értékes, segíti a felhasználókat vagy biztonsági problémát old meg. - - - -## A nézeteltérések kezelése {#disagreements} - -Mivel ennyiféle érdekelt van különböző motivációkkal és hitekkel, ezért a nézeteltérés nem ritka. - -Általában a nézeteltéréseket hosszú egyeztetéseken kezelik nyilvános fórumokon, hogy a probléma gyökerét megtalálják és azt mindenki meg tudja fontolni. Általában az egyik fél engedményt tesz vagy egy örömteli középutat találnak. Ha az egyik csoport egy adott változást áterőltet a rendszeren, akkor a lánc kettéválhat. Amikor az érdekeltek egy része kifogásol egy változást, így a protokollnak egy eltérő, nem kompatibilis verziói működnek, melyekből két blokklánc emelkedik ki. - -### A DAO elágazás {#dao-fork} - -Az elágazások akkor jönnek létre, amikor komoly technikai változások történnek a hálózaton és megváltoztatják a protokoll szabályait. Az [Ethereum-klienseknek](/developers/docs/nodes-and-clients/) frissíteni kell a szoftverjét, hogy az új elágazási szabályokat életbe léptessék. - -A DAO-elágazás volt a válasz egy [2016-os DAO-támadásra](https://www.coindesk.com/understanding-dao-hack-journalists), amikor egy sebezhető [DAO](/glossary/#dao) szerződésből 3,6 millió ETH-t ürítettek le a támadás során. Az elágazás a pénzeszközöket a hibás szerződésből egy újba tette át, hogy a támadás során károsultak kaphassanak belőle. - -Ennek az akciónak a kezelését megszavazták az Ethereum közösségen belül. Bármely ETH tulajdonos szavazhatott egy tranzakción keresztül [egy szavazási platformon](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/). Az elágazás mellett több mint a szavazók 85%-a voksolt. - -Fontos megjegyezni, hogy miközben a protokoll tényleg elágazott, hogy visszafordítsa a támadást, a szavazás súlya megkérdőjelezhető: - -- A szavazók száma rendkívül alacsony volt -- A legtöbben nem tudták, hogy szavazás történt -- A szavazást csak ETH-val rendelkezők végezték, a rendszer többi résztvevője nem vett részt - -A közösség ezen része elutasította az elágazást, főleg, mert az incidenst nem a protokollnak tulajdonították. Ők ezután létrehozták az [Ethereum Classicot](https://ethereumclassic.org/). - -Ma az Ethereum közössége a beavatkozásmentesség szabályát követi a hibás szerződések vagy elveszett pénzek esetén, hogy megtartsák a rendszer hihető semlegességét. - -Bővebben a DAO-támadásról: - - - - - -### Az elágazás hasznossága {#forking-utility} - -Az Ethereum/Ethereum Classic elágazás egy kiváló példája az egészséges elágazásnak. A két csoport elég nagy mértékben nem értett egyet egymással az alapvető értékek tekintetében, hogy megérte a kockázatot, hogy a saját útjukat kövessék. - -Az elágazás lehetősége a jelentős politikai, filozófiai vagy gazdasági különbségek esetén az Ethereum-irányítás sikerének fontos része. Az elágazás lehetősége nélkül az alternatívák folyamatosan ütköztek, részvételre kényszerítve a vonakodókat, akik később végül létrehozták az Ethereum Classicot, és egy teljesen más vízióval rendelkeztek arról, hogy az Ethereum sikere miben áll. - - - -## Beacon-lánc irányítása {#beacon-chain} - -Az Ethereum-irányítási folyamat gyakran a gyorsaság és a hatékonyság rovására a nyitottságot és a bevonódást hangsúlyozza. A Beacon-lánc fejlesztésének meggyorsítása érdekében ezt a proof-of-work Ethereum-hálózattól külön hozták létre, és a maga irányítási gyakorlatát követte. - -Miközben a specifikáció és a fejlesztés teljesen nyitott volt, a hivatalos fejlesztési folyamat nem követte a fenti lépéseket. Így a kutatók és a fejlesztők gyorsabban meg tudtak egyezni a specifikus változtatásokon. - -Amikor a Beacon-lánc egyesült az Ethereum végrehajtási réteggel 2022. szeptember 15-én, a Merge teljesült a [Paris hálózati frissítés](/history/#paris) részeként. Az [EIP-3675](https://eips.ethereum.org/EIPS/eip-3675) javaslat státusza véglegesre változott befejezve az átállást a proof-of-stake mechanizmusra. - - - A beolvadásról bővebben - - - - -## Hogyan lehet részt venni? {#get-involved} - -- [Javasoljon egy EIP-t](/eips/#participate) -- [Vitassa meg a jelenlegi javaslatokat](https://ethereum-magicians.org/) -- [Vegyen részt az R&D beszélgetéseken](https://ethresear.ch/) -- [Csatlakozzon az Ethereum R&D Discord csatornához](https://discord.gg/mncqtgVSVw) -- [Csomópont futtatása](/developers/docs/nodes-and-clients/run-a-node/) -- [Vegyen részt a kliensfejlesztésekben](/developers/docs/nodes-and-clients/#execution-clients) -- [Protokollfejlesztő gyakornoki program](https://blog.ethereum.org/2021/09/06/core-dev-apprenticeship-second-cohort/) - -## További olvasnivaló {#further-reading} - -Az Ethereumban az irányítás nincs szigorúan definiálva. A közösség különféle tagjainak eltérő perspektívái vannak ezzel kapcsolatban. Néhány ezek közül: - -- [Megjegyzések a blokkláncirányításról](https://vitalik.eth.limo/general/2017/12/17/voting.html) – _Vitalik Buterin_ -- [Hogyan működik az Ethereum irányítása?](https://cryptotesters.com/blog/ethereum-governance) – _Cryptotesters_ -- [Hogyan működik az Ethereum irányítása](https://medium.com/coinmonks/how-ethereum-governance-works-71856426b63a) – _Micah Zoltu_ -- [Kik az az Ethereum protokollfejlesztői?](https://hudsonjameson.com/2020-06-22-what-is-an-ethereum-core-developer/) – _Hudson Jameson_ -- [Irányítás, 2. rész: A plutokrácia még mindig rossz](https://vitalik.eth.limo/general/2018/03/28/plutocracy.html) – _Vitalik Buterin_ -- [Túl az érmealapú szavazásra épülő irányításon](https://vitalik.eth.limo/general/2021/08/16/voting3.html) – _Vitalik Buterin_ diff --git a/public/content/translations/hu/09) Learn Pages/security/index.md b/public/content/translations/hu/09) Learn Pages/security/index.md deleted file mode 100644 index d339da19853..00000000000 --- a/public/content/translations/hu/09) Learn Pages/security/index.md +++ /dev/null @@ -1,295 +0,0 @@ ---- -title: Ethereum-biztonság és átverés elleni védelem -description: Biztonságban az Ethereumon -lang: hu ---- - -# Ethereum-biztonság és átverés elleni védelem {#introduction} - -A kriptopénzek iránti növekvő érdeklődés egyre nagyobb kockázatot jelent a csalók és a hackerek részéről. Ez a cikk néhány bevált gyakorlatot mutat be e kockázatok mérséklésére. - -**Ne feledje: Az ethereum.org sosem lép Önnel kapcsolatba. Ne válaszoljon azokra az e-mailekre, amelyek azt állítják, hogy az Ethereum hivatalos támogatói csapatától érkeznek.** - - - -## Kriptobiztonság 101 {#crypto-security} - -### Növelje tudását {#level-up-your-knowledge} - -A kriptográfia működésével kapcsolatos félreértések költséges hibákhoz vezethetnek. Ha például valaki ügyfélszolgálati ügynöknek adja ki magát, aki a privát kulcsokért cserébe vissza tudja adni az elveszett ETH-t, akkor kihasználja azokat az embereket, akik nem értik, hogy az Ethereum egy decentralizált hálózat, amelyből hiányzik ez a fajta funkció. Az Ethereum működésének megértése megéri a befektetést. - - - Mi az Ethereum? - - - - Mi az ether? - - - -## Tárcabiztonság {#wallet-security} - -### Sose ossza meg privát kulcsait {#protect-private-keys} - -**Soha, semmilyen okból se ossza meg a privát kulcsait!** - -A tárca privát kulcsa az Ethereum-tárca jelszava. Ez az egyetlen dolog, aminek a hiányában valaki nem viszi el az összes eszközt a tárcájából, ha ismeri annak a címét! - - - Mi az az Ethereum tárca? - - -#### Sose készítsen képernyőképet a kulcsmondatról/privát kulcsokról {#screenshot-private-keys} - -A képernyőkép készítésével azt kockáztatja, hogy az szinkronizálódik a felhőbe és így elérhetővé válik a támadók számára. A privát kulcsok megszerzése a felhőből egy tipikus támadási forma. - -### Használjon hardveres tárcát {#use-hardware-wallet} - -A hardveres tárca offline módon tárolja a privát kulcsokat. Ez a legbiztonságosabb tárca a privát kulcsok tárolására: a kulcs sosem kapcsolódik az internethez és teljesen helyben marad az eszközén. - -A privát kulcsok offline tartása komoly szinten csökkenti a támadás kockázatát, még ha egy támadó hozzá is fér a számítógépéhez. - -#### Próbálja ki a hardveres tárcát: {#try-hardware-wallet} - -- [Ledger](https://www.ledger.com/) -- [Trezor](https://trezor.io/) - -### Ellenőrizze kétszer a tranzakciókat küldés előtt {#double-check-transactions} - -A rossz tárcába küldött kripto egy tipikus hiba. **Az Ethereumon küldött tranzakció visszafordíthatatlan.** Hacsak nem ismeri a cím tulajdonosát és nem tudja meggyőzni arról, hogy visszaküldje, különben nem tudja visszaszerezni azt. - -Mindig győződjön meg arról, hogy cím pontosan egyezik a kívánt címmel, mielőtt elküldi a tranzakciót. Az okosszerződésekkel való interakciónál is mindig olvassa el a tranzakcióüzenetet, mielőtt aláírja azt. - -### Állítson be költségkeretet az okosszerződéshez {#spend-limits} - -Az okosszerződéseknél ne engedjen korlátlan költési keretet. A korlátlan költés megengedi az okosszerződésnek, hogy kiürítse az Ön tárcáját. Ehelyett állítsa be pontosan azt az összeget, ami a tranzakcióhoz szükséges. - -Számos Ethereum-tárca kínál védelmet keretek beállításával, hogy ne lehessen kiüríteni a tárcát. - -[Hogyan vonható vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez](/guides/how-to-revoke-token-access/) - - - -## Gyakori csalások {#common-scams} - -Nem lehet őket teljesen megállítani, de elérhetjük, hogy kevésbé hassanak ránk, ha ismerjük a legjellemzőbb fogásaikat. Ezeknek a csalásoknak számos variációja van, de általánosságban egy mintát követnek. Emlékezzen rá: - -- mindig legyen szkeptikus -- senki sem ad Önnek ETH-t ingyen vagy olcsón -- senkinek se adja meg a privát kulcsait vagy a személyes információit - -### Twitter-hirdetéses adathalászat {#ad-phishing} - -![Twitter-hivatkozásos adathalászat](./twitterPhishingScam.png) - -Van egy módszer a Twitter (vagyis X) hivatkozás előnézeti funkciójának (kibontása) meghamisítására, amellyel potenciálisan megtéveszthetik a felhasználókat, hogy azt higgyék, egy legitim webhelyet látogatnak meg. Ez a technika a Twitter mechanizmusát használja ki a tweetekben megosztott URL-ek előnézetének létrehozására, és például azt mutathatja, hogy az az _ethereum.org_-tól származik (ahogy a fenti képen), miközben egy rosszindulatú webhelyre irányítja át. - -Mindig ellenőrizze, hogy a megfelelő oldalon van-e, különösen egy hivatkozásra kattintás után. - -[További információk itt](https://harrydenley.com/faking-twitter-unfurling). - -### Ajándékozási csalás {#giveaway} - -Az egyik legtipikusabb csalás a kriptovalutákkal az ajándékozás. Számos formában előfordulhat, de a lényege az, hogy ha Ön ETH-t küld a megadott tárcacímre, akkor duplán kapja vissza az ETH-t. *Emiatt 2-t 1-ért csalásnak is nevezik.* - -Ez az ajánlat csak limitált időre szól, hogy a sürgetés érzését keltse. - -### Közösségimédia-csalások {#social-media-hacks} - -Ennek nagy horderejű esete például 2020. júliusában volt, amikor híres emberek és szervezetek Twitterjét támadták meg. A támadó bitcoin-ajándékozást hirdetett ezeken a számlákon. Habár a megtévesztő üzeneteket gyorsan észrevették és törölték, a támadók még így is szereztek 11 bitcoint (ami 500 000 USD-nek felel meg a 2021. szeptemberi árfolyamon). - -![Csalás a Twitteren](./appleTwitterScam.png) - -### Hírességek ajándékoznak {#celebrity-giveaway} - -A hírességek által kommunikált ajándékozás is tipikus. A csalók egy videóinterjút vagy konferenciabeszélgetést úgy tesznek fel a YouTube-ra, mintha élőben menne, és ennek részeként a híresség egy kriptovaluta-ajándékozást hirdet meg. - -Vitalik Buterint és a kriptóban érintett más személyeket (pl. Elon Musk vagy Charles Hoskinson) gyakran használnak így. Ez adja a csalás valódiságának látszatát (furcsa, de ha Vitalik mondja, akkor biztos úgy van!). - -**Az ajándékozások mindig csalások. Ha bármilyen pénzt küld ezekre a felhívásokra, azt elveszíti.** - -![Csalás a YouTube-on](./youtubeScam.png) - -### Támogatási csalások {#support-scams} - -A kriptovaluta egy viszonylag fiatal és félreértett technológia. Ezt használja ki az a csalás, amikor ügyfélszolgálatosnak adják ki magukat a népszerű tárcák, tőzsdék vagy blokkláncok kapcsán. - -Az interakciók többsége Discordon történik. A támogatást színlelő csalók ezeken a csatornákon keresik azokat, akiknek kérdésük van, majd privát üzenetet küldenek nekik, hogy felajánlják segítségüket. Ráveszik a felhasználót, hogy bízzon meg bennük, majd megszerzik a privát kulcsaikat vagy pénzt küldenek a saját tárcájukba. - -![Támogatást ajánló csalás a Discordon](./discordScam.png) - -Általános szabály, hogy senki sem kommunikál Önnel privát, nem hivatalos csatornákon. Ezeket tartsa észben, ha támogatásról van szó: - -- Sose adja meg a privát kulcsait, kulcsmondatát vagy jelszavait -- Sose engedje, hogy bárki távolról hozzáférjen a gépéhez -- Sose kommunikáljon senkivel a szervezet dedikált csatornáin kívül - - -
- Legyen tudatában: hogy a támogatást ajánló csalók gyakran a Discordon jelennek meg, de bármilyen kommunikációs formában ott lehetnek, legyen az chat vagy email. -
- - -### „ETH2” hamis token {#eth2-token-scam} - -[Az egyesítés (The Merge)](/roadmap/merge/) közeledtével a csalók kihasználták a zavart az „ETH2” kifejezés körül és próbálták rávenni a felhasználókat, hogy váltsák át az ETH-t „ETH2”-re. Nem létezik ETH2, és a Merge sem vezetett be semmilyen tokent. A Merge előtt és után pontosan ugyanaz az ETH létezik. **Az ETH-val kapcsolatban semmit se kellett tenni a felhasználóknak, amikor a rendszer proof-of-work helyett proof-of-stake mechanizmusra állt át**. - -A csalók ügyfélszolgálatosként jelennek meg, hogy rávegyék Önt, adja át az ETH-t és „ETH2”-t kap helyette. Nincs [hivatalos Ethereum-ügyfélszolgálat](/community/support/), és nincs új token. Sose ossza meg a tárcához kapcsolódó kulcsmondatot senkivel. - -_Megjegyzés: Vannak olyan származékos tokenek, amelyek letétbe helyezett ETH-t képviselnek (pl. rETH a Rocket Pooltól, stETH a Lidotól, ETH2 a Coinbase-től), de ezekre nem kell átállnia._ - -### Adathalász csalások {#phishing-scams} - -Az adathalász csalások is egyre gyakoribbak, hogy a csalók ellopják a tárcák tartalmát. - -Néhány ilyen e-mail arra kéri a felhasználót, hogy bizonyos hivatkozásra kattintva lépjen egy weboldalra, adja meg a kulcsmondatát, kérjen új jelszót vagy küldjön ETH-t. Mások olyan rosszindulatú programokat telepítenek a gépére, amivel a csalók hozzáférnek a fájljaihoz. - -Ha egy ismeretlen küldőtől kap üzenetet, akkor: - -- Sose nyisson meg hivatkozást vagy csatolmányt ismeretlen feladótól -- Sose árulja el személyes adatait vagy jelszavait senkinek -- Törölje az ismeretlen feladóktól érkező e-maileket - -[Bővebben az adathalász csalások elkerüléséről](https://support.mycrypto.com/staying-safe/mycrypto-protips-how-not-to-get-scammed-during-ico) - -### Kriptobrókeres csalás {#broker-scams} - -A kriptobrókeres csalók szakembereknek adják ki magukat, akik elkérik az Ön pénzét, hogy befektessék az Ön nevében. Miután megkapták az összeget, lehetséges, hogy még többet kérnek valamilyen különleges lehetőségre, vagy akár el is tűnnek azonnal. - -Ezek a csalók hamis profilokat használnak a YouTube-on, ahol látszólag semleges beszélgetéseket folytatnak. Ezek a beszélgetések nagyon jó értékeléssel rendelkeznek, de ezt mind programok (bot) szavazzák meg nekik, hogy így hitelesebbnek tűnjenek. - -**Sose bízzon meg idegeneket az interneten, hogy befektessék a pénzét. El fogja veszíteni a kriptóját.** - -![Brókeres csalás a YouTube-on](./brokerScam.png) - -### Kriptobányászati csalások {#mining-pool-scams} - -2022. szeptembere óta nincs az Ethereumon bányászás. A csalások mégis tovább folytatódnak. A kriptobányászási csalásoknál arra próbálják rávenni az embereket, hogy csatlakozzanak az Ethereum-bányászathoz, ami nagy jövedelmeket hoz. A csaló kapcsolatban marad Önnel egész végig. Valójában meggyőzi Önt arról, hogy ha csatlakozik a bányászáshoz, akkor az ETH egyenlege még több ETH-t hoz létre. Ezután látni fogja, hogy a kriptovalutája kis hozamot termel. De ez csak azért van, hogy még többet fektessen be. Végül az összes pénzeszközét egy ismeretlen címre küldik, és a csaló eltűnik, vagy akár kapcsolatban is maradhat áldozatával. - -Tartózkodjon azoktól, akik a közösségi médiában be akarják Önt vonni a bányászatba. Ha elveszíti a kriptóját, az többé nem kerül vissza. - -Ne feledje: - -- Legyen óvatos, ha bárki még több pénzt akar csinálni a kriptójából -- Nézze meg a lehetőségeket a letétbe helyezés, likviditási alapok és más befektetések kapcsán -- Az ilyen ajánlatok szinte sose valósak. Ha azok lennének, akkor mindenki ezt követné és ezért már hallott volna róla. - -[Egy ember 200 000 USD-t vesztett egy kriptobányászási csalásban](https://www.reddit.com/r/CoinBase/comments/r0qe0e/scam_or_possible_incredible_payout/) - -### Tokenkiosztási (airdrop) csalások {#airdrop-scams} - -A tokenkiosztási (airdrop) csalások során egy hamis projekt eszközt (NFT, token) dob az Ön tárcájába és egy hamis weboldalra küldi, hogy kérvényezze azokat. Így be kell jelentkeznie az Ethereum-tárcájába és jóváhagynia a tranzakciót. Ez a tranzakció veszélybe sodorja a számláját, mivel a nyilvános és privát kulcsait átadja a csalónak. Az is lehet, hogy egy olyan tranzakciót ír alá, ami a csalónak küldi az Ön pénzeszközeit. - -[Bővebben a tokenkiosztási (airdrop) csalásokról](https://www.youtube.com/watch?v=LLL_nQp1lGk) - - - -## Webbiztonság 101 {#web-security} - -### Használjon erős jelszavakat {#use-strong-passwords} - -[A számlatámadások 80%-a a gyenge vagy ellopott jelszavakból ered](https://cloudnine.com/ediscoverydaily/electronic-discovery/80-percent-hacking-related-breaches-related-password-issues-cybersecurity-trends/). Egy hosszú, betűkből, számokból és szimbólumokból álló sorozat segíthet abban, hogy a számlája biztonságban legyen. - -Gyakori hiba, hogy néhány gyakori, összefüggő szó kombinációját használjuk. Az ehhez hasonló jelszavak nem biztonságosak, mert hajlamosak egy hackelési technikára, amelyet szótáralapú támadásnak hívnak. - -```md -Gyenge jelszó például: AranyosBolyhosCicák! - -Erős jelszó például: ymv\*azu.EAC8eyp8umf -``` - -A másik általános hiba az, amikor a [közösségi média alapján kitalálható](https://wikipedia.org/wiki/Social_engineering_(security)) jelszót találnak ki. Az édesanyja leánykori neve, a gyerekek vagy háziállatok nevei, a születési időpontok használata növeli a támadás kockázatát. - -#### A jó jelszóhoz: {#good-password-practices} - -- Olyan hosszú jelszót válasszon, amit jelszógenerátor készít vagy megenged az adott rendszer -- Használjon nagybetűt, kisbetűt, számokat és jeleket -- Ne használjon személyes adatokat, mint családi nevek -- Kerülje a gyakori, általános szavakat - -[Bővebben az erős jelszó létrehozásáról](https://terranovasecurity.com/how-to-create-a-strong-password-in-7-easy-steps/) - -### Használjon egyedi jelszót mindenre {#use-unique-passwords} - -Egy erős jelszó, amely egy adatvédelmi incidens során nyilvánossá vált, már nem számít erős jelszónak. A [Have I Been Pwned](https://haveibeenpwned.com) weblap megmutatja, hogy a számláját érintette-e bármilyen nyilvános adatvédelmi incidens. Ha igen, akkor **azonnal cserélje le a jelszavait**. Az egyedi jelszavak használata csökkenti annak kockázatát, hogy a támadó mindenhez hozzáfér, ha egy jelszót feltör. - -### Használjon jelszókezelőt {#use-password-manager} - - -
- A jelszókezelő erős, egyedi jelszavakat hoz létre és meg is jegyzi azokat! Erősen ajánljuk, hogy használjon ilyet, és a legtöbb ingyen van! -
- - -Az erős, egyedi jelszavakat nem túl ideális megjegyezni az összes számlához. A jelszókezelő egy biztonságos, titkosított tárhelyet biztosít az összes jelszónak, amit egy erős mesterjelszóval tud elérni. Az új szolgáltatásokra való bejelentkezéseknél is erős jelszavakat ajánl, így Önnek nem kell kitalálnia azt. Számos jelszókezelő azt is megmondja, hogy Ön érintett-e adatszivárgásban, így lecserélheti a jelszavait, mielőtt támadás érné. - -![Példa a jelszókezelő használatára](./passwordManager.png) - -#### Próbáljon ki egy jelszókezelőt: {#try-password-manager} - -- [Bitwarden](https://bitwarden.com/) -- [KeePass](https://keepass.info/) -- [1Password](https://1password.com/) -- Emellett más [javasolt jelszókezelőket](https://www.privacytools.io/secure-password-manager) is megtekinthet - -### Használjon kéttényezős azonosítást {#two-factor-authentication} - -Előfordulhat, hogy arra kérik Önt, hogy egyedi igazolásokkal hitelesítse személyazonosságát. Ezeket nevezzük **tényezőknek**. A három fő tényező a következő: - -- Valami, amit tud (mint egy jelszó vagy biztonsági kérdés) -- Valami, ami Öntől származik (mint egy ujjlenyomat vagy írisz-/arcszkenner) -- Valami, ami az Ön birtokában van (biztonsági kulcs vagy azonosítási alkalmazás a telefonján) - -A **kétfaktoros hitelesítés (2FA)** használata további *biztonsági tényezőt* biztosít online számlái számára. A 2FA biztosítja, hogy a számlához való hozzáféréshez nem elegendő pusztán a jelszó megléte. Általában a második tényező egy véletlenszerű hatjegyű kód, ami egy **időzített egyszeri jelszó (TOTP)**, amit egy azonosítási alkalmazással ér el, mint a Google Authenticator vagy Authy. Ez az a tényező, ami az Ön birtokában van, mert a kódot adó mag az Ön eszközén található. - - -
- Megjegyzés: az SMS-alapú 2FA azonosítás ki van téve a SIM jacking támadásnak, ezért nem biztonságos. A legmagasabb fokú biztonság érdekében használjon olyan szolgáltatást, mint a Google Authenticator vagy az Authy. -
- - -#### Biztonsági kulcsok {#security-keys} - -A biztonsági kulcs a 2FA egy fejlettebb és biztonságosabb típusa. A biztonsági kulcsok fizikai, hardveralapú hitelesítési eszközök, melyek az azonosítási alkalmazásokként működnek. A biztonsági kulcs használata a legbiztonságosabb mód a 2FA eléréséhez. A kulcsok nagyrésze a FIDO egyetemes második tényező (U2F) szabványt használja. [Ismerje meg a FIDO U2F-t](https://www.yubico.com/authentication-standards/fido-u2f/). - -Tudjon meg többet a 2FA-ról: - - - -### Böngészőbővítmények eltávolítása {#uninstall-browser-extensions} - -A böngészőbővítmények (mint a Chrome-bővítmények vagy Firefox kiegészítő modulok) hasznos funkciókkal egészítik ki a böngészőket, de kockázattal is járnak. A legtöbb ilyen bővítmény kéri, hogy beolvashassa és megváltoztathassa az adatokat, így bármit meg tudnak tenni az eszközön. A Chrome bővítményei automatikusan frissülnek, ezért a korábban ártalmatlan kód később talán rosszindulatú részeket is tartalmazhat. A legtöbb böngészőbővítmény nem próbál meg adatot lopni, de attól még képes rá. - -#### Maradjon biztonságban: {#browser-extension-safety} - -- Csak megbízható forrásból telepítsen bővítményeket -- Szedje le azokat, amelyeket nem használja -- Telepítse a bővítményt lokálisan, így nem fog magától frissülni - -[Bővebben a böngészőbővítmények kockázatáról](https://www.kaspersky.co.uk/blog/browser-extensions-security/12750/) - - - -## További olvasnivaló {#further-reading} - -### Webbiztonság {#reading-web-security} - -- [3 millió eszközt érintenek a rosszindulatú Chrome- és Edge-bővítmények](https://arstechnica.com/information-technology/2020/12/up-to-3-million-devices-infected-by-malware-laced-chrome-and-edge-add-ons/) – _Dan Goodin_ -- [Hogyan hozzon létre erős jelszót – amit nem felejt el](https://www.avg.com/en/signal/how-to-create-a-strong-password-that-you-wont-forget) – _AVG_ -- [Mi az a biztonsági kulcs?](https://help.coinbase.com/en/coinbase/getting-started/verify-my-account/security-keys-faq) – _Coinbase_ - -### Kriptobiztonság {#reading-crypto-security} - -- [Védje magát és a pénzeszközeit](https://support.mycrypto.com/staying-safe/protecting-yourself-and-your-funds) – _MyCrypto_ -- [Biztonsági problémák az általános kriptokommunikációs szoftverben](https://docs.salusec.io/untitled/web3-penetration-test/risks-in-social-media) – _Salus_ -- [Biztonsági útmutató kezdőknek és haladóknak](https://medium.com/mycrypto/mycryptos-security-guide-for-dummies-and-smart-people-too-ab178299c82e) – _MyCrypto_ -- [Kriptobiztonság: jelszavak és azonosítás](https://www.youtube.com/watch?v=m8jlnZuV1i4) – _Andreas M. Antonopoulos_ - -### Csalásfelismerés {#reading-scam-education} - -- [Útmutató: hogyan azonosítsa be a hamis tokeneket](/guides/how-to-id-scam-tokens/) -- [Maradjon biztonságban: általános csalások](https://support.mycrypto.com/staying-safe/common-scams) – _MyCrypto_ -- [A csalások elkerülése](https://bitcoin.org/en/scams) – _Bitcoin.org_ -- [Twitter-beszélgetés a tipikus kripto-adathalász e-mailekről és üzenetekről](https://twitter.com/tayvano_/status/1516225457640787969) – _Taylor Monahan_ - - diff --git a/public/content/translations/hu/09) Learn Pages/zero-knowledge-proofs/index.md b/public/content/translations/hu/09) Learn Pages/zero-knowledge-proofs/index.md deleted file mode 100644 index 3d620f82a68..00000000000 --- a/public/content/translations/hu/09) Learn Pages/zero-knowledge-proofs/index.md +++ /dev/null @@ -1,214 +0,0 @@ ---- -title: Felfedés nélküli bizonyítás -description: A zero-knowledge bizonyítékok nem technikai bemutatása kezdők számára. -lang: hu ---- - -# Mik azok a zero-knowledge (nullaismeret-alapú) bizonyítékok? {#what-are-zk-proofs} - -A zero-knowledge bizonyíték annak módja, hogy egy állítás érvényességét úgy igazoljuk, hogy magát az állítást nem fedjük fel. A bizonyító próbálja az állítást elfogadtatni, miközben az ellenőrző felelős annak validálásáért. - -A zero-knowledge bizonyíték először egy 1985-ös, „[Az interaktív bizonyítási rendszerek ismereti komplexitása](http://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Proof%20Systems/The_Knowledge_Complexity_Of_Interactive_Proof_Systems.pdf)” című tanulmányban jelent meg, mely a zero-knowledge bizonyítékok ma is használt definícióját adja: - -> A nulla tudás protokoll egy olyan módszer, amellyel az egyik fél (a bizonyító) **bizonyíthatja** egy másik félnek (az ellenőrző), **hogy valami igaz, anélkül, hogy bármilyen információt felfedne** az a tény, hogy ez a konkrét állítás igaz. - -A zero-knowledge bizonyítékok az elmúlt években tovább fejlődtek, és ma már számos valódi alkalmazásban használjuk ezeket. - - - -## Miért kellenek a zero-knowledge bizonyítékok? {#why-zero-knowledge-proofs-are-important} - -A zero-knowledge bizonyítékok az alkalmazott kriptográfia egyik áttörése, mivel az egyének számára jobb információbiztonságot ígérnek. Gondoljon bele, hogyan bizonyít egy állítást (pl. „X ország állampolgára vagyok”) egy másik félnek (pl. egy szolgáltatásnyújtónak). Bizonyítékot kell adnia ahhoz, hogy az állítását alátámassza, mint az útlevelét vagy a vezetői engedélyét. - -Ennél azonban jelentős adatvédelmi kockázat áll fenn. A személyazonosításra alkalmas információk (PII), melyeket egy harmadik félnek ad át, központi adatbázisokban vannak tárolva, melyek sebezhetők a támadókkal szemben. Mivel a személyazonosság ellopása kritikus problémává válik, komolyabb adatvédelmi intézkedésekre van szükség a bizalmas információk megosztásánál. - -A nulla tudásalapú bizonyítások megoldják ezt a problémát azáltal, hogy **kiküszöböli az állítások érvényességének bizonyításához szükséges információk felfedését**. A zero-knowledge protokoll az állítást (amit tanúnak nevez) használja bemenetként, hogy egy tömör bizonyítványt állítson ki az érvényességéről. Ez a bizonyíték egy erős garanciát ad, hogy az állítás igaz, de nem tár fel semmit abból, amit ehhez felhasznált. - -A korábbi példánál maradva a nemzetiséget egyedül a zero-knowledge bizonyítékkal kell igazolnia. Az ellenőrző csak azt nézi meg, hogy a bizonyíték bizonyos jellemzői igazak, hogy meggyőződjön az állítás igaz voltáról. - -## A zero-knowledge bizonyítékok alkalmazási területei {#use-cases-for-zero-knowledge-proofs} - -### Anonim fizetések {#anonymous-payments} - -A bankkártyafizetések sokszor láthatók több fél számára is, beleértve a fizetési szolgáltatót, a bankokat és más érdekelteket (pl. kormányzati hatóságok). Míg a pénzügyi felügyeletnek vannak előnyei az illegális tevékenységek feltárásában, közben aláássa a hétköznapi emberek magánéletét. - -A kriptovalutákat arra szánták, hogy a felhasználók privát, egymás közötti (peer-to-peer) tranzakciókat hajthassanak végre. Ugyanakkor a legtöbb kriptovalutás tranzakció nyíltan látható a nyilvános blokkláncokon. A felhasználók személyazonosságai gyakran közvetettek és vagy direkt kapcsolódnak valós azonosságukhoz (pl. a Twitter vagy GitHub profil tartalmazza az ETH címüket), vagy összekapcsolhatók alapvető láncon belüli és kívüli adatok elemzésével. - -Vannak bizonyos privát tokenek, hogy teljesen anonim tranzakciókat lehessen végrehajtani. A privát jelleget védő blokkláncok, mint a Zcash és Monero, elfedik a tranzakciók adatait, mint a küldő/fogadó címe, az eszköz típusa, a mennyiség, az időpont. - -A nulla tudástechnológiát a protokollba beépítve az adatvédelemre fókuszáló [blokklánc](/glossary/#blockchain) hálózatok lehetővé teszik a [csomópontok](/glossary/#node) számára a tranzakciók érvényesítését anélkül, hogy hozzá kellene férniük a tranzakciós adatokhoz. - -**A nulla tudásalapú igazolásokat a nyilvános blokkláncokon folyó tranzakciók anonimizálására is alkalmazzák**. Erre a Tornado Cash a példa, ami egy decentralizált, nem felügyelt szolgáltatás, ami privát tranzakciókat tesz lehetővé az Ethereumon. Ez a megoldás zero-knowledge bizonyítékokat használ, hogy elfedje a tranzakció adatait és pénzügyi titoktartást garantál. Sajnos, mivel ezek tetszőlegesen választható adatvédő eszközök, ezért rögtön illegális tevékenységet sejtetnek. Ennek megoldására a privát jellegű adatok védelme végül alapvetővé kell váljon a nyilvános blokkláncokon. - -### A személyazonosság védelme {#identity-protection} - -A jelenlegi személyazonosságot kezelő rendszerek veszélyeztetik a személyes információkat. A zero-knowledge bizonyítékok segíthetnek az egyéneknek azonosítani magukat, miközben megvédik az adataikat. - -Ezek kiemelten fontosak a [decentralizált személyazonosság](/decentralized-identity/) kontextusában. A decentralizált személyazonosság (vagy független személyazonosság) lehetővé teszi, hogy az egyén kontrollálja a személyes azonosítóihoz való hozzáférést. Az állampolgárság igazolása adóazonosító vagy útlevéladatok felfedése nélkül egy jó példa arra, hogy a zero-knowledge technológia hogyan teszi lehetővé a decentralizált személyazonosság-ellenőrzést. - -### Hitelesítés {#authentication} - -Az online szolgáltatások használatához igazolni kell a személyazonosságot és a hozzáférési jogot az adott platformhoz. Ez gyakran az olyan személyes adatok megadásával történik, mint név, e-mail-cím, születési dátum stb. Emellett hosszú jelszavakat kell megjegyezni, de a hozzáférés akár el is veszhet. - -A zero-knowledge bizonyítékok ugyanakkor leegyszerűsíthetik az azonosítást a platformok és a felhasználók számára is. Amint a ZK-bizonyíték elkészült a nyilvános inputok (pl. a platformtagságot tanúsító adat) és privát inputok (pl. a személy adatai) használatával, akkor a felhasználó egyszerűen azzal igazolja magát, amikor a szolgáltatást használni akarja. Ez javítja a felhasználói tapasztalatot, illetve mentesíti a szervezeteket, hogy nagy adag személyes információt tároljanak. - -### Igazolható kalkuláció {#verifiable-computation} - -Az igazolható kalkuláció egy másik alkalmazása a ZK technológiának, hogy fejlessze a blokklánc kialakítását. Az igazolható kalkuláció által a kalkulációt másik entitás is végezheti, miközben az igazolható eredményeket fenntartjuk. A másik fél átadja az eredményeket a bizonyítékkal együtt, ami igazolja, hogy a program megfelelően futott. - -Az ellenőrizhető számítások **kritikusak a blokkláncok feldolgozási sebességének javításához** a biztonság csökkentése nélkül. Ennek megértéséhez ismerni kell az Ethereum skálázási megoldásai közötti eltéréseket. - -[A láncon belüli skálázási megoldások](/developers/docs/scaling/#on-chain-scaling), mint amilyen a párhuzamos futtatás (sharding), nagy mértékű módosítást igényelnek a blokklánc alaprétegén. Ez a megközelítés ugyanakkor nagyon komplex, az bevezetés hibái pedig alááshatják az Ethereum biztonsági modelljét. - -[A láncon kívüli skálázási megoldásokhoz](/developers/docs/scaling/#off-chain-scaling) nem kell az Ethereum protokollt újratervezni. Ehelyett egy kiszervezett kalkulációs modellre támaszkodnak, hogy fejlesszék a tranzakcióátvitelt az Ethereum alaprétegen. - -Ez a gyakorlatban a következőképpen működik: - -- Az Ethereum nem dolgozza fel a tranzakciókat egyesével, hanem kirakja a végrehajtást egy másik láncra. - -- A tranzakciók feldolgozása után a másik lánc visszaküldi az eredményt, ami az Ethereum-státusz része lesz. - -Az Ethereumnak tehát nem kell feldolgozni semmit, csak az eredményeket kell beilleszteni. Ez csökkenti a hálózat leterheltségét és fejleszti a tranzakciós sebességet (a láncon kívüli protokoll gyorsabb végrehajtásra van optimalizálva). - -A láncnak szüksége van arra, hogy validálni tudja a láncon kívüli tranzakciókat anélkül, hogy újra feldolgozná azokat, különben a külső feldolgozás értéke elveszik. - -Itt jön a képbe az igazolható kalkuláció. Amikor egy csomópont feldolgoz egy tranzakciót az Ethereumon kívül, akkor egy zero-knowledge bizonyítékot ad, hogy bizonyítsa a láncon kívüli végrehajtás helyességét. Ez a bizonyíték ([érvényességi bizonyíték](/glossary/#validity-proof)) garantálja, hogy a tranzakció érvényes, így az Ethereum hozzáadhatja a lánc státuszához – anélkül, hogy bárki kifogásolhatná azt. - -[A zero-knowledge rollupok](/developers/docs/scaling/zk-rollups) és [a validiumok](/developers/docs/scaling/validium/) két olyan láncon kívüli, skálázási megoldás, amely érvényességi bizonyítékot ad, hogy a skálázás biztonságos legyen. Ezek a protokollok ezernyi tranzakciót dolgoznak fel láncon kívül és bizonyítékot adnak az Ethereumnak ellenőrzési célból. Amint a bizonyíték ellenőrzésre kerül, az eredményeket azonnal be lehet tenni a láncba, így az Ethereum több tranzakciót tud kezelni anélkül, hogy az alapréteg számítási kapacitását növelni kellene. - -### A vesztegetés és összejátszás lehetőségének csökkentése a láncon belüli szavazásnál {#secure-blockchain-voting} - -A blokklánc szavazási sémái számos kedvező vonással bírnak: teljesen auditálható, nem támadható, ellenáll a cenzúrának és nem kötik földrajzi megszorítások. De még ezek sem immunisak az **összejátszás** problémájára. - -Az összejátszás definíciója a nyílt verseny redukálása megtévesztéssel, csalással és félrevezetéssel, ami felöltheti a vesztegetés formáját, mellyel egy rosszhiszemű szereplő befolyásolni akar egy szavazást. Például Alice kaphat egy összeget Bobtól azért, hogy szavazzon a `B opcióra` egy titkos szavazáson, miközben ő maga az `A opciót` preferálja. - -A vesztegetés és összejátszás behatárolja a hatékonyságát azoknak a folyamatoknak, melyek a szavazást használják jelzőmechanizmusra (főleg amikor a felhasználók bizonyítani tudják, hogyan szavaztak). Ennek komoly következményei vannak, főleg ahol véges erőforrást allokálnak a szavazás révén. - -Például a [kvadratikus finanszírozási mechanizmus](https://www.radicalxchange.org/concepts/plural-funding/) adományokon alapszik, hogy mérje bizonyos opciók támogatottságát a különféle közjóra törekvő projektek között. Minden adomány szavazatként működik egy adott projektre, ahol a több szavazattal bíró projektek nagyobb részt kapnak a finanszírozási alapból. - -A láncon belüli szavazás kiteszi a kvadratikus finanszírozást az összejátszás kockázatának: a blokklánctranzakciók nyilvánosak, így a vesztegetők meg tudják nézni, hogy a megvesztegetett hogyan szavazott. Így a kvadratikus finanszírozás nem lesz hatékony módja a forráselosztásnak a közösség aggregált preferenciái alapján. - -Szerencsére újabb megoldások, mint amilyen a MACI (Minimum összejátszás-ellenes infrastruktúra/Minimum Anti-Collusion Infrastructure), zero-knowledge bizonyítékokat használ, hogy a láncon belüli szavazás ellenálló legyen a vesztegetéssel és összejátszással szemben. A MACI okosszerződésekből és szkriptekből áll, és lehetővé teszi egy központi adminisztrátor (a koordinátor) számára, hogy aggregálja a szavazatokat és kiszámolja az eredményeket, _anélkül_, hogy felfedné az egyéni szavazatok tartalmát. Még így is bizonyítani lehet, hogy a szavazatokat megfelelően számolták össze, illetve egy adott illető részt vette-e a szavazáson. - -#### Hogyan működik a MACI a zero-knowledge bizonyítékokkal? {#how-maci-works-with-zk-proofs} - -Először a koordinátor aktiválja a MACI szerződést az Ethereumon, majd a felhasználók jelentkezhetnek a szavazásra (regisztrálják a nyilvános kulcsukat az okosszerződésben). A felhasználók úgy szavaznak, hogy a nyilvános kulcsukkal titkosított üzenetet küldenek az okosszerződésnek (az érvényes szavazatot a legfrissebb nyilvános kulccsal kell aláírni, egyéb kritériumok mellett). Majd a koordinátor feldolgozza az összes üzenetet a szavazás lezárultával, megszámlálja azokat, és igazolja az eredményt a láncon. - -A MACI-ban a zero-knowledge bizonyítékok biztosítják a kalkuláció helyességét, így a koordinátor nem tudja azokat helytelenül feldolgozni és összesíteni. Ehhez a koordinátornak ZK-SNARK bizonyítékokat kell generálnia, hogy igazolja a) minden üzenetet megfelelően feldolgozott; b) a végső eredmény egyezik a _valid_ szavazatok számával. - -Így a MACI még a szavazatok felhasználónkénti megosztása nélkül is garantálja a számlálási folyamat során kiszámított eredmények integritását. Ez csökkenti az alapvető összejátszási sémák hatékonyságát. Megvizsgálhatjuk ezt a lehetőséget, ha felhasználjuk az előző példát, amikor Bob megvesztegette Alice-t, hogy egy opció mellett szavazzon: - -- Alice szavazásra jelentkezik, elküldve a nyilvános kulcsát az okosszerződésnek. -- Alice beleegyezik, hogy a `B opcióra` szavaz, és ezért Bob fizetni fog neki. -- Alice a `B opcióra` szavaz. -- Alice titokban küld egy titkosított tranzakciót, hogy megváltoztassa a személyazonosságához tartozó nyilvános kulcsot. -- Alice küld egy másik titkosított üzenetet az okosszerződésnek, hogy az `A opcióra` szavaz, az új nyilvános kulcsot használva. -- Alice megmutatja Bobnak a tranzakciót, melyben a `B opcióra` szavazott (ami érvénytelen, mert az a nyilvános kulcs már nem kapcsolódik Alice személyazonosságához a rendszerben) -- Miközben az üzeneteket dolgozza fel a koordinátor, kihagyja Alice szavazatát a `B opcióra` és beleszámolja azt, amit az `A opcióra` adott le. Így Bob próbálkozása, hogy összejátsszon Alice-szel és manipulálja a láncon belüli szavazást, kudarcot vallott. - -A MACI használatához ugyanakkor _muszáj_ megbízni a koordinátorban, hogy nem játszik össze másokkal vagy vesztegeti meg a szavazókat. A koordinátor képes feloldani az üzenetek titkosítását (ez kell a bizonyíték előállításához), így be tudja azonosítani, hogy ki hogyan szavazott. - -Ha a koordinátor jóhiszeműen jár el, akkor a MACI egy kiváló eszköz arra, hogy garantálja a láncon belüli szavazás szentesítését. Ez megmagyarázza a népszerűségét a kvadratikus finanszírozási alkalmazásokban (mint amilyen a [clr.fund](https://clr.fund/#/about/maci)), ami nagy mértékben függ az egyének szavazásának integritásától. - -[Bővebben a MACI-ról](https://privacy-scaling-explorations.github.io/maci/). - -## Hogyan működik a zero-knowledge bizonyíték? {#how-do-zero-knowledge-proofs-work} - -A zero-knowledge bizonyíték által úgy igazolódik egy állítás igazsága, hogy abból bármi kiderülne vagy abból a módból, ahogy az igazolva lett. Ehhez a zero-knowledge protokollok olyan algoritmusokat használnak, melyek adatokat dolgoznak fel és válaszként igaz vagy hamis eredményt adnak. - -A zero-knowledge protokollnak a következő kritériumoknak kell megfelelniük: - -1. **Teljesség**: ha az input érvényes, akkor a zero-knowledge protokoll válasza mindig az, hogy „igaz”. Tehát ha az állítás igaz, a bizonyító és az ellenőrző jóhiszeműen viselkedik, akkor a bizonyítékot el lehet fogadni. - -2. **Megbízhatóság**: ha az input érvénytelen, akkor elméletileg lehetetlen átverni a zero-knowledge protokollt, hogy azt „igaznak” vegye. Így a rosszhiszemű bizonyító nem tudja átverni a jóhiszemű ellenőrzőt, hogy elhiggye az érvénytelen állításról, hogy az érvényes (csak egy nagyon kicsi valószínűséggel). - -3. **Zero-knowledge**: Az ellenőrző semmit sem tud meg az állításról, csak azt, hogy érvényes vagy érvénytelen-e (nulla ismerete lesz az állításról). Ez megakadályozza, hogy az ellenőrző kinyerje az eredeti inputot (az állítás tartalmát) a bizonyítékból. - -Alapformájában a zero-knowledge bizonyíték három elemből áll: **tanú**, **kihívás** és **válasz**. - -- **Tanú**: A zero-knowledge bizonyítékkal a bizonyító valamilyen titkos információ ismeretét akarja bizonyítani. A titkos információ a bizonyíték „tanúja”, és az a tény, hogy a bizonyítónak feltételezett módon ismerete van erről a tanúról, egy sor kérdést generál, melyet csak az tud megválaszolni, aki ismeri az információt. A bizonyító a bizonyítási eljárást azzal kezdi, hogy véletlenszerűen választ egy kérdést, kikalkulálja a választ és elküldi az ellenőrzőnek. - -- **Kihívás**: Az ellenőrző véletlenszerűen választ egy kérdést a sorozatból, és megkéri a bizonyítót, hogy feleljen rá. - -- **Válasz**: A bizonyító elfogadja a kérdést, kikalkulálja a választ, és elküldi az ellenőrzőnek. A bizonyító válasza lehetővé teszi, hogy az ellenőrző meggyőződjön arról, az előbbi tényleg hozzáfér a tanúhoz. Ahhoz, hogy meggyőződjön arról, a bizonyító nem csak vakon tippel és véletlenül adta meg a jó választ, még több kérdést tesz fel. Ezt a folyamatot ismételve annak a valószínűsége, hogy a bizonyítónak nincs is ismerete a tanúról, szignifikánsan lecsökken, míg az ellenőrző elégedetté válik. - -A fenti egy interaktív zero-knowledge bizonyítékstruktúrát ír le. A korai zero-knowledge protokollok interaktív igazolást használtak, ami oda-vissza kommunikációt igényelt a bizonyító és az ellenőrző között. - -Ennek illusztrálására egy jó példa Jean-Jacques Quisquater híres [Ali Baba barlangtörténete](https://en.wikipedia.org/wiki/Zero-knowledge_proof#The_Ali_Baba_cave). A történetben Peggy (a bizonyító) bizonyítani akarja Victornak (az ellenőrzőnek), hogy tudja a titkos jelszót, ami kinyitja a varázsajtót, de nem akarja elárulni, mi az. - -### Nem interaktív zero-knowledge bizonyítékok {#non-interactive-zero-knowledge-proofs} - -Miközben forradalmi, az interaktív bizonyítás hasznossága behatárolt, mert a két félnek elérhetőnek kell lennie és többször kell kapcsolatba lépniük. Még akkor is, ha az ellenőrző meggyőződött a bizonyító őszinteségéről, a bizonyíték ekkor még nem lesz elérhető a független ellenőrzésre (egy új bizonyítékot kell küldeni, ami egy újabb üzenetváltás). - -Ennek megoldására Manuel Blum, Paul Feldman és Silvio Micali az első [nem interaktív zero-knowledge bizonyítékot](https://dl.acm.org/doi/10.1145/62212.62222) javasolta, ahol a bizonyító és az ellenőrző egy megosztott kulccsal rendelkezik. Ez lehetővé teszi a bizonyítónak, hogy az információ (a tanú) ismeretét úgy bizonyítsa, hogy nem adja ki azt. - -Az interaktívhoz képest itt csak egy kommunikáció történik a felek (bizonyító és ellenőrző) között. A bizonyító a titkos információt átadja egy speciális algoritmusnak, hogy az kikalkulálja a zero-knowledge bizonyítékot. Ezt elküldi az ellenőrzőnek, aki egy másik algoritmussal ellenőrzi azt, hogy a bizonyító tényleg ismeri a titkot. - -A nem interaktív bizonyítás lecsökkenti a szükséges kommunikációt, így a ZK-bizonyíték sokkal hatékonyabb. Sőt, a bizonyíték létrehozásával az mindenkinek elérhetővé válik (akinek van megosztott kulcsa és ellenőrző algoritmusa) ellenőrzésre. - -A nem interaktív bizonyítékok áttörést hoztak a ZK technológiának és a ma létező bizonyítórendszerek fejlesztését hozták el. Az alábbiakban áttekintjük ezeket a bizonyítéktípusokat: - -### A zero-knowledge bizonyítékok típusai {#types-of-zero-knowledge-proofs} - -#### ZK-SNARK-ok {#zk-snarks} - -ZK-SNARK a rövidítés a **zero-knowledge tömörített nem interaktív érv ismeretre (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge)**. A ZK-SNARK protokoll a következő jellemzőkkel bír: - -- **Zero-knowledge**: Az ellenőrző az állítás integritását úgy tudja ellenőrizni, hogy nem tud róla semmit. Csak arról van tudomása, hogy az állítás igaz vagy hamis. - -- **Tömörített**: A zero-knowledge bizonyíték kisebb a tanúnál és gyorsan ellenőrizhető. - -- **Nem interaktív**: A bizonyító és az ellenőrző csak egyszer kommunikál, miközben az interaktív bizonyítéknál több körben is egyeztetnek. - -- **Érv**: A bizonyíték kielégíti a megbízhatósági követelményt, így a csalás rendkívül valószínűtlen. - -- **Ismeret**: A bizonyíték nem rakható össze a titkos információ (tanú) ismerete nélkül. Nehéz vagy egyenesen lehetetlen egy bizonyító számára kikalkulálni egy érvényes ZK-bizonyítékot, ha nem ismeri a tanút. - -A korábban említett megosztott kulcs nyilvános paraméterekre hivatkozik, amelyekben a bizonyító és az ellenőrző megegyezik, hogy ezeket használja a bizonyíték létrehozásában és ellenőrzésében. A nyilvános paraméterek létrehozása (Common Reference String/CRS) egy kényes művelet, mivel a protokoll biztonsága múlik rajta. Ha a CRS-t létrehozó entrópia/véletlenszerűség egy rosszhiszemű bizonyító kezébe kerül, akkor hamis bizonyítékokat tud kalkulálni vele. - -[A többrésztvevős kalkuláció (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation) ezt a kockázatot csökkenti a nyilvános paraméterek létrehozása kapcsán. Több résztvevő van jelen egy [bizalmat igénylő összetételi ceremónián](https://zkproof.org/2021/06/30/setup-ceremonies/amp/), ahol mindenki hozzátesz véletlenszerű értékeket a CRS létrehozásához. Amíg egy jóhiszemű fél megsemmisíti az entrópia saját részét (így nem lehet teljesen összeállítani a sorozatot), addig a ZK-SNARK protokoll megőrzi a kalkulációs megbízhatóságát. - -A bizalmat igénylő összetétel esetén a felhasználónak bíznia kell a résztvevőkben, amikor azok létrehozzák a paramétereket. Ugyanakkor a ZK-STARK-ok kifejlesztése lehetővé tette a bizonyító protokolloknak, hogy bizalomigénytől mentes felállásban is működjenek. - -#### ZK-STARK-ok {#zk-starks} - -ZK-STARK a rövidítés a **zero-knowledge skálázható transzparens érv ismeretre (Zero-Knowledge Scalable Transparent Argument of Knowledge)**. A ZK-STARK-ok hasonlítanak a ZK-SNARK-okra, kivéve, hogy: - -- **Skálázható**: ZK-STARK gyorsabb, mint a ZK-SNARK a bizonyíték létrehozásában és ellenőrzésében, amikor a tanú nagyobb méretű. A STARK bizonyítékoknál a bizonyítás és az ellenőrzés ideje csak enyhén növekszik, ahogy a tanú mérete nő (míg a SNARK esetén a növekedés lineáris). - -- **Transzparens**: ZK-STARK nyilvánosan ellenőrizhető véletlenszerűségre támaszkodik, hogy létrehozza a nyilvános paramétereket a bizonyításhoz és az ellenőrzéshez, nem egy bizalmat igénylő összetételre. Ezért sokkal átláthatóbbak a ZK-SNARK-okhoz képest. - -ZK-STARK-ok nagyobb bizonyítékokat készítenek, mint a ZK-SNARK-ok, ezért magasabb az ellenőrzési költség. Ugyanakkor bizonyos esetekben (mint nagy adathalmazok bizonyítása) a ZK-STARK-ok mégis költséghatékonyabbak a ZK-SNARK-okhoz képest. - -## A zero-knowledge bizonyítékok hátulütői {#drawbacks-of-using-zero-knowledge-proofs} - -### Hardverköltségek {#hardware-costs} - -A zero-knowledge bizonyítékok generálása nagyon összetett kalkulációt igényel, amit specializált gépeken lehet a legjobban elvégezni. Mivel ezek drágák, ezért nem elérhetők a hétköznapi emberek számára. Emellett a technológiát használó alkalmazásoknak ezt a költséget bele kell kalkulálniuk az áraikba, így megnövelik a felhasználók költségeit is. - -### A bizonyíték ellenőrzésének költsége {#proof-verification-costs} - -A bizonyítékok ellenőrzése is összetett kalkulációt igényel és megnöveli a technológia bevezetésének költségét az alkalmazásokban. Ez a költség még inkább releváns a bizonyítási kalkuláció kontextusában. Például a ZK-rollupok kb. 500 000 gázt fizetnek, hogy egyetlen ZK-SNARK bizonyítékot ellenőrizzenek az Ethereumon, a ZK-STARK-ok pedig még ennél is többe kerülnek. - -### Bizalmi feltételezések {#trust-assumptions} - -A ZK-SNARK-ban a CRS (nyilvános paraméterek) egyszer kerül létrehozásra és azt újrahasználhatják a felek, akik részt akarnak venni a zero-knowledge protokollban. A nyilvános paramétereket egy bizalmat igénylő összetételi ceremónia révén hozzák létre, ahol a résztvevőkről feltételezzük, hogy jóhiszeműek. - -A felhasználók azonban nem tudják ellenőrizni a résztvevők jóhiszeműségét, meg kell bízniuk a fejlesztőkben. A ZK-STARK-ok mentesek az ilyen bizalomigénytől, mivel a véletlenszerűség nyilvánosan igazolható. Eközben a kutatók dolgoznak a ZK-SNARK-ok bizalomigénynélküli verzióján, hogy növeljék a bizonyítási mechanizmus biztonságát. - -### A kvantumszámítógép fenyegetései {#quantum-computing-threats} - -A ZK-SNARK elliptikus görbe kriptográfiát használ a titkosításhoz. Míg az elliptikus görbe diszkrét logaritmus problémája egyelőre megfejthetetlennek tekinthető, a kvantumszámítógépek fejlődése a jövőben megtörheti ezt a biztonsági modellt. - -A ZK-STARK immunis a kvantumszámítógépek fenyegetésére, mert csak ütközésálló hash-függvényeket használ a biztonsága érdekében. Ezt az algoritmust nehezebb feltörni a kvantumszámítógépnek, nem úgy, mint a nyilvános-privát kulcs párosát, melyet az elliptikusgörbe-alapú kriptográfia használ. - -## További olvasnivaló {#further-reading} - -- [A zero-knowledge bizonyítékok alkalmazási területeinek áttekintése](https://pse.dev/projects) — _Privacy and Scaling Explorations Team_ -- [A SNARK-ok, a STARK-ok és a rekurzív SNARK-ok összehasonlítása](https://www.alchemy.com/overviews/snarks-vs-starks) — _Alchemy Overviews_ -- [Zero-Knowledge bizonyíték: az adatbiztonság javítása a blokkláncon](https://www.altoros.com/blog/zero-knowledge-proof-improving-privacy-for-a-blockchain/) — _Dmitry Lavrenov_ -- [zk-SNARK-ok — Egy valós zero-knowledge példa és mélyebb elemzése](https://medium.com/coinmonks/zk-snarks-a-realistic-zero-knowledge-example-and-deep-dive-c5e6eaa7131c) — _Adam Luciano_ -- [ZK-STARK-ok — Igazolható bizalom létrehozása, még a kvantumszámítógépekkel szemben is](https://medium.com/coinmonks/zk-starks-create-verifiable-trust-even-against-quantum-computers-dd9c6a2bb13d) — _Adam Luciano_ -- [Egy hozzávetőleges áttekintés, hogyan lehetségesek a zk-SNARK-ok](https://vitalik.eth.limo/general/2021/01/26/snarks.html) — _Vitalik Buterin_ -- [A Zero-knowledge bizonyítékok (ZKP) megváltoztatják a szuverén identitás területét](https://frankiefab.hashnode.dev/why-zero-knowledge-proofs-zkps-is-a-game-changer-for-self-sovereign-identity) — _Franklin Ohaegbulam_ - diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md deleted file mode 100644 index de9e1a61daf..00000000000 --- a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-create-an-ethereum-account/index.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Hogyan lehet Ethereum számlát „létrehozni” -description: Részletes útmutató az Ethereum-számla létrehozásától egy tárca segítségével. -lang: hu ---- - -# Hogyan lehet Ethereum számlát létrehozni - -**Bárki nyithat Ethereum-számlát, bármikor és ingyenesen.** Ehhez csak egy kriptotárca alkalmazást kell telepítenie. A tárca egy olyan alkalmazás, amely létrehozza és kezeli az Ethereum-számlát. Tranzakciókat tud küldeni, megnézheti az egyenlegeket és kapcsolódhat a többi alkalmazással, melyek az Ethereumra épültek. - -A tárcával azonnal részt vehet tokenátváltásban, játékban és [NFT](/glossary/#nft)-piactereken is megjelenthet. Nincs szükség arra, hogy egyesével regisztráljon ezekre, mert egy számlával használhatja az összes Ethereumra épített alkalmazást. - -## 1. lépés: A tárca kiválasztása - -A tárca egy olyan alkalmazás, amely segíti az Ethereum-számla kezelését. Tucatnyi különböző tárca közül választhat: mobil-, asztali alkalmazásokkal vagy akár böngészőbővítményekkel működő tárcák is léteznek. - - - - A tárcák listája - - -Ha Ön most ismerkedik ezzel a területtel, akkor választhatja a „Kezdő a kripto világában” szűrőt a „Tárca keresése” oldalon, hogy olyan termékek közül választhasson, amelyek kifejezetten a kezdők számára fontos funkciókat kínálni. - -![Szűrési lehetőségek a „Tárca keresése” oldalon](./wallet-box.png) - -Egyéb profilszűrők is elérhetők, hogy saját igényeire szabhassa a keresést. Íme néhány példa a leggyakrabban használt tárcák közül – mindig vizsgálja meg Ön is az adott szolgáltatást, mielőtt bármilyen szoftvert kiválaszt. - -## 2. lépés: A tárcaalkalmazás letöltése és telepítése - -Miután kiválasztotta a tárcát, a hivatalos webhelyéről vagy az alkalmazás-áruházból töltse le és telepítse azt. Mindegyiknek ingyenesnek kell lennie. - -## 3. lépés: Nyissa meg az alkalmazást, és hozza létre Ethereum-fiókját - -A tárca első megnyitásakor a rendszer megkérdezheti, hogy egy új számlát kíván létrehozni vagy egy meglévőt szeretne importálni. Válassza az új számla létrehozása lehetőséget. **Ennél a lépésnél állítja fel a tárcaszoftver az Ön Ethereum számláját.** - -## 4. lépés: Visszaállítási kulcsmondat eltárolása - -Néhány alkalmazás arra kéri Önt, hogy tároljon el egy titkos kulcsmondatot („kulcskifejezés” vagy „mnemonika”). Rendkívül fontos, hogy ezt a kulcsmondatot biztonságban tartsa! A kulcsmondat hozza létre az Ethereum-számlát és tranzakciók végrehajtására használható. - -**Aki a kulcsmondatot birtokolja, az rendelkezik kontrollal a pénzeszközei felett.** Soha ne ossza meg senkivel! A kulcsmondat 12–24 véletlenszerűen kiválasztott szót tartalmaz (melyek sorrendje fontos). - -
- -
A tárca elkészült?
Tanulja meg használni azt.
- - Hogyan használja a tárcát - - -
- -Érdeklik további útmutatók? Tekintse meg a [Részletes útmutatókat](/guides/) - -## Gyakran ismételt kérdések - -### A tárcám és az Ethereum számlám ugyanaz? - -Nem. A tárca egy olyan eszköz, amely segít kezelni a számlát. Egy tárca több számlához is hozzáférést biztosíthat, és egy számlát több tárcából is el lehet érni. A kulcsmondat révén lehet számlákat létrehozni és felhatalmazást adni a tárcaalkalmazásnak, hogy az kezelje a pénzeszközöket. - -### Tudok küldeni Bitcoint Ethereum-számlára, vagy ethert Bitcoin-címre? - -Nem, ez nem lehetséges. A Bitcoin és az ether két teljesen elkülönült hálózaton létezik (azaz különálló blokkláncok), saját könyveléssel és címformátummal. Számos kezdeményezés volt, amellyel megpróbálták áthidalni e két hálózatot, melyek közül jelenleg a legaktívabb a [becsomagolt bitcoin vagy WBTC](https://www.bitcoin.com/get-started/what-is-wbtc/). Mivel a WBTC egy felügyeleti megoldást (egy csoport irányít bizonyos kritikus funkciókat), ezért itt csak információs céllal szerepel. - -### Ha rendelkezek ETH-címmel, akkor ugyanazt a címet más blokkláncokon is használhatom? - -Ugyanazt a [címet](/glossary/#address) használhatja minden olyan blokkláncon, amely az Ethereumhoz hasonló mögöttes szoftvert használ („EVM-kompatibilis”). Ez a [lista](https://chainlist.org/) megmutatja, hogy melyik blokkláncokon működik ugyanaz a cím. Néhány blokklánc, mint a Bitcoin, teljesen más hálózati szabályok alapján üzemel, ezért ott egy másik címre van szükség, amely más formátummal is bír. Ha okosszerződéses tárcával rendelkezik, akkor a terméktájékoztatóból kiderül, hogy melyik blokkláncokat támogatja, mivel ezek korlátozottabb, de biztonságosabb területen működnek. - -### A tárcám biztonságosabb, mint a pénzeszközeimet a tőzsdén tartani? - -A saját tárca azt jelenti, hogy Ön felelősséget vállal a pénzeszközeinek biztonságáért. Sajnos számtalan esetben omlott már össze tőzsde, elveszítve a vevők pénzét. A saját tárca (a kulcsmondattal együtt) csökkenti annak kockázatát, hogy egy másik entitásra kell bízni az eszközök felügyeletét. Ugyanakkor Önnek biztonságba kell helyeznie a kulcsait, elkerülni a csalásokat, nem szabad véletlenül jóváhagynia tranzakciót vagy feltárni a kulcsokat valaki előtt, hamis weboldalakat használni vagy hasonló kockázatot vállalni. A kockázatok és hasznok különböznek. - -### Ha elvesztettem a mobil/hardver tárcámat, akkor ugyanazt a tárcaalkalmazást használjam, hogy visszaszerezzem a pénzeszközeimet? - -Nem feltétlen, más tárcát is használhat. Amíg tudja a kulcsmondatot, bármelyik tárcába beteheti azt és visszaállítja a számláját. Ügyeljen arra, hogy ne kapcsolódjon az internethez, amikor visszaállítja a tárcáját, nehogy véletlenül kiszivárogjon a kulcsmondata. Az elveszett pénzeszközöket gyakran nem lehet visszaszerezni a kulcsmondat nélkül. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md deleted file mode 100644 index bd0c1958301..00000000000 --- a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-id-scam-tokens/index.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Hogyan lehet felismerni a valótlan tokeneket -description: A valótlan tokenek felismerése, hogyan tűnnek legitimnek, és hogyan lehet elkerülni őket. -lang: hu ---- - -# Hogyan lehet felismerni a valótlan tokeneket {#identify-scam-tokens} - -Az Ethereum egyik leggyakoribb felhasználási módja, hogy egy csoport létrehoz egy kereskedhető tokent, bizonyos értelemben saját valutát. Ezek a tokenek jellemzően a [ERC-20](/developers/docs/standards/tokens/erc-20/)-szabványt követik. Ahol legitim alkalmazási területek vannak, melyek értéket teremtenek, mindig megjelennek a csalók is, hogy ezt az értéket megszerezzék maguknak. - -Kétféle módon próbálhatják Önt megtéveszteni: - -- **Egy valótlan tokent adnak el**, ami hasonlít az eredetire, melyet meg szeretne vásárolni, de a csalók állították ki és nem ér semmit sem. -- **Ráveszik Önt, hogy rossz tranzakciókat írjon alá**, általában úgy, hogy a saját felhasználói felületükre vezetik át Önt. Megpróbálhatják rávenni, hogy a szerződésüknek adjon hozzáférést az ERC-20 tokenjeihez, bizalmas információkat feltárva, amelyekkel elérik az Ön eszközeit stb. Ezek a hamis honlapok szinte tökéletes másai az eredetinek, de rejtett trükkökkel. - -A hamis tokenek illusztrálása végett, és hogyan lehet beazonosítani azokat, megnézünk egy példát: [`wARB`](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82). Ez a token megpróbál úgy kinézni, mint a valós [`ARB`](https://etherscan.io/address/0xb50721bcf8d664c30412cfbc6cf7a15145234ad1) token. - - - -Az Arbitrum egy olyan szervezet, mely optimista rollupokat fejleszt és kezel. Kezdetben az Arbitrum egy profitorientált vállalatként működött, de aztán decentralizálta magát. Ennek részeként kibocsátott egy irányítási tokent, amivel kereskedni lehet. - - - - - -Az Ethereumon létezik egy konvenció, hogy a nem ERC-20-szabványnak megfelelő tokeneknek egy becsomagolt (wrapped) verziót készítenek, melynek a neve w-vel kezdőik. Például itt van a wBTC a bitcoinhoz és a wETH az etherhez. - -Nincs értelme egy olyan ERC-20 token becsomagolt változatát létrehozni, ami már az Ethereumon van, de a csalók a kinézetre hagyatkoznak, nem a mögöttes valóságra. - - - -## Hogyan működnek a hamis tokenek? {#how-do-scam-tokens-work} - -Az Ethereum lényege a decentralizáció. Emiatt nincs központi hatóság, amely elkobozná bárki eszközeit vagy megakadályozná, hogy egy okosszerződést hozzon létre. De ez azt is jelenti, hogy a csalók is képesek bármilyen okosszerződést létrehozni. - - - -Az okosszerződések olyan programok, amelyek az Ethereum-blokkláncon futnak. Minden ERC-20 token egy okosszerződéként van létrehozva. - - - -Specifikusan, az Arbitrum készített egy szerződést, amely az `ARB` szimbólumot használja. De ez nem akadályozza meg a többi embert, hogy egy szerződést készítsenek ugyanezzel a szimbólummal vagy egy hasonlóval. Aki ezt a szerződést megírja, be kell állítsa, hogy az mit fog csinálni. - -## Valósnak tűnnek {#appearing-legitimate} - -Számos trükk van, amit a hamis tokenek létrehozói képesek megtenni, hogy valósnak tüntessék azt fel. - -- **A valós nevet és szimbólumot használják**. Az ERC-20 szerződések viselhetik ugyanazt a szimbólumot és nevet, mint más ERC-20 szerződések. Ezekre az információkra nem lehet a biztonságot alapozni. - -- **A valós kibocsátókat használják**. A hamis tokenek gyakran jelentős összegeket dobnak be olyan címekre, amelyek nagy valószínűséggel az eredeti token valódi kibocsátói. - - Térjünk vissza a `wARB` példájához. [Nagyjából a tokenek 16%-a](https://etherscan.io/token/0xb047c8032b99841713b8e3872f06cf32beb27b82?a=0x1c8db745abe3c8162119b9ef2c13864cd1fdd72f) egy olyan címen található, melynek nyilvános neve [Arbitrum Foundation: Deployer](https://etherscan.io/address/0x1c8db745abe3c8162119b9ef2c13864cd1fdd72f). Ez _nem_ egy hamis cím, ez tényleg az a cím, amely [bevezette a valódi ARB-szerződést az Ethereum főhálózatán](https://etherscan.io/tx/0x242b50ab4fe9896cb0439cfe6e2321d23feede7eeceb31aa2dbb46fc06ed2670). - - Mivel egy cím ERC-20-egyenlege része az ERC-20-szerződés tárhelyének, ezért az meghatározható a szerződés alapján, attól függően, hogy a szerződés fejlesztője mit kíván. A szerződés megakadályozhatja a további átadást is, ezért a valós felhasználók nem tudnak megszabadulni ezektől a hamis tokenektől. - -- **A valós átutalást használják**. _A valós kibocsátók nem fizetnének egy hamis token átküldéséért, ezért ezek a transzferek valósak, ugye?_ **Nem**. `A transzfer` is az ERC-20-szerződés szerint megy. A csalók könnyedén le tudják programozni, hogy így viselkedjen. - -## Hamis weboldalak {#websites} - -A csalók nagyon meggyőző weboldalakat is készíthetnek, amelyek néha az eredeti pontos másai, azonos kinézettel, de mégis apró trükkökkel. Például a valósnak tűnő hivatkozások, amelyek elirányítják a felhasználót hamis oldalakra, vagy valótlan információk, amelyek elkérik a felhasználók kulcsait vagy a támadók címére küldetnek pénzeszközöket. - -A legjobb, ha mindig megvizsgálja a weboldal címét, illetve a hiteles oldalakat elmenti a könyvjelzők közé. Így a valódi oldalra lép be anélkül, hogy félreírná azt vagy külső hivatkozásra támaszkodna. - -## Hogyan tudja Ön is megvédeni magát? {#protect-yourself} - -1. **Ellenőrizze a szerződés címét**. A valódi tokenek valódi szervezetektől érkeznek, amelyek címét meg lehet találni a szervezet honlapján. Például [az `ARB` esetében itt találja a valódi címeket](https://docs.arbitrum.foundation/deployment-addresses#token). - -2. **A valódi tokenek likviditással bírnak**. A likviditási alap méretét meg tudja nézni a [Uniswap](https://uniswap.org/) oldalán, ami az egyik legelterjedtebb tokenváltó protokoll. Ez a protokoll úgy működik, hogy likviditási alapokat hoz létre, amelybe minden befektető letétbe helyezi a tokenjeit a kereskedési díjakból származó jövedelemért cserébe. - -A hamis tokeneknek általában kicsi likviditási alapjuk van, ha egyáltalán van ilyen, mivel a csalók nem akarnak valódi eszközöket kockáztatni. Például az `ARB`/`ETH` Uniswap alap körülbelül egy millió dollárt tartalmaz ([nézze meg a jelenlegi összeget](https://info.uniswap.org/#/pools/0x755e5a186f0469583bd2e80d1216e02ab88ec6ca)), és kis összegek adás-vétele nem fogja változtatni az árát: - -![Valódi token vásárlása](./uniswap-real.png) - -De amikor megpróbálja megvenni a hamis tokent, a `wARB`-t, akkor minden vásárlás 90%-kal változtatja az árat: - -![Hamis token vásárlása](./uniswap-scam.png) - -Ez is azt mutatja, hogy a `wARB` nem lehet valódi. - -3. **Nézze meg az Etherscan alkalmazásban**. Számos hamis tokent már beazonosított és jelentett a közösség. Ezek meg vannak [jelölve az Etherscanben](https://info.etherscan.com/etherscan-token-reputation/). Miközben az Etherscan nem egy irányadó igazságforrás (mivel a decentralizált hálózatoknál ez nem lehetséges), mégis az Etherscan által beazonosított tokenek nagy valószínűséggel hamisak. - - ![Hamis token az Etherscanben](./etherscan-scam.png) - -## Következtetés {#conclusion} - -Amíg érték van a világon, addig csalók is lesznek, akik meg akarják azt szerezni, és egy decentralizált világban senki sem fogja megvédeni Önt, kivéve önmaga. Reméljük, hogy az alábbi jellemzők alapján Ön is könnyedén megkülönbözteti a valódi tokent a hamistól: - -- A hamis tokenek valódiakat személyesítenek meg, felhasználva annak nevét, szimbólumát stb. -- A hamis tokenek _nem_ használhatják ugyanazt a szerződési címet. -- A valódi token címét a kibocsátó szervezettől lehet megtudni. -- Ha ez nem sikerül, akkor olyan népszerű, megbízható alkalmazásokat használhat, mint a [Uniswap](https://app.uniswap.org/#/swap) és az[Etherscan](https://etherscan.io/). diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md deleted file mode 100644 index 01ddb6967b8..00000000000 --- a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-revoke-token-access/index.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Hogyan vonható vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez -description: Útmutató arról, hogyan vonhatja vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez -lang: hu ---- - -# Hogyan vonható vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez - -Ez az útmutató megtanítja Önnek, hogyan tekintheti meg az összes [intelligens szerződés](/glossary/#smart-contract) listáját, amelyhez hozzáférést biztosított, és hogyan mondhatja fel azokat. - -Néha a rosszhiszemű fejlesztők olyan kiskapukat építenek az okosszerződésekbe, melyek hozzáférést biztosítanak a gyanútlan felhasználók eszközeihez, akik azzal a szerződéssel interakcióba lépnek. Gyakran előfordul, hogy az ilyen platformok engedélyt kérnek a felhasználótól **korlátlan számú token** elköltésére, hogy a jövőben kis mennyiségű [gázt](/glossary/#gas) spóroljanak meg, de ez az megnövekedett kockázat. - -Miután egy platform korlátlan hozzáférési jogokkal rendelkezik egy tokenhez a [pénztárcájában](/glossary/#wallet), akkor is elköltheti ezeket a tokeneket, még akkor is, ha Ön kivette a pénzt a platformjáról a pénztárcájába. A rosszindulatú szereplők még így is hozzáférhetnek az Ön pénzéhez, amit a saját tárcájukba lehívnak, és Ön ezt már nem fogja tudni visszaszerezni. - -Ezt úgy tudja elkerülni, hogy tartózkodik a nem tesztelt új projektek használatától, csak azt hagyja jóvá, amire valóban szüksége van és rendszeresen visszavonja a hozzáféréseket. Tehát hogyan is kell ezt csinálni? - -## 1. lépés: Hozzáférés-visszavonási eszközök használata - -Számos weboldal lehetővé teszi, hogy láthassa és visszavonhassa a címéhez kapcsolódó okosszerződéseket. Látogasson el a weboldalra és kapcsolja azt össze a tárcájával: - -- [Ethallowance](https://ethallowance.com/) (Ethereum) -- [Etherscan](https://etherscan.io/tokenapprovalchecker) (Ethereum) -- [Cointool](https://cointool.app/approve/eth) (több hálózat) -- [Revoke](https://revoke.cash/) (több hálózat) -- [Unrekt](https://app.unrekt.net/) (több hálózat) -- [EverRevoke](https://everrise.com/everrevoke/) (több hálózat) - -## 2. lépés: Összekapcsolás a tárcával - -A weboldalon kattintson a „Tárcához kapcsolás” funkcióra. A weboldalon megjelenik egy, a tárcához kapcsolódásról szóló üzenet. - -Használja ugyanazt a hálózatot a tárcán és a weboldalon. Csak azokat az okosszerződéseket fogja látni, melyek ehhez a hálózathoz kötődnek. Például, az Ethereum-főhálózathoz kapcsolódva csak az Ethereum-szerződéseket látja, a más láncokról (pl. Polygon) származó szerződéseket nem. - -## 3. lépés: A visszavonni kívánt okosszerződés kiválasztása - -Itt az összes szerződést látnia kell, amely hozzáfér az Ön tokenjeihez, illetve azok költési keretének is meg kell jelennie. Válassza ki azt, amelyet le kívánja zárni. - -Ha nem tudja, hogy melyik az, akkor az összeset leválaszthatja. Ez nem okoz problémát, a következő alkalommal, amikor ezekkel a szerződésekkel interakcióba lép, új engedélyt kell adnia azoknak. - -## 4. lépés: Az eszközeihez való hozzáférés lezárása - -A lezárásra kattintva egy új tranzakció jelentik meg a tárcájában. Ez várható jelenség. A lezárás sikeres elvégzéséhez ki kell fizetnie a díjat. A hálózattól függően ez akár néhány percig is eltarthat. - -Javasoljuk, hogy néhány perc múlva frissítse a visszavonási eszközt, és nézze meg a tárcájában, hogy valóban eltűnt-e a törölt kapcsolat a listáról. - -Sose adjon a projekteknek korlátlan hozzáférést a tokenjeihez, valamint törölje rendszeresen a hozzáféréseket. A tokenekhez való hozzáférés leállítása nem jár eszközvesztéssel, ha a fenti eszközöket használja. - -
- - -
Szeretne többet megtudni?
- - Tekintse meg a további útmutatóinkat - - - -## Gyakran ismételt kérdések - -### A tokenekhez való hozzáférés leállítása a letétbe helyezést, letéti alapokat, kölcsönzést stb. is felfüggeszti? - -Nem, ez nem befolyásolja egyik [DeFi](/glossary/#defi) stratégiáját sem. A helyzete változatlan marad, és tovább kapja a jutalmakat stb. - -### A projektről leválasztani a tárcát ugyanazzal az eredménnyel jár, mintha visszavonnám az engedélyt, hogy hozzáférjen az eszközeimhez? - -Nem, mert a tárca leválasztása után, ha Ön engedélyt adott a tokenek használatára, akkor a projekt továbbra is használni tudja a tokeneket. Az engedélyt kell visszavonnia. - -### A szerződés engedélye mikor jár le? - -A szerződés engedélyeinek nincs lejárati ideje. Ha engedélyt adott, akkor az akár évekkel később is érvényes lehet. - -### A projektek miért állítanak be korlátlan tokenhasználatot? - -A projektek gyakran így akarják minimalizálni a kérvények számát, mert ilyenkor a felhasználónak csak egyszer kell jóváhagynia és a tranzakciós díjat is csak egyszer kell kifizetnie. Bár ez kényelmes megoldás lehet, ugyanolyan veszélyt is rejt azokra a felhasználókra nézve, akik idővel vagy audittal még nem igazolt oldalak hagynak jóvá ilyet. Néhány tárcánál lehetséges manuálisan beállítani a tokenek felhasználható mennyiségét, hogy csökkentsék a kockázatot. További információkért forduljon tárcaszolgáltatójához. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md deleted file mode 100644 index d3e53b119b4..00000000000 --- a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-swap-tokens/index.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Hogyan lehet átváltani a tokeneket -description: Útmutató a tokenek átváltásához az Ethereumon. -lang: hu ---- - -# Hogyan lehet átváltani a tokeneket - -Elege van abból, hogy olyan tőzsdét keres, amely kedvenc tokenjeivel kereskedik? A legtöbb token felcserélhető [decentralizált cserékkel](/glossary/#dex). - -A tokencsere az Ethereum hálózaton található két különböző eszköz cseréjét foglalja magában, például az ETH cseréjét DAI-ra (egy [ERC-20](/glossary/#erc-20) token). Ez egy gyors és olcsó tranzakció. Szüksége lesz egy kriptotárcára a tokenek váltásához. - -**Feltételek:** - -- Ha van [kriptopénztárcája](/glossary/#wallet), kövesse ezt az oktatóanyagot: [Hogyan: "Regisztráljon" egy Ethereum-fiókot](/guides/how-to-create-an-ethereum-account/) -- lennie kell pénzeszközöknek a tárcájában - -## 1. Kapcsolja a tárcáját egy kiválasztott decentralizált tőzsdéhez (DEX) - -Néhány ismert példa: - -- [Uniswap](https://app.uniswap.org/#/swap) -- [Sushiswap](https://www.sushi.com/swap) -- [1Inch](https://app.1inch.io/#/1/unified/swap/ETH/DAI) -- [Curve](https://curve.fi/#/ethereum/swap) - -Érdekesnek találja? Tudjon meg többet arról, hogy mi a [decentralizált pénzügy (DeFi)](/defi/) és hogyan működnek ezek az újfajta tőzsdék. - -## 2. Válassza ki a két token, amelyeket át szeretne váltani - -Például ETH és DAI. Győződjön meg arról, hogy az egyik tokenből rendelkezik elegendő pénzeszközzel. ![Általános felület az átváltáshoz](./swap1.png) - -## 3. Írja be az eladásra szánt token összegét és nyomja meg az átváltás (swap) gombot - -A tőzsde automatikusan kiszámolja, hogy Ön mennyi tokent fog kapni. - -![Általános felület az átváltáshoz](./swap2.png) - -## 4. Erősítse meg a tranzakciót - -Tekintse át a tranzakció részleteit. Vessen egy pillantást az átváltási rátára és más díjakra, hogy később ne érje kellemetlen meglepetés. - -![Általános felület a tranzakciók megtekintéséhez](./swap3.png) - -## 5. Várja meg, amíg a tranzakciót feldolgozzák - -Bármelyik blokkláncböngészővel megtekintheti a tranzakció állapotát. Ez legfeljebb 10 percen belül megtörténik. - -A tranzakció végrehajtása után automatikusan megkapja a tárcájába a beszerzett tokent. -
- - -
Szeretne többet megtudni?
- - Tekintse meg a további útmutatóinkat - - - -## Gyakran ismételt kérdések - -### Át tudok váltani ETH-t BTC-re a tárcámban? - -Nem, csak olyan tokeneket tud váltani, melyek az Ethereum hálózatán működnek, mint az ETH, az ERC-20-as tokenek vagy NFT-k. A Bitcoinnak az Ethereumon megtalálható, „becsomagolt” formáival tud kereskedni. - -### Mi az a csúszás (slippage)? - -A várható átváltási ráta és az aktuális ráta közötti különbség. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md deleted file mode 100644 index 40bdafec991..00000000000 --- a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-bridge/index.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: Hogyan lehet áthelyezni a tokeneket a második blokkláncrétegbe (L2) -description: Útmutató, hogyan tudja az Ethereumon lévő tokeneket L2-re áthelyezni híd használatával. -lang: hu ---- - -# Hogyan lehet áthelyezni a tokeneket a második blokkláncrétegbe (L2) - -Ha sok tranzakció fut egyszerre az Ethereumon, akkor drágább a hálózatot használni. Erre az egyik megoldás az, hogy új rétegeket hoznak létre, tehát más hálózatokat, melyek az Ethereumhoz hasonlóan működnek. Ezek a második blokkláncrétegek (L2) csökkenthetik a tranzakciók mennyiségét és azok költségét is az Ethereumon azáltal, hogy sok tranzakciót kezelnek alacsonyabb díjért és ezeknek csak az eredményét tárolják az Ethereumon. Így az L2 megoldások gyorsabban működnek és kevesebb költséggel járnak. Számos népszerű kriptoprojekt az L2-re épít annak előnyei miatt. A legegyszerűbb módja a tokenek Ethereumról második blokkláncra (L2) való áthelyezésének a híd használata. - -**Feltételek:** - -- rendelkeznie kell egy kriptotárcával – ehhez kövesse a következő útmutatót: [Hogyan lehet létrehozni Ethereum-számlát](/guides/how-to-create-an-ethereum-account/) -- lennie kell pénzeszközöknek a tárcájában - -## 1. Határozza meg, hogy melyik L2 hálózatot szeretné használni - -További információkat a projektekről és a fontos hivatkozásokról a [második blokkláncréteg (L2) oldalon](/layer-2/) is szerezhet. - -## 2. Lépjen a kiválasztott hídra - -Néhány népszerű L2: - -- [Arbitrum-híd](https://bridge.arbitrum.io/?l2ChainId=42161) -- [Optimism-híd](https://app.optimism.io/bridge/deposit) -- [Boba-hálózat hídja](https://gateway.boba.network/) - -## 3. Kapcsolódjon a hídhoz a tárcájával - -Győződjön meg arról, hogy tárcája az Ethereum-főhálózathoz kapcsolódik. Ha nem, akkor a weboldal automatikusan felhozza a hálózatváltási lehetőséget. - -![Általános felület a tokenek áthelyezéséhez](./bridge1.png) - -## 4. Határozza meg az összeget és helyezze át - -Tekintse át az összeget, amit az L2-n kapni fog és a kapcsolódó díjakat, hogy ne érjék kellemetlen meglepetések. - -![Általános felület a tokenek áthelyezéséhez](./bridge2.png) - -## 5. Hagyja jóvá a tranzakciót a tárcájában - -A tranzakcióért ETH formájában kell fizetnie. - -![Általános felület a tokenek áthelyezéséhez](./bridge3.png) - -## 6. Várja meg, amíg az eszközei átkerülnek - -Ennek 10 perc alatt meg kell történnie. - -## 7. Adja hozzá a kiválasztott L2 hálózatot a tárcájához (opcionális) - -A [chainlist.org](http://chainlist.org) segít az adott hálózat RPC-adatait megtalálni. Amint a hálózat hozzáadásra kerül és a tranzakció végbemegy, a tokenek megjelennek a tárcájában. -
- - -
Szeretne többet megtudni?
- - Tekintse meg a további útmutatóinkat - - - -## Gyakran ismételt kérdések - -### Mi van akkor, ha tőzsdén vannak eszközeim? - -Bizonyos tőzsdékről lehetséges közvetlenül L2-re áthelyezni az eszközöket. Nézze meg az „Áthelyezés a második blokkláncrétegre (L2)” című részt az [L2 oldalon](/layer-2/) a további információkért. - -### Visszavihetem a tokenjeimet az Ethereum-főhálózatra, miután áthelyeztem azokat az L2-re? - -Igen, mindig visszaviheti az eszközeit a főhálózatra ugyanazon a hídon keresztül. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md deleted file mode 100644 index c23c6200ee2..00000000000 --- a/public/content/translations/hu/10) Guides and Quizzes/guides/how-to-use-a-wallet/index.md +++ /dev/null @@ -1,88 +0,0 @@ ---- -title: Hogyan használja a tárcát -description: Útmutató a tokenek küldéséről és fogadásáról, valamint a web3-projektekhez való kapcsolódásról. -lang: hu ---- - -# Hogyan használja a tárcát - -Ismerje meg, hogyan működnek a tárca alapvető funkciói. Ha még nem rendelkezik tárcával, akkor tekintse meg a [Hogyan lehet Ethereum-számlát létrehozni](/guides/how-to-create-an-ethereum-account/) című útmutatót. - -## Nyissa ki tárcáját - -Egy irányítópult jelenik meg, amelyen az egyenlege, valamint a tokenek küldésére és fogadására vonatkozó gombok láthatók. - -## Kriptovaluta fogadása - -Szeretne kriptovalutát fogadni a tárcájába? - -Minden Ethereum-számla rendelkezik saját fogadócímmel, amely egy egyedi, számokat és betűket tartalmazó sor. A cím úgy működik, akár egy bankszámlaszám. Az Ethereum-címek mindig „0x” kezdetűek. Ezt a címet bárkivel megoszthatja: ez biztonságos. - -A cím olyan, mint a lakhelyének a címe: elmondja az embernek, hogy odataláljanak Önhöz. Ez azért is biztonságos, mert be tudja zárni az ajtót egy másik kulccsal, amivel csak Ön rendelkezik, így nem tudnak bejutni, hiába tudják a címét. - -Ha valaki pénzt akar küldeni Önnek, akkor meg kell adnia a nyilvános címét. Számos tárca megengedi, hogy kimásolja azt vagy QR-kódként megossza, hogy könnyebb legyen a használata. Ne gépelje be manuálisan. Ez könnyen hibákhoz és a pénzeszköz elvesztéséhez vezethet. - -Előfordulhat, hogy a különböző alkalmazások eltérnek egymástól vagy más nyelvet használnak, de hasonló folyamaton vezetik végig, ha eszközöket kíván mozgatni. - -1. Nyissa meg a tárcaalkalmazást. -2. Kattintson a „Fogadás” (vagy hasonló nevű) gombra. -3. Másolja Ethereum-címét a vágólapra. -4. Adja meg a küldőnek a fogadó Ethereum-címét. - -## Kriptovaluta küldése - -Szeretne ETH-t küldeni egy másik tárcába? - -1. Nyissa meg a tárcaalkalmazást. -2. Kérje el a fogadó címét, és győződjön meg arról, hogy ugyanahhoz a hálózathoz kapcsolódik, mint a fogadó fél. -3. Másolja be a címet vagy szkennelje be a QR-kódot a kamerával, így nem kell manuálisan megadnia. -4. Kattintson a Küldés (vagy hasonló nevű) gombra a tárcájában. - -![A kriptoszámla küldő mezője](./send.png) -
- -5. Számos eszköz, mint a DAI vagy USDC, egyszerre több hálózaton is létezik. Amikor kriptotokeneket küld, győződjön meg arról, hogy a fogadó fél is ugyanazt a hálózatot használja, mert ezek nem átjárhatók. -6. Biztosítsa, hogy a tárcája elegendő ETH-t tartalmaz, hogy lefedje a tranzakciós díjat is, amely a hálózati feltételek miatt változó összeg. A legtöbb tárca automatikusan hozzáadja a tranzakcióhoz a javasolt díjat, amit Ön jóváhagy. -7. Amint a tranzakció végbement, a kripto összege megjelenik a fogadó fél számláján. Ez a hálózat használóinak számától függően néhány pillanatig vagy percig is eltarthat. - -## Kapcsolódás projektekhez - -Az Ön címe minden Ethereum-projekt esetében azonos. Nem kell regisztrálnia külön sehol. A tárcával bármilyen más információ megadása nélkül kapcsolódni tud az Ethereum-projektekhez. Nincs szükség e-mail-címre vagy egyéb személyes adatokra. - -1. Látogasson el bármelyik projekt oldalára. -2. Ha a projekt oldala csak egy tájékoztató leírás, akkor kattintson az Alkalmazás megnyitása gombra a menüben, ami elvezeti Önt a valódi alkalmazáshoz. -3. Az alkalmazáson belül kattintson a „Kapcsolódás” gombra. - -![Gomb a felhasználó számára, melynek segítségével tárcájával a weboldalhoz kapcsolódhat](./connect1.png) - -4. Válassza ki a tárcáját a megadott opciók listájából. Ha nem látja a tárcáját, akkor nézze meg a „WalletConnect” lehetőség alatt. - -![Kiválasztás a tárcák listájából a kapcsolódáshoz](./connect2.png) - -5. Erősítse meg az aláírási kérést a tárcájában ahhoz, hogy a kapcsolat létrejöjjön. **Az üzenet aláírása nem kerül ETH-pénzeszközbe**. -6. Készen is van! Kezdje el használni az alkalmazást. Számos érdekes projektet találhat a [dapp oldalunkon](/dapps/#explore).
- - -
Szeretne többet megtudni?
- - Tekintse meg a további útmutatóinkat - - - -## Gyakran ismételt kérdések - -### Ha rendelkezek ETH-címmel, akkor ugyanazt a címet más blokkláncokon is használhatom? - -Ugyanazt a címet használhatja minden EVM-kompatibilis blokkláncon (ha az Ön tárcájához tartozik visszaállítási kulcsmondat). Ez a [lista](https://chainlist.org/) megmutatja, hogy melyik blokkláncokon működik ugyanaz a cím. Néhány blokklánc, mint a Bitcoin, teljesen más hálózati szabályok alapján üzemel, ezért ott egy másik címre van szükség, amely más formátummal is bír. Ha okosszerződéses tárcával rendelkezik, akkor a terméktájékoztatóból kiderül, hogy melyik blokkláncokat támogatja. - -### Használhatom ugyanazt a címet több eszközön? - -Igen, több eszközön is lehet ugyanazt a címet használni. A tárca valójában csak egy felület, hogy Ön láthassa az egyenlegét és tranzakciókat indítson, a számla nem a tárcán belül található, hanem a blokkláncon. - -### Nem kaptam meg a kriptót, hol tudom a tranzakció státuszát ellenőrizni? - -Használhatja a [blokkfelfedezőket](/developers/docs/data-and-analytics/block-explorers/), hogy valós időben követni tudja a tranzakció státuszát. Ehhez csak a tárca címére vagy a tranzakció azonosítójára kell rákeresnie. - -### A tranzakciókat le tudom állítani vagy visszafordítani? - -Nem, a jóváhagyás után nem lehet leállítani. diff --git a/public/content/translations/hu/10) Guides and Quizzes/guides/index.md b/public/content/translations/hu/10) Guides and Quizzes/guides/index.md deleted file mode 100644 index e9cc9e97537..00000000000 --- a/public/content/translations/hu/10) Guides and Quizzes/guides/index.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Az Ethereum útmutatói -description: Gyakorlati útmutatók gyűjteménye az Ethereum használatának alapjairól kezdők számára. -lang: hu ---- - -# Az Ethereum útmutatói - -Ön is belevág az utazásba az Ethereum világában? A gyakorlati útmutatók részletesen végigvezetik Önt a kezdeti lépéseken, és megkönnyítik az új technológiában való tájékozódást. - -## Első lépések - -1. [Hogyan lehet Ethereum számlát létrehozni](/guides/how-to-create-an-ethereum-account/) – Bárki csinálhat magának tárcát ingyen. Ez az útmutató segít abban, hogyan fogjon bele. - -2. [Hogyan használja a tárcát](/guides/how-to-use-a-wallet/) – Ismerje meg a tokenek küldését és fogadását a tárcájába, valamint a tárca projektekhez való kapcsolását. - -## Biztonsági alapok - -1. [Hogyan vonható vissza, hogy az okosszerződés hozzáférjen a kriptoeszközeihez](/guides/how-to-revoke-token-access/) – Ha hirtelen azt látja, hogy olyan tranzakció van a tárcájában, melyet nem Ön indított el, akkor ez az útmutató segít abban, hogy ne történjen meg újra. - -2. [Hogyan azonosíthatók a valótlan tokenek](/guides/how-to-id-scam-tokens/) – Mik azok a valótlan tokenek, hogy tűntetik fel magukat valódiként, hogyan azonosíthatók ezek és kerülhető el a csalás. - -## Az Ethereum használata - -1. [Hogyan lehet áthelyezni a tokeneket a második blokkláncrétegbe (L2)](/guides/how-to-use-a-bridge/) – Túl sokba kerülnek az Ethereum-tranzakciók? Fontolja meg, hogy áttér az Ethereum L2-nek nevezett skálázási megoldásaira. - -2. [Hogyan lehet átváltani a tokeneket](/guides/how-to-swap-tokens/) – Át akarja váltani a tokenjét egy másikra? Ez az egyszerű leírás segít abban, hogyan tudja megtenni. diff --git a/public/content/translations/hu/11) Roadmap/eips/index.md b/public/content/translations/hu/11) Roadmap/eips/index.md deleted file mode 100644 index 3801e413ed1..00000000000 --- a/public/content/translations/hu/11) Roadmap/eips/index.md +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Ethereum Fejlesztési Javaslatok (EIP-k) -description: Az EIP megértéséhez szükséges alapinformációk -lang: hu ---- - -# Bevezetés az Ethereum Fejlesztési Javaslatokba (EIP-k) {#introduction-to-ethereum-improvement-proposals} - -## Mik azok az EIP-k? {#what-are-eips} - -[Az Ethereum Fejlesztési Javaslatok (EIP-k)](https://eips.ethereum.org/) olyan sztenderdek, melyek potenciális új funkciókat és folyamatokat specifikálnak az Ethereumra. Az EIP-k tartalmazzák a javasolt változtatások műszaki előírásait, és a közösség „igazságforrásaként” működnek. Az Ethereum hálózati frissítéseit és alkalmazási szabványait az EIP folyamaton keresztül tárgyalják és fejlesztik. - -Az Ethereum közösségben bárki létrehozhat egy EIP-t. Az EIP-írás irányelveit az [EIP-1](https://eips.ethereum.org/EIPS/eip-1) tartalmazza. Egy EIP elsődleges célja, hogy tömör technikai specifikációt nyújtson némi motivációval együtt. Az EIP szerzője felelős a közösségen belüli konszenzus kialakításáért, valamint az eltérő vélemények dokumentálásáért. A jól kidolgozott EIP benyújtásának magas szakmai követelményei miatt a legtöbb EIP-szerző általában alkalmazás- vagy protokollfejlesztő. - -## Miért fontosak az EIP-k? {#why-do-eips-matter} - -Az EIP-k központi szerepet játszanak abban, hogy a változások hogyan történnek és dokumentálódnak az Ethereumon. Így lehet az embereknek javaslatot tenni, vitatkozni és elfogadni a változásokat. Különböző [EIP-típusok léteznek](https://eips.ethereum.org/EIPS/eip-1#eip-types), például alapvető (core) EIP-k az alacsony szintű protokollmódosításokhoz, amelyek a konszenzust érintik és hálózatfrissítést igényelnek, mint az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), valamint az alkalmazásstandardokat érintő ERC-k, például az [EIP-20](https://eips.ethereum.org/EIPS/eip-20) és az [EIP-721](https://eips.ethereum.org/EIPS/eip-721). - -Minden hálózati frissítés EIP-kből áll, melyeket a hálózaton működő összes [Ethereum-kliensnek](/learn/#clients-and-nodes) implementálnia kell. Ez azt jelenti, hogy az Ethereum-főhálózat többi kliensével való konszenzus fenntartása érdekében a kliensfejlesztőknek meg kell győződniük arról, hogy mindannyian implementálták a szükséges EIP-ket. - -A változások technikai specifikációjával együtt az EIP-k egy olyan egységet képeznek, amely körül az irányítás történik az Ethereumban: bárki szabadon javasolhat egyet, ezután a közösség különböző érdekeltjei megvitatják, hogy ezt szabványként kell-e elfogadni, vagy egy hálózati frissítés legyen-e belőle. Mivel a nem alapvető (non-core) EIP-ket nem kell minden alkalmazásnak bevezetnie (például készíthető egy helyettesíthető token, amely nem használja az EIP-20 szabványt), de az alapvető (core) EIP-ket széleskörűen be kell vezetni (mivel minden csomópontot frissíteni kell, hogy ugyanahhoz a hálózathoz tartozzanak), az alapvető EIP-k szélesebb konszenzust igényelnek a közösségen belül, mint a nem alapvető EIP-k. - -## EIP-k története {#history-of-eips} - -Az [Ethereum Improvement Proposals (EIPs) Github gyűjteményt](https://github.com/ethereum/EIPs) 2015 októberében hozták létre. Az EIP folyamat a [Bitcoin Improvement Proposals (BIPs)](https://github.com/bitcoin/bips) folyamaton alapul, ami pedig a [Python Enhancement Proposals (PEPs)](https://www.python.org/dev/peps/) folyamaton alapul. - -Az EIP-szerkesztők feladata a technikai stabilitás és a formázási kérdések vizsgálata, valamint a helyesírás/nyelvtan és a kódstílus ellenőrzése. Többek között Martin Becze, Vitalik Buterin és Gavin Wood voltak az eredeti EIP szerkesztők 2015-től 2016 végéig. - -Jelenlegi EIP-szerkesztők: - -- Alex Beregszaszi (@axic) -- Gavin John (@Pandapip1) -- Greg Colvin (@gcolvin) -- Matt Garnett (@lightclient) -- Sam Wilson (@SamWilsn) - -Tiszteletbeli EIP-szerkesztők: - -- Casey Detrio (@cdetrio) -- Hudson Jameson (@Souptacular) -- Martin Becze (@wanderer) -- Micah Zoltu (@MicahZoltu) -- Nick Johnson (@arachnid) -- Nick Savers (@nicksavers) -- Vitalik Buterin (@vbuterin) - -Ha ön is szeretne EIP-szerkesztő lenni, akkor tekintse meg az [EIP-5069](https://eips.ethereum.org/EIPS/eip-5069) frissítést. - -Az EIP-szerkesztők döntik el, hogy egy javaslat mikor áll készen arra, hogy EIP váljon belőle, és segítenek az EIP-szerzőknek kidolgozni javaslataikat. Az [Ethereum macskapásztorok (Cat Herder)](https://www.ethereumcatherders.com/) segítenek az EIP-szerkesztők és a közösség találkozóinak szervezésében (lásd még [EIPIP](https://github.com/ethereum-cat-herders/EIPIP)). - -A teljes szabványosítási folyamat diagrammal együtt megtalálható az [EIP-1](https://eips.ethereum.org/EIPS/eip-1) frissítésben. - -## Bővebben {#learn-more} - -Ha szeretne többet olvasni az EIP-kről, akkor tekintse meg az [EIP-k weboldalát](https://eips.ethereum.org/) és az [EIP-1](https://eips.ethereum.org/EIPS/eip-1) frissítést. További hasznos linkek: - -- [Az összes Ethereum-fejlesztési javaslat (EIP) listája](https://eips.ethereum.org/all) -- [Az összes EIP-típus leírása](https://eips.ethereum.org/EIPS/eip-1#eip-types) -- [Az összes EIP-állapot leírása](https://eips.ethereum.org/EIPS/eip-1#eip-process) - -### Közösségi oktatási projektek {#community-projects} - -- [PEEPanEIP](https://www.youtube.com/playlist?list=PL4cwHXAawZxqu0PKKyMzG_3BJV_xZTi1F) — *PEEPanEIP egy oktatási videosorozat, amely megtárgyalja az Ethereum-fejlesztési javaslatokat (EIP) és a következő frissítések főbb jellemzőit.* -- [EIPs For Nerds](https://ethereum2077.substack.com/t/eip-research) — *Az EIPs For Nerds átfogó, egyszerűen megfogalmazott áttekintést nyújt az Ethereum-fejlesztési javaslatokról (EIP), beleértve a főbb javaslatokat, az alkalmazás-/infrastruktúra-rétegre vonatkozókat (ERC), hogy tájékoztatást nyújtson és konszenzust teremtsen a Ethereum-protokoll javasolt változásai kapcsán.* -- [EIPs.wtf](https://www.eips.wtf/) — *Az EIPs.wtf további információkat ad az Ethereum-fejlesztési javaslatokról (EIP), beleértve azok státuszát, bevezetési részleteit, a kapcsolódó pull request-eket (PR) és a közösség visszajelzéseit.* -- [EIP.Fun](https://eipfun.substack.com/) — *Az EIP.Fun az Ethereum-fejlesztési javaslatokról (EIP) ad friss híreket, a kapcsolódó EIP megbeszélésekről és más dolgokról tudósít.* -- [EIPs Insight](https://eipsinsight.com/) — *Az EIPs Insight az Ethereum-fejlesztési javaslatok (EIP) státuszáról ad folyamatjellegű és statisztikai adatokat különböző forrásokból.* - -## Részvétel {#participate} - -Bárki létrehozhat EIP-t. A javaslat beküldése előtt el kell olvasni az [EIP-1](https://eips.ethereum.org/EIPS/eip-1) frissítést, amely leírja az EIP-folyamatot és az EIP megírásának módját, továbbá visszajelzést kell kérni az [Ethereum Mágusok](https://ethereum-magicians.org/) weboldalán, ahol a tervezet benyújtása előtt a közösséggel együtt megvitatják a javaslatokat. - -## Hivatkozások {#references} - - - -Az oldal tartalmát részben az [Ethereum Protocol Development Governance and Network Upgrade Coordination](https://hudsonjameson.com/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) szolgáltatta Hudson Jameson által - - diff --git a/public/content/translations/hu/11) Roadmap/roadmap/beacon-chain/index.md b/public/content/translations/hu/11) Roadmap/roadmap/beacon-chain/index.md deleted file mode 100644 index c1f0b5751b4..00000000000 --- a/public/content/translations/hu/11) Roadmap/roadmap/beacon-chain/index.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: A Beacon Chain -description: Tudjon meg többet Beacon a láncról – arról a frissítésről, amely behozta a proof-of-stake mechanizmust az Ethereum hálózatára. -lang: hu -template: upgrade -image: /images/upgrades/core.png -alt: -summaryPoint1: A Beacon lánc vezette be a proof-of-stake konszenzust az Ethereum-ökoszisztémába. -summaryPoint2: Az eredeti proof-of-work Ethereum-lánccal 2022 szeptemberében egyesült. -summaryPoint3: A Beacon lánc vezette be az Ethereumot ma biztosító konszenzuslogikát és block gossip (blokkpletyka) protokollt. ---- - - - A Beacon lánc 2020. december 1-jén jelent meg, és 2022 szeptember 15-én a beolvadás frissítéssel hivatalosan is az Ethereum konszenzusmechanizmusává tette a proof-of-stake módszert. - - -## Mi az a Beacon lánc? {#what-is-the-beacon-chain} - -A Beacon lánc az eredeti proof-of-stake blokklánc neve, amit 2020-ban vezettek be. Azért hozták létre, hogy meggyőződjenek a proof-of-stake konszenzuslogika stabilitásáról és fenntarthatóságáról, mielőtt az Ethereum fő hálózatára is bevezetnék azt. Éppen ezért az eredeti proof-of-work Ethereum-lánccal párhuzamosan futtatták. A Beacon lánc egy üres blokkokból álló lánc volt, de a proof-of-work leváltásával és a proof-of-stake mechanizmusra való átállásával az Ethereum megkövetelte, hogy a Beacon lánc fogadja a végrehajtói kliensek tranzakcióit, ezután blokkokba, majd egy proof-of-stake alapú konszenzusmechanizmus felhasználásával blokkláncba rendezze azokat. Ugyanebben a pillanatban az eredeti Ethereum-kliensek leállították a bányászatot, a blokk-előterjesztési és konszenzuslogikát, és mindent átadtak a Beacon láncnak. Ez volt az az esemény, amely [A Beolvadás](/roadmap/merge/) nevet kapta. A Beolvadás után nem volt többé két blokklánc. Csak egy proof-of-stake-alapú Ethereum, ami most két különböző klienst igényel minden csomóponthoz. A Beacon lánc most a konszenzusréteg, a konszenzuskliensek peer-to-peer hálózata, amely a blokkpletykát és a konszenzuslogikát kezeli, miközben az eredeti kliensek alkotják a végrehajtási réteget, amely a pletykálásért és a tranzakciók végrehajtásáért felel, illetve az Ethereum státuszát kezeli. A két réteg az Engine API révén kommunikál egymással. - -## Mire szolgál a Beacon lánc? {#what-does-the-beacon-chain-do} - -Beacon lánc a neve annak a számlafőkönyvek, amely az Ethereum-[letétesek](/staking/) hálózatát működtette és koordinálta, mielőtt ezek a letétesek megkezdték a valódi Ethereum-tranzakciók validálását. Nem kezel tranzakciókat vagy okosszerződés-interakciókat, mert ezt a végrehajtási réteg végzi. A Beacon lánc felel a blokk és tanúsítás kezeléséért, az elágazásválasztás algoritmusát futtatja, valamint a jutalmakat és büntetéseket adja. Bővebben a [csomópont-architektúra oldalon](/developers/docs/nodes-and-clients/node-architecture/#node-comparison). - -## A Beacon lánc hatása {#beacon-chain-features} - -### Letétbe helyezés bevezetése {#introducing-staking} - -A Beacon lánc vezette be a [proof-of-stake-et](/developers/docs/consensus-mechanisms/pos/) az Ethereum rendszerébe. Ez tartja fent az Ethereum biztonságát, és a folyamat során a validátorokat több ETH-hoz juttatja. A gyakorlatban a letétbe helyezés úgy néz ki, hogy ETH-t helyez letétbe a validátorszoftver aktiválásához. Letétesként futtatja a szoftvert, amely új blokkokat hoz létre és validál a láncon. - -A letétbe helyezés hasonló célt szolgál, mint korábban a [bányászat](/developers/docs/consensus-mechanisms/pow/mining/), de számos tekintetben különbözik attól. A bányászat nagy összegű kezdeti kiadásokkal járt, nagy teljesítményű hardverek beszerzésével és nagy energiafogyasztással, ami a tehetősebbeknek kedvezett, és elősegítette a centralizációt. Emellett a bányászat nem követelte meg a fedezetként szolgáló eszközök zárolását, ezzel korlátozta a protokoll képességét a rosszindulatú szereplők megbüntetésére egy támadás után. - -A proof-of-stake mechanizmusra való áttérés jelentősen fokozta az Ethereum biztonságát és decentralizációját a proof-of-work rendszerhez képest. Minél több ember vesz részt a hálózatban, annál decentralizáltabb és védettebb lesz a támadásokkal szemben. - -A proof-of-stake használata, mint konszenzusmechanizmus, egy alapvető komponens [a ma használt biztonságos, környezetbarát és skálázható Ethereum számára](/roadmap/vision/). - - - Ha Ön szeretne validátorrá válni és segítene az Ethereum biztosításában, akkor tudjon meg többet a letétbe helyezésről. - - -### Felkészülés a szilánkolásra {#setting-up-for-sharding} - -Amióta a Beacon lánc egybeolvadt az eredeti Ethereum-főhálózattal, az Ethereum közössége elkezdte keresni a lehetőséget a hálózat méretezésére. - -A proof-of-stake-nek megvan az az előnye, hogy naprakész nyilvántartása van az összes jóváhagyott blokkelőállítókról, akik mind rendelkeznek ETH-letéttel. Ez a nyilvántartás a konkrét hálózati felelősségi körök megbízható felosztása mellett megalapozza az „oszd meg és uralkodj” ideát. - -Ez a felelősség ellentétben áll a proof-of-work rendszerével, ahol a bányászoknak semmilyen kötelezettségük nem volt a hálózat felé, és bármikor, mindenféle következmény nélkül felhagyhattak a bányászattal, végleg lekapcsolva a csomópontszoftvert. Ebben a rendszerben nyilvántartás sincs az ismert blokkelőterjesztőkről, és nincs megbízható módja a hálózati felelősségi körök biztonságos felosztásának. - -[A szilánkolásról bővebben](/roadmap/danksharding/) - -## A frissítések közötti kapcsolat {#relationship-between-upgrades} - -Az Ethereum-frissítések némileg összefüggnek egymással. Foglaljuk össze, hogyan hat a Beacon lánc a többi frissítésre. - -### A Beacon lánc és a beolvadás {#merge-and-beacon-chain} - -A Beacon lánc először az Ethereum fő hálózatától különállóan létezett, de 2022-ben egybeolvadtak. - - - A beolvadás - - -### Szilánkok és a Beacon lánc {#shards-and-beacon-chain} - -A láncszilánkokat csak működő proof-of-stake konszenzusmechanizmussal lehet biztonságosan bevezetni az Ethereum-ökoszisztémába. A Beacon lánc bevezette a letétbe helyezést, ami „egybeolvadt” a fő hálózattal, egyengetve az utat a szilánkolás előtt, amellyel tovább méretezhető az Ethereum. - - - Láncszilánkok - - -## További olvasnivaló - -- [Az Ethereum jövőbeni frissítéseiről bővebben](/roadmap/vision) -- [Bővebben a csomópont-architektúráról](/developers/docs/nodes-and-clients/node-architecture) -- [Bővebben a proof-of-stake-ről](/developers/docs/consensus-mechanisms/pos) diff --git a/public/content/translations/hu/11) Roadmap/roadmap/future-proofing/index.md b/public/content/translations/hu/11) Roadmap/roadmap/future-proofing/index.md deleted file mode 100644 index 673f160d696..00000000000 --- a/public/content/translations/hu/11) Roadmap/roadmap/future-proofing/index.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Jövőálló Ethereum -description: Ezek a fejlesztések az Ethereumot ellenálló, decentralizált alapréteggé teszik a jövő számára, bármit is hozzon az. -lang: hu -image: /images/roadmap/roadmap-future.png -alt: "Ethereum-ütemterv" -template: roadmap ---- - -Az ütemterv néhány eleme nem feltétlenül a skálázáshoz vagy a biztonsághoz tartozik, hanem stabilizálja és a jövőben is megbízhatóvá teszi az Ethereumot. - -## A kvantumnak való ellenállóság {#quantum-resistance} - -A jelenlegi Ethereumot biztosító [kriptográfia](/glossary/#cryptography) egy része veszélybe kerül, amikor a kvantumszámítás valósággá válik. Habár a kvantum számítógépek valószínűleg évtizedekre vannak attól, hogy valódi veszélyt jelentsenek a modern kriptográfiának, az Ethereumot úgy építik, hogy évszázadokig működjön. Tehát az [Ethereumot ellenállóvá kell tenni a kvantummal](https://consensys.net/blog/developers/how-will-quantum-supremacy-affect-blockchain/) szemben, amilyen gyorsan csak lehet. - -Az Ethereum fejlesztői előtt álló kihívás az, hogy a jelenlegi [proof-of-stake](/glossary/#pos) protokoll egy nagyon hatékony aláírási rendszerre, a BLS-re támaszkodik az érvényes [blokkok](/glossary/#block) szavazatainak összesítésére. Ezt az aláírási sémát a kvantum számítógép fel tudja törni, de a kvantumnak ellenálló verziók nem olyan hatékonyak. - -A [KZG elköteleződési sémák](/roadmap/danksharding/#what-is-kzg) számos helyen megtalálhatók az Ethereumban, hogy kriptográfiai titkokat állítsanak elő, és ezek sebezhetők a kvantummal szemben. Jelenleg ezt úgy kerülik meg, hogy bizalmat igénylő összeállítást használnak, tehát több entitás állítja elő a véletlenszerűséget, amit nem tud a kvantum számítógép visszakövetni. Azonban az ideális megoldás a kvantumbiztos kriptográfia lenne. Két vezető megközelítés létezik, amely képes lenne a BLS-sémát helyettesíteni: a [STARK-alapú](https://hackmd.io/@vbuterin/stark_aggregation) és a [háló alapú](https://medium.com/asecuritysite-when-bob-met-alice/so-what-is-lattice-encryption-326ac66e3175) aláírás. **Ezek kutatása és prototípusa még folyamatban van**. - - Tudjon meg többet a KZG-ről és a bizalmat igénylő összeállításról - -## Egyszerűbb és hatékonyabb Ethereum {#simpler-more-efficient-ethereum} - -A komplexitás teret ad a hibáknak vagy a sebezhetőségnek, amit a támadók ki tudnak használni. Ezért a ütemtervnek része az Ethereum leegyszerűsítése, valamint az olyan kódok eltávolítása, amelyek szükségtelenek vagy amelyeket már most tovább lehet fejleszteni. A jól átlátható, egyszerű kódbázis könnyebb fenntarthatóságot tesz lehetővé a fejlesztők számára. - -Számos fejlesztést fognak eszközölni az [Ethereum Virtuális Géppel (EVM)](/developers/docs/evm) kapcsolatban, hogy egyszerűbb és hatékonyabb legyen. Ezek között megtalálható a [ SELFDESTRUCT operációskód eltávolítása](https://hackmd.io/@vbuterin/selfdestruct) – egy ritkán használt utasítás, amelyre már nincs szükség, és még veszélyes is lehet, főleg más várható fejlesztéseket illetően az Ethereum-tárolási modelljét tekintve. Az [Ethereum-kliensek](/glossary/#consensus-client) továbbra is támogatnak néhány régi tranzakciótípust, amelyek most már teljesen eltávolíthatók. A [gáz](/glossary/#gas) számítási módja is javítható, és hatékonyabb módszerek alkalmazhatók egyes kriptográfiai műveletek aritmetikai alátámasztására. - -Hasonlóan, az Ethereum-kliensek más részeit is frissíteni lehet. Például a végrehajtási és konszenzusos kliensek más adattömörítést használnak. Könnyebb és intuitívabb a kliensek közötti adatmegosztás, ha a sémák egységesek az egész hálózaton keresztül. - -## Jelenlegi helyzet {#current-progress} - -Az Ethereum jövőbiztosságának biztosításához szükséges frissítések többsége **még a kutatási fázisban van, és több év múlva is lehet** a megvalósítás. Az olyan frissítések, mint a SELFDESTRUCT eltávolítása, valamint a végrehajtási és konszenzusos kliensben lévő tömörítési séma egységesítése valószínűleg hamarabb megtörténik, mint a kvantumnak ellenálló kriptográfia megvalósítása. - -**További olvasnivaló** - -- [Gáz](/developers/docs/gas) -- [EVM](/developers/docs/evm) -- [Adatstruktúrák](/developers/docs/data-structures-and-encoding) diff --git a/public/content/translations/hu/11) Roadmap/roadmap/index.md b/public/content/translations/hu/11) Roadmap/roadmap/index.md deleted file mode 100644 index 6bf75328c3b..00000000000 --- a/public/content/translations/hu/11) Roadmap/roadmap/index.md +++ /dev/null @@ -1,119 +0,0 @@ ---- -title: Ethereum-ütemterv -description: Az út, amely az Ethereum jobb skálázhatóságához, biztonságához és fenntarthatóságához vezet. -lang: hu -template: roadmap -image: /images/heroes/roadmap-hub-hero.jpg -alt: "Ethereum-ütemterv" -summaryPoints: -buttons: - - - content: Várható fejlesztések - toId: what-changes-are-coming - - - content: Korábbi fejlesztések - href: /history/ - variant: vázlat ---- - -Az Ethereum jelenleg is a globális koordináció erőteljes platformja, de még mindig szükség van további fejlesztésekre. Az ambiciózus fejlesztéseknek köszönhetően a jelenlegi forma helyett egy teljesen skálázható és maximálisan rugalmas Ethereum-platform fog kibontakozni. Ezeket a fejlesztéseket az Ethereum ütemterve ismerteti. - -**A korábbi Ethereum-fejlesztéseket [Az Ethereum története](/history/) oldalon láthatja** - -## Milyen változások várhatók az Ethereumon? {#what-changes-are-coming} - -Az Ethereum ütemterve a jövőbeli, protokollt érintő, specifikus fejlesztéseket vázolja fel. Összességében ez az ütemterv a következő előnyöket hozza el az Ethereum felhasználói számára: - - - - - - - - -## Miért van szüksége az Ethereumnak egy ütemtervre? {#why-does-ethereum-need-a-roadmap} - -Az Ethereumot folyamatosan fejlesztik, hogy javítsák a skálázhatóságot, a biztonságot vagy a fenntarthatóságot. Az Ethereum egyik fő erőssége az, hogy képes a kutatás és fejlesztés során felmerült új ötleteket bevezetni. Ez az alkalmazkodóképesség adja az Ethereum rugalmasságát, hogy kezelni tudja a felmerülő kihívásokat és lépést tudjon tartani a legfejlettebb technológiai áttörésekkel. - - - -Az ütemterv a kutatók és fejlesztők több évnyi munkájának eredménye, mivel a protokoll maga nagyon technikai, de emellett bárki, aki elég elkötelezett, részt vehet benne. Az ötletek általában beszélgetés formájában kezdődnek a fórumokon, mint amilyen az ethresear.ch (https://ethresear.ch/), az Ethereum Magicians (https://ethereum-magicians.org/) vagy az Eth R&D discord szerver. <0>A teljes hontalanság még a kutatási fázisban van, és valószínűleg több év múlva kerül végrehajtásra. Miután ezeket az ötleteket kellőképpen körüljárták, javaslatot készíthetnek belőlük: [Ethereum-fejlesztési javaslatok (EIP)](https://eips.ethereum.org/). Ez az egész folyamat nyilvános, így a közösség bármelyik tagja mérlegelheti a javaslatokat. - -[Bővebben az Ethereum irányításáról](/governance/) - - - - -

Mi volt az ETH2?

- -

Az „Eth2” kifejezéssel az Ethereum jövőjére hivatkoztak, mielőtt még áttért volna a proof-of-stake mechanizmusra, de elhagyták ezt a kifejezést, hogy sokkal pontosabb terminológiát használjanak helyette. Eredetileg az átállás előtti és utáni állapot megkülönböztetésére használták, vagy néha a különböző Ethereum-kliensekre (a végrehajtási kliensek néha ETH1-kliensként, a konszenzuskliensek pedig ETH2-kliensként jelentek meg).

- - - -## Fog változni az Ethereum ütemterve? {#will-ethereums-roadmap-change-over-time} - -**Igen, szinte biztosan**. Az ütemterv az Ethereum jelenlegi fejlesztési tervezete, amely rövid- és hosszútávú újításokat is magában foglal. Az ütemterv várhatóan változni fog, amikor új információk és technológiák válnak elérhetővé. - -Az ütemterv olyan, mint a fejlesztési szándékok készlete, vagyis a kutatók és a fejlesztők által feltételezett legoptimálisabb út az Ethereum számára. - -## Mikor vezetik be az ütemterv összes fejlesztését? {#when-will-the-roadmap-be-finished} - -Egyes frissítések alacsonyabb prioritásúak, és valószínűleg csak a következő 5–10 évben valósulnak meg (pl. a kvantumellenálláshoz kapcsolódók). **A fejlesztésekhez nehéz lenne pontos időpontot hozzárendelni**, mivel az ütemterv számos elemének kifejlesztése párhuzamosan folyik és különböző sebességgel valósulnak meg. Egy adott fejlesztés prioritása külső tényezők miatt (pl. a kvantumszámítógépek teljesítményének és elérhetőségének hirtelen fejlődése fontosabbá teszi az ezeknek ellenálló kriptográfiát) is változhat. - -Az Ethereum fejlesztésre úgy is tekinthetünk, mint a biológiai fejlődésre. Az a hálózat sokkal sikeresebb lehet, amelyik alkalmazkodik az új kihívásokhoz és fenntartja fittségét, mint az, amely ellenáll a változásnak, ugyanakkor a jó teljesítmény, skálázhatóság és biztonság elérése után egyre kevesebb protokollváltoztatásra lesz szükség. - -## Van-e bármi teendője a felhasználóknak a fejlesztések bevezetésekor? {#do-i-have-to-do-anything-when-there-is-an-upgrade} - -A fejlesztések általában nem érintik a felhasználókat, kivéve, hogy jobb felhasználói élményt, biztonságosabb protokollt és több opciót biztosítanak az Ethereummal való kapcsolódásra. **A rendszeres felhasználóknak nem kell aktívan részt venniük a frissítésben, és semmit sem kell tenniük** eszközeik biztonsága érdekében. A [csomópont](/glossary/#node)-operátoroknak frissíteniük kell klienseiket, hogy felkészüljenek a frissítésre. Néhány fejlesztés az alkalmazásfejlesztők számára is változást jelent. Például az olyan fejlesztések esetében, amelyek a korábbi adatok elérhetőségét érintik, az alkalmazásfejlesztőknek máshonnan kell beszerezniük az előzményadatokat. - -## Mi a helyzet a Verge, Splurge stb. fejlesztésekkel? {#what-about-the-verge-splurge-etc} - -[Vitalik Buterin egy elképzelést javasolt az Ethereum ütemtervéhez](https://twitter.com/VitalikButerin/status/1741190491578810445), amelyet az Ethereum architektúrára gyakorolt hatásai alapján több kategóriába soroltak. Ennek részei: - -- **Az összevonás**: a [munkaigazolásról](/glossary/#pow) a [tét igazolására](/glossary/#pos) való átállással kapcsolatos frissítések -- **The Surge**: a méretezhetőséghez kapcsolódó frissítések [összegzésekkel](/glossary/#rollups) és adatfelosztással -- **A csapás**: a [MEV](/glossary/#mev) cenzúraellenállásával, decentralizációjával és protokollkockázataival kapcsolatos frissítések -- **The Verge**: a [blokkok](/glossary/#block) egyszerűbb ellenőrzéséhez kapcsolódó frissítések -- **A tisztítás**: a csomópontok futtatásának számítási költségeinek csökkentésével és a protokoll egyszerűsítésével kapcsolatos frissítések -- **The Splurge**: egyéb frissítések, amelyek nem illeszkednek jól az előző kategóriákba. - -Ezen terminológia helyett inkább egyszerűbb és felhasználóközpontú modellt használunk. Ennek ellenére a vízió ugyanaz, amit Vitalik javasolt, csak egyszerűbb szavakkal hivatkozunk rá. - -## Mi a helyzet a shardinggal? {#what-about-sharding} - -A megosztás felosztja az Ethereum blokkláncot, így az [ellenőrzők](/glossary/#validator) részhalmazai csak a teljes adat töredékéért felelősek. Ez volt az eredeti elképzelés az Ethereum skálázhatóságára vonatkozóan. A [2. rétegű](/glossary/#layer-2) összesítések azonban a vártnál sokkal gyorsabban fejlődtek, és már sok skálázást biztosítottak, és sokkal többet fognak nyújtani a Proto-Danksharding megvalósítása után. Tehát a shard-láncokra nincs többé szükség, ez a fejlesztés már nem része az ütemtervnek. - -## Specifikus technikai fejlesztéseket keres? {#looking-for-specific-technical-upgrades} - -- [Danksharding](/roadmap/danksharding) – A Danksharding lehetővé teszi, hogy az L2 összevont tranzakciói sokkal olcsóbbak legyenek, mivel adatblobokat illeszt az Ethereum-blokkokhoz. -- [Letétek kivonása](/staking/withdrawals) – A Shanghai/Capella-frissítésnél jelent meg az Ethereumon a letétek kivonásának lehetősége, így bárki felszabadíthatja a letétbe helyezett ETH-egyenlegét. -- [Egy sloton belüli véglegesítés](/roadmap/single-slot-finality) – Ahelyett, hogy egy blokk javaslásához tizenöt perc kellene, azt ugyanabban a slotban lehessen javasolni és véglegesíteni. Ez kényelmesebb megoldást jelentene az alkalmazások számára, és nehezebb lenne megtámadni. -- [Javaslattevő-építő szétválasztás (PBS)](/roadmap/pbs) – A blokk építésének és előterjesztésének feladata több validátor között oszlik meg, így az Ethereum konszenzus tisztább, cenzúramentesebb és hatékonyabb lesz. -- [Titkos vezetőválasztás](/roadmap/secret-leader-election) – Okos kriptográfia biztosítaná, hogy az aktuális blokkelőterjesztő személye nem kerül nyilvánosságra, így védve lesznek bizonyos támadásoktól. -- [Számlaabsztrakció](/roadmap/account-abstraction) – A számlaabsztrakció a fejlesztések azon csoportja, amely az Ethereum részeként, nem pedig egy összetett közvetítő használatával támogatja az okosszerződéses tárcákat. -- [Verkle-fák](/roadmap/verkle-trees) – A Verkle-fák olyan adatstruktúrák, amelyek lehetővé teszik a státusztalan kliensek használatát az Ethereumon. Ezek a kliensek csak kis tárhelyet igényelnek, de képesek az új blokkok validálására. -- [Státusztalanság](/roadmap/statelessness) – A státusztalan kliensek képesek validálni az új blokkokat anélkül, hogy nagy adatmennyiségeket kellene tárolniuk. Ezzel a csomópontok a mai költség töredékéért működtethetők, az általuk nyújtott előnyök elvesztése nélkül. diff --git a/public/content/translations/hu/11) Roadmap/roadmap/merge/index.md b/public/content/translations/hu/11) Roadmap/roadmap/merge/index.md deleted file mode 100644 index 59c38ec9f1b..00000000000 --- a/public/content/translations/hu/11) Roadmap/roadmap/merge/index.md +++ /dev/null @@ -1,229 +0,0 @@ ---- -title: A beolvadás -description: További információ a beolvadásról – amikor az Ethereum fő hálózata áttért a proof-of-stake konszenzusra. -lang: hu -template: upgrade -image: /images/upgrades/merge.png -alt: -summaryPoint1: Az Ethereum fő hálózata proof-of-stake konszenzust használ, ám ez nem mindig volt így. -summaryPoint2: Az áttérés az eredeti proof-of-work mechanizmusról a proof-of-stake mechanizmusa a beolvadás nevet kapta. -summaryPoint3: A Beolvadás az eredeti Ethereum-főhálózat összeolvadását jelenti a Beacon lánc nevű különálló proof-of-stake blokklánccal, amelyek most már egy láncként léteznek. -summaryPoint4: A Beolvadás nagyjából 99,95%-kal csökkentette az Ethereum energiafogyasztását. ---- - - - A beolvadás 2022. szeptember 15-én ment végbe. Ezzel lezárult az Ethereum áttérése a proof-of-stake konszenzusra, így hivatalosan is elhagyta a proof-of-work mechanizmust, és nagyjából 99,95%-kal csökkentette az energiafogyasztását. - - -## Mi volt a beolvadás? {#what-is-the-merge} - -A beolvadás az Ethereum eredeti végrehajtási rétegének (a [genezis](/history/#frontier) óta létező fő hálózatnak) az összeolvadása volt az új proof-of-stake konszenzusréteggel, a Beacon lánccal. Ezzel szükségtelenné vált az energiaintenzív bányászat, és megnyílt a hálózat biztosításának lehetősége letétbe helyezett ETH felhasználásával. Igazán izgalmas lépés volt ez az Ethereum jövőképének – nagyobb méretezhetőség, biztonság és fenntarthatóság – megvalósítása felé vezető úton. - - - -A [Beacon lánc](/roadmap/beacon-chain/) és a [fő hálózat](/glossary/#mainnet) eredetileg külön működött. Az Ethereum-főhálózat biztonságát – az összes számlájával, egyenlegével, okosszerződésével és blokkláncállapotával együtt – továbbra is a [proof-of-work](/developers/docs/consensus-mechanisms/pow/) konszenzus szolgáltatta, még akkor is amikor a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) mechanizmust használó Beacon lánc vele párhuzamosan futott. A beolvadás volt az esemény, amikor ez a két rendszer végre egyesült, és a proof-of-work helyét végleg átvette a proof-of-stake. - -Képzeljük el, hogy az Ethereum egy űrhajó, amely még azelőtt felszállt, hogy igazán készen állt volna a csillagközi utazásra. A Beacon lánccal a közösség egy új hajtóművet és egy erősebb hajótestet épített. Jelentős tesztelést követően eljött az ideje, hogy a régi hajtóművet menet közben kicseréljék az újra. Ezzel az új, hatékonyabb hajtómű beolvadt a már meglévő hajóba, megteremtve a lehetőséget, hogy súlyos fényéveket tegyen meg, és nyakába vegye az univerzumot. - -## Összeolvadás a fő hálózattal {#merging-with-mainnet} - -A proof-of-work mechanizmus biztosította az Ethereum-főhálózatot a születésétől a beolvadásig. Ez tette lehetővé, hogy az általunk jól ismert Ethereum-blokklánc 2015 júliusában az összes ismerős funkciójával együtt (tranzakciók, okosszerződések, számlák stb.) létrejöjjön. - -A fejlesztők az Ethereum története során végig készültek arra, hogy egyszer majd áttérnek a proof-of-work konszenzusról a proof-of-stake mechanizmusra. 2020. december 1-jén a fő hálózattól elkülönült, vele párhuzamosan működő blokkláncként létrejött a Beacon lánc. - -A Beacon lánc eredetileg nem kezelte a fő hálózat tranzakcióit. Ehelyett a saját állapotát illetően jutott konszenzusra az aktív validátorok számlaegyenlegekre vonatkozó egyetértésén keresztül. Mélyreható tesztelést követően eljött az ideje, hogy a Beacon lánc való világbeli adatokkal kapcsolatban is konszenzusra jusson. A beolvadás után a Beacon lánc lett az összes hálózati adat konszenzusmotorja, beleértve a végrehajtási réteg tranzakcióit és számlaegyenlegeit is. - -A beolvadás jelentette a hivatalos váltást, amely után a Beacon lánc tölti be a blokkelőállítás hajtómotorjának szerepét. Az érvényes blokkok előállításának módja többé már nem a bányászat. Ehelyett a proof-of-stake validátorok vették át ezt a szerepet, és most már ők felelnek a tranzakciók validálásának végrehajtásáért és az új blokkok előterjesztéséért. - -Az előzmények nem vesztek el a beolvadással. Ahogy a fő hálózat egyesült a Beacon lánccal, az Ethereum összes tranzakcióelőzményét is magával vitte. - - -A proof-of-stake mechanizmus átvétele megváltoztatta az Ether kibocsátásának módját. Tudjon meg többet: Ether-kibocsátás a beolvadás előtt és után. - - -### Felhasználók és tulajdonosok {#users-holders} - -**A beolvadás nem hozott változást a tulajdonosok/felhasználók számára.** - -_Erre ráfér az ismétlés_: az ETH vagy az Ethereum hálózatán található bármely egyéb digitális eszköz felhasználójaként vagy tulajdonosaként, valamint nem csomópont-operátor letétesként **semmit sem kell tennie a pénzeszközeivel vagy a tárcájával a beolvadás kapcsán.** Az ETH egyszerűen csak ETH. Nincs olyan, hogy „régi ETH”/„új ETH” vagy olyan, hogy „ETH1”/„ETH2”, és a tárcák a beolvadás után is pontosan ugyanúgy működnek, mint azelőtt. Akik mást állítanak, valószínűleg csalók. - -Annak ellenére, hogy lecserélte a proof-of-work mechanizmust, az Ethereum összes előzménye – a létrejöttéig visszamenőleg – változatlan formában megmaradt a proof-of-stake-re való áttérés során. A beolvadás előtt az Ön tárcájában lévő eszközök a beolvadást követően is elérhetők. **Az ön részéről semmilyen frissítési intézkedés nem szükséges.** - -[Az Ethereum biztonságáról bővebben](/security/#eth2-token-scam) - -### Csomópont-operátorok és dapp-fejlesztők {#node-operators-dapp-developers} - - - -A fő intézkedési elemekhez tartoznak az alábbiak: - -1. Futtasson _egyidejűleg_ egy konszenzusklienst és egy végrehajtási klienst; a harmadik fél végpontok a beolvadás után már nem tudnak végrehajtási adatokat szerezni. -2. A végrehajtási és a konszenzusklienst is egy megosztott JWT titkos kulccsal hitelesítse, hogy biztonságosan tudjanak kommunikálni. -3. Állítson be egy „díj címzettje” címet a kapott tranzakciós illetéktételek/MEV fogadásához. - -Ha a fenti felsorolás első két elemét nem teljesíti, akkor a csomópontja „offline” állapotot mutat majd, amíg mindkét réteg szinkronizálása és hitelesítése be nem fejeződik. - -Ha nem állít be egy „díj címzettje” címet, attól még a validátor a szokásos módon tud működni, de Ön lemarad az el nem égetett díjtételekről/MEV-ről, amelyeket egyébként megkapott volna a validátora által előterjesztett blokkokkal. - - - - -Egészen a beolvadásig egy végrehajtási kliens (például: Geth, Erigon, Besu vagy Nethermind) elég volt ahhoz, hogy valaki fogadja, megfelelően validálja és propagálja a hálózaton terjedő blokkokat. _A beolvadás óta_ egy végrehajtási csomagban található tranzakciók érvényessége az őket tartalmazó „konszenzusblokk” érvényességétől is függ. - -Ennek eredményeképpen egy teljes Ethereum-csomóponthoz most már végrehajtási kliens és egy konszenzuskliens is szükséges. Ez a két kliens egy új motor-API segítségével működik együtt. A motor-API JWT titkos kulcsot használó hitelesítést igényel. A kulcsot mindkét kliens megkapja, ami biztonságos kommunikációt tesz lehetővé. - -A fő intézkedési elemekhez tartoznak az alábbiak: - -– konszenzuskliens telepítése a végrehajtási kliens mellé -– végrehajtási és konszenzuskliens hitelesítése megosztott JWT titkos kulccsal, hogy biztonságosan kommunikálhassanak egymással. - -Ha a fenti felsorolás elemeit nem teljesíti, akkor a csomópontja „offline” állapotúnak tűnik majd, amíg mindkét réteg szinkronizálása és hitelesítése be nem fejeződik. - - - - - -A Beolvadás megváltoztatta a konszenzust, amely a következőkre is hatott:< - -
    -
  • blokkstruktúra
    • -
  • slot-/blokkidőzítés
    • -
  • operációskód-változások
    • -
  • a láncon belüli véletlenszerűség forrása
    • -
  • a biztonságos fejléc és a véglegesített blokkok koncepciója
    • -
- -További információért nézze meg Tim Beiko blog postját: Hogyan érinti a Beolvadás az Ethereum alkalmazási rétegét. - - - -## A beolvadás és az energiafogyasztás {#merge-and-energy} - -A beolvadás a proof-of-work végét jelentette az Ethereum számára, valamint egy fenntarthatóbb, környezetbarátabb Ethereum kezdetét. Az Ethereum energiafogyasztása nagyjából 99,95%-kal csökkent, ezzel az Ethereum zöld blokklánc lett. Tudjon meg többet az [Ethereum energiafogyasztásáról](/energy-consumption/). - -## A beolvadás és a méretezhetőség {#merge-and-scaling} - -A beolvadás a további méretezhetőségi fejlesztések lehetőségét is megteremtette, amelyek a proof-of-work konszenzus mellett lehetetlenek voltak, egy lépéssel közelebb hozva az Ethereumot az [Ethereum-jövőképben](/roadmap/vision/) felvázolt méretezési, biztonsági és fenntarthatósági célok eléréséhez. - -## Téveszmék a beolvadásról {#misconceptions} - - - -Két típusú Ethereum-csomópont létezik: olyanok, amelyek képesek blokkjavaslatot tenni, és olyanok, amelyek nem. - -A blokkot előterjesztő csomópontok csak kis részét adják az Ethereum hálózatán működő csomópontoknak. Ebbe a kategóriába tartoznak a proof-of-work (PoW) mechanizmus bányászcsomópontjai és a proof-of-stake (PoS) mechanizmus validátor-csomópontjai. Ez a kategória megköveteli a gazdasági erőforrások elkülönítését (például GPU hash-teljesítményt a proof-of-work mechanizmus alatt, illetve ETH-letétbe helyezést a proof-of-stake mechanizmus mellett) cserébe azért, hogy az operátor alkalomadtán javaslatot tehessen a következő blokkra, és megkaphassa a protokolljutalmakat. - -A hálózat többi csomópontja (tehát a csomópontok többsége) nem köteles gazdasági erőforrásokat feláldozni egy átlagos személyi számítógépen, 1-2 TB elérhető tárhelyen és egy internetkapcsolaton túl. Ezek a csomópontok nem terjesztenek elő blokkjavaslatokat, mégis kritikus szerepet játszanak a hálózat biztosításában azzal, hogy a blokkelőterjesztőket szemmel tartva vizsgálják az újonnan érkező blokkokat, és hálózat konszenzusszabályaival összhangban ellenőrzik azok érvényességét. Ha a blokk érvényes, akkor a csomópont propagálja azt a hálózaton keresztül. Ha a blokk bármilyen okból kifolyólag érvénytelen, akkor a csomópont szoftverje figyelmen kívül hagyja azt, és nem folytatja a propagálását. - -Egy nem blokk-készítő csomópontot bárki futtathat, működjön bármilyen konszenzusmechanizmus szerint is (proof-of-work vagy proof-of-stake); de aki megteheti, azt erőteljesen bátorítják. Egy csomópont futtatása hihetetlen értékkel bír az Ethereum számára, és előnyöket biztosít a csomópontot futtató egyén számára is, például nagyobb biztonságot, adatvédelmet és ellenálló képességet a cenzúrával szemben. - -Az Ethereum-hálózat decentralizációjának fenntartásához rendkívül lényeges az a képesség, hogy bárki tudjon saját csomópontot működtetni. - -Bővebben a saját csomópont működtetéséről - - - - - -A gasdíjak a hálózati teljesítmény iránti kereslet és a hálózati kapacitás egymáshoz viszonyított változásának eredményeként alakulnak. A beolvadással megszűnt a proof-of-work mechanizmus használata, és áttértünk a proof-of-stake konszenzusra, ám a hálózati kapacitást vagy feldolgozóképességet közvetlenül érintő paraméterekben jelentős változás nem következett be. - -A összevonttranzakció-centrikus fejlesztési tervvel az erőfeszítések oda irányultak, hogy a felhasználói aktivitást az L2-n tegyék skálázhatóvá, miközben lehetővé teszik, hogy az L1 főhálózat egy biztonságos, decentralizált réteg, ami optimális az összevont tranzakciós adatok tárolására, így azok használata exponenciálisan olcsóbb lehet. Ennek eléréséhez az áttérés a proof-of-stake mechanizmusra létfontosságú előfeltétel volt. Bővebben a gázról és a díjakról. - - - - -A tranzakciók „sebessége” több módon is mérhető, például az egy blokkban foglalt idővel és a véglegesítés időigényével. Ezek mindegyike változik kicsit, de a felhasználók számára ez nem észlelhető. - -Korábban, a proof-of-work konszenzus ideje alatt a cél az volt, hogy körülbelül 13,3 másodpercenként létrejöjjön egy új blokk. A proof-of-stake mechanizmussal a slotok pontosan 12 másodpercenként ismétlődnek, mind egy-egy lehetőség, hogy egy validátor közzétegyen egy blokkot. A legtöbb slothoz tartozik blokk is, de nem feltétlenül mindegyikhez (például ha egy validátor offline állapotban van). A proof-of-stake mechanizmus mellett körülbelül 10%-kal gyakrabban jön létre blokk, mint a proof-of-work mellett. Ez egy viszonylag jelentéktelen változás, amely a felhasználóknak valószínűleg nem tűnik fel. - -A proof-of-stake magával hozta a tranzakció véglegességének koncepcióját, amely korábban nem létezett. A proof-of-work rendszerében egy blokk visszafordításának nehézsége az adott tranzakció után kibányászott minden egyes blokkal exponenciálisan növekszik, de valójában sosem válik lehetetlenné. A proof-of-stake mechanizmusban a blokkok úgynevezett korszakokba (epoch) rendeződnek (6,4 perces időintervallumonként, amelyek 32 blokklehetőséget tartalmaznak), amelyekről a validátorok szavaznak. Amikor egy korszak lezárul, a validátorok szavaznak arról, hogy adott korszakot „igazolt” állapotúnak tekintsék. Ha a validátorok megegyeznek, hogy a korszakot igazolt állapotúnak tekintsék, akkor az a következő korszakban végleges állapotba kerül. A véglegesített tranzakciók visszafordítása gazdaságtalan lenne, mivel ehhez a teljes letétbe helyezett ETH-állomány több mint egyharmadát meg kellene szerezni és el kellene égetni. - - - - - -Kezdetben a Beolvadás után a letétesek csak az extra díjakat és a MEV-et kapták meg, amelyet a blokkjavaslások eredményeként nyertek. Ezek a jutalmak egy nem letéti számlára kerültek, amelyet a validátor kontrollál (aki a díjakat kapja), és azonnal elérhetők. Ezek különböznek a protokolljutalmaktól, amelyeket a validátori kötelezettségeikért kapnak. - -A Shanghai/Capella hálózatfrissítés óta a letétesek egy visszavonási számlát jelölnek ki, hogy automatikusan megkapják a letéti összeg feletti részt (32 ETH felett). Ez a fejlesztés lehetővé tette, hogy a validátor kilépjen a hálózatból, és ezzel felszabadítsa és visszakapja a teljes egyenlegét. - -Bővebben a letétek visszavonásáról - - - - -Mióta a Shanghai/Capella frissítés lehetővé tette a letétek visszavonását, minden validátort arra ösztönöznek, hogy lehívja a 32 ETH feletti letéti egyenlegét, mivel ezek a pénzeszközök nem járnak plusz hozammal, de a rendszer zárolja őket. Az APR-értéktől függően (amelyet a teljes letétbe helyezett ETH-mennyiség határoz meg) ez arra ösztönözheti őket, hogy teljesen feladják a validátori pozíciójukat és visszakérjék a teljes egyenlegüket, vagy éppen arra, hogy a jutalmaik felhasználásával növeljék a letétjüket és nagyobb hozamhoz jussanak. - -Egy fontos kikötés, hogy a validátor kilépése egy rátához van kötve, és csak eszerint léphet ki valaki egy adott korszakban (minden 6,4. percben). Ez a határérték az aktív validátorok számától függően változik, de a teljes letétbe helyezett ETH-nak kb. 0,33%-a lehet egy adott napon. - -Így nem lehet tömegesen letéti összeget kivonni. Emellett azt is megakadályozza, hogy egy potenciális támadó a letétjét felhasználva slashing-sértést kövessen el, és egyazon korszakon belül felszámolja a validátor teljes ETH-letéti egyenlegét, mielőtt a protokoll érvényesíthetné a megsemmisítési szankciót. - -Az APR értéke szándékosan dinamikus, segítségével a letétesek által alkotott piac megállapíthatja azt a kifizetési szintet, amely mellett hajlandók gondoskodni a hálózat biztonságáról. Ha ez a szint túl alacsony, akkor a validátorok a protokoll által korlátozott tempóban kilépnek. Ez fokozatosan megemeli az APR értékét a maradók számára, ami új vagy visszatérő letéteseket eredményez majd. - - -## Mi történt az „Eth2”-vel? {#eth2} - -Az „Eth2” kifejezést elhagytuk. Miután az „Eth1” és az „Eth2” egyetlen láncban egyesült, már nincs szükség arra, hogy különbséget tegyünk két Ethereum-hálózat között. Csak egy Ethereum maradt. - -A zavar elkerülése érdekében a közösség frissítette az alábbi kifejezéseket: - -- Az „Eth1” helyett a „végrehajtási réteg” kifejezést használjuk. Ez a réteg kezeli a tranzakciókat és a végrehajtást. -- Az „Eth2” helyett a „konszenzusréteg” kifejezést használjuk. Ez a réteg kezeli a proof-of-stake konszenzust. - -Ezek a terminológiai módosítások csak az elnevezési szabályokat változtatják meg; ez nem változtatnak az Ethereum céljain vagy ütemtervén. - -[Tudjon meg többet az „Eth2” átnevezéséről](https://blog.ethereum.org/2022/01/24/the-great-eth2-renaming/) - -## A frissítések közötti kapcsolat {#relationship-between-upgrades} - -Az Ethereum-frissítések némileg összefüggnek egymással. Foglaljuk össze hát, hogy a beolvadás hogyan viszonyul a többi frissítéshez. - -### A beolvadás és a Beacon lánc {#merge-and-beacon-chain} - -A beolvadás a Beacon lánc hivatalos átvételét jelenti az eredeti fő hálózat végrehajtási rétegéhez tartozó új konszenzusrétegként. A beolvadás óta a validátorok feladata az Ethereum-főhálózat biztosítása, és a [proof-of-work](/developers/docs/consensus-mechanisms/pow/) rendszerű bányászat már nem érvényes módszer a blokkok előállítására. - -Ehelyett a blokkokra azok a validáló csomópontok tesznek javaslatot, amelyek ETH-t helyeztek letétbe a konszenzusban való részvétel jogáért. Ezek a frissítések készítik elő a terepet a jövőbeni méretezhetőségi frissítésekhez, többek között a szilánkoláshoz. - - - A Beacon lánc - - -### A beolvadás és a Shanghai frissítés {#merge-and-shanghai} - -Hogy leegyszerűsítsük az áttérést a proof-of-stake mechanizmusra, és maximalizáljuk az összpontosítást erre a feladatra, a beolvadás nem tartalmazott bizonyos várt funkciókat, mint például a letétbe helyezett ETH lehívásának lehetőségét. Ez a funkció külön vált elérhetővé a Shanghai/Capella frissítéssel. - -A kíváncsibbak többet megtudhatnak arról, hogy [Mi történik A Beolvadás után](https://youtu.be/7ggwLccuN5s?t=101), méghozzá Vitalik 2021. áprilisi ETHGlobal eseményen tartott előadásából. - -### A beolvadás és a szilánkolás {#merge-and-data-sharding} - -Az eredeti terv szerint a beolvadás előtt dolgozták volna ki a láncszilánkolást (sharding) a méretezhetőség megoldására. Azonban a [2. rétegű méretezési megoldások](/layer-2/) elterjedésével a prioritás eltolódott afelé, hogy előbb a proof-of-stake leváltsa a proof-of-work rendszert. - -A szilánkolással kapcsolatos tervek gyorsan fejlődnek, ám a 2. rétegű technológiák felemelkedése és sikere kapcsán – amelyet a tranzakció-végrehajtás méretezése terén elértek – a szilánkolásra vonatkozó elképzelések most már arra irányulnak, hogy megtalálják a legoptimálisabb módot a rollupszerződések tömörített lehívási adatainak tárolásával járó teher elosztására, és így lehetővé tegyék a hálózati kapacitás exponenciális növekedését. Ehhez azonban előbb át kell térni a proof-of-stake mechanizmusra. - - - Szilánkolás (sharding) - - -## További olvasnivaló {#further-reading} - - - - diff --git a/public/content/translations/hu/11) Roadmap/roadmap/merge/issuance/index.md b/public/content/translations/hu/11) Roadmap/roadmap/merge/issuance/index.md deleted file mode 100644 index 8589d40858b..00000000000 --- a/public/content/translations/hu/11) Roadmap/roadmap/merge/issuance/index.md +++ /dev/null @@ -1,134 +0,0 @@ ---- -title: Hogyan hatott az ETH kínálatra a Beolvadás -description: Részletes bemutatása annak, hogy a Beolvadás hogyan hatott az ETH kínálatára -lang: hu ---- - -# Hogyan hatott az ETH kínálatra a Beolvadás {#how-the-merge-impacts-ETH-supply} - -A Beolvadás jelenti az Ethereum hálózatok azon változását, amikor 2022. szeptemberében áttértek a proof-of-work mechanizmusról a proof-of-stake mechanizmusra. Akkor az is megváltozott, ahogy az ETH-t kibocsátják. Korábban az új ETH két forrásból származott: a végrehajtási rétegből. (főhálózat) és a konszenzusrétegből (Beacon lánc). A Beolvadás óta a végrehajtási réteg kibocsátása nulla. Nézzük meg ennek részleteit. - -## Az ETH-kibocsátás komponensei {#components-of-eth-issuance} - -A ETH-kínálatot két elsődleges erő irányítja: a kibocsátás és az elégetés. - -Az ETH **kibocsátása** az a folyamat, amikor olyan ETH-t hoznak létre, amely korábban nem létezett. Az ETH **elégetése** az a folyamat, amikor a létező ETH-t megsemmisítik, ezzel kivonva azt a körforgásból. A kibocsátás és elégetés rátája számos paraméter alapján kerül kiszámításra, és az ezek közötti egyensúly határozza meg az ether inflációs/deflációs rátáját. - - - -– A proof-of-stake mechanizmusra való átállás előtt a bányászok kb. 13 000 ETH-t bocsátottak ki naponta -– A letétbe helyezők kb. 1700 ETH-t adnak ki naponta, amelynek alapja 14 millió letétbe helyezett ETH -– A letétbe helyezési kibocsátás a letétbe helyezett ETH összegétől függ -– **A Beolvadás óta a napi kibocsátás 1700 ETH körüli, amely 88%-os csökkenés a korábbihoz képest** -– Az elégetés: a hálózati kereslettől függően változik. Ha egy adott napra az átlagos gázdíj legalább 16 gwei, akkor ez kiegyenlíti a validátoroknak kibocsátott 1700 ETH-t, és a nettó ETH infláció nulla vagy annál kevesebb. - - - -## A Beolvadás előtt (régi szisztéma) {#pre-merge} - -### A végrehajtási réteg kibocsátása {#el-issuance-pre-merge} - -A proof-of-work mechanizmusban a bányászok csak a végrehajtási réteggel kapcsolódtak, és blokkjutalmat kaptak, ha elsőként oldották meg a következő blokkot. A [Constantinople-frissítés](/history/#constantinople) után, 2019-től ez a jutalom 2 ETH volt blokkonként. A bányászok jutalmat szereztek akkor is, ha nem egy valid blokkot hoztak létre, amely nem került be a leghosszabb/hiteles láncba, hanem annak csak [ommer](/glossary/#ommer) vagy testvérblokkja volt. Ezek a jutalmak maximum 1,75 ETH-t értek ommerenként, és az érvényes blokk nyereségén _felül_ kerültek kibocsátásra. A bányászat egy gazdaságilag intenzív tevékenység volt, amelynek fenntartásához magas szintű ETH kibocsátásra volt szükség. - -### A konszenzusréteg kibocsátása {#cl-issuance-pre-merge} - -A [Beacon lánc](/history/#beacon-chain-genesis) 2020-től működik élesben. A bányászok helyett validátorok biztosították a rendszert a proof-of-stake mechanizmussal. Ezt a láncot úgy állították fel, hogy az Ethereum-felhasználók ETH-t helyeztek letétbe egy okosszerződésbe a főhálózaton (a végrehajtási rétegen), amelyet a Beacon lánc felismert és az új láncon ugyanannyit ETH-t adott a felhasználónak. A Beolvadás bevezetéséig a Beacon lánc validátorai nem kezelték a tranzakciókat és lényegében a validátor gyűjtőjének státuszáról hozták meg a konszenzust. - -A Beacon láncon a validátorok ETH jutalmat kaptak azért, hogy tanúsítják a lánc státuszát és blokkokat javasolnak. A validátor teljesítménye alapján jutalmak és büntetések kerülnek kiszabásra minden korszakban (epoch, minden 6,4 percben). A validátorok jutalma **jelentősen** kevesebb, mint a bányászoké volt a proof-of-work mechanizmusban (2 ETH kb. 13,5 másodpercenként), mivel a validáló csomópont üzemeltetése nem annyira intenzív feladat, és így nem jár olyan magas jutalom érte. - -### A Beolvadás előtti kibocsátás részletei {#pre-merge-issuance-breakdown} - -Teljes ETH-kínálat: **~120 520 000 ETH** (a Beolvadás idején, 2022. szeptemberben) - -**A végrehajtási réteg kibocsátása:** - -- A becslések szerint 2,08 ETH 13,3 másodpercenként \*: **kb. 4 930 000** ETH került kibocsátásra egy évben -- Ennek eredményeként egy **hozzávetőleges 4,09%-os** inflációs ráta keletkezett (évi 4,93 millió osztva a teljes 120,5 millióval) -- \*Beleértve a kanonikus blokkokért adott 2 ETH-t, plusz az ommer blokkokért adott átlagos 0,08 ETH-t. Emellett a 13,3 másodperc az alap blokkidő, eltekintve az esetleges [nehézség bombák](/glossary/#difficulty-bomb) hatásaitól. ([Tekintse meg a forrást](https://bitinfocharts.com/ethereum/)) - -**A konszenzusréteg kibocsátása:** - -- A teljes 14 000 000 letétbe helyezett ETH-t figyelembe véve az ETH kibocsátás kb. 1700 ETH/nap ([Tekintse meg a forrást](https://ultrasound.money/)) -- Ennek eredményeként **kb. 620 500** ETH-t bocsátanak ki évente -- Ennek eredménye a **kb. 0,52%-os** inflációs ráta (évi 620,5 ezer osztva a teljes 119,3 millióval) - - -Teljes éves kibocsátási ráta (a Beolvadás előtt): ~4,61% (4,09% + 0,52%)

-a kibocsátás kb. 88,7%-a ment a bányászoknak a végrehajtási rétegen (4,09 / 4,61 * 100)

-kb. 11,3%-a a letétesekhez került a konszenzusrétegen (0,52 / 4,61 * 100) - - -## A Beolvadás után (jelenlegi szisztéma) {#post-merge} - -### A végrehajtási réteg kibocsátása {#el-issuance-post-merge} - -A Beolvadás óta a végrehajtási réteg kibocsátása nulla. A blokkokat többé nem a proof-of-work mechanizmus alapján hozzák létre a konszenzus megújított szabályai szerint. A végrehajtási réteg tevékenységeit „beacon blokkokba” csomagolják, amelyeket a proof-of-stake validátorok publikálnak és tanúsítanak. A beacon blokk tanúsításért és publikálásért járó jutalmakat a konszenzusrétegen külön kezelik. - -### A konszenzusréteg kibocsátása {#cl-issuance-post-merge} - -A konszenzusréteg kibocsátása ma is ugyanúgy folytatódik, mint a Beolvadás előtt, kis összegű jutalmakat ad a validátoroknak a blokkok tanúsításáért és javaslattevésért. A validátori jutalmak továbbra is _validátoregyenlegként_ gyűlnek, amelyet a konszenzusrétegen kezelnek. Ezek nem általános, a főhálózaton használható („végrehajtási”) számlák, hanem elkülönített Ethereum számlák, amelyek nem léphetnek tranzakcióba más számlákkal. Az itt tárolt pénzeszközöket csak ki lehet vonni egy meghatározott végrehajtási címre. - -Ezt a visszavonási lehetőséget a Shanghai/Capella-frissítés tette lehetővé 2023. áprilisban. A letétbe helyezőket arra ösztönzik, hogy vegyék ki a _jutalmakat (a 32 ETH feletti összeget)_, mivel ezek nem járulnak hozzá a letéthez (ami maximum 32 ETH lehet). - -A letétbe helyezők emellett ki is léphetnek és kivonhatják a teljes validátoregyenlegüket. Az Ethereum stabilitása érdekében az egyszerre távozó validátorok száma korlátozott. - -Egy adott napon kb. a teljes validátoroknak a 0,33%-a távozhat. Alapból 4 validátor léphet ki egy korszakon (6,4 perc) belül, vagyis egy nap alatt 900. Plusz 1 validátor kiléphet akkor, ha 65 536 (216) új validátor jön és a teljes számuk több mint 262 144 (218). Például 327 680 validátor felett minden korszakban 5-en léphetnek ki (1125 naponta). Ha az aktív validátorok száma meghaladja a 393 216-t, akkor már 6-an léphetnek ki, és így tovább. - -Ahogy több validátor vonul ki, a meglévő validátorok száma fokozatosan lecsökken a minimum négy validátorra, így megvédi a rendszert attól, hogy az ETH-letétek egyidejű kivonása miatt labilissá váljon. - -### A Beolvadás utáni infláció részletezése {#post-merge-inflation-breakdown} - -- Teljes ETH-kínálat: **~120 520 000 ETH** (a Beolvadás idején, 2022. szeptemberben) -- A végrehajtási réteg kibocsátása: **0** -- A konszenzusréteg kibocsátása: A fentivel megegyezik, **kb. 0,52%** éves kibocsátási ráta (14 millió letétbe helyezett ETH-szel) - - -Teljes éves kibocsátási ráta: kb. 0,52%

-Az éves ETH kibocsátás nettó csökkenése: kb. 88,7% ((4,61% – 0,52%) / 4,61% * 100) - - -##  Az elégetés {#the-burn} - -Az ETH kibocsátással ellenkező erő az a ráta, ahogy az ETH-t elégetik. Az Ethereumon végrehajtandó tranzakcióért fizetni kell egy minimális díjat (alapdíj), amely állandóan változik, blokkról blokkra, a hálózati működés függvényében. Ezt a díjat ETH-ben fizetik, és _elengedhetetlen_ ahhoz, hogy egy tranzakció érvényes legyen. Ezt a díjat _elégetik_ a tranzakció végrehajtása során, így kikerül a körforgásból. - - -A díj elégetése a London-frissítés óta (2021. augusztus) működik, és a Beolvadás óta változatlan. - - -A bevezetett díj elégetése mellett a validátorok büntetéseket is kaphatnak azért, ha nincsenek online, vagy ami még rosszabb, ha olyan szabályokat hágnak át, amely a hálózat biztonságát veszélyeztetik, akkor az súlyos büntetéssel és kizárással jár. Ezek a büntetések lecsökkentik az ETH-t a validátor számláján, ami utána nem kerül máshova, tehát lényegében kivonják a forgalomból vagy elégetik. - -### A deflációhoz szükséges átlagos gázdíj kiszámítása {#calculating-average-gas-price-for-deflation} - -Az ETH kibocsátása egy adott napon a teljese letétbe helyezett ETH-től függ. A jelen leírás idején ez kb. 1700 ETH/nap. - -Ahhoz, hogy meghatározzuk azt az átlagos gázdíjat, ami ellensúlyozza ezt az ETH-kibocsátást egy 24 órás periódusban, először kiszámoljuk a blokkok számát az adott napon, tekintve, hogy a blokkidő 12 másodperc: - -- `(1 blokk / 12 másodperc) * (60 másodperc/perc) = 5 blokk/perc` -- `(5 blokk/perc) * (60 perc/óra) = 300 blokk/óra` -- `(300 blokk/óra) * (24 óra/nap) = 7200 blokk/nap` - -Minden blokk a `15x10^6 gáz/blokk` összeget célozza ([Bővebben a gázról](/developers/docs/gas/)). Ez alapján kiszámolhatjuk az átlagos gázdíjat (gwei/gáz), ami kiegyensúlyozza az ETH-kibocsátást, a napi kibocsátást 1700 ETH-nek véve: - -- `7200 blokk/nap * 15x10^6 gáz/blokk *`**`Y gwei/gáz`**`* 1 ETH/ 10^9 gwei = 1700 ETH/nap` - -Megoldva az `Y-ra`: - -- `Y = (1700(10^9))/(7200 * 15(10^6)) = (17x10^3)/(72 * 15) = 16 gwei` (két számjegyre kerekítve) - -Egy másik módon rendezve ezt egy `X` változót tehetünk az `1700` helyére, ami a napi ETH-kibocsátás, a többit pedig leegyszerűsítve: - -- `Y = (X(10^3)/(7200 * 15)) = X/108` - -Leegyszerűsíthetjük úgy, hogy az `X` függvényét írjuk fel: - -- `f(X) = X/108`, ahol `X` a napi ETH-kibocsátás, és az `f(X)` jelenti gwei/gáz árat, amely ellensúlyozni tudja az újonnan kibocsátott ETH-t. - -Tehát ha az `X` (napi ETH kibocsátás) megnövekszik 1800-ra a teljes letétbe helyezett ETH alapján, `f(X)` (gwei, amivel kiegyensúlyozható a kibocsátás) ekkor `17 gwei` lesz (2 számjegyre kerekítve) - -## További olvasnivaló {#further-reading} - -- [A beolvadás](/roadmap/merge/) -- [Ultrasound.money](https://ultrasound.money/) – _Dashboardok az ETH-kibocsátás és -elégetés valós idejű vizualizációjára_ -- [Az Ethereum-kibocsátás grafikonos ábrázolása](https://www.attestant.io/posts/charting-ethereum-issuance/) – _Jim McDonald 2020._ diff --git a/public/content/translations/hu/11) Roadmap/roadmap/scaling/index.md b/public/content/translations/hu/11) Roadmap/roadmap/scaling/index.md deleted file mode 100644 index ae4ba29b790..00000000000 --- a/public/content/translations/hu/11) Roadmap/roadmap/scaling/index.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Az Ethereum skálázása -description: A összevont tranzakciók összekötegelik a tranzakciókat a láncon kívül, ezzel csökkentve a felhasználó költségét. Az összesítések jelenlegi adatfelhasználásának módja azonban túl drága, ami korlátozza a tranzakciók olcsóságát. Erre a Proto-Danksharding nyújt megoldást. -lang: hu -image: /images/roadmap/roadmap-transactions.png -alt: "Ethereum-ütemterv" -template: roadmap ---- - -Az Ethereum skálázása a [layer 2s](/layer-2/#rollups) második blokkláncréteg (L2), vagy más néven összevont tranzakciók által történik, ami kötegbe rendezi a tranzakciókat és az eredményt beküldi az Ethereumra. Habár az összevont tranzakciók költsége a nyolcada az Ethereum főhálózaténak, még mindig van hova optimalizálni a működésüket és ezzel csökkenteni a felhasználók költségét. A összevont tranzakciók emellett néhány centralizált komponensre támaszkodnak, amelyet a fejlesztők eltávolíthatnak majd, ahogy az összevont tranzakciók fejlődik. - - -
    -
  • Ma az összevont tranzakciók kb. 5–20× olcsóbbak, mint az Ethereum L1
    • -
  • A ZK összevont tranzakciók esetében hamarosan ~40–100× alacsonyabb lesz a díj
    • -
  • Az eljövendő Ethereum-módosítások további ~100–1000×-szoros skálázást tesznek lehetővé
    • -
  • A felhasználók számára egy tranzakció kevesebb mint 0,001 $-ba fog kerülni
    • -
- - -## Az adatok olcsóbbá tétele {#making-data-cheaper} - -A összevont tranzakciók sok tranzakciót gyűjtenek össze, végrehajtják azokat és az eredményt az Ethereumra küldik. Ez rengeteg adatot jelent, amelyet nyíltan elérhetővé kell tenni bárki számára, hogy lefuttathassa a tranzakciókat és ellenőrizze, hogy az összevont tranzakció operátora jóhiszeműen járt el. Ha valaki talál egy eltérést, akkor megkérdőjelezheti azt. - -### Proto-Danksharding {#proto-danksharding} - -Az összevont tranzakciós adatok korábban tartósan az Ethereumon maradtak, ami drága volt. Az összevont tranzakciók tranzakciós költségeinek több mint 90%-át az adattárolás teszi ki. A tranzakciós költségek csökkentéséhez az adatot egy új átmeneti blob tárhelyre mozgathatjuk. A blob olcsóbb, mert nem tartós; törölhetők az Ethereumról, amint már nincs rájuk szükség. Az összevont tranzakciós adatok hosszú távon azoknak a felelősségébe tartoznak, akiknek szükségük van azokra, mint például az összevont tranzakciós operátorok, tőzsdék, indexáló szolgáltatások stb. Az Ethereum blob-tranzakcióval való kiegészítése a „Proto-Danksharding” néven ismert frissítés része. - -A Proto-Danksharding segítségével sok blobot lehet hozzáadni az Ethereum blokkokhoz. Ez egy újabb jelentős (több mint 100×) skálázási lehetőség az Ethereum tranzakcióátvitelét illetően és a költségek csökkentésére. - -### Dank-féle párhuzamos futtatás (Danksharding) {#danksharding} - -A blob adatok bővítésének második szakasza bonyolult, mert új módszereket igényel az összesítő adatok hálózaton való elérhetőségének ellenőrzéséhez, és [ellenőrzőkre](/glossary/#validator) támaszkodik, amelyek elválasztják a [blokk](/glossary/#block) felépítési és blokkjavaslat-feladatokat. Kell hozzá egy olyan módszer is, amely kriptográfiailag bizonyítja, hogy a validátor igazolta a blobadat egy kis részét. - -Ez a második lépés a [Danksharding](/roadmap/danksharding/). **Valószínűleg több év múlva** a teljes megvalósításig. A Danksharding más fejlesztéseken is múlik, mint a [PBS](/roadmap/pbs) és új hálózati dizájn, hogy a hálózat hatékonyan tudja konfirmálni, hogy az adatok elérhetők, azáltal hogy véletlenszerűen néhány kilobájtos mintát választ egy adott időben, ezt [adat-elérhetőségi mintavételnek (DAS)](/developers/docs/data-availability) nevezzük. - -Bővebben a Dankshardingról - -## Az összevont tranzakciók decentralizálása {#decentralizing-rollups} - -Az [összevont tranzakciók](/layer-2) már most is gondoskodnak az Ethereum méretezhetőségéről. Az [összevont tranzakciós projektek gazdag ökoszisztémája](https://l2beat.com/scaling/tvl) teszi lehetővé, hogy a felhasználó gyorsabban és olcsóbban indítson tranzakciót, a biztonsági garanciák széles körét kiélvezve. Ugyanakkor az összevont tranzakciók centralizált szekvenszert használnak (ami feldolgozza a tranzakciókat és aggregálja azokat, mielőtt az Ethereumra küldené). Ez lehetővé teszi a cenzúrát, mivel a szekvenszeroperátorokat meg lehet büntetni, vesztegetni vagy máshogy veszélyeztetni. Emellett az [összevont tranzakciók eltérnek abban](https://l2beat.com), hogyan validálják a bejövő adatokat. A legjobb módja a „bizonyítók” [csalási bizonyítékok](/glossary/#fraud-proof) vagy érvényességi igazolások benyújtása, de még nincs meg minden összesítés. Még ahol léteznek is ilyen érvényesítési/csalásbiztos összevont tranzakciók, ott is csak kevés bizonyítót használnak. Ezért a következő fontos lépés az Ethereum skálázásban, hogy elossza a szekvenszer és a bizonyító felelősségét több emberre. - -Bővebben az összevont tranzakciókról - -## Jelenlegi helyzet {#current-progress} - -A Proto-Danksharding az első ilyen ütemterv, amelyet a Cancun-Deneb („Dencun”) hálózatfrissítés részeként hajtanak végre 2024 márciusában. **A teljes Danksharding valószínűleg több év múlva lesz elérhető**, mivel számos egyéb ütemtervelemtől függ először. Az összevont tranzakciók infrastruktúrájának decentralizálása egy fokozatos folyamat lesz – több különböző összevont tranzakció létezik, amelyek kicsit más felállásban működnek, és más rátán fogják tudni elvégezni a decentralizálást. - -[További információ a Dencun hálózatfrissítésről](/roadmap/dencun/) - - diff --git a/public/content/translations/hu/11) Roadmap/roadmap/security/index.md b/public/content/translations/hu/11) Roadmap/roadmap/security/index.md deleted file mode 100644 index 19f667b706c..00000000000 --- a/public/content/translations/hu/11) Roadmap/roadmap/security/index.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Biztonságosabb Ethereum -description: Az Ethereum a legbiztonságosabb és leginkább decentralizált okosszerződés-platform a világon. Azonban még mindig vannak fejlődési lehetőségek, hogy az Ethereum ellenálló maradjon minden szinten a támadásokkal szemben a jövőben is. -lang: hu -image: /images/roadmap/roadmap-security.png -alt: "Ethereum-ütemterv" -template: roadmap ---- - -Az **Ethereum már egy nagyon biztonságos**, decentralizált [okosszerződéses](/glossary/#smart-contract) platform. Azonban még mindig vannak fejlődési lehetőségek, hogy az Ethereum ellenálló maradjon mindenféle támadással szemben a jövőben is. Ezek közé tartozik az [Ethereum-kliensek](/glossary/#consensus-client) versengő [blokkokkal](/glossary/#block) való kezelésének finom módosítása, valamint a hálózat által a blokkok [„véglegesítettnek”](/developers/docs/consensus-mechanisms/pos/#finality) történő megnövelése. (ami azt jelenti, hogy nem változtathatók meg anélkül, hogy rendkívüli gazdasági veszteséget okoznának a támadónak). - -Olyan fejlesztések is folyamatban vannak, amelyek a tranzakciók cenzúrázását nehezítik meg, azáltal hogy a blokkjavasló nem tudja, mit tartalmaz az adott blokk, és új módokat kínál annak megállapítására, hogy egy kliens cenzúráz-e. Ezek a fejlesztések együtt frissítik a [tét bizonyítéka](/glossary/#pos) protokollt, hogy a felhasználók – magánszemélyektől a vállalatokig – azonnal megbízhassanak alkalmazásaikban, adataikban és eszközeikben az Ethereumban. - -## A letétbe helyezés visszavonása {#staking-withdrawals} - -A [proof-of-work](/glossary/#pow)-ről a tét-igazolásra való frissítés azzal kezdődött, hogy az Ethereum úttörői „kockáztatták” ETH-jukat egy letéti szerződésben. Ez az ETH arra van, hogy megvédje a hálózatot. 2023. április 12-én egy második frissítés is megtörtént, amely lehetővé teszi a téttel járó ETH visszavonását. Azóta a validátorok szabadon tétet tehetnek vagy visszavonhatnak ETH-t. - -Bővebben a visszahívásokról - -## Támadások elleni védelem {#defending-against-attacks} - -Vannak fejlesztések, amelyek az Ethereum proof-of-stake protokollját érintik. Az egyik a [view-merge](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739) néven ismert – egy biztonságosabb [elágazás](/glossary/#fork)-választási algoritmus, amely megnehezít bizonyos kifinomult támadástípusokat. - -Az Ethereumnak a blokkok [véglegesítéséhez](/glossary/#finality) szükséges idő csökkentése jobb felhasználói élményt biztosítana, és megakadályozná az olyan kifinomult „reorg” támadásokat, amelyek során a támadók megpróbálják átrendezni a legutóbbi blokkokat, hogy profitot vonjanak ki, vagy bizonyos tranzakciókat cenzúrázzanak. Az [**Single slot finality (SSF)**](/roadmap/single-slot-finality/) egy **módszer a véglegesítési késleltetés minimalizálására**. Jelenleg 15 percnyi blokk esetén tudna egy támadó elméletileg meggyőzni egy másik validátort, hogy újrakonfigurálja azokat. Az SSF esetén ez 0 lenne. A felhasználók számára, kezdve az egyénektől egészen az alkalmazásokig és tőzsdékig, mindig hasznos, ha gyorsan lehet biztosítani, hogy a tranzakcióik ne lesznek visszafordítva, a hálózatnak pedig az, hogy a támadások teljes osztályait ki tudja zárni. - -Bővebben az egy sloton belüli véglegességről (SSF) - -## A cenzúra elleni védelem {#defending-against-censorship} - -A decentralizáció megakadályozza, hogy egyének vagy [ellenőrzők](/glossary/#validator) kis csoportjai túlságosan befolyásossá váljanak. Az új letéti technológiák segítenek, hogy az Ethereum validátorai decentralizáltak maradjanak, miközben védi őket a hardver-, szoftver- és hálózati hibáktól. Ide tartoznak azok a szoftverek is, amelyek több [csomópont](/glossary/#node) között osztják meg az érvényesítői felelősséget. Ez az **elosztottvalidátor-technológia (DVT)**. A [letéti alapokat](/glossary/#staking-pool) ez ösztönzi, hogy használják a DVT-t, így több számítógép vehet részt egyszerre a validációban, ezzel redundanciával (extra kapacitás) és hibatoleranciával kiegészítve a működést. A validátorkulcsokat több rendszerre osztja el ahelyett, hogy egy operátor futtatna több validátort. Ezáltal a rosszhiszemű operátoroknak nehezebb támadást indítani az Ethereum ellen. Összességében további biztonsági előnyökkel járhat, ha a validátorok _közösségként_ működnek, nem egyénként. - -Bővebben az elosztottvalidátor-technológiáról (DVT) - -Az **előterjesztő-építő szétválasztás (PBS)** drasztikusan fejleszti az Ethereum beépített, cenzúrának való ellenállást. A PBS lehetővé teszi, hogy egy validátor rakja össze a blokkot, egy másik pedig továbbadja az Ethereum-hálózatnak. Ez biztosítja, hogy a professzionális profitmaximalizáló blokképítő algoritmusokól eredő nyereségek majd egyenletesebben oszoljanak el a hálózaton, **megakadályozva a letétek koncentrációját** a legjobban működő intézményes letéteseknél. A blokk előterjesztője a leginkább profitábilis blokkot választja azok közül, amit a blokképítők piaca ajánl. A cenzúrához a blokk előterjesztőjének gyakran egy kevésbé profitábilis blokkot kellene választania, ami **gazdaságilag irracionális és nyilvánvaló a többi validátor számára is** a hálózaton. - -Olyan potenciális kiegészítések is elérhetők a PBS-hez, mint a titkosított tranzakciók és a bekerülési lista, ami tovább növeli az Ethereum cenzúrának való ellenállást. Ezek következtében a blokk építője és javaslója nem tudja, hogy milyen tranzakciók vannak a blokkban. - -Bővebben a PBS-ről - -## A validátorok védelme {#protecting-validators} - -Lehetséges, hogy egy szofisztikált támadó beazonosítja a következő validátort és megakadályozza őt a javaslattételben; ez a **szolgáltatásmegtagadási, vagy más néven DoS**-támadás. A [**titkos vezetőválasztás (SLE)**](/roadmap/secret-leader-election) bevezetése megvéd ettől a támadási típustól, mivel a blokkjavaslók nem lesznek előre ismertek. Úgy működik, hogy a blokkjavaslókat képviselő kriptográfiai elköteleződéseket állandón keverik, és ezek sorrendje adja meg, hogy amelyik validátor kerül kiválasztásra, amiről csak ő fog tudni. - -Bővebben a titkos vezetőválasztásról - -## Jelenlegi helyzet {#current-progress} - -**Az ütemtervben szereplő biztonsági frissítések a kutatás előrehaladott szakaszában vannak**, de várhatóan még egy ideig nem hajtják végre őket. A következő lépés a nézetegyesítésre (amelyeket még nem valósítottak meg élesben) a specifikáció véglegesítése és a prototípusok létrehozása. diff --git a/public/content/translations/hu/11) Roadmap/roadmap/user-experience/index.md b/public/content/translations/hu/11) Roadmap/roadmap/user-experience/index.md deleted file mode 100644 index 8903f1fdf84..00000000000 --- a/public/content/translations/hu/11) Roadmap/roadmap/user-experience/index.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: A felhasználói élmény javítása -description: A legtöbb ember számára még mindig túl bonyolult az Ethereum használata. A tömeges használathoz az Ethereumnak drasztikusan csökkentenie kell ezt az akadályt – mindenki számára előnyösnek kell lennie a decentralizált, engedélymentes és cenzúrának ellenálló Ethereum-hozzáférésnek, ugyanakkor olyan könnyednek kell lennie, mint a hagyományos web2 alkalmazás használata. -lang: hu -image: /images/roadmap/roadmap-ux.png -alt: "Ethereum-ütemterv" -template: roadmap ---- - -**Az Ethereum használatát egyszerűsíteni kell**; a [kulcsok](/glossary/#key) és [pénztárcák](/glossary/#wallet) kezelésétől a tranzakciók kezdeményezéséig. A tömeges elterjedtség elősegítése érdekében az Ethereumnak drasztikusan javítania kell a használat egyszerűsítését, lehetővé téve a felhasználók számára az engedély nélküli és cenzúraálló hozzáférést az Ethereumhoz a [Web2](/glossary/#web2) alkalmazások súrlódásmentes használatának élményével. - -## A kulcsmondatokon túl {#no-more-seed-phrases} - -Az Ethereum-számlákat egy kulcspár védi, amelyek a számla azonosítását (nyilvános kulcs) és az üzenetek aláírását (privát kulcs) szolgálják. A privát kulcs olyan, akár egy mesterjelszó; teljes hozzáférést biztosít az Ethereum-számlához. Ez egy más megközelítés, mint amelyet a legtöbb felhasználó ismer, akik a bankokra és web2-alkalmazásokra bízzák a számlák kezelését. Az Ethereum tömeges használatának eléréséhez egyértelmű és könnyed utat kell mutatni a felhasználóknak, hogyan anélkül felügyelhessék eszközeiket és adataikat, hogy érteniük kellene a nyilvános-privát kulcsok kriptográfiájához és a kulcskezeléshez. - -A megoldás az [intelligens szerződéses](/glossary/#smart-contract) pénztárcák használata az Ethereummal való interakcióhoz. Az okosszerződéses tárcák képesek megvédeni a számlát, ha a kulcsok elvesznek vagy ellopják azokat, jobban ellenállnak a csalásnak és támadásnak, és új funkciók használatát is lehetővé teszik a tárcákban. Habár okosszerződéses tárcák már most is léteznek, de nagyon nehézkes megépíteni azokat, mert az Ethereum-protokollnak jobban kellene azokat támogatni. Ezt az extra támogatást nevezzük számlaabsztrakciónak. - -Bővebben a számlaabsztrakcióról - -## Csomópont mindenkinek - -A [csomópontokat](/glossary/#node) futtató felhasználóknak nem kell megbízniuk harmadik felekben abban, hogy adatokat szolgáltatjanak nekik, és gyorsan, privát módon és engedély nélkül kommunikálhatnak az Ethereum [blokkláncával](/glossary/#blockchain). Azonban a csomópont jelenlegi működtetése technikai tudást és jelentős merevlemez-kapacitást igényel, így a legtöbb felhasználónak másokhoz kell fordulnia. - -Számos fejlesztés meg fogja könnyíteni a csomópontok működtetését és csökkenti erőforrásigényüket. Az adatok tárolásához egy sokkal kevesebb tárhelyet igénylő struktúrát fognak használni, amit **Verkle fának** neveznek. Emellett a [státusztalanság](/roadmap/statelessness) és az [adatok lejárata](/roadmap/statelessness/#data-expiry) miatt a csomópontoknak nem kell majd a teljes Ethereum-státuszadatát tárolniuk, jelentősen lecsökkentve a merevlemezigényeket. A [könnyű kliensek](/developers/docs/nodes-and-clients/light-clients/) is rengeteg előnyt nyújtanak a teljes csomópontok üzemeltetéséhez, mivel ezeket mobileszközökről vagy egyszerű böngészőalkalmazásokból is futtatni lehet majd. - -Bővebben a Verkle-fákról - -Ezekkel az fejlesztésekkel gyakorlatilag nullára csökken a csomópontfuttatás akadálya. A felhasználók biztonságos, engedélymentes hozzáférést nyernek az Ethereumhoz, anélkül hogy komoly lemezterületet vagy CPU-t áldoznának erre, és nem kell harmadik félhez fordulniuk adatért vagy a hálózat eléréséhez, amikor alkalmazásokat használnak. - -## Jelenlegi helyzet {#current-progress} - -Az okosszerződéses tárcák már elérhetők, de több fejlesztésre van szükség, hogy még decentralizáltabbak és engedélymentesek legyenek. Az EIP-4337 egy olyan javaslat, ami már nem igényli az Ethereum-protokoll komoly módosítását. Az EIP-4337-hez szükséges fő intelligens szerződést **2023 márciusában vezették be**. - -**A teljes hontalanság még a kutatási fázisban van**, és valószínűleg több év múlva kerül végrehajtásra. Ehhez még számos mérföldkövet el kell érni, ilyen például az adatok lejárata is, amelyek hamarabb bevezetésre kerülhetnek. A többi tervezett fejlesztésnek, mint a [Verkle-fáknak](/roadmap/verkle-trees/) és a [javaslattevő-építő szétválasztásnak](/roadmap/pbs/) előbb meg kell valósulnia. - -A Verkle-fás teszthálózatok már használhatók, a következő lépés a Verkle-fákkal működő kliensek privát és nyilvános teszthálózaton való futtatása. Ön is segíthet a fejlesztés meggyorsításában, ha szerződéseket hoz létre a teszthálózaton és klienseket működtet a teszthez. diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/account-abstraction/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/account-abstraction/index.md deleted file mode 100644 index a683d64e2ac..00000000000 --- a/public/content/translations/hu/12) Roadmap 2/roadmap/account-abstraction/index.md +++ /dev/null @@ -1,126 +0,0 @@ ---- -title: Számlaabsztrakció -description: Az Ethereum tervek áttekintése azzal kapcsolatban, hogy a felhasználói számlák egyszerűbbek és biztonságosabbak legyenek -lang: hu -summaryPoints: - - A számlaabsztrakció sokkal egyszerűbbé teszi az okosszerződéses tárcák építését - - Az okosszerződéses tárcák egyszerűbbé teszik az Ethereum számlákhoz való hozzáférés menedzselését - - Az elvesztett vagy nyilvánossá vált kulcsokat többféle biztonsági megoldással is vissza lehet nyerni ---- - -# Számlaabsztrakció {#account-abstraction} - -A felhasználók **[külső tulajdonú számlák (EOA)](/glossary/#eoa)** révén kapcsolódnak az Ethereumhoz. Ez az egyetlen módja, hogy egy tranzakciót kezdeményezzenek vagy elindítsanak egy okosszerződést. Ez behatárolja azt, ahogyan a felhasználók az Ethereummal kapcsolatba léphetnek. Nehézkessé teszi például, hogy tranzakciókötegeket hajtsanak végre és a felhasználóknak mindig tartani kell ETH-t, hogy fedezzék a tranzakciók költségeit (gáz). - -A számlaabsztrakció egy olyan mód, amely megoldást ad ezekre a problémákra azáltal, hogy a felhasználók rugalmasabban adhatnak több biztonságot a számláikhoz, illetve jobb felhasználói élményben lehet részük. Ehhez arra van szükség, hogy [EOA-kat fejleszteni kell](https://eips.ethereum.org/EIPS/eip-3074), hogy okosszerződéssel is lehessen azokat irányítani, vagy [az okosszerződéseket kell fejleszteni](https://eips.ethereum.org/EIPS/eip-2938) úgy, hogy tranzakciókat tudjanak kezdeményezni. Mindkét opcióhoz módosítani kell az Ethereum-protokollt. Egy harmadik megoldás is lehetséges, ahol egy [második, elkülönült tranzakciós rendszert](https://eips.ethereum.org/EIPS/eip-4337) hoznak létre, hogy a meglévő protokollal párhuzamosan működjön. A megoldási módtól függetlenül az eredmény az, hogy az Ethereumot okosszerződéses tárcákkal, a meglévő protokoll támogatásával vagy egy hozzáadott tranzakciós hálózattal is el lehet érni. - -Az okosszerződéses tárcák számos előnnyel járnak a felhasználók számára: - -- beállíthatják a saját rugalmas biztonsági szabályaikat -- a számlát vissza lehet állítani akkor is, ha a kulcsok elvesztek -- a számla biztonságát meg lehet osztani megbízható eszközökkel vagy egyénekkel -- lehet gázt fizetni más helyett, illetve helyettünk is fizethet más -- a tranzakciókat össze lehet kötegelni (pl. az átváltásokat egyszerre jóvá lehet hagyni és végrehajtani) -- az alkalmazás- (dapp) és tárcafejlesztőknek több lehetőségük van, hogy javítsák a felhasználói élményeket - -Jelenleg ezek az előnyök nem érhetők el, mert csak a külső tulajdonú számlák ([EOA](/glossary/#eoa)) indíthatnak tranzakciókat. Az EOA-k lényegileg egy nyilvános-privát kulcspárból állnak. Így működnek: - -- aki rendelkezik egy privát kulccsal, az _bármit_ megtehet az Ethereum Virtuális Gép (EVM) szabályain belül -- aki nem rendelkezik a privát kulccsal, az _semmit_ sem tehet. - -Ha a kulcsok elvesznek, akkor nem lehet azokat visszaszerezni, illetve az ellopott kulcsok azonnali hozzáférést adnak a számlán lévő eszközökhöz. - -Az okosszerződéses tárcák megoldást tudnak ezekre adni, de jelenleg nehéz programozni ezeket, mert minden egyes logikát a végén le kell fordítani egy adag EOA-tranzakcióra, hogy azokat végre lehessen hajtani az Ethereumon. A számlaabsztrakció lehetővé teszi az okosszerződések számára, hogy tranzakciókat indítsanak el, ezért a felhasználó bármilyen általa kívánt logikát be tud kódolni az okosszerződéses tárcába és azt végre tudja hajtatni az Ethereumon. - -Végül a számlaabsztrakció fejleszti az okosszerződéses tárcák támogatását, mivel egyszerűbb lesz azokat megépíteni és biztonságosabb lesz használni. A számlaabsztrakció révén a felhasználók az Ethereum összes előnyét kiélvezhetik, és nem kell tudniuk vagy foglalkozniuk a mögöttes technológiával. - -## A kulcsmondatokon túl {#beyond-seed-phrases} - -Jelenleg a számlákat a privát kulcsok használata védi, amelyet kulcsmondatokból állítanak elő. Aki hozzáfér a kulcsmondathoz, az könnyen fel tudja fedezni a számlát védő privát kulcsot, így hozzáférhet a számla eszközeihez. Ha a privát kulcs és a kulcsmondat elvész, akkor azokat már nem lehet visszanyerni és a számlán tárolt eszközök örökre be lesznek fagyasztva. A kulcsmondatok biztonságos tárolása elég kényelmetlen még a szakértő felhasználók számára is, és az ezekre irányuló adathalászat a fő oka annak, hogy a felhasználókat átverik. - -A számlaabsztrakció esetében az okosszerződés tárolja a eszközöket és hagyja jóvá a tranzakciókat. Ezeket az okosszerződéseket személyre szabott logikával lehet működtetni, hogy a lehető legbiztonságosabbak legyenek és a felhasználóra legyenek szabva. A felhasználó még mindig privát kulcsokat használ ahhoz, hogy a számlát irányítsa, de azt biztonsági hálóval együtt teszi, amely könnyebbé és biztonságosabbá teszi a kezelést. - -Például olyan biztonsági kulcsok adhatók a tárcához, hogy ha valaki elveszíti vagy véletlenül feltárja a fő kulcsát más előtt, akkor azt kicserélheti egy új, biztonságos kulcsra, amelyet a biztonsági kulcs engedélyez. A különféle kulcsot más-más módon biztosíthatja a felhasználó, vagy megbízott őrzők között is feloszthatja azt. Ezáltal sokkal nehezebbé válik a csalóknak, hogy teljes kontrollt szerezzenek az eszközök felett. Hasonlóképpen szabályokat is hozzáadhat a pénztárcához, hogy csökkentse a fő kulcsának veszélyeztetettségét, például lehetővé teheti az alacsony értékű tranzakciók egyetlen aláírással történő ellenőrzését, míg a nagyobb értékű tranzakciókhoz több hitelesített aláíró jóváhagyása szükséges. Az intelligens szerződéses pénztárcák más módokon is segíthetnek a tolvajok meghiúsításában, például egy engedélyezési lista segítségével blokkolhat minden tranzakciót, kivéve, ha az megbízható címre érkezik, vagy ha nem igazolja több előre jóváhagyott kulccsal. - -### Néhány példa arra, hogy milyen biztonsági logikákat lehet beépíteni az okosszerződéses tárcába: - -- **Többaláírásos jóváhagyás**: A jóváhagyásra való meghatalmazást meg lehet osztani több megbízható ember vagy eszközök között. Ekkor a szerződést úgy lehet beállítani, hogy egy előre meghatározott érték feletti tranzakció jóváhagyást kérjen a megbízott felek egy adott arányától (pl. 5-ből 3-tól). Egy magas értékű tranzakció például jóváhagyást kérhet egy mobileszköztől és egy hardvertárcától egyszerre, vagy a megbízott családtagok között megosztott számláktól igényelhet aláírást. -- **Számlabefagyasztás**: Ha egy eszköz elveszett vagy más kezébe került, akkor a számlát be lehet fagyasztani egy másik jóváhagyott eszközről, ezzel megvédve a felhasználó eszközeit. -- **Számla-visszaállítás**: Elveszett az eszköz vagy elfelejtette a jelszót? A jelenlegi felállásban ez azt jelenti, hogy a számlán tartott eszközök örökre befagyasztva maradnak. Az intelligens szerződéses pénztárcával beállíthat egy engedélyezési listát azokról a fiókokról, amelyek engedélyezhetik az új eszközöket és visszaállíthatják a hozzáférést. -- **Tranzakciólimitek beállítása**: Napi határértéket lehet megadni arra vonatkozóan, hogy milyen értéket lehet áttranszferálni az adott számláról egy nap/hét/hónap alatt. Tehát ha egy támadó hozzáférést szerez a számlához, akkor nem tudja egyszerre kiüríteni azt, a tulajdonos pedig be tudja azt fagyasztani és visszaállítani a saját hozzáférést. -- **Engedélyezőlisták létrehozása**: Csak bizonyos címekre engedélyezi a tranzakciókat, amelyekről tudja, hogy biztonságosak. Ez azt jelenti, hogy _még ha_ a privát kulcsát ellopták is, a támadó csak a listán szereplő célszámlákra küldhet pénzt. Ezekhez az engedélyezési listákhoz több aláírásra lenne szükség a módosításukhoz, így a támadók csak akkor vehetik fel a saját címüket a listára, ha hozzáfértek több biztonsági kulcshoz. - -## Jobb felhasználói élmény {#better-user-experience} - -A számlaabsztrakció lehetővé teszi a **jobb felhasználói élményt** és **a magasabb fokú biztonságot**, mert támogatást biztosít az okosszerződéses tárcának a protokoll szintjén. Ez a megoldás az okosszerződések, tárcák és alkalmazások fejlesztőinek olyan szintű szabadságot ad az innovációra a felhasználói élményt illetően, olyan módokon, amiket most még elképzelni sem tudunk. Néhány egyértelmű fejlesztés a számlaabsztrakció mellett többek között az, hogy a tranzakciókat kötegelni lehet a gyorsaság és a hatékonyság érdekében. Például egy egyszerű swapnak egy kattintásos műveletnek kell lennie, de manapság több tranzakció aláírása szükséges ahhoz, hogy jóváhagyják az egyes tokenek elköltését a csere végrehajtása előtt. A számlaabsztrakcióval megszűnik ez a többszörös jóváhagyás, mert a tranzakciókat össze lehet kötegelni. Emellett a kötegelt tranzakciókat úgy hagyja jóvá a felhasználó, hogy a tokeneknek a megfelelő értéke szerepel benne, majd a végrehajtás után visszavonja a jóváhagyást, ezzel fokozva a biztonságot. - -A gáz, vagyis a tranzakciós díjak kezelése is sokkal fejlettebbé válik a számlaabsztrakcióval. Az alkalmazások felajánlhatják, hogy kifizetik a felhasználók gázdíját, továbbá a gázt más tokenben is lehet rendezni, nem csak ETH-ben, így a felhasználóknak nem kötelező ETH-összeget tartani a számlájukon, hogy a tranzakciókat finanszírozni tudják. Ez úgy valósul meg, hogy a szerződésen belül a felhasználó tokenjeit átváltják ETH-re, és ebben fizetik ki a gázt. - - - -A gázdíjak kezelése az egyik fő gond az Ethereum-felhasználók számára, mert csak ETH-ben lehet azt rendezni. Tegyük fel, hogy van egy tárca USDC-egyenleggel, de nincs benne ETH. Akkor az USDC-tokeneket nem tudja a tulajdonos elküldeni vagy átváltani, mert nem tudja kifizetni a gázdíjat. Nem lehet átváltani az USDC-t ETH-re, mert ez önmagában gázdíjat igényel. Ennek megoldásához ETH-t kell beküldeni a számlára egy tőzsdéről vagy egy másik címről. Az okosszerződéses tárcákkal ki lehet fizetni a gázdíjat a számlán tartott USDC-ből, így szabadon használható a számla. Ennek köszönhetően nem kell ETH-egyenleget tartani az összes számlán. - -A számlaabsztrakció lehetővé teszi a dapp fejlesztőknek azt is, hogy a gázdíj kezelésében kreatívak legyenek. Például a kedvenc tőzsdéjének a felhasználó akár fix díjat is fizethetne havonta korlátlan mennyiségű tranzakcióért. A dappok felajánlhatják, hogy kifizetik az összes gázdíjat a felhasználó helyett, ezzel jutalmazva őket, hogy az adott platformot használják, vagy belépési ajánlat gyanánt. A fejlesztőknek könnyebb lesz innovatív módon hozzáállni a gázhoz, amikor az okosszerződéses tárcákat protokollszinten támogatják. - - - -A megbízható periódus használata is jelentős hatással lehet a felhasználói élményekre, főleg olyan alkalmazásoknál, mint a játékok, ahol sok kis értékű tranzakciót kell rövid időn belül jóváhagyni. Ha egyesével kell a tranzakciókat engedélyezni, akkor az megtöri a játék élményét, de az állandó jóváhagyás nem lenne biztonságos. Az okosszerződéses tárca engedélyezni tudna bizonyos tranzakciókat egy fix időre, egy meghatározott értékig vagy csak egy bizonyos címre. - -Érdekes azt is átgondolni, hogyan alakulnak a váráslások a számlaabsztrakcióval. Jelenleg minden tranzakciót jóvá kell hagyni és végre kell hajtani a tárcából úgy, a megfelelő token kellő összege rendelkezésre áll. A számlaabsztrakcióval ez az élmény inkább olyan lehet, mint egy online vásárlás, ahol a felhasználó beleteszi a tételeket a kosarába, egyszerre fizeti ki az összeset, és a szerződés kezeli azokat a logikákat, amelyek ehhez szükségesek. - -Ez csak néhány példa arra, hogy a felhasználói élmény hogyan fejlődhet a számlaabsztrakcióval, ám ennél sokkal több is lehetségessé válik. A számlaabsztrakció felszabadítja a fejlesztőket a jelenlegi EOA-k kötöttségei alól, behozhatják a web2 jó szempontjait a web3-ba anélkül, hogy feláldoznák az eszközök fölötti saját felügyeletet, illetve kreatív módon javíthatják a felhasználói élményeket. - -## Hogyan kerül bevezetésre a számlaabsztrakció? {#how-will-aa-be-implemented} - -Az okosszerződéses tárcák most is léteznek, de kihívásokkal teli a megvalósításuk, mert az EVM nem támogatja azokat. Ehelyett azon alapulnak, hogy elég összetett kódokba burkolják a standard Ethereum-tranzakciókat. Az Ethereum képes ezt megváltoztatni azáltal, hogy megengedi az okosszerződéseknek a tranzakciókezdeményezést, így az Ethereum okosszerződésbe lehet kódolni a szükséges logikákat, nem pedig a láncon kívül kezelni azokat. Az okosszerződésbe írt logikák növelik az Ethereum decentralizációját is, mivel nem lesz szükség a tárcafejlesztők által működtetett közvetítőkre, hogy lefordítsák a felhasználók által aláírt üzeneteket Ethereum-tranzakciókká. - - - -EIP-2771 a metatranzakció koncepcióját vezeti be, amelynek révén egy harmadik személy kifizetheti a felhasználó gázdíját anélkül, hogy ehhez változtatni kellene az Ethereum protokollon. Eszerint a felhasználó által aláírt tranzakciók egy „továbbító” szerződéshez kerülnek. Ez a továbbító egy megbízott entitás, amely ellenőrzi a tranzakciók érvényességét, mielőtt elküldi azokat egy gázközvetítőnek. Ezt a láncon kívül intézik, így nem kell érte gázdíjat fizetni. A gázközvetítő átadja a tranzakciót egy „fogadó” szerződésnek, és kifizeti a szükséges díjat, hogy a tranzakció végrehajtható legyen az Ethereumon. A tranzakciót végre lehet hajtani, ha a „továbbító” ismert és a „fogadó” bízta meg. Ez a modell megkönnyíti a fejlesztők számára, hogy gázdíj nélküli tranzakciókat tegyenek lehetővé a felhasználók számára. - - - - - -Az EIP-4337 az első lépés az okosszerződéses tárca támogatására decentralizált módon anélkül, hogy az Ethereum-protokollt változtatni kellene hozzá. Ahelyett, hogy a konszenzusréteget módosítanák, hogy támogassa az okosszerződéses tárcákat, egy új rendszert adnak a meglévő tranzakciós pletykaprotokollhoz. Ez a magasabb szintű rendszer egy új objektumra épül, amely a UserOperation nevet kapta, és a felhasználótól érkező tevékenységeket csomagolja össze a megfelelő aláírásokkal együtt. Majd ezeket a UserOperation-objektumokat elküldik egy dedikált memóriakészletbe, ahol a validátorok azokat egy tranzakcióköteggé szedhetik össze. A tranzakcióköteg számos egyéni UserOperations-sorozatot képvisel, és ugyanúgy bekerül egy Ethereum-blokkba, mint bármilyen normál tranzakció. Ezután a validátorok felveszik azt egy díjmaximalizáló kiválasztási modell alapján. - -Az EIP-4337 azt is megváltoztatja, ahogy a tárcák működnek. Ahelyett, hogy minden egyes tárca újraimplementálná a közös, de összetett biztonsági logikát, ezek a funkciók kikerülnének egy globális tárcaszerződésbe, amelyet „ belépési pontnak” neveznek. Ez üzemeltetné az olyan funkciókat, mint a díjak fizetése és az EVM-kód végrehajtása, így a tárcafejlesztők fókuszálhatnak a kiváló felhasználói élményre. - -Megjegyzés: az EIP-4337 által tervezett belépésipont-szerződést az Ethereum-főhálózatra 2023. március 1-én üzemelték be. A szerződés az Etherscan oldalon tekinthető meg. - - - - - -Az EIP-2938 az Ethereum-protokollt fejleszti azzal, hogy bevezet egy új, AA_TX_TYPE nevű tranzakciótípust, amely három mezőt tartalmaz: nonce, target és data, ahol a nonce egy tranzakciószámláló, a target a belépésipont-szerződés címe, a data pedig az EVM-bájtkód. Ezen tranzakciók végrehajtásához két új parancsot (operációs kódot) kell hozzáadni az EVM-hez: NONCE és PAYGAS. A NONCE opkód trekkeli a tranzakciósorrendet, a PAYGAS kalkulálja és levonja a végrehajtáshoz szükséges gázdíjat a szerződés egyenlegéből. Ezek az új funkciók lehetővé teszik az Ethereumnak, hogy támogassa az okosszerződéses tárcákat, mivel a szükséges infrastruktúra az Ethereum-protokollba épül be. - -Jelenleg az EIP-2938 változtatás nem aktív. A közösség az EIP-4337 javaslatot támogatja, mert ahhoz nem szükséges megváltoztatni a protokollt. - - - - - -Az EIP-3074 az Ethereumot úgy fejleszti, hogy a külső tulajdonú számlák képesek legyenek delegálni a kontrollt egy okosszerződésnek. Eszerint az okosszerződés logikája jóváhagyhat olyan tranzakciót, amely egy külső tulajdonú számlától (EOA) származik. Ez lehetővé teszi az olyan funkciók bevezetését, mint a gázdíjak szponzor általi kifizetése és a kötegelt tranzakciók. Ennek működéséhez két új operációs kódot kell hozzáadni az EVM-hez: AUTH és AUTHCALL. Az EIP-3074 révén az okosszerződéses tárca előnyei elérhetővé válnak úgy, hogy nem kell hozzá szerződés – ehelyett egy státuszmentes, bizalomigény-mentes, nem változtatható szerződés, a „hívó” kezeli a tranzakciókat. - -Jelenleg az EIP-3074 változtatás nem aktív. A közösség az EIP-4337 javaslatot támogatja, mert ahhoz nem szükséges megváltoztatni a protokollt. - - - -## Jelenlegi helyzet {#current-progress} - -Az okosszerződéses tárcák már elérhetők, de több fejlesztésre van szükség, hogy még decentralizáltabbak és engedélymentesek legyenek. Az EIP-4337 egy kiforrott javaslat, amely nem igényel változtatást az Ethereum-protokollban, ezért ezt gyorsan be lehet vezetni. Azok a fejlesztések, amelyekhez az Ethereum-protokollt módosítani kell, jelenleg nincsenek aktív állapotban, így ezek a változások hosszabb időt vesznek igénybe. Az is lehetséges, hogy a számlaabsztrakciót kellőképpen el lehet érni az EIP-4337 révén, ezért a protokollt nem is kell hozzá megváltoztatni. - -## További olvasnivaló {#further-reading} - -- [erc4337.io](https://www.erc4337.io/) -- [Panelbeszélgetés a számlaabsztrakcióról a Devcontól, Bogotából](https://www.youtube.com/watch?app=desktop&v=WsZBymiyT-8) -- [„A számlaabsztrakció miért hoz jelentős fejlődést a dappok számára?” – Devcon, Bogota](https://www.youtube.com/watch?v=OwppworJGzs) -- [„Számlaabsztrakció ELI5” – Devcon, Bogota](https://www.youtube.com/watch?v=QuYZWJj65AY) -- [Vitalik „Út a számlaabsztrakcióhoz” jegyzetei](https://notes.ethereum.org/@vbuterin/account_abstraction_roadmap#Transaction-inclusion-lists) -- [Vitalik blogbejegyzése a közösségi médiával visszaállítható tárcákról](https://vitalik.eth.limo/general/2021/01/11/recovery.html) -- [EIP-2938 jegyzetek](https://hackmd.io/@SamWilsn/ryhxoGp4D#What-is-EIP-2938) -- [EIP-2938 dokumentáció](https://eips.ethereum.org/EIPS/eip-2938) -- [EIP-4337 jegyzetek](https://medium.com/infinitism/erc-4337-account-abstraction-without-ethereum-protocol-changes-d75c9d94dc4a) -- [EIP-4337 dokumentáció](https://eips.ethereum.org/EIPS/eip-4337) -- [EIP-2771 dokumentáció](https://eips.ethereum.org/EIPS/eip-2771) -- [„A számlaabsztrakció alapjai” – Mi az a számlaabsztrakció, I. rész](https://www.alchemy.com/blog/account-abstraction) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/danksharding/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/danksharding/index.md deleted file mode 100644 index 09fe7abda99..00000000000 --- a/public/content/translations/hu/12) Roadmap 2/roadmap/danksharding/index.md +++ /dev/null @@ -1,95 +0,0 @@ ---- -title: Dank-féle párhuzamos futtatás (Danksharding) -description: Ismerje meg a Proto-Danksharding és a Danksharding egymást követő fejlesztéseit, amelyek az Ethereum-skálázását teszik lehetővé. -lang: hu -summaryPoints: - - A Danksharding egy többfázisú fejlesztés, amely javítja az Ethereum skálázhatóságát és kapacitását. - - Az első fázisban, ami a Proto-Danksharding, a blokkokhoz hozzáadják a blobokat - - Az adatblobok egy olcsóbb megoldást ajánlanak az összevont tranzakcióknak, hogy betegyék az adatokat az Ethereumra, és ez a felhasználóknál alacsonyabb tranzakciós díjként jelenjen meg. - - Ezután a Danksharding elosztja a felelősséget az adatblobok igazolásához a csomópontok csoportjai mentén, ezzel tovább skálázva az Ethereumot másodpercenként több mint 100 000 tranzakcióra. ---- - -# Dank-féle párhuzamos futtatás (Danksharding) {#danksharding} - -A **Danksharding** az a módszer, amivel az Ethereum egy valóban skálázható blokklánc lesz, ehhez azonban számos protokollfejlesztést kell végrehajtani. A **Proto-Danksharding** egy köztes lépés a megvalósításban. Mindkettő célja az, hogy a második blokkláncrétegen (L2) a tranzakciók a lehető legolcsóbbak legyenek a felhasználók számára, az Ethereum pedig több mint 100 000 tranzakciót tudjon feldolgozni másodpercenként. - -## Mi az a Proto-Danksharding? {#what-is-protodanksharding} - -A Proto-Danksharding, más néven [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844), az [összegzések](/layer-2/#rollups) egyik módja annak, hogy olcsóbb adatokat adjanak a blokkokhoz. A név attól a két kutatótól származik, akik ezt a módszert javasolták: Protolambda és Dankrad Feist. Korábban az összevont tranzakciókat a tranzakciók költségének csökkentésében behatárolta az a tény, hogy a tranzakciós adatokat a `CALLDATA` mezőbe posztolják. - -Ez egy drága megoldás, mert az Ethereum-csomópontok dolgozzák fel és a láncon örökre élő adat marad, miközben az összevont tranzakcióknak csak egy rövid időre lenne szükségük ezekre. A Proto-Danksharding az adatblobokat vezeti be, amelyeket el lehet küldeni és hozzá lehet csatolni a blokkokhoz. Az ezekben a blobokban lévő adatok nem elérhetők az EVM számára, és automatikusan törlődnek egy meghatározott idő után (a jelen írás idéjén ez 4096 korszak vagy 18 nap). Így az összevont tranzakciók sokkal olcsóbban be tudják küldeni az adatokat, és ez a felhasználóknak olcsóbb tranzakciókat eredményez. - - - -Az összevont tranzakciók az Ethereum skálázási megoldásai azáltal, hogy a tranzakciókat a láncon kívül kötegelik össze, majd azok eredményét posztolják az Ethereumra. összevont tranzakció lényegében két részből áll: adat és végrehajtás-ellenőrzés. Az adat a tranzakciók teljes sora, amelyet az összevont tranzakció dolgoz fel, hogy az Ethereumra beküldve megváltozzon annak státusza. A végrehajtás-ellenőrzés azt jelenti, hogy néhány jóhiszemű szereplő („bizonyító”) újra végrehajtja a tranzakciókat, hogy biztosan korrekt legyen a javasolt státuszváltozás. A végrehajtás-ellenőrzéshez a tranzakciós adatoknak elérhetőnek kell lenniük annyi időre, hogy azokat bárki letölthesse és ellenőrizni tudja. Így a bizonyító be tudja azonosítani és meg tudja kérdőjelezni az összevont tranzakció szekvenszerének rosszhiszemű viselkedését. Ugyanakkor az adatoknak nem kell örökre elérhetőnek maradniuk. - - - - - -A összevont tranzakciók elköteleződést posztolnak a tranzakciók adatai alapján a láncon belül, és az aktuális adatokat elérhetővé teszik az adatblobokban. Ezáltal a bizonyítók le tudják ellenőrizni az elköteleződések érvényességét, és meg tudják kérdőjelezni az általuk tévesnek tartott adatokat. A csomópont szintjén az adatblobok a konszenzusos kliensben találhatók. A konszenzus kliens tanúsítja, hogy látta az adatot és a elérhetővé vált a hálózaton. Ha az adatot örökre meg kellene tartani, akkor ezek a kliensek megnövekednek, és a csomópontok üzemeltetéséhez komoly hardverigények merülnének fel. Ehelyett az adatok automatikusan törlődnek a csomópontról 18 naponta. A konszenzusos kliens tanúsításai bizonyítják, hogy a bizonyítónak elegendő lehetősége volt az adatok ellenőrzésére. Az aktuális adatokat pedig tárolhatják a láncon kívül az összevont tranzakció üzemeltetői, a felhasználók vagy mások. - - - -### Hogyan ellenőrzik a blobadatokat? {#how-are-blobs-verified} - -A összevont tranzakciók az általuk feldolgozott tranzakciókat adatblobokban posztolják. Emellett posztolnak egy „elköteleződést” is. Tehát az adathoz hozzáillesztenek egy polinomiális funkciót. Ezt a funkciót számos ponton meg lehet vizsgálni. Például, ha egy rendkívül egyszerű függvényt definiálunk, `f(x) = 2x-1`, akkor ezt a funkciót megvizsgálhatjuk arra, hogy `x = 1`, `x = 2`, `x = 3`, amelyből az `1, 3, 5` eredmények származnak. A bizonyító ugyanezt a funkciót alkalmazza az adatra, és megvizsgálja azt ugyanazokon a pontokon. Ha az eredeti adat megváltozott, akkor a függvény sem lesz azonos, és az értékek is különbözni fognak minden ponton. Valójában az elköteleződés és a bizonyíték is elég bonyolult, mert kriptográfiai függvényekbe van csomagolva. - -### Mi az a KZG? {#what-is-kzg} - -A KZG a Kate-Zaverucha-Goldberg rövidítés egy olyan séma három [szerzője](https://link.springer.com/chapter/10.1007/978-3-642-17373-8_11), amely egy adathalmazt egy kis [kriptográfiai „elköteleződésre”](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) redukál. A összevont tranzakció által beküldött adatblobot ellenőrizni kell, hogy az összevont tranzakció megfelelően működik-e. Ennek lényege, hogy a bizonyító újrafuttatja a blobban lévő tranzakciókat, hogy megvizsgálja az elköteleződés érvényességét. Ez koncepcionálisan ugyanolyan, mint ahogy a végrehajtási kliensek ellenőrizik az Ethereum-tranzakciók érvényességét az első blokkláncrétegen (L1) a Merkle-bizonyítékok alapján. A KZG egy alternatív bizonyíték, amely egy polinomiális egyenletet illeszt az adathoz. Az elköteleződés megvizsgálja a polinomiálist néhány titkos adatponton. A bizonyító ugyanezt a polinomiálist illeszti rá az adatra, megvizsgálja ugyanazon értékeken, és ellenőrzi, hogy az eredmény ugyanaz-e. Ilyen módon lehetséges ellenőrizni az adatot a zero-knowledge technikákkal kompatibilis módon, amelyet néhány összevont tranzakció és az Ethereum-protokoll használ. - -### Mit volt a KZG-ceremónia? {#what-is-a-kzg-ceremony} - -A KZG-ceremónia egy olyan módszer volt, amellyel az Ethereum-közösség több tagja együtt létrehozhatott egy számokból álló titkos, véletlenszerű sorozatot, amelyet adatvalidálásra tudtak használni. Nagyon fontos volt, hogy ezt a számsort ne tudja meg senki és ne is lehessen újraalkotni azt. Ennek biztosításához minden egyes résztvevő az előző tagtól kapott egy részletet. Ekkor létrehozhattak néhány új, véletlenszerű értéket (pl. azzal, hogy a böngésző leköveti az egérmozgást), és ezt összekeverhették az előző részlettel. Ezután elküldték ezt az értéket a következő tagnak, és megsemmisítették a saját gépükön. Amíg volt legalább egy személy, aki jóhiszeműen végezte ezt a folyamatot, addig a támadó számára nem derült ki a végső érték. - -Az EIP-4844 KZG-ceremónia nyilvános volt és emberek tízezrei vettek benne részt, hogy hozzátegyék a saját entrópiájukat (véletlenszerűséget). Összesen több mint 140 000 hozzájáruló volt, ami a világ legnagyobb ilyen jellegű ceremóniájává tette. Ahhoz, hogy a ceremóniát megtámadhassák, ezeknek a résztvevőknek 100%-ban rosszhiszeműnek kell lenniük. A résztvevők szempontjából lényeges, hogy ha ő maguk jóhiszeműen jártak el, akkor nincs szükség arra, hogy megbízzanak másban, mert már maguk is biztosították a ceremóniát (egyénként kielégítették az N-ből 1 résztvevő kritériumot). - - - -Amikor egy összevont tranzakció adatot tesz a blobba, akkor egy „elköteleződést” ad, amit a láncon posztol. Ez az elköteleződés annak a vizsgálatnak az eredménye, ami bizonyos adatpontokon a polinomiális illesztést végzi. Ezeket a pontokat a KZG ceremónia által létrehozott véletlenszerű számok határozzák meg. Ekkor a bizonyítók ellenőrizhetik a polinomiálist ugyanazokon a pontokon, hogy az adat érvényességét igazolják – ha ugyanarra az értékre jutnak, akkor az adat helyes. - - - - - -Ha valaki ismeri az elköteleződéshez használt véletlenszerű helyet, akkor könnyedén kreálhat egy polinomiálist, ami illeszkedik a megadott pontokhoz (pl. egy „ütközés”). Ezt azt jelenti, hogy a blobhoz adhatnak vagy a blobból elvehetnek adatot, és mégis tudnak érvényes bizonyítékot adni róla. Ennek megakadályozására a bizonyítók nem az aktuális, titkos helyet kapják meg, hanem a helyet egy elliptikus görbét használó kriptográfiai „fekete dobozba” csomagolva kapják meg. Ezek gyakorlatilag annyira összetorlasztják az értékeket, hogy az eredetiket nem lehet visszafejteni, miközben néhány okos algebrai bizonyító és igazoló még mindig képes megvizsgálni a polinomiálisokat az általuk képviselt pontokon. - - - - - Se a Danksharding, se a Proto-Danksharding nem követi a hagyományos „sharding” (szilánkosítási) modellt, amelynek célja a blokklánc több részre való felosztása lenne. A shard láncok többé nem szerepelnek az Ethereum ütemtervben. Ehelyett a Danksharding elosztott adatmintavételt használ a blobokon keresztül, hogy az Ethereumot skálázza. Ezt sokkal egyszerűbb bevezetni. Ezt a modellt néha „adat-shardingnak” is nevezik. - - -## Mi az a Danksharding? {#what-is-danksharding} - -A Danksharding az összevont tranzakciós skálázási megoldás teljes megvalósítása, amely a Proto-Dankshardinggal kezdődik. A Danksharding az Ethereumon hatalmas helyet teremt az összevont tranzakcióknak, hogy az összecsomagolt tranzakciós adataikat beküldjék. Ezzel az Ethereum képes lesz könnyedén támogatni az egyéni összevont tranzakciók százait, és tranzakciók millióit végrehajtani minden másodpercben. - -Ez úgy működik, hogy a blokkokhoz csatolt blobokat a Proto-Danksharding hatról (6) a teljes Dankshardingban 64-re bővítjük. A szükséges változások többi része a konszenzus kliensek működését fejleszti, hogy azok képesek legyenek az új, nagy méretű blobokat kezelni. Ezen változások néhány része már benne van az ütemtervben, függetlenül a Danksharding bevezetéstől. Például a Dankshardinghoz szükséges a javaslattevő-építő szétválasztás (PBS) bevezetése. Ez egy olyan fejlesztés, amely szétválasztja a blokkok építését és azok előterjesztését a különböző validátorok között. Ugyanígy az adatelérhetőség-mintázás szükséges a Dankshardinghoz, de az igazán könnyű kliensek fejlesztéséhez is, amelyek nem tárolnak túl sok előzményadatot („státuszmentes kliensek”). - - - -A javaslattevő-építő szétválasztás (PBS) azért szükséges, hogy az egyéni validátoroknak ne kelljen kiterjedt elköteleződéseket és 32 MB-nyi blobadatra vonatkozó bizonyítékokat generálni. Ez túl nagy terhet jelentene az otthoni letétbe helyezőknek, és erőteljesebb hardvereket kellene beszerezniük a részvételhez, amely sértené a decentralizációt. Ehelyett specializált blokképítők veszik fel a költséges számítási művelet felelősségét. Majd a blokkot elérhetővé teszik a blokk javaslattevőinek, hogy azt elküldhessék. A javaslattevő egyszerűen a legnyereségesebb blokkot választja. Így bárki olcsón és gyorsan tudja ellenőrizni a blobokat, tehát bármelyik validátor megvizsgálhatja, hogy a blokképítők jóhiszeműen viselkednek-e. Így a nagy méretű blobokat úgy lehet feldolgozni, hogy az nem csökkenti a decentralizációt. A rosszhiszemű blokképítőket ki lehet zárni a hálózatból és meg lehet bünteti őket – mások majd a helyükbe lépnek, mert ez egy profitábilis tevékenység. - - - - - -Adatelérhetőség-mintázásra is szükség van, hogy a validátorok gyorsan és hatékonyan tudják ellenőrizni a blobadatokat. Az adatelérhetőség-mintázás segítségével a validátorok meggyőződnek arról, hogy a blobadat elérhető volt és megfelelő elköteleződés történt. Minden validátor véletlenszerűen választhat néhány adatpontot és létrehozhatja a bizonyítékot, így egyik validátornak sem kell az egész blobot ellenőrizni. Ha bármilyen adat hiányzik, azt gyorsan be lehet azonosítani, így a blobot elutasítják. - - - -### Jelenlegi helyzet {#current-progress} - -A teljes Danksharding bevezetéséhez még számos év szükséges. Időközben a KZG ceremóniája több mint 140 000 hozzájárulással zárult, és a Proto-Danksharding [EIP](https://eips.ethereum.org/EIPS/eip-4844)-je lejárt. Ezt a javaslatot az összes teszthálózatban maradéktalanul bevezették, és 2024 márciusában a Cancun-Deneb ("Dencun") hálózatfrissítéssel életbe lépett a Mainnet hálózaton. - -### További olvasnivaló {#further-reading} - -- [Proto-Danksharding jegyzetek](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) – _Vitalik Buterin_ -- [Dankrad jegyzetei a Dankshardingról](https://notes.ethereum.org/@dankrad/new_sharding) -- [Dankrad, Proto és Vitalik beszélgetése a Dankshardingról](https://www.youtube.com/watch?v=N5p0TB77flM) -- [A KZG-ceremónia](https://ceremony.ethereum.org/) -- [Carl Beekhuizen beszéde a Devconon a megbízható összeállításról](https://archive.devcon.org/archive/watch/6/the-kzg-ceremony-or-how-i-learnt-to-stop-worrying-and-love-trusted-setups/?tab=YouTube) -- [Bővebben az adatelérhetőség-mintázásról a blobokhoz](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) -- [Dankrad Feist a KZG elköteleződésekről és bizonyítékokról](https://youtu.be/8L2C6RDMV9Q) -- [KZG polinomiális elköteleződések](https://dankradfeist.de/ethereum/2020/06/16/kate-polynomial-commitments.html) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/dencun/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/dencun/index.md deleted file mode 100644 index 89028a204b3..00000000000 --- a/public/content/translations/hu/12) Roadmap 2/roadmap/dencun/index.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: Cancun-Deneb (Dencun) FAQ -description: Gyakori kérdések a Cancun-Deneb (Dencun) hálózati frissítés kapcsán -lang: hu ---- - -# Cancun-Deneb (Dencun) {#dencun} - -Cancun-Deneb (Dencun) az Ethereum-hálózat fejlesztése, mely bevezeti a **Proto-Danksharding (EIP-4844)** fejlesztést, lehetővé teszi az átmeneti **adatblobok** használatát, hogy olcsóbb legyen a [második blokkláncréteg (L2)](/glossary/#layer-2) összegzők tárolása. - -Egy új tranzakciótípus lehetővé teszi, hogy az összegzők költséghatékonyabban tudjanak adatot tárolni az úgynevezett „blobokban”. A blobok kb. 18 napig (pontosabban 4096 [korszakig](/glossary/#epoch)) elérhetők a hálózaton. Ezután a blobokat leválasztják a hálózatról, de az alkalmazások még mindig tudják az adatérvényességet ellenőrizni a bizonyítékok révén. - -Ez rendkívüli módon csökkenti az összegzők költségét, behatárolja a lánc növekedését, és több felhasználót képes kiszolgálni, miközben megtartja a biztonságot és a csomópontüzemeltetők decentralizált struktúráját. - -## Mikor lesznek az összegzőknek alacsonyabb díjaik a Proto-Danksharding következtében? {#when} - -- A frissítés a 269 568. korszakban lett telepítve, **2024. március 13-án, 13:55-kor (UTC)** -- A legnagyobb összegzők, mint az Arbitrum vagy Optimism, jelezték, hogy a blobokat azonnal használni fogják a frissíté után -- Az egyéni összegzők eltérő időpontban fognak átállni, mert mindnek frissíteni kell a maga rendszerét, hogy ki tudja használni az új blob-helyet - -## Hogyan lehet az ETH-t átváltani a végleges elágazás után? {#scam-alert} - -- **Az ETH-szel nincs teendője**: Az Ethereum Dencun frissítés után nincs szükség arra, hogy átváltsa vagy frissítse az ETH-t. A számlaegyenlege ugyanaz marad, a jelenleg Ön által birtokolt ETH elérhető marad az aktuális állapotában a végleges elágazás után is. -- **Figyeljen oda a csalásokra!**  **bárki mondja, hogy „frissítse” az ETH-t, az be akarja Önt csapni.** Ezzel a hálózatfrissítéssel kapcsolatban Önnek semmilyen teendője nincs. A pénzeszközei teljesen érintetlenek maradnak. Emlékezzen rá, hogy a legjobb védekezés a csalások ellen, ha Ön tájékozott. - -[Bővebben a csalások felismeréséről és elkerüléséről](/security/) - -## Milyen problémát old meg a Dencun hálózati frissítés? {#network-impact} - -A Dencun elsődlegesen a **skálázhatóságot** célozza (több felhasználó és több tranzakció kezelését) **megengedhető díjak** mellett, miközben a hálózat **decentralizációja megmarad**. - -Az Ethereum közössége egy összegzőalapú megközelítést alkalmaz a növekedésre, melynél a második blokkláncréteg (L2) összegzők biztosítják, hogy több felhasználó biztonságos módon használja a rendszert. - -A rollup hálózatok a főhálózattól függetlenül kezelik a tranzkaciók _feldolgozását_ (vagy „végrehajtását”), majd publikálják az eredmény kriptográfiai bizonyítékát és/vagy a tömörített tranzakciós adatokat a főhálózaton, hogy azok felkövethetők legyenek. Ezen bizonyítékok tárolása költséges ([gáz](/glossary/#gas) formájában), melyet a Proto-Danksharding előtt állandó módon kellett tárolnia minden csomópontüzemeltetőnek, ami drága feladat. - -A Proto-Danksharding bevezetése a Dencun frissítés által olcsóbb adattárolást tesz lehetővé ezen bizonyítékoknak, mivel a csomópontüzemeltetőknek csak 18 napig kell tárolni azokat, utána biztonsággal eltávolíthatóak, hogy ne növeljék tovább a hardverigényeket. Mivel az összegzőknek általában 7 napos visszavonási periódusuk van, ezért a biztonsági modelljük változatlan marad, amíg az L1-en ugyanilyen hosszen elérhetők a blobok. A 18 napos periódus egy kellően nagy időszakot biztosít erre. - -[Bővebben az Ethereum skálázásról](/roadmap/scaling/) - -## Hogyan lehet a régi blobadatokat elérni? {#historical-access} - -Miközben az általános Ethereum-csomópontok a hálózatnak a _jelen állapotát_ tárolják, a korábbi blobadatokat kb. 18 nappal később már mellőzni lehet. Mielőtt az adatot eltávolítaná, az Ethereum biztosítja, hogy az összes hálózati résztvevőnek elérhető volt arra, hogy: - -- Az érdekelt felek letöltsék és eltárolják az adatokat. -- Az összegző megkérdőjelezési periódusai lezáruljanak. -- Az összegző tranzakciói véglegessé váljanak. - -A blob-_előzményadatok_ számos okból szükségesek lehetnek, illetve azokat több decentralzált protokoll is elérheti és tárolhatja: - -- **Harmadik fél indexáló protokollok**, mint a The Graph, amelyek csomópont-üzemeltetők decentralizált hálózata révén tárolják ezeket az adatokat, melyet kriptogazdasági mechanizmusokkal ösztönöznek. -- **BitTorrent** egy decentralizált protokoll, ahol az önkéntesek tárolják és terjesztik ezeket az adatokat másoknak. -- **[Ethereum portal network](/developers/docs/networking-layer/portal-network/)** célja, hogy elérést biztosítson az Ethereum összes adatához a csomópont-üzemeltetők decentralizált hálózatán keresztül, akik között elosztják az adatokat, ahogy a BitTorrent esetében. -- **Egyéni felhasználók** bármikor eltárolhatják az adatokat, amelyre historikus okokból szükségük lehet. -- **Rollup szolgáltatók** számára érdemes tárolni ezeket az adatokat, hogy jobb legyen a felhasználói élmény. -- **Blokkfelfedezők** általában olyan archív csomópontokat futtatnak, melyek indexálják és eltárolják az összes információt, hogy visszakereshető legyen a felhasználóknak egy webfelületen keresztül. - -Fontos megjegyezni, hogy az előzményállapotok visszahíváse egy **N-ből 1 bizalmi modellen** alapszik. Eszerint csak _egyetlen megbízható forrásból_ kell adat ahhoz, hogy ellenőrizhető legyen a helyessége a hálózat jelen állapotát felhasználva. - -## Hogyan járul hozzá ez a frissítés az Ethereum nagyobb útitervéhez? {#roadmap-impact} - -Proto-Danksharding elősegíti a teljes [Danksharding](/roadmap/danksharding/) bevezetést. A Danksharding lényege, hogy a rollup-adatok tárolását elosztja a csomópont-üzemeltetők között, így az egyes operátoroknak csak a teljes adat egy kis részét kell kezelniük. Ez az elosztás megnöveli a blokkonkénti adatblobok számát, ami alapvető az Ethereum skálázásához, hogy több felhasználót és tranzakciót tudjon kezelni. - -Ez a skálázási megoldás elengedhetetlen ahhoz, hogy [felhasználók milliárdjait támogassa az Ethereum](/roadmap/scaling/) megengedhető díjakkal és fejlettebb alkalmazásokkal, miközben megőrzi a hálózat decentralizáltságát. E változások nélkül a csomópontüzemeltetők hardverigényei megnövekednének, amely egyre drágább gépeket követelne tőlük. Emiatt a kisebb üzemeltetők kiesnének a működésből, amitől koncentrálódna a hálózat irányítása néhány nagy operátornál, és ez ellene megy a decentralizáció alapelvének. - -## Érinti ez a frissítés az Ethereum összes konszenzusát és validátorkliensét? {#client-impact} - -Igen, a Proto-Danksharding (EIP-4844) következtében mind a végrehajtási klienseket, mind a konszenzusklienseket frissíteni kell. Az összes Ethereum-kliens új verziója elérhető, hogy alátámassza ezt a frissítést. A frissítés után az Ethereum-hálózattal való szinkronizáció érdekében a csomópont-üzemeltetőknek támogatott kliensverziót kell futattniuk. Vegye figyelembe, hogy a kliensverziók adott időben érvényesek, a felhasználók a legutóbbi frissítéseket vegyék figyelembe. [Tekintse meg a támogatott kliensverziók részleteit](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement#client-releases). - -A konszenzuskliensek kezelik a _validátorszoftvert_, melyek mind frissítve lettek, hogy eleget tegyenek a változásnak. - -## Hogyan érinti a Cancun-Deneb (Dencun) a Goerlit és az Ethereum egyéb teszthálózatait? {#testnet-impact} - -- A fejlesztői hálózatok, a Goerli, Sepolia és a Holesky is mind átesik a Dencun frissítésen és a Proto-Danksharding teljes mértékben működik ezekben -- A rollup-fejlesztők használhatják ezeket a hálózatokat az EIP-4844 tesztelésre -- A legtöbb felhasználót ugyanakkor a teszthálózatok változása egyáltalán nem érinti - -## Innentől fogva az összes L2-es tranzakció blobhelyet használ majd, vagy választani lehet? {#calldata-vs-blobs} - -Az Ethereum második blokkláncrétegének (L2) összegzői kétféle tárhelyet használhatnak: átmeneti blobhely vagy állandó okosszerződéses calldata. A blobhely egy gazdaságos megoldás, átmeneti tárolást ad alacsonyabb költségen. Biztosítja az adatelérhetőséget a megkérdőjelezési időszakra. Másrészt az okosszerződés calldata állandó tárhelyet biztosít, de sokkal drágább. - -A döntést a blobhely és a calldata között a rollup-szolgáltatók hozzák meg. Ezt a döntést a blobhely iránti igény befolyásolja. Ha a bobhelyre nagy az igény, akkor a rollupok talán a calldata-t választják, hogy időben el tudják tárolni az adatokat. - -Bár elméletileg a felhasználó is választhat, de az a jellemző, hogy a rollup-szolgáltatók hozzák meg ezt a döntést. Ha a felhasználók hoznának döntést, az összetettebb helyzetet teremtene, főleg a költséghatékény tranzakciócsomagolás esetén. E döntés részleteit a felhasználók megtekinthetik a rollup-szolgáltatók dokumentációiban. - -## A 4844 csökkenti az L1 gázdíjat? {#l1-fee-impact} - -Nem igazán. Egy új gázpiac jött létre kizárólag a blobhelyeknek a rollup-szolgáltatók részére. _Habár az L1 díjak csökkenhetnek azzal, hogy a rollup-adatokat blobokba teszik, ez a frissítés elsősorban arra fókuszál, hogy az L2-es díjak csökkenjenek. Az L1 (főhálózat) díjainak csökkenése másodlagos hatás, mely kisebb mértékű._ - -- Az L1 gázcsökkenés arányos azzal, hogy a rollup-szolgáltatók mennyire kezdik el használni a blobadatokat -- Az L1 gáz valószínűleg versenyképes marad a nem rollup-jellegű tevékenységek révén -- Azok az összegzők, amelyek blobhelyet használnak, kevesebb L1 gázt igényelnek, ezért annak díja csökkenhet -- A blobhely még behatárolt, ezért ha egy blokkban tele van a blob, akkor a rollup kénytelen állandó tárhelyet használni, ami növeli az L1 és L2 gázárakat is - -## Csökkenteni fogja ez a változás a többi EVM L1 blokkláncok díjait? {#alt-l1-fee-impact} - -Nem. A Proto-Danksharding által hozott előnyök az Ethereum L2 rollupokra vonatkoznak, melyek a bizonyítékokat az L1-en (főhálózat) tárolják. - -Az a tény, hogy valami kompatibilis az Ethereum virtuális géppel (EVM), nem jelenti azt, hogy ebből a frissítésből bármilyen előnyt is élvezne. Az Ethereumtól függetlenül működő hálózatok (legyenek akár EVM-kompatibilisek vagy sem) nem tárolják az adataikat az Ethereumon, így nem hoz számukra előnyt ez a frissítés. - -[Bővebben az L2 rollupokról](/layer-2/) - -## Ön inkább vizuális típus? {#visual-learner} - - - -_Az Ethereum skálázása, EIP-4844 — Finematics_ - - - -_Blobhely 101 Domothy-val — Bankless_ - -## További olvasnivaló {#further-reading} - -- [EIP4844.com](https://www.eip4844.com/) -- [EIP-4844: Elosztott blob tranzakciók (Proto-Danksharding)](https://eips.ethereum.org/EIPS/eip-4844) -- [Dencun főhálózati bejelentés](https://blog.ethereum.org/2024/02/27/dencun-mainnet-announcement) - _Ethereum Foundation blog_ -- [The Hitchhiker's Guide to Ethereum: Proto-Danksharding](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum/#proto-danksharding-eip-4844) - _Jon Charbonneau_ -- [Proto-Danksharding GYIK](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) - _Vitalik Buterin_ -- [Részletes magyarázat az EIP-4844-ről: A Cancun frissítés lényege](https://medium.com/@ebunker.io/an-in-depth-explanation-of-eip-4844-the-core-of-the-cancun-upgrade-de7b13761d2c) - _Ebunker_ -- [AllCoreDevs Update 016](https://tim.mirror.xyz/HzH5MpK1dnw7qhBSmzCfdCIxpwpD6DpwlfxtaAwEFro) - _Tim Beiko_ diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/pbs/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/pbs/index.md deleted file mode 100644 index cc32211809a..00000000000 --- a/public/content/translations/hu/12) Roadmap 2/roadmap/pbs/index.md +++ /dev/null @@ -1,51 +0,0 @@ ---- -title: Javaslattevő-építő szétválasztása -description: Ismerje meg, hogy az Ethereum-validátorok hogyan és miért osztják fel a blokképítési és -küldési feladatokat. -lang: hu ---- - -# Javaslattevő-építő szétválasztása {#proposer-builder-separation} - -Jelenleg az Ethereum validátorok blokkokat hoznak létre_és_ küldenek. Összecsomagolnak olyan tranzakciókat, amelyekről tudomást szereztek a pletykahálózaton keresztül, blokkot készítenek azokból és elküldik a társaiknak az Ethereum-hálózaton. A **javaslattevő-építő szétválasztás (PBS)** szétosztja ezeket a feladatokat a validátorok között. A blokk építői minden egyes slotban létrehozzák a blokkokat és felajánlják azokat a javaslattevőnek, aki az adott slotban felel az előterjesztésért. A javaslattevő nem láthatja a blokk tartalmát, egyszerűen a legjövedelmezőbbet választja, és megfizeti a blokképítés díját, mielőtt elküldi a blokkot a társainak. - -Ez több szempontból is egy fontos fejlesztés. Először is lehetővé teszi, hogy a tranzakciók cenzúrázása protokoll szinten ne történhessen meg. Másodsorban az egyszerűbb validátorokat nem tudják kirekeszteni a versenyből az intézményes résztvevők, akik jobban tudják optimalizálni a blokképítési profitjukat. Harmadjára az Ethereum-skálázását is támogatja azáltal, hogy lehetővé teszi a Danksharding fejlesztéseket (párhuzamos futtatás). - -## A PBS és a cenzúrának való ellenállás {#pbs-and-censorship-resistance} - -A blokk építésének és előterjesztésének szétválasztása megnehezíti a blokképítők számára, hogy cenzúrázzák a tranzakciókat. Ennek az az alapja, hogy egy viszonylag összetett kritériumokat lehet megadni arra, hogy minek muszáj benne lennie a blokkban, ezért a javaslattevés előtt nem lehet a tranzakciókat cenzúrázni. Mivel a javaslattevő egy másik entitás az építőhöz képest, ezért védekezhet a cenzúrázó blokképítők ellen. - -Például bekerülési listákat tud adni a javaslattevő, hogy a tudomására jutott tranzakciókat, amelyeket mégsem lát az adott blokkban, a következő építésnél kötelezővé tudja tenni. Ezt a bekerülési listát a javaslattevő a saját memóriakészletéből (tranzakciók, amelyekről tudomása van) készíti és küldi el a társainak még mielőtt a blokkjavaslat megtörténne. Ha a bekerülési listáról bármely tranzakció hiányzik, akkor a javaslattevő elutasíthatja az adott blokkot, hozzáteheti a hiányzó tételeket mielőtt javasolja azt, vagy elküldheti a javaslatot és a többi validátorra bízhatja, hogy azok utasítsák el. Ennek az elképzelésnek létezik egy valószínűleg még hatékonyabb verziója, amikor az építőtől azt várjuk, hogy teljesen kihasználja a blokkhelyet, és ha nem teszi, akkor a bekerülési listáról lehet még hozzáadni tranzakciókat a blokkhoz. Ez jelenleg egy aktív kutatási terület, a bekerülési listák optimális konfigurálása még nem dőlt el. - -[A titkosított memóriakészletek](https://www.youtube.com/watch?v=fHDjgFcha0M&list=PLpktWkixc1gUqkyc1-iE6TT0RWQTBJELe&index=3) nem teszik lehetővé az építő és a javaslattevő számára, hogy tisztában legyenek a blokkba foglalt tételekkel, csak miután az már elküldésre került. - - - -A nagyobb hatalommal bíró szervezetek nyomást gyakorolhatnak a validátorokra, hogy zárjanak ki bizonyos címekre menő vagy onnan jövő tranzakciókat. A validátorok ennek megfelelően beazonosíthatják a feketelistás tételeket a tranzakciógyűjtőben és kihagyhatják azokat a javasolt blokkból. A PBS után ez nem lehetséges, mert a javaslattevő nem fogja tudni, hogy milyen tranzakciók szerepelnek az általa elküldött blokkban. Bizonyos egyéneknek vagy alkalmazásoknak talán fontos lehet bizonyos cenzúraszabályoknak megfelelni, amikor az adott régióban azt törvény szabályozza. Ezekben az esetekben a szabálynak való megfelelés az alkalmazás szintjén történik, így a protokoll továbbra is engedélymentes és cenzúramentes marad. - - - -## A PBS és a MEV {#pbs-and-mev} - -A **maximálisan kinyerhető érték (MEV)** arra utal, amikor a validátorok maximalizálják a nyereségüket azzal, hogy kedvezőségi sorrendbe állítják a tranzakciókat. Általános példa az arbitrázs célú átváltás a decentralizált tőzsdéken (pl. egy nagy értékű eladás vagy vétel elé kerülve), vagy annak észlelése, hogy egy pénzügyi (DeFi) pozíciót érdemes lenne likvidálni. A MEV maximalizálása olyan szofisztikált technikai tudást és személyre szabott szoftverkiegészítéseket igényel a normális validátorhoz képest, hogy sokkal valószínűbb, hogy az intézményes működtetők lehagyják az egyéneket vagy egyszerű validátorokat a MEV kinyerése kapcsán. Emiatt a letétbe helyezés díjai valószínűleg magasabbak lesznek a centralizált működtetőknél, ami olyan központosítő erőt hoz létre, amely nem motiválja az otthoni letétbe helyezést. - -A PBS úgy oldja meg ezt a problémát, hogy újrakonfigurálja a MEV gazdasági helyzetét. Ahelyett, hogy a blokk javaslattevője végezne saját MEV keresést, egyszerűen felvesz egy blokkot a neki felajánlottak közül, amelyet a blokképítők készítettek. A blokk építői végezhetnek szofisztikált MEV-kinyerést, de ennek nyeresége a javaslattevőhöz jut. Tehát még ha a MEV kinyerést dominánsan néhány specializált blokképítő végzi, ennek jutalma a hálózat bármelyik validátorához kerülhet, beleértve az egyéni, otthoni letétbe helyezőket. - - - -Az egyéneket arra motiválhatja, hogy egyéni letétbe helyezés helyett inkább készletekbe tegyék a letétet, mert a szofisztikált MEV-stratégiák miatt az nagyobb nyereséget kínál. A blokk építőjének és javaslattevőjének elkülönítése azt jelenti, hogy a kinyert MEV több validátornál kerül elosztásra, nem pedig a leghatékonyabb MEV-kinyerőnél központosul. Emellett a specializált blokképítők levehetik az egyénekről a blokk készítésének terhét, megakadályozhatják, hogy az egyének saját maguknak vegyenek ki MEV-et a validálás során, miközben maximalizálják az egyéni, független validátorok számát, akik jóhiszemű módon képesek ellenőrizni a blokkokat. A fontos koncepció a „bizonyító-ellenőrző aszimmetria”, amelynek lényege, hogy a centralizált blokklétrehozás rendben van addig, amíg robosztus és maximálisan decentralizált validátorhálózat áll rendelkezésre a blokkok jóhiszemű igazolásához. A decentralizáció egy eszköz, nem pedig végcél – valós blokkokat szeretnénk elérni. - - -## A PBS és a Danksharding {#pbs-and-danksharding} - -A Danksharding az a módszer, amivel az Ethereum skálázza a teljesítményt, hogy másodpercenként több mint 100 000 tranzakciót kezeljen és közben minimalizálja az összevont tranzakcióért fizető felhasználók által fizetett díjakat. A PBS-en alapszik, mert a blokképítőknek extra feladatot ad, akiknek bizonyítékot kell készíteniük 64 MB-nyi összevonttranzakció-adatra kevesebb mint 1 másodperc alatt. Ehhez valószínűleg specializált építőkre van szükség, akik elég komoly hardvert tudnak kijelölni ehhez a feladathoz. A nem PBS szerinti helyzetben a blokképítés egyre inkább centralizálódhat a szofisztikáltabb és erőteljesebb működtetők körül a MEV kinyerése miatt is. A javaslattevő-építő szétválasztás (PBS) egy olyan mód, amely felöleli ezt a valóságot és megakadályozza a blokkvalidálás központosítását (ami nagyon fontos), illetve elősegíti a letéti jutalmak elosztását. Remek lehetőség ez arra is, hogy a specializált blokképítők hajlandók és képesek legyenek kiszámolni a Dankshardinghoz szükséges adatbizonyítékokat. - -## Jelenlegi helyzet {#current-progress} - -A PBS a kutatás előrehaladott fázisában tart, bár akadnak még fontos kérdések, mielőtt az Ethereum klienseknél bevezetésre kerül. Nincs még véglegesített specifikáció. Ebből adódhat, hogy akár egy év is szükséges a bevezetésére. Tekintse meg a [kutatás jelenlegi állapotát](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance). - -## További olvasnivaló {#further-reading} - -- [Kutatási állapot: cenzúrának való ellenállás a PBS esetén](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) -- [PBS-barát díjpiac dizájn](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) -- [A PBS és a cenzúrának való ellenállás](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Secondary-auctions) -- [Bekerülési listák](https://notes.ethereum.org/@fradamt/H1ZqdtrBF) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/secret-leader-election/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/secret-leader-election/index.md deleted file mode 100644 index 893d104f6bc..00000000000 --- a/public/content/translations/hu/12) Roadmap 2/roadmap/secret-leader-election/index.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: Titkos vezetőválasztás -description: Annak áttekintése, hogyan segíthet a titkos vezetőválasztás a validátorokat megvédeni a támadóktól -lang: hu -summaryPoints: - - A blokkjavaslók IP-címe előre ismert, így sebezhetővé válnak a támadásokkal szemben - - A titkos vezetőválasztás elrejti a validátorok személyazonosságát, így nem tudni előre, hogy kire esik a választás - - Ezen elképzelés egyik további lépése az, hogy minden slotban legyen véletlenszerű a validátorválasztás. ---- - -# Titkos vezetőválasztás {#single-secret-leader-election} - -A jelenlegi [proof-of-stake](/developers/docs/consensus-mechanisms/pos) alapú konszenzusmechanizmusban a következő blokkjavaslók nyilvánosak, és az IP-címüket hozzájuk lehet kapcsolni. Tehát a támadók be tudják azonosítani, hogy melyik validátor fogja a következő blokkot javasolni, megtámadhatják őt egy szolgáltatásmegtagadásos (denial-of-service/DOS) támadással, így nem tudják időben javasolni a blokkot. - -Ez lehetőséget nyújt a támadó számára, hogy profitra tegyen szert. Például a blokkjavasló, akit a slot `n+1`-ra választottak, megtámadja a blokkjavaslót a slot `n`-ben, így az nem tud blokkot javasolni. Így a támadó két slotra vonatkozó MEV-et (maximálisan kinyerhető értéket) tud kivonni, vagy az összes tranzakciót egyben berakja egy blokkba, hogy az összes díjat megszerezze. Ez nagy valószínűséggel jobban érinti az otthoni validálókat, mint a szofisztikált, szervezeti validátorokat, akik fejlettebb módokon tudják védeni magukat, így ennek az egésznek centralizáló hatása van. - -Számos megoldás létezik erre a problémára. Az egyik az [elosztottvalidátor-technológia](https://github.com/ethereum/distributed-validator-specs), ami elosztja a validátorhoz szükséges feladatokat több számítógépen, némi duplikációval (extra kapacitással), így a támadónak sokkal nehezebb megakadályozni a javaslatot egy adott slotban. A legrobusztusabb megoldás a **Single Secret Leader Election (SSLE)**, vagyis az egyetlen, titkos vezető kiválasztása. - -## Egyetlen, titkos vezető kiválasztása {#secret-leader-election} - -Az SSLE-ben okos kriptográfia biztosítja, hogy csak a kiválasztott validátor tudja, hogy őt választották. Minden validátor elköteleződik egy titok mellett, amelyet mind ismernek. Az elköteleződéseket összekeverik és újrakonfigurálják, hogy senki se tudja összekapcsolni azokat a validátorok elköteleződésével, de minden validátor tudja, hogy melyik tartozik őhozzá. Majd a rendszer véletlenszerűen választ egyet. Ha egy validátor azt észleli, hogy az ő elköteleződésére esett a választás, akkor tudja, hogy neki kell javasolnia a blokkot. - -Ennek az elképzelésnek a vezető implementációja a [Whisk](https://ethresear.ch/t/whisk-a-practical-shuffle-based-ssle-protocol-for-ethereum/11763). Ami a következőképpen működik: - -1. A validátorok elköteleződnek egy közös titok mellett. Az elköteleződési séma úgy van kialakítva, hogy bár köthető a validátor személyazonosságához, de egyúttal véletlenszerű is, így egy harmadik fél nem tudja visszafejteni az adott validátor személyazonosságát. -2. A korszak kezdetén a validátorok véletlenszerű csoportja kerül kiválasztásra, hogy mintát vegyenek a 16 384 validátorból a RANDAO használatával. -3. A következő 8182 slotra (1 nap), a blokkjavaslók összekeverik és véletlenszerűsítik az elköteleződések csoportját a saját privát entrópiájukat (véletlenszerűség) használva. -4. Ezután RANDAO készít egy sorba rendezett listát az elköteleződésekből. Ez a lista az Ethereum slotokhoz kapcsolódik. -5. A validátorok látják, hogy az elköteleződésük egy specifikus slothoz kapcsolódik, és annak bekövetkeztével javasolják a blokkot. -6. Ezeket a lépéseket ismétlik, hogy a hozzárendelés előrébb tartson, mint az aktuális slot. - -Ekkor a támadók nem tudják előre, hogy amelyik validátor jön legközelebb, így nem tudják megtámadni DOS módszerrel. - -## Egynél több titkos vezető kiválasztása (SnSLE) {#secret-non-single-leader-election} - -Van egy másik javaslat is, amelynek lényege, hogy a validátorok mindegyikének véletlenszerű esélye legyen a blokkjavaslásra minden slotban, hasonlóan ahhoz, ahogy a proof-of-work működött, ennek a neve a**egynél több titkos vezető kiválasztása (SnSLE)**. Az adott napi protokollban lévő validátorok véletlenszerű kiválasztásához egyszerű módot kínál a RANDAO-funkció. Ennek lényege, hogy egy kellően véletlenszerű szám keletkezik, amelyet több független validátor adat kevert hashekből. Az SnSLE esetében ezeket a hasheket lehetne használni a következő blokkjavasló kiválasztására, például a legkevesebb értékű hasht választva. Az érvényes hashek tartománya behatárolható, hogy finomhangolják a valószínűségét egy adott validátor kiválasztásának minden slotban. Ha a hashnek kevesebbnek kell lennie, mint `2^256 * 5 / N` ahol `N` az aktív validátorok számát jelenti, akkor annak az esélye, hogy valamelyik egyéni validátort kiválasztják a slotban az `5/N`. Ebben a példában 99,3% az esélye, hogy legalább egy blokkjavasló valid hasht készített minden slotban. - -## Jelenlegi helyzet {#current-progress} - -Az SSLE és az SnSLE még kutatási fázisban van. Nincs véglegesített specifikáció egyik elképzelésre sem. Az SSLE és az SnSLE egymással versengő javaslatok, nem lehet mindkettőt bevezetni. A bevezetéshez több kutatásra és fejlesztésre, prototípus-készítésre és a nyilvános teszthálózatokon való telepítésre van szükség. - -## További olvasnivaló {#further-reading} - -- [SnSLE](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/single-slot-finality/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/single-slot-finality/index.md deleted file mode 100644 index 0646ca66ed5..00000000000 --- a/public/content/translations/hu/12) Roadmap 2/roadmap/single-slot-finality/index.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Egy sloton belüli véglegesség -description: Az egy sloton belüli véglegesség magyarázata -lang: hu ---- - -# Egy sloton belüli véglegesség {#single-slot-finality} - -Jelenleg 15 percet vesz igénybe, hogy egy Ethereum blokk véglegesedjen. Ugyanakkor az Ethereum konszenzusmechanizmusa úgy is fejleszthető, hogy a blokk validálása hatékonyabb legyen, és a véglegességhez szükséges idő drasztikusan csökkenjen. Ahelyett, hogy egy blokk javaslásához tizenöt perc kellene, azt ugyanabban a slotban lehessen javasolni és véglegesíteni. Ezt a koncepciót nevezik **egy sloton belüli véglegességnek (SSF)**. - -## Mi az a véglegesség? {#what-is-finality} - -Az Ethereum proof-of-stake alapú konszenzusmechanizmusában a véglegesítés arra utal, hogy a blokkot nem lehet megváltoztatni vagy eltávolítani a blokkláncból anélkül, hogy legalább 33%-nyi résztvevő vállalná az ezzel járó súlyos büntetést, vagyis az ETH elégetését. Ez egy kriptogazdasági biztonság, mert nagyon nagy költséggel járna, ha valaki meg akarná változtatni a lánc sorrendjét vagy tartalmát, így a racionális gazdasági szereplők nem vállalnák. - -## Miért törekszünk gyorsabb véglegesítésre? {#why-aim-for-quicker-finality} - -A véglegessé válás jelenlegi ideje túl hosszúnak bizonyult. A legtöbb felhasználó nem akar 15 percet várni, hogy végleges legyen a tranzakciója. Továbbá az alkalmazások és tőzsdék számára is kellemetlen, amelyek gyors tranzakcióátvitelt szeretnének, és mégis sokáig kell várniuk, hogy állandónak tekinthessék a változást. A blokk előterjesztése és a véglegesítése közötti idő arra is lehetőséget teremt, hogy egy támadó átrendezze a tartalmat, illetve hogy blokkokat cenzúrázzon vagy MEV-et szerezzen. Az a mechanizmus, amely a várakozó blokkok frissítését intézi, elég összetett és számtalanszor volt már javítva, hogy a gyenge biztonsági pontokat lezárják, így ez az Ethereum kódjának ez az a része, ahol kisebb hibák nagy valószínűséggel fordulnak elő. Ezeket a problémákat mind megoldaná, hogy ha egy slotban véglegessé válna a blokk. - -## A decentralizáció/idő/költség átváltása {#the-decentralization-time-overhead-tradeoff} - -A véglegesség garanciája az új blokknál nem azonnal történik meg; idő kell ahhoz, hogy a blokkot véglegesnek tekintsük. Ennek az az oka, hogy a véglegesítéshez a teljes letétbe helyezett ETH 2/3-át képviselő validátoroknak tanúsítaniuk kell az új blokkot. A hálózat minden validáló csomópontjának a többi csomóponttól érkező tanúsításokat kell feldolgoznia, hogy a blokk elérte a 2/3-os határt vagy nem. - -Minél rövidebb idő alatt kell elérni a véglegesedést, annál komolyabb számítási kapacitásra van szükség a csomópontoknál, mert a tanúsítást gyorsan kell elvégezni. Emellett minél több validáló csomópont van a hálózaton, annál több tanúsításra van szükség blokkonként, ami növeli a feldolgozási kapacitási igényt. Ha nagyobb feldolgozási kapacitás szükséges, akkor kevesebb személy vehet részt benne, mert drága hardvert kell ahhoz használni, hogy a validáló csomópont működjön. Ha a blokkok között több idő telik el, akkor kevesebb számítási kapacitás is elég a csomópontokhoz, de a véglegesedés is később történik meg, mert a tanúsításokat lassan dolgozzák fel. - -Így tehát átváltás van jelen a költség (számítási kapacitás), a decentralizáció (a validációban részt vevő csomópontok száma) és a véglegesítés ideje között. Az ideális rendszer a minimális számítási kapacitás, a maximális decentralizáció és a minimális véglegesítési idő között egyensúlyoz. - -Az Ethereum jelenlegi konszenzusmechanizmusa e három paraméter között a következőképpen egyensúlyoz: - -- **A minimális letétbe helyezést 32 ETH-ben állapítja meg**. Ez meghatároz egy felső határt arra, hogy a validátoroknak mennyi tanúsítást kell végezniük, amelyet az egyéni csomópontok hajtanak végre, és ezáltal egy felső határt határoz meg e csomópontok számítási igényeinek is. -- **A véglegesítés idejét kb. 15 percre teszi**. Ez elegendő időt ad az otthoni számítógépen futó validátoroknak is, hogy biztonsággal elvégezzék minden blokk tanúsítását. - -A jelenlegi mechanizmussal a véglegesítés idejét úgy lehet csökkenteni, ha csökkentjük a validátorok számát a hálózaton vagy növeljük a hardverszükségletet minden csomópont esetében. Ugyanakkor fejleszthető a tanúsítások végzése is, amellyel több tanúsítás lehetséges növekvő költség és az egyes csomópontok túlterhelése nélkül. A hatékonyabb végrehajtás lehetővé teszi, hogy a véglegesítés egy sloton belül, ne két korszak alatt történjen meg. - -## Az egy sloton belüli véglegesítéshez (SSF) vezető út {#routes-to-ssf} - - - -A jelenlegi konszenzusmechanizmus összekombinálja a több validátortól, vagyis a bizottságtól származó tanúsítást, hogy csökkentse az üzenetek számát, amelyet minden validátornak fel kell dolgoznia a validálás során. Minden validátornak lehetősége van tanúsítani egy adott korszakban (32 slot), de egy adott slotban csak a validátorok egy csoportja, a bizottság végzi a tanúsítást. Ehhez alhálózatokra osztódnak, amelyekben néhány validátor aggregátorként működik. Ezek az aggregátorok a saját alhálózatukban lévő validátortól látott összes aláírást összevonják egy aggregált aláírásba. Az aggregátor, aki a legtöbb egyéni hozzájárulást tudta összevonni, átadja az aggregált aláírást a blokk javaslattevőjének, aki azt beleteszi a blokkba a többi bizottságtól kapott aggregált aláírással együtt. - -Ez a folyamat elegendő kapacitást ad minden validátornak, hogy szavazzon minden korszakban, mert ez korszakonként 32 slot × 64 bizottság× 256 validátor bizottságonként = 524 288 validátor. A jelen szöveg írásának időpontjában (2023. február) kb. 513 000 aktív validátor van. - -E séma szerint egy teljes korszak kell ahhoz, hogy minden validátor részt vehessen a tanúsításban egy blokkhoz kapcsolódóan. Ugyanakkor lehetséges ezt a mechanizmust úgy is továbbfejleszteni, hogy minden validátor minden slotban végezhessen tanúsítást. - - -Mióta az Ethereum konszenzusmechanizmusát megtervezték, az aláírásaggregálás sémája (BLS) sokkal skálázhatóbbnak bizonyult, mint azt korábban gondolták, és közben a kliensek is fejlődtek az aláírások feldolgozásában és ellenőrzésében. Kiderült, hogy a nagy számú validátor valójában egyetlen slotban is képes végrehajtani a tanúsításokat. Például egymillió validátorral, akik közül mindenki kétszer szavaz egy slotban, a slot ideje pedig 16 másodperc, a csomópontoknak az aláírások ellenőrzését egy minimális másodpercenként 125 000 aggregációs rátán kellene végrehajtaniuk, hogy egymillió tanúsítást végezzenek a slotban. Valójában egy átlagos számítógépnek 500 nanomásodpercig tart egy aláírás ellenőrzése, tehát 125 000 ellenőrzést nagyjából 62,5 ms alatt végezne el – jóval az egy másodperces határ alatt. - -Még hatékonyabb lenne, ha szuperbizottságokat hoznának létre, pl. 125 000 véletlenszerűen kiválasztott validátort slotonként. Csak ezek a validátorok szavaznának egy adott blokkra, ezért a validátoroknak csak ezen alcsoportja döntene a blokk véglegesítéséről. Hogy vajon ez egy jó ötlet vagy sem, az azon múlik, hogy a közösség számára mennyire drága egy sikeres támadás az Ethereum ellen. Mivel ahelyett, hogy a támadó véglegesíteni tudna egy blokkot, ha a teljes letétbe helyett ethernek a 2/3-t kontrollálja, csak a _szuperbizottságban_ kell a 2/3-nyi lekötött etherrel bírnia egy rosszhiszemű blokk véglegesítéséhez. Ez továbbra is egy aktívan kutatott terület, de valószínű, hogy egy igazán nagy méretű validátorkészlet esetén, amelynél már szuperbizottságokat kell bevezetni, ezen csoportok megtámadásának költsége rendkívül magas lenne (pl. a denominált költség ETH-ben `2/3 × 125 000 × 32 = kb. 2,6 millió ETH`). A támadás költsége igazítható azáltal, hogy a validátorkészlet méretét megnövelik (pl. úgy igazítható a validátorszám, hogy a támadás költsége 1, 4, 10 stb. millió ether legyen). [A kezdeti vélemények](https://youtu.be/ojBgyFl6-v4?t=755) a közösség részéről azt sugallják, hogy az 1-2 millió ether egy elfogadható támadási költség, ami szuperbizottságonként ~65 536–97 152 validátort jelentene. - -Ugyanakkor nem az ellenőrzés a valódi szűk keresztmetszet, hanem az aláírások aggregálása a kihívás a validátor-csomópontok számára. Az aláírásaggregáció skálázásához a validátorok számát valószínűleg meg kell növelni minden alhálózatban, növelni kell az alhálózatok számát, vagy az aggregáció új rétegeit kell bevezetni (pl. a bizottságok bizottságát létrehozni). A megoldás része lehet a specializált aggregátorok létrehozása is, hasonlóan ahhoz, ahogy a javaslattevő-építő szétválasztás (PBS) és a Danksharding bevezetésénél a blokk építését és az összevont tranzakcióhoz tartozó elköteleződés létrehozását kiszervezik specializált építőknek. - -## Mi a szerepe az elágazásválasztásnak az SSF-ben? {#role-of-the-fork-choice-rule} - -A jelenlegi konszenzusmechanizmus a véglegesedési mechanizmus és az elágazásválasztás közötti szoros kapcsolaton alapszik, az első az az algoritmus, amely meghatározza, hogy a validátorok 2/3-a tanúsított-e egy adott láncot, a második pedig az az algoritmus, amelyik eldönti, hogy melyik lánc a megfelelő, amikor több opció is létezik. Az elágazásválasztás algoritmusa csak azokat a blokkokat veszi figyelembe, amelyek az utolsó véglegesített blokk _után_keletkeznek. Az SSF bevezetésével nem lesz olyan blokk, ami az elágazásválaszt határkörébe esik, mert a véglegesítés ugyanabban a slotban történik, mint a blokk előterjesztése. Ennélfogva az SSF bevezetésével _sem_ az elágazásválasztás algoritmusa, _sem_ a véglegességi mechanizmus nem lesz aktív. A véglegességi mechanizmus véglegesítené azokat a blokkokat, ahol a validátorok 2/3-a online volt és jóhiszeműen tanúsított. Ha a blokk nem tudná meghaladni a 2/3-os határt, akkor az elágazásválasztási szabály lépne életbe, hogy meghatározza a követendő láncot. Ez arra is lehetőséget ad, hogy az inaktivitás miatti elszivárgás mechanizmusát fenntartsák, amely visszaállítja a láncot, amikor a validátorok több mint 1/3-a offline, jóllehet némileg továbbfejlesztve azt. - -## Fennálló problémák {#outstanding-issues} - -Ha az aggregáció skálázásához az alhálózatokban megnövelnék a validátorok számát, az azzal a problémával járna, hogy a peer-to-peer hálózatra nagyobb teher nehezedne. Az aggregáció új rétegeinek bevezetése elég összetett programozási feladat és késleltetést okoz (mivel hosszabb időbe telik, mire a blokkot ellenőrző minden alhálózati aggregátortól kap valamit). Az sem egyértelmű, hogyan lehetne kezelni azt, hogy több aktív validátor van a hálózaton, mint amit egy slotban fel lehet dolgozni, még akár BLS aláírásaggregációval is. Mivel minden slotban minden validátor tanúsít és nincsenek bizottságok az SSF koncepcióban, egy lehetséges megoldás lehet az is, hogy az effektív egyenleg maximális 32 ETH határát teljesen eltörölnék, így a több validátort működtetők konszolidálhatnák a letétjeiket és kevesebb validátort futtathatnának, ezzel csökkentve az üzenetek számát, amelyet a validátor-csomópontoknak kell feldolgozniuk a teljes validátorkészletet illetően. A nagyletéteseken múlik, hogy konszolidálják a validátoraikat. Az is lehetséges, hogy bármikor felső határt húznak a validátorok számát vagy a letétbe helyezett ETH összegét illetően. Ugyanakkor ehhez szükséges egy olyan mechanizmus, amely eldönti, hogy melyik validátor vehet részt és amelyik nem, ez pedig nem kívánt másodlagos hatásokat okozhat. - -## Jelenlegi helyzet {#current-progress} - -Az SSF még kutatási fázisban van. Nem várható, hogy a következő években bevezetésre kerül, csak miután más lényeges fejlesztések elérhetővé váltak, mint a [Verkle-fák](/roadmap/verkle-trees/) és a [Danksharding](/roadmap/danksharding/). - -## További olvasnivaló {#further-reading} - -- [Vitalik az SSF-ről az EDCON rendezvényen (2022)](https://www.youtube.com/watch?v=nPgUKNPWXNI) -- [Vitalik jegyzetei: az egy sloton belüli véglegességhez vezető út](https://notes.ethereum.org/@vbuterin/single_slot_finality) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/statelessness/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/statelessness/index.md deleted file mode 100644 index 3949b9a5d33..00000000000 --- a/public/content/translations/hu/12) Roadmap 2/roadmap/statelessness/index.md +++ /dev/null @@ -1,103 +0,0 @@ ---- -title: Státuszmentesség, a státusz és az előzményadatok lejárata -description: Az előzményadatok lejáratának és a státuszmentes Ethereumnak a magyarázata -lang: hu ---- - -# Státuszmentesség, a státusz és az előzményadatok lejárata {#statelessness} - -A valódi decentralizácóhoz szükség van arra, hogy az Ethereum-csomópontokat egyszerű hardveren lehessen futtatni. A csomópontok futtatása lehetővé teszi a felhasználónak, hogy független kriptográfiai validálással ellenőrizzék az információkat, és ne kelljen megbízniuk egy harmadik félben, hogy az adatokkal lássa el őket. A csomópont futtatásával a felhasználó közvetlenül küldhet tranzakciót az Ethereum peer-to-peer hálózatára, és nem kell megbíznia egy közvetítőben. A decentralizáció nem lehetséges, ha ezek az előnyök csak a drága hardverrel rendelkező felhasználók számára elérhetők. Ehelyett a csomópontokat rendkívül szerény teljesítményű és memóriaigényű készülékeken is lehessen működtetni, mint amilyenek a mobiltelefonok, a mikroszámítógépek vagy az otthoni számítógépek. - -Jelenleg a nagy tárhelyigény jelenti a legnagyobb akadályt ahhoz, hogy a csomópontokat bárki működtethesse globálisan. Ennek az a fő oka, hogy az Ethereum státuszadatainak nagy halmazait kell eltárolni. Ezek a státuszadatok kritikus információkat tartalmaznak az új blokkok és tranzakciók megfelelő lefuttatásához. A jelen cikk írásának időpontjában egy gyors 2 TB SSD szükséges ahhoz, hogy egy teljes Ethereum csomópontot lehessen futtatni. Ez egy olyan csomópont tárhelyigénye, amely nem törli ki a régebbi adatokat és nagyjából heti 14 GB-tal nő. Az archív csomópontok pedig, amelyek a genezis óta az összes adatot tartalmazzák, már 12 TB-t érnek el (ezen leírás időpontjában, 2023. februárjában). - -A régebbi adatokhoz lehet olcsóbb merevlemezeket használni, de ezek túl lassúak ahhoz, hogy a bejövő blokkokkal lépést tartsanak. Az csak egy átmeneti és részleges megoldás, hogy a kliensek jelenlegi tárolási modelljét megtartva olcsóbbá és könnyebbé tegyük az adattárolást, mivel az Ethereum státusznövekedése határtalan, tehát a tárhelyigény csak növekszik, a technológiai fejlesztéseknek pedig folyamatosan lépést kell tartaniuk ezzel. Ehelyett a klienseknek új módszert kell találni a blokkok és tranzakciók ellenőrzésére, amelyhez az adatokat nem szükséges a lokális adatbázisból kikeresni. - -## A csomópontokhoz szükséges tárhely csökkentése {#reducing-storage-for-nodes} - -Számos módon le lehet csökkenteni a csomópontban tárolt adatmennyiséget, ehhez azonban különféle mértékben, de módosítani kell az Ethereum-protokollon: - -- **Az előzményadatok lejárata**: lehetővé teszi, hogy a csomópont törölje azokat a státuszadatokat, amelyek X blokknál régebbiek, de nem változtatja meg a Ethereum-kliens státuszkezelési módját -- **A státusz lejárata**: lehetővé teszi, hogy inaktívvá válhassanak azok a státuszadatok, amelyeket nem használnak rendszeresen. Az inaktív adatokkal nem kell foglalkoznia a kliensnek mindaddig, amíg az újból be nem hívják őket. -- **Gyenge státusztalanság**: csak a blokk-készítőknek van szükségük a teljes státuszadatra, a többi csomópont a lokális státuszadatbázis nélkül is képes ellenőrizni a blokkokat. -- **Erős státusztalanság**: semelyik csomópontnak nincs szüksége az összes státuszadatra. - -## Az adatok lejárata {#data-expiry} - -### Az előzményadatok lejárata {#history-expiry} - -Az előzményadatok lejárata azt jelenti, hogy a kliensek törlik a régebbi adatokat, amelyekre már valószínűleg nem lesz szükség, így csak kevés előzményadatot tárolnak, és az új adatok felülírják a legrégebbieket. A klienseknek két okból van szükségük előzményadatokra: szinkronizáláshoz és adatlekérdezések teljesítéséhez. Eredetileg a klienseknek a genezisblokkból kellett szinkronizálniuk, ellenőrizve, hogy minden egyes soron következő blokk megfelelő-e egészen a lánc elejéig. Jelenleg a kliensek ezt az utat a lánc elejéig a „gyenge szubjektivitású ellenőrzési pontoktól” kiindulva teszik meg. Ezek az ellenőrzési pontok megbízható kiindulási pontok, vagyis olyan, mintha a genezisblokk közelebb lenne a jelenhez, nem az Ethereum kezdetétől nézné. Tehát a kliensek törölhetnek minden olyan információt, amely a legutóbbi gyenge szubjektivitású ellenőrzési pontnál korábbi, így is képesek szinkronizálni a lánc elejével. A kliensek jelenleg úgy szolgáltatnak előzményadatokat (amelyek JSON-RPC-n keresztül érkeznek), hogy azokat a helyi adatbázisukból kérik le. Ez az előzményadatok lejáratával nem lesz lehetséges, mert az adat egy része nem lesz már elérhető. Az előzményadatok biztosítására egy innovatív megoldásra van szükség. - -Az egyik lehetőség az, hogy a kliensek az előzményadatokat a társaiktól kérik le olyan megoldással, mint amilyen a Portal Network. A Portal Network egy fejlesztés alatt álló peer-to-peer hálózat az előzményadatok biztosítására, ahol minden csomópont az Ethereum előzményadatának egy kis részét tárolja, így a teljes adathalmaz a hálózaton elosztva létezik. Ezek megszerzése úgy működik, hogy megkeresik azokat a peereket, akik tárolja az adott adatokat és lekérik tőlük ezeket. Másik megoldás lehet, hogy mivel általában az alkalmazásoknak van szüksége előzményadatokra, ezért az ő felelősségük lenne ezek tárolása. Talán lenne elég önfeláldozó szereplő az Ethereum világában, akik önkéntesen tárolnának előzményarchívumokat. Lehetne egy decentralizált autonóm szervezet (DAO), ami felvállalja az adattárolást, vagy ideális esetben lehetne ezen opciók kombinációja is. Ezek a szolgáltatók számos módon szolgálhatnának adattal, például torrent, FTP, Filecoin vagy IPFS formájában. - -Az előzményadatok lejárata egy kicsit ellentmondásos téma, mert eddig az Ethereum mindig nyilvánosan vállalta bármilyen adat elérhetőségét. Mindig alapból elérhető volt egy teljes szinkronizáció a genezistől kezdve, még akkor is, ha az újraépítéshez a régi adatok pillanatfelvételét kellett használni. Az előzményadatok lejárata ezt a felelősséget az Ethereum-protokollon kívülre helyezi. Ez akár új cenzúrakockázatot is hordozhat magában, ha végül centralizált szerzetek biztosítják az előzményadatokat. - -Az EIP-4444 még nem áll készen, de aktív egyeztetés folyik róla. Érdekes módon, az EIP-4444-gyel kapcsolatos kihívások jellemzően nem technikaiak, hanem inkább a közösségi kezelésből erednek. A közösségnek bele kell egyeznie az új módszerbe, el kell fogadnia, hogy az előzményadatokat megbízható entitások szolgáltassák. - -Ez a fejlesztés nem változtatja meg alapjaiban az Ethereum-csomópontok státuszadat-kezelését, csak azok elérésére lesz hatással. - -### A státusz lejárata {#state-expiry} - -A státusz lejárata azt jelenti, hogy az egyéni csomópontokból eltávolítják a státuszt, ha azt az utóbbi időben nem használták. Ezt többféle módon is meg lehet valósítani, például: - -- **Lejárat a bérleti díj alapján**: kapcsoljunk a számlákhoz „bérleti díjat”, és amikor ez nullázódik, akkor a számla is lejár -- **Lejárat idő alapján**: a számlák inaktíválódnak, ha egy ideig nem végeznek olvasási/írási műveletet rajtuk - -A bérleti díj alapján vett lejárat lehet egy közvetlen díjkérés a számláktól, hogy azok maradjanak aktív állapotban az adatbázisban. Az idő alapján vett lejárat lehet az utolsó interakció óta eltelt idő, illetve az összes számla periodikus lejárata. Lehetnek olyan mechanizmusok is, amelyek ötvözik az idő- és a bérletidíj-alapú modelleket, például az egyéni számlák aktív státuszban maradnak, ha fizetnek egy kis összeget az időalapú lejárat előtt. Ezzel kapcsolatban fontos megérteni, hogy az inaktív állapot nem jelent **törlést**, csak elkülönítve tárolják a kapcsolódó adatokat az aktív státusztól. Az inaktív státuszt vissza lehet állítani élő állapotra. - -Ez úgy valósulhat meg, hogy például egy státuszfa áll rendelkezésekre bizonyos időperiódusokra (talán 1 évre). Amikor az új periódus elkezdődik, egy teljesen új státuszfa jön létre. Csak a jelenlegi státuszfát lehet módosítani, a többi megváltoztathatatlan. Az Ethereum-csomópontoknak csak a jelenlegi és a legutóbbi státuszfát kellene tárolniuk. Ehhez időbélyeget kell tenni a címekre, hogy melyik periódusban léteznek. [Számos módja van annak](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607), hogy ezt bevezessék, de a legjobb megoldáshoz a [címeket meg kell hosszabbítani](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485), hogy elférjen az új információ, illetve a hosszabb címek biztonságosabbak is. Az ütemtervben ezt a fejlesztés a [címhely kiterjesztése](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485) címen szerepel. - -Az előzményadatok lejáratához hasonlóan a státuszlejáratnál is az egyéni felhasználók helyett tárolhatják a régi státuszadatokat más entitások, mint központi szolgáltatók, önfeláldozó közösségi tagok vagy olyan jövőbeli, decentralizált megoldások, mint amilyen a Portal Network. - -A státusz lejárata még kutatási fázisban van, a fejlesztés nem áll készen a bevezetésre. A státuszlejárat talán a státuszmentes kliensek és az előzményadatok lejárata után kerül bevezetésre, mert ezek a fejlesztések a legtöbb validátor számára már kezelhetővé teszik a nagy státuszokat. - -## Hontalanság {#statelessness} - -A státusztalanság nem azt jelenti, hogy a státusz megszűnik, hanem megváltozik az Ethereum-csomópontok státuszkezelési módja. A státusztalanság kétféle jelleget ölthet: gyenge és erős státusztalanság. A gyenge státusztalanság a legtöbb csomópont számára megengedi, hogy státusz nélkül állapotban fussanak, mivel csak néhánynak lesz a feladata a tárolás. Az erős státusztalanság megszűnteti azt, hogy bármelyik csomópontnak tárolnia kelljen az összes státuszadatot. Mindkét fajta a következő előnyökkel jár az átlagos validátorok számára: - -- szinte azonnali szinkronizálás -- képesek a blokkokat soron kívül is validálni -- a csomópontokat egyszerű hardverrel is lehet futtatni (pl. telefonnal) -- a csomópontokhoz olcsó merevlemezt is lehet használni, mert nincs szükség írásra/olvasásra -- kompatibilis az Ethereum elkövetkező kriptográfiai fejlesztéseivel - -### Gyenge státusztalanság {#weak-statelessness} - -A gyenge státusztalanság megváltoztatja azt, ahogy az Ethereum-csomópontok ellenőrzik a státuszváltozásokat, de teljesen nem szüntetik meg azt, hogy a hálózaton néhány csomópontnak ne kelljen státuszt tárolni. Ehelyett a státusz tárolásának felelősségét a blokkelőterjesztőknek adja, a hálózat többi csomópontja, amely a blokkokat ellenőrzi, működhet a teljes státuszadat nélkül. - -**Gyenge státusztalanság esetén a blokkelőterjesztőknek szükségük van a teljes státuszadatra, de az ellenőrzőknek nincs** - -Ehhez előbb [Verkle-fákat](/roadmap/verkle-trees/) kell bevezetni az Ethereum-klienseknél. A Verkle-fák adatstruktúrák az Ethereum státuszainak tárolására, amelyek kicsi, fix méretű „tanúkat” készítenek, amelyet meg lehet osztani a társakkal, és a blokkokat ezekhez lehet validálni a lokális adatbázisok helyett. Egy [ javaslattevő-építő szétválasztás (PBS)](/roadmap/pbs/) is szükséges, mert így a blokképítőknek specializált csomópontjaik lehetnek sokkal erőteljesebb hardverrel, és csak nekik kell hozzáférni a teljes státuszadathoz. - - - -A státusztalanság arra épül, hogy a blokképítők tárolják a teljes státuszadatot, így képesek olyan tanúkat készíteni, amit a blokk validálásához használnak. A többi csomópontnak nincs szüksége a státuszadatokra, minden szükséges információ benne van a tanúban. Ez egy olyan helyzet, amelyben a blokképítés drága, viszont a blokkellenőrzés olcsó tevékenység, így kevesebben fognak blokképítő csomópontokat működtetni. Ugyanakkor a blokképítők decentralizációja nem annyira kritikus téma, hogyha a lehető legtöbb résztvevő képes függetlenül részt venni a blokkok ellenőrzésében. - -Tudjon meg többet a témáról Dankrad jegyzeteiből - - -A blokképítők használják a státuszadatot a tanúk létrehozásához – ez egy minimális adathalmaz, mellyel ellenőrizhető a blokkban lévő tranzakciók által okozott státuszváltozás. A többi validátornak nincs szüksége a státuszra, csak a státuszgyökeret (a teljes státusz hashje) tárolják. Megkapják a blokkot és a tanút, és ezeket felhasználva frissítik a saját státuszgyökerüket. Ezáltal a validáló csomópont rendkívül könnyű lesz. - -A gyenge státusztalanság a kutatás előrehaladott állapotában tart, de a bevezetése a javaslattevő-építő szétválasztáson (PBS) és a Verkle-fák bevezetésén múlik, hogy a kis méretű tanúkat el lehessen küldeni a társaknak. Ez alapján a bevezetése talán néhány év múlva történhet meg az Ethereum főhálózatán. - -### Erős státusztalanság {#strong-statelessness} - -Az erős státusztalanság megszünteti azt, hogy bármelyik csomópontnak tárolnia kelljen a státuszadatot. Ehelyett a tranzakciókat a tanúkkal együtt küldik, amelyet a blokképítők aggregálnak. Így a blokképítők felelősek azért, hogy a szükséges státuszokat tárolják, hogy abból elkészítsék a tanúkat a releváns számlákra. A státuszhoz kapcsolódó felelősség szinte teljesen a felhasználókhoz kerül, mivel tanúkat és hozzáférési listákat küldenek arról, hogy milyen számlákkal és tárhelykulcsokkal kapcsolódnak. Ennek következtében rendkívül könnyű csomópontok működhetnek, viszont az okosszerződésekkel nehezebb lesz az interakciójuk. - -Az erős státusztalanságot vizsgálják a kutatók, de jelenleg nem valószínű, hogy része lesz az Ethereum ütemtervének – sokkal valószínűbb, hogy a gyenge státusztalanság elegendő az Ethereum skálázási igényekhez. - -## Jelenlegi helyzet {#current-progress} - -A gyenge státusztalanság, az előzményadatok és a státuszadatok lejárata még kutatási fázisban van, és talán évek múlva kerül bevezetésre. Az sem biztos, hogy a javaslatokból mindegyiket be kell vezetni, mert kiderülhet például, hogy a státusz lejárati ideje után már nincs szükség az előzményadat-lejáratot is megvalósítani. Előbb az ütemterv más elemeiknek kell megvalósulniuk, mint például a [Verkle-fák](/roadmap/verkle-trees) és a [javaslattevő-építő szétválasztás (PBS)](/roadmap/pbs). - -## További olvasnivaló {#further-reading} - -- [Vitalik a státusztalanságról (AMA)](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) -- [A státuszméret menedzsmentjének elmélete](https://hackmd.io/@vbuterin/state_size_management) -- [Státusz összekapcsolása az élesedés okozta konfliktus minimalizálására](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) -- [A státusztalansághoz és a státuszlejárathoz vezető út](https://hackmd.io/@vbuterin/state_expiry_paths) -- [Az EIP-4444 specifikációi](https://eips.ethereum.org/EIPS/eip-4444) -- [Alex Stokes az EIP-4444 fejlesztéséről](https://youtu.be/SfDC_qUZaos) -- [Miért olyan fontos a státusztalanság](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) -- [Ez eredeti státusztalan kliens koncepciójának leírása](https://ethresear.ch/t/the-stateless-client-concept/172) -- [Bővebben a státuszlejáratról](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) -- [Még több tudnivaló a státuszlejáratról](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) diff --git a/public/content/translations/hu/12) Roadmap 2/roadmap/verkle-trees/index.md b/public/content/translations/hu/12) Roadmap 2/roadmap/verkle-trees/index.md deleted file mode 100644 index 2f608b229e9..00000000000 --- a/public/content/translations/hu/12) Roadmap 2/roadmap/verkle-trees/index.md +++ /dev/null @@ -1,66 +0,0 @@ ---- -title: Verkle-fák -description: A Verkle-fák részletes bemutatása, illetve annak leírás, hogy miként használják ezeket az Ethereum fejlesztésére -lang: hu -summaryPoints: - - Fedezze fel, hogy mire valók a Verkle-fák - - Tekintse meg, hogy a Verkle-fák hogyan járulnak hozzá az Ethereum fejlődéséhez ---- - -# Verkle-fák {#verkle-trees} - -A Verkle-fák (a vektor elköteleződés és a „Merkel-fák” összevonásából) olyan adatstruktúrát alkotnak, amely az Ethereum-csomópontokat fejleszti, hogy ne kelljen nagy mennyiségű státuszadat tárolniuk, de mégis validálni tudják a blokkokat. - -## Hontalanság {#statelessness} - -A Verkle-fák kritikus lépést jelentenek a státusztalan Ethereum-kliensekhez vezető úton. A státusztalan kliensek úgy tudják validálni a bejövő blokkokat, hogy ahhoz nem kell tárolniuk a teljes státuszadatbázist. Ahelyett, hogy az Ethereum státuszának saját lokális másolatát használnák, a státusztalan kliensek egy „tanút” használnak a státuszadatokhoz, amely a blokkal együtt érkezik. A tanú a státuszadat egyéni darabjainak halmaza, amely ahhoz szükséges, hogy a tranzakciók egy adott kötegét le lehessen futtatni, illetve egy kriptográfiai bizonyíték arra, hogy a tanú valóban a teljes adat része. Ezt a tanút használják a státuszadatbázis _helyett_. Ehhez arra van szükség, hogy a tanúk nagyon kis méretűek legyenek, így biztosan időben el lehet juttatni őket a hálózaton keresztül a validátorokhoz, hogy azt egy 12 másodperces slotban feldolgozzák. A jelenlegi státuszadatstruktúra nem megfelelő, mert a tanúk túl nagy méretűek. A Verkle-fák megoldják ezt a problémát, mert kis méretű tanúkat tudnak készíteni, így a státusztalan kliensek egyik fő akadályát ki tudják küszöbölni. - - - -Az Ethereum-kliensek jelenleg a Patricia Merkle Trie-adatstruktúrát használják a státuszadatok tárolására. Az egyéni számlákra vonatkozó információk a fa és a digitális fa leveleiként tárolódnak, ahol a levélpárokat addig hashelik, amíg már csak egyetlen hash marad. Ezt a végső hasht hívják gyökérnek. A blokkellenőrzéshez az Ethereum-kliensek végrehajtják az összes tranzakciót a blokkban és frissítik a lokális státuszfájukat. A blokkot akkor tekintik érvényesnek, amikor a lokális fa gyökere azonos lesz azzal, amit a blokkelőterjesztő adott, mivel ha bármilyen különbség lenne az előterjesztő és a validáló csomópont számolása között, akkor a gyökérhash teljesen eltérne. Ezzel az a gond, hogy a blokklánc validálásához minden kliensnek tárolnia kell a vezetőblokk és számos előzményblokk teljes státuszfáját (a Geth-ben alapvető, hogy a vezetőblokk utáni 128 blokkra megtartják a státuszadatokat). Ehhez a klienseknek nagy tárhelyre van szükségük, ami megakadályozza, hogy teljes csomópontokat lehessen olcsón és kisebb kapacitású hardverrel üzemeltetni. Ezt úgy lehet megoldani, hogy a státuszfát egy hatékonyabb struktúrára (Verkle-fa) cserélik, ami képes kis méretű tanúkkal összefoglalni az adatokat, amit a teljes státuszadat helyett meg lehet osztani a validátorokkal. A státuszadat átformázása a Verkle-fa struktúrájába egy mérföldkő a státuszmentes kliensek bevezetéséhez. - - - -## Mi az a tanú és miért van rá szükség? {#what-is-a-witness} - -A blokk ellenőrzése azt jelenti, hogy a benne lévő tranzakciókat újra végrehajtják, megváltoztatják az Ethereum státuszfát, és kiszámolják az új gyökérhasht. Az érvényes blokk az lesz, amelynek a kiszámolt státuszgyökér-hashe ugyanazt, mint amit a blokkal együtt adtak (mert ekkor a blokkot javasló valóban végrehajtotta a számításokat úgy, ahogy mondja). A jelenlegi Ethereum-kliensekben a státusz frissítéséhez hozzá kell férni a teljes státuszfához, ami egy nagyméretű adatstruktúra, és lokálisan kell azt tárolni. A tanú a státuszadatnak csak töredékeit tartalmazza, ami a blokkban lévő tranzakciók lefuttatásához szükségesek. A validátornak tehát csak ezeket a töredékeket kell használnia arra, hogy leellenőrizze, a javaslattevő végrehajtotta-e a blokk tranzakcióit és megfelelő módon frissítette-e a státuszt. Ugyanakkor ez azt is jelenti, hogy a tanút az Ethereum hálózatán olyan gyorsan kell eljuttatni a peereknek, hogy azt biztosan megkapja és feldolgozza minden egyes csomópont a 12 másodperces slotban. Ha a tanú túl nagy méretű, akkor néhány csomópont számára sokáig tart a letöltése, így nehéz lépést tartani a lánccal. Ez egy centralizáló erő, mert csak gyors internetkapcsolattal bíró csomópontok vehetnek részt a blokkvalidálásban. A Verkle-fák révén nem kell a státuszt a merevlemezen tárolni; a blokk validálásához _mindent_ maga a blokk tartalmaz. Sajnos a Merkle-fákból előállítható tanúk túl nagy méretűek ahhoz, hogy lehetővé tegyék a státusztalan klienseket. - -## Hogyan állítható elő a Verkle-fákkal kisebb méretű tanúk? {#why-do-verkle-trees-enable-smaller-witnesses} - -A Merkle-fa struktúrája nagy méretű tanúkat ad – ezeket nem lehet biztonsággal szétküldeni a peerek között a 12 másodperces slotban. Ennek az az oka, hogy a tanú egy olyan útvonal, amely összeköti az adatokat (amelyeket a levelek tartalmaznak) a gyökérhash-sel. Az adatok ellenőrzéséhez nem elég az összes köztes hash, ami összeköti a leveleket és a gyökeret, hanem szükség van testvérpontokra is. A bizonyítékban minden csomópontnak van egy testvére, amivel hashelődik, hogy létrehozza a fa következő hashét. Ez rengeteg adat. A Verkle-fák úgy csökkentik a tanú méretét, hogy megrövidítik a falevelek és a gyökér közötti távolságot, és nem kell a testvérpontokat is megadni ahhoz, hogy a gyökér-hash validálható legyen. Még ennél is több hely nyerhető azzal, hogy egy erőteljes polinomiális elköteleződési sémát használnak a hash-stílusú vektorelköteleződés helyett. A polinomiális elköteleződés lehetővé teszi, hogy a tanú adott méretű legyen, függetlenül az általa bizonyított levelek számától. - -A polinomiális elköteleződési séma alapján a tanú kezelhető méretű lesz, és könnyedén átadható a peer-to-peer hálózaton keresztül. Ez alapján a kliensek minimális adatmennyiséggel képesek minden blokkban ellenőrizni a státuszváltozást. - - - -A tanú mérete a benne lévő levelek száma alapján változik. Feltéve, hogy a tanú 1000 levelet fed le, akkor a Merkle-fához tartozó tanú 3,5 MB lenne (egy 7 szintű fa esetében). Ugyanezen adatok esetében a Verkle-fa tanúja (4 szintű fát feltételezve) 150 kB – **ez nagyjából 23-szor kisebb**. A tanú ilyen szintű méretcsökkenése megengedi, hogy a státusztalan kliensek tanúi elfogadhatóan kicsik maradjanak. A polinomiális tanúk 0,128–1 kB méretűek, attól függően, hogy amelyik polinomiális elköteleződést használják. - - - -## Mi a Verkle-fák struktúrája? {#what-is-the-structure-of-a-verkle-tree} - -A Verkle-fák `key, value` (kulcs, érték) párokból állnak, ahol a kulcsok 32 bájtos elemek, amelyek egy 31 bájtos _tőből_ és egy egyetlen bájtos _toldalékból_ tevődnek össze. Ezek a kulcsok _kiterjesztő_ pontokba és _belső_ pontokba rendeződnek. A kiterjesztőpontok egyetlen tövet képviselnek 256 gyermek számára különböző toldalékokkal. A belső pontoknak is 256 gyermekük van, de ezek lehetnek más kiterjesztőpontok is. A Verkle- és a Merkle-fastruktúra közötti fő különbség az, hogy a Verkle-fa sokkal laposabb, kevesebb köztes pont kapcsolja a levelet a gyökérhez, ezért kevesebb adat kell a bizonyíték legyártásához. - -![](./verkle.png) - -[Tudjon meg többet a Verkle-fák struktúrájáról](https://blog.ethereum.org/2021/12/02/verkle-tree-structure) - -## Jelenlegi helyzet {#current-progress} - -A Verkle-fa teszthálózatai már működnek, de jelentős mértékű kliensfrissítésre van még szükség ahhoz, hogy támogatni tudják ezt az adatstruktúrát. Ön is segíthet a fejlesztés meggyorsításában, ha szerződéseket hoz létre a teszthálózaton és klienseket működtet a teszthez. - -[Fedezze fel a Verkle Gen Devnet 6 teszthálózatot](https://verkle-gen-devnet-6.ethpandaops.io/) - -[Nézze meg, ahogy Guillaume Ballet bemutatja a Condrieu Verkle-teszthálózatot](https://www.youtube.com/watch?v=cPLHFBeC0Vg) (a Condrieu teszthálózat még a proof-of-work mechanizmus szerint működött, és mára már Verkle Gen Devnet 6 teszthálózat váltotta fel). - -## További olvasnivaló {#further-reading} - -- [Verkle-fák a státusztalanság megvalósításához](https://verkle.info/) -- [Dankrad Feist magyarázata a Verkle-fákról a PEEPanEIP csatornán](https://www.youtube.com/watch?v=RGJOQHzg3UQ) -- [Guillaume Ballet magyarázata a Verkle-fákról az ETHGlobal rendezvényen](https://www.youtube.com/watch?v=f7bEtX3Z57o) -- [„Hogyan segítenek a Verkle-fák abban, hogy az Ethereum áttekinthető és egyszerű legyen?” – Guillaume Ballet előadása a Devcon 6 rendezvényen](https://www.youtube.com/watch?v=Q7rStTKwuYs) -- [Piper Merriam előadása a státusztalan kliensekről az ETHDenver 2020-as rendezvényén](https://www.youtube.com/watch?v=0yiZJNciIJ4) -- [Dankrad Fiest Verkle-fákról és státuszmentességről szóló podcastja a Zero Knowledge csatornán](https://zeroknowledge.fm/episode-202-stateless-ethereum-verkle-tries-with-dankrad-feist/) -- [Vitalik Buterin magyarázata a Verkle-fákról](https://vitalik.eth.limo/general/2021/06/18/verkle.html) -- [Dankrad Feist magyarázata a Verkle-fákról](https://dankradfeist.de/ethereum/2021/06/18/verkle-trie-for-eth1.html) -- [A Verkle-fák EIP-dokumentációja](https://notes.ethereum.org/@vbuterin/verkle_tree_eip#Illustration) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/accounts/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/accounts/index.md deleted file mode 100644 index a0a01058a0c..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/accounts/index.md +++ /dev/null @@ -1,136 +0,0 @@ ---- -title: Ethereum számlák -description: Az Ethereum számlák magyarázata – az adatstruktúrájuk és a kapcsolatuk a kulcspár kriptográfiával. -lang: hu ---- - -Egy Ethereum számla egy olyan entitás, mely ether (ETH) egyenleggel rendelkezik és tranzakciókat tud indítani az Ethereumon. A számlák lehetnek felhasználók által irányítottak, vagy okos szerződésként telepítettek. - -## Előfeltételek {#prerequisites} - -Ennek az oldalnak a jobb megértése érdekében javasoljuk, hogy először olvassa el a [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) oldalunkat. - -## Számlatípusok {#types-of-account} - -Az Ethereum két számlatípust kínál: - -- Externally owned account (EOA) – bárki irányíthatja a privát kulcsokkal -- Szerződéses számla – egy okosszerződés, amelyet a hálózatra telepítettek és kód irányítja. Tudjon meg többet az [okosszerződésekről](/developers/docs/smart-contracts/) - -Mindkét számlatípus képes: - -- ETH és más tokenek fogadása, tartása és küldése -- Interakcióba lépni a telepített okosszerződésekkel - -### Legfontosabb különbségek {#key-differences} - -**Külső tulajdonú** - -- Egy számla létrehozása nem kerül semmibe -- Tranzakciókat indíthatsz -- A külső tulajdonú számlák közötti tranzakciók csak ETH/token átutalások lehetnek -- Egy kriptográfiai kulcspárból állnak: a nyilvános és a privát kulcs kontrollálja a számlával kapcsolatos ügyleteket - -**Szerződés** - -- Egy számla létrehozása költséggel jár, mivel a hálózati tárhelyet használja -- Csak úgy küldhet tranzakciókat ha az egy válasz egy bejövő tranzakcióra -- A külső tulajdonú számláról szerződéses számlára küldött tranzakciók egy programkódot indítanak, amely sokféle parancsot tud végrehajtani, mint például token átutalása vagy akár új szerződés létrehozása -- A szerződéses számláknak nincs privát kulcsuk. Ehelyett az okosszerződés logikája kontrollálja azokat - -## Egy számla közelebbről {#an-account-examined} - -Az Ethereum számláknak négy mezőjük van: - -- `nonce` – Egy számláló, amely az elküldött tranzakciók számát (külső tulajdonú számla) vagy a létrehozott szerződések számát (szerződéses számla) mutatja. Egy adott nonce segítségével csak egy tranzakció hajtható végre az adott számlára, így nem lehet újrajátszani a tranzakciót, így védve van az ilyen jellegű támadásoktól. -- `balance` – A cím által birtokolt Wei-k száma. A Wei az ETH denominált egysége és 1e+18 Wei van egy ETH-ben. -- `codeHash` – Ez a hash egy számla _kódjára_ hivatkozik az Ethereum Virtuális Gépen (EVM). A szerződéses számlák olyan kódrészleteket tartalmaznak, amelyek különféle műveleteket tudnak végrehajtani. Ez az EVM-kód kerül végrehajtásra, ha a számla egy üzenethívást kap. A többi számlamezővel ellentétben ezt nem lehet megváltoztatni. Az összes ilyen kódrészletet az státuszadatbázis tartalmazza a megfelelő hashek alatt későbbi visszakeresés céljából. Ezt a hash-értéket nevezik codeHash-nek. Külső tulajdonú számláknál a codeHash mező egy üres sztring hash-e. -- `storageRoot` – Néha úgy is hivatkoznak rá, mint tárhely-hash. Egy Merkle Patricia trie gyökér csomópontjához tartozó 256 bites hash, amely a számla tárhelyének tartalmát kódolja (256 bites integer értékek közötti leképzés), a fába kódolva, mint egy 256 bites integer kulcsok 256 bites Keccak hash-e és az RLP kódolású 256 bites integer értékek közötti leképzés. Ez a fa a számla tárolótartalmának hash-ét kódolja, és alapértelmezés szerint üres. - -![Egy diagram mely egy számla felépítését mutatja be](./accounts.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból - -## Külső tulajdonú számlák és kulcspárok {#externally-owned-accounts-and-key-pairs} - -Egy számla egy kriptográfiai kulcspárból áll: egy publikusból és egy privátból. Segítenek bizonyítani, hogy a tranzakciót valóban a küldő írta alá és megelőzik a hamisítást. A privát kulcs az, amellyel aláírja a tranzakciókat, így felügyeletet biztosít a számlához tartozó pénz felett. Valójában sosem birtokolsz kriptovalutát, privát kulcsokat birtokolsz - a tőke mindvégig az Ethereum főkönyvében van. - -Ez biztosítja azt, hogy rosszindulatú szereplők ne indíthassanak hamis tranzakciókat, mivel mindig azonosítani tudod a tranzakció küldőjének kilétét. - -Ha Alice ethert szeretne küldeni a számlájáról Bob számlájára, akkor Alice-nek egy tranzakció kérelmet kell készítenie és elküldeni a hálózatra hitelesítésre. Az Ethereum publikus kulcs kriptográfiája biztosítja, hogy Alice be tudja bizonyítani, hogy ő volt aki elindította a tranzakciós kérelmet. Kriptográfiai mechanizmusok nélkül egy kártékony ellenség, Eve, egyszerűen elküldhetne egy kérelmet, mely úgy néz ki, mint „küldj 5 ETH-t Alice számlájáról Eve számlájára” és senki sem tudná bebizonyítani, hogy ez nem Alice-től származik. - -## Számla létrehozása {#account-creation} - -Amikor szeretne létrehozni egy számlát, akkor a legtöbb könyvtár generál egy véletlenszerű privát kulcsot. - -Egy privát kulcs 64 hexadecimális karakterből áll, és jelszóval lehet titkosítani. - -Példa: - -`fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd036415f` - -A nyilvános kulcsot a privát kulcsból generálják az [Elliptic Curve Digital Signature Algorithm](https://wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) segítségével. A számla publikus címét úgy lehet megkapni, ha elvesszük a legutolsó 20 bájtot a Keccak-256 hash nyilvános kulcsából és hozzáadunk egy `0x` előtagot az elejére. - -Ez azt jelenti, hogy egy külső tulajdonú számla (EOA) 42 karakter hosszú címmel bír (20 bájtnyi szegmens, ami 40 hexadecimális karakter, plusz a `0x` előtag). - -Példa: - -`0x5e97870f263700f46aa00d967821199b9bc5a120` - -A következő példa megmutatja, hogyan lehet a [Clef](https://geth.ethereum.org/docs/tools/clef/introduction) nevű aláíró eszközzel egy új számlát létrehozni. A Clef egy számlakezelő és -aláíró eszköz, amely az Ethereum klienssel, a [Geth-szel](https://geth.ethereum.org) van egybecsomagolva. A `clef newaccount` parancs egy új kulcspárt hoz létre, és egy titkosított kulcstárolóba menti el. - -``` -> clef newaccount --keystore - -Please enter a password for the new account to be created: -> - ------------- -INFO [10-28|16:19:09.156] Your new key was generated address=0x5e97870f263700f46aa00d967821199b9bc5a120 -WARN [10-28|16:19:09.306] Please backup your key file path=/home/user/go-ethereum/data/keystore/UTC--2022-10-28T15-19-08.000825927Z--5e97870f263700f46aa00d967821199b9bc5a120 -WARN [10-28|16:19:09.306] Please remember your password! -Generated account 0x5e97870f263700f46aa00d967821199b9bc5a120 -``` - -[Geth-dokumentáció](https://geth.ethereum.org/docs) - -Lehetséges új publikus kulcsokat származtatni a privát kulcsodból, de nem tudsz publikus kulcsokból privát kulcsot származtatni. Létfontosságú a privát kulcs biztonságban tartása, mert ahogy a neve is sugallja, ez **PRIVÁT**. - -Egy privát kulcsra van szükséged, hogy üzeneteket és tranzakciókat tudj aláírni, mely egy aláírást hoz létre. Ezáltal mások az aláírásodból leszármaztathatják a publikus kulcsodat, amely az üzenet feladójának kilétét bizonyítja. Az alkalmazásában használhat javascript könyvtárat, hogy tranzakciókat küldjön a hálózatra. - -## Szerződéses számlák {#contract-accounts} - -A szerződéses számláknak szintén egy 42 karakterből álló hexadecimális címük van: - -Példa: - -`0x06012c8cf97bead5deae237070f9587f8e7a266d` - -Ez a szerződés cím általában akkor jön létre, amikor egy szerződést feltelepítenek az Ethereum blokkláncra. A cím a készítő címéből és az erről a címről küldött tranzakciók számából („nonce”) származik. - -## Validátorkulcsok {#validators-keys} - -Az Ethereumon létezik egy másik típusú kulcs is, amelyet a proof-of-work-alapú konszenzusról a proof-of-stake-alapúra való átálláskor vezettek be. Ezek a BLS kulcsok, amelyek a validátorokat azonosítják. Hatékonyan aggregálhatók, hogy a hálózatnak kevesebb sávszélességre legyen szüksége a konszenzus elérésekor. Ezen kulcsaggregáció nélkül a validátor minimális letétének sokkal nagyobbnak kellene lennie. - -[Bővebben a validátorkulcsokról](/developers/docs/consensus-mechanisms/pos/keys/). - -## Megjegyzés a tárcákkal kapcsolatban {#a-note-on-wallets} - -A számla nem egyenlő a tárcával. A tárca egy olyan interfész vagy alkalmazás, amely lehetővé teszi az Ethereum-számlával való interakciót, legyen az külső tulajdonú számla vagy szerződéses számla. - -## Egy vizuális bemutató {#a-visual-demo} - -Nézze meg, ahogy Austin elmagyarázza a hash funkciót és a kulcspárokat. - - - - - -## További olvasnivaló {#further-reading} - -- [Az Ethereum-számlák megértése](https://info.etherscan.com/understanding-ethereum-accounts/) - etherscan - -_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Okosszerződések](/developers/docs/smart-contracts/) -- [Tranzakciók](/developers/docs/transactions/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/blocks/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/blocks/index.md deleted file mode 100644 index d877e79182f..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/blocks/index.md +++ /dev/null @@ -1,152 +0,0 @@ ---- -title: Blokkok -description: Egy áttekintő a blokkokról az Ethereum blokkláncban - az adatstruktúrájukról, miért van rájuk szükség és hogyan készülnek. -lang: hu ---- - -A blokkok tranzakciókból álló csoportosítások a láncban lévő előző blokk hash-ével ellátva. Ez összeköti a blokkokat (egy lánccá), mivel a hasheket kriptográfiailag származtatjuk a blokk adatból. Ez megelőzi a csalásokat, mivel bármely blokkon történő változtatás érvénytelenítené az összes következő blokkot, mivel az összes többi hash megváltozna és bárki aki a blokkláncot futtatja észrevenné. - -## Előfeltételek {#prerequisites} - -A blokkok könnyen feldolgozhatók még a legkezdőbb felhasználóknak is. De ennek az oldalnak a jobb megértése érdekében javasoljuk, hogy először olvassa el a [Számlák](/developers/docs/accounts/), a [Tranzakciók](/developers/docs/transactions/) és a [Bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) című cikkeinket. - -## Miért kellenek a blokkok? {#why-blocks} - -Annak biztosítása érdekében, hogy az Ethereum-hálózat minden résztvevője egy szinkronizált állapotot tart fenn és megegyezik a pontos tranzakciós történetben, a tranzakciókat blokkokba rendezzük. Ez azt jelenti, hogy több tucatnyi (vagy több száz) tranzakció felett van elköteleződés, egyetértés és szinkronizáció egyszerre. - -![Diagram, amely egy státuszt módosító blokkban lévő tranzakciót mutat](./tx-block.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból - -Az elkötelezettségek elosztásával elegendő időt adunk az összes hálózati résztvevőnek arra, hogy konszenzusra tudjanak jutni: annak ellenére, hogy a tranzakciós kérelmek másodpercenként több tucatszor fordulnak elő, az Ethereum blokkjai tizenkét másodpercenként köteleződnek el. - -## Hogy működnek a blokkok {#how-blocks-work} - -Hogy megőrizzük a tranzakciós történetet, a blokkoknak szigorú sorrendet kell betartaniuk (minden létrejövő új blokk tartalmaz egy referenciát a szülő blokkjára), és a blokkokban lévő tranzakciók is szigorú sorrendet követnek. Ritka esetek kivételével bármikor amikor a hálózat összes résztvevője egyetért a blokkok pontos számában és előzményeiben, és azon dolgozik, hogy az aktuális élő tranzakciós kérelmeket a következő blokkba csomagolja. - -Amint egy blokkot egy véletlenszerűen választott validátor összeállít által a hálózaton, az továbbterjed a hálózat többi részére; az összes csomópont hozzáfűzi ezt a blokkot a blokkláncukra, majd egy új validátort választanak a következő blokk összeállításához. A pontos blokk-összeállítási folyamatot és az elköteleződés/konszenzus folyamatot jelenleg az Ethereum „proof-of-stake” protokollja specifikálja. - -## Proof-of-stake protokoll {#proof-of-work-protocol} - -A proof-of-stake a következőket jelenti: - -- A validációt végző csomópontoknak letétbe kell helyezniük 32 ETH-t egy letéti szerződésbe fedezetként, hogy elkerülhető legyen a rosszhiszemű viselkedés. Ez segít megvédeni a hálózatot, mert a rosszhiszemű viselkedés következtében a letét egy része vagy egésze megsemmisül. -- Minden slotban (tizenkét másodpercben) a validátort véletlenszerűen választják ki, hogy javasoljon egy blokkot. Tranzakciókat gyűjt össze, végrehajtja azokat és meghatározza a blokklánc új státuszát. Ezt az információt egy blokkba csomagolja és elküldi a többi validátornak. -- A többi validátor megtudja, hogy van egy új blokk, újra végrehajtja a tranzakciókat, hogy azok megegyeznek-e a javasolt új státusszal. Feltéve a blokk érvényes, hozzáteszik a saját adatbázisukhoz. -- Ha egy validátor két ütköző blokkot talál ugyanarra a slotra, akkor az elágazást választó algoritmussal azt választják, amelyet a legtöbb letétbe helyezett ETH támogat. - -[A proof-of-stake-ről bővebben](/developers/docs/consensus-mechanisms/pos) - -## Mi van egy blokkban? {#block-anatomy} - -A blokkban rengeteg információ van. A legmagasabb szinten a következő mezőket tartalmazza: - -| Mező | Leírás | -|:---------------- |:----------------------------------------------------------------------------- | -| `slot` | az a slot, amelyhez a blokk tartozik | -| `proposer_index` | a validátor azonosítója, aki a blokkot javasolta | -| `parent_root` | az előző blokk hash-e | -| `state_root` | a státusz objektum gyökér hash-e | -| `törzs` | egy olyan objektum, amely számos mezőt tartalmaz, ahogy azt alább definiáljuk | - -A blokk `body` számos mezőt tartalmaz: - -| Mező | Leírás | -|:-------------------- |:------------------------------------------------------------------- | -| `randao_reveal` | egy érték, amely a következő blokkjavaslót választja ki | -| `eth1_data` | információ a letéti szerződésről | -| `graffiti` | tetszőleges adat a blokkok taggelésére | -| `proposer_slashings` | a validátorok listája, akiket slashelni kell | -| `attester_slashings` | a tanusítók listája, akiket slashelni kell | -| `tanúsítások` | a tanúsítók listája, akik ezt a blokkot támogatják | -| `behelyezés` | az új letétek listája a letéti szerződésbe | -| `voluntary_exits` | a validátorok listája, akik kilépnek a hálózatból | -| `sync_aggregate` | a validátorok egy csoportja, akik a könnyű klienseket szolgálják ki | -| `execution_payload` | a végrehajtási klienstől jövő tranzakciók | - -A `attestations` (tanúsítások) mező tartalmazza a blokkban lévő az összes tanúsítást. A tanúsítások saját adattípussal rendelkezik, amelyben számos adat megtalálható. A tanúsítások a következőket tartalmazzák: - -| Mező | Leírás | -|:------------------ |:------------------------------------------------------------ | -| `aggregation_bits` | a validátorok listája, akik részt vettek a tanúsításban | -| `adat` | konténer számos almezővel | -| `aláírás` | az összes tanúsítást végző validátor aláírásának aggregátuma | - -A `data` mező a `tanúsítás` részen belül tartalmazza: - -| Mező | Leírás | -|:------------------- |:----------------------------------------------------------------- | -| `slot` | a slot, amelyhez a tanúsítás kapcsolódik | -| `index` | a tanúsítást végző validátorok indexei | -| `beacon_block_root` | a Beacon blokk gyökér hash-e, amely ezt az objektumot tartalmazza | -| `forrás` | az utolsó igazolt ellenőrzési pont | -| `target` | a legutolsó korszak határoló blokkja | - -A tranzakciók végrehajtása az `execution_payload` paraméterben frissíti a globális állapotot. Minden kliens újra végrehajtja a tranzakciókat, amelyek a `execution_payload` paraméterben vannak, hogy biztosítsa, az új állapot egyezik az új blokk `state_root` mezőjében lévőjével. Így tudják a kliensek megmondani, hogy az új blokkot érvényes és biztonságos-e hozzáadni a saját blokkláncukhoz. Az `execution payload` maga egy objektum, amely számos mezővel rendelkezik. Van egy `execution_payload_header` is, ami fontos összegzőinformációkat tartalmaz a végrehajtási adatokról. Ezek az adatstruktúrák a következőképpen vannak rendezve: - -Az `execution_payload_header` a következő mezőket tartalmazza: - -| Mező | Leírás | -|:------------------- |:------------------------------------------------------------------------ | -| `parent_hash` | a jelenlegi blokk elődjének a hash-e | -| `fee_recipient` | a számla címe, amelyre a tranzakciós díjakat fizették | -| `state_root` | a globális állapot gyökér hash-e, miután a változások bementek a blokkba | -| `receipts_root` | a tranzakció fogadói fájának hash-e | -| `logs_bloom` | eseménynaplókat tartalmazó adatstruktúra | -| `prev_randao` | egy érték, amit a véletlenszerű validátor kiválasztásnál használnak | -| `block_number` | a jelenlegi blokk száma | -| `gas_limit` | a jelenlegi blokkban megengedett maximális gáz | -| `gas_used` | a jelenlegi blokkban elhasznált gáz aktuális összege | -| `időbélyeg` | a blokk ideje | -| `extra_data` | tetszőleges hozzáadott adat, mint nyers bájt | -| `base_fee_per_gas` | az alapdíj értéke | -| `block_hash` | a végrehajtó blokk hash-e | -| `transactions_root` | a végrehajtási csomagban lévő tranzakciók gyökér hash-e | -| `withdrawal_root` | a végrehajtási csomagban lévő visszavonások gyökér hash-e | - -Az `execution_payload` maga a következőket tartalmazza (ami azonos a fejléccel, kivéve, hogy a gyökér hash-ek helyett a tranzakciók és visszavonások aktuális listáját tartalmazza): - -| Mező | Leírás | -|:------------------ |:------------------------------------------------------------------------ | -| `parent_hash` | a jelenlegi blokk elődjének a hash-e | -| `fee_recipient` | a számla címe, amelyre a tranzakciós díjakat fizették | -| `state_root` | a globális állapot gyökér hash-e, miután a változások bementek a blokkba | -| `receipts_root` | a tranzakció fogadói fájának hash-e | -| `logs_bloom` | eseménynaplókat tartalmazó adatstruktúra | -| `prev_randao` | egy érték, amit a véletlenszerű validátor kiválasztásnál használnak | -| `block_number` | a jelenlegi blokk száma | -| `gas_limit` | a jelenlegi blokkban megengedett maximális gáz | -| `gas_used` | a jelenlegi blokkban elhasznált gáz aktuális összege | -| `időbélyeg` | a blokk ideje | -| `extra_data` | tetszőleges hozzáadott adat, mint nyers bájt | -| `base_fee_per_gas` | az alapdíj értéke | -| `block_hash` | a végrehajtó blokk hash-e | -| `tranzakciók` | a tranzakciók listája, amit végre kell hajtani | -| `kivételek` | a visszavonásra kerülő objektumok listája | - -A `withdrawals` (visszavonások) listája tartalmazza a `withdrawal` (visszavonási) objektumokat, amelyek a következőképpen vannak strukturálva: - -| Mező | Leírás | -|:---------------- |:---------------------------------- | -| `address` | a visszavonásra került számla címe | -| `amount` | a visszavonás összege | -| `index` | a visszavonás index értéke | -| `validatorIndex` | a validátor index értéke | - -## Blokk idő {#block-time} - -A blokk ideje arra utal, hogy mennyi idő választja el a blokkokat. Az Ethereumban az időt tizenkét másodperces egységekre bontják, amelyet slotnak neveznek. Minden slotban egy validátort választanak, hogy javasoljon blokkot. Feltéve, hogy minden validátor online van és teljesen működőképes, minden slotban lesz egy blokk, tehát a blokk idő 12 másodperc. Azonban a validátorok lehetnek néha offline is, amikor felkérik őket blokkjavaslatra, tehát a slot néha üresen megy. - -Ez különbözik a proof-of-work alapú rendszerektől, ahol a blokk ideje valószínű érték és a protokoll céljának kibányászási nehézsége állítja be. Az Ethereum [átlagos blokkideje](https://etherscan.io/chart/blocktime) egy tökéletes példa erre, ahol az átállás a proof-of-work mechanizmusról a proof-of-stake-re egyértelműen kikövetkeztethető az új 12 másodperces blokkidő konzisztens voltából. - -## Blokkméret {#block-size} - -Utolsó fontos megjegyzés, hogy a blokkok maguk is korlátozott méretűek. Minden blokk 15 millió gáz célmérettel rendelkezik, de a blokk mérete a hálózati kereslet függvényében, egészen a 30 millió gáz határig (ami a célméret kétszerese) változik. A blokk gázkorlátja felfelé vagy lefelé is igazodhat az előző blokk gázkorlátjának 1/1024 faktorával. Így a validátorok megváltoztathatják a blokk gázkorlátját a konszenzus révén. A blokkban lévő tranzakciók által elköltött teljes gáz mennyisége kevesebb kell legyen, mint a blokk gázkorlátozása. Ez fontos, mert ez azt jelenti, hogy a blokkok nem lehetnek tetszőlegesen nagyok. Ha a blokkok tetszőlegesen nagyok lehetnének, akkor a kevésbé teljesítőképes teljes csomópontok egyre kevésbé tudnának lépést tartani a hálózattal a tárhely- és sebességigények miatt. Minél nagyobb a blokk, annál nagyobb számítási erő kell ahhoz, hogy időben fel legyen dolgozva a következő slotra. Ez egy centralizáló erő, amelynek úgy áll ellen, hogy határt szab a méretnek. - -## További olvasnivaló {#further-reading} - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Tranzakciók](/developers/docs/transactions/) -- [Gáz](/developers/docs/gas/) -- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/dapps/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/dapps/index.md deleted file mode 100644 index adf50977ec0..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/dapps/index.md +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Bevezetés a dappokba -description: -lang: hu ---- - -A decentralizált alkalmazás (dapp) egy olyan applikáció, amely olyan decentralizált hálózatra épült, ami egy [okosszerződést](/developers/docs/smart-contracts/) és egy frontend felhasználói felületet egyesít magában. Megjegyzésül: az Ethereum okosszerződések elérhetőek és transzparensek - mint a nyílt API-ok - így a dappod tartalmazhat olyan okosszerződést, melyet másvalaki írt. - -## Előfeltételek {#prerequisites} - -Mielőtt a dappokról tanulnál érdemes átnézned a [blokklánc alapok](/developers/docs/intro-to-ethereum/) oldalt, valamint eolvasnod az Ethereum hálózatról szóló oldalt, és azt, hogy mitől lesz decentralizált. - -## A dapp meghatározása {#definition-of-a-dapp} - -A dapp egy olyan backend kód, mely egy decentralizált peer-to-peer hálózaton fut. Ezzel szemben egy app esetében a backend kód centralizált szervereken fut. - -Egy dappnak bármely nyelven íródott frontend kódja vagy felhasználói felülete lehet (akárcsak az appoknak), mely hívásokat indíthat a backend felé. Továbbá a frontendje olyan decentralizált tárhelyeken lehet, mint az [IPFS](https://ipfs.io/). - -- **Decentralizált** – a dapp-ok az Ethereumon működnek, azaz egy nyitott, nyilvános, decentralizált platformon, ahol egyetlen személy vagy csoportnak sem irányít -- **Determinisztikusak** vagyis ugyanazt a függvényt hajtják végre a végrehajtási környezettől függetlenül. -- **Turing-teljes** – a dappok képesek végrehajtani bármilyen akciót, ha a megfelelő erőforrások rendelkezésre állnak -- **Izolált** – a dappok egy virtuális környezetben, az Ethereum Virtuális Gépen futnak, így ha az okosszerződésben hiba van, az nem érinti a blokklánchálózat normál működését - -### Az okosszerződésekről {#on-smart-contracts} - -Hogy bevezessük a dappokat, először be kell vezetnünk az okosszerződéseket – a dapp backendjét jobb kifejezés híján. A részletes áttekintéshez keresse fel az [okosszerződések](/developers/docs/smart-contracts/) oldalt. - -Az okosszerződés olyan kód, mely az Ethereum blokkláncon fut és pontosan úgy, ahogyan programozták. Amint az okosszerződések feltelepültek a hálózatra, azok többé nem módosíthatók. A dappok decentralizáltak lehetnek, mivel a szerződésbe írt logika irányítja őket, nem pedig egy egyén vagy egy vállalat. Ez azt is jelenti, hogy nagyon óvatosan kell megtervezned a szerződéseidet és alaposan le kell tesztelned őket. - -## A dapp fejlesztés előnyei {#benefits-of-dapp-development} - -- **Nulla állásidő** – amint az alkalmazás alapjául szolgáló okosszerződés telepítésre kerül a blokkláncon, a hálózat állandóan készen áll kiszolgálni a szerződéssel interakcióba lépő klienseket. Rosszindulatú szereplők emiatt nem tudnak szolgáltatásmegtagadási támadásokat indítani az egyes dappok ellen. -- **Adatvédelem** – nem kell igazolnod a valódi személyazonosságodat, hogy interakcióba lépj egy dappal. -- **Cenzúra rezisztancia** – nincs olyan egyedüli entitás a hálózaton, mely megakadályozhatná a felhasználókat abban, hogy tranzakciókat indítsanak, dappokat telepítsenek vagy adatot olvassanak a blokkláncról. -- **Teljes adat integritás** – a blokkláncon tárolt adatot nem megváltoztatható és nem megkérdőjelezhető a kriptográfiai primitíveknek köszönhetően. Rosszindulatú szereplők nem tudnak tranzakciókat vagy egyéb más adatot hamaisítni, amelyet publikáltak. -- **Bizalommentes számítás/hitelesíthető viselkedés** – az okosszerződéseket lehet elemezni és garantált, hogy megjósolható módon fognak végbe menni anélkül, hogy meg kellene bízni egy központi hatóságban. Ez nem igaz a hagyományos modellek esetében; ha például online bankolást használunk, meg kell bíznunk a pénzintézetekben, hogy nem fognak visszaélni a pénzügyi adatainkkal, megmásítani a feljegyzéseket vagy hacker támadást elszenvedni. - -## A dapp-fejlesztés hátrányai {#drawbacks-of-dapp-development} - -- **Karbantartás** – a dappokat nehezebb karbantartani, mivel a blokkláncra publikált kódot és az adatot nehezebb módosítani. A fejlesztők számára nehézkes frissíteni a dappjukat (vagy a dapp által tárolt mögöttes adatot), amint felkerültek a blokkláncra – még akkor is ha hibákat vagy biztonsági kockázatokat fedeztek fel a régi verzióban. -- **Végrehajtási költség** – magas a végrehajtási költség, a skálázás pedig nagyon nehéz. Ahhoz, hogy azt a biztonsági, integritási, átláthatósági és megbízhatósági szintet elérjük, melyre az Ethereum törekszik, minden egyes csomópont lefuttatja és eltárolja az összes tranzakciót. Ezen felül a proof-of-work konszenzus is időbe telik. -- **Hálózati torlódás** – ha egy dapp túl sok számítási kapacitást használ fel, akkor a teljes hálózat feltorlódik. Jelenleg a hálózat körülbelül 10 tranzakciót tud feldolgozni egy másodperc alatt; ha ennél gyorsabban küldenek be tranzakciókat, akkor a feldolgozatlan tranzakciók száma gyorsan felfújódhat. -- **Felhasználói élmény** – nehezebb felhasználóbarát élményeket adni, mivel az átlagos felhasználók túl nehéznek találhatják az eszközkészlet felállítását ahhoz, hogy a blokklánccal valóban biztonságos módon interakcióba léphessenek. -- **Centralizálás** – előfordulhat, hogy a felhasználó- és fejlesztőbarát megoldások, amelyek az Ethereum alaprétegére épülnek, végül centralizált szolgáltatásként fognak működni. Például az ilyen szolgáltatások kulcsokat vagy más bizalmas információkat tárolnak a szerveroldalon, centralizált szervert használnak a frontend kiszolgálására, vagy fontos üzleti logikákat futtatnak egy centralizált szerveren, mielőtt a blokkláncra írnának. Ez kizárja rengeteg (ha nem az összes) előnyét a blokkláncnak a hagyományos modellel szemben. - -## Ön inkább vizuális típus? {#visual-learner} - - - -## Eszközök a dappok létrehozásához {#dapp-tools} - -**Scaffold-ETH _– Próbálja ki a Solidity megoldást olyan frontenddel, amely illeszkedik az Ön okosszerződéséhez._** - -- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) -- [Példa egy dappra](https://punkwallet.io/) - -**Create Eth App _– Hozzon létre Ethereum-alapú alkalmazásokat egy paranccsal._** - -- [GitHub](https://github.com/paulrberg/create-eth-app) - -**One Click Dapp _- FOSS-eszköz dapp-frontendek készítéshez egy [ABI-ból](/glossary/#abi)._** - -- [oneclickdapp.com](https://oneclickdapp.com) -- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) - -**Etherflow _– FOSS-eszköz az Ethereum fejlesztők számára, amellyel tesztelheti csomópontjukat, illetve RPC-hívásokat állíthatnak össze és debuggolhatnak a böngészőből._** - -- [etherflow.quiknode.io](https://etherflow.quiknode.io/) -- [GitHub](https://github.com/abunsen/etherflow) - -**thirdweb _– SDK-k minden nyelven, okosszerződések, eszközök és infrastruktúra a web3 fejlesztéshez._** - -- [Honlap](https://thirdweb.com/) -- [Dokumentáció](https://portal.thirdweb.com/) -- [GitHub](https://github.com/thirdweb-dev/) - -**Crossmint _– Vállalati szintű web3 fejlesztési platform okosszerződések telepítéséhez, hitelkártyás és láncok közötti fizetések lehetővé tételéhez, valamint API-ok használatára NFT-k létrehozása, terjesztése, értékesítése, tárolása és szerkesztése érdekében._** - -- [crossmint.com](https://www.crossmint.com) -- [Dokumentáció](https://docs.crossmint.com) -- [Discord](https://discord.com/invite/crossmint) - -## További olvasnivaló {#further-reading} - -- [Fedezze fel a dappokat](/dapps) -- [A web 3.0 alkalmazások architektúrája](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ -- [Egy 2021-es útmutató a decentralizált alkalmazásokról](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) – _LimeChain_ -- [Mik azok decentralizált alkalmazások?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) – _Gemini_ -- [Népszerű dapp-ok](https://www.alchemy.com/dapps) - _Alchemy_ - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Bevezetés az Ethereum stack-be](/developers/docs/ethereum-stack/) -- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/index.md deleted file mode 100644 index f50543ecffd..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/index.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: Ethereum virtuális gép (EVM) -description: Bevezetés az Ethereum virtuális gépbe és arról, hogy hogyan kapcsolódik az állapothoz, tranzakciókhoz és okosszerződésekhez. -lang: hu ---- - -Az Ethereum Virtual Machine (EVM) egy decentralizált virtuális környezet, amely következetesen és biztonságosan hajtja végre a kódot az Ethereum összes csomópontján. A csomópontok az EVM-et futtatják az intelligens szerződések végrehajtására, a „[gáz](/gas/)” használatával mérik a [műveletekhez](/developers/docs/evm/opcodes/) szükséges számítási erőfeszítést, biztosítva az erőforrások hatékony elosztását és a hálózat biztonságát. - -## Előfeltételek {#prerequisites} - -Alapvető számítástudományi fogalmak ismerete, mint például a [bájtok](https://wikipedia.org/wiki/Byte), [memória](https://wikipedia.org/wiki/Computer_memory), és a [stack](https://wikipedia.org/wiki/Stack_(abstract_data_type)) szükségesek ahhoz, hogy megértse az EVM-et. Érdemes tisztában lenni egy pár kriptográfiai/blokklánc fogalommal úgy, mint a [hash függvények](https://wikipedia.org/wiki/Cryptographic_hash_function) és a [Merkle-fa](https://wikipedia.org/wiki/Merkle_tree). - -## Főkönyvtől az állapot gépig {#from-ledger-to-state-machine} - -Az 'elosztott főkönyv' analógiáját gyakran használjuk olyan blokkláncok jellemzésére, mint a Bitcoin, mely lehetővé egy decentralizált valuta létrehozását alapvető kriptográfiai eszközök használatával. A főkönyv tartalmazza a történések rekordjait, amelynek meg kell felelnie bizonyos szabályoknak, ami azt irányítja, hogy mit tehet meg és mit nem tehet meg valaki a főkönyv módosításához. Például egy Bitcoin cím nem költhet el több bitcoint, mint amennyit előzőleg megkapott. Ezek a szabályok támasztják alá az összes Bitcoin tranzakciót és sok más blokkláncot is. - -Míg az Ethereumnak megvan a saját natív kriptovalutája (Ether), amely ugyanazokat az intuitív szabályokat követi, emellett lehetőséget ad egy másik hathatós funkciónak is: [az okosszerződéseknek](/developers/docs/smart-contracts/). Ehhez a bonyolultabb funkcióhoz egy szofisztikáltabb analógia szükségeltetik. Egy elosztott főkönyv helyett az Ethereum egy elosztott [állapot gép](https://wikipedia.org/wiki/Finite-state_machine). Az Ethereum állapota egy nagy adatstruktúra, mely nem csak a számlákat és az egyenlegeket tárolja, de egy _állapot gépet_ is, mely blokkról blokkra változhat egy előre meghatározott szabályrendszer szerint és tetszőleges gépi kódot tud végrehajtani. Az állatot blokkról blokkra történő megváltozásának specifikus szabályait az EVM rögzíti. - -![Egy diagram mely az EVM felépítését mutatja be](./evm.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból - -## Az Ethereum állapot átmeneti függvény {#the-ethereum-state-transition-function} - -Az EVM úgy viselkedik, mint egy matematikai függvény: Adott egy bemenet, mely egy determinisztikus kimenetet generál. Ezért nagyon hasznos, ha az Ethereumot formálisabban úgy írjuk le, mint egy **állapot átmeneti függvényt**: - -``` -Y(S, T)= S' -``` - -Adott egy régebbi érvényes állapot `(S)` és egy új érvényes tranzakciókból álló halmaz `(T)`, az Ethereum állapot átmeneti függvény `Y(S, T)` létrehoz egy új érvényes kimeneti állapotot `S'` - -### Állapot {#state} - -Az Ethereum kontextusában az állapot egy hatalmas adatstruktúra, amelyet úgy hívnak, hogy [módosított Merkle Patricia-fa](/developers/docs/data-structures-and-encoding/patricia-merkle-trie/), amely az összes [számlát](/developers/docs/accounts/) hashekkel köti össze és redukálja egy gyökér hash-é, amelyet a blokklánc tárol. - -### Tranzakciók {#transactions} - -A tranzakciók számlákból származó kriptográfiailag aláírt instrukciók. A tranzakcióknak két típusa van: azok, amelyek üzenet hívásokat eredményeznek és azok melyek szerződés létrehozásokat. - -A szerződés létrehozás egy új szerződéses számla létrehozásával jár, mely a fordított [okosszerződés](/developers/docs/smart-contracts/anatomy/) bájtkódot tartalmazza. Amikor egy másik számla egy üzenet hívást intéz ehhez a szerződéshez, végrehajtja a bájtkódját. - -## EVM Utasítások {#evm-instructions} - -Az EVM egy [veremgépként](https://wikipedia.org/wiki/Stack_machine) fut 1024 elemes mélységgel. Mindegyik tétel egy 256 bites szó, amelyet a 256 bitet kriptográfia használata miatt választottak (mint amilyen a Keccak-256 hash-e vagy secp256k1 aláírások). - -A végrehajtás alatt az EVM egy tranziens _memóriát_ tart fenn (mint egy szócímzett bájttömböt), amely nem folytatólagos a tranzakciók között. - -A szerződések azonban tartalmaznak egy Merkle Patricia _tároló_ fát (mint egy szócímezhető szótömböt), amely hozzá van rendelve a kérdéses számlához és része a globális státusznak. - -A befordított okosszerződés bájtkódja EVM-[opcode-ként](/developers/docs/evm/opcodes) fut le, amely standard stack művelet, mint a `XOR`, `AND`, `ADD`, `SUB` stb. Az EVM egy pár blokklánc-specifikus stack-műveletet is implementál, mint az `ADDRESS`, `BALANCE`, `BLOCKHASH` stb. - -![Egy diagram, amely azt mutatja, hogy hol van szükség gázra az EVM-műveleteknél](../gas/gas.png) _Diagramok átvéve az [Illusztrált Ethereum EVM](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból - -## EVM Implementációk {#evm-implementations} - -Az összes EVM-implementációnak meg kell felelnie az Ethereum sárgakönyvben megfogalmazott specifikációnak. - -Az Ethereum kilenc éves története alatt az EVM több revízión átesett és számos EVM-implementáció létezik különböző programozási nyelveken. - -Az [Ethereum végrehajtási kliensek](/developers/docs/nodes-and-clients/#execution-clients) tartalmaznak egy EVM-implementációt. Továbbá több önálló implementáció létezik, ilyen például: - -- [Py-EVM](https://github.com/ethereum/py-evm) - _Python_ -- [evmone](https://github.com/ethereum/evmone) - _C++_ -- [ethereumjs-vm](https://github.com/ethereumjs/ethereumjs-vm) - _JavaScript_ -- [revm](https://github.com/bluealloy/revm) - _Rust_ - -## További olvasnivaló {#further-reading} - -- [Ethereum sárga könyv](https://ethereum.github.io/yellowpaper/paper.pdf) -- [Jello könyv, vagyis a KEVM: az EVM szemantikái K-ban](https://jellopaper.org/) -- [The Beigepaper](https://github.com/chronaeon/beigepaper) -- [Ethereum Virtuális Gép Opcode-ok](https://www.ethervm.io/) -- [Ethereum Virtuális Gép operációskódjainak interaktív referenciája](https://www.evm.codes/) -- [Rövid bevezetés a Solidity dokumentációjába](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#index-6) -- [Az Ethereum elsajátítása - az Ethereum virtuális gép](https://github.com/ethereumbook/ethereumbook/blob/develop/13evm.asciidoc) - -## Kapcsolódó témák {#related-topics} - -- [Gáz](/developers/docs/gas/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/opcodes/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/opcodes/index.md deleted file mode 100644 index d5f93cfe26a..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/evm/opcodes/index.md +++ /dev/null @@ -1,174 +0,0 @@ ---- -title: Az EVM operációs kódjai -description: Az Ethereum Virtuális Gép összes elérhető operációs kódja. -lang: hu ---- - -## Áttekintés {#overview} - -Ez az EVM referenciaoldalának [wolflo/evm-opcodes](https://github.com/wolflo/evm-opcodes) frissített változata. A [Sárga könyvből](https://ethereum.github.io/yellowpaper/paper.pdf), a [Jello könyvből](https://jellopaper.org/evm/) és a [geth](https://github.com/ethereum/go-ethereum) implementációból származik. Ez egy mindenki számára elérhető referencia, de nem feltétlen szigorú. Ha biztosra szeretne menni, akkor használja a Jello könyvet vagy egy kliens implementációját. - -Interaktív referenciát keres? Tekintse meg az [evm.codes](https://www.evm.codes/) oldalt. - -A dinamikus gázköltséggel működő műveletekhez nézze meg a következőt: [gas.md](https://github.com/wolflo/evm-opcodes/blob/main/gas.md). - -Tipp: a teljes sorokhoz használja a `[shift] + scroll` funkciót, hogy vízszintesen tudjon mozogni. - -| Stack | Név | Gáz | Kezdő stack | Eredmény stack | Memória / Tárhely | Megjegyzések | -|:-----:|:-------------- |:---------------------------------------------------------------------------------------------------:|:------------------------------------------------ |:-------------------------------------------- |:----------------------------------------------------------------------------- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 00 | STOP | 0 | | | | halt execution | -| 01 | ADD | 3 | `a, b` | `a + b` | | (u)int256 addition modulo 2\*\*256 | -| 02 | MUL | 5 | `a, b` | `a * b` | | (u)int256 multiplication modulo 2\*\*256 | -| 03 | SUB | 3 | `a, b` | `a - b` | | (u)int256 addition modulo 2\*\*256 | -| 04 | DIV | 5 | `a, b` | `a // b` | | uint256 division | -| 05 | SDIV | 5 | `a, b` | `a // b` | | int256 division | -| 06 | MOD | 5 | `a, b` | `a % b` | | uint256 modulus | -| 07 | SMOD | 5 | `a, b` | `a % b` | | int256 modulus | -| 08 | ADDMOD | 8 | `a, b, N` | `(a + b) % N` | | (u)int256 addition modulo N | -| 09 | MULMOD | 8 | `a, b, N` | `(a * b) % N` | | (u)int256 multiplication modulo N | -| 0A | EXP | [A1](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a1-exp) | `a, b` | `a ** b` | | uint256 exponentiation modulo 2\*\*256 | -| 0B | SIGNEXTEND | 5 | `b, x` | `SIGNEXTEND(x, b)` | | [sign extend](https://wikipedia.org/wiki/Sign_extension) `x` from `(b+1)` bytes to 32 bytes | -| 0C-0F | _invalid_ | | | | | | -| 10 | LT | 3 | `a, b` | `a < b` | | uint256 less-than | -| 11 | GT | 3 | `a, b` | `a > b` | | uint256 greater-than | -| 12 | SLT | 3 | `a, b` | `a < b` | | int256 less-than | -| 13 | SGT | 3 | `a, b` | `a > b` | | int256 greater-than | -| 14 | EQ | 3 | `a, b` | `a == b` | | (u)int256 equality | -| 15 | ISZERO | 3 | `a` | `a == 0` | | (u)int256 iszero | -| 16 | AND | 3 | `a, b` | `a && b` | | bitwise AND | -| 17 | OR | 3 | `a, b` | `a \|\| b` | | bitwise OR | -| 18 | XOR | 3 | `a, b` | `a ^ b` | | bitwise XOR | -| 19 | NOT | 3 | `a` | `~a` | | bitwise NOT | -| 1A | BYTE | 3 | `i, x` | `(x >> (248 - i * 8)) && 0xFF` | | `i`th byte of (u)int256 `x`, from the left | -| 1B | SHL | 3 | `shift, val` | `val << shift` | | shift left | -| 1C | SHR | 3 | `shift, val` | `val >> shift` | | logical shift right | -| 1D | SAR | 3 | `shift, val` | `val >> shift` | | arithmetic shift right | -| 1E-1F | _invalid_ | | | | | | -| 20 | KECCAK256 | [A2](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a2-sha3) | `ost, len` | `keccak256(mem[ost:ost+len-1])` | | keccak256 | -| 21-2F | _invalid_ | | | | | | -| 30 | ADDRESS | 2 | `.` | `address(this)` | | address of executing contract | -| 31 | BALANCE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `addr.balance` | | balance, in wei | -| 32 | ORIGIN | 2 | `.` | `tx.origin` | | address that originated the tx | -| 33 | CALLER | 2 | `.` | `msg.sender` | | address of msg sender | -| 34 | CALLVALUE | 2 | `.` | `msg.value` | | msg value, in wei | -| 35 | CALLDATALOAD | 3 | `idx` | `msg.data[idx:idx+32]` | | read word from msg data at index `idx` | -| 36 | CALLDATASIZE | 2 | `.` | `len(msg.data)` | | length of msg data, in bytes | -| 37 | CALLDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := msg.data[ost:ost+len-1] | copy msg data | -| 38 | CODESIZE | 2 | `.` | `len(this.code)` | | length of executing contract's code, in bytes | -| 39 | CODECOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | | mem[dstOst:dstOst+len-1] := this.code[ost:ost+len-1] | copy executing contract's bytecode | -| 3A | GASPRICE | 2 | `.` | `tx.gasprice` | | gas price of tx, in wei per unit gas [\*\*](https://eips.ethereum.org/EIPS/eip-1559#gasprice) | -| 3B | EXTCODESIZE | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `len(addr.code)` | | size of code at addr, in bytes | -| 3C | EXTCODECOPY | [A4](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a4-extcodecopy) | `addr, dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := addr.code[ost:ost+len-1] | copy code from `addr` | -| 3D | RETURNDATASIZE | 2 | `.` | `size` | | size of returned data from last external call, in bytes | -| 3E | RETURNDATACOPY | [A3](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a3-copy-operations) | `dstOst, ost, len` | `.` | mem[dstOst:dstOst+len-1] := returndata[ost:ost+len-1] | copy returned data from last external call | -| 3F | EXTCODEHASH | [A5](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a5-balance-extcodesize-extcodehash) | `addr` | `hash` | | hash = addr.exists ? keccak256(addr.code) : 0 | -| 40 | BLOCKHASH | 20 | `blockNum` | `blockHash(blockNum)` | | | -| 41 | COINBASE | 2 | `.` | `block.coinbase` | | a jelenlegi blokk előterjesztőjének címe | -| 42 | TIMESTAMP | 2 | `.` | `block.timestamp` | | timestamp of current block | -| 43 | NUMBER | 2 | `.` | `block.number` | | number of current block | -| 44 | PREVRANDAO | 2 | `.` | `randomness beacon` | | randomness beacon | -| 45 | GASLIMIT | 2 | `.` | `block.gaslimit` | | gas limit of current block | -| 46 | CHAINID | 2 | `.` | `chain_id` | | push current [chain id](https://eips.ethereum.org/EIPS/eip-155) onto stack | -| 47 | SELFBALANCE | 5 | `.` | `address(this).balance` | | balance of executing contract, in wei | -| 48 | BASEFEE | 2 | `.` | `block.basefee` | | base fee of current block | -| 49 | BLOBHASH | 3 | `idx` | `tx.blob_versioned_hashes[idx]` | | [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) | -| 4A | BLOBBASEFEE | 2 | `.` | `block.blobbasefee` | | a jelenlegi blokk blob alapdíjja ([EIP-7516](https://eips.ethereum.org/EIPS/eip-7516)) | -| 4B-4F | _invalid_ | | | | | | -| 50 | POP | 2 | `_anon` | `.` | | remove item from top of stack and discard it | -| 51 | MLOAD | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost` | `mem[ost:ost+32]` | | read word from memory at offset `ost` | -| 52 | MSTORE | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost:ost+32] := val | write a word to memory | -| 53 | MSTORE8 | 3[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, val` | `.` | mem[ost] := val && 0xFF | write a single byte to memory | -| 54 | SLOAD | [A6](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a6-sload) | `key` | `storage[key]` | | read word from storage | -| 55 | SSTORE | [A7](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a7-sstore) | `key, val` | `.` | storage[key] := val | write word to storage | -| 56 | JUMP | 8 | `dst` | `.` | | `$pc := dst` mark that `pc` is only assigned if `dst` is a valid jumpdest | -| 57 | JUMPI | 10 | `dst, condition` | `.` | | `$pc := condition ? dst : $pc + 1` | -| 58 | PC | 2 | `.` | `$pc` | | program counter | -| 59 | MSIZE | 2 | `.` | `len(mem)` | | size of memory in current execution context, in bytes | -| 5A | GAS | 2 | `.` | `gasRemaining` | | | -| 5B | JUMPDEST | 1 | | | mark valid jump destination | a valid jump destination for example a jump destination not inside the push data | -| 5C | TLOAD | 100 | `key` | `tstorage[key]` | | kiolvasás az átmeneti tárhelyről ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5D | TSTORE | 100 | `key, val` | `.` | tstorage[key] := val | írás az átmeneti tárhelyre ([EIP-1153](https://eips.ethereum.org/EIPS/eip-1153)) | -| 5E | MCOPY | 3+3\* szavak + [A0](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `dstOst, ost, len` | `.` | mem[dstOst] := mem[ost:ost+len] | memóriamásolás egyik helyről a másikra ([EIP-5656](https://eips.ethereum.org/EIPS/eip-5656)) | -| 5F | PUSH0 | 2 | `.` | `uint8` | | az állandó 0 érték áttolása a stackre | -| 60 | PUSH1 | 3 | `.` | `uint8` | | push 1-byte value onto stack | -| 61 | PUSH2 | 3 | `.` | `uint16` | | push 2-byte value onto stack | -| 62 | PUSH3 | 3 | `.` | `uint24` | | push 3-byte value onto stack | -| 63 | PUSH4 | 3 | `.` | `uint32` | | push 4-byte value onto stack | -| 64 | PUSH5 | 3 | `.` | `uint40` | | push 5-byte value onto stack | -| 65 | PUSH6 | 3 | `.` | `uint48` | | push 6-byte value onto stack | -| 66 | PUSH7 | 3 | `.` | `uint56` | | push 7-byte value onto stack | -| 67 | PUSH8 | 3 | `.` | `uint64` | | push 8-byte value onto stack | -| 68 | PUSH9 | 3 | `.` | `uint72` | | push 9-byte value onto stack | -| 69 | PUSH10 | 3 | `.` | `uint80` | | push 10-byte value onto stack | -| 6A | PUSH11 | 3 | `.` | `uint88` | | push 11-byte value onto stack | -| 6B | PUSH12 | 3 | `.` | `uint96` | | push 12-byte value onto stack | -| 6C | PUSH13 | 3 | `.` | `uint104` | | push 13-byte value onto stack | -| 6D | PUSH14 | 3 | `.` | `uint112` | | push 14-byte value onto stack | -| 6E | PUSH15 | 3 | `.` | `uint120` | | push 15-byte value onto stack | -| 6F | PUSH16 | 3 | `.` | `uint128` | | push 16-byte value onto stack | -| 70 | PUSH17 | 3 | `.` | `uint136` | | push 17-byte value onto stack | -| 71 | PUSH18 | 3 | `.` | `uint144` | | push 18-byte value onto stack | -| 72 | PUSH19 | 3 | `.` | `uint152` | | push 19-byte value onto stack | -| 73 | PUSH20 | 3 | `.` | `uint160` | | push 20-byte value onto stack | -| 74 | PUSH21 | 3 | `.` | `uint168` | | push 21-byte value onto stack | -| 75 | PUSH22 | 3 | `.` | `uint176` | | push 22-byte value onto stack | -| 76 | PUSH23 | 3 | `.` | `uint184` | | push 23-byte value onto stack | -| 77 | PUSH24 | 3 | `.` | `uint192` | | push 24-byte value onto stack | -| 78 | PUSH25 | 3 | `.` | `uint200` | | push 25-byte value onto stack | -| 79 | PUSH26 | 3 | `.` | `uint208` | | push 26-byte value onto stack | -| 7A | PUSH27 | 3 | `.` | `uint216` | | push 27-byte value onto stack | -| 7B | PUSH28 | 3 | `.` | `uint224` | | push 28-byte value onto stack | -| 7C | PUSH29 | 3 | `.` | `uint232` | | push 29-byte value onto stack | -| 7D | PUSH30 | 3 | `.` | `uint240` | | push 30-byte value onto stack | -| 7E | PUSH31 | 3 | `.` | `uint248` | | push 31-byte value onto stack | -| 7F | PUSH32 | 3 | `.` | `uint256` | | push 32-byte value onto stack | -| 80 | DUP1 | 3 | `a` | `a, a` | | clone 1st value on stack | -| 81 | DUP2 | 3 | `_, a` | `a, _, a` | | clone 2nd value on stack | -| 82 | DUP3 | 3 | `_, _, a` | `a, _, _, a` | | clone 3rd value on stack | -| 83 | DUP4 | 3 | `_, _, _, a` | `a, _, _, _, a` | | clone 4th value on stack | -| 84 | DUP5 | 3 | `..., a` | `a, ..., a` | | clone 5th value on stack | -| 85 | DUP6 | 3 | `..., a` | `a, ..., a` | | clone 6th value on stack | -| 86 | DUP7 | 3 | `..., a` | `a, ..., a` | | clone 7th value on stack | -| 87 | DUP8 | 3 | `..., a` | `a, ..., a` | | clone 8th value on stack | -| 88 | DUP9 | 3 | `..., a` | `a, ..., a` | | clone 9th value on stack | -| 89 | DUP10 | 3 | `..., a` | `a, ..., a` | | clone 10th value on stack | -| 8A | DUP11 | 3 | `..., a` | `a, ..., a` | | clone 11th value on stack | -| 8B | DUP12 | 3 | `..., a` | `a, ..., a` | | clone 12th value on stack | -| 8C | DUP13 | 3 | `..., a` | `a, ..., a` | | clone 13th value on stack | -| 8D | DUP14 | 3 | `..., a` | `a, ..., a` | | clone 14th value on stack | -| 8E | DUP15 | 3 | `..., a` | `a, ..., a` | | clone 15th value on stack | -| 8F | DUP16 | 3 | `..., a` | `a, ..., a` | | clone 16th value on stack | -| 90 | SWAP1 | 3 | `a, b` | `b, a` | | | -| 91 | SWAP2 | 3 | `a, _, b` | `b, _, a` | | | -| 92 | SWAP3 | 3 | `a, _, _, b` | `b, _, _, a` | | | -| 93 | SWAP4 | 3 | `a, _, _, _, b` | `b, _, _, _, a` | | | -| 94 | SWAP5 | 3 | `a, ..., b` | `b, ..., a` | | | -| 95 | SWAP6 | 3 | `a, ..., b` | `b, ..., a` | | | -| 96 | SWAP7 | 3 | `a, ..., b` | `b, ..., a` | | | -| 97 | SWAP8 | 3 | `a, ..., b` | `b, ..., a` | | | -| 98 | SWAP9 | 3 | `a, ..., b` | `b, ..., a` | | | -| 99 | SWAP10 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9A | SWAP11 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9B | SWAP12 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9C | SWAP13 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9D | SWAP14 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9E | SWAP15 | 3 | `a, ..., b` | `b, ..., a` | | | -| 9F | SWAP16 | 3 | `a, ..., b` | `b, ..., a` | | | -| A0 | LOG0 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len` | `.` | | LOG0(memory[ost:ost+len-1]) | -| A1 | LOG1 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0` | `.` | | LOG1(memory[ost:ost+len-1], topic0) | -| A2 | LOG2 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1` | `.` | | LOG2(memory[ost:ost+len-1], topic0, topic1) | -| A3 | LOG3 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2` | `.` | | LOG3(memory[ost:ost+len-1], topic0, topic1, topic2) | -| A4 | LOG4 | [A8](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a8-log-operations) | `ost, len, topic0, topic1, topic2, topic3` | `.` | | LOG4(memory[ost:ost+len-1], topic0, topic1, topic2, topic3) | -| A5-EF | _invalid_ | | | | | | -| F0 | CREATE | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len` | `addr` | | addr = keccak256(rlp([address(this), this.nonce])) | -| F1 | CALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | gas, addr, val, argOst, argLen, retOst, retLen | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F2 | CALLCODE | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, val, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] = returndata | same as DELEGATECALL, but does not propagate original msg.sender and msg.value | -| F3 | RETURN | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | return mem[ost:ost+len-1] | -| F4 | DELEGATECALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| F5 | CREATE2 | [A9](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a9-create-operations) | `val, ost, len, salt` | `addr` | | addr = keccak256(0xff ++ address(this) ++ salt ++ keccak256(mem[ost:ost+len-1]))[12:] | -| F6-F9 | _invalid_ | | | | | | -| FA | STATICCALL | [AA](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#aa-call-operations) | `gas, addr, argOst, argLen, retOst, retLen` | `success` | mem[retOst:retOst+retLen-1] := returndata | | -| FB-FC | _invalid_ | | | | | | -| FD | REVERT | 0[\*](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#a0-1-memory-expansion) | `ost, len` | `.` | | revert(mem[ost:ost+len-1]) | -| FE | INVALID | [AF](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#af-invalid) | | | designated invalid opcode - [EIP-141](https://eips.ethereum.org/EIPS/eip-141) | | -| FF | SELFDESTRUCT | [AB](https://github.com/wolflo/evm-opcodes/blob/main/gas.md#ab-selfdestruct) | `addr` | `.` | | elküldi az összes ETH-t az `addr` címre; ha ugyanabban a tranzakcióban hajtják végre, mint a szerződés létrejött, az megsemmisíti a szerződést | diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/gas/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/gas/index.md deleted file mode 100644 index 7d839ae7b4b..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/gas/index.md +++ /dev/null @@ -1,140 +0,0 @@ ---- -title: Gáz és tranzakciós díjak -description: -lang: hu ---- - -Az gáz nélkülözhetetlen az Ethereum hálózaton. Ez az üzemanyag, amitől működik, ahogyan az autóknak is szükségük van benzinre, hogy menjenek. - -## Előfeltételek {#prerequisites} - -Hogy jobban megértse ezt az oldalt, javasoljuk, hogy olvassa el a [tranzakciókról](/developers/docs/transactions/) és az [EVM-ről](/developers/docs/evm/) szóló oldalakat. - -## Mi az a gáz? {#what-is-gas} - -A gáz a számítási erőfeszítés mértékegységét jelenti, mely bizonyos műveletek végrehajtásához szükséges az Ethereum hálózaton. - -Mivel az Ethereum-tranzakciók számítási kapacitást igényelnek a végrehajtáshoz, ezeket ki kell fizetni, hogy a hálózat ne legyen sebezhető a szemeteléssel vagy a végtelen ciklusokat indító logikákkal szemben. A számításokért gázdíj formájában kell fizetni. - -A gázdíj **a művelet végrehajtásához szükséges gáz mennyisége, szorozva a gázegység költségével**. A díjat a tranzakció sikerességétől függetlenül is ki kell fizetni. - -![Egy diagram, amely azt mutatja, hogy hol van szükség gázra az EVM-műveleteknél](./gas.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból - -A gázdíjakat az Ethereum saját valutájában, etherben (ETH) kell kifizetni. A gázdíjakat általában gwei-ben adják meg, ami az ETH címlete. Egy gwei az ETH egymilliárdnyi részével (0,000000001 ETH vagy 10-9 ETH) egyenlő. - -Például ahelyett, hogy azt mondanánk, hogy a gáz 0,000000001 ether-be kerül, azt mondjuk, hogy a gáz ára 1 gwei. - -A gwei a giga-wei-ből ered, ami milliárd weit jelent. Egy gwei az egy milliárd wei. A wei (amit [Wei Dai](https://wikipedia.org/wiki/Wei_Dai) után neveztek el, aki a [b-pénz feltalálója](https://www.investopedia.com/terms/b/bmoney.asp)) az ETH legkisebb egysége. - -## Hogyan kerül kiszámításra a gázdíj? {#how-are-gas-fees-calculated} - -Amikor a felhasználó egy tranzakciót indít, akkor ki tudja választani, hogy mennyi gázdíjat hajlandó fizetni a végrehajtásért. Bizonyos gázmennyiség felajánlásával ajánlatot tesz, hogy az adott tranzakció bekerüljön a következő blokkba. Ha túl kicsi az összeg, akkor a validátorok kisebb valószínűséggel kapják fel a tranzakciót, így az később vagy esetleg egyáltalán nem kerül feldolgozásra. Ha túl sokat ajánl valaki, akkor talán elveszíti az ETH-összeg egy részét. Hogyan érdemes meghatározni a fizetendő díjat? - -A teljes gázdíj két komponensből áll: az `alapdíj` és az `elsőbbségi díj` (borravaló). - -Az `alapdíjat` a protokoll állapítja meg – ahhoz, hogy a tranzakció érvényes legyen, legalább ennyit ki kell érte fizetni. Az `elsőbbségi díj` egy borravaló az alapdíjon felül, amely miatt a tranzakció vonzóvá válhat a validátorok szemében, ezért felveszik azt a következő blokkba. - -Az a tranzakció, amely csak az `alapdíjat` fizeti meg, technikailag érvényes, de kevéssé valószínű, hogy bekerül, mert nem jelent motivációt a validátoroknak, hogy egy másik tranzakció helyett ezt válasszák. A „megfelelő” `elsőbbségi díjat` a hálózat használata határozza meg abban az időpontban, amikor a felhasználó a tranzakciót elküldi – ha nagy a kereslet, akkor magasabb `elsőbbségi díjat` kell fizetni, kisebb keresletnél pedig kevesebb is elég lehet. - -Például Jordannek ki kell fizetnie 1 ETH-t Taylornak. Az ETH transzferhez 21 000 egységnyi gázra van szükség, az alapdíj pedig 10 gwei. Jordan 2 gwei borravalót ad hozzá. - -A teljes díj így néz ki: - -`a felhasznált gáz mennyisége * (alapdíj + elsőbbségi díj)` - -ahol az `alapdíjat` a protokoll határozza meg, az `elsőbbségi díjat` pedig a felhasználó adja, hogy a validátort díjazza. - -pl. `21 000 * (10 + 2) = 252 000 gwei` (0,000252 ETH). - -Amikor Jordan elküldi a pénzt, akkor a számlájáról 1,000252 ETH-t fognak levonni. Taylornak pedig jóváírnak 1,0000 ETH-t. A validátor megkapja 0,000042 ETH borravalót. A 0,00021 ETH `alapdíjat` elégetik. - -### Alapdíj {#base-fee} - -Minden blokk rendelkezik alapdíjjal, ami egyfajta foglalási díjként működik. A blokkba csak úgy lehet bekerülni, hogy a gázért felajánlott ár eléri az alapdíjat. Az alapdíj az aktuális blokktól függetlenül kerül kiszámításra, inkább az előző blokk határozza meg, hogy a tranzakciós illeték kiszámíthatóbb legyen a felhasználók számára. Amikor a blokk létrejön, akkor ez az **alapdíj „elég”**, vagyis kivonják a körforgásból. - -Az alapdíj egy olyan képlettel kerül kiszámításra, amely összeveti az előző blokk méretét (a benne lévő tranzakciók által felhasznált gáz mennyisége) a célmérettel. Ha a blokk meghaladja a célméretet, akkor az alapdíj legfeljebb 12,5%-kal emelkedik blokkonként. Ez az exponenciális növekedés gazdasági szempontból eléri, hogy a blokkméret ne maradhasson ilyen nagy a végtelenségig. - -| Blokkszám | Benne lévő gáz | Díjnövekedés | Jelenlegi alapdíj | -| --------- | --------------:| ------------:| -----------------:| -| 1 | 15M | 0% | 100 gwei | -| 2 | 30M | 0% | 100 gwei | -| 3 | 30M | 12,5% | 112,5 gwei | -| 4 | 30M | 12,5% | 126,6 gwei | -| 5 | 30M | 12,5% | 142,4 gwei | -| 6 | 30M | 12,5% | 160,2 gwei | -| 7 | 30M | 12,5% | 180,2 gwei | -| 8 | 30M | 12,5% | 202,7 gwei | - -A táblázatot folytatva a 9. blokkba kerülő tranzakcióra a tárca megadja a felhasználónak, hogy a **maximális alapdíj**, amivel bekerülhet a következő blokkba, az `a jelenlegi alapdíj * 112,5%` vagy `202,7 gwei * 112,5% = 228,1 gwei`. - -Fontos megjegyezni, hogy nem valószínű, hogy egymás után sok teljes blokk készül, mert az alapdíj gyorsan növekszik a teljes blokk előtt. - -| Blokkszám | Benne lévő gáz | Díjnövekedés | Jelenlegi alapdíj | -| --------- | --------------:| ------------:| -----------------:| -| 30 | 30M | 12,5% | 2705,6 gwei | -| ... | ... | 12,5% | ... | -| 50 | 30M | 12,5% | 28 531,3 gwei | -| ... | ... | 12,5% | ... | -| 100 | 30M | 12,5% | 10 302 608,6 gwei | - -### Elsőbbségi díj (borravaló) {#priority-fee} - -Az elsőbbségi díj (borravaló) motiválja a validátorokat, hogy bevegyék a tranzakciót a blokkba. A borravaló nélkül a validátoroknak gazdaságilag ugyanolyan értékű, ha üresen marad a blokk, mint ha felvesznek bele tranzakciókat, mert a blokkért megkapják a díjazásukat. A kis értékű borravaló egy minimális ösztönzést ad a validátoroknak, hogy felvegyenek egy tranzakciót. Azokért a tételekért, amelyeket ugyanabban a blokkban, de a többi tétel előtt szeretnénk végrehajtatni, magasabb borravalót érdemes fizetni, hogy lekörözze a többi tranzakció ajánlatát. - -### Maximális díj {#maxfee} - -Ahhoz, hogy a hálózaton végre legyen hajtva egy tranzakció, a felhasználók meghatározhatnak egy maximális határt, amit még hajlandók kifizetni érte. Ennek az opcionális paraméternek a neve `maxFeePerGas`. A tranzakció végrehajtásához a maximális díjnak meg kell haladnia az alapdíj és a borravaló összegét. A tranzakció küldője visszakapja azt a különbözetet, ami a maximális díj, valamint az alapdíj és a borravaló összege között van. - -### Blokkméret {#block-size} - -Minden blokk 15 millió gáz célmérettel rendelkezik, de a blokk mérete a hálózati kereslet függvényében, egészen a 30 millió gáz határig (amely a célméret kétszerese) változik. A protokoll úgy éri el az egyensúlyi, átlagos 15 milliós blokkméretet, hogy a _tâtonnement_, vagyis a közelítés módszerét alkalmazza. Tehát, ha a blokkméret meghaladja a célértéket, akkor a protokoll megnöveli az alapdíjat a következő blokknál. Ugyanígy csökkenti az alapdíjat, ha a blokkméret kisebb, mint a célérték. Az alapdíj mértéke arányosan változik annak függvényében, hogy a jelenlegi blokkméret hogyan viszonyul a célmérethez. [Bővebben a blokkokról](/developers/docs/blocks/). - -### A gázdíjak kiszámítása a gyakorlatban {#calculating-fees-in-practice} - -A felhasználó egyértelműen kijelentheti, hogy mennyit hajlandó fizetni azért, hogy a tranzakciót végrehajtsák. Emellett a legtöbb tárcaszolgáltató automatikusan beállít egy javasolt tranzakciós illetéket (alapdíj + a javasolt elsőbbségi díj), hogy csökkentse a használat komplexitását. - -## Miért léteznek a gázdíjak? {#why-do-gas-fees-exist} - -Röviden, a gázdíjak tartják fenn a Ethereum hálózat biztonságát. Azzal, hogy a hálózaton végrehajtott minden számítás egy díjat von maga után, megelőzzük, hogy rosszhiszemű személyek túlterheljék a hálózatot. Azért, hogy megelőzzük a véletlen vagy ártó szándékú végtelen ciklusokat vagy más számítási pazarlással járó kódot, minden egyes tranzakciónak be kell állítani egy határt, hogy mennyi számítási lépést hajthat végre a kód futtatása. A számítás alapmértékegysége a „gáz”. - -Habár a tranzakció tartalmaz egy határt, a fel nem használt gázdíj visszakerül a felhasználóhoz. Például a `maximális díj – (alapdíj + borravaló)` visszatérítésre kerül. - -![Egy diagram, amely a fel nem használt gáz visszatérítését ábrázolja](../transactions/gas-tx.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból - -## Mit jelent a gázkorlátozás? {#what-is-gas-limit} - -A gázkorlátozás arra utal, hogy egy tranzakció során legfeljebb mennyi gázra lesz szükség. A bonyolultabb tranzakciók, mint az [okosszerződések](/developers/docs/smart-contracts/), több számítási kapacitást igényelnek, ezért magasabb gázkorlátozásra van szükségük, mint egy egyszerű átutalásnál. Egy általános ETH-transzfer 21 000 egységi gázkorlátozást igényel. - -Például, ha egy egyszerű ETH transzferre azt állítjuk be, hogy a gázkorlátozás 50 000 legyen, az EVM felhasznál 21 000-et, a felhasználó pedig visszakapja a maradék 29 000-et. Ha viszont túl kevés gázt határozunk meg, például a gázkorlátozás 20 000 lesz egy egyszerű ETH transzferhez, akkor az EVM elfogyasztja a 20 000 egységet, és megpróbálja végrehajtani a tranzakciót, de nem tudja azt teljesíteni. Ekkor az EVM visszaforgatja a változtatásokat, de mivel a validátor már elvégzett 20 000 gáz mennyiségű munkát, ezért ez el lett fogyasztva. - -## Miért lehetnek olyan magasak a gázdíjak? {#why-can-gas-fees-get-so-high} - -A magas gázdíjak oka az Ethereum népszerűsége. Amikor nagy a kereslet, akkor a felhasználóknak magasabb borravalót kell ajánlaniuk, hogy lekörözzék a többi tranzakciót. A magasabb borravaló miatt az adott tranzakció valószínűleg bekerül a következő blokkba. Emellett a sokkal összetettebb okosszerződéses alkalmazások sok műveletet végezhetnek funkcióik támogatása érdekében, amivel sok gázt fogyasztanak el. - -## Kezdeményezések a gázköltségek csökkentésére {#initiatives-to-reduce-gas-costs} - -Az Ethereum [skálázhatósági fejlesztései](/roadmap/) meg fogják oldani a gázdíjak körüli problémák egy részét, így lehetővé teszik, hogy a platform ezernyi tranzakciót dolgozzon fel másodpercenként és globálisan skálázható legyen. - -A második blokkláncréteggel (L2) kialakított skálázás a fő kezdeményezés arra, hogy nagy mértékben javuljanak a gázköltségek, a felhasználói élmény és a skálázhatóság. [Bővebben az L2 skálázásról](/developers/docs/scaling/#layer-2-scaling). - -## A gázdíjak felügyelete {#monitoring-gas-fees} - -Ha Ön szeretné felügyelni a gázdíjakat azért, hogy kevesebbet kelljen fizetnie az ETH-tranzakciókért, akkor számos eszköz áll rendelkezésre: - -- [Etherscan](https://etherscan.io/gastracker) _ Tranzakció gázdíjának becslése_ -- [ETH Gas Tracker](https://www.ethgastracker.com/) _Figyeli és kövesti az Ethereum és az L2 gázárakat a tranzakciós díjak csökkentése és a pénzmegtakarítás érdekében_ -- [Blocknative ETH gázbecslés](https://chrome.google.com/webstore/detail/blocknative-eth-gas-estim/ablbagjepecncofimgjmdpnhnfjiecfm) _Gázbecslő Chrome-kiterjesztés, amely támogatja az eredeti (0. típusú) és az EIP-1559 (2. típusú) tranzakciókat._ -- [Cryptoneur gázdíjkalkulátor](https://www.cryptoneur.xyz/gas-fees-calculator) _Számolja ki a gázdíjat a saját pénznemében a különféle tranzakciókra az Ethereum főhálózatán, az Arbitrumon és a Polygonon._ - -## Kapcsolódó eszközök {#related-tools} - -- [Blocknative gázplatform](https://www.blocknative.com/gas) _Gázbecslő API, amelyet a Blocknative globális memóriakészlet adatplatformja támogat_ - -## További olvasnivaló {#further-reading} - -- [Az Ethereum gázdíjról részletesen](https://defiprime.com/gas) -- [Csökkentse az okosszerződésének gázfogyasztását](https://medium.com/coinmonks/8-ways-of-reducing-the-gas-consumption-of-your-smart-contracts-9a506b339c0a) -- [A proof-of-stake és a proof-of-work összehasonlítása](https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/) -- [Gázoptimalizáló stratégiák fejlesztők számára](https://www.alchemy.com/overviews/solidity-gas-optimization) -- [EIP-1559-dokumentumok](https://eips.ethereum.org/EIPS/eip-1559). -- [Tim Beiko EIP-1559 forrásai](https://hackmd.io/@timbeiko/1559-resources). diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/index.md deleted file mode 100644 index 5b5b808dd9e..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/index.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Ethereum-fejlesztési dokumentáció -description: Bevezetés az ethereum.org fejlesztői dokumentációjába. -lang: hu ---- - -Ezt a dokumentációt arra tervezték, hogy segítsen az Ethereumon való fejlesztésben. Bemutatja az Ethereumot, mint koncepciót, elmagyarázza az Ethereum tech stacket, és áttekintést nyújt a haladó témákról és a komplexebb alkalmazásokról használati esetek segítségével. - -Ez egy nyílt forráskódú közösségi kezdeményezés, így nyugodtan javasolhat új témákat, hozzáadhat új tartalmat és példákat adhat meg, ahol úgy érzi, hogy hasznos lehet. Az összes dokumentáció szerkeszthető a GitHub-on – csak [kövesse az instrukciókat](https://github.com/ethereum/ethereum-org-website/blob/dev/docs/editing-markdown.md). - -## Fejlesztési modulok {#development-modules} - -Ha most először fejleszt az Ethereumon, akkor azt javasoljuk, hogy kezdje a legelején, és olvassa végig, mint egy könyvet. - -### Alapvető témák {#foundational-topics} - - - -### Ethereum stack {#ethereum-stack} - - - -### Speciális {#advanced} - - diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ether/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ether/index.md deleted file mode 100644 index 12b283273ac..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ether/index.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: Bevezetés az ether világába -description: Bevezetés fejlesztőknek az ether kriptovalutába. -lang: hu ---- - -## Előfeltételek {#prerequisites} - -Ennek az oldalnak a jobb megértése érdekében javasoljuk, hogy először olvassa el a [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) oldalunkat. - -## Mi az a kriptovaluta? {#what-is-a-cryptocurrency} - -A kriptovaluta a csere eszköze, amelyet egy blokkláncalapú főkönyv biztosít. - -A csere eszköze bármi lehet, amit széles körben elfogadnak az áruk és szolgáltatások kifizetésére, a főkönyv pedig egy adattároló, ahol a tranzakciókat követik. A blokklánc-technológia lehetővé teszi a felhasználóknak, hogy tranzakciókat végezzenek a főkönyvön, anélkül hogy egy harmadik félben kellene megbízniuk, aki a főkönyvet kezeli. - -Az első kriptovaluta a Bitcoin volt, amelyet Satoshi Nakamoto hozott létre. A Bitcoin 2009-es elindulása óta az emberek ezernyi kriptovalutát hoztak létre számos különféle blokkláncon. - -## Mi az ether? {#what-is-ether} - -**Ether (ETH)** a kriptovaluta, amelyet számtalan dologra használnak az Ethereum hálózaton. Alapvetően ez az egyetlen elfogadott fizetési eszköz a tranzakciódíjakhoz, és a [Beolvadás](/roadmap/merge) után ether kell ahhoz, hogy blokkot javasoljanak és validáljanak a főhálózaton. Az ether emellett az elsődleges fedezet a [decentralizált pénzügyek (DeFi)](/defi) kölcsönzési piacain, az NFT (nem helyettesíthető token) piactereken könyvelési egység, fizetség a szolgáltatások nyújtásakor vagy termékeladáskor és még sok más esetben. - -Az Ethereum lehetővé teszi a fejlesztők számára, hogy [**decentralizált alkalmazásokat (dapp)**](/developers/docs/dapps) hozzanak létre, amely ugyanazt a számítási kapacitást használja. Ez egy véges kapacitás, ezért az Ethereumnak szüksége van egy olyan mechanizmusra, amellyel megállapítható, hogy ki használja fel azt. Máskülönben egy alkalmazás véletlenül vagy rosszhiszeműen fel tudná használni a hálózat összes erőforrását, így mások nem férnének ahhoz hozzá. - -Az ether kriptovaluta segíti az árazási mechanizmust az Ethereum számítógépes kapacitására vonatkozóan. Amikor a felhasználó tranzakciót akar indítani, ethert kell fizetnie, hogy ez a tranzakció bekerülhessen a blokkláncra. Ezt a felhasználói költséget [gázdíjnak (tranzakciós díj)](/developers/docs/gas/) nevezik, ami pedig attól függ, hogy az adott tranzakció végrehajtásához mennyi kapacitásra van szükség, illetve ugyanabban az időben mennyire van kereslet. - -Ezért még ha egy rosszindulatú dapp egy végtelen körforgást indítana is el, a tranzakció végül kifogyna az etherből és leállna, így a hálózat visszatér a normális állapotba. - -[Gyakori az, hogy összekapcsolják](https://abcnews.go.com/Business/bitcoin-slumps-week-low-amid-renewed-worries-chinese/story?id=78399845) az Ethereumot és az ethert – amikor az emberek az Ethereum árára gondolnak, akkor az ethernek az árát értik alatta. - -## Az ether létrehozása (minting) {#minting-ether} - -A minting az a folyamat, amikor új ethert hoznak létre az Ethereum főkönyvön. A mögöttes Ethereum protokoll kreálja az új ethert, a felhasználók nem tudnak ilyet tenni. - -Az ether minden javasolt blokk jutalmaként keletkezik, illetve minden korszakban azért a validátori tevékenységért jár, ami a konszenzus létrehozását adja. A teljes kiadott összeg függ a validátorok számától, és hogy ők mennyi ethert helyeztek letétbe. Ez a teljes kiadás ideális esetben egyenlően oszlik el a validátorok között az, mivel minden validátor jóhiszemű és online van, de a valóságban változik a validátor teljesítménye alapján. A blokkjavasló a kiadott összeg 1/8-át kapja meg, a többi eloszlik a többi validátor között. A blokkjavasló emellett még borravalót kap a tranzakciós díjból és MEV-hez (maximálisan kinyerhető érték) kapcsolódó bevételt, ez azonban az újrahasznált etherből ered, nem az újból. - -## Az ether elégetése {#burning-ether} - -Ahogy új ether keletkezik a blokkhoz kapcsolódó jutalmak következtében, úgy meg is szűnik, amit elégetésnek nevezünk. Amikor az ethert elégetik, az örökre kivonódik a körforgásból. - -Ez minden tranzakciónál megtörténik az Ethereumon. Amikor a felhasználó fizet a tranzakcióért, akkor az alap gázdíj, amit a kereslet alapján állapít meg a rendszer, megsemmisül. Ez megkönnyíti a tranzakciós illeték becslését az Ethereumon, tekintve, hogy a blokkméretek változóak és van egy maximális gázdíj. Amikor nagy a kereslet a hálózaton, akkor a [blokkok](https://etherscan.io/block/12965263) több ethert égetnek el, mint amennyit létrehoznak, tehát ellentételezik a kibocsátást. - -Az alapdíj elégetése megakadályozza, hogy a blokk-készítők manipulálják a tranzakciókat. Például, ha egy blokk-készítő megkapná az alapdíjat, akkor a saját tranzakcióit ingyen tehetné be, míg a többiek díját megemelné. Alternatívaként vissza lehetne adni az alapdíjat a felhasználóknak láncon kívül, ami egy homályosabb és komplexebb tranzakciósilleték-piachoz vezetne. - -## Az ether címletei {#denominations} - -Mivel számos tranzakció értéke az Ethereumon viszonylag kicsi, ezért az ether számos címlettel bír, amelyek kisebb egységek. Ezekből a wei és a gwei a legfontosabbak. - -Wei a legkisebb címlet, ezért sok technikai bevezetés, mint az [Ethereum Sárga könyv](https://ethereum.github.io/yellowpaper/paper.pdf) minden kalkulációt ebben végez. - -Gwei vagyis giga wei általában a gázdíj meghatározásában jelenik meg az Ethereumon. - -| Címlet | Érték etherben | Gyakori használat | -| ------ | ---------------- | ---------------------------------- | -| Wei | 10-18 | Technikai implementáció | -| Gwei | 10-9 | A felhasználóknak érthető gázdíjak | - -## Az ether küldése {#transferring-ether} - -Az Ethereumon minden tranzakció tartalmaz egy `value` (érték) mezőt, ami az elküldendő ether összegét mutatja wei címletben, hogy a küldő címéről a fogadó címére érkezzen. - -Amikor a fogadó címe egy [okosszerződés](/developers/docs/smart-contracts/), akkor ezt az elküldött ethert a gázdíjak fizetésére is használhatják, amikor az okosszerződés végrehajtja a programkódját. - -[Bővebben a tranzakciókról](/developers/docs/transactions/) - -## Az ether-egyenleg lekérdezése {#querying-ether} - -A felhasználók bármelyik [számla](/developers/docs/accounts/) egyenlegét meg tudják nézni az adott számla `balance` (egyenleg) mezőjében, ami az ott lévő ethert weiben mutatja. - -Az [Etherscan](https://etherscan.io) egy népszerű eszköz arra, hogy egy webalapú alkalmazásban megnézhessék egy adott cím egyenlegét. Például [ez az Etherscan oldal](https://etherscan.io/address/0xde0b295669a9fd93d5f28d9ec85e40f4cb697bae) megmutatja az Ethereum Alapítvány egyenlegét. A számlaegyenlegeket a tárcák lekérdezésével vagy a csomópontokon közvetlenül is meg lehet nézni. - -## További olvasnivaló {#further-reading} - -- [Az Ether és az Ethereum meghatározása](https://www.cmegroup.com/education/courses/introduction-to-ether/defining-ether-and-ethereum.html) – _CME Group_ -- [Ethereum fehérkönyv](/whitepaper/): Az eredeti javaslat az Ethereum megalkotására. A jelen dokumentum az ether lényegét és a kialakításának célját írja le. -- [Gwei-kalkulátor](https://www.alchemy.com/gwei-calculator): Használja ezt a gwei-kalkulátort, hogy könnyedén váltson wei, gwei és ether címleteket. Egyszerűen adja meg az összeget weiben, gweiben vagy ETH-ban, és automatikusan kiszámolja az átváltást. - -_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md deleted file mode 100644 index 8f4502e2801..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/intro-to-ethereum/index.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: Bevezetés az Ethereumba -description: A dapp fejlesztője bemutatja az Ethereum alapfogalmait. -lang: hu ---- - -## Mi az a blokklánc? {#what-is-a-blockchain} - -A blokkláncot legjobban úgy lehet leírni, mint egy nyilvános adatbázist, melyet frissítenek és megosztanak egy számítógépes hálózaton. - -A "blokk" arra utal, hogy az adat és az állapot szekvenciális adagokban vagy "blokkokban" van tárolva. Ha ETH-t küld valakinek, akkor a tranzakciós adatot hozzá kell adni egy blokkhoz, hogy végrehajtásra kerüljön. - -A "lánc" arra a tényre utal, hogy minden egyes blokk kriptográfiailag hozzá van rendelve a szülő blokkjához. Tehát a blokkok össze vannak kötve. Egy blokk adatát nem lehet megváltoztatni anélkül, hogy megváltoztatnánk az összes későbbi blokkot, amely a teljes hálózat konszenzusát igényelné. - -A hálózat minden számítógépének meg kell egyeznie minden új blokkon és az egész láncon. Ezeket a számítógépeket úgy ismerjük, mint csomópontok. A csomópontok biztosítják, hogy mindenki számára ugyanaz az adat. Ahhoz, hogy ezt az elosztott megegyezést teljesítse, a blokkláncoknak szükségük van konszenzusmechanizmusra. - -Az Ethereum [proof-of-stake alapú konszenzusmechanizmust](/developers/docs/consensus-mechanisms/pos/) használ. Aki új blokkot akar adni a lánchoz, annak le kell kötnie ETH-t – az Ethereum saját valutáját – fedezetként, és futtatniuk kell a validátor szoftvert. Ezen validátorok közül véletlenszerűen választják ki a blokkot javaslót, amelyet a többi validátor ellenőriz és hozzáad a lánchoz. Jutalmak és büntetések rendszere ösztönzi a résztvevőket a jóhiszemű viselkedésre és arra, hogy online legyenek. - -Ha szeretné látni, hogy a blokklánc adat hogyan hashelődik és azután hogyan adódik hozzá a blokkreferenciák történetéhez, akkor nézze meg [ezt a bemutatót](https://andersbrownworth.com/blockchain/blockchain) Anders Brownworth narrálásával, illetve az alábbi videót. - -Nézze meg, ahogy Anders elmagyarázza a hasheket a blokkláncban: - - - -## Mi az Ethereum? {#what-is-ethereum} - -Az Ethereum egy blokklánc egy beágyazott számítógéppel. Alapot szolgáltat alkalmazások és szervezetek számára egy decentralizált, engedélymentes és cenzúrának ellenálló módon. - -Az Ethereum univerzumban van egy kanonikus számítógép (melyet Ethereum Virtuális Gépnek vagy EVM-nek hívnak), amelynek állapota felett mindenki egyetért a hálózaton. Mindenki, aki részt vesz az Ethereum hálózatban (minden Ethereum-csomópont) egy másolattal rendelkezik ennek a számítógépnek az állapotáról. Ezen kívül bármely résztvevő közvetíthet kéréseket ehhez a számítógéphez, hogy tetszőleges számításokat hajtsanak végre. Amikor egy ilyen kérést közvetítenek, a többi résztvevő a hálózaton hitelesíti, validálja és véghez viszi (lefuttatja) a számítást. Ez állapotváltozást okoz az EVM-ben, amelyet a teljes hálózatban elköteleznek és tovább terjesztenek. - -A számítási kérelmeket tranzakciós kérelmeknek nevezzük; az összes tranzakció bejegyzését, valamint az EVM jelenlegi állapotát a blokklánc tárolja, amelyet viszont minden csomópont tárol és elfogad. - -A kriptográfiai mechanizmusok biztosítják, hogy az ellenőrzött és a blokklánchoz hozzáadott tranzakciók később nem változtathatók meg. Ugyanazok a mechanizmusok biztosítják azt is, hogy az összes tranzakciót megfelelő engedélyekkel írják alá és hajtják végre (senki ne legyen képes digitális eszközök küldésére Alice számlájáról, kivéve magát Alice-t). - -## Mi az ether? {#what-is-ether} - -**Ether (ETH)** az Ethereum saját kriptovalutája. Az ETH célja, hogy a számítási kapacitásért fizetni lehessen. Egy ilyen piac gazdasági ösztönzőt biztosít a résztvevőknek, hogy hitelesítsék/végrehajtsák a tranzakciós kérelmeket és, hogy számítási kapacitást szolgáltassanak a hálózatnak. - -A résztvevők a tranzakcióért jutalomként felajánlanak ETH-t a hálózatnak. A hálózat elégeti a jutalom egy részét és díjazza azokat, akik végül elvégzik a tranzakció ellenőrzését, végrehajtását, a blokkláncba való beillesztését és a hálózatba történő közvetítését. - -Az ETH összege a számítási kapacitáshoz kapcsolódik. Ezek a jutalmak megakadályozzák a rosszindulatú résztvevőket is abban, hogy szándékosan eltömítsék a hálózatot azzal, hogy végtelen ciklusokat vagy erőforrásigényes szkriptek végrehajtását kérik, mivel ezeknek a szereplőknek fizetni kell a kalkulációért. - -Az ETH-t arra is használják, hogy kriptogazdasági biztonságot adjon a hálózatnak három módon: 1) a validátorok jutalmat kapnak, hogy blokkot javasolnak vagy kiszűrik a rosszhiszemű viselkedést; 2) a validátorok letétbe helyezik fedezetként a rosszhiszemű viselkedés elkerülése érdekében (csalás esetén az ETH megsemmisül); 3) a szavazatok súlyozására használják az újonnan javasolt blokkoknál, a konszenzusmechanizmus elágazási pontjához kapcsolódóan. - -## Mi az az okosszerződés? {#what-are-smart-contracts} - -A gyakorlatban a résztvevők nem írnak minden alkalommal új kódot, amikor számítást kérelmeznek az EVM-től. Ehelyett az alkalmazásfejlesztők programokat (újrafelhasználható kódrészleteket) töltenek fel az EVM tárhelyére, majd a felhasználók kérik, hogy ezeket a kódrészleteket lefuttassák változó paraméterekkel. A feltöltött és a hálózat által végrehajtott programokat okosszerződéseknek hívjuk. - -Úgy is elképzelheti ezeket az okosszerződéseket, mint egyfajta ételautomata: egy szkript, amelyet ha meghívnak bizonyos paraméterekkel, végrehajt valamilyen akciót vagy számítást, ha bizonyos feltételek teljesülnek. Például egy egyszerű árusító okosszerződés létrehozhatná és átruházhatná egy digitális eszköz tulajdonjogát, ha a hívó fél ETH-t küld egy bizonyos címzettnek. - -Bármely fejlesztő írhat egy okosszerződést és teheti nyilvánossá a hálózat számára úgy, hogy a blokkláncot egy adat rétegként használja a hálózatnak fizetett díj ellenében. Bármely felhasználó meghívhatja az okosszerződést és végrehajthatja a kódját szintén valamekkora díj ellenében. - -Ezáltal az okosszerződésekkel a fejlesztők tetszőlegesen bonyolult felhasználó oldali alkalmazásokat és szolgáltatásokat fejleszthetnek és telepíthetnek: piactereket, pénzügyi eszközöket, játékokat stb. - -## Terminológia {#terminology} - -### Blokklánc {#blockchain} - -Az összes blokk sorozata, amely elköteleződött az Ethereum hálózaton a hálózati történetben. A név onnan származik, hogy minden egyes blokk tartalmaz egy referenciát az előző blokkra, amely segít fenntartani egy sorrendet a összes blokk között (így egy pontos történetet is). - -### ETH {#eth} - -**Ether (ETH)** az Ethereum saját kriptovalutája. A felhasználók más felhasználóknak ETH-t fizetnek, hogy teljesítsék a kód végrehajtási kérelmeiket. - -[Többet az ETH-ről](/developers/docs/intro-to-ether/) - -### EVM {#evm} - -Az Ethereum Virtuális Gép egy globális számítógép, amelynek állapota felett az Ethereum-hálózat minden résztvevője tárol és egyet ért. Bármely résztvevő kérelmezheti valamilyen tetszőleges kód végrehajtását az EVM-en; a kód végrehajtás megváltoztatja az EVM állapotát. - -[További tudnivalók az EVM-ről](/developers/docs/evm/) - -### Csomópontok {#nodes} - -A valódi gépek, amelyek az EVM állapotot tárolják. A csomópontok kommunikálnak egymással, hogy információkat terjesszenek az EVM állapotáról és az új állapotváltozásokról. Bármely felhasználó kérheti a kód végrehajtását azáltal is, hogy kód végrehajtási kérelmet közvetít egy csomópontból. Az Ethereum hálózat az összes Ethereum csomópont és a kommunikációjuk összessége. - -[Többet a csomópontokról](/developers/docs/nodes-and-clients/) - -### Számlák {#accounts} - -Ahol az ETH tárolódik. A felhasználók indíthatnak számlákat, ETH-t helyezhetnek el a számlákon, és utalhatnak át a számlájukról más felhasználóknak. A számlák és a számla egyenlegek egy nagy táblában vannak eltárolva az EVM-ben; a teljes EVM állapot részei. - -[További tudnivalók a számlákról](/developers/docs/accounts/) - -### Tranzakciók {#transactions} - -A tranzakciós kérelem egy formális kifejezés a kód végrehajtási kérelemre az EVM-en, a tranzakció pedig egy teljesített tranzakciós kérelem és a hozzárendelt változás az EVM állapotában. Bármely felhasználó közvetíthet tranzakciós kérelmet a hálózatra egy csomópontból. Ahhoz, hogy a tranzakciókérelemnek valóban legyen hatása az elfogadott EVM-állapot felett, először validálni kell, végre kell hajtani és komittálni kell a hálózatra egy másik csomópont által. Bármely kód végrehajtása állapotváltozást okoz az EVM-ben; elkötelezettséggel ez az állapotváltozás a hálózat minden csomópontjához eljut. Néhány tranzakció példa: - -- Küldjön X ETH-t a számlámról Alice számlájára. -- Publikáljon egy okosszerződéses kódot az EVM státuszba. -- Hajtsd végre az okosszerződés kódot az X címen az EVM-ben Y paraméterekkel. - -[Többet a tranzakciókról](/developers/docs/transactions/) - -### Blokkok {#blocks} - -A tranzakciók száma nagyon magas, így a tranzakciókat adagokban vagy blokkokban „kötelezzük el”. A blokkok általában több tucat vagy több száz tranzakciót tartalmaznak. - -[További tudnivalók a blokkokról](/developers/docs/blocks/) - -### Okosszerződések {#smart-contracts} - -Egy újra felhasználható kódrészlet (egy program), amelyet egy fejlesztő publikál az EVM státuszba. Bárki kérheti az okosszerződéses kód végrehajtását egy tranzakciós kérelemmel. Mivel a fejlesztők tetszőlegesen végrehajtható alkalmazásokat írhatnak az EVM-be (játékokat, piactereket, pénzügyi eszközöket stb.) okosszerződések publikálásával, ezért gyakran hívjuk ezeket [dappoknak, vagy decentralizált alkalmazásoknak](/developers/docs/dapps/). - -[Többet az okos szerződésekről](/developers/docs/smart-contracts/) - -## További olvasnivaló {#further-reading} - -- [Ethereum fehérkönyv](/whitepaper/) -- [Amúgy hogyan működik az Ethereum?](https://medium.com/@preethikasireddy/how-does-ethereum-work-anyway-22d1df506369) - _Preethi Kasireddy_ (**Megjegyzés:** bár ez a forrás még mindig értékes, de a [Beolvadás](/roadmap/merge) előtti, és ezért az említett proof-of-work mechanizmus helyett az Ethereum már [proof-of-stake](/developers/docs/consensus-mechanisms/pos)-et használ) - -_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ - -## Kapcsolódó útmutatók {#related-tutorials} - -- [Egy fejlesztő útmutatása az Ethereumba 1. rész](/developers/tutorials/a-developers-guide-to-ethereum-part-one/) _– Az Ethereum nagyon kezdőbarát felfedezése Python és web3.py használatával_ diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/networks/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/networks/index.md deleted file mode 100644 index 7412237f931..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/networks/index.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -title: Hálózatok -description: Egy áttekintő az Ethereum hálózatairól és hogy hol lehet tesztnet ethert (ETH) szerezni, hogy teszteld az alkalmazásaidat. -lang: hu ---- - -Az Ethereum-hálózatok olyan összekapcsolt számítógépek csoportjai, amelyek az Ethereum-protokoll segítségével kommunikálnak. Egyetlen Ethereum főhálózat létezik, de ugyanazt a protokollt használó, független hálózatokat is létre lehet hozni tesztelési és fejlesztési célból. Számos ilyen független hálózat létezik, amelyek a protokollt követik, de nem kommunikálnak egymással. Akár a saját számítógépén is létrehozhat egyet, hogy egy okosszerződést vagy egy web3 alkalmazást teszteljen. - -Ethereum-számlája működni fog a különböző hálózatokon, de a számlaegyenlege és a tranzakciós előzmények nem kerülnek át az Ethereum fő hálózatából. Tesztelési célból hasznos tudni, hogy amely hálózatok állnak rendelkezésre, és hogy hogyan szerezhet egy teszthálózat ETH-t, amivel kipróbálhat dolgokat. Biztonsági okokból nem javasolt olyan számla használata a teszthálózaton, amely a főhálózathoz tartozik és fordítva. - -## Előfeltételek {#prerequisites} - -Érdemes tisztában lennie az [Ethereum alapjaival](/developers/docs/intro-to-ethereum/), mielőtt a különböző hálózatokról olvas, mivel ezek a teszthálózatok az Ethereum olcsó és biztonságos verziói, amelyekkel ki lehet próbálni dolgokat. - -## Nyilvános hálózatok {#public-networks} - -A nyilvános hálózatokat bárki elérheti szerte a világban egy internetkapcsolattal. Bárki olvashat és indíthat tranzakciókat egy nyilvános blokkláncon és hitelesítheti a tranzakciók végrehajtását. A tagok közötti konszenzus dönti el az új tranzakciók bedolgozását és a hálózat státuszát. - -### Ethereum-főhálózat {#ethereum-mainnet} - -A főhálózat az elsődleges nyilvános Ethereum produkciós blokklánc, ahol valós értékű tranzakciók történnek az elosztott főkönyvön. - -Amikor az emberek és tőzsdék az ETH árfolyamon vitatkoznak, akkor a főhálózati ETH-ről beszélnek. - -### Ethereum-teszthálózatok {#ethereum-testnets} - -A főhálózat mellett vannak nyilvános tesztnetek. Ezeket a hálózatokat a protokoll fejlesztők vagy az okosszerződések fejlesztői használják, hogy teszteljék mind a protokoll frissítéseket, és a lehetséges okosszerződéseket egy produkciószerű környezetben a főhálózatba történő telepítés előtt. Úgy is gondolhatsz rá, mint a produkciós és a staging szerver analógiájára. - -Általában fontos, hogy le legyen tesztelve egy teszthálózatra írt szerződéses kód, mielőtt a főhálózatra telepítenénk. Azoknál az alkalmazásoknál, ahol már meglévő okosszerződéssel kell kapcsolódni, a legtöbb projekt ezeknek a másolatát átteszi a teszthálózatra. - -A legtöbb teszthálózat úgy indul, hogy egy engedélyezett proof-of-authority konszenzusmechanizmust használ. Ez azt jelenti, hogy a csomópontok egy kis csoportja van kiválasztva a tranzakciók validálására és új blokkok létrehozására - az identitásukat helyezik letétbe a folyamat alatt. Alternatívaként néhány teszthálózat egy nyitott proof-of-stake konszenzusmechanizmust vezet be, ahol mindenki futtathat validátort, ahogy az Ethereum főhálózaton is működik. - -A teszthálózathoz tartozó ETH-nak elvileg nincs valós értéke. Ugyanakkor a ritka vagy nehezen megszerezhető teszthálózati ETH-nek mégis kialakulhat valamilyen piaca. Mivel ETH-re van szükség, hogy ténylegesen interakcióba lépjen az Ethereummal (még a teszthálózaton is), a legtöbb ember csapokból szerzi a teszthálózati ETH-t. A legtöbb csap egy web alkalmazás, ahol beírhatja a címét, amire ETH-t szeretne kapni. - -#### Melyik teszthálózatot használja? - -A két nyilvános teszthálózat, amelyet a kliens fejlesztők jelenleg fenntartanak a Sepolia és a Goerli. Sepolia egy hálózat a szerződés- és alkalmazásfejlesztők számára, ahol az alkalmazásaikat tesztelhetik. A Goerli-hálózat a protokollfejlesztőknek biztosít teret frissítéseik teszteléséhez, illetve a letétbe helyezőknek a validátorok futtatásához. - -#### Sepolia {#sepolia} - -**a Sepolia az ajánlott teszthálózat az alkalmazásfejlesztők számára.**. A Sepolia-hálózat egy engedélyezett validátorszettet használ. Viszonylag új, tehát kevés státusz és előzmény található rajta. Ezért gyorsan tud szinkronizálni, a csomópont futtatása pedig kevesebb tárhelyet igényel. Ez hasznos azoknak, akik gyorsan fel akarnak állítani egy csomópontot és közvetlenül kapcsolódni a hálózattal. - -- Zárt validátorszett, amelyet a kliensek és a tesztelő csapatok irányítanak -- Új teszthálózat, amelyre kevesebb alkalmazás van telepítve -- Gyorsan szinkronizál és kevesebb tárhely kell a csomópont futtatáshoz - -##### Források - -- [Honlap](https://sepolia.dev/) -- [GitHub](https://github.com/eth-clients/sepolia) -- [Otterscan](https://sepolia.otterscan.io/) -- [Etherscan](https://sepolia.etherscan.io) -- [Blockscout](https://eth-sepolia.blockscout.com/) - -##### Csapok - -- [QuickNode Sepolia csap](https://faucet.quicknode.com/drip) -- [Grabteeth](https://grabteeth.xyz/) -- [PoW csap](https://sepolia-faucet.pk910.de/) -- [Coinbase Wallet csap | Sepolia](https://coinbase.com/faucets/ethereum-sepolia-faucet) -- [Alchemy Sepolia csap](https://sepoliafaucet.com/) -- [Infura Sepolia csap](https://www.infura.io/faucet) -- [Chainstack Sepolia csap](https://faucet.chainstack.com/sepolia-faucet) -- [Ethereum-ökoszisztéma csap](https://www.ethereum-ecosystem.com/faucets/ethereum-sepolia) - -#### Goerli _(hosszútávú támogatás)_ {#goerli} - -_Megjegyzés: [a Goerli teszthálózat lezárásra kerül](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) és a [Holesovice](https://github.com/eth-clients/holesovice) veszi át a helyét 2023-ban. Kérjük, hogy vigye át az alkalmazásait a Sepolia hálózatra._ - -A Goerli egy olyan teszthálózat, ahol a validálást és a letétbe helyezést lehet tesztelni. A Goerli hálózat minden olyan felhasználók számára elérhető, aki teszthálózati validátort szeretne futtatni. Ezt használhatják azok a letétesek is, akik tesztelni akarják a protokollfrissítéseket, mielőtt azok a főhálózatra kerülnének. - -- Nyitott validátorszett, a letétesek tesztelhetik a hálózati frissítéseket -- Sok státusz elérhető, ezért alkalmas az okosszerződések komplex interakcióit letesztelni -- Hosszabb ideig tart a szinkronizálás és több tárhely kell a csomópont futtatáshoz - -##### Erőforrások - -- [Honlap](https://goerli.net/) -- [GitHub](https://github.com/eth-clients/goerli) -- [Etherscan](https://goerli.etherscan.io) -- [Blockscout](https://eth-goerli.blockscout.com/) - -##### Csapok - -- [QuickNode Goerli csap](https://faucet.quicknode.com/drip) -- [Grabteeth](https://grabteeth.xyz/) -- [PoW csap](https://goerli-faucet.pk910.de/) -- [Paradigm csap](https://faucet.paradigm.xyz/) -- [Alchemy Goerli csap](https://goerlifaucet.com/) -- [All That Node Goerli csap](https://www.allthatnode.com/faucet/ethereum.dsrv) -- [Coinbase Wallet csap | Goerli](https://coinbase.com/faucets/ethereum-goerli-faucet) -- [Chainstack Goerli csap](https://faucet.chainstack.com/goerli-faucet) - -Ha szeretne egy validátort indítani a Holesky teszthálózaton, akkor használja az ethstaker [„olcsó Holesky validátor” indítópultot](https://holesky.launchpad.ethstaker.cc/en/). - -### Második blokkláncréteg (L2) teszthálózatok {#layer-2-testnets} - -[A második blokkláncréteg (L2)](/layer-2/) az Ethereum skálázási megoldásait takarja. Az L2 egy elkülönült blokklánc, ami kiterjeszti az Ethereumot, örökölve annak biztonsági garanciáit. Az L2 teszthálózatok szorosan kapcsolódnak a nyilvános Ethereum teszthálózatokhoz. - -#### Arbitrum Goerli {#arbitrum-goerli} - -Teszthálózat az [Arbitrum-hoz](https://arbitrum.io/). - -##### Csapok - -- [Chainlink csap](https://faucets.chain.link/) - -#### Optimistic Goerli {#optimistic-goerli} - -Teszthálózat az [Optimism-hoz](https://www.optimism.io/). - -##### Csapok - -- [Paradigm csap](https://faucet.paradigm.xyz/) -- [Coinbase Wallet csap | Optimism Goerli](https://coinbase.com/faucets/optimism-goerli-faucet) - -#### Starknet Goerli {#starknet-goerli} - -Teszthálózat a [Starknethez](https://www.starknet.io). - -##### Csapok - -- [Starknet csap](https://faucet.goerli.starknet.io) - -## Privát hálózatok {#private-networks} - -Egy Ethereum hálózat privát, ha a csomópontok nem kapcsolódnak egy nyilvános hálózathoz (vagyis a főhálózathoz vagy egy teszthálózathoz). Ebben a kontextusban a privát azt jelenti, hogy elszigetelt és fenntartott, nem pedig azt, hogy védett vagy biztonságos. - -### Fejlesztői hálózatok {#development-networks} - -Egy Ethereum alkalmazás fejlesztésekor fontos, hogy egy privát hálózaton futtassa, hogy megnézze, hogyan működik telepítés előtt. Hasonlóan ahhoz, amikor egy lokális szervert futtat a számítógépén webfejlesztés céljából, egy lokális blokklánc-példányt is futtathat, ahol tesztelheti a dappot. Ez gyorsabb iterációt tesz lehetővé, mint egy nyilvános tesztnet. - -Vannak olyan projektek és eszközök, amelyek ebben segítenek. Tudjon meg többet a [fejlesztői hálózatokról](/developers/docs/development-networks/). - -### Konzorciumhálózatok {#consortium-networks} - -Egy konszenzus folyamatot néhány előre meghatározott megbízható csomópont végzi. Például egy ismert tudományos intézmények magánhálózata, amelyek mindegyike egyetlen csomópontot irányít, és a blokkokat az aláírók küszöbértéke érvényesíti a hálózaton belül. - -Ha egy nyilvános Ethereum hálózat olyan, mint a nyilvános internet, akkor úgy gondoljon a konzorcium hálózatra, mint egy privát intranetre. - -## Kapcsolódó eszközök {#related-tools} - -- [Chainlist](https://chainlist.org/) _– az EVM-hálózatok listája, hogy a tárcákat és a szolgáltatókat a megfelelő Chain ID és Network ID segítségével kapcsolják be_ -- [EVM-alapú láncok](https://github.com/ethereum-lists/chains) _– GitHub könyvtár a lánc metaadatokból, amelyek a Chainlisten megjelennek_ - -## További olvasnivaló {#further-reading} - -- [Javaslat: kiszámítható Ethereum teszthálózati életciklus](https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575/17) -- [Az Ethereum teszthálózatok evolúciója](https://etherworld.co/2022/08/19/the-evolution-of-ethereum-testnet/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/transactions/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/transactions/index.md deleted file mode 100644 index a2b0532b580..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/transactions/index.md +++ /dev/null @@ -1,221 +0,0 @@ ---- -title: Tranzakciók -description: Egy áttekintő az Ethereum tranzakciókról – hogyan működnek, az adatszerkezetük és hogyan lehet őket elküldeni egy alkalmazáson keresztül. -lang: hu ---- - -A tranzakciók számlákból származó kriptográfiailag aláírt instrukciók. Egy számla tranzakciót indíthat, hogy frissítse az Ethereum hálózat állapotát. A legegyszerűbb tranzakció az ETH átutalása egyik számláról a másikra. - -## Előfeltételek {#prerequisites} - -Ennek az oldalnak a jobb megértése érdekében javasoljuk, hogy először a [Számlák](/developers/docs/accounts/) és a [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) című cikkeinket olvassa el. - -## Mi az a tranzakció? {#whats-a-transaction} - -Az Ethereum-tranzakció egy külső tulajdonú számla által kezdeményezett tevékenységre utal, más szóval egy számla, amelyet egy ember, nem pedig egy szerződés kezel. Például, ha Bob elküld Alice-nek 1 ETH-t, akkor Bob számláját terhelni kell, Alice számlájára pedig jóvá kell írni az összeget. Ez az állapotot megváltoztató művelet egy tranzakción belül történik. - -![Diagram, amely egy állapotot módosító tranzakciót ábrázol](./tx.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból - -Az EVM állapotát megváltoztató tranzakciókat a teljes hálózat számára közvetíteni kell. Bármely csomópont kérvényezheti egy tranzakció végrehajtását az EVM-en; miután ez megtörténik, egy validátor végrehajtja a tranzakciót és továbbterjeszti az eredményül kapott állapotot a hálózat többi része számára. - -A tranzakciókért fizetni kell, és be kell kerüljenek egy validált blokkba. Hogy egyszerűbb legyen ez az áttekintés, a gázdíjak és a validáció témaköröket máshol taglaljuk. - -Az elküldött tranzakció a következő információkat tartalmazza: - -- `from` – a küldő címe, aki aláírja a tranzakciót. Ez egy külső tulajdonú számla, mivel a szerződéses számlák nem küldenek tranzakciót. -- `to` – a fogadó címe (ha egy külső tulajdonú számla, akkor a tranzakció értéket továbbít. Ha egy szerződéses számla, akkor a tranzakció szerződéskódot fog végrehajtani) -- `signature` – a küldő azonosítója. Ez akkor jön létre, amikor a feladó privát kulcsa aláírja a tranzakciót, és megerősíti, hogy a küldő engedélyezte ezt a tranzakciót -- `nonce` – egy növekvő számláló, amely a számláról küldött tranzakciók számát mutatja -- `value` – az átküldendő ETH mennyisége a küldőtől a címzettnek (WEI-ben, ahol 1 ETH 1e+18 wei-nek felel meg) -- `input data` – opcionális mező tetszőleges adatok megadására -- `gasLimit` – a maximális gáz mennyisége, amelyet a tranzakció elfogyaszthat. Az [EVM](/developers/docs/evm/opcodes) határozza meg a számítási lépésekhez szükséges gázmennyiségét -- `maxPriorityFeePerGas` – az elfogyasztott gáz maximális ára, amely a validátor által kapott borravaló részét képezi -- `maxFeePerGas` – a gázegységért fizethető maximális díj, amit a tranzakcióért kifizetnek (beleértve a `baseFeePerGas` és a `maxPriorityFeePerGas` értékét is) - -A gáz a tranzakció feldolgozásához szükséges számításért jár, amelyet a validátor feldolgoz. A felhasználóknak díjat kell fizetniük ezért a számításért. A `gasLimit` és a `maxPriorityFeePerGas` meghatározza a validátornak fizetett maximális tranzakciós illetéket. [Bővebben a gázról](/developers/docs/gas/). - -A tranzakcióobjektum nagyjából így néz ki: - -```js -{ - from: "0xEA674fdDe714fd979de3EdF0F56AA9716B898ec8", - to: "0xac03bb73b6a9e108530aff4df5077c2b3d481e5a", - gasLimit: "21000", - maxFeePerGas: "300", - maxPriorityFeePerGas: "10", - nonce: "0", - value: "10000000000" -} -``` - -De a tranzakcióobjektumot alá kell írni a küldő privát kulcsával. Ez bizonyítja, hogy a tranzakció kizárólag a küldőtől jöhetett, és nem történt csalás. - -Egy Ethereum-kliens, mint a Geth, fogja kezelni az aláírási folyamatot. - -Példa egy [JSON-RPC](/developers/docs/apis/json-rpc)-hívásra: - -```json -{ - "id": 2, - "jsonrpc": "2.0", - "method": "account_signTransaction", - "params": [ - { - "from": "0x1923f626bb8dc025849e00f99c25fe2b2f7fb0db", - "gas": "0x55555", - "maxFeePerGas": "0x1234", - "maxPriorityFeePerGas": "0x1234", - "input": "0xabcd", - "nonce": "0x0", - "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", - "value": "0x1234" - } - ] -} -``` - -Példa válasz: - -```json -{ - "jsonrpc": "2.0", - "id": 2, - "result": { - "raw": "0xf88380018203339407a565b7ed7d7a678680a4c162885bedbb695fe080a44401a6e4000000000000000000000000000000000000000000000000000000000000001226a0223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20ea02aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", - "tx": { - "nonce": "0x0", - "maxFeePerGas": "0x1234", - "maxPriorityFeePerGas": "0x1234", - "gas": "0x55555", - "to": "0x07a565b7ed7d7a678680a4c162885bedbb695fe0", - "value": "0x1234", - "input": "0xabcd", - "v": "0x26", - "r": "0x223a7c9bcf5531c99be5ea7082183816eb20cfe0bbc322e97cc5c7f71ab8b20e", - "s": "0x2aadee6b34b45bb15bc42d9c09de4a6754e7000908da72d48cc7704971491663", - "hash": "0xeba2df809e7a612a0a0d444ccfa5c839624bdc00dd29e3340d46df3870f8a30e" - } - } -} -``` - -- a `raw` az aláírt tranzakció a [Recursive Length Prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp) által kódolt formában -- a `tx` az aláírt tranzakció JSON-ban - -Az aláírás hash-sel a tranzakcióról kriptográfiailag be lehet bizonyítani, hogy a küldőtől jött és így továbbították a hálózatra. - -### Az adatmező {#the-data-field} - -A tranzakciók többsége egy szerződést ér el egy külső tulajdonú számláról. A legtöbb szerződést Solidity nyelven írják, az adatmezőt az [alkalmazás bináris interfész (ABI)](/glossary/#abi) alapján lehet értelmezni. - -Az első négy bájt adja meg a funkciót a híváshoz, a funkció nevének és argumentumok hash-ét használva. A funkció néha beazonosítható ebből az [adatbázisból](https://www.4byte.directory/signatures/). - -A hívási adat többi része az argumentumok, [az ABI-specifikáció szerint kódolva](https://docs.soliditylang.org/en/latest/abi-spec.html#formal-specification-of-the-encoding). - -Nézzük meg ezt a [tranzakciót](https://etherscan.io/tx/0xd0dcbe007569fcfa1902dae0ab8b4e078efe42e231786312289b1eee5590f6a1). **Kattintson a részletekért** a hívási adatok megtekintéséért. - -A funkcióválasztó a `0xa9059cbb`. Számos [ismert funkció létezik ezzel az aláírással](https://www.4byte.directory/signatures/?bytes4_signature=0xa9059cbb). Ebben az esetben [a szerződés forráskódját](https://etherscan.io/address/0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48#code) feltöltöttük az Etherscan-be, így tudjuk, hogy a funkció a `transfer(address,uint256)`. - -Az adat többi része: - -``` -0000000000000000000000004f6742badb049791cd9a37ea913f2bac38d01279 -000000000000000000000000000000000000000000000000000000003b0559f4 -``` - -Az ABI specifikáció szerint az integer értékek (mint a címek, amelyek 20 bájt hosszú integerek) az ABI-ban 32 bájt hosszan jelennek meg, nullákkal az elején. Így tudjuk, hogy a `to` (fogadó) cím a [`4f6742badb049791cd9a37ea913f2bac38d01279`](https://etherscan.io/address/0x4f6742badb049791cd9a37ea913f2bac38d01279). Az `value` (érték) pedig 0x3b0559f4 = 990206452. - -## Tranzakciótípusok {#types-of-transactions} - -Az Ethereumon található néhány tranzakciótípus: - -- Általános tranzakciók: egyik számláról a másikra. -- Szerződést telepítő tranzakciók: ahol nincs „to” vagyis fogadó cím, és az adatmezőket a szerződéskódra használják. -- A szerződés végrehajtása: olyan tranzakció, amely egy telepített okosszerződéssel kapcsolódik. Ekkor a „to” vagyis fogadó cím az okosszerződés címe. - -### A gázról {#on-gas} - -Ahogy korábban említettük, a tranzakciók [gáz](/developers/docs/gas/)költséget igényelnek a lefutáshoz. Egy egyszerű átutalás 21 000 gázegységet igényel. - -Bob 1 ETH-t küld Alice-nek, ahol a `baseFeePerGas` 190 gwei és a `maxPriorityFeePerGas` 10 gwei, így Bobnak a következő díjat kell kifizetnie: - -``` -(190 + 10) * 21 000 = 4 200 000 gwei ---vagyis-- -0,0042 ETH -``` - -Bob számlája **-1,0042 ETH-val** csökken (1 ETH Alice-nek + 0,0042 ETH gázdíjakra) - -Alice számlájára **+1,0 ETH** érkezik - -Az elégetendő alapdíj **-0,00399 ETH** - -A validátor megtartja a borravalót, ami **+0,000210 ETH** - - -![Egy diagram, amely a fel nem használt gáz visszatérítését ábrázolja](./gas-tx.png) _Diagram átvéve az [Ethereum EVM illusztrálva](https://takenobu-hs.github.io/downloads/ethereum_evm_illustrated.pdf)_ anyagból - -A tranzakcióban fel nem használt összes gáz visszakerül a felhasználó számlájára. - -### Okosszerződéses interakciók {#smart-contract-interactions} - -Minden olyan tranzakció gázt igényel, mely okosszerződéssel függ össze. - -Az okosszerződések olyan funkciókat is tartalmazhatnak, mint a [`view`](https://docs.soliditylang.org/en/latest/contracts.html#view-functions) vagy [`pure`](https://docs.soliditylang.org/en/latest/contracts.html#pure-functions), melyek nem változtatnak a szerződés állapotán. Emiatt ezen függvények meghívása egy külső tulajdonú számláról (EOA) nem igényel gázt. Az ennek megfelelő RPC meghívás az [`eth_call`](/developers/docs/apis/json-rpc#eth_call) - -Kivéve, ha az `eth_call` révén használják ezeket, a `view` vagy `pure` függvényeket általában belülről hívják meg (vagyis magából a szerződésből vagy másik szerződésből), ami gázba kerül. - -## Tranzakció-életciklus {#transaction-lifecycle} - -Amikor valaki elküld egy tranzakciót, a következő történik: - -1. A tranzakciós hash kriptográfiailag generálódik: `0x97d99bc7729211111a21b12c933c949d4f31684f1d6954ff477d0477538ff017` -2. A tranzakció ezután elterjed a hálózaton, bekerül a tranzakció gyűjtőmedencébe, ami az összes függő tranzakciót tartalmazza. -3. A validátornak ki kell választania a tranzakciót és bele kell foglalnia egy blokkba, hogy hitelesítse és „sikeresnek” minősítse. -4. Az idő múlásával a tranzakciót tartalmazó adott blokk a hitelesítettből a véglegesített állapotba jut. Ezek a frissítések biztossá teszik, hogy a tranzakció sikeres és többé nem lehet megváltoztatni. Amint a blokk végleges lesz, csak egy hálózatszintű támadás tudja megváltoztatni, ami sok milliárd dollárba kerülne a támadó részéről. - -## Vizuális bemutató {#a-visual-demo} - -Kövesse végig, ahogy Austin bemutatja a tranzakciókat, a gázt és a bányászatot. - - - -## Beírt tranzakciógöngyöleg {#typed-transaction-envelope} - -Az Ethereum eredetileg egyetlen formátummal rendelkezett a tranzakciókat illetően. Minden tranzakcióban a következő értékek voltak jelen: nonce, gázdíj, gázkorlátozás, a fogadó címe, az érték, adatok, v, r és s. Ezek a mezők [RLP-kódolásúak](/developers/docs/data-structures-and-encoding/rlp/), hogy így nézzenek ki: - -`RLP([nonce, gasPrice, gasLimit, to, value, data, v, r, s])` - -Az Ethereum tovább fejlődött, hogy többféle tranzakciót is támogatni tudjon olyan funkciók lehetővé tételéhez, mint a hozzáférési listák és a [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559), és úgy tudja ezeket bevezetni, hogy ne érintsék az eredeti tranzakció formátumát. - -Az [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) teszi ezt lehetővé. A tranzakciókat így interpretálják: - -`TransactionType || TransactionPayload` - -Ahol a mezők jelentése: - -- `TransactionType` – egy szám 0 és 0x7f között, összesen 128 lehetséges tranzakciótípusra. -- `TransactionPayload` – tetszőleges bájtsor, amelyet a tranzakció típusa határoz meg. - -A `TransactionType` értéke alapján a tranzakció a következő kategórába eshet - -1. **0-s típusú (eredeti) tranzakciók:** Az eredeti tranzakciós formátum az Ethereum bevezetése óta. Nem tartalmaznak az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) által bevezetett jellemzőket, mint a dinamikus gázdíj-kalkuláció vagy elérhetőségi listák az okosszerződéseknek. Ezek az eredeti tranzakciók nem tartalmaznak olyan specifikus előtagot, amely jelezné a típusukat a sorosított formájukban, a `0xf8` bájttal kezdődnek, amikor [Rekurzív hosszúságú prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp) kódolást használnak. A TransactionType értéke ekkor `0x0`. - -2. **1-es típusú tranzakciók:** Az [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930) vezette be ezeket az Ethereum [Berlin frissítése](/history/#berlin) során, és ezek egy `accessList` (elérési lista) paramétert tartalmaznak. Ez a lista meghatározza azokat a címeket és tárolási kulcsokat, melyeket a tranzakció várhatóan elér, hogy így csökkentse a [gáz](/developers/docs/gas/)költségét az összetett tranzakcióknak, melyek okosszerződésekből erednek. Az EIP-1559 díjpiaci változások nem részei az 1-es típusú tranzakcióknak. Ezek magukba foglalnak egy `yParity` paramétert, amely lehet `0x0` vagy `0x1`, amely a secp256k1 aláírás y értékének megfelelését jelöli. Ezek a `0x01`bájttal kezdődnek, és a TransactionType értéke `0x1`. - -3. **2-es típusú tranzakciók**, általában EIP-1559-tranzakciók, melyeket az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) vezetett be az Ethereum [London frissítésekor](/history/#london). Ezek lettek az Ethereum-hálózat sztenderd tranzakciótípusai. Egy új díjpiaci mechanizmust vezettek be, amely javítja az előrejelezhetőséget azáltal, hogy egy alapdíjra és egy prioritási díjra osztja fel a tranzakciós díjat. A `0x02` bájttal kezdődnek és olyan mezőket tartalmaznak, mint a `maxPriorityFeePerGas` és `maxFeePerGas`. Jelenleg a 2-es típusú tranzakciók az alapértelmezettek a rugalmasság és a hatékonyság okán, főleg a nagy hálózati leterheltség idején, mert a felhasználók jobban tudják kezelni a tranzakciós díjakat ezáltal. A TransactionType értéke ezekre `0x2`. - - - -## További olvasnivaló {#further-reading} - -- [EIP-2718: Tranzakciógöngyöleg](https://eips.ethereum.org/EIPS/eip-2718) - -_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Számlák](/developers/docs/accounts/) -- [Ethereum virtuális gép (EVM)](/developers/docs/evm/) -- [Üzemanyag](/developers/docs/gas/) diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/web2-vs-web3/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/web2-vs-web3/index.md deleted file mode 100644 index d2fd0ad437b..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/web2-vs-web3/index.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Web2 vs Web3 -description: -lang: hu ---- - -A web2 arra az internetre utal, melyet ma legtöbbünk ismer. Egy internet, melyet olyan cégek dominálnak, melyek szolgáltatásokat nyújtanak a személyes adataidért cserébe. A web3 az Ethereum kontextusában decentralizált alkalmazásokra utal, melyek a blokkláncon futnak. Ezek olyan alkalmazások, amelyek lehetővé teszik, hogy bárki részt vegyen anélkül, hogy monetizálná a személyes adatait. - -Egy sokkal inkább kezdőknek szóló áttekintést szeretne? Tekintse meg a [bevezetés a web3-ba](/web3/) oldalt. - -## Web3 előnyök {#web3-benefits} - -Sok web3-fejlesztő választotta a dappok fejlesztését az Ethereum örökletes decentralizációja miatt: - -- A hálózaton mindenkinek hozzáférése van, hogy használja a szolgáltatást - máshogy megfogalmazva, nincs engedélyhez kötve. -- Senki sem blokkolhatja és nem tagadhatja meg a szolgáltatáshoz való hozzáférést. -- A fizetések be vannak építve a natív tokennel, Etherrel (ETH). -- Az Ethereum Turing-kompatibilis, vagyis lényegében bármi leprogramozható a számára. - -## Gyakorlati összehasonlítás {#practical-comparisons} - -| Web2 | Web3 | -| ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | -| A Twitter bármely felhasználót vagy tweetet cenzúrázhatja | A web3 tweetek cenzúrázhatatlanok, mivel az irányítás decentralizált | -| A fizetési szolgáltatás úgy dönthet, hogy bizonyos munkákért nem engedélyezi a kifizetéseket | A web3 fizetési alkalmazások nem igényelnek személyes adatot és nem tudnak fizetéseket megakadályozni | -| A maszek gazdaságot kiszolgáló alkalmazások leállhatnak és ez hatással lehet a dolgozó bevételére | A web3 szerverek nem állhatnak le – az Ethereumot használják backendként, mely egy több ezer számítógépből álló decentralizált hálózat | - -Ez nem jeleni azt, hogy minden szolgáltatást dappá kell alakítani. Ezek a példák a web2 és a web3 szolgáltatások közötti fő különbségeket hivatottak bemutatni. - -## Web3 korlátok {#web3-limitations} - -A web3-at jelenleg több dolog is korlátozza: - -- Méretezhetőség – a tranzakciók lassabbak a web3-on, mivel decentralizált. Az olyan státuszváltozásokat, mint amilyen a fizetés is, egy csomópontnak kell feldolgoznia és közvetíteni azt a hálózaton keresztül. -- UX – a web3 alkalmazásokkal történő interakció extra lépéseket, szoftvert és oktatást igényelhet. Ez akadályozza az elterjedését. -- Elérhetőség – a modern webböngészők nem elég integráltak ahhoz, hogy a web3-at a legtöbb felhasználó elérhesse. -- Költség – a legtöbb sikeres dapp csak a kódjának csak egy kis hányadát teszi fel a blokkláncra, mivel ez elég költséges. - -## Centralizáció versus decentralizáció {#centralization-vs-decentralization} - -Az alábbi táblázatban felsoroljuk a centralizált és decentralizált digitális hálózatok néhány széleskörű előnyét és hátrányát. - -| Centralizált hálózatok | Decentralizált hálózatok | -| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Alacsony hálózati átmérő (minden résztvevő egy központi fennhatósághoz kapcsolódik); az információ gyorsan terjed, mivel a terjesztést egy központi fennhatóság kezeli nagy mennyiségű számítási kapacitással. | Hálózat legtávolabbi résztvevői között jelentősen több élnyi távolság is előfordulhat. Az információ közvetítése a hálózat egyik sarkából a másikba sok idő vehet igénybe. | -| Általában nagyobb teljesítmény (nagyobb átvitel, kevesebb a teljes kiadott számítási kapacitás) és könnyebb implementálni. | Általában alacsonyabb teljesítmény (kisebb átvitel, több a teljes kiadott számítási kapacitás) és bonyolultabb implementálni. | -| Az egymásnak ellentmondó adatok előfordulásakor a megoldás tiszta és egyszerű: az igazság végső forrása a központi fennhatóság. | Egy protokoll (gyakran bonyolult) szükséges, hogy a nézeteltéréseket feloldja, ha a peerek egymásnak ellentmondanak az adat állapotáról, melyekről a résztvevőknek szinkronban kéne lenniük. | -| Egyetlen meghibásodási pont: a rosszindulatú szereplők képesek megállítani a hálózatot a központi hatóság megtámadásával. | Nincs egyetlen meghibásodási pont: a hálózat akkor is működhet, ha a résztvevők nagy részét megtámadják/megszűntetik. | -| A hálózati résztvevők közötti koordináció sokkal könnyebb, és azt egy központi hatóság kezeli. A központi hatóság arra kényszerítheti a hálózati résztvevőket, hogy frissítéseket, protokollfrissítéseket stb. fogadjanak el nagyon kis súrlódással. | A koordináció gyakran nehéz, mivel egyetlen résztvevőnek sincs végső szava a hálózati szintű döntésekben, a protokollfrissítésekben stb. A legrosszabb esetben a hálózat hajlamos a szétesésre, ha nézeteltérések vannak a protokoll változásaival kapcsolatban. | -| A központi hatóság cenzúrázhatja az adatokat, potenciálisan elvágva a hálózat egyes részeit a hálózat többi részével való interakciótól. | A cenzúra sokkal nehezebb, mivel az információ sokféleképpen terjedhet a hálózaton keresztül. | -| A hálózatban való részvételt a központi hatóság ellenőrzi. | Bárki részt vehet a hálózatban; nincsenek "kapuőrök." Ideális esetben a részvétel költsége nagyon alacsony. | - -Azt meg kell jegyezni, hogy ezek a minták nem biztos, hogy minden hálózatra igazak. Továbbá a valóságban egy hálózat centralizáltsága/decentralizáltsága skálán mérhető; nincsen teljesen centralizált vagy teljesen decentralizált hálózat. - -## További olvasnivaló {#further-reading} - -- [Mi az a web3?](/web3/) – _ethereum.org_ -- [A web 3.0 alkalmazások architektúrája](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ -- [A decentralizáció jelentése](https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274) _Feb 6, 2017 - Vitalik Buterin_ -- [Why Decentralization Matters](https://medium.com/s/story/why-decentralization-matters-5e3f79f7638e) _Feb 18, 2018 - Chris Dixon_ -- [Mi az a web 3.0 és miért fontos?](https://medium.com/fabric-ventures/what-is-web-3-0-why-it-matters-934eb07f3d2b) _2019. december 31. – Max Mersch and Richard Muirhead_ -- [Miért van szükség a web 3.0-ra?](https://medium.com/@gavofyork/why-we-need-web-3-0-5da4f2bf95ab) _2018. szeptember 12. – Gavin Wood_ diff --git a/public/content/translations/hu/13) Foundational Docs/developers/docs/wrapped-eth/index.md b/public/content/translations/hu/13) Foundational Docs/developers/docs/wrapped-eth/index.md deleted file mode 100644 index 2eacb55c159..00000000000 --- a/public/content/translations/hu/13) Foundational Docs/developers/docs/wrapped-eth/index.md +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Mi az a becsomagolt ether (WETH) -description: A becsomagolt ether (WETH) bemutatása, ami egy ERC-20 kompatibilis burkolata az ethernek (ETH). -lang: hu ---- - -# Becsomagolt ether (WETH) {#intro-to-weth} - -Az Ether (ETH) az Ethereum fő valutája. Számos célra használják, mint letétbe helyezéshez, valutaként, illetve a számolási kapacitás kifizetésére gázdíjakban. **A WETH egy továbbfejlesztett formája az ETH-nek néhány új funkcionalitással, melyek az alkalmazásokhoz és az [ERC-20 tokenekhez](/glossary/#erc-20)** szükségesek, amelyek az Ethereumon található más digitális eszközök. Ahhoz, hogy ezekkel a tokenekkel kapcsolódni lehessen, az ETH-nak is ugyanazokat a szabályokat kell követnie, vagyis az ERC-20 szabványt. - -Ennek áthidalására jött létre a becsomagolt ETH (WETH). **A becsomagolt ETH egy okosszerződés, amely lehetővé teszi, hogy bármilyen összeget beletegyen a szerződésbe, és ugyanazt megkapja WETH-ben**, amely megfelel az ERC-20 tokenszabványnak. A WETH az ETH reprezentációja, mellyel lehetségessé válik, hogy ne natív eszközként, hanem ERC-20 tokenként lehessen interakciót végezni vele. A natív ETH-re még mindig szükség van a gázdíjak kifizetéséhez, ezért a letétbe helyezésnél tartson meg valamekkora összeget. - -A WETH ETH-re való kicsomagolásához WETH-okosszerződést használhat. Bármekkora összeget átválthat WETH-ről a WETH okosszerződéssel, és ugyanazt megkapja ETH-ben. Ekkor a letétbe helyezett WETH elég és kikerül az elérhető WETH kínálatból. - -**Nagyjából az ETH kinálat kb. 3%-a van lekötve a WETH tokenszerződésben**, melynek következtében ez a leginkább használt [okosszerződés](/glossary/#smart-contract). A WETH különösen fontos azoknak a felhasználóknak, akik a decentralizált pénzügyek (DeFi) alkalmazásait használják. - -## Miért kell az ETH-t becsomagolni ERC-20 tokenként? {#why-do-we-need-to-wrap-eth} - -Az [ERC-20](/developers/docs/standards/tokens/erc-20/) egy sztenderd interfészt határoz meg az átváltható tokenekhez, így bárki létrehozhat olyan tokent, mely gond nélkül interaktál az Ethereum ökoszisztémában ezen szabvány által működő alkalmazásokkal és tokenekkel. Mivel az **ETH korábban keletkezett, mint az ERC-20 szabvány**, ezért nem felel meg ennek a specifikációnak. Emiatt **nem lehet egyszerűen** átváltani az ETH-t más ERC-20 tokenre vagy **ETH-t használni olyan alkalmazásokban, melyek ERC-20 szabványt használnak**. A becsomagolt ETH a következőket teszi lehetővé: - -- **ETH átváltása ERC-20 tokenekre**: közvetlen módon nem lehet ETH-t váltani ERC-20 tokenekre. A WETH az ether reprezentációja, amely megfelel az ERC-20 helyettesíthető tokenszabványnak, így átváltható más ERC-20 tokenekre. - -- **ETH használata dappokban**: mivel az ETH nem ERC-20-kompatibilis, ezért a fejlesztőknek külön interfészeket kell építeniük (egyet az ETH-hez, egy másikat az ERC-20 tokenekhez) az alkalmazásokban. A becsomagolt ETH átugorja ezt az akadályt, így a fejlesztők ugyanabban a dappban tudják kezelni az ETH-t és a többi tokent. Számos decentralizált pénzügyi alkalmazás használja ezt a szabványt, és piacokat hoz létre e tokenek átváltására. - -## A becsomagolt ether (WETH) és az ether (ETH) közötti különbség {#weth-vs-eth-differences} - -| | **Ether (ETH)** | **Becsomagolt ether (WETH)** | -| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Kínálat | Az ETH kínálatát az Ethereum-protokoll kezeli. Az ETH [kibocsátását](/roadmap/merge/issuance) az Ethereum validátorok kezelik, amikor tranzakciókat hajtanak végre és blokkokat hoznak létre. | A WETH egy ERC-20 token, melynek kínálatát egy okosszerződés kezeli. A WETH új egységeit a szerződés bocsátja ki, miután ETH-letétet kapott a felhasználóktól, vagy a WETH egységek elégnek, amikor a felhasználó vissza akarja azt váltani ETH-re. | -| Tulajdonlás | A tulajdonjogot az Ethereum-protokoll által van kezelve a számlaegyenleg révén. | A WETH tulajdonjogát a WETH token okosszerződés kezeli, melyet az Ethereum protokoll biztosít. | -| Gáz | Az ether (ETH) az elfogadott fizetés a számítási kapacitásért az Ethereum hálózaton. A gázdíjakat gwei-ben (az ether egyik egységében) fejezik ki. | A WETH tokennel való gázfizetés alapvetően nem támogatott. | - -## Gyakran ismételt kérdések {#faq} - - - -Gázdíjat kell fizetni az ETH be- vagy kicsomagolásáért, amikor a WETH szerződést használja. - - - - - -A WETH általánossában biztonságosnak tekinthető, mert egy egyszerű, harcedzett okosszerződésen alapul. A WETH szerződést formálisan is ellenőrizték, mely az Ethereum okosszerződések legmagasabb biztonsági sztenderdje. - - - - - -[A WETH kanonikus bevezetése](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) mellett, melyet ezen az oldalon részleteznek, más változatok is léteznek. Ezek lehetnek személyreszabott tokenek, melyeket az alkalmazásfejlesztők hoztak létre, vagy más blokkláncokon kiadott változatok, illetve máshogy viselkedhetnek vagy más biztonsági beállításokkal bírhatnak. **Mindig ellenőrizze le a tokeninformációt, hogy melyik WETH implementációval végez interakciót.** - - - - - -- [Ethereum főhálózat](https://etherscan.io/token/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2) -- [Arbitrum](https://arbiscan.io/token/0x82af49447d8a07e3bd95bd0d56f35241523fbab1) -- [Optimism](https://optimistic.etherscan.io/token/0x4200000000000000000000000000000000000006) - - - -## További olvasnivaló {#further-reading} - -- [Mi az a WETH?](https://weth.tkn.eth.limo/) -- [WETH tokeninformáció az Etherscan oldalon](https://etherscan.io/token/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) -- [A WETH formális ellenőrzése](https://zellic.io/blog/formal-verification-weth) diff --git a/public/content/translations/hu/14) Community Pages/community/code-of-conduct/index.md b/public/content/translations/hu/14) Community Pages/community/code-of-conduct/index.md deleted file mode 100644 index 043e7b01a6e..00000000000 --- a/public/content/translations/hu/14) Community Pages/community/code-of-conduct/index.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Magatartási szabályok -description: Alapvető szabályok az ethereum.org oldalain. -lang: hu ---- - -# Magatartási szabályok {#code-of-conduct} - -## Misszió {#mission} - -A legátfogóbb és legelérhetőbb tudásközpont kifejlesztése és fenntartása az Ethereum számára. - -## Értékek {#values} - -Az ethereum.org közösség arra törekszik, hogy: - -- tanító jellegű legyen, mindenkinek segít megérteni az Ethereumot -- befogadó legyen -- elérhető legyen -- közösség által vezérelt legyen -- az Ethereum mögötti technológiákra és alkalmazási területekre fókuszál -- az Ethereumhoz kapcsolódó koncepciókra és dizájnelvekre fókuszál - -## Nem vagyunk {#what-we-are-not} - -- Az Ethereum Alapítvány weboldala -- Olyan platform, ahol befektetéseket vagy bármilyen profitszerzést támogatunk -- Olyan platform, ahol egyéni projekteket vagy szervezeteket mutatunk be vagy hagyunk jóvá -- Decentralizált tőzsde (DEX), centralizált tőzsde (CEX) vagy bármilyen már pénzügyi platform -- Olyan platform, amely bármilyen pénzügyi vagy jogi tanácsot ad - -## Magatartási szabályok {#code-of-conduct} - -### Vállalás {#pledge} - -Az ethereum.org világképének lényege a nyitott részvétel. Ezt a weboldalt és közösséget ezernyi közreműködő tartja fenn, és ez csak úgy lehetséges, ha egy befogadó, részvételt támogató környezetet tartunk fenn. A közreműködők vállalják, hogy olyan környezetet teremtenek, melynek nem része a bántás vagy bosszantás, a ethereum.org minden platformját és közösségi terét beleértve. Az ethereum.org közösség mindenkit örömmel fogad és értékel, aki konstruktív és barátságos módon részt akar venni, és ebben nem számít a kor, bármilyen alkalmatlanság, etnikum, nemi identitás, tapasztalat, a szakértelem területe, tanulmányok, szociogazdasági státusz, nemzetiség, megjelenés, faj, vallás vagy a diverzitás bármelyik dimenziója. - -### Érvényességi terület {#scope} - -Ez a magatartási szabályzat minden ethereum.org helyre érvényes (mint amilyen a GitHub, Discord, Figma Crowdin, Twitter és más online platformok), és amikor a közösség találkozik a valóságban különféle eseményeken, konferenciákon. - -### Irányelveink {#our-standards} - -A pozitív környezethez hozzájáruló viselkedések például: - -- Befogadó nyelvezetet használunk -- A különböző nézeteket és tapasztalatokat tisztelettel kezeljük -- A konstruktív kritikát örömmel vesszük és együttérzően adjuk -- A konfliktusok és ellentétek esetén nyugodtan és professzionálisan közelítünk -- A többi tag felé empátiával és toleranciával fordulunk -- Bátorítjuk az új hangokat a közösségben - -Az elfogadhatatlan viselkedések például: - -- Fizikai erőszak, azzal való fenyegetés vagy támogatása bármilyen formában -- Szexualitással kapcsolatos beszéd vagy kép használata, illetve ilyen jellegű közeledés -- Egy másik ember megszemélyesítése, vagy rosszhiszeműen azt állítani, hogy egy személlyel vagy szervezettel kapcsolatban áll valaki -- Zavaró, derogáló kommentek, személyes vagy politikai támadások -- Más tag zaklatása nyilvános vagy privát csatornákon -- Mások privát információinak nyilvánossá tétele, mint fizikai vagy elektronikus cím, kifejezett kérése nélkül -- Pszichológiai manipuláció, csalás vagy más jellegű befolyásolása a tagoknak -- Bármilyen befektetés, token, projekt hirdetése személyes haszonszerzés céljából, legyen az pénzügyi vagy nem -- A szerverek teleszemetelése nem odavaló tartalommal -- A közösségi moderátorok kérését vagy figyelmeztetését nem venni figyelembe -- Bármilyen viselkedés, ami nem tekinthető megfelelőnek egy professzionális helyzetben - -### Jelentés {#reporting} - -A magatartási szabályok megsértése általában látható a közösségnek, mivel mindent nyitott, nyilvános csatornákon kezelünk, hogy a tagok maguk vigyázzák a rendet. - -Ha úgy véli, hogy valami figyelmet igényelne, akkor szóljon egy moderátornak (pl. discord-vezető), így segíthetnek a kivizsgálásban és a megfelelő válasz megtételében. - -A jelentésnél minden részletet adjon meg, példákkal és időpontokkal. Ez segít, hogy igazságos eredmény születhessen. - -### Szankciók {#enforcement} - -Az eset súlyosságától függően figyelmeztetések, átmeneti kizárások és végleges kizárások várhatók az ethereum.org közösségeitől. diff --git a/public/content/translations/hu/14) Community Pages/community/events/index.md b/public/content/translations/hu/14) Community Pages/community/events/index.md deleted file mode 100644 index 0b564281725..00000000000 --- a/public/content/translations/hu/14) Community Pages/community/events/index.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -title: Ethereum események -description: Hogyan lehet bekapcsolódni az Ethereum közösségébe. -lang: hu -hideEditButton: true ---- - -# Közelgő események {#events} - -**Minden hónapban részt vehet Ethereum-eseményeken a világ bármely pontján.** Vegyen részt egy Önhöz közel eső eseményen, hogy találkozzon a közösség tagjaival, megismerje a munkalehetőségeket és új képességeket fejlesszen. - - - -A lista nem teljeskörű, a közösség tagjai frissítik. Tudomása van egy tervezett Ethereum-eseményről? [Kérjük, adja hozzá](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-events.json)! - -## Ethereum-találkozók {#meetups} - -Nem talál olyan eseményt, amely jó lenne Önnek? Próbáljon meg elmenni egy találkozóra. Ezek kisebb események, melyeket az Ethereum-rajongók szerveznek, hogy az Ethereum iránt érdeklődők összegyűljenek, beszélgessenek az Ethereumról, megismerjék az új fejlesztéseket. - - - -Saját találkozót szeretne szervezni? Nézze meg a [BUIDL Network-öt](https://consensys.net/developers/buidlnetwork/), ami a ConsesSys kezdeményezése, hogy támogassa az Ethereum találkozókat. - -Ez a lista nem teljeskörű, a közösség tagjai írják. [Több Ethereum találkozót](https://www.meetup.com/topics/ethereum/) találhat itt. Ismer olyan találkozót szervező csoportot, amelyik nincs a listán? [Kérjük, adja hozzá!](https://github.com/ethereum/ethereum-org-website/blob/dev/src/data/community-meetups.json) diff --git a/public/content/translations/hu/14) Community Pages/community/get-involved/index.md b/public/content/translations/hu/14) Community Pages/community/get-involved/index.md deleted file mode 100644 index 577a957a598..00000000000 --- a/public/content/translations/hu/14) Community Pages/community/get-involved/index.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -title: Hogyan lehet részt venni? -description: Hogyan lehet bekapcsolódni az Ethereum közösségébe. -lang: hu ---- - -# Hogyan lehet részt venni? {#get-involved} - -Az Ethereum-közösségek tagjai különféle háttérrel és képességekkel rendelkeznek. Lehet Ön fejlesztő, művész vagy könyvelő, mindenkinek lehetősége van közreműködni. Az alábbi javaslatok segíthetnek megtalálni a megfelelő kiindulási pontot. - -Kezdje azzal, hogy elolvassa az ethereum.org misszióját és értékeit a [magatartási szabályok](/community/code-of-conduct) oldalon. - -## Fejlesztők {#developers} - -- Tanuljon az Ethereumról és próbálja ki az [ethereum.org/developers/](/developers/) oldalon -- Vegyen részt egy Önhöz közel eső [ETHGlobal](http://ethglobal.co/) hackathonon! -- Nézze meg azokat a [projekteket, melyek a szakterületéhez vagy a választott programnyelvéhez kapcsolódnak](/developers/docs/programming-languages/) -- Nézze meg a [Konszenzus- és végrehajtási réteg megbeszéléseket](https://www.youtube.com/@EthereumProtocol/streams) vagy vegyen részt rajtuk -- [Ökoszisztémát támogató programok listája](https://esp.ethereum.foundation/wishlist/) – eszközök, dokumentáció és infrastruktúra, ahol az Ethereum-ökoszisztémát támogató programok aktívan várják a támogatásért jelentkezőket -- [Web3Bridge](https://www.web3bridge.com/) – csatlakozzon az inspiráló web3-közösséghez, mely egész Afrikában fejlesztők és közösségi tagok százait választja ki, tanítja be és támogatja -- Csatlakozzon az [Eth R&D Discord](https://discord.com/invite/VmG7Uxc) csatornához -- Csatlakozzon az [Ethereum Cat Herders Discord csatornához](https://discord.com/invite/Nz6rtfJ8Cu) - -## Kutatók és akadémikusok {#researchers-and-academics} - -Ön matematikus, kriptográfus vagy közgazdász háttérrel rendelkezik? Érdeklik az élvonalbeli tevékenységek az Ethereum-ökoszisztéma kapcsán: - -- Csatlakozzon az [Eth R&D Discord](https://discord.com/invite/VmG7Uxc) csatornához -- Írjon vagy véleményezzen egy Ethereum fejlesztési javaslatot (EIP) - - Írjon EIP-t - 1. Adja be ötletét az [Ethereum Magicians csoportnak](https://ethereum-magicians.org) - 2. Olvassa el az [EIP-1-et](https://eips.ethereum.org/EIPS/eip-1) – **Igen, ez a _teljes_ dokumentum.** - 3. Kövesse az EIP-1 iránymutatásait. Hivatkozzon rá, ahogy a vázlatot készíti. - - Tudja meg, hogyan lehet [EIP-szerkesztő](https://eips.ethereum.org/EIPS/eip-5069) - - Ön is véleményezheti az EIP-ket már most! Nézze meg a [nyitott PR-okat az `e-review` címkét](https://github.com/ethereum/EIPs/pulls?q=is%3Apr+is%3Aopen+label%3Ae-review) használva. Adjon technikai visszajelzést a `discussion-to` hivatkozáson. - - Vegyen részt az [EIP-menedzsementben](https://github.com/ethereum-cat-herders/EIPIP) - - Csatlakozzon az [Ethereum Cat Herders Discord csatornához](https://discord.com/invite/Nz6rtfJ8Cu) - - [Bővebben az EIP-kről](/eips/) -- [Challenges.ethereum.org](https://challenges.ethereum.org/) – magas értékű kutatói jutalmak, ahol akár >$100 000 dollárnál is többet kaphat -- [Ethresear.ch](https://ethresear.ch) – az Ethereum elsődleges kutatói fóruma, illetve a világ legbefolyásosabb fóruma a kriptogazdaság terén -- [EF Research AMA](https://old.reddit.com/r/ethereum/comments/vrx9xe/ama_we_are_ef_research_pt_8_07_july_2022) – egy folyamatos kérdés-válasz sorozat a kutatókkal. A következő részek megnyitásakor bárki feltehet kérdéseket. -- [Ökoszisztémát támogató programok listája](https://esp.ethereum.foundation/wishlist/) – kutatási területek, ahol az Ethereum-ökoszisztémát támogató programok aktívan várják a támogatásért jelentkezőket -- [AllWalletDevs](https://allwallet.dev) – fórum az Ethereum-fejlesztők, -tervezők és -érdeklődők számára, hogy rendszeresen összegyűljenek és megtárgyalják a tárcákat - -[Fedezzen fel még több kutatási területet](/community/research/). - -## Nem technikai képességek {#non-technical} - -Ha Ön nem fejlesztő, nehéz lehet felmérni, hogy hol kapcsolódjon be az Ethereum világába. Íme néhány javaslat hivatkozásokkal együtt a specifikus szakmai hátterekhez. - -### Szervezzen találkozót a városában {#meetups} - -- Nem tudja, hogyan kezdje? A [BUIDL-hálózat](https://consensys.net/developers/buidlnetwork/) segít benne. - -### Írjon az Ethereumról {#write-content} - -- Az Ethereumnak szüksége van jó írókra, akik el tudják magyarázni az értékeit egyszerű nyelven -- Még nem áll készen, hogy a saját cikkét megjelentesse? Vegyen részt a meglévő tartalom kezelésében vagy [javasoljon új tartalmat az ethereum.org számára](/contributing/)! - -### Készítsen jegyzetet a közösségi megbeszéléseken (community calls) {#take-notes} - -- Számos nyilvános közösségi megbeszélés létezik, ahol a jegyzet készítése nagy segítség. Ha érdekli Önt, akkor csatlakozzon az [Ethereum Cat Herders discord](https://discord.com/invite/Nz6rtfJ8Cu) csatornához, és mutatkozzon be! - -### Fordítsa saját nyelvére az Ethereumhoz kapcsolódó tartalmat {#translate-ethereum} - -- Az ethereum.org egy fordítói programot is üzemeltet, mely a weboldalakat és más forrásokat fordítja különféle nyelvekre -- Nézze meg [itt](/contributing/translation-program), hogyan tudna ebben segíteni - -### Csomópont futtatása {#run-a-node} - -Csatlakozzon ezernyi csomópont működtetőjéhez, hogy az Ethereum még decentralizáltabb legyen. - -- [Bővebben a csomópontok futtatásáról](/developers/docs/nodes-and-clients/run-a-node/) - -### Helyezze letétbe a rendelkezésére álló ETH-t {#staking} - -A letétbe helyezéssel jutalmakat tud szerezni, miközben segít az Ethereum hálózatát biztosítani. - -- [Többet a letétbe helyezésről](/staking/) - -### Támogasson projekteket {#support-projects} - -Az Ethereum-ökoszisztéma missziója, hogy közjóval kapcsolatos és nagy hatást tevő projekteket finanszírozzon. Még a kis adományokkal is kimutathatja támogatását és fontos munkákat segíthet. - -- [Gitcoin](https://gitcoin.co/fund) -- [clr.fund](https://clr.fund/#/about) - -## Pénzügyi szakemberek és könyvelők {#financial-professionals} - -- Az Ethereum otthont ad a decentralizált pénzügyek ökoszisztémának – protokollok és alkalmazások hálózata, ami egy alternatív pénzügyi rendszert kínál. Nézzen meg néhány DeFi-alkalmazást a [DeFi Llama](https://defillama.com/) vagy [DeFiPrime](https://defiprime.com) oldalakon -- Ön könyvelő? Az Ethereum-eszközök, mint ETH, tokenek, DeFi stb. számtalan új könyvelési kérdést vetnek fel. Nézzen meg néhány projektet, amelyek a felhasználók könyvelési kihívásait próbálják támogatni – ilyen például a [Rotki](https://rotki.com/) - -## Termékmenedzserek {#product-managers} - -- Az Ethereum-ökoszisztémának az Ön tehetségére is szüksége van! Számos cég keres ilyen pozícióra munkaerőt. Ha szeretne egy nyílt forráskódú projektben közreműködni, keresse meg az [Ethereum Cat Herders](https://discord.com/invite/Nz6rtfJ8Cu) vagy [RaidGuild](https://www.raidguild.org/) csapatokat - -## Marketing {#marketing} - -- Számtalan marketinggel és kommunikációval összefüggő pozíció érhető el az Ethereumnál! - -## Ethereum-álláslehetőségek {#ethereum-jobs} - -**Szeretne munkát találni az Ethereum világában?** - -- [ethereum.org jobs](/about/#open-jobs) -- [Ethereum Foundation job board (Lever)](https://jobs.lever.co/ethereumfoundation) -- [Ethereum Foundation job board (BambooHR)](https://ethereum.bamboohr.com/jobs/) -- [JobStash](https://jobstash.xyz) -- [Cryptocurrency Jobs](https://cryptocurrencyjobs.co/ethereum/) -- [Careers at ConsenSys](https://consensys.net/careers/) -- [Crypto Jobs List](https://cryptojobslist.com/ethereum-jobs) -- [Bankless jobs board](https://pallet.xyz/list/bankless/jobs) -- [Web3 Jobs](https://web3.career) -- [Web3 Army](https://web3army.xyz/) -- [Crypto Valley Jobs](https://cryptovalley.jobs/) -- [Ethereum-álláslehetőségek](https://startup.jobs/ethereum-jobs) -- [CryptoJobster](https://cryptojobster.com/tag/ethereum/) - -## Csatlakozzon egy DAO-hoz {#decentralized-autonomous-organizations-daos} - -A DAO-k decentralizált autonóm szervezetek. Ezek az Ethereum technológiára építve működtetnek szerveződéseket és együttműködéseket. Például a tagság kezelése, a javaslatok megszavazása vagy összegyűjtött eszközök kezelése kapcsán. Bár kísérleti fázisban vannak, de rengeteg lehetőséget ajánlanak, hogy találjon egy hasonlóan gondolkodó csoportot, együttműködő partnereket és hatást gyakoroljon az Ethereum közösségre. [Bővebben a DAO-król](/dao/) - -- [DAOSquare](https://daosquare.io/) [@DAOSquare](https://twitter.com/DAOSquare) – _A DAO koncepció támogatása a nem technikai területeken, illetve hogy az emberek értéket teremtsenek a DAO által_ -- [Developer DAO](https://www.developerdao.com/) [@developer_dao](https://twitter.com/developer_dao) – _Fejlesztők közössége, akik hisznek az internet közös tulajdonlásában_ -- [dOrg](https://dOrg.tech) [@dOrg_tech](https://twitter.com/dOrg_tech) – _egy szabadúszó web3-fejlesztői csapat, amely DAO-ként működik_ -- [HausDAO](https://daohaus.club) [@nowdaoit](https://twitter.com/nowdaoit) – _A DAOhaus közösségi irányítása_ -- [LexDAO](https://lexdao.org) [@lex_DAO](https://twitter.com/lex_DAO) – _Jogi szerepkörök_ -- [Machi X](https://machix.com) [@MachiXOfficial](https://twitter.com/MachiXOfficial) - _Művészeti közösség_ -- [MetaCartel Ventures](https://metacartel.xyz) [@VENTURE_DAO](https://twitter.com/VENTURE_DAO) – _kockázati tőke a korai fázisban lévő kriptoprojektek számára_ -- [MetaGame](https://metagame.wtf) [@MetaFam](https://twitter.com/MetaFam) – _MMORPG játékmechanika a való élethez_ -- [MetaFactory](https://metafactory.ai) [@TheMetaFactory](https://twitter.com/TheMetaFactory) – _Digifizikális ruházati márkák_ -- [MolochDAO](https://molochdao.com) [@MolochDAO](https://twitter.com/MolochDAO) – _Az Ethereum-fejlesztések finanszírozását intéző közösség_ -- [Raid Guild](https://raidguild.org) [@RaidGuild](https://twitter.com/RaidGuild) – _Web3-fejlesztők csoportja_ - -Kérjük, hogy az ethereum.org [magatartási szabályait](/community/code-of-conduct) vegye figyelembe, amikor bármilyen kezdeményezésben közreműködik! diff --git a/public/content/translations/hu/14) Community Pages/community/grants/index.md b/public/content/translations/hu/14) Community Pages/community/grants/index.md deleted file mode 100644 index 06307fb83f2..00000000000 --- a/public/content/translations/hu/14) Community Pages/community/grants/index.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Az Ethereum Alapítvány és közösségi támogatói program -description: A támogatói programok listája az egész Ethereum-ökoszisztémára vonatkozóan. -lang: hu ---- - -# Ethereum-támogatások {#ethereum-grants} - -Az itt bemutatott programok különféle finanszírozási támogatást adnak projekteknek, melyek az Ethereum-ökoszisztéma sikerét és fejlődését segítik elő. Használja ezt útmutatóként ahhoz, hogy finanszírozási lehetőséget találjon magának és jelentkezzen, hogy a következő Ethereum-projektje sikerét előmozdítsa. - -A listát a közösség tartja karban. Ha bármit hiányol vagy nem talál helyesnek, akkor szerkessze az oldalt! - -## Kiterjedt Ethereum-ökoszisztéma {#broad-ethereum-ecosystem} - -Ezek a programok a kiterjed Ethereum-ökoszisztémát támogatják és a projektek széles körének ajánlanak finanszírozást. Mint a skálázási megoldások, közösségépítés, biztonság, adatvédelem és még sok más. Nem kötődnek valamelyik platformhoz, és mindig jó kiindulópont, ha valamiért Ön bizonytalan a támogatások témájában. - -- [EF Ecosystem Support Program](https://esp.ethereum.foundation) – _Nyílt forráskódú projektek finanszírozása: fókuszban az egyetemes eszközök, infrastruktúra, kutatás és közjavak_ -- [Moloch DAO](https://www.molochdao.com/) – _Adatvédelem, L2 skálázás, kliensbiztonság és más területek_ -- [DAO Grants](https://docs.google.com/spreadsheets/d/1XHc-p_MHNRdjacc8uOEjtPoWL86olP4GyxAJOFO0zxY/edit#gid=0) – _A támogatást ajánló szervezetek listája Google-táblázatban_ -- [Academic Grants](https://esp.ethereum.foundation/academic-grants) – _Az Ethereummal kapcsolatos akadémiai munkák támogatása_ -- [Blockworks Grantfarm](https://blockworks.co/grants/programs) – _A Blockworks egy átfogó jegyzéket hozott létre, lefedve az összes támogatást, változtatási javaslatot (RFP) és hibavadászatot._ - -## Projektspecifikus {#project-specific} - -Projektek által adott támogatás olyanoknak, akik az adott technológiát fejlesztenék vagy kísérleteznének vele. - -- [Aave Grants Program](https://aavegrants.org/) – _[Aave](https://aave.com/) támogatási DAO_ -- [Balancer](https://grants.balancer.community/) – _[Balancer](https://balancer.fi/) ökoszisztéma alap_ -- [Chainlink Grants Program](https://chain.link/community/grants) – _[Chainlink](https://chain.link/) közösségi támogatások_ -- [Decentraland Grants Program](https://governance.decentraland.org/grants/) – _[Decentraland](https://decentraland.org/) DAO Metaverzum_ -- [Lido Ecosystem Grants Organisation (LEGO)](https://lido.fi/lego) – _[Lido](https://lido.fi/) pénzügyi ökoszisztéma_ -- [MetaMask Program](https://metamaskgrants.org/) – _[MetaMask](https://metamask.io/) munkavállalók által vezetett támogatási DAO_ -- [SKALE Network Grants Program](https://skale.space/developers#grants) – _[SKALE Network](https://skale.space/) ökoszisztéma_ -- [Swarm Foundation Grants Program](https://my.ethswarm.org/grants) - _[Swarm Foundation](https://www.ethswarm.org/) ökoszisztéma_ -- [The Graph](https://thegraph.com/ecosystem/grants/) – _[The Graph](https://thegraph.com/) ökoszisztéma_ -- [Uniswap Grants Program](https://www.uniswapfoundation.org/approach) – _[Uniswap](https://uniswap.org/)-közösség_ - -## Kvadratikus finanszírozás {#quadratic-funding} - -Az Ethereum nyílt forráskódú gyökerei egy érdekes, új finanszírozási modellhez vezettek: kvadratikus finanszírozás. Ennek lehetősége van azt a módot továbbfejleszteni, ahogy a közjavak finanszírozását kezelhetjük. A kvadratikus finanszírozás gondoskodik arról, hogy azok a projektek kapják a finanszírozást, amelyre tényleg a legnagyobb az igény. Tehát azokat támogatjuk, amelyek a leginkább magasabb szintre emelik az emberek életét. [Bővebben a kvadratikus finanszírozásról.](/defi/#quadratic-funding) - -- [Gitcoin](https://gitcoin.co/grants) -- [clr.fund](https://clr.fund/) - -## Dolgozzon az Ethereumnál {#work-in-ethereum} - -Még nem áll készen, hogy a saját projektjét elindítsa? Cégek százai keresnek lelkes munkavállalókat, hogy az Ethereum-ökoszisztémában közreműködjenek. Többet szeretne tudni? [Nézze meg az Ethereummal kapcsolatos álláshirdetéseket](/community/get-involved/#ethereum-jobs) diff --git a/public/content/translations/hu/14) Community Pages/community/language-resources/index.md b/public/content/translations/hu/14) Community Pages/community/language-resources/index.md deleted file mode 100644 index 1f4bf27fbfb..00000000000 --- a/public/content/translations/hu/14) Community Pages/community/language-resources/index.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -title: Nyelvi források -description: Az Ethereumról szóló nem angol nyelvű források -lang: hu ---- - -# Nyelvi források {#language-resources} - -Az Ethereum közösség globális és sok millió nem angolul beszélő taggal bír. - -Az a célunk, hogy oktatási anyagokat biztosítsunk minden nyelven és segítsünk a nyelvi akadályok leküzdését, amely sok ember számára kihívást jelent. - -Ha Ön az anyanyelvén olvasna szívesen, vagy ismer olyat, aki nem beszél angolul, akkor alább hasznos forrásokat talál. Ethereum rajongók százezrei gyűlnek össze ezeken az online fórumokon, hogy megosszák a híreket, megbeszéljék az új fejlesztéseket, megvitassák a technikai problémákat és elképzeljék a jövőt. - -Ismer valamilyen oktatási anyagot az anyanyelvén? [Adjon be egy kérést](https://github.com/ethereum/ethereum-org-website/issues/new/choose), hogy adják hozzá a listához! - -## Ethereum.org források {#ethereum-org} - -Az Ethereum.org több mint 40 nyelvre van lefordítva, amelyeket minden oldal tetején található nyelvválasztó menüben találhat. - -![Nyelvválasztó menü](./language-selector-menu.png) - -Ha Ön kétnyelvű és segítene nekünk, hogy több embert érjünk el, akkor közreműködhet az [ethereum.org Fordítói programban](/contributing/translation-program/#translation-program) és segíthet lefordítani a weboldalt. - -## Közösségi források {#community} - -### Brazíliai portugál {#br-pt} - -**Hírek** - -- [BeInCrypto](http://www.beincrypto.com.br) – kriptovalutával kapcsolatos hírek és cikkek, beleértve a tőzsdék listáját, amelyek Braziliában elérhetők -- [Cointelegraph](http://cointelegraph.com.br/category/analysis) – brazil verzió a főbb kriptovalutával kapcsolatos hírekkel -- [Livecoins](http://www.livecoins.com.br/ethereum) – kriptovalutával kapcsolatos hírek és eszközök -- [Seudinheiro](http://www.seudinheiro.com/criptomoedas/) – kriptovalutával kapcsolatos hírek és riportok -- [Modular Crypto](https://modularcrypto.xyz/) - kriptovalutával kapcsolatos hírek és oktatási cikkek - -**Oktatás** - -- [web3dev](https://www.web3dev.com.br/) – tartalomközpont és Discord-közösség web3-fejlesztők számára. -- [Web3Brasil](https://github.com/web3brasil/web3brasil) – web3 és DeFi oktatóanyagok -- [CriptoFacil](http://www.criptofacil.com/ultimas-noticias/) – kriptovalutával kapcsolatos hírek és oktatás, beleértve az Ethereum kezdőknek és a DeFi kezdőknek anyagokat -- [CriptoAtivos](http://www.criptoativos.wiki.br/) – a kriptovaluta világa, oktatás és blog -- [Cointimes](http://www.cointimes.com.br/) – kriptovalutával kapcsolatos hírek és oktatás -- [Web3 starter pack](https://docs.google.com/document/d/1X8PSTFH7FTw9J-gbKWM6Y430SWCBT8d4t4pJgFQHJ8E/) – útmutató, ami a leggyakoribb és alapvető kriptokérdésekre ad választ - -### Kínai {#zh} - -**Általános források** - -- [Ethereum.cn](https://www.ethereum.cn/) – közösségi tartalom, amely a konszenzusréteg frissítéseit, a core dev megbeszélések jegyzeteit, L2-ket stb. tartalmazza. -- [EthFans](https://github.com/editor-Ajian/EthFans.org-annual-collected-works/) – tanuljon meg mindent az alapoktól a haladó szintű Ethereum-témákig -- [Unitimes](https://mp.weixin.qq.com/s/tvloZSDBSOQN9zDQj_91kA) – közösségi tartalom, amely az Ethereum, DeFi, NFT, web3 témákhoz tartozó tudást fedi le -- [123ETH](https://123eth.org/) – Portál az Ethereum-ökoszisztémához -- [Zhen Xiao](http://zhenxiao.com/blockchain/) – ingyenes online kurzusok a kriptovalutáról és alkalmazásairól -- [Ethereum Whitepaper](https://github.com/ethereum/wiki/wiki/[%E4%B8%AD%E6%96%87]-%E4%BB%A5%E5%A4%AA%E5%9D%8A%E7%99%BD%E7%9A%AE%E4%B9%A6) – az Ethereum tanulmányok kínai verziói - -**Ethereum-ökoszisztéma** - -- [ETHPlanet](https://www.ethplanet.org/) – online és személyes hackathonok, képzés egyetemisták számára -- [PrimitivesLane](https://www.primitiveslane.org/) – non-profit kutatói csoport, amely a blokklánc-technológiára fókuszál -- [Ethereum Translation Community CN](https://www.notion.so/Ethereum-Translation-Community-CN-05375fe0a94c4214acaf90f42ba40171) – az Ethereum oktatási anyagok lefordítása - -**Fejlesztőknek** - -- [DappLearning](https://github.com/Dapp-Learning-DAO/Dapp-Learning) – tanulócsoport a legfontosabb dapp-projektek tanulmányozására, gondolatok és kommentek megosztása hetente -- [LearnBlockchain](https://learnblockchain.cn/) – fejlesztői közösség a blokklánc-technológiával kapcsolatos információk megosztására - -**Kriptográfiai kutatóknak** - -- [SecbitLabs](https://mp.weixin.qq.com/s/69_tqBJpr_sbaKtR1sBRMw) – WeChat-profil, amely a kriptográfiát, biztonságot stb. magyarázza el. -- [Sparkbyte](https://mp.weixin.qq.com/s/9KgKTc_jtJ7bWKdbNPoqvQ) – WeChat profil, amely a zero-knowledge technológiát ismerteti - -### Cseh {#cs} - -- [Gwei.cz](https://gwei.cz) – helyi közösség a web3 körül, amely oktatási anyagokat készít, online és személyes találkozókat szervez -- [Gwei.cz Příručka](https://prirucka.gwei.cz/) – Ethereum útmutató kezdőknek -- [DAO Příručka](https://dao.gwei.cz/) – útmutató kezdőknek a DAO-okról -- [Mastering Ethereum](https://ipfs.io/ipfs/bafybeidvuxhnsgfx3tncpfxheqglkjwmdxclknlgd7s7qggd2a6bzgb27m) – Az Ethereum elsajátítása, cseh verzió - -### Francia {#fr} - -- [Ethereum France](https://www.ethereum-france.com/) – az Ethereum mentén események szervezése, tartalomkészítés, beszélgetések -- [Ethereum.fr](https://ethereum.fr/) – Ethereummal kapcsolatos hírek és oktatás -- [BanklessFR](https://banklessfr.substack.com/) – Bankless hírlevél franciául -- [CryptoFR](https://cryptofr.com/category/44/ethereum-general) – kriptovalutával kapcsolatos fórum egy Ethereum aloldallal - -### Német {#de} - -- [Microsoft Learn (Solidity)](https://docs.microsoft.com/de-de/learn/modules/blockchain-learning-solidity/) – A Solidity használata -- [Microsoft Learn (smart contracts)](https://docs.microsoft.com/de-de/learn/modules/blockchain-solidity-ethereum-smart-contracts/) – Ethereum okosszerződések írása Solidity-val -- [Microsoft Learn (Ethereum networks)](https://docs.microsoft.com/de-de/learn/modules/blockchain-ethereum-networks/) – az Ethereum-hálózatokhoz való kapcsolódás és azok telepítése -- [Microsoft Learn (blockchains)](https://docs.microsoft.com/de-de/learn/paths/ethereum-blockchain-development/) – a blokkláncfejlesztés első lépései - -### Héber {#he} - -- [Udi Wertheimer – Amit a bitcoin használók tanulhatnak az Ethereumtól](https://www.cryptojungle.co.il/udi-wertheimer-what-bitcoiners-can-learn-from-ethereum/) -- [Omer Greismen (OpenZeppelin) - Hogyan akadályoztunk meg egy 15 milliárd dolláros okosszerződés meghackelését](https://www.cryptojungle.co.il/omer-greisman-openzeppelin/) -- [Shy Datika (INX) - Tokenizálás és a kötvények jövője, beleértve azt, hogy vajon az Ethereum egy kötvény](https://www.cryptojungle.co.il/shy-datika-tokenization/) -- [Roy Confino (Lemonade) - Biztosítás az Ethereumon](https://www.cryptojungle.co.il/roy-confino-insurance/) -- [Idan Ofrat (Fireblocks) - Intézményi bevezetés](https://www.cryptojungle.co.il/idan-ofrat-fireblocks/) -- [Gal Weizman (MetaMask) - Mi az a MetaMask](https://www.cryptojungle.co.il/gal-weizman-metamask/) -- [Dror Aviely (Consensys) - Az Ethereum központja](https://www.cryptojungle.co.il/dror-aviely-ethereum-center/) -- [Nir Rozin - Egy kriptopunk élete](https://www.cryptojungle.co.il/nir-rozin-cryptopunk/) -- [Adan Kedem - Játékok és a metaverzum](https://www.cryptojungle.co.il/adan-kedem-web3-gaming/) -- [Uri Kolodny (Starkware) - Ethereum és a blokkláncrétegek](https://www.cryptojungle.co.il/uri-kolodny-starkware/) -- [Udi Wertheimer - Ethereum 2.0 vs. versenyzés](https://www.cryptojungle.co.il/udi-on-eth2/) -- [Ben Samocha (myself) - Ethereum 2.0 - egy lehetőség?](https://www.cryptojungle.co.il/etherurm2-week-summary/) -- [Alon Muroch (Bloxstaking) - Mi az Ethereum 2.0?](https://www.cryptojungle.co.il/alon-moroch-eth2/) -- [Eilon Aviv (Collider Ventures) - Mi sülhet el rosszul az Ethereum 2.0-val](https://www.cryptojungle.co.il/eilon-aviv-eth2-0/) -- [Eilon Aviv (Collider Ventures) - Miért van szükség Ethereum 2.0-ra](https://www.cryptojungle.co.il/eilon-aviv-ethereum-2-0/) - -### Olasz {#it} - -- [Ethereum Italia](https://www.ethereum-italia.it/) – Ethereummal kapcsolatos oktatás, események és hírek, főleg az okosszerződésekről és a blokklánc-technológiáról -- [Ethereum Italia Podcast](https://www.ethereum-italia.it/podcast/) – Ethereum podcast olaszul -- [Microsoft Learn (Solidity)](https://docs.microsoft.com/it-it/learn/modules/blockchain-learning-solidity/) – A Solidity használatának bemutatása -- [Microsoft Learn (Smart contracts)](https://docs.microsoft.com/it-it/learn/modules/blockchain-solidity-ethereum-smart-contracts/) – Okosszerződések írása a Solidity-val -- [Microsoft Learn (dapps)](https://docs.microsoft.com/it-it/learn/modules/blockchain-create-ui-decentralized-apps/) – felhasználói felület létrehozása decentralizált alkalmazásokkal - -### Japán {#ja} - -- [Japán virtuális és kriptoeszközök tőzsdei szövetsége](https://jvcea.or.jp/) -- [Japán kriptoeszközök üzleti szövetsége](https://cryptocurrency-association.org/) -- [A blokkláncfejlesztés első lépései – Oktatási anyagok | Microsoft Docs](https://docs.microsoft.com/ja-jp/learn/paths/ethereum-blockchain-development/) – a blokkláncba és fejlesztésbe való bevezetés az Ethereum platformon -- [Mastering Ethereum](https://www.oreilly.co.jp/books/9784873118963/) – Az Ethereum elsajátítása, japán verzió -- [Hands-On Smart Contract Development with Solidity and Ethereum](https://www.oreilly.co.jp/books/9784873119342/) – okosszerződés fejlesztés Solidity-val az Ethereumon japánul - -### Orosz {#ru} - -- [Cyber Academy](https://cyberacademy.dev) – Oktatási anyagok web3-fejlesztők számára -- [Forklog](https://forklog.com) - hírek és oktatási cikkek a kriptóról általában, a különféle blokkláncok létező technológiáiról és a jövőbeli fejlesztéseiről -- [BeInCrypto](https://ru.beincrypto.com) - hírek, kriptoárelemzések és nem technikai cikkek egyszerű magyarázatokkal mindenről, ami kripto - -### Spanyol {#es} - -- [Ethereum Madrid](https://ethereummadrid.com/) – blokklánc, DeFi és irányítási tanfolyamok, események és blog -- [Cointelegraph](https://es.cointelegraph.com/ethereum-for-beginners) – Ethereum útmutató kezdőknek spanyolul -- [Tutoriales online](https://tutoriales.online/curso/solidity) – sajátítsa el a Solidity használatát és programozást az Ethereumon -- [Curso Introducción a Ethereum Development](https://youtube.com/playlist?list=PLTqiwJDd_R8y9pfUBjhkVa1IDMwyQz-fU) – A Solidity alapjai, az első okosszerződések tesztelése és telepítése -- [Curso Introducción a Seguridad y Hacking en Ethereum](https://youtube.com/playlist?list=PLTqiwJDd_R8yHOvteko_DmUxUTMHnlfci) – gyakori sebezhető pontok és biztonsági problémák a valódi okosszerződésekben -- [Curso Introducción a DeFi Development](https://youtube.com/playlist?list=PLTqiwJDd_R8zZiP9_jNdaPqA3HqoW2lrS) – tanulja meg, hogyan működnek a DeFi okosszerződések a Solidity-ben és készítse el a saját automata Market Maker-ét -- [Cryptoversidad](https://www.youtube.com/c/Cryptoversidad) – Nem technikai blokkláncok oktatása a kezdőtől a haladó szintig. Tudjon meg mindent a kriptóról és az Ethereumról. - -### Török {#tr} - -- [BTK Akademi](https://www.btkakademi.gov.tr/portal/course/blokzincir-ve-kripto-paralar-10569#!/about) – blokklánc- és kriptovaluta-központú tanfolyam -- [Az nagyszerű átnevezés: mi történt az Eth2-vel?](https://miningturkiye.org/konu/ethereum-madenciligi-bitiyor-mu-onemli-gelisme.655/) – török fordítása a blogpostnak, ami elmagyarázza az eth2-től való elmozdulást - -### Vietnámi {#vi} - -- [Tino Group](https://wiki.tino.org/ethereum-la-gi/) – Ethereum, dapp-ok, tárcák áttekintése és gyakran ismételt kérdések -- [Tap Chi Bitcoin](https://tapchibitcoin.io/tap-chi/tin-tuc-ethereum-eth) – webplatform Ethereummal kapcsolatos hírekkel és oktatással -- [Coin68](https://coin68.com/ethereum-tieu-diem/) – kriptovaluta-portál Ethereummel kapcsolatos hírekkel és oktatási anyagokkal diff --git a/public/content/translations/hu/14) Community Pages/community/online/index.md b/public/content/translations/hu/14) Community Pages/community/online/index.md deleted file mode 100644 index f93382c295f..00000000000 --- a/public/content/translations/hu/14) Community Pages/community/online/index.md +++ /dev/null @@ -1,75 +0,0 @@ ---- -title: Online közösségek -description: A támogatói programok listája az egész Ethereum-ökoszisztémára vonatkozóan. -lang: hu ---- - -# Online közösségek {#online-communities} - -Ethereum rajongók százezrei gyűlnek össze ezeken az online fórumokon, hogy megosszák a híreket, megbeszéljék az új fejlesztéseket, megvitassák a technikai problémákat és elképzeljék a jövőt. - -## Listázási szabály {#listing-policy} - -A felsorolt közösségek integritásának és értékének megőrzése érdekében az ethereum.org szigorú irányelveket követ a jogosultság meghatározásakor: - -### Jogosultsági kritériumok {#eligibility-criteria} - -- **Relevancia**: A közösségnek közvetlenül az Ethereumhoz és annak ökoszisztémájához kell kapcsolódnia. -- **Aktivitási szint**: A közösségnek aktívnak kell lennie, rendszeres interakciókkal, hozzászólásokkal vagy párbeszédekkel. A szunnyadó vagy inaktív közösségek eltávolíthatók. -- **Inkluzivitás**: A közösségnek olyan barátságos környezetet kell kialakítania, amely tiszteletben tartja a sokszínűséget, és ösztönzi a különböző hátterű emberek részvételét. -- **Nem kereskedelmi fókusz**: A listázás közösségi célú terek, nem kereskedelmi vagy promóciós platformok számára elérhető. - -### Tartalmi irányelvek {#content-guidelines} - -- **Megfelelő tartalom**: A közösségeknek saját moderálási irányelvekkel kell rendelkezniük, elkerülve a levélszemetet, a gyűlöletbeszédet, a zaklatást vagy bármilyen olyan tartalmat, amely illegális tevékenységet népszerűsít. -- **Nyelv**: Bár az angol az elsődleges nyelv, más nyelvű közösségeket is bátorítunk, hogy jelentkezzenek, amíg fenntartják a befogadó és tiszteletteljes légkört. -- **Átláthatóság**: A közösség céljáról, szabályairól és moderátorairól világos információknak kell a tagok számára elérhetőnek lenniük. - -### További javaslatok {#other-recommendations} - -- **Elérhetőség**: A közösségi fórumoknak mindenki számára elérhetőnek kell lenniük bejelentkezés vagy regisztráció nélkül. -- **Meghívók a Discord-szerverre**: Ajánlott, hogy csak megbízható Discord-szerver meghívók kerüljenek fel az ethereum.org-ra. Ideális esetben ezek a meghívók a weboldal közösségi oldalára (pl. [ethglobal.com/discord](https://ethglobal.com/discord)) vagy egy hivatalos URL-re (pl. [discord.gg/ethstaker](https://discord.gg/ethstaker) vagy [discord.com/invite/ethstaker](https://discord.com/invite/ethstaker)) mutatnak. - -Ha úgy gondolja, hogy egy közösséget hozzá kellene adni vagy el kellene távolítani ezen irányelvek alapján, kérjük, [nyisson egy problémát a GitHub könyvtárban](https://github.com/ethereum/ethereum-org-website/issues). - - -## Fórumok {#forums} - -r/ethereum – minden az Ethereumról -r/ethfinance – az Ethereum pénzügyi része, beleértve a decentralizált pénzügyeket (DeFi) -r/ethdev – az Ethereum fejlesztéséről -r/ethtrader – trendek és piaci elemzések -r/ethstaker – az Ethereumon történő letétbe helyezés iránt érdeklődőknek -Fellowship of Ethereum Magicians – a technikai szabványok felé orientálódó közösség -Ethereum Stackexchange – az Ethereum-fejlesztők támogatása -Ethereum Research – a legbefolyásosabb üzenőfal a kriptogazdasági kutatáshoz - -## Csevegőszobák {#chat-rooms} - -Ethereum Cat Herders – projektmanagement-támogatás az Ethereum-fejlesztésekhez -Ethereum Hackers – az ETHGlobal által üzemeltetett Discord chat: online közösség az Ethereum hackereknek világszinten -CryptoDevs – Ethereum-fejlesztésre fókuszáló Discord-közösség -EthStaker Discord – közösségi vezetésű útmutatás, oktatás, támogatás és források a meglévő és lehetséges letéteseknek -Ethereum.org website team – beszélgessen az ethereum.org web fejlesztésről és dizájnról a közösség tagjaival -Matos Discord – web3 alkotói közösség, ahol a fejlesztők, az iparági vezetők és az Ethereum rajongók találkoznak. Szenvedélyünk a web3 fejlesztés, a dizájn és a kultúra. Jöjjön és építsen velünk. -Solidity Gitter – solidity fejlesztésről (Gitter) szóló csevegés -Solidity Matrix – solidity fejlesztősről (Matrix) szóló csevegés -Ethereum Stack Exchange *–kérdések és válaszok fóruma* -Peeranha *– decentralizált kérdések és válaszok fóruma* - -## YouTube és Twitter {#youtube-and-twitter} - -Ethereum Alapítvány – legyen napra kész az Ethereum Alapítvány újdonságaival kapcsolatban -@ethereum – az Ethereum Alapítvány hivatalos profilja -@ethdotorg – portál az Ethereumhoz, a növekvő globális közösségünk számára -Nagy befolyással bíró Ethereum Twitter-fiókok listája - - - - -
- - Tudjon meg többet a DAO-król - -
- diff --git a/public/content/translations/hu/14) Community Pages/community/research/index.md b/public/content/translations/hu/14) Community Pages/community/research/index.md deleted file mode 100644 index f5b68e42663..00000000000 --- a/public/content/translations/hu/14) Community Pages/community/research/index.md +++ /dev/null @@ -1,399 +0,0 @@ ---- -title: Az Ethereum-kutatás aktív területei -description: Fedezze fel a nyitott kutatás különféle területeit, és hogy hogyan tud Ön is bekapcsolódni. -lang: hu ---- - -# Az Ethereum-kutatás aktív területei {#active-areas-of-ethereum-research} - -Az Ethereum egyik fontos erőssége, hogy egy aktív kutatási és mérnöki közösség folyamatosan fejleszti. Számtalan lelkes és képzett ember a világ minden táján szeretné belevetni magát a jelenlegi problémák megoldásába, de gyakran nem könnyű megtalálni, hogy mik is a problémák. Ez az oldal körvonalazza a legfontosabb aktív kutatási területeket. - -## Hogyan működik az Ethereum-kutatás {#how-ethereum-research-works} - -Az Ethereum-kutatás nyitott és transzparens, a [decentralizált tudomány (DeSci)](https://hackernoon.com/desci-decentralized-science-as-our-chance-to-recover-the-real-science) elveit testesítve meg. Olyan kultúrát követünk, amely a kutatási eszközöket és eredményeket olyan nyilvánossá és interaktívvá teszi, amennyire csak lehetséges, például a végrehajtható fájlok révén. Az Ethereum-kutatás gyorsan halad, az új eredményeket nyilvánosan posztolják és megvitatják az olyan fórumokon, mint az [ethresear.ch](https://ethresear.ch/), ahelyett hogy a hagyományos módon, a véleményezések után adnák ki a nyilvánosságnak. - -## Általános kutatási források {#general-research-resources} - -Minden téma gazdag forrásanyagban bővelkedik az [ethreser.ch](https://ethresear.ch) és az [Eth R&D Discord csatornán](https://discord.gg/qGpsxSA). Ezek a főbb helyek, ahol a kutatók megvitatják a legutóbbi ötleteket és fejlesztési lehetőségeket. - -Ezt a riportot 2022. májusában készítette a [DelphiDigital](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum), melyben kiváló áttekintést adnak az Ethereum fejlesztési tervéről (roadmap). - -## Finanszírozási források {#sources-of-funding} - -Ön is bekapcsolódhat az Ethereum-kutatásba, és kereshet vele! Például az [Ethereum Alapítvány](/foundation/) nemrég adott [akadémikus finanszírozási támogatásokat](https://esp.ethereum.foundation/academic-grants). Az [Ethereum-támogatások oldalon](/community/grants/) megtalálhatja az aktív és jövőbeli finanszírozási lehetőségeket. - -## Protokollkutatás {#protocol-research} - -A protokollkutatás az Ethereum alaprétegével foglalkozik – szabályok összessége, hogy a csomópontok hogyan kapcsolódnak, kommunikálnak, cserélik és tárolják az adatot, és hogyan jutnak konszenzusra a blokklánc státuszát illetően. A protokollkutatás két fő kategóriára oszlik: konszenzus és végrehajtási. - -### Konszenzus {#consensus} - -A konszenzuskutatás az [Ethereum proof-of-stake mechanizmusával](/developers/docs/consensus-mechanisms/pos/) foglalkozik. Néhány példa: - -- sebezhető pontok azonosítása és befedése; -- a kriptogazdasági biztonság mérése; -- a kliensbevezetések biztonságának vagy teljesítményének növelése; -- és könnyű kliensek fejlesztése. - -Emellett a jövőbe előretekintő kutatások, a protokoll alapvető újratervezése, mint amilyen az egy sloton belüli véglegesedés is, jelentős fejlődést tudnának hozni az Ethereum számára. Továbbá a peer-to-peer hálózat hatékonysága, biztonsága és monitorozása a konszenzus kliensek között is fontos terület. - -#### Háttérolvasmányok {#background-reading} - -- [Bevezetés a proof-of-stake mechanizmusba](/developers/docs/consensus-mechanisms/pos/) -- [Casper-FFG dokumentáció](https://arxiv.org/abs/1710.09437) -- [Casper-FFG magyarázat](https://arxiv.org/abs/1710.09437) -- [Gasper dokumentáció](https://arxiv.org/abs/2003.03052) - -#### Jelenlegi kutatás {#recent-research} - -- [Ethresear.ch konszenzus](https://ethresear.ch/c/consensus/29) -- [Elérhetőségi/véglegességi dilemma](https://arxiv.org/abs/2009.04987) -- [Egy sloton belüli véglegesség](https://ethresear.ch/t/a-model-for-cumulative-committee-based-finality/10259) -- [Javaslattevő-építő elkülönítés](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance) - -### Végrehajtás {#execution} - -A végrehajtási réteg a tranzakciók feldolgozását végzi, az [Ethereum virtuális gépet (EVM)](/developers/docs/evm/) futtatja és végrehajtási csomagokat küld a konszenzusrétegnek. Számos aktív kutatási terület van, beleértve: - -- a könnyű kliens támogatás kiépítése; -- gáz korlátok kutatása; -- és új adatstruktúrák (pl. Verkle-fák) beépítése. - -#### Háttérolvasmányok {#background-reading-1} - -- [Bevezetés az EVM-be](/developers/docs/evm) -- [Ethresear.ch konszenzusréteg](https://ethresear.ch/c/execution-layer-research/37) - -#### Jelenlegi kutatás {#recent-research-1} - -- [Adatbázis-optimalizálások](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/db_faq.md) -- [Státuszlejárat](https://notes.ethereum.org/@vbuterin/state_expiry_eip) -- [A státuszlejárathoz vezető út](https://hackmd.io/@vbuterin/state_expiry_paths) -- [Verkle és státuszlejárat-javaslat](https://notes.ethereum.org/@vbuterin/verkle_and_state_expiry_proposal) -- [Előzményadatok kezelése](https://eips.ethereum.org/EIPS/eip-4444) -- [Verkle-fák](https://vitalik.eth.limo/general/2021/06/18/verkle.html) -- [Adatelérhetőségi mintavétel](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding) - -## Kliensfejlesztés {#client-development} - -Az Ethereum kliensek az Ethereum protokoll implementációi. A kliensfejlesztés teszi lehetővé, hogy a protokoll kutatás eredményei valósággá váljanak azáltal, hogy ezekbe a kliensekbe beépítik azokat. A kliens fejlesztés magába foglalja a kliensspecifikációk frissítését és specifikus implementációk beépítését. - -Az Ethereum-csomópontok két szoftvert futtatnak: - -1. a konszenzuskliens a blokklánc elejét/fejét trekkeli, elterjeszti a blokkokat (pletyka) és kezeli a konszenzus logikáját -2. a végrehajtási kliens az Ethereum virtuális gépet támogatja, valamint a tranzakciókat és okosszerződéseket futtatja - -Bővebb információkért tekintse át a [node-ok és kliensek oldalt](/developers/docs/nodes-and-clients/), ahol a jelenlegi kliensbevezetések listáját is megtalálja. Az Ethereum-fejlesztésekről is találhat információkat az [Ethereum története oldalon](/history/). - -### Végrehajtási kliensek {#execution-clients} - -- [Végrehajtásikliens-specifikáció](https://github.com/ethereum/execution-specs) -- [Végrehajtási API-specifikáció](https://github.com/ethereum/execution-apis) - -### Konszenzuskliensek {#consensus-clients} - -- [Konszenzuskliens-specifikáció](https://github.com/ethereum/consensus-specs) -- [Beacon API-specifikáció](https://ethereum.github.io/beacon-APIs/#/Beacon/getStateRoot) - -## Skálázás és teljesítmény {#scaling-and-performance} - -Az Ethereum skálázása egy hatalmas kutatási terület. A jelenlegi megközelítések felölelik a rollupokba történő tranzakciógyűjtést, ami az adatblobok használatával rendkívül olcsó lesz a felhasználók számára. A skálázás áttekintését megtalálja a [skálázási oldalon](/developers/docs/scaling). - -### Második blokkláncréteg (L2) {#layer-2} - -Jelenleg több második blokkláncréteg (L2) protokoll létezik, ami az Ethereumot skálázza, amelyek különféle technikákkal csomagolják össze a tranzakciókat és biztosítják azokat az L1 rétegen. Ez egy gyorsan fejlődő téma rengeteg kutatási és fejlesztési potenciállal. - -#### Háttérolvasmányok {#background-reading-2} - -- [Bevezetés az L2-be](/layer-2/) -- [Polynya: rollupok, adatelérhetőségi rétegek (DA) és moduláris láncok](https://polynya.medium.com/rollups-data-availability-layers-modular-blockchains-introductory-meta-post-5a1e7a60119d) - -#### Jelenlegi kutatás {#recent-research-2} - -- [A helyes sorbarendezés a szekvenszereknél az Arbitrumnál](https://eprint.iacr.org/2021/1465) -- [ethresear.ch L2](https://ethresear.ch/c/layer-2/32) -- [Rollupra fókuszáló ütemterv](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) -- [L2Beat](https://l2beat.com/) - -### Hidak {#bridges} - -Az L2 az egyik területe még több kutatást és fejlesztést igényel – ez pedig nem más, mint a hidak biztonsága és teljesítménye. Ez a különböző L2 megoldások közötti hidakra, valamint az L1 és L2 közötti hidakra vonatkozik. Fontos terület, mert gyakori célpontja a támadásoknak. - -#### Háttérolvasmányok {#background-reading-3} - -- [Bevezetés a blokklánchidak működésébe](/bridges/) -- [Vitalik a hidakról](https://old.reddit.com/r/ethereum/comments/rwojtk/ama_we_are_the_efs_research_team_pt_7_07_january/hrngyk8/) -- [Blokklánc-hidak cikk](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) -- [A hidakba ragadt érték](https://dune.com/eliasimos/Bridge-Away-\(from-Ethereum\)) - -#### Jelenlegi kutatás {#recent-research-3} - -- [Hidak validálása](https://stonecoldpat.github.io/images/validatingbridges.pdf) - -### Szilánkolás (sharding) {#sharding} - -Az Ethereum-blokklánc shardingja már régóta része a terveknek. Míg az új skálázási megoldások, mint a Danksharding, mostanában kerülnek a középpontba. - -A teljes Danksharding előzménye, a Proto-Danksharding a Cancun-Deneb („Dencun”) hálózati frissítéssel került bevezetésre. - -[További információ a Dencun hálózatfrissítésről](/roadmap/dencun/) - -#### Háttérolvasmányok {#background-reading-4} - -- [Proto-Danksharding jegyzetek](https://notes.ethereum.org/@vbuterin/proto_danksharding_faq) -- [Bankless Danksharding video](https://www.youtube.com/watch?v=N5p0TB77flM) -- [Ethereum sharding kutatási összefoglaló](https://notes.ethereum.org/@serenity/H1PGqDhpm?type=view) -- [Danksharding (Polynya)](https://polynya.medium.com/danksharding-36dc0c8067fe) - -#### Jelenlegi kutatás {#recent-research-4} - -- [EIP-4844: Proto-Danksharding](https://eips.ethereum.org/EIPS/eip-4844) -- [Vitalik a shardingról és az adatelérhetőségi mintavételről](https://hackmd.io/@vbuterin/sharding_proposal) - -### Hardver {#hardware} - -A [csomópontok futtatása](/developers/docs/nodes-and-clients/run-a-node/) szerényebb hardvereken alapvető lenne az Ethereum decentralizáltan tartásához. Ezért a hardverszükségletek minimalizálása is fontos kutatási terület. - -#### Háttérolvasmányok {#background-reading-5} - -- [Ethereum az ARM-ról](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) - -#### Jelenlegi kutatás {#recent-research-5} - -- [ecdsa az FPGA-król](https://ethresear.ch/t/does-ecdsa-on-fpga-solve-the-scaling-problem/6738) - -## Biztonság {#security} - -A biztonság nagyon kiterjedt téma, beleértjük a szemetelés (spam) és család elleni védelmet, a tárca-, hardver- és kriptogazdasági biztonságot, az alkalmazások és kliensszoftverekben való hibakeresést és ezek tesztelését, valamint a kulcskezelést is. E területek mélyebb feltárása hozzájárul a szélesebb körű alkalmazáshoz. - -### Kriptográfia & ZKP {#cryptography--zkp} - -A zero-knowledge bizonyítékok (ZKP) és a kriptográfia kritikus a személyes adatok védelme és a biztonság szempontjából. A zero-knowledge egy viszonylag új, de gyorsan fejlődő ág, számos nyitott kutatási és fejlesztési lehetőségekkel. Néhány kiemelt lehetőség, például a hatékonyabb implementációja a [Keccak hashing algoritmusnak](https://hackmd.io/sK7v0lr8Txi1bgION1rRpw?view#Overview), jobb polinomiális kommitmentek találása vagy az ecdsa nyilvános kulcsok és aláírás ellenőrző hálózatok költségének csökkentése. - -#### Háttérolvasmányok {#background-reading-6} - -- [0xparc blog](https://0xparc.org/blog) -- [zkp.science](https://zkp.science/) -- [Zero Knowledge podcast](https://zeroknowledge.fm/) - -#### Jelenlegi kutatás {#recent-research-6} - -- [Jelenlegi előrehaladás az elliptikus görbe kriptográfiában](https://ethresear.ch/t/the-ec-fft-algorithm-without-elliptic-curve-and-isogenies/11346) -- [Ethresear.ch ZK](https://ethresear.ch/c/zk-s-nt-arks/13) - -### Tárcák {#wallets} - -Az Ethereum-tárcák lehetnek böngészőkiterjesztések, asztali gépen és mobilon lévő alkalmazások vagy okosszerződések az Ethereumon. Aktív kutatás folyik a hagyományos módon visszaállítható tárcák területén, hogy az egyéni felhasználói kulcs kezelése kevesebb kockázatot jelentsen. A tárcák fejlődéséhez kapcsolódik az éppen születő kutatási terület a számlaabsztrakciók alternatív formáiról. - -#### Háttérolvasmányok {#background-reading-7} - -- [Bevezetés a tárcákba](/wallets/) -- [Bevezetés a tárcabiztonságba](/security/) -- [ethresear.ch biztonság](https://ethresear.ch/tag/security) -- [EIP-2938 Számlaabsztrakció](https://eips.ethereum.org/EIPS/eip-2938) -- [EIP-4337 Számlaabsztrakció](https://eips.ethereum.org/EIPS/eip-4337) - -#### Jelenlegi kutatás {#recent-research-7} - -- [Validációfókuszú okosszerződéses tárcák](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) -- [A számlák jövője](https://ethereum-magicians.org/t/validation-focused-smart-contract-wallets/6603) -- [EIP-3074 AUTH és AUTHCALL opkódok](https://eips.ethereum.org/EIPS/eip-3074) -- [Kód publikálása egy EOA címen](https://eips.ethereum.org/EIPS/eip-5003) - -## Közösség, oktatás és a felhasználók elérése {#community-education-and-outreach} - -Az új felhasználók bevezetése az Ethereumra új oktatási anyagokat igényel és új megközelítéseket az emberek elérésére. Ezek lehetnek blogbejegyzések és cikkek, könyvek, podcastok, mémek, oktatási anyagok, események és bármi más, ami közösséget épít, fogadja az újonnan érkezőket és tanítja őket az Ethereumról. - -### UX/UI {#uxui} - -Ahhoz, hogy több embert lehessen bevezetni az Ethereum világába, fejleszteni kell a felhasználói élményt / kezelőfelületet (UX/UI). Ehhez a dizájnerek és termékszakértők meg kell vizsgálják a tárcák és alkalmazások dizájnját. - -#### Háttérolvasmányok {#background-reading-8} - -- [Ethresear.ch UX/UI](https://ethresear.ch/c/ui-ux/24) - -#### Jelenlegi kutatás {#recent-research-8} - -- [Web3 tervezés Discord](https://discord.gg/FsCFPMTSm9) -- [Web3 tervezési elvek](https://www.web3designprinciples.com/) -- [Ethereum Magicians UX egyeztetések](https://ethereum-magicians.org/t/og-council-ux-follow-up/9032/3) - -### Gazdaság {#economics} - -Az Ethereumban a gazdasági kutatás nagyjából két megközelítés mentén zajlik: a mechanizmusok biztonságának validálása, melyek a gazdasági ösztönzőkön alapulnak (mikroökonómia), valamint a protokoll, az alkalmazások és a felhasználók közötti értékáramlás elemzése (makroökonómia). Összetett kriptogazdasági tényezők állnak fenn az Ethereum saját eszközei (ether) és a rá épülő tokenek (mint NFT-k és ERC20 tokenek) kapcsán. - -#### Háttérolvasmányok {#background-reading-9} - -- [Robust Incentives Group](https://ethereum.github.io/rig/) -- [ETHconomics workshop a Devconnect-en](https://www.youtube.com/playlist?list=PLTLjFJ0OQOj5PHRvA2snoOKt2udVsyXEm) - -#### Jelenlegi kutatás {#recent-research-9} - -- [EIP1559 empírikus elemzése](https://arxiv.org/abs/2201.05574) -- [A kínálati egyensúly megközelítése](https://ethresear.ch/t/circulating-supply-equilibrium-for-ethereum-and-minimum-viable-issuance-during-the-proof-of-stake-era/10954) -- [A MEV tényleges mennyisége: mennyire sötét az erdő?](https://arxiv.org/abs/2101.05511) - -### Blokkméret és díjpiacok {#blockspace-fee-markets} - -A blokkméretpiacok irányítják, hogy a felhasználó tranzakciói közvetlenül az Ethereumban (L1) vagy hidakkal összekötött hálózatokon keresztül (pl. rollupok (L2)) kerülnek-e be a blokkláncba. Az Ethereumon a tranzakciók a díjpiacra kerülnek, melyet az EIP-1559 mentén vezettek be a protokollba, hogy ne lehessen szemeteléssel (spam) és ártorlódással veszélyeztetni a láncot. Mindkét rétegen a tranzakciók externáliákat hoznak létre, melyet maximálisan kinyerhető értéknek (MEV) neveznek, és új piaci struktúrát eszközölt, hogy ezt megszerezze vagy kezelje. - -#### Háttérolvasmányok {#background-reading-10} - -- [A tranzakciós díj mechanizmusterve az Ethereum blokkláncra: Az EIP-1559 gazdasági elemzése (Tim Roughgarden, 2020.)](https://timroughgarden.org/papers/eip1559.pdf) -- [EIP-1559 szimulációk (Robust Incentives Group)](https://ethereum.github.io/abm1559) -- [Rollupok gazdasága az első elvektől](https://barnabe.substack.com/p/understanding-rollup-economics-from?utm_source=url) -- [Flash Boys 2.0: beelőzés (frontrunning), tranzakcióátrendezés és konszenzusinstabilitás a decentralizált tőzsdéken](https://arxiv.org/abs/1904.05234) - -#### Jelenlegi kutatás {#recent-research-10} - -- [Multidimenzionális EIP-1559 videoprezentáció](https://youtu.be/QbR4MTgnCko) -- [Területek közötti MEV](http://arxiv.org/abs/2112.01472) -- [MEV-aukciók](https://ethresear.ch/t/mev-auction-auctioning-transaction-ordering-rights-as-a-solution-to-miner-extractable-value/6788) - -### Proof-of-stake ösztönzők {#proof-of-stake-incentives} - -A validátorok az Ethereum saját eszközét (ether) használják fedezetként a rosszhiszemű viselkedés ellen. Ennek kriptogazdasága határozza meg a hálózat biztonságát. A szofisztikált validátorok talán képesek kihasználni az ösztönző réteg finom részleteit, hogy támadást indítsanak. - -#### Háttérolvasmányok {#background-reading-11} - -- [Ethereum gazdasági mesterkurzus és gazdasági modell](https://github.com/CADLabs/ethereum-economic-model) -- [A PoS ösztönzők szimulációja (Robust Incentives Group)](https://ethereum.github.io/beaconrunner/) - -#### Jelenlegi kutatás {#recent-research-11} - -- [A tranzakciók cenzúrának való ellenállásának növelése a javaslattevő/építő elkülönítéssel (PBS)](https://notes.ethereum.org/s3JToeApTx6CKLJt8AbhFQ) -- [Három támadás a PoS Ethereumon](https://arxiv.org/abs/2110.10086) - -### Likvid letétbe helyezés és derivatívák {#liquid-staking-and-derivatives} - -A likvid letétbe helyezés lehetővé teszi, hogy a 32 ETH-nél kevesebbel rendelkező felhasználók is részesüljenek jutalomban azáltal, hogy az ETH-t átváltják letétbe helyezett ethert képviselő tokenre, amit a decentralizált pénzügyekben (DeFi) használni lehet. Ugyanakkor az ezzel kapcsolatos ösztönzők és piaci dinamizmusok még feltárásra várnak, az Ethereum biztonságra gyakorolt hatásukkal együtt (pl. centralizáció kockázata). - -#### Háttérolvasmányok {#background-reading-12} - -- [Ethresear.ch likvid letétbe helyezés](https://ethresear.ch/search?q=liquid%20staking) -- [Lido: A bizalomigénymentes letétbe helyezéshez vezető út az Ethereumon](https://blog.lido.fi/the-road-to-trustless-ethereum-staking/) -- [Rocket Pool: Bevezető a letétbe helyezési protokollba](https://medium.com/rocket-pool/rocket-pool-staking-protocol-part-1-8be4859e5fbd) - -#### Jelenlegi kutatás {#recent-research-12} - -- [A Lido-tól való visszavonások kezelése](https://ethresear.ch/t/handling-withdrawals-in-lidos-eth-liquid-staking-protocol/8873) -- [A visszavonási hitelesítő adatok](https://ethresear.ch/t/withdrawal-credential-rotation-from-bls-to-eth1/8722) -- [A likvid letéti derivatívák kockázatai](https://notes.ethereum.org/@djrtwo/risks-of-lsd) - -## Tesztelés {#testing} - -### Formális ellenőrzés {#formal-verification} - -A formális ellenőrzés egy olyan kód, amely igazolja, hogy az Ethereum konszenzusspecifikációi helyesek, és nincs bennük hiba. A specifikációnak van egy végrehajtható verziója, melyet Python nyelven írtak, és ami fenntartást és fejlesztést igényel. A kutatás segíthet feltárni ennek a specifikációimplementációnak a fejlesztési lehetőségeit, és eszközöket biztosíthat, hogy az ellenőrzés robusztusabb legyen. - -#### Háttérolvasmányok {#background-reading-13} - -- [Bevezetés a formális ellenőrzésbe](https://ptolemy.berkeley.edu/projects/embedded/research/vis/doc/VisUser/vis_user/node4.html) -- [Formális ellenőrzés (Intel)](https://www.cl.cam.ac.uk/~jrh13/papers/mark10.pdf) - -#### Jelenlegi kutatás {#recent-research-13} - -- [A letéti szerződés formális ellenőrzése](https://github.com/runtimeverification/deposit-contract-verification) -- [A Beacon-lánc specifikációjának formális ellenőrzése](https://github.com/runtimeverification/deposit-contract-verification) - -## Adattudomány és elemzés {#data-science-and-analytics} - -Több adatelemzési eszközre és irányítópultra van szükség, hogy részletes adatokat nyújtson az Ethereum működéséről és a hálózat egészségéről. - -### Háttérolvasmányok {#background-reading-14} - -- [Dune elemzések](https://dune.com/browse/dashboards) -- [Kliensdiverzitási irányítópult](https://clientdiversity.org/) - -#### Jelenlegi kutatás {#recent-research-14} - -- [Robust Incentives Group adatelemzése](https://ethereum.github.io/rig/) - -## Alkalmazások és eszközök {#apps-and-tooling} - -Az alkalmazási réteg a programok kiterjedt ökoszisztémáját támogatja, melyek tranzakciókat hajtanak végre az Ethereum alaprétegén. A fejlesztői csapatok állandón új utakat találnak az Ethereum felhasználására, hogy átjárható, engedélymentes és cenzúrának ellenálló alkalmazásokat készítsenek, egyrészt a fontos web2 eszközök mását, másrészt teljesen új web3-koncepciókat. Eközben olyan új eszközöket fejlesztenek, melyekkel a dappok Ethereumra való építése kevésbé bonyolulttá válik. - -### DeFi {#defi} - -A decentralizált pénzügyek (DeFi) az egyik elsődleges alkalmazáscsoport, melyet az Ethereumra építettek. Ennek célja az egymásra illeszthető „pénz építőkockák” létrehozása, amellyel a felhasználók tárolnak, küldenek, kölcsönöznek, kölcsönvesznek és befektetnek kriptoeszközöket az okosszerződések használatával. A DeFi egy gyorsan fejlődő terület, mely folyamatosan megújul. Folyamatos igény van a biztonságos, hatékony és elérhető protokollokra. - -#### Háttérolvasmányok {#background-reading-15} - -- [DeFi](/defi/) -- [Coinbase: Mi az a DeFi?](https://www.coinbase.com/learn/crypto-basics/what-is-defi) - -#### Jelenlegi kutatás {#recent-research-15} - -- [Decentralizált pénzügyek, centralizált tulajdonjog?](https://arxiv.org/pdf/2012.09306.pdf) -- [Optimism: A sub-dollár tranzakciókhoz vezető út](https://medium.com/ethereum-optimism/the-road-to-sub-dollar-transactions-part-2-compression-edition-6bb2890e3e92) - -### DAO-k {#daos} - -Az Ethereum képes arra, hogy decentralizált módon irányítson a decentralizált autonóm szervezetek (DAO) segítségével. Sok aktív kutatás folyik, hogy hogyan lehetne fejleszteni a DAO-kat az Ethereumon, felhasználni azokat az irányítás fejlettebb formáira, mint egy minimális bizalmat igénylő, koordinációs eszköz, mely nagyban kiterjeszti az emberek opcióit a hagyományos szervezeteken túlra. - -#### Háttérolvasmányok {#background-reading-16} - -- [Bevezetés a DAO-kba](/dao/) -- [Dao Collective](https://daocollective.xyz/) - -#### Jelenlegi kutatás {#recent-research-16} - -- [A DAO ökoszisztéma térképe](https://www.researchgate.net/publication/358694594_Mapping_out_the_DAO_Ecosystem_and_Assessing_DAO_Autonomy) - -### Fejlesztői eszközök {#developer-tools} - -Az Ethereum-fejlesztők eszközei gyorsan fejlődnek. Ezen a területen is sok aktív kutatás folyik. - -#### Háttérolvasmányok {#background-reading-17} - -- [Eszközök programozási nyelv szerint](/developers/docs/programming-languages/) -- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) -- [Konszenzusfejlesztői eszközök listája](https://github.com/ConsenSys/ethereum-developer-tools-list) -- [Tokenszabványok](/developers/docs/standards/tokens/) -- [CryptoDevHub: EVM eszközök](https://cryptodevhub.io/wiki/ethereum-virtual-machine-tools) - -#### Jelenlegi kutatás {#recent-research-17} - -- [Eth R&D Discord konszenzus eszközök csatornája](https://discordapp.com/channels/595666850260713488/746343380900118528) - -### Orákulumok {#oracles} - -Az orákulumok importálják be a láncon kívüli adatokat a blokkláncra egy engedélymentes és decentralizált módon. Mivel ez az adat a láncon belül van, ezért a dappok képesek lekövetni a világ változásait, mint a valódi eszközök árfluktuációja, a láncon kívüli alkalmazások adatai vagy akár az időjárásváltozás. - -#### Háttérolvasmányok {#background-reading-18} - -- [Bevezetés az orákulumokba](/developers/docs/oracles/) - -#### Jelenlegi kutatás {#recent-research-18} - -- [A blokklánc-orákulumok áttekintése](https://arxiv.org/pdf/2004.07140.pdf) -- [Chainlink fehérkönyv](https://chain.link/whitepaper) - -### Alkalmazások biztonsága {#app-security} - -Az Ethereum elleni támadások általában az egyéni alkalmazások gyenge pontjait használják ki, nem a protokollét. A támadók és az alkalmazásfejlesztők egy fegyverkezési versenybe kényszerültek, hogy új támadásokat és új védekezéseket fejlesszenek. Ebből az következik, hogy mindig fontos a kutatás és fejlesztés, hogy az alkalmazások biztonságban legyenek. - -#### Háttérolvasmányok {#background-reading-19} - -- [Féreglyuk-kihasználási jelentés](https://blog.chainalysis.com/reports/wormhole-hack-february-2022/) -- [Az Ethereum-szerződések meghackelésének vizsgálatai](https://forum.openzeppelin.com/t/list-of-ethereum-smart-contracts-post-mortems/1191) -- [Rekt hírek](https://twitter.com/RektHQ?s=20\&t=3otjYQdM9Bqk8k3n1a1Adg) - -#### Jelenlegi kutatás {#recent-research-19} - -- [ethresear.ch alkalmazások](https://ethresear.ch/c/applications/18) - -### Technológiai stack {#technology-stack} - -A teljes Ethereum-technológiai köteg decentralizálása is egy érdekes kutatási terület. Jelenleg az Ethereum dappoknak gyakran vannak centralizációs pontjai, mert központi eszközökön vagy infrastruktúrán alapulnak. - -#### Háttérolvasmányok {#background-reading-20} - -- [Ethereum stack](/developers/docs/ethereum-stack/) -- [Coinbase: Bevezetés a web3 stackbe](https://blog.coinbase.com/a-simple-guide-to-the-web3-stack-785240e557f0) -- [Bevezetés az okosszerződésekbe](/developers/docs/smart-contracts/) -- [Bevezetés a decentralizált tárhelybe](/developers/docs/storage/) - -#### Jelenlegi kutatás {#recent-research-20} - -- [Okosszerződések összeilleszthetősége](/developers/docs/smart-contracts/composability/) diff --git a/public/content/translations/hu/14) Community Pages/community/support/index.md b/public/content/translations/hu/14) Community Pages/community/support/index.md deleted file mode 100644 index 707142b32f3..00000000000 --- a/public/content/translations/hu/14) Community Pages/community/support/index.md +++ /dev/null @@ -1,105 +0,0 @@ ---- -title: Ethereum támogatás -description: Kapjon támogatást az Ethereum-ökoszisztémában. -lang: hu ---- - -# Ethereum támogatás {#support} - -## Hivatalos Ethereum ügyfélszolgálat {#official-support} - -Egy hivatalos Ethereum ügyfélszolgálatot keres? Tudnia kell, hogy az Ethereum decentralizált. Nincs központi szervezet, entitás vagy ember, aki birtokolná az Ethereumot, ezért nincs hivatalos ügyfélszolgálat vagy támogatói csapat sem. - -Ezt azért is fontos megérteni, mert **bárki jelentkezik Önnél, mint hivatalos ügyfélszolgálatos, az csak csaló lehet!** A csalókkal szemben a legjobb védekezés, ha Ön mindig jól informált és komolyan veszi a saját biztonságát. - - - Ethereum-biztonság és átverés elleni védelem - - - - Ismerje meg az Ethereum alapjait - - -Amellett, hogy nincs hivatalos ügyfélszolgálat, számtalan csoport, közösség és projekt szeretne Önnek segíteni, illetve rengeteg hasznos információ és forrás áll rendelkezésre ezeken az oldalakon. További kérdése van? Csatlakozzon az [ethereum.org Discord](/discord/) csatornához, és megpróbálunk segíteni. - -## Gyakran ismételt kérdések {#faq} - -### Rossz tárcába küldtem az ETH-t {#wrong-wallet} - -Az Ethereumon küldött tranzakció visszavonhatatlan. Sajnos, ha rossz pénztárcába küldte az ETH-t, nincs mód arra, hogy visszaszerezze ezeket az összegeket. Nincs központi szervezet, entitás vagy személy, aki birtokolja az Ethereumot, tehát nincs, aki visszafordítaná a tranzakciót. Ezért létfontosságú, hogy mindig ellenőrizze a tranzakcióit, mielőtt elküldi azokat. - -### Hogyan juthatok hozzá az Ethereum-ajándékhoz? {#giveaway-scam} - -Az Ethereum ajándékok csalások, amik el akarják lopni az Ön ETH-ját. Ne essen kísértésbe az olyan ajánlatoktól, amelyek túl szépnek tűnnek ahhoz, hogy igazak legyenek – ha az ETH-t egy ajándékcímre küldi, akkor nem kap ajándékot, és nem tudja visszaszerezni a pénzét. - -[Bővebben a csalás elkerüléséről](/security/#common-scams) - -### A tranzakcióm beragadt {#stuck-transaction} - -A tranzakciók az Ethereumon néha várakoznak, ha a tranzakciós díj alacsonyabb, mint amit épp megkíván a hálózati kereslet. Számos tárcában lehetősége van újraküldeni ugyanazt a tranzakciót egy magasabb díjjal, hogy az át tudjon menni. Alternatívaként leállíthatja a függőben lévő tételt úgy, hogy egy tranzakciót küld a címéről és ugyanazt a Nonce-t használja, mint a függőben lévő tételnél. - -[Hogyan lehet felgyorsítani vagy leállítani a függő tranzakciókat a MetaMaskon](https://metamask.zendesk.com/hc/en-us/articles/360015489251-How-to-speed-up-or-cancel-a-pending-transaction) - -[Hogyan lehet leállítani a függőben lévő Ethereum-tranzakciókat](https://info.etherscan.com/how-to-cancel-ethereum-pending-transactions/) - -### Hogyan lehet Ethereumot bányászni? {#mining-ethereum} - -Az Ethereum bányászat többé nem elérhető. A bányászat leállt, amikor az Ethereum [proof-of-work](/glossary/#pow)-ről [proof-of-stake](/glossary/#pos)-re váltott. Ehelyett validátorok vannak. Bárki [tétbe helyezhet](/glossary/#staking) az ETH-t, és tétjutalmat kaphat a hálózat biztonságát szolgáló érvényesítő szoftver futtatásáért. - -### Hogyan legyek staker / futtathatok validátort? {#how-to-stake} - -A validátornak 32 ETH-t kell letétbe helyezni az Ethereum letéti szerződésben és fel kell állítani egy csomópontot. További információk [a letétbehelyezésről szóló oldalon](/staking) és a[letéti launchpaden](https://launchpad.ethereum.org/) érhetők el. - -## Dapp-fejlesztés {#building-support} - -A fejlesztés tele van kihívásokkal. Alább található néhány fejlesztőket támogató platform, tapasztalt Ethereum-fejlesztőkkel. - -- [Alchemy University](https://university.alchemy.com/#starter_code) -- [CryptoDevs discord](https://discord.com/invite/5W5tVb3) -- [Ethereum StackExchange](https://ethereum.stackexchange.com/) -- [StackOverflow](https://stackoverflow.com/questions/tagged/web3) -- [Web3 University](https://www.web3.university/) -- [LearnWeb3](https://discord.com/invite/learnweb3) - -Emellett dokumentációkat és fejlesztői útmutatókat is talál az [Ethereum fejlesztői források](/developers/) szekcióban. - -### Eszközök {#dapp-tooling} - -A kérdése egy bizonyos eszközhöz, projekthez vagy könyvtárhoz kapcsolódik? A legtöbb projekt működtet csevegőszervereket vagy fórumokat ilyen célból. - -Néhány népszerű példa: - -- [Solidity](https://gitter.im/ethereum/solidity) -- [ethers.js](https://discord.gg/6jyGVDK6Jx) -- [web3.js](https://discord.gg/GsABYQu4sC) -- [Hardhat](https://discord.gg/xtrMGhmbfZ) -- [Alchemy](http://alchemy.com/discord) -- [Tenderly](https://discord.gg/fBvDJYR) - -## Csomópontok futtatása {#node-support} - -Ha Ön csomópontot vagy validátort futtat, a következő közösségek segítenek belevágni. - -- [EthStaker discord](https://discord.gg/ethstaker) -- [EthStaker reddit](https://www.reddit.com/r/ethstaker) - -Az Ethereum klienseket építő csapatok is dedikált, nyilvános fórumokkal rendelkeznek, ahol kérdezni lehet. - -### Végrehajtási kliensek {#execution-clients} - -- [Geth](https://discord.gg/FqDzupGyYf) -- [Nethermind](https://discord.gg/YJx3pm8z5C) -- [Besu](https://discord.gg/p8djYngzKN) -- [Erigon](https://github.com/ledgerwatch/erigon/issues) -- [Reth](https://github.com/paradigmxyz/reth/discussions) - -### Konszenzusos kliensek {#consensus-clients} - -- [Prysm](https://discord.gg/prysmaticlabs) -- [Nimbus](https://discord.gg/nSmEH3qgFv) -- [Lighthouse](https://discord.gg/cyAszAh) -- [Teku](https://discord.gg/7hPv2T6) -- [Lodestar](https://discord.gg/aMxzVcr) -- [Grandine](https://discord.gg/H9XCdUSyZd) - -Tudja meg, hogy [futtathat csomópontot](/developers/docs/nodes-and-clients/run-a-node/). diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" deleted file mode 100644 index abb713e7ba3..00000000000 --- "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/archive-nodes/index.md" +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Ethereum archív csomópont -description: Az archív csomópontok áttekintése -lang: hu -sidebarDepth: 2 ---- - -Az archív csomópont az Ethereum-kliens egy fajtája, melynek lényege, hogy az összes státuszt tárolja. Ez egy hasznos eszköz bizonyos célokra, de nehezebb kezelni, mint egy teljes csomópontot. - -## Előfeltételek {#prerequisites} - -Meg kell érteni az [Ethereum-csomópont](/developers/docs/nodes-and-clients/), [architektúráját](/developers/docs/nodes-and-clients/node-architecture/), a [szinkronizációs stratégiáig](/developers/docs/nodes-and-clients/#sync-modes), [futtatási gyakorlatát](/developers/docs/nodes-and-clients/run-a-node/) és [használatukat](/developers/docs/apis/json-rpc/). - -## Mi is az az archív csomópont - -Az archív csomópont lényegéhez meg kell érteni, hogy mit jelent a státusz. Az Ethereumot úgy is nevezhetjük, hogy _tranzakcióalapú státuszgép_. Számlákból áll, és amikor az alkalmazások tranzakciókat hajtanak végre, akkor megváltozik ezek státusza. Az a globális adat, mely lefedi az összes számla- és szerződésinformációt, egy státusznak nevezett fastruktúrájú adatbázisban tárolódik. Ezt a végrehajtási réteg (EL) kliense kezeli, és a következő adatokat tárolja el: - -- Számlaegyenlegek és nonce-ok -- Szerződéskód és tárhely -- Konszenzussal kapcsolatos adatok, pl. a letétbe helyezési szerződés - -A hálózattal való interakció, az új blokkok ellenőrzése és létrehozása végett az Ethereum-klienseknek követniük kell a legutóbbi változásokat (a lánc elejét), így ezért a jelenlegi státuszt is. A teljes csomópontként konfigurált végrehajtási réteg kliense ellenőrzi és követi a hálózat legutóbbi státuszát, de csak néhány státuszt kap el, pl. a legutóbbi 128 blokkét, így képes kezelni a láncátrendezéseket és gyors hozzáférést tud biztosítani a legutóbbi adatokhoz. A legfrissebb státuszra van szüksége minden kliensnek, hogy ellenőrizze a bejövő tranzakciókat és használja a hálózatot. - -Úgy is felfoghatjuk a státuszt, mint egy pénzügyi rendszer pillanatfelvétele egy adott blokknál, az archív pedig a történeti visszajátszás. - -Az előzménystátuszokat biztonsággal meg lehet vágni, mert azok nem szükségesek a hálózat működéséhez, és a kliens számára haszontalan lenne a nem releváns adatok tárolása. Azokat a státuszokat, melyek egy bizonyos blokknál korábban keletkeztek (pl. 128 blokkal korábban), egyszerűen törlik. A teljes csomópontok csak blokklánc-előzményadatokat (blokkok és tranzakciók) tartanak meg, valamint esetenként korábbi pillanatfelvételeket is, amelyek alapján újragenerálhatják a régebbi státuszokat, ha azokra szükség lenne. Ehhez az EVM-ben újra lefuttatják a régi tranzakciókat, amihez sok számítási kapacitás kellhet, ha a szükséges státusz távol esik a legközelebbi pillanatfelvételtől. - -Tehát a historikus státuszok elérése egy teljes csomópont esetén számottevő számítási kapacitást fogyaszt. A kliensnek talán az összes régi tranzakciót le kell futtatnia, és a genezistől kezdve ki kell számolnia az előzménystátuszt. Az archív csomópontok úgy oldják meg ezt, hogy nemcsak a legutóbbi státuszokat tárolják, hanem minden előzménystátuszt is, amely minden egyes blokk után keletkezik. Alapvetően ez egy kompromisszum, mert a számítási kapacitás helyett ehhez nagyobb tárhely szükséges. - -Fontos megjegyezni, hogy a hálózat nem az archív csomópontoktól függ, hogy azok megtartsák és biztosítsák az összes előzményadatot. Ahogy már említettük, a teljes csomópontok minden köztes előzménystátuszt meg tudnak mutatni. A tranzakciókat mindegyik teljes csomópont tárolja (jelenleg kisebb mint 400 G), és vissza tudja azokat játszani ahhoz, hogy egy teljes archívumot felépítsen belőlük. - -### Felhasználási módok - -Az Ethereum általános használata, mint a tranzakciók küldése, a szerződések létrehozása, a konszenzus ellenőrzése stb. nem igényel semmilyen előzményadatot. A felhasználóknak nincs szükségük archív csomópontra ahhoz, hogy interakciókat hajtsanak végre a hálózattal. - -A státuszarchívumok fő haszna az előzménystátuszok gyors elérése. Például az archív csomópont azonnal megadja az eredményt a következő kérdésekre: - -- _Mi volt az ETH egyenlege a 0x1337... számlának a 15 537 393. blokknál?_ -- _Mi az egyenlege a 0x tokennek a 0x szerződéseben az 1 920 000. blokknál?_ - -Ahogy felvázoltuk, a teljes csomópont ezt az adatot az EVM végrehajtással tudja előállítani, ami CPU-t és időt igényel. Az archív csomópontok a merevlemezen érik el és azonnal meg tudják azt adni. Ez egy hasznos jellemző az infrastruktúra bizonyos részeinek, például: - -- Szolgáltatásnyújtók, mint a blokk felfedezők -- Kutatók -- Biztonsági elemzők -- Dapp-fejlesztők -- Auditálás és a szabályoknak való megfelelés - -Számtalan ingyenes [szolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service/) van, ami hozzáférést enged az előzményadatokhoz. Mivel nagyobb teherrel jár egy archív csomópont futtatása, ez a hozzáférés általában korlátozott és esetileg működik. Ha egy projekt állandó hozzáférést igényel az előzményadatokhoz, akkor érdemes saját archív csomópontot futtatnia. - -## Telepítés és használat - -Az archív csomópont ebben a kontextusban azt jelenti, hogy a végrehajtási kliensek adatot szolgáltatnak, mert kezelik a státuszadatbázist és JSON-RPC végpontokat biztosítanak. A konfigurációs lehetőségek, a szinkronizálási idő és az adatbázis mérete kliensenként változik. A részletekkel kapcsolatos részletekért, kérjük, tekintse át az Ön által használt kliens dokumentációját. - -Mielőtt egy archív csomópontot kezdene futtatni, tekintse át a kliensek közötti különbségeket, elsősorban a különböző [hardverszükségleteket](/developers/docs/nodes-and-clients/run-a-node/#requirements). A legtöbb kliensben ez a funkció nincs optimalizálva, így az archív változataik több mint 12 TB helyet igényelnek. Ezzel ellentétben az olyan implementáció, mint amilyen az Erigon, képes ugyanazt az adatot kevesebb mint 3 TB helyen tárolni, ami az archív csomópontok esetében a leghatékonyabbá teszi őket. - -## Bevált gyakorlatok - -Azon túl, amit általános [javaslatként megfogalmaznak a csomópont futtatásához](/developers/docs/nodes-and-clients/run-a-node/), az archív csomópont működtetése többet igényelhet a hardver és a fenntartás szempontjából. Figyelembe véve az Erigon [fő jellemzőit](https://github.com/ledgerwatch/erigon#key-features), a leghasznosabb megközelítés egy [Erigon](/developers/docs/nodes-and-clients/#erigon)-kliens létrehozása lenne. - -### Hardver - -Mindig ellenőrizze az egy adott csomópontra vonatkozó hardverigényeket a kliens dokumentációjában. Az archív csomópontok legnagyobb igénye a tárhely. A klienstől függően ez 3 és 12 TB között változhat. A HDD jobb lenne a nagymennyiségű adatok tárolásához, de a szinkronizálás és a lánc elejének állandó frissítése SSD-meghajtókat igényel. A [SATA](https://www.cleverfiles.com/help/sata-hard-drive.html) meghajtók elég jók, de abból is a megbízható minőségű javasolt, vagyis legalább a [TLC](https://blog.synology.com/tlc-vs-qlc-ssds-what-are-the-differences). A lemezek elég lemezhellyel rendelkező asztali gépbe vagy szerverbe is behelyezhetők. Ezek a dedikált eszközök ideálisak egy ilyen, szinte állandóan aktív csomópont futtatásához. Laptopon is futtatható, de a hordozhatóság több költséggel jár. - -Az összes adatnak egy köteten el kell férnie, ezért a lemezeket össze kell kapcsolni, pl. a [RAID0](https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0) vagy a [LVM](https://web.mit.edu/rhel-doc/5/RHEL-5-manual/Deployment_Guide-en-US/ch-lvm.html) által. Érdemes lehet megfontolni a [ZFS](https://en.wikipedia.org/wiki/ZFS) használatát is, mert ez támogatja az írásra másolás (copy-on-write) funkciót, amivel az adat biztosabban, alacsony szintű hiba nélkül íródik a lemezre. - -A nagyobb stabilitás érdekében és a véletlen adatbázis-meghibásodás megelőzésére, főleg a professzionális összeállításban, érdemes [ECC-memóriát](https://en.wikipedia.org/wiki/ECC_memory) használni, ha azt a rendszer is támogatja. A RAM méretének általában akkorának kell lennie, mint egy teljes csomópont esetében, de az ennél több RAM csak segíthet a szinkronizálás gyorsításában. - -A kezdeti szinkronizáláskor az archív csomópont kliensei lefuttatják az összes tranzakciót a genezistől kezdve. A végrehajtási sebességet a CPU korlátozza, tehát a gyorsabb CPU segít a kezdeti szinkronizáláskor. Egy átlagos számítógépen a kezdeti szinkronizálás egy hónapig is eltarthat. - -## További olvasnivaló {#further-reading} - -- [A teljes és az archív csomópont összehasonlítása az Ethereumon](https://www.quicknode.com/guides/infrastructure/ethereum-full-node-vs-archive-node) – _QuickNode, 2022. szeptember_ -- [Építsen saját Ethereum archív csomópontot](https://tjayrush.medium.com/building-your-own-ethereum-archive-node-72c014affc09) – _Thomas Jay Rush, 2021. augusztus_ -- [Hogyan kell felállítani az Erigont, Erigon RPC-t és TrueBlocks-t (scrape és API) szolgáltatásként](https://magnushansson.xyz/blog_posts/crypto_defi/2022-01-10-Erigon-Trueblocks) – _Magnus Hansson, frissítve 2022. szeptember_ - -## Kapcsolódó témák {#related-topics} - -- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) -- [Csomópontok futtatása](/developers/docs/nodes-and-clients/run-a-node/) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" deleted file mode 100644 index 473fd04c5dc..00000000000 --- "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/bootnodes/index.md" +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: Bevezető az Ethereum betöltő csomópontjaiba (bootnode) -description: Alapvető információk a betöltő csomópontok megértéséhez -lang: hu ---- - -Amikor egy új csomópont csatlakozik az Ethereum hálózathoz, akkor a már hálózaton lévő csomópontokhoz kell kapcsolódnia, hogy új társakat tudjon találni. Ezeket az Ethereum hálózatba való belépőpontokat nevezik betöltő csomópontoknak. A kliensekbe bele van kódolva a betöltő csomópontok listája. Ezeket általában az Ethereum Alapítvány fejlesztőket vagy klienseket kezelő csapatai maguk működtetik. Érdemes megjegyezni, hogy a betöltő csomópontok nem azonosak a statikus csomópontokkal. A statikus csomópontokat ismételten meghívják, miközben a betöltő csomópontokat csak akkor, amikor nincs elég társ, akivel kapcsolódni lehetne, és a csomópontnak új kapcsolatokat kell felállítania. - -## Kapcsolódás egy betöltő csomóponthoz {#connect-to-a-bootnode} - -A legtöbb kliensbe bele van programozva a betöltő csomópontok listája, de egy felhasználó maga is futtathat betöltő csomópontot, vagy olyat is használhat, amely nem szerepel a kliensben. Ekkor a kliens indításakor kell megadni ezeket, ahogy a következő Geth példa mutatja (nézze meg a kliensének a dokumentációját): - -``` -geth --bootnodes "enode://@:" -``` - -## Betöltő csomópont futtatása {#run-a-bootnode} - -A betöltő csomópontok teljes csomópontok, amelyeket nem fed egy hálózati címfordítás ([Network Address Translation](https://www.geeksforgeeks.org/network-address-translation-nat/)). Minden teljes csomópont működhet betöltőként, ha nyilvánosan elérhető. - -Amikor egy csomópontot felállítanak, akkor [enode](/developers/docs/networking-layer/network-addresses/#enode) címet kell jegyezni rá, ami egy nyilvános azonosító, mellyel mások kapcsolódni tudnak hozzá. - -Ez az enode minden újraindításnál újragenerálódik, ezért a betöltő csomópont esetében ellenőrizni kell a kliens dokumentációban, hogyan lehet állandó enode-ot létrehozni. - -A betöltő csomópont hasznossága érdekében érdemes megnövelni azon társak maximális számát, akik kapcsolódhatnak hozzá. A betöltő csomópont futtatása sok kapcsolttal jelentősen megnöveli a szükséges sávszélességet. - -## Az elérhető betöltő csomópontok {#available-bootnodes} - -A go-ethereumhoz kapcsolódó beépített betöltő csomópontok listáját [itt találja](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go#L23). Ezeket az Ethereum Alapítvány és a go-ethereum csapat tartja karban. - -Más listák is léteznek a betöltő csomópontokról, amelyeket önkéntesek tartanak karban. Legalább egy hivatalos betöltő csomópontot mindenféleképpen használni kell, különben támadás alá kerülhet a csomópont (és elvágják a kapcsolataitól). diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" deleted file mode 100644 index 5d4aefd9826..00000000000 --- "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/client-diversity/index.md" +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Kliensdiverzitás -description: Áttekintés az Ethereum-kliensdiverzitás fontosságáról. -lang: hu -sidebarDepth: 2 ---- - -Az Ethereum-csomópont viselkedését az általa használt kliensszoftver irányítja. Számos Ethereum-kliens létezik, melyeket különböző csapatok különféle nyelveken fejlesztettek és tartanak karban. A klienseket egy közös specifikáció alapján építik, hogy fennakadás nélkül tudjanak egymással kommunikálni, ugyanolyan funkcionalitással bírjanak és azonos felhasználói élményt adjanak. Ugyanakkor jelenleg a kliensek nem oszlanak el a csomópontokon elég egyenlően ahhoz, hogy a hálózat megerősítésének teljes potenciálját ki lehetne használni. Ideális esetben a felhasználók nagyjából azonosan oszlanának meg a különféle kliensek között, hogy a hálózatnak a lehető legdiverzebb legyen a klienshasználata. - -## Előfeltételek {#prerequisites} - -Ha Önnek még újdonság ez a téma, akkor tekintse meg a [Csomópontok és kliensek](/developers/docs/nodes-and-clients/) című áttekintést. A [végrehajtási réteg](/glossary/#execution-layer) és a [konszenzusréteg](/glossary/#consensus-layer) definícióját megtalálja a glosszáriumban. - -## Miért vannak különböző kliensek? {#why-multiple-clients} - -A különböző, egymástól függetlenül fejlesztett és karbantartott kliensek azért jöttek létre, mert ez a diverzitás a hálózatot sokkal ellenállóbbá teszi a támadásokkal és a hibákkal szemben. A különféle kliensek az Ethereum egyedi erősségét jelentik, mivel más blokkláncok egyetlen kliens tévedhetetlenségén alapulnak. Ugyanakkor nem elég a különféle kliensek elérhetősége, azokat használnia is kell a közösségnek, és a teljes aktív csomópontok között relatíve egyenlően kellene eloszlaniuk. - -## Miért olyan fontos a kliensdiverzitás? {#client-diversity-importance} - -A decentralizált hálózat egészsége nagy mértékben függ a függetlenül fejlesztett és fenntartott kliensektől. Nézzük át ennek okait. - -### Hibák {#bugs} - -Egy kliensben előforduló hiba kisebb kockázatot jelent a hálózatnak, amikor az az Ethereum-csomópontok kisebb hányadát képviseli. Ha a csomópontok nagyjából egyenlően oszlanak meg a különféle kliensek között, akkor nagyon kicsi az esélye, hogy a legtöbb kliens ugyanattól a hibától szenved, így a hálózat sokkal szilárdabb lesz. - -### Támadásokkal szembeni ellenállás {#resilience} - -A kliensdiverzitás nagyobb ellenállást jelent a támadásokkal szemben. Például egy olyan támadás, ami [egy bizonyos klienst arra vesz rá](https://twitter.com/vdWijden/status/1437712249926393858), hogy a lánc egy elágazását kövesse, nem valószínű, hogy sikeres lesz, mert más klienseket nem tud ugyanúgy rászedni, így a kanonikus lánc érintetlen marad. Az alacsony kliensdiverzitás növeli a kockázatát egy olyan támadásnak, amely a domináns kliens ellen irányul. A kliensdiverzitás egyértelműen fontos védelem a rosszindulatú támadások esetén, ahogy azt a 2016-os shanghai példa mutatja, amikor a támadók a domináns klienst (Geth) rávették, hogy egy lassú i/o funkciót hajtson végre blokkonként tízezerszer. Mivel más kliensek is online voltak, amelyek nem voltak ugyanígy sebezhetőek, az Ethereum képes volt ellenállni a támadásnak, folytatta működését és kijavította a Geth-kliens sebezhetőségét. - -### Proof-of-stake véglegesedés {#finality} - -Egy olyan hiba a konszenzusos kliensben, amely az Ethereum-csomópontok több mint 33%-át érinti, meg tudja akadályozni azt, hogy a konszenzusréteg véglegesedjen, tehát a felhasználók nem tudhatják, hogy a tranzakcióik nem lesznek visszaforgatva vagy megváltoztatva valamikor. Ez rendkívül problémás helyzet az Ethereumra épült alkalmazások számára, főleg a decentralizált pénzügy (DeFi) területén. - - Még ennél is rosszabb, ha egy kétharmados többséggel bíró kliensben történik hiba, ami miatt a lánc hibásan szétválik és véglegesedik, így a validátorok egy jó része egy valótlan láncon ragad. Ha ezek a validátorok újra a helyes lánchoz akarnának csatlakozni, akkor súlyos büntetéssel, vagy egy lassú és költséges visszavonási és újraaktviálási folyamattal néznének szembe. A súlyos büntetés mértéke arányos a kétharmados többség hibás csomópontjainak számával, melynek a letétjét (32 ETH) teljesen megsemmisítik. - -Habár ezek nem valószínű szcenáriók, az Ethereum ökoszisztémája képes a kockázatot csökkenteni azzal, hogy az aktív csomópontokon keresztül egyenlően oszlanak el a kliensek. Ideális esetben a teljes csomópontok 33%-át nem dominálja egy adott konszenzusos kliens. - -### Közös felelősség {#responsibility} - -A többségi klienseknek emberi költsége is van. Túlzott terhet és felelősséget helyez egy kis fejlesztői csapatra. Minél kisebb a kliensdiverzitás, annál nagyobb a felelősség terhe a fejlesztőkön, hogy karbantartsák a domináns klienst. Ennek a felelősségnek a megosztása a különféle csapatok között egyaránt egészségesebb az Ethereum-csomóponthálózat és az emberi hálózat számára. - -## Jelenlegi kliensdiverzitás {#current-client-diversity} - -![Diagram a kliensdiverzitásról](./client-diversity.png) _A diagram adatai az [ethernodes.org](https://ethernodes.org) és a [clientdiversity.org](https://clientdiversity.org/)_ honlapokról - -A két diagram a jelen írás időpontjában (2022. január) érvényes kliensmegoszlást mutatja a végrehajtási és konszenzusrétegre. A végrehajtási réteget túlságosan dominálja a [Geth](https://geth.ethereum.org/), amit távolról követ az [Open Ethereum](https://openethereum.github.io/), az [Erigon](https://github.com/ledgerwatch/erigon) és a [Nethermind](https://nethermind.io/), a többi kliens együtt nem teszi ki a hálózat 1%-át. A konszenzusréteg leggyakrabban használt kliense, a [Prysm](https://prysmaticlabs.com/#projects), nem annyira domináns, mint a Geth, de így is a hálózat több mint 60%-át lefedi. A [Lighthouse](https://lighthouse.sigmaprime.io/) és a [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) kb. 20% és 14%-ot tesznek ki, a többi klienst kevesen használják. - -A végrehajtási réteg adatai az [Ethernodes](https://ethernodes.org) oldalról származnak (2022. január 23.). A konszenzusos kliensek adatait [Michael Sproul](https://github.com/sigp/blockprint) biztosította. A konszenzusos kliensek adatait nehezebb megszerezni, mert nem rendelkeznek összetéveszthetetlen nyomokkal, amelyekkel azonosítani lehet ezeket. Az adatot egy klasszifikációs algoritmus segítségével készítették, amely bizonyos esetekben összekeveri a kisebb részesedéssel bíró klienseket (bővebben [itt](https://twitter.com/sproulM_/status/1440512518242197516) olvashat erről). A diagram esetében ezeket a nem egyértelmű klasszifikációkat egy vagy/vagy címkével láthatja (pl. Nimbus/Teku). Mindazonáltal az egyértelmű, hogy a hálózat többségét a Prysm működteti. Az adat egy pillanatfelvétel egy adott mennyiségű blokkról (jelen esetben Beacon blokkok a 2048001-tól 2164916-ig tartó slotokban), és a Prysm dominanciája néha ennél magasabb is, meghaladva a 68%-ot. Annak ellenére, hogy ezek pillanatfelvételek, mégis megmutatják a kliensdiverzitás helyzetét. - -Friss kliensdiverzitási adat elérhető már a konszenzusrétegre is a [clientdiversity.org](https://clientdiversity.org/) oldalon. - -## Végrehajtási réteg {#execution-layer} - -Mostanáig a kliensdiverzitás fókusza inkább a konszenzusrétegen volt. Ugyanakkor a [Geth](https://geth.ethereum.org) végrehajtási kliense jelenleg az összes csomópont 85%-át kiteszi. Ez az arány ugyanolyan problémás, mint a konszenzusos kliensek esetében. Például egy hiba a Geth-ben, amely a tranzakciók kezelését vagy a végrehajtási csomagok összeállítását érinti, oda vezethet, hogy a konszenzusos kliensek problémás vagy hibás tranzakciókat véglegesítenek. Ezért az Ethereum egészségesebb lenne egy egyenlőbb végrehajtásikliens-eloszlással, ideális esetben egy adott kliens nem fedné le a hálózat több mint 33%-át. - -## Kisebbségi kliens használata {#use-minority-client} - -A kliensdiverzitás eléréséhez nem elég, hogy az egyéni felhasználók kisebbségi klienseket válasszanak, ehhez szükség van arra, hogy a bányász/validátor csoportok és intézmények is, mint a nagyobb dappok és tőzsdék is átálljanak. Ugyanakkor az összes felhasználó kiveheti a részét, hogy ezt az egyenlőtlenséget orvosolja, és az összes elérhető Ethereum-szoftver használva legyen. Az egyesítés (Merge) után minden csomópont-üzemeltetőnek futtatnia kell egy végrehajtási és egy konszenzusos klienst. Az alább javasolt klienskombinációkkal növelni lehet a diverzitást. - -### Végrehajtásos kliensek {#execution-clients} - -[Besu](https://www.hyperledger.org/use/besu) - -[Nethermind](https://downloads.nethermind.io/) - -[Erigon](https://github.com/ledgerwatch/erigon) - -[Go-Ethereum](https://geth.ethereum.org/) - -### Konszenzusos kliensek {#consensus-clients} - -[Nimbus](https://nimbus.team/) - -[Lighthouse](https://github.com/sigp/lighthouse) - -[Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) - -[Lodestar](https://github.com/ChainSafe/lodestar) - -[Prysm](https://docs.prylabs.network/docs/getting-started) - -A technikailag képzett felhasználók segíthetik ezt a folyamatot azzal is, hogy több útmutatót és dokumentációt készítenek a kisebbségi kliensekről, és arra bátorítják a társaikat, hogy a domináns kliens helyett mást használjanak. A kisebbségi konszenzusos kliensre való áttérésről itt talál útmutatókat: [clientdiversity.org](https://clientdiversity.org/). - -## Kliensdiverzitási irányítópultok {#client-diversity-dashboards} - -Számos irányítópult vagy kimutatás ad képet az aktuális kliensdiverzitásról a végrehajtási és konszenzusréteget illetően. - -**Konszenzusréteg:** - -- [Rated.network](https://www.rated.network/) -- [clientdiversity.org](https://clientdiversity.org/) **Végrehajtási réteg:** - -- [supermajority.info](https://supermajority.info//) -- [Ethernodes](https://ethernodes.org/) - -## További olvasnivaló {#further-reading} - -- [Kliensdiverzitás az Ethereum konszenzusrétegen](https://mirror.xyz/jmcook.eth/S7ONEka_0RgtKTZ3-dakPmAHQNPvuj15nh0YGKPFriA) -- [Ethereum Merge: A többségi kliens futtatása Önt is veszélyezteti!](https://dankradfeist.de/ethereum/2022/03/24/run-the-majority-client-at-your-own-peril.html) – _Dankrad Fiest, 2022. március 24._ -- [A kliensdiverzitás fontossága](https://our.status.im/the-importance-of-client-diversity/) -- [Az Ethereumcsomópont-szolgáltatások listája](https://ethereumnodes.com/) -- [Az „öt miért” kérdés alkalmazása a kliensdiverzitási problémára](https://notes.ethereum.org/@afhGjrKfTKmksTOtqhB9RQ/BJGj7uh08) -- [Ethereum-diverzitás és hogyan lehetne elérni (YouTube)](https://www.youtube.com/watch?v=1hZgCaiqwfU) -- [clientdiversity.org](https://clientdiversity.org/) - -## Kapcsolódó témák {#related-topics} - -- [Ethereum-csomópont futtatása](/run-a-node/) -- [Csomópontok és kliensek](/developers/docs/nodes-and-clients/) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" deleted file mode 100644 index 96cae2ec293..00000000000 --- "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/index.md" +++ /dev/null @@ -1,315 +0,0 @@ ---- -title: Csomópontok és kliensek -description: Áttekintés az Ethereum csomópontokról (node) és kliens szoftverekről, valamint egy csomópont felállításának menetéről, és hogy miért érdemes sajátot működtetni. -lang: hu -sidebarDepth: 2 ---- - -Az Ethereum számítógépekből (ún. csomópontokból) álló elosztott hálózat, amelyen a számítógépek a blokkok és tranzakciós adatok hitelesítésére képes szoftvert futtatnak. A szoftver futtatása teszi a felhasználó számítógépét Ethereum-csomóponttá. A csomóponthoz két különálló szoftverre, vagyis kliensre van szükség. - -## Előfeltételek {#prerequisites} - -Mielőtt mélyebbre merülne, és megkezdené a saját Ethereum-kliensének működtetését, javasoljuk, hogy ismerje meg a közvetítőmentes (peer-to-peer) hálózatok koncepcióját és az[Ethereum Virtális Gép (EVM) alapjait](/developers/docs/evm/). Tekintse meg a [Bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) című cikket. - -Ha Önnek újdonság a csomópontok témaköre, akkor azt javasoljuk, először tekintse meg az [Ethereum-csomópont futtatása](/run-a-node) című felhasználóbarát ismertetőnket. - -## Mik azok a csomópontok és kliensek? {#what-are-nodes-and-clients} - -„Csomópont” minden olyan Ethereum-kliensszoftver-példány, amely más – szintén Ethereum-szoftvert futtató – számítógépek hálózatához kapcsolódik. A kliens az Ethereum egy implementációja, amely adatok hitelesítését végzi a protokollszabályok alapján, és fenntartja a hálózat biztonságát. A csomópontnak két klienst kell futtatnia: konszenzusos és végrehajtási kliens. - -- A végrehajtási kliens (más néven végrehajtási motor, EL-kliens vagy korábbi nevén Eth1-kliens) a hálózatban terjesztett új tranzakciókat figyeli, végrehajtja őket az EVM-ben, és tárolja az összes aktuális Ethereum-adat legutolsó állapotát és adatbázisát. -- A konszenzusos kliens (más néven Beacon-csomópont, CL-kliens vagy korábbi nevén Eth2-kliens) feladata a proof-of-stake konszenzusalgoritmus végrehajtása, amely lehetővé teszi, hogy a hálózat a végrehajtási kliens validált adatai alapján megegyezésre jusson. Létezik egy harmadik szoftver is, a validátor, amelyet a konszenzusok klienshez lehet hozzáadni, így az adott csomópont részt vehet a hálózat biztosításában. - -Ezek a kliensek együtt dolgoznak azon, hogy az Ethereum-hálózat legfrissebb állapotát kövessék, és lehetővé tegyék a felhasználók számára, hogy interakcióba lépjenek a hálózattal. Az egymással együttműködő szoftverrészekből álló moduláris felépítés neve [bennfoglalt komplexitás (encapsulated complexity)](https://vitalik.eth.limo/general/2022/02/28/complexity.html). Ez a megközelítés lehetővé tette, hogy [az egyesítés (Merge)](/roadmap/merge) hibátlanul végbemehessen, a kliensszoftvereket könnyebb legyen karbantartani és fejleszteni, továbbá az egyéni klienseket újra lehet hasznosítani, például a [2. blokkláncrétegben](/layer-2/). - -![Összekapcsolt végrehajtási és konszenzusos kliensek](./eth1eth2client.png) Az összekapcsolt végrehajtási és konszenzusos kliens egyszerűsített ábrája. - -### Kliensdiverzitás {#client-diversity} - -A [ végrehajtási klienseket](/developers/docs/nodes-and-clients/#execution-clients) és a [ konszenzusos klienseket](/developers/docs/nodes-and-clients/#consensus-clients) számos különböző programnyelvben fejlesztették ki a különféle csapatok. - -A többféle kliensimplementáció erősebbé teheti a hálózatot azáltal, hogy nem függ szorosan egyetlen programkódtól. A cél a sokszínűség elérése anélkül, hogy bármelyik kliens dominálná a hálózatot, így el lehet kerülni az egyetlen hibapont lehetőségét. A nyelvek változatossága szélesebb fejlesztői közösséget is vonz, és lehetővé teszi, hogy az általuk előnyben részesített nyelven integrációt hajtsanak végre. - -Tudjon meg többet a [kliensdiverzitásról](/developers/docs/nodes-and-clients/client-diversity/). - -Az implementációk közös vonása, hogy egyazon specifikációt követik. Ez a specifikáció diktálja, hogyan működik az Ethereum-hálózat és a blokklánc. Minden technikai részlet ki van dolgozva, a specifikációkat pedig itt találhatja: - -- Eredetileg az [Ethereum Sárga Könyvében](https://ethereum.github.io/yellowpaper/paper.pdf), vagyis műszaki alaptanulmányában. -- [Végrehajtási specifikációk](https://github.com/ethereum/execution-specs/) -- [Konszenzusspecifikációk](https://github.com/ethereum/consensus-specs) -- [EIP-ek](https://eips.ethereum.org/), amelyeket a különböző [ hálózatfrissítések](/history/) során vezettek be - -### Csomópontok követése a hálózatban {#network-overview} - -Az Ethereum-hálózat csomópontjairól számos trekker biztosít valós idejű adatokat. Megjegyzendő, hogy a decentralizált hálózatok jellege miatt ezek a letapogatók (crawler) csak korlátozott rálátást tudnak nyújtani a hálózatra, és eltérő eredményeket jelenthetnek. - -- [Csomóponttérkép](https://etherscan.io/nodetracker), készítette: Etherscan -- [Ethercsomópontok](https://ethernodes.org/), készítette: Bitfly -- [Nodewatch](https://www.nodewatch.io/), készítette: Chainsafe, konszenzuscsomópontok letapogatása -- [Monitoreth](https://monitoreth.io/) - a MigaLabs által biztosított megosztott hálózati ellenőrzési eszköz - -## Csomóponttípusok {#node-types} - -Ha [ saját csomópontot akar futtatni](/developers/docs/nodes-and-clients/run-a-node/), akkor fontos megértenie, hogy különböző típusú csomópontok léteznek, amelyek adathasználata eltérő. A kliensek valójában három különböző típusú csomópontot futtathatnak: könnyű (light), teljes (full) és archív (archive). Különböző szinkronizálási stratégiák is elérhetők, amelyek rövidebb szinkronizálási időt tesznek lehetővé. A szinkronizálás arra utal, hogy milyen gyorsan tudja elérni a csomópont az Ethereum legfrissebb státuszát. - -### Teljes csomópont (full node) {#full-node} - -A teljes csomópontok a blokklánc egymást követő blokkjait validálják, melyhez letöltik és ellenőrzik a blokk tartalmát és az adat státuszát minden egyes blokkra. A teljes csomópontoknak több fajtája létezik, néhány a kezdetektől indul, a genezis blokktól, és a blokklánc teljes történetét validálja blokkonként. Mások az ellenőrzést egy későbbi blokktól indítják, melynek érvényességében megbíznak (pl. a Geth-féle, pillanatfelvételen alapuló szinkronizálás). Függetlenül az ellenőrzés kezdőpontjától, a teljes csomópontok csak a legutóbbi adatokat (általában az utolsó 128 blokkot) tárolják, az ennél régebbieket törlik, hogy ne foglaljon annyi helyet. A régebbi adatot újra elő lehet állítani, amikor szükséges. - -- A blokkláncadatokat teljeskörűen tárolja (habár ezt időről időre megrövidíti a rendszer, tehát a teljes csomópont sem tárolja az összes állapotadatot a genezisig visszamenőleg). -- Részt vesz a blokkvalidációban, hitelesíti az összes blokkot és állapotot. -- A teljes csomópont minden státuszt elő tud hívni a lokális tárhelyéről vagy újra tudja generálni a pillanatképekből. -- Kiszolgálja a hálózatot, és kérésre adatszolgáltatást nyújt. - -### Archív csomópont {#archive-node} - -Az archív csomópontok olyan teljes csomópontok, melyek minden blokkot ellenőriznek a genezis óta, és nem törölnek semmilyen letöltött adatot. - -- Tárolja mindazt, ami a teljes csomóponton van, és archívumot épít a múltbeli állapotokból. Akkor van rá szükség, ha például valaki le akar kérni egy számlaegyenleget a 4 000 000. blokknál, vagy nyomon követést alkalmazva egyszerűen és gyorsan le akarja tesztelni a saját tranzakcióit anélkül, hogy kibányászná őket. -- Ezek az adatok terabájtnyi egységeket képviselnek, emiatt az archív csomópontok kevésbé vonzók az átlagfelhasználók számára, de hasznos lehet az olyan szolgáltatóknak, mint a blokkfelfedezők, a tárcaforgalmazók és a blokkláncelemzők. - -A kliensek szinkronizálása az archív kivételével minden módban részleges blokkláncadatokat eredményez. Ez azt jelenti, hogy nincs egy összes múltbeli státusszal rendelkező archívum, de igény esetén a teljes csomópont képes felépíteni azt. - -Tudjon meg többet az [archív csomópontokról](/developers/docs/nodes-and-clients/archive-nodes). - -### Könnyű csomópont {#light-node} - -A teljes blokkok letöltése helyett a könnyű csomópontok csak a blokkfejléceket töltik le. Ezek a fejlécek összegző információkat hordoznak a blokkok tartalmáról. A könnyű csomópont a szükséges egyéb információkat egy teljes csomóponttól kéri le. A könnyű csomópont ezután független módon hitelesítheti a kapott adatokat a blokkfejlécben található állapot-gyökérhash értékek alapján. A könnyű csomópontok segítségével a felhasználók a teljes csomópontok futtatásához elengedhetetlen erős hardver és nagy sávszélesség nélkül is részt vehetnek az Ethereum hálózatában. Végül a könnyű csomópontok mobiltelefonokon vagy beágyazott eszközökön is futtathatók lesznek. A könnyű csomópontok nem vesznek részt a konszenzusban (tehát nem lehetnek bányászok/validátorok), de ugyanolyan funkcionalitással és biztonsági garanciákkal férhetnek hozzá az Ethereum-blokklánchoz, mint egy teljes csomópont. - -A könnyű kliensek az Ethereum aktív fejlesztési területei közé tartoznak, és hamarosan új könnyű kliensek megjelenésére számítunk a konszenzusréteg és a végrehajtási réteg számára. A könnyűkliens-adatok nyújtásának további potenciális útvonala lehet a [ pletykahálózat (gossip network)](https://www.ethportal.net/). Ez előnyös, mivel a pletykahálózat képes támogatni a könnyű csomópontok hálózatát anélkül, hogy a teljes csomópontoknak kellene adatot szolgáltatniuk. - -Az Ethereum még nem támogatja a könnyű csomópontok nagy tömegeit, de számítani lehet rá, hogy ezek támogatása a közeljövőben gyorsan fejlődik majd. Különösen a [Nimbus](https://nimbus.team/), a [Helios](https://github.com/a16z/helios) és a [LodeStar](https://lodestar.chainsafe.io/) kliensek fejlesztenek aktívan a könnyű csomópontok területén. - -## Miért futtassak Ethereum csomópontot? {#why-should-i-run-an-ethereum-node} - -Egy csomópont futtatása lehetővé teszi, hogy Ön közvetlenül, bizalomigény nélkül és privát módon használhassa az Ethereumot, miközben a hálózatot támogatva fokozza annak szilárdságát és decentralizációját. - -### Milyen előnyökkel jár ez Önnek? {#benefits-to-you} - -A saját csomópont futtatása lehetővé teszi az Ethereum valóban privát, önálló és bizalomigény nélküli használatát. Önnek nem kell bíznia a hálózatban, mivel az adatokat saját maga is ellenőrizheti a kliensén keresztül. A „Nem kell megbíznia senkiben. Csak ellenőrizni” egy népszerű blokkláncmantra. - -- A csomópontja önállóan hitelesíti az összes tranzakciót és blokkot a konszenzusszabályoknak megfelelően. Ez azt jelenti, hogy nem kell a hálózat egyetlen más csomópontjára sem támaszkodnia, sem teljesen megbíznia bennük. -- Saját csomópontjához használhat egy Ethereum-tárcát. Biztonságosabban és diszkrétebben használhatja a dappokat, mivel nem kell kiadnia a címét és az egyenlegét közvetítőknek. Mindent ellenőrizhet a saját kliensével. A [MetaMask](https://metamask.io), a [Frame](https://frame.sh/)és [ számos egyéb tárca](/wallets/find-wallet/) kínál RPC-importálást, amely lehetővé teszi számukra az Ön csomópontjának használatát. -- Más olyan szolgáltatásokat is futtathat vagy végezhet saját hatáskörben, amelyek az Ethereum adataira támaszkodnak. Ilyen lehet például egy Beaconlánc-validátor, egy második blokkláncréteg szoftvere, infrastruktúra, blokkfelfedezők, fizetésfeldolgozó alkalmazások stb. -- Ön saját egyéni [RPC-végpontokat](/developers/docs/apis/json-rpc/) is kínálhat. Ezeket a végpontokat felajánlhatja nyilvánosan a közösségnek is, hogy ezzel is elkerüljék a nagy, centralizált szolgáltatókat. -- A csomópontjához a **folyamaton belüli kommunikációk (IPC)** mechanizmusával csatlakozhat, vagy átírhatja a csomópontját, hogy a saját programját töltse be pluginként. Ez rövid késleltetést tesz lehetővé, ami nagyon fontos, ha például valaki web3 könyvtárak használatával dolgoz fel nagy mennyiségű adatot, vagy amikor a lehető leggyorsabban ki kell cserélnie tranzakcióit (például frontrunning esetén). -- Közvetlenül letétbe helyezhet ETH-t, ezzel biztosítja a hálózatot és jutalmakat szerez. A kezdéshez tekintse meg az [önálló letétbe helyezésről](/staking/solo/) szóló oldalunkat. - -![Hogyan férhet hozzá az Ethereumhoz az alkalmazásával és a csomópontjával](./nodes.png) - -### Hálózati előnyök {#network-benefits} - -A csomópontok sokfélesége fontos az Ethereum egészsége, biztonsága és működési ellenálló képessége szempontjából. - -- A teljes csomópontok betartatják a konszenzusszabályokat, így nem lehet őket becsapni és rávenni szabálytalan blokkok elfogadására. Ez extra biztonságot nyújt a hálózatnak, mert ha az összes csomópont könnyű csomópont lenne, amelyek nem végeznek teljes ellenőrzést, akkor a validátorok megtámadhatnák a hálózatot. -- Ha egy támadás legyűri a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/#what-is-pos) mechanizmus kriptogazdaság-védelmi rendszerét, akkor a teljes csomópontok a becsületes lánc követése mellett szavazva közösségi visszaállítást hajthatnak végre. -- Ha több csomópont van a hálózatban, az sokszínűbb és szilárdabb hálózatot eredményez, ami a decentralizáció végső célja, és megteremti a cenzúrával szemben ellenálló és megbízható rendszer lehetőségét. -- A teljes csomópontok hozzáférést biztosítanak a blokkláncadatokhoz a könnyű kliensek számára, melyek ettől függenek. A könnyű csomópontok nem tárolják az egész blokkláncot, ehelyett az adatokat a [blokkfejlécekben található státuszgyökerek](/developers/docs/blocks/#block-anatomy) alapján ellenőrzik. Szükség esetén további információkat is kérhetnek a blokkokról a teljes csomópontoktól. - -Ha valaki egy teljes csomópontot futtat, akkor az az egész Ethereum-hálózat számára előnyös, még ha nem is működtet azon validátort. - -## Saját csomópont üzemeltetése {#running-your-own-node} - -Szeretne saját Ethereum-klienst futtatni? - -A kezdők számára is könnyen érthető bevezetőért látogasson el a [Csomópont futtatása](/run-a-node) oldalunkra. - -Ha Ön jártas a technológiában, akkor további részleteket és lehetőségeket talál arra vonatkozóan, hogyan [pörgesse fel saját csomópontját](/developers/docs/nodes-and-clients/run-a-node/). - -## Alternatívák {#alternatives} - -A saját csomópont felállítása idő- és erőforrásigényes lehet, de nem minden esetben szükséges saját példányt futtatnia. Ekkor használhat egy harmadik fél által biztosított API-t (alkalmazásprogramozási felület). Ezen szolgáltatások használatának áttekintéséhez nyissa meg a [Csomópontok mint szolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service/) című bejegyzésünket. - -Ha az Ön közösségében valaki nyilvános API-val futtat egy Ethereum-csomópontot, akkor egy egyedi RPC-n keresztül átirányíthatja a tárcáit erre a közösségi csomópontra, így nagyobb fokú adatvédelemben részesülhet, mintha egy véletlenszerűen kiválasztott, harmadik félben bízna meg. - -Ugyanakkor, ha Ön klienst üzemeltet, akkor megoszthatja azokkal a barátaival, akiknek szüksége lehet rá. - -## Végrehajtási kliensek {#execution-clients} - -Az Ethereum-közösség több nyílt forráskódú végrehajtási klienst (korábbi nevén „Eth1-kliens”, vagy egyszerűen „Ethereum-kliens”) tart fent, amelyeket különböző csapatok különböző programnyelveken hoztak létre. Ez erősebbé és [sokszínűvé](/developers/docs/nodes-and-clients/client-diversity/) teszi a hálózatot. A cél a sokszínűség elérése anélkül, hogy bármelyik kliens dominálna, így el lehet kerülni az egyetlen hibapont lehetőségét. - -Ez a táblázat összefoglalja a különböző klienseket. Ezek mindegyike megfelel a [klienstesztnek](https://github.com/ethereum/tests), és aktívan karbantartják őket, hogy naprakészek legyenek a hálózati frissítések tekintetében. - -| Kliens | Nyelv | Operációs rendszerek | Hálózatok | Szinkronizációs stratégiák | Állapot elhagyás | -| ------------------------------------------------------------------------ | ---------- | --------------------- | ------------------------- | -------------------------------------------------------------------- | ------------------- | -| [Geth](https://geth.ethereum.org/) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Snap](#snap-sync), [teljes](#full-sync) | Archív, megvágott | -| [Nethermind](https://www.nethermind.io/) | C#, .NET | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Snap](#snap-sync) (kiszolgálás nélkül), gyors, [teljes](#full-sync) | Archív, csökkentett | -| [Besu](https://besu.hyperledger.org/en/stable/) | Java | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Snap](#snap-sync), [gyors](#fast-sync), [teljes](#full-sync) | Archív, csökkentett | -| [Erigon](https://github.com/ledgerwatch/erigon) | Go | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Teljes](#full-sync) | Archív, csökkentett | -| [Reth](https://reth.rs/) | Rust | Linux, Windows, macOS | Mainnet, Sepolia, Holesky | [Teljes](#full-sync) | Archív, megvágott | -| [EthereumJS](https://github.com/ethereumjs/ethereumjs-monorepo) _(béta)_ | TypeScript | Linux, Windows, macOS | Sepolia, Holesky | [Teljes](#full-sync) | Megvágott | - -A támogatott hálózatokkal kapcsolatos további információkért olvassa el az [Ethereum-hálózatok](/developers/docs/networks/) című cikket. - -Minden kliens egyedi felhasználási esetekkel és előnyökkel rendelkezik, ezért a saját preferenciái alapján válasszon közülük. A sokféleség lehetővé teszi, hogy az implementációk különféle szolgáltatásokra és felhasználói közönségekre koncentráljanak. Előfordulhat, hogy a klienseket a szolgáltatások, a támogatás, a programozási nyelv vagy a licencek alapján választja ki. - -### Besu {#besu} - -íA Hyperledger Besu egy vállalati szintű Ethereum-kliens a nyilvános és engedélyhez kötött hálózatokhoz. Az Ethereum-főhálózat összes szolgáltatását támogatja, a nyomon követéstől a GraphQL-ig, kiterjedt felügyeleti funkciót kínál, és a ConsenSys támogatja, mind a nyílt közösségi csatornákon, mind a vállalkozások számára elérhető kereskedelmi SLA-k révén. Java nyelven íródott, és az Apache 2.0 licenc alatt fut. - -A Besu részletes [dokumentációja](https://besu.hyperledger.org/en/stable/) az összes funkció és beállítás tekintetében tájékoztatást nyújt. - -### Erigon {#erigon} - -Az Erigon – korábbi nevén Turbo-Geth – a Go Ethereum elágazásaként indult el a sebességre és a hatékony tárhelyhasználatra fókuszálva. Az Erigon az Ethereum teljesen újraépített implementációja, mely jelenleg Go nyelven elérhető, de más programozási nyelven is lehet majd implementálni. Az Erigon célja egy gyorsabb, modulárisabb és optimalizáltabb Ethereum-implementáció megteremtése. Kevesebb mint 3 nap alatt képes egy 2 TB tárhelyet használó, teljes archív csomópont szinkronizációját elvégezni. - -### Go Ethereum {#geth} - -A Go Ethereum (röviden Geth) az Ethereum protokoll egyik eredeti implementációja. Jelenleg ez a legelterjedtebb kliens a legnagyobb felhasználói bázissal és sokféle eszközzel a felhasználók és a fejlesztők számára. Go nyelven van írva, teljesen nyílt forráskódú, és a GNU LGPL v3 licenc alatt fut. - -További információkat a Geth [dokumentációjában](https://geth.ethereum.org/docs/) talál. - -### Nethermind {#nethermind} - -A Nethermind egy Ethereum-implementáció, amelyet a C# .NET tech stackkel hoztak létre az LGPL-3.0 licenc alatt, és minden nagyobb platformon fut, beleértve az ARM-et is. Nagyszerű teljesítményt nyújt: - -- egy optimizált virtuális géppel; -- állapoteléréssel; -- networkinggel és sokféle funkcióval, mint a Prometheus/Graphana irányítópultok, seq vállalati naplózási támogatás, JSON-RPC nyomon követés és analitikai plugin-ek. - -Ezenkívül a Nethermind [részletes dokumentációval](https://docs.nethermind.io), erős fejlesztői támogatással és online közösséggel is rendelkezik, valamint nonstop támogatással a prémium felhasználók részére. - -### Reth {#reth} - -A Reth (a Rust Ethereum rövidítve) egy Ethereum teljes csomópont-implementáció, amely felhasználóbarát, rendkívül moduláris, gyors és hatékony. A Reth-et eredetileg a Paradigm építette és fejlesztette, és az Apache és MIT alatt van engedélyeztetve. - -A Reth készen áll az éles használatra, olyan kritikus környezetekben is jól használható, mint a letétbe helyezés vagy nagy elérhetőséget igénylő szolgáltatások. Olyan esetekben is jól teljesít, melyek nagy teljesítményt igényelnek jó áron, mint az RPC, MEV, indexálás, szimulációk és peer-to-peer tevékenységek. - -Tudjon meg többet a [Reth Book](https://reth.rs/) vagy a [Reth GitHub repo](https://github.com/paradigmxyz/reth?tab=readme-ov-file#reth) révén. - -### Fejlesztés alatt {#execution-in-development} - -Ezek a kliensek még a fejlesztés korai fázisában vannak, és ezért nem lehet élesben használni őket. - -#### EthereumJS {#ethereumjs} - -Az EthereumJS végrehajtási kliens (EthereumJS) TypeScript nyelven íródott, és számos csomagból áll, beleértve a Block, Transaction és Merkle-Patricia Trie osztályok által képviselt alapvető Ethereum primitíveket, valamint az alapvető klienskomponenseket, beleértve az Ethereum virtuális gép (EVM) implementációját, egy blokkláncosztályt és a DevP2P hálózati stacket. - -Tudjon meg többet erről a [dokumentációból](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master) - -## Konszenzusos kliensek {#consensus-clients} - -Többféle konszenzusos kliens (korábbi nevén „Eth2” kliens) is létezik, amely támogatja a [ konszenzusfrissítéseket](/roadmap/beacon-chain/). Ezek felelnek az összes konszenzushoz kapcsolódó logikáért, beleértve az elágazásalgoritmust, a tanúsítások feldolgozását, valamint a [proof-of-stake](/developers/docs/consensus-mechanisms/pos) jutalmak és büntetések kezelését. - -| Kliens | Nyelv | Operációs rendszerek | Hálózatok | -| ------------------------------------------------------------- | ---------- | --------------------- | ------------------------------------------------------------ | -| [Lighthouse](https://lighthouse.sigmaprime.io/) | Rust | Linux, Windows, macOS | Beacon Chain, Goerli, Pyrmont, Sepolia, Ropsten stb. | -| [Lodestar](https://lodestar.chainsafe.io/) | TypeScript | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia, Ropsten stb. | -| [Nimbus](https://nimbus.team/) | Nim | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia, Ropsten stb. | -| [Prysm](https://docs.prylabs.network/docs/getting-started/) | Go | Linux, Windows, macOS | Beacon Chain, Gnosis, Goerli, Pyrmont, Sepolia, Ropsten stb. | -| [Teku](https://consensys.net/knowledge-base/ethereum-2/teku/) | Java | Linux, Windows, macOS | Beacon Chain, Gnosis, Goerli, Sepolia, Ropsten stb. | -| [Grandine](https://docs.grandine.io/) (béta) | Rust | Linux, Windows, macOS | Beacon Chain, Goerli, Sepolia és mások | - -### Lighthouse {#lighthouse} - -A Lighthouse egy konszenzusos kliens-implementáció, amelyet Rust nyelven írtak, és az Apache-2.0 licenc alatt adták ki. Fenntartója a Sigma Prime, és a Beacon lánc létrejötte óta stabil és szabadon használható. Különböző vállalkozások, letéti alapok és magánszemélyek támaszkodnak rá. Célja a biztonságos, nagy teljesítményű és interoperábilis működés számos különböző környezetben, az asztali számítógépektől egészen a kifinomult, automatizált rendszerekig. - -A dokumentációt a [Lighthouse Book](https://lighthouse-book.sigmaprime.io/) tartalmazza - -### Lodestar {#lodestar} - -A Lodestar egy szabadon használható konszenzusoskliens-implementáció, amelyet TypeScript nyelven írtak, és az LGPL-3.0 licenc alatt adták ki. A fenntartója a ChainSafe Systems, és az önálló letétbe helyezőknek, fejlesztőknek és kutatóknak készült legújabb konszenzusos kliens. A Lodestar egy Beacon-csomópontból és egy validátorkliensből áll, amely az Ethereum-protokollok JavaScript implementációival működik. A Lodestar célja az Ethereum használhatóbbá tétele a könnyű kliensek felhasználói számára, a hozzáférés kiterjesztése egy szélesebb fejlesztői körre, és hogy hozzájáruljon az ökoszisztéma sokszínűségéhez. - -További információ a [Lodestar webhelyünkön](https://lodestar.chainsafe.io/) található - -### Nimbus {#nimbus} - -A Nimbus egy konszenzusos kliens-implementáció, amelyet Nim nyelven írtak, és az Apache-2.0 licenc alatt adták ki. Ez egy szabadon használható kliens, amelyet önálló letétbe helyezők és letéti alapok használnak. A Nimbust erőforráshatékony rendszernek tervezték, emiatt a korlátozott erőforrásokkal rendelkező eszközökön és a vállalati szintű infrastruktúrákon egyaránt könnyű futtatni anélkül, hogy a stabilitást vagy a jutalmat szerző teljesítményt veszélyeztetné. A kisebb erőforráslábnyom azt jelenti, hogy nagy hálózati terheltség mellett nagyobb a kliens biztonsági zónája. - -További információ a [Nimbus-dokumentációban](https://nimbus.guide/) található - -### Prysm {#prysm} - -A Prysm egy teljes körű funkciókat kínáló, nyílt forráskódú konszenzusos kliens, amelyet Go nyelven írtak, és a GPL-3.0 licenc alatt adták ki. Opcionális webalkalmazási felhasználói felületet kínál, előtérbe helyezi a felhasználói élményt, a dokumentációt és a konfigurálhatóságot az otthoni letétbe helyezők és az intézményi felhasználók számára is. - -További információkért tekintse meg a [Prysm-dokumentációt](https://docs.prylabs.network/docs/getting-started/). - -### Teku {#teku} - -A Teku a Beacon lánc egyik eredeti geneziskliense. A szokásos célok (biztonság, szilárdság, stabilitás, használhatóság, teljesítmény) mellett a Teku külön célként tűzte ki, hogy teljes mértékben megfeleljen a különböző konszenzusoskliens-szabványoknak. - -A Teku nagyon rugalmas alkalmazási opciókat kínál. A Beacon-csomópont és a validátorkliens egyetlen folyamatként együtt is futtatható, ami rendkívül kényelmes az önálló letétbe helyezők számára, illetve a csomópontok a kifinomult letéti műveletek érdekében külön is futtathatók. Emellett a Teku teljesen kompatibilis a [Web3Signer](https://github.com/ConsenSys/web3signer/) rendszerrel az aláírásikulcs-biztonság, valamint a súlyos és kizárással járó büntetés (slashing) elkerülése érdekében. - -A Teku Java nyelven íródott és az Apache 2.0 licenc alatt fut. A ConsenSys Protocols csapata fejleszti, amely a Besu és a Web3Signer fejlesztője is. További információk a [Teku-dokumentációban](https://docs.teku.consensys.net/en/latest/) találhatók. - -### Grandine {#grandine} - -A Grandine egy konszenzuskliens-implementáció, amelyet Rust nyelven írtak, és a GPL-3.0 licenc alatt adták ki. Fenntartója a Grandine központi csapata, továbbá gyors, nagy teljesítményre képes és könnyű. A letétbe helyezők széles skálájához illeszkedik, a kis erőforrásigényű eszközökön, például Raspberry Pi-n futó egyéni letétbe helyezőktől kezdve a több tízezer validálót futtató, nagy intézményi letétesekig. - -A dokumentációt a [Grandine Book](https://docs.grandine.io/) tartalmazza - -## Szinkronizálási módok {#sync-modes} - -Ahhoz, hogy az Ethereum-kliens az aktuális adatokat kövesse és hitelesítse a hálózaton, szinkronizálnia kell a legfrissebb hálózati státusszal. Ez úgy történik, hogy adatokat tölt le többi klienstől, kriptográfiailag ellenőrzi azok integritását, és felépít egy helyi blokkláncadatbázist. - -A szinkronizálási módok ennek a folyamatnak a különböző megközelítéseit képviselik eltérő kompromisszumokkal. A kliensek a szinkronizálási algoritmusok végrehajtásában is különböznek. A végrehajtással kapcsolatos konkrétumokról mindig a választott kliens hivatalos dokumentációjából tájékozódjon. - -### A végrehajtási réteg szinkronizálási módjai {#execution-layer-sync-modes} - -A végrehajtási réteg különféle módokon futhat a felhasználási esetek szerint, újravégrehajtva a blokklánc globális állapotát addig, hogy csak a lánc csúcsával szinkronizál egy megbízható ellenőrzési pontból. - -#### Teljes szinkronizálás (full sync) {#full-sync} - -A teljes szinkronizálás letölti az összes blokkot (beleértve a fejléceket és a blokkadatokat), és a genezistől kezdve a blokkok végrehajtásával lépésenként legenerálja a blokklánc státuszát. - -- Minimalizálja a bizalomigényt, és a tranzakciók hiánytalan ellenőrzésével a legmagasabb fokú biztonságot garantálja. -- A tranzakciók növekvő száma miatt az összes tranzakció feldolgozása napokat vagy akár heteket is igénybe vehet. - -Az [archív csomópontok](#archive-node) teljes szinkronizálást végeznek, hogy felépítsék (és megtartsák) a státuszváltozások teljes előzményadatait, melyeket az összes blokk összes tranzakciója indukált. - -#### Gyors szinkronizálás (fast sync) {#fast-sync} - -Ahogy a teljes szinkronizálás, a gyors szinkronizálás is letölt minden blokkot (beleértve a fejléceket, tranzakciókat és visszaigazolásokat). Ugyanakkor nem hajtja újra végre a korábbi tranzakciókat, hanem a visszaigazolásokra támaszkodik, amíg elér a legújabb fejhez, ahol importálásba kezd és feldolgozza a blokkokat, hogy teljes csomópontot adjon. - -- Gyors szinkronizálási stratégia. -- Csökkenti az internet-sávszélességi igényt. - -#### Snap szinkronizálás (snap sync) {#snap-sync} - -A snap szinkronizálás is blokkról blokkra ellenőrzi a láncot. Ugyanakkor nem a genezisblokktól kezdi, hanem egy azt követő, megbízható ellenőrzési ponton, ami valóban része a blokkláncnak. A csomópont elmenti a periodikus ellenőrzési pontokat, miközben törli az adatokat, melyek egy bizonyos időpontnál régebbiek. Ezek a pillanatfelvételek kellenek az adatok újragenerálásához szükségszerint, így nem kell azokat örökre tárolni. - -- A leggyorsabb szinkronizálási stratégia jelenleg az alapértelmezett mód az Ethereum-főhálózaton. -- A biztonság feláldozása nélkül takarít meg nagy lemezterületet és sávszélességet. - -[Bővebben a snap szinkronizálásról](https://github.com/ethereum/devp2p/blob/master/caps/snap.md). - -#### Könnyű szinkronizálás (light sync) {#light-sync} - -A könnyű szinkronizálás letölti az összes blokkfejlécet és blokkadatot, és véletlenszerűen ellenőriz néhányat. Csak a lánc végét szinkronizálja a megbízható ellenőrző ponttól kezdve. - -- Csak a legutolsó állapotot hívja le, és megbízik a fejlesztőkben és a konszenzusmechanizmusban. -- A kliens néhány percen belül készen áll arra, hogy az aktuális hálózati állapottal használják. - -**Megjegyzés**: A proof-of-stake Ethereum-hálózatán még nem működik a könnyű szinkronizálás, ennek új verziói nemsokára használhatóak lesznek! - -[Bővebben a könnyű kliensekről](/developers/docs/nodes-and-clients/light-clients/) - -### A konszenzusréteg szinkronizálási módjai {#consensus-layer-sync-modes} - -#### Optimista szinkronizálás {#optimistic-sync} - -Az optimista szinkronizálás egy Merge utáni szinkronizálási stratégia, amelynek célja az opt-in és a visszamenőleges kompatibilitás megvalósítása, lehetővé téve, hogy a végrehajtási pontok a már bejáratott módszerekkel végezhessék a szinkronizálást. A végrehajtási motor _ optimista módon_ képes a beacon blokkokat importálni azok teljes körű ellenőrzése nélkül, megtalálni a legújabb fejlécet, majd a fenti módszerekkel megkezdeni a lánc szinkronizálását. Majd miután a végrehajtási kliens behozta a lemaradást, értesíti a konszenzusos klienst a Beacon láncon található tranzakciók érvényességéről. - -[Az optimista szinkronizálásról bővebben](https://github.com/ethereum/consensus-specs/blob/dev/sync/optimistic.md) - -#### Ellenőrzésipont-alapú szinkronizálás {#checkpoint-sync} - -Az ellenőrzésipont-alapú vagy más néven gyenge szubjektivitású szinkronizálás első osztályú felhasználói élményt nyújt a Beacon-csomópont szinkronizálásához. A [gyenge szubjektivitás](/developers/docs/consensus-mechanisms/pos/weak-subjectivity/) feltevésein alapul, ami lehetővé teszi, hogy a kliens a Beacon láncot a genezis helyett egy közelmúltbeli, gyenge szubjektivitású ellenőrzési ponttól kezdve szinkronizálja. Ez jelentősen lerövidíti a kezdeti szinkronizálás idejét ahhoz hasonló bizalmi feltevések mellett, mintha a [genezistől](/glossary/#genesis-block) kezdve szinkronizálnánk. - -A gyakorlatban ez azt jelenti, hogy a csomópontunk egy távoli szolgáltatóhoz kapcsolódva a közelmúltban véglegesített állapotokat tölt le, majd attól a ponttól kezdve folytatja az adatok hitelesítését. Az adatokat szolgáltató harmadik fél bizalmat igényel, ezért körültekintően kell kiválasztani. - -Az [ ellenőrzésipont-alapú szinkronizálásról](https://notes.ethereum.org/@djrtwo/ws-sync-in-practice) bővebben - -## További olvasnivaló {#further-reading} - -- [Ethereum-alapismeretek – 2. rész – A csomópontok megértése](https://kauri.io/ethereum-101-part-2-understanding-nodes/48d5098292fd4f11b251d1b1814f0bba/a) _– Wil Barnes, 2019. február 13._ -- [Teljes csomópontok futtatása az Ethereumon: Útmutató az alig motivált felhasználók számára](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux, 2019. november 7._ - -## Kapcsolódó témák {#related-topics} - -- [Blokkok](/developers/docs/blocks/) -- [Hálózatok](/developers/docs/networks/) - -## Kapcsolódó útmutatók {#related-tutorials} - -- [Alakítsa át a Raspberry Pi 4-et validátor-csomóponttá pusztán a MicroSD kártya előkészítésével – Telepítési útmutató](/developers/tutorials/run-node-raspberry-pi/) _– Készítse fel a Raspberry Pi 4-et, csatlakoztasson egy Ethernet-kábelt, csatlakoztassa az SSD-t, és kapcsolja be az eszközt, hogy a Raspberry Pi 4 teljes Ethereum-csomóponttá váljon a végrehajtási rétegen (fő hálózat) és/vagy a konszenzusrétegen (Beacon lánc/validátor)._ diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" deleted file mode 100644 index 5ba397e43bf..00000000000 --- "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/light-clients/index.md" +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Könnyű kliens -description: Az Ethereum könnyű klienseinek bemutatása. -lang: hu ---- - -A teljes csomópont futtatása a leginkább bizalomigény-mentes, decentralizált és cenzúrának ellenálló mód, ahogy az Ethereummal kapcsolódni lehet. A teljes csomópont esetén Ön rendelkezik a blokklánc saját másolatával, amit azonnal lekérdezhet, illetve közvetlen hozzáférése van az Ethereum peer-to-peer hálózatához. Ehhez azonban jelentős memória, tárhely és CPU szükséges. Tehát nem lehetséges mindenki számára, hogy a saját csomópontját működtesse. Az Ethereum ütemterve számos olyan megoldást tartalmaz, mely segít majd ezen, mint például a státuszmentesség, de lehet, hogy csak néhány év múlva kerül bevezetésre. A közeljövőben az a kompromisszum jelenthet megoldást, hogy a teljes csomópont néhány előnyét feláldozzuk olyan teljesítménynövelésre, amivel a csomópont alacsony hardverszükséglettel is működtethető. Ezt a kompromisszumot képviselik a könnyű csomópontok. - -## Mi az a könnyű kliens {#what-is-a-light-client} - -A könnyű csomópont az, amely könnyű kliensszoftvert működtet. Ahelyett, hogy a blokklánc adatának másolatát tartaná és önállóan ellenőrizné a változásokat, a szükséges adatot szolgáltatóktól szerzi be. A szolgáltató lehet egy közvetlen kapcsolat egy teljes csomóponthoz vagy egy központosított RPC-szerveren keresztül. Az adatot ezután ellenőrzi a könnyű csomópont, így kezeli a lánc legfrissebb állapotát. A könnyű csomópont csak a blokkfejlécet kezeli, és csak esetenként tölti le a blokk tartalmát. A csomópontok eltérhetnek a könnyűségükben, mivel a könnyű és a teljes kliensszoftver kombinációját is működtethetik. Például könnyűségi beállítás lehet az, hogy könnyű végrehajtási kliens és könnyű konszenzusos kliens működik. Az is valószínű, hogy számos csomópont könnyű konszenzusos klienst futtat teljes végrehajtási klienssel, vagy fordítva. - -## Hogyan működnek a könnyű kliensek? {#how-do-light-clients-work} - -Amikor az Ethereum átállt a proof-of-stake mechanizmusra, akkor új infrastruktúrát vezetett be a könnyű kliensek támogatására. Ez úgy működik, hogy véletlenszerűen választ ki egy 512 validátorból álló alcsoportot minden 1,1 naponta, hogy **szinkronizálási bizottságként** működjenek. A szinkronizálási bizottság írja alá az éppen aktuális blokkok fejlécét. Minden blokkfejléc tartalmazza a bizottság validátorainak aggregált aláírását és egy bit-mezőt arról, hogy melyik validátor írta alá és melyik nem. Minden fejléc tartalmazza a következő blokk aláírásában részt vevő validátorok listáját is. Eszerint egy könnyű kliens gyorsan értelmezni tudja, hogy a szinkronizálási bizottság aláírta az adatot, amit ő is megkapott, továbbá a bizottság kilétét is igazolni tudja azáltal, hogy az előző blokkban megkapta a résztvevők listáját. Így a könnyű kliens is ismeri a legutóbbi Ethereum-blokkot anélkül, hogy ténylegesen letöltené azt, és csak a fejlécben található összefoglalást kell néznie. - -A végrehajtási rétegen nem létezik egyetlen specifikáció a könnyű végrehajtási kliensre. Ennek tartományába belefér a teljes kliens „könnyű üzemmódja”, ami rendelkezik a teljes csomópont összes EVM- és hálózati funkcionalitásával, de csak a blokkfejlécet ellenőrzi, a kapcsolódó adatot nem tölti le; vagy lehet egy sokkal egyszerűbb kliens is, amelynek az Ethereummal való kapcsolata az RPC-szolgáltatónak küldött kérésen alapszik. - -## Miért fontosak a könnyű kliensek? {#why-are-light-clients-important} - -A könnyű kliensek azért fontosak, mert lehetővé teszik a felhasználóknak, hogy ellenőrizni tudják a bejövő adatokat, és ne kelljen vakon megbízni az adatszolgáltatók korrekt és egyenes hozzáállásában, és mindeközben a teljes csomópont számítási erőforrásának csak egy apró töredékét használják. A könnyű kliensek által kapott adatot össze kell vetni a blokkfejléccel, amelyet már aláírt az Ethereum-validátorok véletlenszerűen választott, 512 tagból álló bizottságának legalább 2/3-a. Ez egy nagyon erős bizonyíték arra vonatkozóan, hogy az adat helyes. - -A könnyű kliens a számítási kapacitás, memória és tárhely töredékét használja csak, ezért mobilon is futtatható, beágyazható egy alkalmazásba vagy egy böngésző részeként is működhet. A könnyű kliensek megadják a lehetőséget arra, hogy az Ethereumhoz minimális bizalomigényű hozzáférése legyen a felhasználónak, ami épp annyira egyszerű, mint megbízni egy harmadik fél által adott szolgáltatásban. - -Vegyünk egy egyszerű példát. Tegyük fel, Ön meg szeretné nézni a számlaegyenlegét. Ehhez egy kérést kell küldenie egy Ethereum-csomópontnak. Ez a csomópont megnézi az Ethereum státuszáról készült saját másolatát az egyenlegért, és azt visszaküldi Önnek. Ha Önnek nincs közvetlen hozzáférése egy csomóponthoz, akkor központi szolgáltatók adják meg ezt az adatot. Ön küld egy kérést e szolgáltatóknak, akik ellenőrzik a csomópontjukat, és visszaküldik az eredményt. Ezzel annyi a probléma, hogy Önnek meg kell bíznia a szolgáltatóban, hogy a helyes információt adja. Sosem tudhatja, hogy az információ helyes, ha nem ellenőrzi maga. - -A könnyű kliens megoldja ezt a problémát. Ön ekkor is egy külső adatszolgáltatótól kér információt, de az adat egy bizonyítékkal érkezik, melyet a könnyű csomópont le tud ellenőrizni a blokkfejléchez képest. Tehát az Ethereum ellenőrzi az adat helyességét egy bizalmat igénylő szolgáltató helyett. - -## Milyen innovációkat tesznek lehetővé a könnyű kliensek? {#what-innovations-do-light-clients-enable} - -Az elsődleges előnye a könnyű klienseknek az, hogy több ember fér hozzá az Ethereumhoz független módon, jelentéktelen hardvert igényel és minimális a függés a harmadik felektől. Ez jó a felhasználóknak, mert ellenőrizni tudják a saját adataikat, és jó a hálózatnak is, mert növeli a csomópontok számát és diverzitását, melyek ellenőrzik a láncot. - -Az innováció egyik fő területe az, hogy az Ethereum-csomópontokat olyan eszközökön is lehet futtatni, amelyek kis tárhellyel, memóriával és feldolgozási kapacitással bírnak. Miközben a mai Ethereum-csomópontok jelentős számítási kapacitást igényelnek, addig a könnyű klienseket be lehet ágyazni a böngészőkbe, mobilon lehet futtatni, és talán még annál is kisebb eszközökön, mint az okosórák. Tehát az Ethereum-tárcák beágyazott kliensekkel futtathatók mobilon is. Emellett a mobiltárcák még inkább decentralizáltak lehetnek, mert az adatokhoz nem egy központi szolgáltatónál jutnak hozzá. - -Ennek kiterjesztése lehetővé teszi **a dolgok internete (IoT)** eszközök használatát is. A könnyű kliens gyorsan igazolni tudja valamilyen tokenegyenleg vagy NFT tulajdonlását, mindazzal a garanciával együtt, amit a szinkronizálási bizottság ad, és valamilyen akciót indít el egy IoT-hálózaton. Vegyünk egy [kerékpárkölcsönzőt](https://youtu.be/ZHNrAXf3RDE?t=929), amely egy alkalmazást használ egy beágyazott könnyű klienssel, hogy gyorsan ellenőrizze, hogy a felhasználónál megtalálható a kölcsönző NFT-je, és ha igen, akkor rendelkezésére bocsát egy kerékpárt! - -Az Ethereum összevont tranzakciói is élvezhetik a könnyű kliensek előnyét. Az összevont tranzakciók egyik nagy problémája az, hogy támadások érik azokat a hidakat, melyeken pénzeszközöket küldenek az Ethereum főhálózatról az összevont tranzakcióra. Az egyik sebezhető pont az összevont tranzakciók által használt orákulum, amellyel felismerik, hogy egy felhasználó letétet helyezett a hídba. Ha az orákulum rossz adatot szolgáltat, akkor rászedheti az összevont tranzakciót, hogy elhiggye a hídnak adott letétet, és így tévesen pénzeszközt adjon át. Az összevont tranzakcióba ágyazott könnyű kliens megvédheti azt a korrupt orákulumoktól, mert a hídnak adott letét egy olyan bizonyítékkal jön, melyet az összevont tranzakció ellenőrizni tud, mielőtt bármilyen tokent átadna. Ugyanez a koncepció alkalmazható más láncok közötti hidaknál. - -A könnyű kliensek az Ethereum-tárcák fejlesztésére is használhatók. Ahelyett, hogy egy RPC-szolgáltató által adott adatban bízna, a tárca közvetlenül ellenőrizni tudná az adatot egy beágyazott könnyű kliens révén. Ez növelné a tárca biztonságát. Ha az RPC-szolgáltató rosszhiszemű volt és helytelen adatot adott, akkor a beágyazott könnyű kliens ezt feltárná Önnek! - -## Mi a könnyű kliens fejlesztésének jelenlegi helyzete? {#current-state-of-development} - -Számos könnyű klienst fejlesztenek, beleértve a végrehajtási, konszenzusos és a kombinált klienseket is. A jelen írás keletkezésekor az alábbi bevezetésekről van információnk: - -- [Lodestar](https://github.com/ChainSafe/lodestar/tree/unstable/packages/light-client): konszenzusos könnyű kliens TypeScript-ben -- [Helios](https://github.com/a16z/helios): kombinált végrehajtási és konszenzusos könnyű kliens Rust-ban -- [Geth](https://github.com/ethereum/go-ethereum/tree/master/beacon/light): a végrehajtási kliens könnyű módozata (fejlesztés alatt áll) Go-ban -- [Nimbus](https://nimbus.guide/el-light-client.html): konszenzusos könnyű kliens Nim-ben - -Tudomásunk szerint ezek még nem állnak készen az éles használatra. - -Számos fejlesztés zajlott akörül is, hogy a könnyű kliensek hogyan férnek hozzá az Ethereum adataihoz. Jelenleg a könnyű kliensek a teljes csomópontoknak adott RPC-kéréseken alapulnak kliens/szerver modellt használva, de a jövőben az adatot egy decentralizáltabb módon is kérhetik egy dedikált hálózatot használva, mint amilyen a [Portal Network](https://www.ethportal.net/), amely képes adatot szolgáltatni a könnyű klienseknek a peer-to-peer pletykaprotokollt használva. - -Más tételek az [ütemtervből](/roadmap/), mint a [Verkle-fák](/roadmap/verkle-trees/) és a [státuszmentesség](/roadmap/statelessness/) végül ugyanazt a biztonsági garanciát fogják elhozni a könnyű klienseknek, mint amilyennel teljes kliensek rendelkeznek. - -## További olvasnivaló {#further-reading} - -- [Felföldi Zsolt a Geth könnyű kliensekről](https://www.youtube.com/watch?v=EPZeFXau-RE) -- [Etan Kissling a könnyű kliens networkingről](https://www.youtube.com/watch?v=85MeiMA4dD8) -- [Etan Kissling a könnyű kliensekről az egyesítés (Merge) után](https://www.youtube.com/watch?v=ZHNrAXf3RDE) -- [Piper Merriam: A működő könnyű kliensekhez vezető kanyargós ösvény](https://snakecharmers.ethereum.org/the-winding-road-to-functional-light-clients/) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" deleted file mode 100644 index ebe15f5ec10..00000000000 --- "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/node-architecture/index.md" +++ /dev/null @@ -1,57 +0,0 @@ ---- -title: Csomópont-architektúra -description: Bevezetés az Ethereum-csomópontok szerveződésébe. -lang: hu ---- - -Egy Ethereum-csomópont két kliensből áll: egy [végrehajtási kliensből](/developers/docs/nodes-and-clients/#execution-clients) és egy [konszenzusos kliensből](/developers/docs/nodes-and-clients/#consensus-clients). - -Amikor az Ethereum a [proof-of-work (munkaigazolás)](/developers/docs/consensus-mechanisms/pow/) mechanizmusát használta, akkor a végrehajtási kliens elegendő volt egy teljes Ethereum-csomópont futtatásához. A [proof-of-stake (letétigazolás)](/developers/docs/consensus-mechanisms/pow/) mechanizmusának bevezetésétől a végrehajtási kliens egy másik szoftverrel együtt kell működtetni, amely a [konszenzusos kliens](/developers/docs/nodes-and-clients/#consensus-clients). - -Ez az ábra a két Ethereum-kliens kapcsolatát mutatja. A két kliens a saját megfelelő peer-to-peer (P2P), azaz társak közötti hálózatához kapcsolódik. Külön P2P hálózatra van szükségük, mert a végrehajtási kliens a saját hálózatán terjeszti a „pletykát” a tranzakciókról, hogy azok a kliensek helyi tranzakciógyűjtőjébe kerülhessenek, miközben a konszenzusos kliens a saját hálózatán a blokkokról „pletykál”, mellyel konszenzust és láncnövekedést ér el. - -![](node-architecture-text-background.png) - -Ahhoz, hogy ez a két kliensből álló struktúra működni tudjon, a konszenzusos klienseknek tranzakciókötegeket kell átadni a végrehajtási kliensnek. Ahogy a kliens ezeket a tranzakciókat lokálisan végrehajtja, le tudja ellenőrizni, hogy nem sértenek-e semmilyen Ethereum szabályt, illetve a javasolt Ethereum státusz korrekt-e. Ehhez hasonlóan, amikor az adott csomópont válik a blokképítővé, akkor a konszenzusos kliensnek tranzakciókötegeket kell kérnie a Geth-től, hogy azokat az új blokkba betegye és végrehajtsa, hogy frissíteni tudja a globális státuszt. Ez a kliensek közötti kommunikáció egy helyi RPC-kapcsolaton keresztül megy végbe az [motor API-t](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) használva. - -## Mit csinál a végrehajtási kliens? {#execution-client} - -A végrehajtási kliens feladata a tranzakciók kezelése, a tranzakciókról való pletykálás, a státusz kezelése és az Ethereum virtuális gép ([EVM](/developers/docs/evm/)) támogatása. Ugyanakkor **nem** felel a blokképítésért, a blokkról való pletykáért vagy a konszenzuslogika kezeléséért. Ezek a konszenzusos kliens feladatai. - -A végrehajtási kliens végrehajtási csomagokat készít, melynek része a tranzakciók listája, a frissített státuszfa és más végrehajtással kapcsolatos adatok. A konszenzusos kliens a végrehajtási csomagot teszi bele a blokkba. A végrehajtási kliens azért is felel, hogy az új blokkok tranzakcióit újrafuttatva biztosítsa azok érvényességét. A tranzakciók újrafuttatása a végrehajtási kliens beépített számítógépén történik, melyet [Ethereum virtuális gépként (EVM)](/developers/docs/evm) ismerünk. - -A végrehajtási kliens emellett egy felhasználói felületet is ajánl az Ethereumnak az [RPC-módszerek](/developers/docs/apis/json-rpc) révén, mellyel a felhasználók adatokhoz juthatnak az Ethereum-blokkláncról, tranzakciókat küldhetnek be és okosszerződéseket hozhatnak létre. Az RPC-kapcsolatot általában egy olyan könyvtár kezeli, mint a [Web3js](https://docs.web3js.org/), [Web3py](https://web3py.readthedocs.io/en/v5/), vagy egy olyan felhasználói felület, mint egy böngészőbővítménnyel rendelkező tárca. - -Összefoglalva a végrehajtási kliens: - -- az Ethereumhoz való hozzáférés a felhasználók számára -- az Ethereum virtuális gép, az Ethereum státusz és a tranzakciógyűjtő helye. - -## Mit csinál a konszenzusos kliens? {#consensus-client} - -A konszenzusos kliens azokat a logikákat kezeli, amellyel a csomópont szinkronban marad az Ethereum-hálózattal. Ebbe beletartozik az, hogy blokkokat kap a társaitól és futtatja az elágazási algoritmust, hogy biztosítsa, a csomópont mindig a láncot követi a tanúsítások lehető legnagyobb hányadát összegyűjtve (melyet a validátor aktuális egyenlege súlyoz). A végrehajtási klienshez hasonlóan a konszenzusos klienseknek is saját P2P hálózata van, melyen keresztül megosztják a blokkokat és a tanúsításokat. - -A konszenzusos kliens nem vesz részt a tanúsításban vagy a blokkelőterjesztésben, mivel ezt a validátor teszi, ami egy opcionális, hozzáadott program a konszenzusos klienshez. A konszenzusos kliens validátor nélkül csak azzal foglalkozik, hogy fenntartsa a lánc elejét, vagyis legutóbbi állapotát, hogy a csomópont szinkronizálva maradjon. Ennélfogva a felhasználó képes az Ethereummal a végrehajtási kliensen keresztül kapcsolódni, és biztos lehet abban, hogy azt a megfelelő láncon teszi. - -## Validátorok {#validators} - -A csomópont működtetői hozzáadhatnak egy validátort a konszenzusos klienseikhez azzal, hogy 32 ETH-t letétbe helyeznek a letéti szerződésben. A validátorkliens a konszenzusos klienssel van összecsomagolva, és bármikor hozzá lehet adni egy csomóponthoz. A validátor kezeli a tanúsításokat és a blokkelőterjesztéseket. Lehetővé teszik, hogy a csomópont jutalmakat szerezzen vagy ETH-t veszítsen a büntetések és kizárások révén. A validátorszoftver futtatása megengedi, hogy a csomópont új blokkot is javasolhasson. - -[Bővebben a letétbe helyezésről](/staking/). - -## A csomópontösszehasonlítás elemei {#node-comparison} - -| Végrehajtási kliens | Konszenzusos kliens | Validátor | -| ------------------------------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------ | -| A tranzakciókról pletykál a saját P2P hálózatán | A blokkokról és tanúsításokról pletykál a saját P2P hálózatán | Blokkot javasol | -| Végrehajt vagy újra végrehajt tranzakciókat | Az elágazási algoritmust futtatja | Jutalmakat/büntetéseket szerez | -| Ellenőrzi a bejövő státuszváltozásokat | A lánc elejét, vagyis legfrissebb állapotát követi | Tanúsításokat végez | -| Kezeli a státuszhoz és a visszaigazolásokhoz tartozó fastruktúrákat | A Beacon-státuszt kezeli (ami konszenzusos és végrehajtási infókat tartalmaz) | 32 ETH letétbe helyezése szükséges hozzá | -| Végrehajtási csomagokat készít | A felhalmozott véletlenszerűséget trekkeli a RANDAO-ban | Súlyos és kizárással járó büntetést kaphat | -| JSON-RPC API-t ad az Ethereummal való kapcsolódáshoz | Az ellenőrzést és véglegesedést trekkeli | | - -## További olvasnivaló {#further-reading} - -- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos) -- [Blokkjavaslat](/developers/docs/consensus-mechanisms/pos/block-proposal) -- [A validátor jutalmai és büntetései](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" deleted file mode 100644 index 299af6a2d47..00000000000 --- "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/nodes-as-a-service/index.md" +++ /dev/null @@ -1,419 +0,0 @@ ---- -title: Csomópontok, mint szolgáltatás -description: Belépőszintű áttekintés a csomópontszolgáltatásokról, az előnyökről és hátrányokról, valamint a népszerű szolgáltatókról. -lang: hu -sidebarDepth: 2 ---- - -## Bevezetés {#Introduction} - -A saját [Ethereum csomópont](/developers/docs/nodes-and-clients/#what-are-nodes-and-clients) futtatása kihívás lehet, különösen az induláskor, vagy amikor gyorsan növekszik. [Számos szolgáltatás van](#popular-node-services), mely optimizált csomópontinfrastruktúrát futtat a felhasználónak, így ő inkább az alkalmazás vagy termék fejlesztésére összpontosíthat. A továbbiakban feltárjuk, hogyan működnek a csomópontszolgáltatások, mik a használatuk előnyei és hátrányai, valamint bemutatjuk a szolgáltatókat, ha szeretne ilyet igénybe venni. - -## Előfeltételek {#prerequisites} - -Ha most ismerkedik a témával, akkor először nézze meg a [Csomópontok és kliensek](/developers/docs/nodes-and-clients/) című anyagot. - -## Letétbe helyezők {#stakoooooooooooooors} - -Az önálló letétbe helyezők inkább saját infrastruktúrát kell futtassanak, mint hogy egy harmadik fél által nyújtott szolgáltatásra támaszkodnának. Ez azt jelenti, hogy egy végrehajtási klienst kell futtatni egy konszenzusos klienssel együtt. Az [egyesítés (Merge)](/roadmap/merge) előtt lehetséges volt csak egy konszenzusos kliens futtatása és egy központi szolgáltató nyújtotta a végrehajtási adatot, de ez már nem működik, az önálló letétbe helyezőnek mind a két klienst működtetnie kell. Ugyanakkor vannak olyan szolgáltatások, melyek megkönnyítik ezt. - -[Bővebben a csomópont futtatásáról](/developers/docs/nodes-and-clients/run-a-node/). - -Ezen az oldalon olyan szolgáltatásokat mutatunk be, amelyek a nem letétbe helyező csomópontokra vonatkoznak. - -## Hogyan működnek a csomópont-szolgáltatások? {#how-do-node-services-work} - -A csomópont-szolgáltatók elosztott csomópontklienseket futtatnak a háttérben, így a felhasználónak nem kell. - -Ezek a szolgáltatások általában egy API-kulcsot adnak, amivel a felhasználó írhat a blokkláncra és olvashat onnan. Gyakran biztosítanak hozzáférést az [Ethereum teszthálózatokhoz](/developers/docs/networks/#ethereum-testnets) a főhálózat mellett. - -Egyes szolgáltatások olyan dedikált csomópontot kínálnak, amelyet egyedül az Ön számára tartanak fenn, míg mások terheléselosztókat használnak a tevékenység elosztására a csomópontok között. - -Szinte az összes csomópont-szolgáltatás rendkívül könnyen integrálható, egy sornyi változtatással jár a kódban, hogy kicserélje az önállóan üzemeltetett csomópontot, vagy a szolgáltatások között váltson. - -A csomópont-szolgáltatók gyakran különféle [csomópontklienseket](/developers/docs/nodes-and-clients/#execution-clients) és [-típusokat](/developers/docs/nodes-and-clients/#node-types) futtatnak, lehetővé téve ezzel a teljes vagy archív csomópontok elérését amellett, hogy kliensspecifikus metódusokat érnek el egy API-ban. - -Fontos megjegyezni, hogy a csomópont-szolgáltatások nem tárolják és nem is tárolhatják a privát kulcsokat vagy az adatokat. - -## Mik az előnyei a csomópont-szolgáltatások használatának? {#benefits-of-using-a-node-service} - -A csomópontszolgáltatás használatának legfőbb előnye, hogy Önnek a programozás mellett nem kell időt töltenie a csomópontok fenntartásával és kezelésével. Ez lehetővé teszi, hogy a termék építésére összpontosítson, és ne aggódjon az infrastruktúra karbantartása miatt. - -Saját csomópontok futtatása igen költséges lehet, figyelembe véve a tárhelyet, sávszélességet és a ráfordított, értékes programozási időt. Az olyan dolgok, mint a több csomópont felállítása a méretezéskor, a csomópontok frissítése a legújabb verziókra és a státusz konzisztenciájának biztosítása, elvonhatják a fejlesztőt a kívánt web3-termék építésétől és csökkentik a ráfordított erőforrásokat. - -## Mik a hátrányai a csomópont-szolgáltatások használatának? {#cons-of-using-a-node-service} - -A csomópontszolgáltatás használatával a felhasználó központosítja az általa fejlesztett termék infrastrukturális aspektusát. Ezért azok a projektek, amelyek a decentralizációt tartják kiemelt fontosságúnak, előnyben részesíthetik az saját fenntartású csomópontokat szemben egy harmadik fél szolgáltatásával. - -Tudjon meg többet a [saját csomópont üzemeltetésének előnyeiről](/developers/docs/nodes-and-clients/#benefits-to-you). - -## Népszerű csomópont-szolgáltatások {#popular-node-services} - -Az alábbiak a legnépszerűbb Ethereum-csomópontszolgáltatók – ha ismer olyat, amit ajánlana, akkor adja hozzá! Minden csomópont-szolgáltatás különböző előnyöket és szolgáltatásokat kínál az ingyenes vagy fizetett szintek mellett. A döntés meghozatala előtt meg kell vizsgálnia, hogy melyik felel meg legjobban az igényeinek. - -- [**Alchemy**](https://alchemy.com/) - - [Dokumentáció](https://docs.alchemyapi.io/) - - Jellemzők - - A legnagyobb ingyenes opció 300 M számítási egység havonta (kb. 30 M getLatestBlock-lekérdezés) - - Több blokklánc támogatása a Polygon, Starknet, Optimism, Arbitrum részére - - A legnagyobb Ethereum dappok és DeFi tranzakciómennyiségek 70%-át lefedi - - Valós idejű webhook-figyelmeztetés az Alchemy Notify révén - - Kiváló támogatás, valamint megbízhatóság és stabilitás - - Alchemy NFT API - - Irányítópult, melynek része a Request Explorer, Mempool Watcher és a Composer - - Integrált teszthálózati csaphozzáférés - - Aktív Discord építőközösség 18 000 felhasználóval - -- [**All That Node**](https://allthatnode.com/) - - [Dokumentáció](https://docs.allthatnode.com/) - - Jellemzők - - Napi 50 000 kérés az ingyenes opcióban - - Több mint 40 protokoll támogatása - - JSON-RPC (EVM, Tendermint), REST és Websocket API-ok támogatása - - Korlátlan hozzáférés az archív adatokhoz - - A hét minden napján, napi 24 órában rendelkezésre álló technikai támogatás és 99,9%-nál nagyobb rendelkezésre állás - - Elérhető csap több láncon is - - Korlátlan végponthozzáférés korlátlan számú API-kulccsal - - Trace/Debug API támogatás - - Automatikus frissítések - -- [**Amazon Managed Blockchain**](https://aws.amazon.com/managed-blockchain/) - - [Dokumentáció](https://aws.amazon.com/managed-blockchain/resources/) - - Jellemzők - - Teljeskörűen kezelt Ethereum csomópontok - - Hat régióban elérhető - - JSON-RPC HTTP-n és biztonságos WebSockets-en - - Három láncot támogat - - SLA-k, AWS támogatás 24/7 - - Go-ethereum és Lighthouse - -- [**Ankr**](https://www.ankr.com/) - - [Dokumentáció](https://docs.ankr.com/) - - Jellemzők - - Az Ankr-protokollnak több mint 8 láncra van nyílt hozzáférése a publikus RPC API-végpontokhoz - - Terheléselosztás és a csomópont állapotának felügyelete annak érdekében, hogy a felhasználó gyorsan és megbízható módon elérje a legközelebbi csomópontot - - Prémium opció, amely WSS-végpontot és korlátlan rátát biztosít - - Teljes és validátor-csomópont beállítása egyetlen kattintással több mint 40 láncra - - Menet közbeni méretezés - - Analitikai eszközök - - Irányítópult (dashboard) - - RPC, HTTPS és WSS végpontok - - Közvetlen támogatás - -- [**Blast**](https://blastapi.io/) - - [Dokumentáció](https://docs.blastapi.io/) - - Jellemzők - - RPC- és WSS-támogatás - - Többrégiós csomópont-szolgáltatás - - Decentralizált infrastruktúra - - Publikus API - - Dedikált ingyenes csomag - - Több láncra (>17) vonatkozó támogatás - - Archív csomópontok - - Napi 24 órás Discord támogatás a hét minden napján - - Napi 24 órás felügyelet és riasztások a hét minden napján - - Összességében 99,9% SLA - - Fizetési lehetőség kriptóban - -- [**BlockDaemon**](https://blockdaemon.com/) - - [Dokumentáció](https://ubiquity.docs.blockdaemon.com/) - - Előnyök - - Vezérlőpult - - Csomópontként - - Elemzések - -- [**BlockPI**](https://blockpi.io/) - - [Dokumentáció](https://docs.blockpi.io/) - - Jellemzők - - Robosztus és elosztott csomópontstruktúra - - Akár 40 HTTPS és WSS-végpont - - Ingyenes kezdőcsomag és havi csomag - - Nyomonkövetési módszer + archív adattámogatás - - A csomagok 90 napig érvényesek - - Személyre szabott csomag és menet közbeni fizetés - - Fizetési lehetőség kriptóban - - Közvetlen és technikai támogatás - -- [**Chainbase**](https://www.chainbase.com/) - - [Dokumentáció](https://docs.chainbase.com) - - Jellemzők - - Elérhető, gyors és skálázható RPC szolgáltatás - - Több láncot lefedő támogatás - - Ingyenes díjszabások - - Felhasználó barát irányítópult - - Blokklánc-adatszolgáltatás az RPC-n túl - -- [**Chainstack**](https://chainstack.com/) - - [Dokumentáció](https://docs.chainstack.com/) - - Jellemzők - - Ingyenes megosztott csomópontok - - Megosztott archív csomópontok - - GraphQL-támogatás - - RPC- és WSS-végpontok - - Dedikált teljes és archív csomópontok - - Gyors szinkronizálási idő a dedikált bevezetésekre - - Saját felhőt hozhat - - Óránkénti árazás - - Közvetlen, napi 24 órás támogatás a hét minden napján - -- [**DataHub**](https://datahub.figment.io) - - [Dokumentáció](https://docs.figment.io/) - - Jellemzők - - Ingyenes opció 3 000 000 havi lekéréssel - - RPC- és WSS-végpontok - - Dedikált teljes és archív csomópontok - - Automatikus méretezhetőség (mennyiségi kedvezmények) - - Ingyenes archív adatok - - Szolgáltatáselemzések - - Vezérlőpult - - Közvetlen, napi 24 órás támogatás a hét minden napján - - Fizetési lehetőség kriptóban (vállalat) - -- [**DRPC**](https://drpc.org/) - - [Dokumentáció](https://docs.drpc.org/) - - Jellemzők - - Decentralizált RPC-csomópontok - - Több mint 15 csomópont-szolgáltató - - Csomópont-kiegyensúlyozás - - Korlátlan számítási egység havonta az ingyenes opcióban - - Adatellenőrzés - - Személyre szabott végpontok - - Http és WSS-végpontok - - Korlátlan mennyiségű kulcs (ingyenes és fizetett opcióban) - - Rugalmas fallback opciók - - [Publikus végpont](https://eth.drpc.org) - - Ingyenes, megosztott archív csomópontok - -- [**GetBlock**](https://getblock.io/) - - [Dokumentáció](https://getblock.io/docs/get-started/authentication-with-api-key/) - - Jellemzők - - Hozzáférés több mint 40 blokklánc-csomóponthoz - - 40 000 ingyenes napi lekérdezés - - Korlátlan számú API-kulcs - - Gyors kapcsolódási sebesség 1 GB/másodpercnél - - Nyomon követés és archiválás - - Korszerű elemzések - - Automatikus frissítések - - Technikai támogatás - -- [**InfStones**](https://infstones.com/) - - Jellemzők - - Ingyenes opció - - Menet közbeni méretezés - - Elemzések - - Irányítópult (dashboard) - - Egyedi API-végpontok - - Dedikált teljes csomópontok - - Gyors szinkronizálási idő a dedikált bevezetésekre - - Közvetlen, napi 24 órás támogatás a hét minden napján - - Hozzáférés több mint 50 blokklánc-csomóponthoz - -- [**Infura**](https://infura.io/) - - [Dokumentáció](https://infura.io/docs) - - Jellemzők - - Ingyenes opció - - Menet közbeni méretezés - - Fizetős archív adatok - - Közvetlen támogatás - - Irányítópult (dashboard) - -- [**Kaleido**](https://kaleido.io/) - - [Dokumentáció](https://docs.kaleido.io/) - - Jellemzők - - Ingyenes kezdőopció - - Ethereum-csomópont beállítása egyetlen kattintással - - Személyre szabható kliensek és algoritmusok (Geth, Quorum és Besu || PoA, IBFT és Raft) - - Több mint 500 adminisztratív és szolgáltatói API - - RESTful-interfész az Ethereum-tranzakciók beküldésére (Apache Kafka támogatott) - - Kimenő adatfolyamok esemény-végrehajtáshoz (Apache Kafka támogatott) - - Kimerítő láncon kívüli adatok és kiegészítő szolgáltatások (pl. kétoldalú titkosított üzentátadás) - - Egyértelmű becsatlakozás a hálózatba irányítással és szerepkör szerinti hozzáféréskontroll - - Szofisztikált felhasználókezelés az adminisztrátorok és a végfelhasználók felé is - - Nagy mértékben skálázható, rugalmas, vállalati szintű infrastruktúra - - Felhőalapú HSM privátkulcs-kezelés - - Ethereum főhálózathoz kötött - - ISO 27k és SOC 2, Type 2 tanúsítványok - - Dinamikus runtime-konfiguráció (pl. felhőintegráció hozzáadása, csomópontbemenet-változtatás stb.) - - Támogatja a többfelhős, többrégiós és hibrid telepítési beállításokat - - Egyszerű, óránkénti SaaS-alapú árazás - - SLA-k és napi 24 órás támogatás a hét minden napján - -- [**Lava-hálózat**](https://www.lavanet.xyz/) - - [Dokumentáció](https://docs.lavanet.xyz/) - - Jellemzők - - Ingyenes teszthálózathasználat - - Decentralizált redundancia a nagy arányú elérhetőség érdekében - - Nyílt forráskódú - - Teljesen decentralizált SDK - - Ethers.js-integráció - - Intuitív projektmenedzsment interfész - - Konszenzusalapú adatintegritás - - Több láncot lefedő támogatás - -- [**Moralis**](https://moralis.io/) - - [Dokumentáció](https://docs.moralis.io/) - - Jellemzők - - Ingyenes megosztott csomópontok - - Ingyenes, megosztott archív csomópontok - - Adatvédelmi fókuszú (naplózás nélküli szabályzat) - - Láncokon átívelő támogatás - - Menet közbeni méretezés - - Irányítópult (dashboard) - - Egyedi Ethereum SDK - - Egyedi API-végpontok - - Közvetlen, technikai támogatás - -- [**NodeReal MegaNode**](https://nodereal.io/) - - [Dokumentáció](https://docs.nodereal.io/nodereal/meganode/introduction) - - Jellemzők - - Megbízható, gyors és skálázható RPC API-szolgáltatások - - Továbbfejlesztett API a web3-fejlesztőknek - - Több láncot lefedő támogatás - - Ingyenes kezdési lehetőség - -- [**NOWNodes**](https://nownodes.io/) - - [Dokumentáció](https://documenter.getpostman.com/view/13630829/TVmFkLwy) - - Jellemzők - - Hozzáférés több mint 50 blokklánc-csomóponthoz - - Ingyenes API-kulcs - - Blokkfelfedezők - - Az API-válaszidő kevesebb mint 1 másodperc - - A hét minden napján, napi 24 órában rendelkezésre álló támogató csapat - - Személyes számlakezelő - - Megosztott, archív, biztonsági és dedikált csomópontok - -- [**Pocket Network**](https://www.pokt.network/) - - [Dokumentáció](https://docs.pokt.network/home/) - - Jellemzők - - Decentralizált RPC-protokoll és piactér - - Ingyenes opció 1M lekérdezéssel naponta (végpontonként, max. 2) - - [Nyilvános végpontok](https://docs.pokt.network/developers/public-endpoints) - - Letétbe helyezés előtti program (ha 1M napi lekérdezésnél többre van szükség) - - Több mint 15 láncot támogat - - 6400-nál több csomópont szerez POKT-ot az applikációk kiszolgálásából - - Archív csomópont, archív csomópont nyomon követéssel, teszthálózat-csomóponttámogatás - - Ethereum főhálózat csomóponti kliensdiverzitás - - Nincs egyetlen meghibásodási pont - - Nincs kimaradás a szolgáltatásban - - Költséghatékony, nullához közeli tokengazdaságtan (POKT letétbe helyezése egyszer a hálózati szélessávért) - - Nincs havi elsüllyedt költség, eszközzé változtatja az infrastruktúrát - - A terheléseloszlás be van építve a protokollba - - A napi lekérésmennyiséget és az óránkénti csomópontokat a végtelenségig skálázza úgy, ahogy Ön halad előre - - A leginkább privát, cenzúrának ellenálló opció - - Gyakorlati fejlesztőtámogatás - - [Pocket Portal](https://bit.ly/ETHorg_POKTportal) irányítópult és elemzések - -- [**QuickNode**](https://www.quicknode.com) - - [Dokumentáció](https://www.quicknode.com/docs/) - - Jellemzők - - A hét minden napján, napi 24 órában rendelkezésre álló technikai támogatás és fejlesztői Discord-közösség - - Földrajzilag kiegyensúlyozott, többfelhős/-gépes, rövid késleltetésű hálózat - - Több láncra vonatkozó támogatás (Optimism, Arbitrum, Polygon + 11 más) - - Köztes rétegek a gyorsaság és a stabilitás érdekében (call routing, cache, indexálás) - - Okosszerződés-felügyelet a webhookokon keresztül - - Intuitív irányítópult, elemzési készlet, RPC composer - - Fejlett szintű biztonsági jellemzők (JWT, maszkolás, fehérlistázás) - - NFT-adatok és elemzési API - - [SOC2-tanúsítvánnyal](https://www.quicknode.com/security) - - Bárki számára alkalmas, legyen szó fejlesztőkről vagy nagyvállalatokról - -- [**Rivet**](https://rivet.cloud/) - - [Dokumentáció](https://rivet.readthedocs.io/en/latest/) - - Jellemzők - - Ingyenes opció - - Menet közbeni méretezés - -- [**SenseiNode**](https://senseinode.com) - - [Dokumentáció](https://docs.senseinode.com/) - - Jellemzők - - Dedikált és megosztott csomópontok - - Irányítópult (dashboard) - - Az AWS-en kívüli több szolgáltató biztosítja több helyen Latin-Amerikában - - Prysm és Lighthouse kliensek - -- [**SettleMint**](https://console.settlemint.com/) - - [Dokumentáció](https://docs.settlemint.com/) - - Jellemzők - - Ingyenes próba - - Menet közbeni méretezés - - GraphQL-támogatás - - RPC- és WSS-végpontok - - Dedikált teljes csomópontok - - Saját felhőt hozhat - - Analitikai eszközök - - Irányítópult (dashboard) - - Óránkénti árazás - - Közvetlen támogatás - -- [**Tenderly**](https://tenderly.co/web3-gateway) - - [Dokumentáció](https://docs.tenderly.co/web3-gateway/web3-gateway) - - Jellemzők - - Ingyenes opció, mely 25 millió Tenderly egységet tartalmaz havonta - - Ingyenes hozzáférés az előzményadatokhoz - - 8-szor gyorsabb olvasásintenzív terhelés - - 100%-ban konzisztens olvasási hozzáférés - - JSON-RPC-végpontok - - UI-alapú RPC lekérdezésépítő és lekérdezés-előnézet - - Szorosan integrált a Tenderly fejlesztéssel, hibajavítással és tesztelőeszközökkel - - Tranzakciószimulációk - - Használatelemzés és szűrés - - Könnyű hozzáférésikulcs-kezelés - - Dedikált programozói támogatás csevegés, e-mail és Discord által - -- [**Tokenview**](https://services.tokenview.io/) - - [Dokumentáció](https://services.tokenview.io/docs?type=nodeService) - - Jellemzők - - A hét minden napján, napi 24 órában rendelkezésre álló technikai támogatás és fejlesztői Telegram-közösség - - Több láncot támogat (Bitcoin, Ethereum, Tron, BNB Smart Chain, Ethereum Classic) - - RPC- és WSS-végpontok nyitott használata - - Korlátlan hozzáférés az archív adatot szolgáltató API-hoz - - Dashboard Request Explorer és Mempool Watcher funkcióval - - NFT-adatszolgáltató API és Webhook figyelmeztetés - - Fizetési lehetőség kriptóban - - Külső támogatás az extra funkcionális igényekhez - -- [**Watchdata**](https://watchdata.io/) - - [Dokumentáció](https://docs.watchdata.io/) - - Jellemzők - - Adatmegbízhatóság - - Megszakításmentes kapcsolat nulla leállással - - Folyamatautomatizálás - - Ingyenes díjszabások - - Magasan meghúzott határok, melyek mindenféle felhasználóhoz illeszkednek - - Támogatás a különféle csomópontok számára - - Erőforrás-méretezhetőség - - Gyors feldolgozási sebesség - -- [**ZMOK**](https://zmok.io/) - - [Dokumentáció](https://docs.zmok.io/) - - Jellemzők - - Front-running mint szolgáltatás - - Globális tranzakciógyűjtőhely kereső/szűrőmódszerekkel - - Korlátlan TX díj és végtelen gáz a tranzakcióküldéshez - - A leggyorsabban szerzi meg az új blokkot és olvassa a blokkláncot - - Az API hívásonkénti legjobb ár garantált - -- [**Zeeve**](https://www.zeeve.io/) - - [Dokumentáció](https://www.zeeve.io/docs/) - - Jellemzők - - Vállalatszintű, kódnélküli automatizációs platform, ami a blokklánc-csomópontok és hálózatok telepítését, felügyeletét és menedzselését biztosítja - - Több mint 30 támogatott protokoll és integráció, és még több jön - - Értékes web3-infrastruktúraszolgáltatások, mint a decentralizált tárhely, decentralizált identitás és a blokkláncfőkönyv-adatszolgáltató API-k valódi felhasználási módokra - - A hét minden napján, napi 24 órában rendelkezésre álló támogatás és proaktív felügyelet, amely mindenkor biztosítja a csomópontok egészségét. - - RPC-végpontok, melyek hitelesített hozzáférést kínálnak az API-okhoz, valamint problémamentes kezelést biztosítanak az intuitív irányítópultokkal és elemzésekkel. - - Egyaránt biztosít a cég által adott felhő és a felhasználó saját felhőjével működő opciókat, és támogatja a legtöbb felhőszolgáltatót, mint AWS, Azure, Google Cloud, Digital Ocean és a helyszíni megoldásokat. - - Intelligens routing, hogy a felhasználóhoz legközelebbi csomópontot tudja használni - - -## További olvasnivaló {#further-reading} - -- [Az Ethereumcsomópont-szolgáltatások listája](https://ethereumnodes.com/) - -## Kapcsolódó témák {#related-topics} - -- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) - -## Kapcsolódó útmutatók {#related-tutorials} - -- [Bevezetés az Ethereum fejlesztésbe Alchemy-vel](/developers/tutorials/getting-started-with-ethereum-development-using-alchemy/) -- [Útmutató tranzakció küldéshez a web3 és az Alchemy használatával](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) diff --git "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" "b/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" deleted file mode 100644 index d3161ec3889..00000000000 --- "a/public/content/translations/hu/15) Foundational Docs \342\200\223 Nodes and Clients/developers/docs/nodes-and-clients/run-a-node/index.md" +++ /dev/null @@ -1,480 +0,0 @@ ---- -title: Pörgesse fel saját Ethereum-csomópontját -description: Általános bevezető az Ethereum-kliens saját példányának működtetéséről. -lang: hu -sidebarDepth: 2 ---- - -A saját csomópont működtetése számos előnnyel jár, új lehetőségeket nyit meg, és emellett támogatja az ökoszisztémát. Ez az áttekintés a saját csomópont felpörgetéséről szól, illetve arról, hogyan vegyen részt az Ethereum tranzakciók validálásában. - -Fontos megérteni, hogy az [egyesítés (Merge)](/roadmap/merge) után két kliensre van szükség egy Ethereum-csomópont működtetéséhez: egy **végrehajtási réteg (EL)** és egy **konszenzusréteg (CL)** kliensre. Itt azt mutatjuk be, hogy ezt a két klienst hogyan kell telepíteni, konfigurálni és összekapcsolni az Ethereum-csomópont futtatásához. - -## Előfeltételek {#prerequisites} - -Először is tisztában kell lennie azzal, hogy mi az az Ethereum-csomópont, és mi a lényege annak, hogy klienst futtasson. Ezt megtalálja a [Csomópontok és kliensek](/developers/docs/nodes-and-clients/) című leírásban. - -Ha Önnek újdonság a csomópontok témaköre, vagy egy kevésbé technikai megközelítést szeretne, akkor azt javasoljuk, először tekintse meg az [Ethereum-csomópont futtatása](/run-a-node) című felhasználóbarát ismertetőnket. - -## A megközelítés kiválasztása {#choosing-approach} - -A csomópont felpörgetésének első lépése a megközelítés kiválasztása. Az igények és lehetőségek alapján el kell dönteni a klienstelepítést (a végrehajtási és a konszenzusos kliensre is), a környezetet (hardver, rendszer) és a kliensbeállítás paramétereit. - -A jelen leírás végigvezeti Önt ezeken a döntéseken, hogy megtalálja a leginkább Önnek való módot a saját Ethereum-példányának működtetésére. - -A klienstelepítés eldöntéséhez nézze meg a főhálózaton elérhető [végrehajtási klienseket](/developers/docs/nodes-and-clients/#execution-clients), [konszenzusos klienseket](/developers/docs/nodes-and-clients/#consensus-clients) és tudjon meg többet a [kliensdiverzitásról](/developers/docs/nodes-and-clients/client-diversity). - -El kell döntenie, hogy a szoftvert inkább a saját [hardverén vagy inkább a felhőben](#local-vs-cloud) futtatja, figyelembe véve a kliensek [igényeit](#requirements). - -A környezet kialakítása után telepítse a kiválasztott klienseket egy [kezdőknek is könnyen használható felülettel](#automatized-setup) vagy [manuálisan](#manual-setup) egy terminállal, ahol haladó opciókkal élhet. - -Amikor a csomópont már működik és szinkronizál, akkor Ön elkezdheti [használni](#using-the-node), de ne feledkezzen meg a [karbantartásról](#operating-the-node) sem. - -![Kliensfelállítás](./diagram.png) - -### Környezet és hardver {#environment-and-hardware} - -#### Helyi gépen vagy felhőben {#local-vs-cloud} - -Az Ethereum-klienseket általános számítógépeken is lehet futtatni, nincs szükség hozzá speciális hardverre, mint amilyenek a bányászathoz való gépek. Ennélfogva számos lehetőség adódik egy csomópont telepítésére a felhasználó igényei szerint. Nézzük meg mindkét opciót, amikor egy helyi, fizikai gépen, és amikor egy felhőszerveren vannak a kliensek: - -- Felhő - - A szolgáltatók szinte állandó szerverműködést és statikus nyilvános IP-címeket ajánlanak - - A dedikált vagy virtuális szerver kényelmesebb lehet, mint sajátot építeni - - Ugyanakkor meg kell bízni egy harmadik félben – a szerverszolgáltatóban - - A teljes csomópont nagyobb tárhelyet igényel, ezért a bérelt szerver ára is magasabb lesz -- Saját hardver - - Bizalomigény-mentesebb és önállóbb megközelítés - - Egyszeri befektetés - - Lehetőség van előre konfigurált gépeket vásárolni - - Fizikailag össze kell rakni, karban kell tartani, és valószínűleg meg kell oldania a géppel és a hálózattal kapcsolatban felmerülő problémákat is - -Mindkét opció más előnyökkel jár. Ha felhőalapú megoldás mellett dönt, akkor a hagyományos felhőalapú szolgáltatók mellett léteznek speciális szolgáltatások a csomópontok telepítésére. Tekintse meg a [Csomópontok mint szolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service/) című oldalt a csomópont-szolgáltatókról szóló információkért. - -#### Hardver {#hardware} - -Ugyanakkor egy cenzúrának ellenálló, decentralizált hálózat nem függhet a felhő alapú szolgáltatóktól. Ehelyett az ökoszisztémának egészségesebb, ha a felhasználó a saját csomópontját a saját helyi hardverén üzemelteti. [A becslések](https://www.ethernodes.org/networkType/Hosting) szerint a csomópontok nagy aránya fut felhőn, ami felveti az egyetlen hibaforrás lehetőségét. - -Az Ethereum-klienseket a saját számítógépén, laptopján, szerverén vagy akár egy egykártyás számítógépen is üzemeltetheti. Miközben lehetséges a személyi számítógépen működtetni a klienseket, egy csomópont számára dedikált gép jelentősen növeli a teljesítményt és biztonságot, és minimalizálja az Ön elsődleges számítógépére tett hatást is. - -A saját hardver használata igen könnyű is lehet. Vannak egyszerű opciók, de a műszaki területen jártasabb embereknek fejlettebb összeállítások is elérhetők. Tekintsük át az Ethereum-kliensek számítógépen való futtatásához szükséges feltételeket és eszközöket. - -#### Követelmények {#requirements} - -A hardverkövetelmények kliensenként eltérők, de általánosságban nem magasak, mivel a csomópontnak csak szinkronizálva kell lennie. Nem összekeverendő a bányászattal, amelynek sokkal magasabb számításiteljesítmény-igénye van. Ugyanakkor a szinkronizációs idő és a teljesítmény javul egy erősebb hardverrel. - -Mielőtt telepítene egy klienst, győződjön meg arról, hogy a számítógépe rendelkezik elegendő erőforrással. A minimális és az ajánlott követelményeket alább találja. - -A hardver szűk keresztmetszete leginkább a lemezterület. Az Ethereum blokklánccal való szinkronizálás igen bemenet/kimenet-intenzív folyamat, és sok helyet igényel. A legjobb a **tartós állapotú meghajtó (SSD)**, melyen még a szinkronizálás után is marad sok száz GB-nyi szabad tárhely. - -Az adatbázis mérete és a kezdeti szinkronizálás sebessége függ a kiválasztott klienstől, annak konfigurációjától és a [szinkronizálási stratégiától](/developers/docs/nodes-and-clients/#sync-modes). - -Emellett arról is meg kell győződnie, hogy az internetkapcsolatát nem korlátozza egy [sávszélességi maximum](https://wikipedia.org/wiki/Data_cap). A korlátlan kapcsolódás az ajánlott, mert a kezdeti szinkronizálás és az adat nyilvánossá tétele a hálózaton meg fogja haladni a határt. - -##### Operációs rendszer - -Minden kliens támogatja a legnagyobb operációs rendszereket, mint a Linux, ,macOS, Windows. Tehát a csomópontok működtetéséhez a számítógépén vagy a szerverén olyan operációs rendszert (OS) használ, amilyet szeretne. Biztosítsa, hogy az operációs rendszer frissítve van, hogy ezzel elkerülje a lehetséges hibákat és biztonsági gyengeségeket. - -##### Minimális követelmények - -- Processzor (CPU) 2+ maggal -- 8 GB RAM -- 2 TB SSD -- 10+ MBit/másodperc sávszélesség - -##### Ajánlott követelmények - -- Gyors processzor (CPU) 4+ maggal -- 16 GB+ RAM -- Gyors SSD 2+ TB kapacitással -- 25+ MBit/másodperc sávszélesség - -A szinkronizálási mód és a kiválasztott kliens befolyásolja a lemezterület-igényt, alább a kliensek szerinti becslést láthatja. - -| Kliens | Lemezterület (snap szinkronizálás) | Lemezterület (teljes archívum) | -| ---------- | ---------------------------------- | ------------------------------ | -| Besu | 800 GB+ | 12 TB+ | -| Erigon | N.a. | 2,5 TB+ | -| Geth | 500 GB+ | 12 TB+ | -| Nethermind | 500 GB+ | 12 TB+ | -| Reth | N.a. | 2,2 TB+ | - -- Megjegyzés: az Erigon és a Reth nem ajánl snap szinkronizálási módot, de lehetséges a teljes adatmegvágás (kb. 2 TB az Erigonnál, 1,2 TB a Rethnél) - -A konszenzusos kliens esetében a lemezterület szintén függ a telepítéstől és a beállított jellemzőktől (pl. validátor büntető/kizáró funkció), de általánosságban egy újabb 200 GB-ra van szükség a beacon-adathoz. Sok validátorral a sávszélesség terhelése is növekszik. Ebben az elemzésben [megtalálja a konszenzuskliens követelmények részleteit](https://mirror.xyz/0x934e6B4D7eee305F8C9C42b46D6EEA09CcFd5EDc/b69LBy8p5UhcGJqUAmT22dpvdkU-Pulg2inrhoS9Mbc). - -#### Plug-and-play megoldások {#plug-and-play} - -A saját csomópont futtatása saját hardverrel úgy a legegyszerűbb, ha plug and play csomagot használunk. Az előre beállított gépeknél nem kell mást tenni, mint megrendelni, csatlakoztatni és használni. Minden előre be van konfigurálva és magától fut egy intuitív útmutatóval és a szoftver felügyeletére és irányítására szolgáló irányítópulttal. - -- [DappNode](https://dappnode.io/) -- [Avado](https://ava.do/) - -#### Ethereum egy egykártyás számítógépen {#ethereum-on-a-single-board-computer} - -Egyszerű és olcsó módja egy Ethereum-csomópont futtatásának ha egykártyás számítógépet használunk, akár ARM architektúrával, mint a Raspberry Pi. Az [Ethereum az ARM-on](https://ethereum-on-arm-documentation.readthedocs.io/en/latest/) több végrehajtási és konszenzusos kliens egyszerűen futtatását teszi lehetővé a Raspberry Pi és más ARM-kártyák számára. - -Ezek a kicsi, pénztárcabarát és hatékony eszközök ideálisak a csomópont otthoni futtatására, de a teljesítményük korlátozott lehet. - -## A csomópont felpörgetése {#spinning-up-node} - -Az aktuális kliensfelállítás végezhető automata telepítőkkel vagy manuálisan, közvetlenül telepítve a kliensszoftvert. - -A kevésbé szakértő felhasználók számára az automatikus telepítés a legjobb megoldás, mivel ez a szoftver végigvezeti őket az telepítésen, a kliensbeállításokat pedig magától intézi. Ugyanakkor, akinek van már tapasztalata a terminál használatában, az a manuális beállítás lépéseit is követheti. - -### Vezetett felállítás {#automatized-setup} - -Számos felhasználóbarát projekt arra törekszik, hogy leegyszerűsítse a kliens felállítását. Ezek a bevezetők automatikus klienstelepítést és -konfigurálást kínálnak, emellett néha grafikus felületet is biztosítanak a vezetett beállításhoz és a felügyelethez. - -Több ilyen projektet is találhat alább, melyek segítenek néhány kattintással telepíteni és felügyelni a klienseket: - -- [DappNode](https://docs.dappnode.io/docs/user/getting-started/choose-your-path) - A DappNode nem csak a gyártótól származó géppel kapható. A szoftvert, a csomópont-telepítőt és a számos jellemzővel bíró irányítási központot tetszőleges hardveren is használhatja. -- [eth-docker](https://eth-docker.net/) – Az automatikus beállítás a Docker használatával arra fókuszál, hogy egyszerű és biztonságos legyen a letétbe helyezés – egy alapvető terminál és Docker-ismeret szükséges hozzá, ezért a haladóbb felhasználóknak ajánlott. -- [Stereum](https://stereum.net/ethereum-node-setup/) – Telepítő a kliens távoli szerveren, SSH-kapcsolódáson keresztüli telepítéséhez egy GUI beállítási útmutatóval, irányítási központtal és számos egyéb jellemzővel. -- [NiceNode](https://www.nicenode.xyz/) – Telepítő az egyértelmű felhasználói élményért, amely leírja, hogyan futtasson csomópontot saját számítógépén. Csak válassza ki a klienseket, és néhány kattintással indítsa el azokat. Még fejlesztés alatt áll. -- [Sedge](https://docs.sedge.nethermind.io/docs/intro) – Csomópont-felállítási eszköz, amely automatikusan generál egy Docker-konfigurációt a CLI-varázslót használva. Go nyelven írta a Nethermind. - -### Manuális kliensfelállítás {#manual-setup} - -Ez a másik lehetőség, hogy a kliensszoftvert manuális letöltse, ellenőrizze és konfigurálja. Még ha bizonyos kliensek ajánlanak is grafikus felületet, a manuális beállításhoz szükség van alapvető terminálismeretekre, de közben nagy mértékű rugalmasságot tesznek lehetővé. - -Ahogy említettük, az Ethereum-csomópont működtetéséhez egy konszenzusos kliens és egy végrehajtási kliens szükséges. Néhány kliens tartalmazhat másik típusú könnyű klienst és előfordulhat, hogy a szinkronizáláshoz sem kell más szoftver. Ugyanakkor a teljes, bizalomigény-mentes ellenőrzéshez mindkét klienst telepíteni kell. - -#### A kliensszoftver megszerzése {#getting-the-client} - -Először meg kell szerezni a kiválasztott [végrehajtási kliens](/developers/docs/nodes-and-clients/#execution-clients) és [konszenzusos kliens](/developers/docs/nodes-and-clients/#consensus-clients) szoftverét. - -Egyszerűen töltsön le egy végrehajtható alkalmazást vagy egy telepítőcsomagot, ami megfelel az operációs rendszernek és az architektúrának. Mindig ellenőrizze az aláírásokat és a letöltött csomagok ellenőrző összegét. Néhány kliens mappákat vagy Docker képeket is ajánl az egyszerűbb telepítés és frissítések érdekében. Minden kliens nyílt forráskódú, tehát Ön is építhet egyet a forrásból. Ez egy sokkal haladóbb módszer, de néhány esetben szükség lehet rá. - -A telepítési utasításokat megtalálja a klienshez kapcsolódó dokumentációban. - -Ezek a kliensek kiadási oldalai, ahol az előre megépített binárisok vagy instrukciók találhatók: - -##### Végrehajtásos kliensek - -- [Besu](https://github.com/hyperledger/besu/releases) -- [Erigon](https://github.com/ledgerwatch/erigon/releases) -- [Geth](https://geth.ethereum.org/downloads/) -- [Nethermind](https://downloads.nethermind.io/) -- [Reth](https://reth.rs/installation/installation.html) - -Fontos tisztában lenni azzal is, hogy a kliensdiverzitás [problémát jelent a végrehajtási rétegen](/developers/docs/nodes-and-clients/client-diversity/#execution-layer). Önnek is azt javasoljuk, hogy futtasson kisebbségi végrehajtási klienst. - -##### Konszenzusos kliensek - -- [Lighthouse](https://github.com/sigp/lighthouse/releases/latest) -- [Lodestar](https://chainsafe.github.io/lodestar/install/source/) (nem ad előre megépített binárist, csak egy Docker-képet vagy fel kell építeni a forrásból) -- [Nimbus](https://github.com/status-im/nimbus-eth2/releases/latest) -- [Prysm](https://github.com/prysmaticlabs/prysm/releases/latest) -- [Teku](https://github.com/ConsenSys/teku/releases) - -A [kliensdiverzitás](/developers/docs/nodes-and-clients/client-diversity/) kritikus a konszenzus-csomópontok esetén, melyek validátort működtetnek. Ha a validátorok többsége egyetlen kliensverziót használ, akkor a hálózat biztonsága veszélybe kerül. Ezért Ön is használjon kisebbségi klienst. - -[Tekintse meg a legfrissebb klienshasználatot](https://clientdiversity.org/), és tudjon meg többet a [kliensdiverzitásról](/developers/docs/nodes-and-clients/client-diversity). - -##### A szoftver ellenőrzése - -A szoftver letöltése után érdemes ellenőrizni annak integritását. Ez opcionális, de ilyen fontos infrastrukturális elemeknél, mint amilyen az Ethereum-kliens, fontos tisztában lenni a támadó vektorokkal és elkerülni azokat. Ha egy előre megépített binárist tölt le, akkor meg kell abban bíznia és kockáztatja, hogy egy támadó kicseréli a végrehajthatót egy ártalmasra. - -A fejlesztők aláírják a kiadott binárisokat a PGP-kulcsokkal, így kriptográfiailag ellenőrizheti, hogy tényleg az a szoftver fut-e, amit ők hoztak létre. Ehhez a fejlesztők által használt publikus kulcsokra van szükség, melyeket a kliens kiadási oldalán vagy a dokumentációban megtalál. Miután letöltötte a kliensprogramot és az aláírást, használjon egy PGP-implementációt, pl. [GnuPG](https://gnupg.org/download/index.html), hogy könnyedén ellenőrizze ezeket. Tekintse meg ezt az útmutatót a nyílt forráskódú szoftver ellenőrzéséről a `gpg` használatával kapcsolatban [linux](https://www.tecmint.com/verify-pgp-signature-downloaded-software/) vagy [Windows/MacOS](https://freedom.press/training/verifying-open-source-software/) operációs rendszeren. - -Egy másik ellenőrzési lehetőség az, hogy a letöltött szoftver hashe, vagyis egyedi kriptográfiai ujjlenyomata egyezik a fejlesztő által adottal. Ez még a PGP-nél is egyszerűbb, és néhány kliensnél csak ez a lehetőség érhető el. Csak futtassa le a hash funkciót a letöltött szoftverre, és hasonlítsa össze azzal, amit a kiadási oldalon talál. Például: - -```sh -sha256sum teku-22.6.1.tar.gz - -9b2f8c1f8d4dab0404ce70ea314ff4b3c77e9d27aff9d1e4c1933a5439767dde -``` - -#### Kliensfelállítás {#client-setup} - -Miután telepítette, letöltötte vagy összeállította a kliensszoftvert, készen áll a használatra. Ennek lényege, hogy a megfelelő konfigurációkkal kell elindítani. A kliensek bőven kínálnak konfigurációs lehetőségeket, melyek különféle jellemzőket tesznek elérhetővé. - -Kezdjük azokkal az opciókkal, melyek jelentősen befolyásolják a kliens teljesítményét és adathasználatát. A [szinkronizációs módok](/developers/docs/nodes-and-clients/#sync-modes) a blokkláncadat letöltésére és validálására ajánlanak különféle módszereket. A csomópont elindítása előtt el kell dönteni, hogy milyen hálózati és szinkronizálási módokat használjon. A legfontosabb a lemezterület és a szinkronizálási idő, amire a kliensnek szüksége lesz. Nézze meg a kliens dokumentációjában, hogy melyik szinkronizálási mód az alapbeállítás. Ha ez nem felel meg Önnek, akkor válasszon egy másikat a biztonsági szint, az elérhető adatok és a költségek alapján. A szinkronizálási algoritmus mellett a korábbi adatok különféle megvágását is be lehet állítani. Ez a megvágás eltávolítja a nem releváns adatokat, pl. azokat a státuszfaszinteket, melyek a közelmúlt blokkjaiból elérhetetlenek. - -Másik alapvető konfigurációs lehetőség például a hálózat kiválasztása (főhálózat vagy teszthálózat), HTTP-végpont az RPC vagy a WebSockets részére stb. A kliens dokumentációja tartalmaz minden jellemzőt és opciót. Különféle klienskonfigurációkat lehet beállítani azáltal, hogy a klienst a megfelelő jelöléssel futtatják közvetlenül a CLI-ben vagy a konfigurációs fájlban. Minden kliens egy kicsit más, ezért mindig a hivatalos dokumentációból vagy a támogatást nyújtó oldalról szerezze be a konfigurációs lehetőségek részleteit. - -Teszteléshez futtathatja a klienst a teszthálózatok egyikén. [Bővebben a támogatott hálózatokról](/developers/docs/nodes-and-clients/#execution-clients). - -A végrehajtási kliensek alapvető konfigurációit a következő részben találja. - -#### A végrehajtási kliens elindítása {#starting-the-execution-client} - -Mielőtt elindítaná az Ethereum-kliensszoftvert, ellenőrizze, hogy a környezet készen áll. Például: - -- Elég lemezterület áll rendelkezésre a kiválasztott hálózati és szinkronizálási mód szerint. -- A memóriát és a CPU-t nem akasztotta meg más program. -- Az operációs rendszer frissítve van a legutóbbi verzióra. -- A rendszerben a helyes idő és dátum szerepel. -- A router és a tűzfal elfogad kapcsolódásokat a hallgató (listening) portokon keresztül. Alapvetően az Ethereum-kliensek hallgató (TCP) és felfedező (UDP) portot használnak, melynek alapbeállítása 30303. - -Futtassa először teszthálózaton a kliensét, hogy biztosan minden jól működik. - -Minden olyan kliensbeállítást tisztázni kell, mely a kezdőpontban nincs alapból beállítva. A választott konfigurációt a jelölőkkel vagy a konfigurációs fájlban tudja rögzíteni. Minden kliensnél különböznek az elérhető jellemzők és a konfigurációs szintaxisok. A specifikációhoz nézze meg a kliens dokumentációját. - -A végrehajtási és konszenzusos kliensek egy hitelesített végponton keresztül kommunikálnak, mely az [Engine API-ban](https://github.com/ethereum/execution-apis/tree/main/src/engine) van specifikálva. A konszenzusos klienshez való kapcsolódáshoz a végrehajtási kliensnek generálnia kell egy [`jwtsecret`](https://jwt.io/) kódot egy ismert útvonalon. Biztonsági és stabilitási okokból a klienseket ugyanazon a gépen kell működtetni, és mindkettőnek ismernie kell ezt az útvonalat, mert ez hitelesíti a helyi RPC-kapcsolódást közöttük. A végrehajtási kliensnek meg kell határoznia egy hallgató (listening) portot a hitelesített API-khoz. - -Ezt a tokent a kliensszoftver automatikusan létrehozza, de ezt néha manuálisan kell megtenni. Az [OpenSSL](https://www.openssl.org/) révén Ön is létre tudja hozni: - -```sh -openssl rand -hex 32 > jwtsecret -``` - -#### A végrehajtási kliens futtatása {#running-an-execution-client} - -Ez a rész a végrehajtási kliensek elindítását mutatja be. Csak példaként szolgál az alapszintű konfigurációkra, ami a következő beállításokkal indítja el a klienst: - -- Meghatározza a hálózatot, amihez kapcsolódik a kliens; példánkban ez a főhálózat - - Ehelyett használhatja [az egyik teszthálózatot](/developers/docs/networks/) is a beállítások kipróbálására -- Meghatározza az adatkönyvtárat, ahol az összes adat, beleértve a blokkláncot is, le lesz tárolva - - Írja át az útvonalat egy valódira, pl. ami a külső meghajtójára mutat -- Lehetővé teszi, hogy az interfészek kommunikáljanak a klienssel - - Beleértve a JSON-RPC-t és az Engine API-t a konszenzusos klienssel való kommunikációhoz -- Meghatározza a `jwtsecret` kódhoz tartozó útvonalat a hitelesített API-hoz - - Cserélje le a példát egy valódi útvonallal, amit elérnek a kliensek, pl. `/tmp/jwtsecret` - -Ne feledje, hogy ez csak alappélda, az összes beállítás a kezdőértéken marad. Tekintse át a kliensek dokumentációit, hogy megismerje a kezdeti értékeket, beállításokat és jellemzőket. A további jellemzőkért, mint a validátorok futtatása, felügyelete stb. tekintse át az adott kliens dokumentációját. - -> Vegye figyelembe, hogy a perjelek `\` a példákban csak formázásra szolgálnak, a konfigurációs jeleket egy sorban is meg lehet határozni. - -##### A Besu futtatása - -Ez a példa a Besut a főhálózaton indítja el, a blokkláncadatokat az alapértelmezett formátumban tárolja a `/data/ethereum` alatt, engedélyezi a JSON RPC-t és Engine RPC-t a konszenzusos klienssel való kapcsolódáshoz. Az Engine API-t a `jwtsecret` token hitelesíti, és csak a `localhostból` jövő hívások vannak megengedve. - -```sh -besu --network=mainnet \ - --data-path=/data/ethereum \ - --rpc-http-enabled=true \ - --engine-rpc-enabled=true \ - --engine-host-allowlist="*" \ - --engine-jwt-enabled=true \ - --engine-jwt-secret=/path/to/jwtsecret -``` - -A Besu egy telepítő opcióval bír, mely egy sor kérdést tesz fel, majd legenerálja a konfigurációs fájlt. Indítsa el az interaktív telepítőt a következővel: - -```sh -besu --Xlauncher -``` - -A [Besu dokumentációja](https://besu.hyperledger.org/en/latest/HowTo/Get-Started/Starting-node/) további opciókat és konfigurációs részleteket tartalmaz. - -##### Az Erigon futtatása - -Ez a példa az Erigont a főhálózaton indítja el, a blokkláncadatot a `/data/ethereum` alatt tárolja, engedélyezi a JSON-RPC-t, meghatározza a namespace-eket, és engedélyezi a hitelesítést a konszenzusos klienssel való kapcsolódáshoz, amit a `jwtsecret` útvonal határoz meg. - -```sh -erigon --chain mainnet \ - --datadir /data/ethereum \ - --http --http.api=engine,eth,web3,net \ - --authrpc.jwtsecret=/path/to/jwtsecret -``` - -Az Erigon alapból teljes szinkronizálást végez 8 GB HDD-vel, ami több mint 2 TB archív adatot eredményez. Biztosítsa, hogy a `datadir` egy olyan lemezre mutat, ahol elég szabad hely van, vagy állítsa be a `--prune` jelölőt, ami megvágja a különféle adatokat. További információért nézze meg az Erigon `--help` oldalát. - -##### A Geth futtatása - -Ez a példa a Gethet a főhálózaton indítja el, a blokkláncadatokat a `/data/ethereum` alatt tárolja, engedélyezi a JSON-RPC-t, és meghatározza a namespace-eket. Engedélyezi a hitelesítést, hogy a konszenzusos klienssel lehessen kapcsolódni, amihez a `jwtsecret` útvonal szükséges, és azt is megadja, hogy milyen kapcsolódások lehetségesek, jelen példánkban csak a `localhosttól` érkezők. - -```sh -geth --mainnet \ - --datadir "/data/ethereum" \ - --http --authrpc.addr localhost \ - --authrpc.vhosts="localhost" \ - --authrpc.port 8551 - --authrpc.jwtsecret=/path/to/jwtsecret -``` - -Tekintse meg a [dokumentációt az összes konfigurálási opcióhoz](https://geth.ethereum.org/docs/fundamentals/command-line-options), és tudjon meg többet a[Geth futtatása konszenzusos klienssel](https://geth.ethereum.org/docs/getting-started/consensus-clients) témáról. - -##### A Nethermind futtatása - -A Nethermind különféle [telepítési opciókat](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/getting-started) kínál. A csomag számos binárist tartalmaz, beleértve egy Telepítőt, ami egy vezetett felállítást tesz lehetővé, így a konfigurációt interaktív módon lehet létrehozni. Másik megoldásként használhatja a Runner-t is, ami a végrehajtási program maga, és konfigurációs jelölőkkel futtathatja. A JSON-RPC alapból engedélyezve van. - -```sh -Nethermind.Runner --config mainnet \ - --datadir /data/ethereum \ - --JsonRpc.JwtSecretFile=/path/to/jwtsecret -``` - -A Nethermind dokumentációk egy [teljeskörű útmutatót](https://docs.nethermind.io/nethermind/first-steps-with-nethermind/running-nethermind-post-merge) adnak arról, hogyan lehet a Nethermind-ot konszenzusos klienssel működtetni. - -A végrehajtási kliens elindítja a fő funkcióit, a kiválasztott végpontokat, és társakat keres. Miután sikeresen felfedezte a társait, elkezd szinkronizálni. A végrehajtási kliens kapcsolódásra vár a konszenzusos klienstől. A jelenlegi blokkláncadatok elérhetők lesznek, amint a kliens sikeresen szinkronizál a jelen státuszhoz. - -##### A Reth futtatása - -Ez a példa a Reth-et a főhálózaton indítja el az alapértelmezett adathelyet figyelembe véve. Engedélyezi a JSON-RPC-t és az Engine RPC hitelesítést a `jwtsecret` elérési útvonal által meghatározott konszenzusklienshez való csatlakozáshoz, és csak a `localhost`-ról érkező hívások engedélyezettek. - -```sh -reth node \ - --authrpc.jwtsecret /path/to/jwtsecret \ - --authrpc.addr 127.0.0.1 \ - --authrpc.port 8551 -``` - -Tekintse meg a [Reth konfigurálást](https://reth.rs/run/config.html?highlight=data%20directory#configuring-reth), hogy többet megtudjon az alapértelmezett adatkönyvtárakról. [A Reth dokumentációja](https://reth.rs/run/mainnet.html) további opciókat és konfigurációs részleteket tartalmaz. - -#### A konszenzusos kliens elindítása {#starting-the-consensus-client} - -A konszenzusos klienst a megfelelő portkonfigurációval kell indítani, hogy egy lokális RPC-kapcsolatot hozzon létre a végrehajtási klienssel. A konszenzusos klienst a felfedett végrehajtási kliens portjával kell futtatni, mint konfigurációs argumentum. - -A konszenzusos kliensnek szüksége van a végrehajtási kliens `jwt-secret` kódjához vezető útvonalra, hogy hitelesíteni tudja az RPC-kapcsolódást közöttük. A fenti példákhoz hasonlóan, minden konszenzusos kliensnek van egy konfigurációs jelölője, ami argumentumként felveszi a jwt token útvonalát. Ennek konzisztensnek kell lennie a `jwtsecret` útvonallal, melyet a végrehajtási kliens kapott. - -Ha Ön validátort tervez majd futtatni, akkor be kell tennie egy konfigurációs jelölőt a validációs díj címzettjének Ethereum-címét megadva. Ezt az ether jutalmat gyűjti a validátor. Minden konszenzusos kliensnek van egy opciója, pl. `--suggested-fee-recipient=0xabcd1`, hogy az Ethereum címet argumentumként vegye fel. - -Amikor egy Beacon-csomópontot indít a teszthálózaton, jelentős szinkronizálási időt takaríthat meg, ha egy publikus végpontot használ a [Checkpoint sync-re](https://notes.ethereum.org/@launchpad/checkpoint-sync). - -#### Konszenzusos kliens futtatása {#running-a-consensus-client} - -##### A Lighthouse futtatása - -Mielőtt a Lighthouse-t futtatná, ismerje meg, hogyan kell telepíteni és konfigurálni azt a [Lighthouse Könyvből](https://lighthouse-book.sigmaprime.io/installation.html). - -```sh -lighthouse beacon_node \ - --network mainnet \ - --datadir /data/ethereum \ - --http \ - --execution-endpoint http://127.0.0.1:8551 \ - --execution-jwt /path/to/jwtsecret -``` - -##### A Lodestar futtatása - -Telepítse a Lodestar szoftvert összeállítva vagy a Docker-kép letöltésével. Tudjon meg többet a [dokumentációból](https://chainsafe.github.io/lodestar/) és a még részletesebb [felállítási útmutatóból](https://hackmd.io/@philknows/rk5cDvKmK). - -```sh -lodestar beacon \ - --rootDir="/data/ethereum" \ - --network=mainnet \ - --eth1.enabled=true \ - --execution.urls="http://127.0.0.1:8551" \ - --jwt-secret="/path/to/jwtsecret" -``` - -##### A Nimbus futtatása - -A Nimbus egyaránt tartalmaz konszenzusos és végrehajtási klienst. Különféle eszközökön lehet futtatni igen szerény számítási kapacitással. Miután [installálta a hozzá tartozó dolgokat és magát a Nimbust](https://nimbus.guide/quick-start.html), futtathatja a konszenzusos kliensét: - -```sh -nimbus_beacon_node \ - --network=mainnet \ - --web3-url=http://127.0.0.1:8551 \ - --rest \ - --jwt-secret="/path/to/jwtsecret" -``` - -##### A Prysm futtatása - -A Prysm egy szkripttel együtt elérhető, amely egyszerű, automatikus telepítést tesz lehetővé. A részleteket a [Prysm dokumentációban](https://docs.prylabs.network/docs/install/install-with-script) találja. - -```sh -./prysm.sh beacon-chain \ - --mainnet \ - --datadir /data/ethereum \ - --execution-endpoint=http://localhost:8551 \ - --jwt-secret=/path/to/jwtsecret -``` - -##### A Teku futtatása - -```sh -teku --network mainnet \ - --data-path "/data/ethereum" \ - --ee-endpoint http://localhost:8551 \ - --ee-jwt-secret-file "/path/to/jwtsecret" -``` - -Amikor egy konszenzusos kliens kapcsolódik egy végrehajtási klienshez, hogy beolvassa a letéti szerződést és azonosítsa a validátorokat, szintén kapcsolódik más Beacon-csomóponttársakhoz, és elkezdi szinkronizálni a konszenzus-slotokat a genezistől kezdve. Amint a Beacon-csomópont eléri a jelenlegi korszakot (epoch), a Beacon API használhatóvá válik a validátor számára. Bővebben a [Beacon-csomópont API-król](https://eth2docs.vercel.app/). - -### Validátorok hozzáadása {#adding-validators} - -A konszenzusos kliens Beacon-csomópontként működik a validátoroknak, hogy azok kapcsolódni tudjanak. Minden konszenzusos kliensnek saját validátorszoftvere van, melyről a releváns dokumentáció részleteiben beszél. - -A saját validátor futtatása lehetővé teszi az [önálló letétbe helyezést](/staking/solo/), a leginkább hatásos és bizalomigény nélküli módszert, mely az Ethereum hálózatát támogatja. Ehhez azonban szükség van 32 ETH letétre. Ha szeretne validátort futtatni a saját csomópontján egy kisebb összeggel, akkor Önt érdekelheti az engedélyhez nem kötött csomópontműködtetőkből álló decentralizált alapok, mint amilyen a [Rocket Pool](https://rocketpool.net/node-operators). - -A letétbe helyezéssel és a validátorkulcs-generálásával a legkönnyebben a [Holesky Testnet Staking Launchpad](https://holesky.launchpad.ethereum.org/) segítségével kezdhet foglalkozni, amellyel tesztelheti a beállítását a [csomópont futtatása a Holesky-n](https://notes.ethereum.org/@launchpad/holesky) útmutatóval. Amikor készen áll a főhálózatra, akkor ugyanezeket a lépéseket kell megismételnie a [Mainnet Staking Launchpad](https://launchpad.ethereum.org/) segítségével. - -Tekintse át a [letétbe helyezési oldalt](/staking), hogy a letéti opciókról tájékozódjon. - -### A csomópont használata {#using-the-node} - -A végrehajtási kliensek [RPC API végpontokat](/developers/docs/apis/json-rpc/) kínálnak, mellyel tranzakciókat lehet beküldeni, valamint okosszerződésekkel interakcióba lépni vagy telepíteni azokat különféle módokon az Ethereum hálózaton: - -- Manuálisan meghívni azokat egy megfelelő protokollal (pl. a `curl` kódot használva) -- Egy megadott konzolt csatolva (pl. `geth attach`) -- Alkalmazásokban implementálva azokat a web3-könyvtárak segítségével, pl. [web3.py](https://web3py.readthedocs.io/en/stable/overview.html#overview), [ethers](https://github.com/ethers-io/ethers.js/) - -A különféle klienseknél eltér az RPC-végpontok telepítése. De van egy standard JSON-RPC, melyet minden klienssel lehet használni. Az áttekintésért [nézze meg a JSON-RPC dokumentációt](/developers/docs/apis/json-rpc/). Az alkalmazások, melyeknek információra van szükségük az Ethereum hálózatáról, ezt az RPC-t használhatják. Például a népszerű MetaMask tárca megengedi, hogy Ön [kapcsolódjon a saját RPC végpontjához](https://metamask.zendesk.com/hc/en-us/articles/360015290012-Using-a-Local-Node), ami erős adatvédelmet és biztonsági előnyöket ad. - -A konszenzusos kliensek mind felfednek egy [Beacon API-t](https://ethereum.github.io/beacon-APIs), amit a kliens státuszának ellenőrzésére vagy a blokkok és konszenzusadatok letöltésére lehet használni, lekérdezéseket küldve olyan eszközökkel, mint amilyen a [Curl](https://curl.se). Bővebben a konszenzusos kliensek dokumentációiban olvashat erről. - -#### RPC elérése {#reaching-rpc} - -Az alapértelmezett port a végrehajtási kliens JSON-RPC számára a `8545`, de a konfigurációban módosítani lehet a lokális végpontok portjait. Alapból az RPC-interfész csak a számítógépének localhost-ján érhető el. A távoli eléréshez fel kell azt fednie nyilvánosan úgy, hogy a címet `0.0.0.0` kódra változtatja. Ettől elérhetővé válik a helyi hálózat és a nyilvános IP-címek számára. A legtöbb esetben porttovábbítást is be kell állítani a routeren. - -Az interneten való port felfedéssel vigyázzon, mert ez bárki számára lehetővé teszi a csomópontjának irányítását. A támadók elérhetik a csomópontot, hogy leállítsák a rendszert vagy ellopják a pénzeszközöket, ha a klienst tárcaként használja. - -Ennek elkerülésére a potenciálisan ártó RPC-módokat megakadályozhatja úgy, hogy azok nem módosíthatók. Például a Geth-tel a módosítható módokat egy jelölővel láthatja el: `--http.api web3,eth,txpool`. - -Az RPC-interfészhez való hozzáférést kiterjesztheti edge layer API-k vagy webszerver-alkalmazások fejlesztésével, mint amilyen a Nginx, és ezeket a kliens lokális címéhez és portjához kapcsolhatja. Egy köztes réteg használata segíthet a fejlesztőknek, hogy hitelesítést állítsanak fel a biztonságos `https` kapcsolódásokhoz az RPC-interfészhez. - -A webszerver, a proxy vagy a kifelé néző Rest API nem az egyedüli módszer arra, hogy a csomópontjának az RPC-végpontjához hozzáférést adjon. Egy nyilvánosan elérhető végpont adatbiztonságot megőrző módja az, hogy a csomópontot a saját [Tor](https://www.torproject.org/) onion szolgáltatásán hosztolja. Így az RPC elérhető a lokális hálózaton kívül, statikus, nyilvános IP-cím vagy egy nyitott port nélkül is. Ugyanakkor ez a beállítás az RPC-végpontot talán csak a Tor hálózaton keresztül teszi elérhetővé, amit nem támogat minden alkalmazást, és ezért kapcsolódási problémákat okozhat. - -Ehhez létre kell hoznia a saját [onion szolgáltatását](https://community.torproject.org/onion-services/). Tekintse meg a [dokumentációt](https://community.torproject.org/onion-services/setup/) az onion szolgáltatás felállításáról ahhoz, hogy a sajátját hosztolja. Ezt egy webszerverhez kapcsolhatja egy proxy-val az RPC-porthoz vagy közvetlenül az RPC-hez. - -Végül az egyik legnépszerűbb mód a belső hálózathoz való hozzáférés-biztosításra a VPN-en keresztüli kapcsolat. Attól függően, hogy Ön mire használja és mennyi felhasználónak akar hozzáférést biztosítani a csomópontjához, a biztonságos VPN-kapcsolat jó opció lehet. Az [OpenVPN](https://openvpn.net/) egy teljes körű SSL VPN, amely OSI layer 2 vagy 3 biztonságos hálózati kiterjesztést implementál az iparági standard SSL/TLS-protokollt használva, támogatja a rugalmas klienshitelesítési módokat bizonyítványok, okoskártyák és/vagy felhasználói név és jelszó alapján, és engedi a felhasználó vagy csoport specifikus hozzáférés-kezelési szabályzatok használatát a tűzfalszabályokat alkalmazva a VPN virtuális interfészére. - -### A csomópont üzemeltetése {#operating-the-node} - -A csomópontot rendszeresen felügyelni kell, hogy az megfelelően működik-e. Emellett esetenként karbantartást kell végezni. - -#### A csomópont online tartása {#keeping-node-online} - -A csomópontnak nem kell mindig online lennie, de érdemes minél többet online tartani, hogy szinkronban legyen a hálózattal. Le lehet állítani azért, hogy újra legyen indítva, de érdemes figyelni arra, hogy: - -- A leállítás eltarthat néhány percig, ha a jelenlegi státusz még íródik a lemezre. -- A kényszerített leállítás következtében sérülhet az adatbázis, ami miatt akár az egész csomópontot újra kell szinkronizálni. -- A kliens nem lesz szinkronban a hálózattal, így az újraindításnál újra kell szinkronizálni. Miközben a csomópont képes onnan szinkronizálni, ahol legutóbb tartott, ez eltarthat egy darabig attól függően, hogy mennyit volt offline. - -_Ez nem vonatkozik a konszenzusréteg validátor-csomópontjaira._ Ekkor a csomópont offline állapota minden olyan szolgáltatást érint, amely ettől függ. Ha _letétbe helyezési_ célból üzemeltet csomópontot, akkor minimalizálni kell a kiesett időt. - -#### Kliensszolgáltatások létrehozása {#creating-client-services} - -Fontolja meg, hogy létrehoz egy szolgáltatást, hogy a klienseket automatikusan futtassa a bekapcsoláskor. Például a Linux szervereken érdemes lehet létrehozni egy szolgáltatást például a `systemd` kóddal, amely elindítja a klienst a megfelelő konfigurációval egy korlátozott privilégiumokkal bíró felhasználó alatt és automatikusan újraindítja azt. - -#### A kliensek frissítése {#updating-clients} - -Tartsa a kliensszoftverét naprakészen a legutóbbi biztonsági javításokkal, funkciókkal és [EIP-ekkel](/eips/). Főleg a [végleges elágazás (hard fork)](/history/) esetén legyen biztos abban, hogy a megfelelő kliensverziót használja. - -> A fontos hálózati frissítések előtt az Ethereum Alapítvány publikál egy cikket a [blogon](https://blog.ethereum.org). Ön is [feliratkozhat ezekre a bejelentésekre](https://blog.ethereum.org/category/protocol#subscribe), hogy e-mailes figyelmeztetést kapjon, amikor a csomópontot frissíteni kell. - -A kliensek frissítése igen egyszerű. Minden kliens dokumentációjában specifikus instrukciókat talál, de az általános eljárás az, hogy le kell tölteni a legújabb verziót és újra kell indítani a klienst az új végrehajtási programmal. A kliens ott folytatja, ahol abbahagyta, de már a frissítésekkel együtt. - -Minden kliensimplementáció rendelkezik egy ember által olvasható verziójelöléssel, melyet a peer-to-peer protokollban használnak, de a parancssorból is elérhető. Ez a verziójelölés megmutatja a felhasználóknak, hogy a megfelelő verziót használják-e, illetve a blokkfelfedezők és más elemzési eszközök számára, hogy megvizsgálják a kliensek megoszlását a hálózaton keresztül. A verziójelöléssel kapcsolatos további információkért tekintse át az adott kliens dokumentációját. - -#### Hozzáadott szolgáltatások futtatása {#running-additional-services} - -A saját csomópont futtatása megengedi olyan szolgáltatások használatát, melyhez hozzáférés szükséges az Ethereum-kliens RPC-hez. Ezek olyan, Ethereumra épített szolgáltatások, mint a [2. blokkláncréteg által nyújtott megoldások](/developers/docs/scaling/#layer-2-scaling), a tárcák biztonsági mentése, blokkfelfedezők, fejlesztői eszközök és más Ethereum infrastruktúrák. - -#### A csomópont felügyelete {#monitoring-the-node} - -A csomópont megfelelő felügyeletéhez érdemes a mérőszámokat gyűjteni. A kliensek képesek mérőszámokat biztosítani a végpontokról, így átfogó képet ad a csomóponttal kapcsolatban. Használjon olyan eszközöket, mint az [InfluxDB](https://www.influxdata.com/get-influxdb/) vagy a [Prometheus](https://prometheus.io/), hogy adatbázist hozzon létre, amelyből vizualizációt és diagrammokat készíthet olyan szoftverekkel, mint a [Grafana](https://grafana.com/). Különféle beállítások és Grafana-irányítópultok léteznek a csomópont és az egész hálózat vizualizációjára. Nézze meg például a [Geth felügyeletéről szóló útmutatót](/developers/tutorials/monitoring-geth-with-influxdb-and-grafana/). - -A felügyelet részeként figyeljen a gép teljesítményére is. A csomópont kezdeti szinkronizálásakor a kliensszoftver nagyobb terhet helyezhet a CPU-ra és RAM-ra. A Grafana mellett olyan eszközt is használhat, amit az operációs rendszere ajánl, mint a `htop` vagy az `uptime`. - -## További olvasnivaló {#further-reading} - -- [Ethereum letétbe helyezési útmutatók](https://github.com/SomerEsat/ethereum-staking-guides) – _Somer Esat, rendszeresen frissítve_ -- [Útmutató | Hogyan állítson fel validátort az Ethereum letétbe helyezéshez a főhálózaton](https://www.coincashew.com/coins/overview-eth/guide-or-how-to-setup-a-validator-on-eth2-mainnet) _– CoinCashew, rendszeresen frissítve_ -- [ETHStaker útmutatók a validátorok futtatásáról a teszthálózatokon](https://github.com/remyroy/ethstaker#guides) – _ETHStaker, rendszeresen frissítve_ -- [Az egyesítéssel (Merge) kapcsolatos gyakran ismételt kérdések a csomópontműködtetők számára](https://notes.ethereum.org/@launchpad/node-faq-merge) – _2022. július_ -- [A hardverkövetelmények elemzése az Ethereum teljes validátor-csomóponthoz kapcsolódóan](https://medium.com/coinmonks/analyzing-the-hardware-requirements-to-be-an-ethereum-full-validated-node-dc064f167902) _– Albert Palau, 2018. szeptember 24._ -- [Teljes csomópontok futtatása az Ethereumon: Útmutató az alig motivált felhasználók számára](https://medium.com/@JustinMLeroux/running-ethereum-full-nodes-a-guide-for-the-barely-motivated-a8a13e7a0d31) _– Justin Leroux, 2019. november 7._ -- [Hyperledger Besu csomópont futtatása az Ethereum főhálózaton: előnyök, követelmények és felállítás](https://pegasys.tech/running-a-hyperledger-besu-node-on-the-ethereum-mainnet-benefits-requirements-and-setup/) _– Felipe Faraggi, 2020. május 7._ -- [Nethermind Ethereum-kliens bevezetése felügyeleti eszközökkel együtt](https://medium.com/nethermind-eth/deploying-nethermind-ethereum-client-with-monitoring-stack-55ce1622edbd) _– Nethermind.eth, 2020. július 8._ - -## Kapcsolódó témák {#related-topics} - -- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) -- [Blokkok](/developers/docs/blocks/) -- [Hálózatok](/developers/docs/networks/) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" deleted file mode 100644 index 2b36bba4bb1..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/index.md" +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Konszenzus mechanizmusok -description: Az elosztott rendszerek konszenzusprotokolljainak és szerepeiknek bemutatása az Ethereumban. -lang: hu ---- - -A konszenzusmechanizmust gyakran használják arra, hogy proof-of-stake (letéti igazolás), proof-of-work (munkaigazolás) vagy proof-of-authority (jogosultságigazolás) protokollokra hivatkoznak. Ugyanakkor ezek csak a konszenzusmechanizmus elemei, amelyek megvédik azt a [Sybil-támadásoktól](/glossary/#sybil-attack). A konszenzusmechanizmus elképzelések, protokollok és ösztönzők teljes halmaza, amely lehetővé teszi, hogy csomópontok elosztott kötege meg tudjon egyezni a blokklánc státuszáról. - -## Előfeltételek {#prerequisites} - -Ennek az oldalnak a könnyebb megértése érdekében javasoljuk, hogy először olvassa el a [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/) oldalunkat. - -## Mi az a konszenzus? {#what-is-consensus} - -A konszenzus azt jelenti, hogy általános megegyezés történik. Tegyük fel, hogy egy csapat ember moziba megy. Ha a választott film kapcsán nincs nézeteltérés, akkor konszenzus van. Ha nézeteltérés van, akkor a csoportnak el kell döntenie, hogy mit nézzen. Szélsőséges esetben a csoport több felé fog válni. - -Az Ethereum blokkláncon ez a folyamat formális, a konszenzus eléréséhez a hálózaton lévő csomópontok 66%-ának egyet kell értenie a hálózat globális státuszát illetően. - -## Mi az a konszenzusmechanizmus? {#what-is-a-consensus-mechanism} - -A konszenzusmechanizmus kifejezés a protokollok, ösztönzők és elképzelések egész halmazára utal, amelyek lehetővé teszik, hogy a csomópontok hálózata megegyezzen a blokklánc státuszáról. - -Az Ethereum egy proof-of-stake-alapú konszenzusmechanizmust használ, amelynek kriptogazdasági biztonsága abból ered, hogy a letétesek által zárolt tőkéhez jutalmak és büntetések kapcsolódnak. Ez az ösztönző struktúra arra ösztönzi az egyes letéteseket, hogy becsületes validátorokat működtessenek, bünteti azokat, akik nem így tesznek, és rendkívül magas költséget teremt a hálózat megtámadásához. - -Ezután van egy protokoll, amely szabályozza, hogyan választják ki a becsületes validátorokat, hogy blokkokat javasoljanak vagy validáljanak, tranzakciókat dolgozzanak fel és szavazzanak a lánc fejéről. Azokban a ritka helyzetekben, amikor több blokk is ugyanabban a pozícióban van a lánc élén, van egy elágazásválasztó-mechanizmus, amely kiválasztja a „legnehezebb” láncot alkotó blokkokat, a blokkokra szavazó validátorok száma alapján, a letétbe helyezett ether-egyenlegükkel súlyozva. - -A konszenzus szempontjából fontosak a kódon kívüli koncepciók is, mint a megszokotton kívüli társadalmi koordináció biztonsága, mely a hálózat elleni támadások elleni védelmi vonal. - -Ezek az elemeket együttesen adják ki a konszenzusmechanizmust. - -## A konszenzusmechanizmusok fajtái {#types-of-consensus-mechanisms} - -### Proof-of-work alapú {#proof-of-work} - -Ahogy a Bitcoin, korábban Ethereum is a **proof-of-work (PoW)** alapú konszenzusprotokollt használta. - -#### Blokk létrehozás {#pow-block-creation} - -A bányászok versenyeznek, hogy új blokkokat hozzanak létre, amelyek tele vannak feldolgozott tranzakciókkal. A győztes megosztja az új blokkot a hálózat többi részével és valamennyi újonnan kibocsátott ETH-t kap jutalmul. A versenyt az a számítógép nyeri, amelyik a leggyorsabban meg tud oldani egy matematikai feladványt. Ez hozza létre a kriptográfiai kapcsolatot az aktuális és az azt megelőző blokk között. Ennek a feladványnak a megoldása jelenti a munkát a „proof-of-workben”. A kanonikus láncot ezután egy elágazásválasztási szabály határozza meg, amely kiválasztja azon blokkok halmazát, amelyek bányászatával a legtöbb munkát végezték. - -#### Biztonság {#pow-security} - -A hálózatot az tartja biztonságban, hogy a számítási kapacitás több mint 51%-ára van szükség a lánc meghamisításához. Ez olyan nagy befektetést igényelne a felszerelésben és energiában, hogy a támadó valószínűleg többet költene, mint amennyit nyerne vele. - -Bővebben a [proof-of-workről (PoW)](/developers/docs/consensus-mechanisms/pow/) - -### Proof-of-stake-alapú {#proof-of-stake} - -Az Ethereum jelenleg **proof-of-stake (PoS)** alapú konszenzusprotokollt használ. - -#### Blokk létrehozás {#pos-block-creation} - -A validátorok blokkokat hoznak létre. Minden slotban véletlenszerűen kiválasztanak egy blokkelőterjesztőt. A kiválasztott konszenzusos kliense egy adat tranzakciót kér végrehajtási csomagként a végrehajtási klienstől. Ezt konszenzusadatokba csomagolják, hogy egy blokkot alkossanak, melyet az Ethereum hálózat többi csomópontjának továbbítanak. Ezért a blokk-készítésért ETH-t kapnak. Ritka esetekben, amikor egy slothoz több blokk is létezik, vagy a csomópontok különböző időpontokban értesülnek a blokkokról, az elágazásválasztó algoritmus azt a blokkot választja ki, amely a legnagyobb súlyú tanúsítással alkotja a láncot (ahol a tanúsítást végző validátorok számát azok ETH-egyenlegével súlyozzák). - -#### Biztonság {#pos-security} - -A proof-of-stake rendszer kriptogazdasági szempontból biztonságos, mivel egy támadónak, aki megpróbálja átvenni az irányítást a lánc felett, hatalmas mennyiségű ETH-t kell feláldoznia. A jutalmak rendszere arra ösztönzi az egyes letétbe helyezőket, hogy tisztességesen viselkedjenek, a büntetések pedig visszatartják őket attól, hogy rosszhiszeműen cselekedjenek. - -Bővebben a [proof-of-stake-ről](/developers/docs/consensus-mechanisms/pos/) - -### Vizuális áttekintés {#types-of-consensus-video} - -Tekintse meg az Ethereumon használt különféle konszenzusmechanizmusokat: - - - -### Ellenállás a Sybil-támadásnak és láncválasztás {#sybil-chain} - -A proof-of-work és proof-of-stake önmagukban nem konszenzusprotokollok, de az egyszerűség kedvéért gyakran így hivatkoznak rájuk. Ezek Sybil-ellenálló mechanizmusok és a blokkok létrehozójának kiválasztói; ezek segítségével lehet eldönteni, hogy ki a legutóbbi blokk kreálója. Egy másik fontos összetevő a láncválasztó (elágazásválasztó) algoritmus, amely lehetővé teszi a csomópontok számára, hogy egyetlen helyes blokkot válasszanak a lánc élére olyan esetekben, amikor több blokk van ugyanabban a pozícióban. - -A **Sybil-rezisztencia** azt méri, hogy egy protokoll hogyan viselkedik egy Sybil-támadással szemben. Az ilyen típusú támadásokkal szembeni ellenállás lényeges egy decentralizált blokkláncnál, és lehetővé teszi, hogy a bányászok és a validáltorok a befektetett erőforrások alapján egyenlő mértékben részesüljenek jutalomban. A proof-of-work és proof-of-stake mechanizmusok úgy védekeznek, hogy a felhasználóknak sok energiát kell ráfordítaniuk vagy sok biztosítékot kell nyújtaniuk. Ezek a védelmek gazdaságilag elrettentő erejűek a Sybil-támadásokkal szemben. - -A **láncválasztási szabály** dönti el, hogy melyik lánc a „helyes”. A Bitcoin a „leghosszabb lánc” szabályt alkalmazza, ami azt jelenti, hogy amelyik blokklánc a leghosszabb, azt a többi csomópont is elfogadja érvényesnek, és azzal dolgozik. A proof-of-work láncok esetében a leghosszabb láncot a lánc összesített proof-of-work nehézsége határozza meg. Korábban az Ethereum is a leghosszabb lánc szabályát használta; most a proof-of-stake mechanizmussal működik, egy frissített elágazásválasztó algoritmust fogadott el, amely a lánc „súlyát” méri. A súly a validátorok szavazatainak összege, súlyozva a validátorok letétbe helyezett ether-egyenlegével. - -Az Ethereum a [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) nevű konszenzusmechanizmust használja, amely a [Casper FFG proof-of-stake](https://arxiv.org/abs/1710.09437) módszert a [GHOST elágazásválasztási szabállyal](https://arxiv.org/abs/2003.03052) kombinálja. - -## További olvasnivaló {#further-reading} - -- [Mi az a blokklánc-konszenzusalgoritmus?](https://academy.binance.com/en/articles/what-is-a-blockchain-consensus-algorithm) -- [Mit jelent a Nakamoto-konszenzus? Útmutató kezdőknek](https://blockonomi.com/nakamoto-consensus/) -- [Hogyan működik a Casper?](https://medium.com/unitychain/intro-to-casper-ffg-9ed944d98b2d) -- [A proof-of-work blokkláncok biztonságáról és teljesítményéről](https://eprint.iacr.org/2016/555.pdf) -- [Bizánci hiba](https://en.wikipedia.org/wiki/Byzantine_fault) - -_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/) -- [Bányászat](/developers/docs/consensus-mechanisms/pow/mining/) -- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/) -- [Proof-of-authority (jogosultsági igazolás)](/developers/docs/consensus-mechanisms/poa/) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" deleted file mode 100644 index fe0fed8b75a..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md" +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Az Ethereum proof-of-stake rendszerére vonatkozó támadás és védekezés -description: Ismerje meg a proof-of-stake Ethereum elleni ismert támadási vektorokat és azok elleni védelmet. -lang: hu ---- - -A tolvajok és szabotőrök folyamatosan keresik a lehetőséget, hogy megtámadják az Ethereum kliensszoftverét. Ez az oldal ismerteti az Ethereum konszenzusrétegét érő ismert támadási vektorokat, és felvázolja, hogyan lehet ezeket a támadásokat kivédeni. - -## Előfeltételek {#prerequisites} - -## {#what-is-pos} - -Gyakori tévhit, hogy egy sikeres támadó képes új ethert generálni, vagy tetszőleges számlákról ethert lehívni. Egyik sem lehetséges, mivel minden tranzakciót a hálózat összes végrehajtási kliense hajtja végre. A tranzakcióknak meg kell felelniük az érvényesség alapvető feltételeinek (például a tranzakciókat a feladó privát kulcsa írja alá, a feladónak elegendő egyenleggel kell rendelkeznie stb. Az eredménynek három osztálya van, amelyet egy támadó reálisan megcélozhat: átszervezés, dupla véglegesség vagy a véglegesség késleltetése. - -## {#validators} - -Az **átszervezés** a blokkok új sorrendbe rendezése, esetleg a kanonikus láncban lévő blokkok hozzáadásával vagy kivonásával. Egy rosszindulatú átszervezés biztosíthatja, hogy bizonyos blokkok bekerüljenek vagy kikerüljenek, lehetővé téve a dupla költést vagy az értékkivonást előre és hátra futó tranzakciókkal (MEV). Az átszervezés arra is felhasználható, hogy bizonyos tranzakciókat ne lehessen felvenni a kanonikus láncba, ami a cenzúra egy formája. Az átszervezés legszélsőségesebb formája a „véglegesítés visszaállítása”, amely eltávolítja vagy helyettesíti a korábban véglegesített blokkokat. Ez csak akkor lehetséges, ha a támadó a teljes feltett ether több mint ⅓-át megsemmisíti – ez a garancia az úgynevezett „gazdasági véglegesség” (erről később még lesz szó). - -**Kettős véglegesség** az a valószínűtlen, de súlyos állapot, amikor két elágazás képes egyszerre véglegesedni, ami tartós szakadást okoz a láncban. Ez elméletileg lehetséges egy olyan támadó számára, aki hajlandó a teljes feltett ether 34%-át kockáztatni. A közösség kénytelen lenne a láncon kívül koordinálni és megegyezni arról, hogy melyik láncot kövesse, amihez a társadalmi réteg erejére lenne szükség. - -## {#transaction-execution-ethereum-pos} - -1. -2. -3. -4. -5. -6. - -A szociális réteg elleni támadás célja lehet az Ethereumba vetett közbizalom aláásása, az ether leértékelése, az elfogadás csökkentése vagy az Ethereum-közösség gyengítése, hogy megnehezítse a sávon kívüli koordinációt. - -## {#finality} - -Először is, azok a személyek, akik nem vesznek részt aktívan az Ethereumban (a kliensszoftver futtatásával), a társadalmi réteget (0. réteg) célozva támadhatnak. A 0. réteg az alap, amelyre az Ethereum épül, és mint ilyen, potenciális támadási felületet jelent, amelynek következményei a stack többi részére is kihatnak. Néhány példa: - -## {#crypto-economic-security} - -Ezeket a támadásokat az teszi különösen veszélyessé, hogy sok esetben nagyon kevés tőkére vagy technikai tudásra van szükség. Egy 0. rétegbeli támadás egy kriptogazdasági támadás multiplikátora lehet. Ha például a cenzúrát vagy a véglegesség visszaállítását egy rosszindulatú többségi érdekelt fél érné el, a szociális réteg aláásása megnehezíthetné a sávon kívüli közösségi válaszlépések koordinálását. - -A 0. rétegbeli támadások elleni védekezés valószínűleg nem egyszerű, de néhány alapelvet fel lehet állítani. Az egyik az Ethereummal kapcsolatos nyilvános információk magas jel-zaj arányának fenntartása, amelyeket a közösség becsületes tagjai hoznak létre és terjesztenek blogokon, Discord szervereken, kommentált specifikációkon, könyveken, podcastokon és Youtube-on keresztül. Itt az ethereum.org-on is igyekszünk pontos információkat fenntartani és a lehető legtöbb nyelvre lefordítani. A tér minőségi információkkal és mémekkel való elárasztása hatékony védekezés a félretájékoztatás ellen. - -## {#fork-choice} - -Egy másik fontos megerősítés a társadalmi réteg támadásaival szemben az egyértelmű küldetésnyilatkozat és az irányítási protokoll. Az Ethereum a decentralizáció és a biztonság bajnokaként pozicionálta magát az L1-es okosszerződések között, miközben nagyra értékeli a skálázhatóságot és a fenntarthatóságot is. Bármilyen nézeteltérések merülnek fel az Ethereum közösségben, ezek az alapelvek minimálisan sérülnek. A narratíva értékelése ezen alapelvek alapján és a felülvizsgálat egymást követő fordulóin keresztül az EIP (Ethereum Fejlesztési Javaslatok) folyamatában segíthet a közösségnek megkülönböztetni a jó és a rossz szereplőket, illetve korlátozhatja a rosszindulatú szereplők lehetőségét az Ethereum jövőbeli irányának befolyásolására. - -## {#pos-and-security} - -Végezetül fontos, hogy az Ethereum-közösség nyitott és befogadó maradjon minden résztvevő számára. A zártkörű közösségek különösen sebezhetők a társadalmi támadásokkal szemben, mivel könnyű „mi és ők” narratívákat építeni. A törzsiség és a mérgező maximalizmus árt a közösségnek és aláássa a 0. réteg biztonságát. A hálózat biztonságában érdekelt Ethereum-tagoknak úgy kell tekinteni az online és személyes találkozásokra, mint ami közvetlenül hozzájárul az Ethereum 0. rétegének biztonságához. - -- -- -- -- Hozzáértő, de rosszindulatú szereplők beszivárgása a fejlesztői közösségbe, akiknek célja a fejlődés lelassítása a megbeszélések megzavarásával, a fontos döntések késleltetésével, szemeteléssel (spam) stb. - -## {#pros-and-cons} - -| | | -| | | -| | | -| | | -| | | -| | | - -### {#comparison-to-proof-of-work} - -Több cikk is ismertette az Ethereum elleni olyan támadásokat, amelyek a teljes feltett ether csak kis hányadával érnek el reorgokat vagy végleges késleltetést. Ezek a támadások általában arra épülnek, hogy a támadó visszatart valamilyen információt a többi validátor elől, majd valamilyen árnyalt módon és/vagy egy alkalmas pillanatban kiadja azt. - -- -- -- -- -- -- - -## {#further-reading} - -- -- -- -- -- -- []() -- -- []() - -## {#related-topics} - -- []() -- []() diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" deleted file mode 100644 index 6007bf787fe..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/attestations/index.md" +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Tanúsítások -description: A tanúsítások menete az Ethereum proof-of-stake (letéti igazolás) mechanizmusában. -lang: hu ---- - -A validátornak minden korszakban tanúsítást kell készítenie, aláírnia és szétküldenie. Ez a leírás bemutatja, hogyan néznek ki ezek a tanúsítások, hogyan kezelik azokat és kommunikálják a konszenzusos kliensek között. - -## Mi az a tanúsítás? {#what-is-an-attestation} - -Minden [korszakban](/glossary/#epoch) (6,4 perc) a validátor tanúsítást készít a hálózatnak. A tanúsítás a korszak egy megadott slotjára történik. A tanúsítás célja az, hogy szavazzon amellett, ahogyan ő maga látja a láncot, különösképpen a legutóbbi ellenőrzött blokk és a jelen korszak első blokkja tekintetében (melyeket `source` (eredet) és `target` (cél) ellenőrzési pontoknak neveznek). Az információkat összekombinálják az összes résztvevő validátorra, így a hálózat konszenzust tud elérni a blokklánc státuszát illetően. - -A tanúsítás a következő elemekből áll: - -- `aggregation_bits`: a validátorok bitlistája, ahol a pozíció a validátornak a bizottságbeli indexéhez kapcsolódik; az érték (0/1) azt mutatja, hogy a validátor aláírta a `data` mezőt (tehát aktív és egyetért a blokkelőterjesztővel) -- `data`: a tanúsításhoz kapcsolódó részletek, ahogy az alább látszik -- `signature`: egy BLS-aláírás, ami aggregálja az egyéni validátorok aláírásait - -A tanúsítást végző validátor első feladata az, hogy felépítse a `data` mezőit. A `data` a következő információkat tartalmazza: - -- `slot`: A slot száma, melyre a tanúsítás vonatkozik -- `index`: Egy szám, ami beazonosítja, hogy a validátor melyik bizottsághoz tartozik egy adott slotban -- `beacon_block_root`: A blokk gyökérhashe, amit a validátor lát a lánc fejeként (az elágazásválasztási algoritmus alkalmazásának eredménye) -- `source`: A véglegesedési szavazás része, amely azt mutatja, hogy a validátorok melyik blokkot látják a legutoljára igazoltnak -- `target`: A véglegesedési szavazás része, mely azt mutatja, hogy a validátorok melyik blokkot látják a jelen korszak első blokkjának - -Amint a `data` felépül, a validátor átválthatja a bitet az `aggregation_bits` mezőben 0-ról 1-re, amely a saját validátor indexéhez kapcsolódik, így mutatja, hogy részt vett. - -Végül a valdátor aláírja a tanúsítást és elküldi azt a hálózaton. - -### Aggregált tanúsítás {#aggregated-attestation} - -Az adat elterjesztése a hálózaton minden validátor esetében jelentős költséggel jár. Ezért az egyéni validátorok tanúsításait aggregálják az alhálózatokon belül, mielőtt szélesebb körben szétküldenék azt. Ennek része az aláírások aggregálása, így a kiküldött tanúsítás tartalmazza a konszenzus `data` mezőit és egyetlen aláírást, melyet azon validátorok aláírásából készítenek, akik egyetértettek a `data` tartalmával. Ezt le lehet ellenőrizni az `aggregation_bits` mezővel, mert ez adja meg a bizottságban lévő validátorok indexeit (akiknek az ID-ja a `data` mezőben látható), amellyel le lehet kérdezni az egyéni aláírásokat. - -Minden korszakban minden alhálóban 16 validátort kiválasztanak, hogy `aggregátor` legyen. Az aggregátorok összegyűjtik az összes tanúsítást, amelyről hallanak a pletykahálózaton, és amelyeknek ugyanolyan `data` áll rendelkezésre, mint nekik. Minden egyező tanúsítás küldője feljegyzésre kerül az `aggregation_bits` mezőben. Ezután az aggregátorok szétküldik az aggregált tanúsítást a szélesebb hálózaton. - -Amikor egy validátort választanak blokkelőterjesztőnek, akkor az új blokkba beteszi az aggregált tanúsításokat az alhálózatoktól egészen az utolsó slotig. - -### A tanúsítások belefoglalásának életciklusa {#attestation-inclusion-lifecycle} - -1. Létrehozás -2. Előterjesztés -3. Aggregálás -4. Előterjesztés -5. Belefoglalás - -A tanúsítás életciklusát a következő ábra is bemutatja: - -![a tanúsítás életciklusa](./attestation_schematic.png) - -## Jutalmak {#rewards} - -A validátorok jutalmat kapnak az elküldött tanúsításokért. A tanúsítás jutalma függ a részvételi jelzésektől (forrás, cél és fej), az alapjutalomtól és a részvételi aránytól. - -A részvételi jelzések értéke igaz vagy hamis lehet, a benyújtott tanúsítás és a kapcsolódó késedelem függvényében. - -A legjobb esetben mindhárom jelző igaz, ekkor a validátor a következő jutalmat kapná (helyes jelzőnként): - -`jutalom += alapjutalom * jelzés súlya * jelzés tanúsítási aránya / 64` - -A jelzés tanúsítási arányát az adott jelzésre vonatkozóan az összes tanúsítást végező validátor tényleges egyenlegének összegével mérik az összes aktív tényleges egyenleghez viszonyítva. - -### Alapjutalom {#base-reward} - -Az alapjutalom számítása a tanúsításban részt vevő validátorok számától és az általuk letétbe helyezett ether egyenlegétől függ: - -`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)` - -#### Belefoglalási késés {#inclusion-delay} - -Amikor a validátorok szavaztak a lánc fejére (`block n`), akkor a `block n+1` még nem volt előterjesztve. Ezért a tanúsítások természetes módon **egy blokkal később** kerülnek be, így minden tanúsítás, amelyik azt mondta, hogy a `block n` a lánc feje, az bekerül a `block n+1`-be, és a **belefoglalási késés** értéke 1. Ha a belefoglalási késés két slotnyi lesz, akkor a tanúsítási jutalom feleződik, mert a tanúsítási jutalom kiszámításához az alapjutalom szorozva van a belefoglalási késés reciprokával. - -### Tanúsítási esetek {#attestation-scenarios} - -#### Hiányzó validátor, aki szavaz {#missing-voting-validator} - -A validátoroknak legfeljebb 1 korszak áll rendelkezésre, hogy elküldjék a tanúsításukat. Ha a tanúsítás lekési a 0. korszakot, akkor belefoglalási késéssel be tudják még küldeni az 1. korszakban. - -#### Hiányzó aggregátor {#missing-aggregator} - -Összesen 16 aggregátor van minden korszakban. Emellett véletlenszerű validátorok be vannak jegyezve **két alhálózatra 256 korszakra**, és ők helyettesítik az aggregátorokat, ha bárki hiányzik. - -#### Hiányzó blokkelőterjesztő {#missing-block-proposer} - -Néhány esetben a szerencsés aggregátor blokkelőterjesztővé válhat. Ha a tanúsítás nem került be, mert a blokkelőterjesztő hiányzik, akkor a következő előterjesztő felkapja az aggregált tanúsítást és beteszi a következő blokkba. Ugyanakkor az **belefoglalási késés** növekszik eggyel. - -## További olvasnivaló {#further-reading} - -- [Tanúsítások Vitalik által kommentált konszenzusspecifikációban](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) -- [Tanúsítások az eth2book.info oldalon](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) - -_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" deleted file mode 100644 index 7ded209d33e..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/block-proposal/index.md" +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Blokkjavaslat -description: Magyarázat a blokkok előterjesztéséről a proof-of-stake Ethereumban. -lang: hu ---- - -A blokkok a blokklánc alapvető egységei. A blokkok az információ különálló egységei, melyeket a csomópontok terjesztenek egymás között, megegyeznek róluk és hozzáadják őket a saját adatbázisukhoz. Ez az oldal azt magyarázza el, hogyan jönnek létre a blokkok. - -## Előfeltételek {#prerequisites} - -A blokkelőterjesztés része a proof-of-stake (letéti igazolás) protokollnak. Ahhoz, hogy könnyebben átlássa a folyamatot, tekintse meg a [proof-of-stake-ről](/developers/docs/consensus-mechanisms/pos/) és a [blokk architektúráról](/developers/docs/blocks/) szóló anyagokat. - -## Ki hozza létre a blokkot? {#who-produces-blocks} - -A validátorszámlák javasolják a blokkokat. A validátorszámlákat azok a csomópontműködtetők kezelik, akik validátorszoftvert futtatnak a végrehajtási és konszenzusklienseik részeként, és letétbe helyeztek 32 ETH-t a letéti szerződésbe. Ugyanakkor egy adott validátor csak esetenként felel azért, hogy blokkot javasoljon. Az Ethereum az időt slotokra és korszakokra (epoch) osztja fel. Minden slot 12 másodperc, és 32 slot (6,4 perc) tesz ki egy korszakot. Minden slotban lehetőség van arra, hogy az Ethereumon egy új blokkot hozzanak létre. - -### Véletlenszerű kiválasztás {#random-selection} - -A kijelölt validátort ál-véletlenszerűen választják, hogy javasoljon blokkot egy adott slotban. A blokkláncban nincs olyan, hogy valódi véletlenszerűség, mert ha minden csomópont valóban véletlen számokat generálna, akkor sose lenne konszenzus. Ehelyett az a lényeg, hogy a validátorkiválasztás megjósolhatatlan legyen. A véletlenszerűséget az Ethereumon egy RANDAO néven ismert algoritmussal érik el, ami összekeveri a blokkelőterjesztőtől jövő hasht egy seeddel, ami minden blokkban frissítve van. Ezt az értéket használják, hogy kiválasszanak egy adott validátort a teljes szettből. A validátorkiválasztás két korszakra előre adott, hogy ezzel védekezzenek a seedmanipuláció ellen. - -Habár a validátorokat hozzáadják a RANDAO-hoz minden slotban, de a globális RANDAO értéke csak egyszer frissül minden korszakban. Ahhoz, hogy a következő blokkelőterjesztő indexét kiszámolja, a RANDAO értéket összekeveri a slotszámmal, hogy minden slotnak egyedi értéke legyen. A valószínűség, hogy egy adott validátor kiválasztásra kerül, nem egyszerűen `1/N` (ahol `N` = teljes aktív validátorok). Ehelyett ezt súlyozzák minden validátor aktuális ETH egyenlegével. A maximum egyenleg (balance) az 32 ETH (tehát `balance < 32 ETH` kevesebb súlyt jelent, mint `balance == 32 ETH`, de a `balance > 32 ETH` nem jelent nagyobb súlyt, mint `balance == 32 ETH`). - -Minden slotban egy blokkelőterjesztőt választanak. Normális esetben a dedikált slotban egy blokkelőterjesztő létrehoz és elküld egyetlen blokkot. Két blokk ugyanarra a slotra való létrehozásáért súlyos és kizárással járó büntetés jár, gyakran emlegetik kétértelműségként is. - -## Hogyan jön létre a blokk? {#how-is-a-block-created} - -A blokkelőterjesztőnek egy aláírt beacon blokkot kell szétküldeni, amely a lánc aktuális fejére épül, ahogy azt a lokálisan futtatott elágazásválasztási algoritmusuk mutatja. Az elágazásválasztás algoritmusa először érvényesíti az előző slotból származó tanúsításokat, majd megkeresi azt a blokkot, melynek összességében a legtöbb tanúsítása van. Ez a blokk lesz a szülője annak az új blokknak, amelyet a javaslattevő készít. - -A blokkelőterjesztő összegyűjti az adatokat a saját lokális adatbázisából és a láncról, és ezekből állít össze blokkot. A blokk tartalma alábbiakban látható: - -```rust -class BeaconBlockBody(Container): - randao_reveal: BLSSignature - eth1_data: Eth1Data - graffiti: Bytes32 - proposer_slashings: List[ProposerSlashing, MAX_PROPOSER_SLASHINGS] - attester_slashings: List[AttesterSlashing, MAX_ATTESTER_SLASHINGS] - attestations: List[Attestation, MAX_ATTESTATIONS] - deposits: List[Deposit, MAX_DEPOSITS] - voluntary_exits: List[SignedVoluntaryExit, MAX_VOLUNTARY_EXITS] - sync_aggregate: SyncAggregate - execution_payload: ExecutionPayload -``` - -A `randao_reveal` mező egy igazolható, véletlenszerű értéket vesz fel, melyet a blokkelőterjesztő hoz létre azzal, hogy aláírja a jelenlegi korszak számát. Az `eth1_data` egy szavazat arra, ahogy a blokkelőterjesztő a letéti szerződést látja, beleértve a letéti Merkle-fa gyökerét és a letétek teljes számát, mely lehetővé teszi az új letétek ellenőrzését. A `graffiti` egy opcionális mező, mellyel üzenetet lehet adni a blokkhoz. A `proposer_slashings` és az `attester_slashings` olyan mezők, melyek bizonyítják, hogy adott validátorok súlyos büntetést érdemelnek aszerint, ahogy az előterjesztő látja a láncot. A `deposits` az új validátorletétek listája, melyről az előterjesztő tudomással bír, a `voluntary_exits` pedig azok a validátorok, akikről a konszenzusréteg pletykahálózatán hallott, hogy ki akarnak lépni. A `sync_aggregate` egy olyan vektor, mely megmutatja, melyik validátorok voltak korábban a szinkronizálási bizottság tagjai (a validátorok alcsoportja, melyek a könnyű klienseknek biztosítanak adatot) és vettek részt az adatok aláírásában. - -Az `execution_payload` információt ad a végrehajtási és a konszenzuskliensek közötti átadott tranzakciókról. Az `execution_payload` a végrehajtandó adatok egy csomagja, melyet beágyaznak egy beacon blokkba. Az `execution_payload` mezői a blokkstruktúrát mutatják, ahogy azt az Ethereum Sárgakönyv felvázolja, kivéve, hogy nincsenek ommerek és `prev_randao` van a `difficulty` helyett. A végrehajtási kliens a tranzakciók egy helyi gyűjtőjéhez fér hozzá, melyről a saját pletykahálózatán hallott. Ezeket a tranzakciókat helyben végrehajtja, hogy egy friss státuszfát kapjon (post-state). A tranzakciók bekerülnek az `execution_payload` mezőbe egy listaként, mint `transactions`, az új státuszfa (post-state) pedig a `state-root` mezőbe kerül. - -Ezeket az adatokat egy beacon blokkba gyűjtik, melyet aláírnak és szétküldenek az előterjesztő társainak, akik továbbküldik a saját társaiknak, és így tovább. - -Bővebben a [a blokkok anatómiájáról](/developers/docs/blocks). - -## Mi történik a blokkal? {#what-happens-to-blocks} - -A blokk bekerül az előterjesztő helyi adatbázisába, és elküldi azt a társaknak a konszenzusréteg pletykahálózatán keresztül. Amikor egy validátor megkap egy blokkot, ellenőrzi a benne lévő adatokat, úgy mint hogy megfelelő szülővel rendelkezik-e, a megfelelő slotra vonatkozik-e, az előterjesztő indexe megfelel-e, a RANDAO nyilatkozat érvényes-e és az előterjesztőt nem büntették-e meg. Az `execution_payload` kicsomagolásra kerül, és a validátor végrehajtási kliense újra lefuttatja a tranzakciókat, hogy ellenőrizze a javasolt státuszváltozást. Ha a blokk átmegy minden ellenőrzésen, akkor az összes validátor hozzáadja a blokkot a saját kanonikus láncához. Majd a folyamat kezdődik elölről a következő slotban. - -## Blokkjutalmak {#block-rewards} - -A blokkelőterjesztő fizetséget kap a munkájáért. Van egy `base_reward` (alapdíj), melyet az aktív validátorok számából és az ő aktuális egyenlegeikből kalkulálnak ki. A blokkelőterjesztő ezután megkapja a `base_reward` egy töredékét minden érvényes tanúsításért, mely a blokkba került; minél több validátor tanúsítja a blokkot, annál nagyobb ez a jutalom. Azért is jutalom jár, ha valaki bejelent egy validátort, akit meg kell büntetni. Ez `1/512 * aktuális egyenleg` minden súlyosan megbüntetett validátor után. - -[Bővebben a jutalmakról és büntetésekről](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) - -## További olvasnivaló {#further-reading} - -- [Bevezetés a blokkokba](/developers/docs/blocks/) -- [Bevezetés a proof-of-stake mechanizmusba](/developers/docs/consensus-mechanisms/pos/) -- [Az Ethereum konszenzusspecifikációi](https://github.com/ethereum/consensus-specs) -- [Bevezetés a Gasperbe](/developers/docs/consensus-mechanisms/pos/) -- [Az Ethereum frissítése](https://eth2book.info/) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" deleted file mode 100644 index 2338c0a3ab5..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/faqs/index.md" +++ /dev/null @@ -1,172 +0,0 @@ ---- -title: Gyakran ismételt kérdések -description: Gyakran ismételt kérdések az Ethereum proof-of-stake (letéti igazolás) mechanizmusáról. -lang: hu ---- - -## Mi az a proof-of-stake? {#what-is-proof-of-stake} - -A proof-of-stake (letéti igazolás) egy algoritmusfajta, ami biztonságot tud adni a blokkláncoknak azáltal, hogy a támadók elveszítik az értékeiket, amint rosszhiszeműen viselkednek. A proof-of-stake rendszereknél szükség van egy validátorszettre, amely eszközöket biztosít, és ezeket lehet megsemmisíteni, ha bizonyítottan rosszindulatúan cselekszenek. Az Ethereum proof-of-stake mechanizmust használ arra, hogy biztosítsa a blokkláncot. - -## Hogyan viszonyul a proof-of-stake a proof-of-work mechanizmushoz? {#comparison-to-proof-of-work} - -A proof-of-work (munkaigazolás) és a proof-of-stake (letéti igazolás) egyaránt olyan mechanizmus, mely elrettenti a rosszhiszemű szereplőket attól, hogy teleszemeteljék vagy becsapják a hálózatot. Mindkettőnél azok a csomópontok, melyek aktívan részt vesznek a konszenzusban, valamennyi eszközt „tesznek be a hálózatba”, melyet elveszítenek, ha nem viselkednek megfelelően. - -A proof-of-work esetében ez az eszköz az energia. A bányászként ismert csomópont egy olyan algoritmust futtat, melynek célja, hogy egy értéket gyorsabban számoljon ki, mint az összes többi csomópont. A leggyorsabb csomópont javasolhat blokkot a láncra. Ahhoz, hogy a lánc történetét megváltoztassa vagy dominálja a blokkelőterjesztést, a bányásznak olyan hatalmas számítási kapacitással kell bírnia, hogy mindig megnyerje a versenyt. Ez olyan szinten drága és nehezen kivitelezhető, hogy ez megvédi a láncot a támadásoktól. A proof-of-work alapú bányászathoz szükséges energia egy valódi eszköz, amiért a bányászok fizetnek. - -A proof-of-stake-hez validátor szerepű csomópontokra van szükség, amelyek egyértelműen kriptoeszközt adnak át egy okosszerződésnek. Ha egy validátor nem megfelelően viselkedik, ezt a kriptót megsemmisíthetik, mivel ezt közvetlen módon letétbe helyezték a láncon, nem pedig közvetett módon, az energiakiadáson keresztül. - -A proof-of-work sokkal energiaigényesebb, mert a bányászati folyamatban elektromosságot égetnek el. A proof-of-stake ezzel szemben csak nagyon kevés energiát igényel – az Ethereum-validátorokat igen alacsony kapacitású eszközön is futtathatják, mint amilyen a Raspberry Pi. Az Ethereum proof-of-stake mechanizmusát sokkal biztonságosabbnak vélik, mint a proof-of-work metódust, mert a támadás költsége sokkal nagyobb, a támadót pedig sokkal súlyosabb következmények sújtják. - -A proof-of-work és proof-of-stake összehasonlítása állandó téma. [Vitalik Buterin blogja](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-are-the-benefits-of-proof-of-stake-as-opposed-to-proof-of-work), valamint a Justin Drake és Lyn Alden közötti vita jól összefoglalja az érveket. - - - -## Energiatakarékos a proof-of-stake? {#is-pos-energy-efficient} - -Igen. A proof-of-stake hálózat csomópontjai kis mennyiségű energiát használnak. Egy harmadik fél által készített tanulmány szerint az Ethereum teljes proof-of-stake hálózatának fogyasztása kb. 0,0026 TWh/év, ami nagyjából 13 000-szer kevesebb, mint a játék csak az Egyesült Államokban. - -[Bővebben az Ethereum energiafelhasználásáról](/energy-consumption/). - -## Biztonságos a proof-of-stake? {#is-pos-secure} - -Az Ethereum proof-of-stake mechanizmusa nagyon biztonságos. A mechanizmust nyolc éven át kutatták, fejlesztették és alaposan tesztelték, mielőtt életbe lépett volna. A biztonsági garanciák eltérnek a proof-of-work alapú blokkláncoktól. A proof-of-stake esetén a rosszindulatú validátorokat aktívan meg lehet büntetni (slash) és ki lehet dobni a validátorok közül, ami nekik jelentős összegű ETH-be kerül. A proof-of-work esetében a támadó megismételheti a támadását, amíg elegendő hashkapacitással nem rendelkezik. Az Ethereum proof-of-stake-nél egy ugyanolyan jellegű támadás költségesebb, mint proof-of-work esetén. A lánc elérhetőségének befolyásolásához a hálózaton lévő összes letétbe helyezett ether legalább 33%-ára van szükség (kivéve a nagyon kifinomult, rendkívül valószínűtlen sikerű támadások esetén). A jövőbeli blokkok tartalmának ellenőrzéséhez a teljes letétbe helyezett ETH legalább 51%-a szükséges, az előzményadatok átírásához pedig a teljes letét több mint 66%-a kell. Az Ethereum protokollja a 33%-os vagy 51%-os támadásoknál megsemmisítené ezeket az eszközöket, a 66%-os támadásnál pedig társadalmi konszenzussal oldaná meg. - -- [Bővebben az Ethereum proof-of-stake támadás elleni védelméről](/developers/docs/consensus-mechanisms/pos/attack-and-defense) -- [Bővebben a proof-of-stake kialakításáról](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) - -## Olcsóbbá teszi az Ethereumot a proof-of-stake? {#does-pos-make-ethereum-cheaper} - -Nem. A tranzakció elküldésének költségét (gázdíj) egy dinamikus díjpiac határozza meg, amely a hálózati kereslet növekedésével nő. A konszenzusmechanizmus ezt közvetlenül nem befolyásolja. - -[Bővebben a gázról](/developers/docs/gas). - -## Mik azok a csomópontok, kliensek és validátorok? {#what-are-nodes-clients-and-validators} - -A csomópontok az Ethereum-hálózathoz csatlakozó számítógépek. A kliensek az általuk futtatott szoftverek, amelyek a számítógépet csomóponttá alakítják. A klienseknek két típusa van: a végrehajtási és a konszenzuskliensek. Mindkettőre szükség van egy csomópont létrehozásához. A validátor a konszenzusos kliens opcionális kiegészítője, amely lehetővé teszi a csomópont számára, hogy részt vegyen a proof-of-stake konszenzusban. Ez azt jelenti, hogy blokkokat hoz létre és javasol, amikor kiválasztják, és igazolja azokat a blokkokat, amelyekről a hálózaton hall. Validátor futtatásához a csomópont üzemeltetőjének 32 ETH-t kell befizetnie a letéti szerződésbe. - -- [Bővebben a csomópontokról és kliensekről](/developers/docs/nodes-and-clients) -- [Többet a letétbe helyezésről](/staking) - -## A proof-of-stake egy új ötlet? {#is-pos-new} - -Nem. A BitcoinTalk egyik felhasználója 2011-ben [javasolta a proof-of-stake alapötletét](https://bitcointalk.org/index.php?topic=27787.0) a Bitcoin továbbfejlesztéseként. Tizenegy év telt el, mire készen állt a megvalósításra az Ethereum főhálózaton. Néhány más lánc már korábban megvalósította a proof-of-stake-et, de nem az Ethereum sajátos mechanizmusát (ami Gasper néven ismert). - -## Mi a különleges az Ethereum proof-of-stake mechanizmusában? {#why-is-ethereum-pos-special} - -Az Ethereum proof-of-stake mechanizmusa teljesen egyedi. Nem ez volt az első proof-of-stake mechanizmus, amelyet megterveztek és megvalósítottak, de ez a legstabilabb. A proof-of-stake mechanizmusát Casper-nek nevezik. A Casper határozza meg, hogyan választják ki a validátorokat a blokkelőterjesztésre, hogyan és mikor tanúsítanak, hogyan számolják a tanúsításokat, milyen jutalmakat és büntetéseket kapnak a validátorok, a súlyos büntetések feltételeit, a hibabiztos mechanizmusokat, mint például az inaktivitás elszivárgás, és a „véglegesség” feltételeit. A véglegesség egy feltétel, hogy egy blokk a kanonikus lánc állandó része legyen, a hálózaton lévő összes letétbe helyezett ETH legalább 66%-ának szavazatával kell bírnia. A kutatók a Caspert kifejezetten az Ethereum számára fejlesztették ki, így ez az első és egyetlen blokklánc, amely megvalósította. - -A Casper mellett az Ethereum proof-of-stake-je egy LMD-GHOST nevű elágazásválasztó-algoritmust használ. Erre abban az esetben van szükség, ha két blokk létezik ugyanarra a slotra. Ezáltal a blokklánc két elágazást hoz létre. Az LMD-GHOST azt választja ki, amelyiknél a tanúsítások „súlya” a legnagyobb. A súly a tanúsítások száma súlyozva a validátorok tényleges egyenlegével. Az LMD-GHOST egyedülálló az Ethereumban. - -A Casper és az LMD_GHOST kombinációja Gasper néven ismert. - -[Bővebben a Gasperről](/developers/docs/consensus-mechanisms/pos/gasper/) - -## Mi az a súlyos büntetés (slashing)? {#what-is-slashing} - -Súlyos büntetésnek nevezzük a validátor letétjének megsemmisítését és a validátornak a hálózatból való kizárását. A súlyos büntetés során elveszített ETH mennyisége a megbüntetett validátorok számával arányos – ez azt jelenti, hogy az összejátszó validátorok súlyosabb büntetést kapnak, mint az egyének. - -[Bővebben a súlyos büntetésről (slashing)](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) - -## Miért kell a validátoroknak 32 ETH? {#why-32-eth} - -A validátoroknak ETH-t kell letétbe helyezniük, hogy legyen mit veszíteniük, ha rosszhiszeműen viselkednek. Azért is kell 32 ETH-t feltölteniük, hogy a csomópontok egyszerűbb hardveren is működhessenek. Ha az egy validátorra jutó minimális ETH alacsonyabb lenne, akkor a validátorok száma, és így az egyes slotokban feldolgozandó üzenetek száma is növekedne, ezért nagyobb teljesítményű hardverre lenne szükség egy csomóponthoz. - -## Hogyan választják ki a validátorokat? {#how-are-validators-selected} - -Egy adott validátor álvéletlenszerűen kerül kiválasztásra a RANDAO nevű algoritmus segítségével, hogy egy adott slotban blokkot javasoljon; ez a blokkelőterjesztőtől származó hasht keveri egy seeddel, amely minden blokkban frissül. Ezt az értéket használják, hogy kiválasszanak egy adott validátort a teljes szettből. A validátor kiválasztását két korszakra előre elvégzik. - -[Bővebben a validátorkiválasztásról](/developers/docs/consensus-mechanisms/pos/block-proposal) - -## Mi az a letéti grinding? {#what-is-stake-grinding} - -A letéti grinding egy proof-of-stake hálózat elleni támadás, ahol a támadó megpróbálja a validátor kiválasztási algoritmust a saját validátorai javára torzítani. A RANDAO letéti grinding támadásához a teljes lekötött ETH-mennyiség felére van szükség. - -[Bővebben a letéti grindingről](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) - -## Mi az a közösségi slashing? {#what-is-social-slashing} - -A közösségi slashing a közösség azon lehetősége, hogy egy támadás esetén eldöntse a blokklánc elágazását. Ez lehetővé teszi a közösség számára, hogy helyreálljon egy helytelen láncot véglegesítő támadás esetén. A közösségi slashing a cenzúrázó támadások ellen is használható. - -- [Bővebben a közösségi slashingről](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) -- [Vitalik Buterin a közösségi slashingről](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) - -## Engem is érhet súlyos büntetés (slashing)? {#will-i-get-slashed} - -Validátorként nehéz súlyos büntetést szerezni, hacsak nem valaki szándékosan rosszindulatúan viselkedik. A súlyos büntetést speciális esetekben alkalmazzák, amikor a validátorok több blokkot javasolnak ugyanabban a slotban, vagy ellentmondanak önmaguknak a tanúsításaikkal – ezek nem valószínű, hogy véletlenül előfordulnak. - -[Bővebben a súlyos büntetés feltételeiről](https://eth2book.info/altair/part2/incentives/slashing) - -## Mit jelent a nincs kockázat probléma? {#what-is-nothing-at-stake-problem} - -A nincs kockázat probléma egy koncepcionális hiányosság néhány proof-of-stake mechanizmus esetén, ahol csak jutalmak vannak, és nincsenek büntetések. Ha nincs kockázat, tehát nem lehet a letétet elveszíteni, akkor a gyakorlatias validátor ugyanúgy tanúsítja bármelyik vagy akár több elágazását is a blokkláncnak, mert ebből több jutalmat kap. Az Ethereum ezt úgy kezeli, hogy véglegességi feltételeket szab és létezik súlyos büntetés, így biztosítható a kanonikus lánc. - -[Bővebben a nincs kockázat problémáról](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) - -## Mi az az elágazásválasztó algoritmus? {#what-is-a-fork-choice-algorithm} - -Az elágazásválasztó algoritmus olyan szabályokat alkalmaz, amelyek meghatározzák, hogy melyik lánc a kanonikus. Optimális körülmények között nincs szükség elágazásválasztási szabályra, mivel slotonként csak egy blokkelőterjesztő van, és csak egy blokk jön létre. Alkalmanként lehetséges, hogy több blokk keletkezik ugyanarra a slotra vagy későn érkező információ miatt több lehetőség van a lánc fejéhez közeli blokkok szerveződésére. Ezekben az esetekben minden kliensnek azonos módon kell végrehajtania néhány szabályt, hogy biztosítsa, hogy a blokkok helyes sorrendjét válasszák. Az elágazásválasztó algoritmus kódolja ezeket a szabályokat. - -Az Ethereum elágazásválasztási algoritmusának neve LMD-GHOST. Azt az elágazást választja, amelynek a legnagyobb a tanúsítási súlya, vagyis amelyikre a legtöbb letétbe helyezett ETH szavazott. - -[Bővebben az LMD-GHOST-ról](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) - -## Mit jelent a véglegesség a proof-of-stake-ben? {#what-is-finality} - -A véglegesség a proof-of-stake-ben az a garancia, hogy egy adott blokk stabil része a kanonikus láncnak, és nem lehet azt visszafordítani, kivéve, ha a konszenzus meghiúsul, és a támadó a teljes letétbe helyezett ether 33%-át elégeti. Ez egy kriptogazdasági véglegesség, szemben a „valószínűségi véglegességgel”, amely a proof-of-work blokkláncokra releváns. A valószínűségi véglegességben nincsenek explicit véglegesített/nem véglegesített státuszok a blokkok számára – egyszerűen egyre kevésbé valószínű, hogy egy blokkot el lehet távolítani a láncból, ahogy telik az idő, és a felhasználók maguk határozzák meg, hogy mikor eléggé biztosak abban, hogy egy blokk helyzete „biztonságos”. A kriptogazdasági véglegesítésnél az ellenőrzőpont blokkpárjait a letétbe helyezett ether 66%-ának kell megszavaznia. Ha ez a feltétel teljesül, akkor az ellenőrzőpontok közötti blokkok egyértelműen véglegesek. - -[Bővebben a véglegességről](/developers/docs/consensus-mechanisms/pos/#finality) - -## Mi az a „gyenge szubjektivitás”? {#what-is-weak-subjectivity} - -A gyenge szubjektivitás a proof-of-stake hálózatok egyik jellemzője, ahol a társadalmi információkat használják a blokklánc aktuális státuszának megerősítésére. Az új csomópontok vagy a hálózathoz egy hosszabb offline állapot után csatlakozó csomópontok kaphatnak egy friss állapotot, így azonnal láthatják, hogy a megfelelő láncon vannak-e. Ezeket a státuszokat a gyenge szubjektivitás ellenőrzési pontjainak nevezik, és más csomópontok üzemeltetőitől kaphatók, blokkfelfedezőktől vagy több nyilvános végponttól. - -[Bővebben a gyenge szubjektivitásról](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) - -## Ellenáll a proof-of-stake a cenzúrának? {#is-pos-censorship-resistant} - -A cenzúrának való ellenállását jelenleg nehéz bizonyítani. A proof-of-worktől eltérően azonban a proof-of-stake lehetőséget ad a cenzúrázó validátorok megbüntetésére. A protokollban hamarosan szétválasztják a blokképítőket a blokkelőterjesztőktől, és bevezetik azon tranzakciók listáját, amelyeket a blokképítőknek bele kell foglalniuk a blokkba. Ez a javaslattevő-építő szétválasztás, mely segít megakadályozni, hogy a validátorok cenzúrázzák a tranzakciókat. - -[Bővebben a javaslattevő-építő szétválasztásról (PBS)](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) - -## Az Ethereum proof-of-stake rendszerét érheti 51%-os támadás? {#pos-51-attack} - -Igen. A proof-of-stake rendszer ugyanúgy ki van téve az 51%-os támadásnak, mint a proof-of-work. Ahelyett, hogy a támadónak a hálózat hash teljesítményének 51%-ára lenne szüksége, az összes letétbe helyezett ETH 51%-a kell. Az a támadó, aki a teljes letét 51%-át összegyűjti, átveszi az irányítást az elágazásválasztó-algoritmus felett. Ez lehetővé teszi a támadó számára, hogy bizonyos tranzakciókat cenzúrázzon, rövidtávú átszervezéseket végezzen, és a blokkok önérdekű átrendezésével profitot (MEV) szerezzen. - -[Bővebben a proof-of-stake-re irányuló támadásokról](/developers/docs/consensus-mechanisms/pos/attack-and-defense) - -## Mi a közösségi koordináció, és miért van rá szükség? {#what-is-social-coordination} - -A közösségi koordináció az Ethereum utolsó védelmi vonala, amely lehetővé teszi, hogy egy helyes láncot helyreállítsanak egy olyan támadásból, amely helytelen blokkokat véglegesített. Ebben az esetben az Ethereum közösségének „sávon kívül” kellene koordinálnia és megállapodnia egy helyes kisebbségi elágazás használatában, és ezzel a támadó validátorait kizárni (slashing). Ehhez az alkalmazásokra és a tőzsdékre is szükség lenne, hogy felismerjék a helyes elágazást. - -[Bővebben a közösségi koordinációról](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) - -## A proof-of-stake-ben a gazdagok gazdagabbak lesznek? {#do-rich-get-richer} - -Minél több ETH-t tesz letétbe valaki, annál több validátort tud futtatni, és annál több jutalmat tud felhalmozni. A jutalmak lineárisan skálázódnak a letétbe helyezett ETH összegével, és mindenki ugyanannyi százalékos hozamot kap. A proof-of-work jobban gazdagítja a gazdagokat, mint a proof-of-stake, mivel a gazdagabb bányászok, akik hardvereket vásárolnak, a méretgazdaságosság előnyeit élvezik, tehát a vagyon és a jutalom közötti kapcsolat nem lineáris. - -## A proof-of-stake centralizáltabb, mint a proof-of-work? {#is-pos-decentralized} - -Nem, a proof-of-work a centralizáció felé hajlik, mivel a bányászati költségek növekednek és kiszorítják a magánszemélyeket, majd a kisebb vállalatokat, és így tovább. A proof-of-stake jelenlegi problémája a likvid letéti derivatívák (LSD) hatása. Ezek olyan tokenek, amelyek valamilyen letétbe helyezett ETH-t képviselnek, és amelyeket bárki elcserélhet a másodlagos piacokon anélkül, hogy a tényleges ETH letétet felbontanák. Az LSD-k lehetővé teszik a felhasználók számára, hogy 32 ETH-nél kevesebb letétet tegyenek, de egyúttal centralizációs kockázatot is teremtenek, ahol néhány nagy szervezet végül a letét nagy részét ellenőrizheti. Ezért az [önálló letétbe helyezés](/staking/solo) a legjobb megoldás az Ethereum számára. - -[Bővebben a letétcentralizációról az LSD-kben](https://notes.ethereum.org/@djrtwo/risks-of-lsd) - -## Miért csak ETH-t lehet letétbe helyezni? {#why-can-i-only-stake-eth} - -Az ETH az Ethereum natív valutája. Elengedhetetlen, hogy minden letét egyetlen valutában legyen, mert így lehet a súlyozott szavazatokhoz szükséges aktuális egyenlegeket venni és ez kell a biztonsághoz is. Az ETH az Ethereum alapvető összetevője, nem egy okosszerződés. Más valuták beépítése jelentősen megnövelné a bonyolultságot és csökkentené a letétek biztonságát. - -## Az Ethereum az egyetlen proof-of-stake blokklánc? {#is-ethereum-the-only-pos-blockchain} - -Nem, több proof-of-stake blokklánc létezik. Egyik sem azonos az Ethereummal, mert annak proof-of-stake mechanizmusa egyedülálló. - -## Mi az a Beolvadás? {#what-is-the-merge} - -A Beolvadás volt az a pillanat, amikor az Ethereum kikapcsolta a proof-of-work alapú konszenzusmechanizmusát, és bekapcsolta a proof-of-stake alapút. A Beolvadás 2022. szeptember 15-én történt. - -[A beolvadásról bővebben](/roadmap/merge) - -## Mi az elérhetőség és a biztonság? {#what-are-liveness-and-safety} - -Az elérhetőség és a biztonság a blokklánc két alapvető biztonsági szempontja. Az elérhetőség azt jelenti, hogy a lánc véglegesedni tud. Ha a lánc véglegesedése leáll, vagy a felhasználók nem tudnak könnyen hozzáférni, akkor nem elérhető a lánc. A hozzáférés rendkívül magas költségei is elérhetőségi hibák. A biztonság arra utal, hogy mennyire nehéz a láncot megtámadni, vagyis egymásnak ellentmondó ellenőrzőpontokat véglegesíteni. - -[Bővebb információkat talál a Casper dokumentációban](https://arxiv.org/pdf/1710.09437.pdf) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" deleted file mode 100644 index d2dc7a2fbfd..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/gasper/index.md" +++ /dev/null @@ -1,52 +0,0 @@ ---- -title: Gasper -description: A Gasper proof-of-stake mechanizmusának magyarázata. -lang: hu ---- - -A Gasper a Casper, a baráti véglegességi eszköz (Casper-FFG), és az LMD-GHOST elágazásválasztó-algoritmus kombinációja. Ezek az összetevők együttesen alkotják az Ethereum proof-of-stake-et biztosító konszenzusmechanizmust. A Casper az a mechanizmus, amely bizonyos blokkokat „véglegesre” frissít, hogy a hálózatba újonnan belépők biztosak lehessenek abban, hogy a kanonikus láncot szinkronizálják. Az elágazásválasztó algoritmus felhalmozott szavazatokat használ, hogy a csomópontok könnyen kiválaszthassák a helyeset, amikor elágazások keletkeznek a blokkláncban. - -**Érdemes megjegyezni**, hogy a Casper-FFG eredeti definíciója kissé megváltozott a Gasperbe való beépítéshez. Ezen az oldalon a frissített változatot tekintjük át. - -## Előfeltételek - -A jelen téma könnyebb megértéséhez tekintse meg a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) alapjairól szóló bevezető oldalt. - -## A Gasper szerepe {#role-of-gasper} - -A Gasper egy proof-of-stake blokklánc tetején helyezkedik el, ahol a csomópontok biztonsági letétként ethert biztosítanak, amely megsemmisíthető, ha lusták vagy rosszhiszeműek a blokkok javaslata vagy validálása során. A Gasper az a mechanizmus, amely meghatározza, hogyan jutalmazzák és büntetik a validátorokat, hogyan döntenek arról, hogy mely blokkokat fogadják el és melyeket utasítják el, és hogy a blokklánc melyik elágazására építsenek. - -## Mi az a véglegesség? {#what-is-finality} - -A véglegesség bizonyos blokkok tulajdonsága, ami azt jelenti, hogy nem lehet visszafordítani azokat, kivéve, ha kritikus konszenzushiba történt, és a támadó a teljes letétbe helyezett ether legalább 1/3-át megsemmisítette. A véglegesített blokkok olyan információkat jelentenek, amelyekkel kapcsolatban a blokklánc biztos. Egy blokknak kétlépcsős frissítési eljáráson kell átesnie ahhoz, hogy véglegesítésre kerüljön: - -1. Az összes feltett ether kétharmadának kell megszavaznia, hogy az adott blokk bekerüljön a kanonikus láncba. Ez a feltétel a blokkot „érvényesített” kategóriába emeli. Az érvényesített blokkokat nem valószínű, hogy visszafordítják, de bizonyos feltételek mellett megtörténhet. -2. Ha egy másik blokkot érvényesítenek egy érvényesített blokk tetején, akkor az „véglegesített” állapotba kerül. Egy blokk véglegesítése az adott blokknak a kanonikus láncba való felvétele iránti elköteleződés. Nem lehet visszaállítani, kivéve, ha egy támadó több millió ethert (több milliárd $USD) semmisít meg. - -Ezek a blokkfrissítések nem minden slotban történnek meg. Ehelyett csak a korszakhatárhoz tartozó blokkok érvényesíthetők és véglegesíthetők. Ezeket a blokkokat ellenőrzőpontoknak nevezzük. A frissítés az ellenőrzőpontpárokat veszi figyelembe. Két egymást követő ellenőrzőpont között „szupertöbbségi kapcsolatnak” kell fennállnia (az összes letétbe helyezett ether kétharmada szavaz arra, hogy a B ellenőrzőpont az A ellenőrzőpont helyes leszármazottja) ahhoz, hogy a korábbi ellenőrzőpontot véglegesítettre, a frissebbet pedig érvényesítettre lehessen állítani. - -Mivel a véglegesítéshez kétharmados egyetértés kell a blokk kanonikus voltát illetően, egy támadó nem tud a következők nélkül alternatív véglegesített láncot létrehozni: - -1. A teljes letétbe helyezett ether kétharmadának birtoklása vagy manipulálása nélkül. -2. A letétbe helyezett ether legalább egyharmadának elpusztítása nélkül. - -Az első feltétel azért merül fel, mert egy lánc véglegesítéséhez a letétbe helyezett ether kétharmadára van szükség. A második feltétel azért van, mert ha a teljes letét kétharmada mindkét elágazás mellett szavazott, akkor egyharmadának mindkettőre szavaznia kellett. A kettős szavazás súlyos büntetést és kizárást von maga után, amelyet maximálisan büntetnének, és a teljes letét egyharmada megsemmisülne. 2022 májusától ezért egy támadónak körülbelül 10 milliárd dollár értékű ethert kellene elégetnie. A Gasperben a blokkokat érvényesítő és véglegesítő algoritmus a [Casper-FFG](https://arxiv.org/pdf/1710.09437.pdf) kissé módosított formája. - -### Ösztönzők és súlyos büntetés (slashing) {#incentives-and-slashing} - -A validátorok jutalmat kapnak a blokkok jóhiszemű előterjesztéséért és validálásáért. Ethert kapnak jutalomként, mely hozzáadódik a letétjükhöz. Másrészt, azok a validátorok, akik nem cselekszenek, amikor felszólítják őket, lemaradnak ezekről a jutalmakról, és bizonyos esetekben elveszítik meglévő letétjük egy kis részét. A távolmaradásért járó büntetések csekélyek, és a legtöbb esetben csak a jutalmak elmaradását jelentik. Ugyanakkor vannak olyan validátori műveletek, amelyeket nehéz lenne véletlenül megtenni, ezért valamilyen rosszindulatú szándékot jeleznek, például több blokkot javasolni vagy tanúsítani ugyanarra a slotra, vagy ellentmondani a korábbi ellenőrzési pontra vonatkozó szavazásnak. Ezek a viselkedésmódok súlyos büntetést vonnak maguk után komoly következményekkel: a slashing eredményeként a validátor letétjének egy része megsemmisül, a validátort pedig eltávolítják a hálózatból. Ez a folyamat 36 napig tart. Az 1. napon legfeljebb 1 ETH összegű kezdeti büntetés jár. Ezután a súlyos büntetést kapott validátor ether egyenlege lassan fogy a kilépési időszak alatt, de a 18. napon „korrelációs büntetést” kap, amely nagyobb, ha több validátor egy időben kerül kizárásra. A maximális büntetés a teljes letét. Ezek a jutalmak és büntetések arra szolgálnak, hogy ösztönözzék a becsületes validátorokat, és visszatartsák a hálózat elleni támadásokat. - -### Inaktivitási elszivárgás {#inactivity-leak} - -A biztonság mellett a Gasper „elfogadható elérhetőséget” is biztosít. Ez az a feltétel, hogy amíg az összes letétbe helyezett ether kétharmada becsületesen és a protokollt követve szavaz, a lánc képes lesz a véglegesítésre, függetlenül bármilyen más tevékenységtől (például támadások, késleltetés vagy súlyos büntetések). Másképp fogalmazva, a teljes letétbe helyezett ether egyharmadának veszélyeztetettnek kell lennie ahhoz, hogy a lánc ne tudjon véglegesedni. A Gasperben van egy további védelmi vonal az elérhetőség sérülése ellen, amelyet „inaktivitási elszivárgásként” ismerünk. Ez a mechanizmus akkor aktiválódik, amikor a blokklánc véglegesítése több mint négy korszakon keresztül meghiúsul. Azoknak a validátoroknak, akik nem tanúsítják aktívan a többségi láncot, a letétjük fokozatosan elszivárog, amíg a többség vissza nem nyeri a teljes letét kétharmadát, így az elérhetőség sérülése csak átmeneti. - -### Elágazásválasztás {#fork-choice} - -A Casper-FFG eredeti definíciója tartalmazott egy elágazásválasztó algoritmust a következő szabállyal: `kövesse azt a láncot, amely a legnagyobb magasságú érvényesített ellenőrzőpontot tartalmazza`, ahol a magasságot a genezisblokktól való távolságként határozzuk meg. A Gasperben az eredeti elágazásválasztási szabályt lecserélték egy kifinomultabb, LMD-GHOST nevű algoritmusra. Fontos megérteni, hogy normális körülmények között az elágazásválasztási szabály szükségtelen, mert minden slothoz egyetlen blokkajánló tartozik, és ezt a jóhiszemű validátorok tanúsítják. Csak nagy hálózati aszinkronitás esetén, vagy ha egy rosszhiszemű blokkajánló kétértelműen nyilatkozott, van szükség elágazásválasztó algoritmusra. Ha azonban ezek az esetek mégis bekövetkeznek, ez az algoritmus kritikus védelmet jelent, ás biztosítja a helyes láncot. - -Az LMD-GHOST a következő kifejezés rövidítése: latest message-driven greedy heaviest observed sub-tree (a legutolsó üzenet által vezérelt, mohó, legsúlyosabb részfa). Ez egy nehézkes meghatározása annak, hogy a tanúsítások legnagyobb összesített súlyával rendelkező elágazást választja ki kanonikusnak (mohó legsúlyosabb részfa), és ha több üzenet érkezik egy validátortól, csak a legutolsót veszi figyelembe (legutolsó üzenet által vezérelt). Mielőtt a legnehezebb blokkot hozzáadná a kanonikus láncához, minden validátor minden blokkot e szabály alapján értékel. - -## További olvasnivaló {#further-reading} - -- [Gasper: A GHOST és a Casper kombinációja](https://arxiv.org/pdf/2003.03052.pdf) -- [Casper, a baráti véglegességi eszköz (Friendly Finality Gadget)](https://arxiv.org/pdf/1710.09437.pdf) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" deleted file mode 100644 index dda68f89056..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/index.md" +++ /dev/null @@ -1,99 +0,0 @@ ---- -title: Proof-of-stake (PoS) -description: A proof-of-stake konszenzusprotokoll és az Ethereumban betöltött szerepének bemutatása. -lang: hu ---- - -Az Ethereum [konszenzusmechanizmusa](/developers/docs/consensus-mechanisms/) a proof-of-stake (PoS) koncepción alapul. Az Ethereum 2022-ben váltott a proof-of-stake mechanizmusra, mivel biztonságosabb, kevésbé energiaintenzív és jobban megfelel az új méretezési megoldások bevezetéséhez, mint a korábbi [proof-of-work](/developers/docs/consensus-mechanisms/pow) architektúra. - -## Előfeltételek {#prerequisites} - -Az oldal könnyebben megértéséhez javasoljuk, hogy tekintse meg a [konszenzusmechanizmusok](/developers/docs/consensus-mechanisms/) cikket. - -## Mi az a proof-of-stake (PoS)? {#what-is-pos} - -A proof-of-stake (letéti igazolás) egy módszer annak bizonyítására, hogy a validátorok valamilyen értéket helyeztek a hálózatba, amely tisztességtelen cselekedet esetén megsemmisíthető. Az Ethereum proof-of-stake mechanizmusánál a validátorok ETH formájában zárolják tőkéjüket az Ethereumon található okosszerződésben. A validátor feladata annak ellenőrzése, hogy a hálózaton keresztül terjesztett új blokkok érvényesek, és adott esetben ő maga is új blokkokat hoz létre és terjeszt elő. Ha megpróbálják meghamisítani a hálózatot (például egy helyett több blokkot javasolnak, vagy egymásnak ellentmondó tanúsításokat küldenek), a letétbe helyezett ETH egy része vagy egésze megsemmisülhet. - -## Validátorok {#validators} - -A validátorként való részvételhez a felhasználónak 32 ETH-t kell egy letéti szerződésben zárolnia, és három különböző szoftvert kell futtatnia: egy végrehajtási klienst, egy konszenzusos klienst és egy validátorklienst. Az ETH letétbe helyezésével a felhasználó beáll egy aktiválási sorba, amely korlátozza az új validátorok hálózathoz való csatlakozásának ütemét. Az aktiválást követően a validátorok új blokkokat kapnak a társaiktól az Ethereum-hálózaton. A blokkban szállított tranzakciókat újra végrehajtják, hogy ellenőrizzék, hogy az Ethereum státuszában javasolt változások érvényesek-e, és ellenőrzik a blokk aláírását. A validátor ezután szavazatot (ún. tanúsítást) ad le az adott blokkra a hálózaton keresztül. - -Amíg a proof-of-work esetében a blokkidőt a bányászati nehézség határozza meg, addig a proof-of-stake esetén a tempó rögzített. A proof-of-stake Ethereum esetén az idő (12 másodperces) slotokra és korszakokra (egy korszak 32 slotból áll) oszlik. A rendszer minden slotban véletlenszerűen kiválaszt egy validátort a blokk előterjesztésére. Ez a validátor felel az új blokk létrehozásáért és elküldéséért a hálózat többi csomópontja felé. Emellett a rendszer minden slotban véletlenszerűen megválaszt egy a validátorbizottságot, amelynek a szavazatai döntenek az előterjesztett blokk érvényességéről. A validátorok bizottságokra való felosztása fontos a hálózati terhelés kezelhetősége szempontjából. A bizottságok úgy osztják fel a validátorhalmazt, hogy minden aktív validátor minden korszakban tanúsít, de nem minden slotban. - -## Hogyan kerülnek végrehajtásra a tranzakciók az Ethereum proof-of-stake mechanizmusban {#transaction-execution-ethereum-pos} - -Az alábbiakban egy teljes magyarázatot adunk arról, hogyan hajtanak végre egy tranzakciót az Ethereum proof-of-stake-ben. - -1. A felhasználó létrehoz és aláír egy [tranzakciót](/developers/docs/transactions/) a privát kulcsával. Ezt általában egy tárca vagy egy könyvtár, például [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) stb. kezeli, eközben a háttérben a felhasználó az Ethereum [JSON-RPC API](/developers/docs/apis/json-rpc/) segítségével kérést intéz egy csomóponthoz. A felhasználó meghatározza, hogy mennyi gázt fizet borravalóként a validátornak, hogy az felkapja az adott tranzakciót és betegye egy blokkba. A [borravalót](/developers/docs/gas/#priority-fee) megkapja a validátor, az [alapdíjat](/developers/docs/gas/#base-fee) pedig elégeti a rendszer. -2. A tranzakciót beküldik az Ethereum [végrehajtási klienshez](/developers/docs/nodes-and-clients/#execution-client), hogy ellenőrizze az érvényességét. Ennek része, hogy a küldőnek van elég ETH összege, hogy végre legyen hajtva a tranzakció és a megfelelő kulccsal írta azt alá. -3. Ha a tranzakció érvényes, a végrehajtási kliens a helyi tranzakciógyűjtőjéhez (memóriakészlet, a függő tranzakciók listája) adja és előterjeszti a többi csomópontnak a végrehajtási réteg pletykahálózatán. Amikor a többi csomópont hall a tranzakcióról, akkor azok is beteszik a helyi memóriakészletbe. A haladó felhasználók úgy is dönthetnek, hogy nem a hálózaton terjesztik el a tranzakciójukat, hanem továbbíthatják azt speciális blokképítőknek, mint a [Flashbots aukció](https://docs.flashbots.net/flashbots-auction/overview). Ez lehetővé teszi számukra, hogy a tranzakciókat a következő blokkokba szervezzék a maximális profit érdekében ([MEV](/developers/docs/mev/#mev-extraction)). -4. A hálózat egyik validátor-csomópontja az aktuális slot blokkelőterjesztője, amelyet előzőleg a RANDAO segítségével álvéletlenszerűen kiválasztottak. Ez a csomópont felelős az Ethereum blokklánchoz hozzáadandó következő blokk létrehozásáért és továbbításáért, valamint a globális státusz frissítéséért. A csomópont három részből áll: végrehajtási kliens, konszenzusos kliens és validátorkliens. A végrehajtási kliens a tranzakciókat a helyi memóriakészletből egy végrehajtási csomagba rendezi, és helyben végrehajtja őket, hogy státusztváltozást generáljon. Ezt az információt továbbítják a konszenzusos kliensnek, ahol a végrehajtási csomagot egy Beacon-blokk részeként csomagolják be, amely jutalmakra, büntetésekre, súlyos büntetésekre, tanúsításokra stb. vonatkozó információkat is tartalmaz, amelyek lehetővé teszik a hálózat számára, hogy megállapodjon a lánc élén álló blokkok sorrendjében. A végrehajtási és a konszenzusos kliensek közötti kommunikáció részletesebb leírása a [A konszenzusos és a végrehajtási kliensek összekapcsolása](/developers/docs/networking-layer/#connecting-clients) című cikkben található. -5. A többi csomópont az új Beacon-blokkot a konszenzusréteg pletykahálózatán keresztül kapja meg. Átadják azt a saját végrehajtási kliensüknek, ami a tranzakciókat helyben újra végrehajtja, így megbizonyosodnak arról, hogy érvényes a javasolt státuszváltozás. A validátorkliens ezután tanúsítja, hogy a blokk érvényes, és logikailag ez a következő blokk a láncban (vagyis az [elágazásválasztási szabályok](/developers/docs/consensus-mechanisms/pos/#fork-choice) szerint a legnagyobb tanúsítási súllyal bíró láncra épül). A blokk hozzáadódik a helyi adatbázishoz minden olyan csomópontban, amely tanúsítja azt. -6. A tranzakció akkor tekinthető „véglegesítettnek”, ha egy olyan lánc részévé vált, amelyben két ellenőrzőpont között „szupertöbbségi kapcsolat” van. Az ellenőrzési pontok minden korszak kezdetén fordulnak elő, és azért léteznek, mert az aktív tanúsítóknak csak egy részhalmaza tanúsít minden slotban, de az összes aktív tanúsító minden korszakban tanúsít. Ezért csak a korszakok között lehet „szupertöbbségi kapcsolat” (mikor a hálózaton lévő összes letétbe helyezett ETH 66%-a egyetért két ellenőrzőponton). - -A véglegesedésről a következő részben találhat bővebb információkat. - -## Véglegesség {#finality} - -Az elosztott hálózatokon egy tranzakció akkor válik „véglegessé”, amikor egy olyan blokk része lesz, amelyet csak jelentős mennyiségű ETH elégetésével lehet megváltoztatni. A proof-of-stake Ethereum-hálózata ezt az úgynevezett „checkpoint” (ellenőrző pont) blokkokkal éri el. Minden korszak első blokkja egy checkpoint blokk. A validátorok szavaznak az általuk érvényesek tartott checkpoint blokkpárokra. Ha egy checkpoint blokkpár megkapja legalább az összes letétbe helyezett ETH kétharmadát képviselő szavazatmennyiséget, akkor a checkpoint blokkok frissülnek. A kettő közül a későbbi (célblokk) „igazolt” állapotba kerül. A kettő közül a korábbi már igazolt állapotú, mivel az előző korszak „célblokkja” volt. Ez a blokk „véglegesített” állapotba kerül. - -Egy véglegesített blokk visszaalakításához egy támadónak legalább a letétbe helyezett összes ETH egyharmadát fel kellene áldoznia. Ennek pontos okát az [Ethereum Alapítvány blogposztja](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) részletesen ismerteti. Mivel a véglegességhez kétharmados többség szükséges, egy támadó a teljes ETH-letét egyharmadával szavazva akadályozhatja meg, hogy a hálózat véglegesítse a blokkot. Létezik egy mechanizmus, amellyel védekezni lehet ez ellen: ez az [inactivity leak](https://eth2book.info/bellatrix/part2/incentives/inactivity) (inaktivitási szivárgás). Akkor aktiválódik, amikor a blokklánc véglegesítése több mint négy korszakon keresztül meghiúsul. Az inactivity leak elszivárogtatja a többség ellen szavazó validátorok ETH-letétjét, ezzel lehetővé teszi, hogy a többség visszaszerezze a kétharmados többséget és véglegesítse a láncot. - -## Kriptogazdaság-védelem {#crypto-economic-security} - -Egy validátor futtatása elkötelezettséget jelent. A validátortól elvárják, hogy megfelelő hardvert és internetkapcsolatot tartson fenn a blokkvalidálásban és -előterjesztésben való részvételhez. Cserébe a validátor ETH-kifizetést kap (növekszik a letéti egyenlege). Ugyanakkor a validátorként való részvétel új lehetőségeket kínál a felhasználóknak, hogy személyes haszon vagy szabotázs érdekében megtámadják a hálózatot. Ez ellen hat, hogy a validátorok elveszítik az ETH-jutalmakat, ha felhívás esetén nem vesznek részt a validálásban, és a meglévő letétjük is megsemmisülhet, ha becstelenül viselkednek. Két fő viselkedési módot tekintünk rosszhiszeműnek: egy sloton belül több blokk előterjesztése (kétértelműsítés), valamint az ellentmondásos tanúsítások elküldése. - -A megvágott ETH-mennyiség azon múlik, hogy ugyanabban az időben hány másik validátor ETH-letétjét vágja még meg a rendszer. Ez az úgynevezett [„korrelációs bírság”](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty), amelynek mértéke lehet csekély (a letét kb. 1%-a az egyedülálló validátornál), de eredményezheti akár a validátori letét 100%-ának elvesztését is (tömeges megvágási esemény). Egy kényszerített kilépési periódus felénél szabja ki a rendszer, amely egy azonnali bírsággal (legfeljebb 1 ETH) kezdődik az 1. napon, majd korrelációs bírsággal folytatódik a 18. napon, végül a hálózatból való kivetéssel fejeződik be a 36. napon. Kis összegű tanúsítási bírságot kapnak minden nap, mert jelen vannak a hálózaton, de nem adnak le szavazatot. Ez mind azt jelenti, hogy egy koordinált támadás nagyon költséges lenne a támadó számára. - -## Elágazásválasztás {#fork-choice} - -Amikor a hálózat optimálisan és becsületesen működik, akkor mindig csak egy blokk van a lánc elején, és minden validátor tanúsítja azt. Mindazonáltal lehetséges, hogy hálózati látencia vagy a blokkelőterjesztő kétértelmű javaslata miatt a validátorok eltérően látják a lánc elejét. Ezért a konszenzusklienseknek egy algoritmusra van szükségük, hogy eldöntsék, melyiket részesítsék előnyben. A proof-of-stake Ethereum által használt algoritmus az [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf), és úgy működik, hogy azonosítja az előzmények szerint a tanúsítások legnagyobb többségét magáénak tudó elágazást (fork). - -## Proof-of-stake és biztonság {#pos-and-security} - -Egy [51%-os támadás](https://www.investopedia.com/terms/1/51-attack.asp) veszélye a proof-of-work architektúrához hasonlóan a proof-of-stake konszenzusnál is fennáll, ám itt még kockázatosabb a támadók számára. A támadónak a letétbe helyezett ETH-mennyiség 51%-ára volna szüksége. Így a saját tanúsításai segítségével biztosíthatná, hogy az általa előnyben részesített elágazás (fork) szerezze meg a legtöbb tanúsítást. A felhalmozott tanúsítások „súlya” az, amit a konszenzuskliensek a helyes lánc meghatározásához használnak, tehát ez a támadó képes volna általánosan elfogadottá tenni a saját elágazását. Ugyanakkor a proof-of-work konszenzussal szemben a proof-of-stake erőssége az ellentámadás rugalmas bevezetésében rejlik. Például a becsületes validátorok dönthetnek úgy, hogy tovább építik a kisebbségi láncot, és figyelmen kívül hagyják a támadó elágazását, és ugyanerre biztatják az alkalmazásokat, a tőzsdéket és a poolokat is. Úgy is határozhatnak, hogy erőszakkal eltávolítják támadót hálózatról, és megsemmisítik az ETH-letétjét. Ezek erős gazdaságvédelmet jelentenek az 51%-os támadások ellen. - -Az 51%-os támadáson túl a rosszhiszemű szereplők megpróbálhatnak más jellegű káros tevékenységeket, mint amilyen: - -- a nagy hatótávolságú támadások (bár a véglegességi eszköz semlegesíti ezt a támadási vektort) -- rövid hatótávolságú „átrendezések” (bár a javaslattevő-erősítése és a tanúsítási határidők kivédik ezt) -- pattogó (bouncing) és a kiegyenlítő (balancing) támadások (szintén mitigálja a javaslattevő-erősítése, és ezeket főleg ideális hálózati körülmények között lehet végrehajtani) -- lavinatámadások (az elágazásválasztási algoritmus szabálya semlegesíti, amely csak az utolsó üzenetet veszi figyelembe) - -Összességében a proof-of-stake – ahogy azt az Ethereum megvalósította – gazdasági szempontból bizonyítottan védettebb, mint proof-of-work. - -## Előnyök és hátrányok {#pros-and-cons} - -| Előnyök | Hátrányok | -| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | -| A letétbe helyezés az egyének számára megkönnyíti a részvételt a hálózat biztosításában, ezzel elősegíti a decentralizációt. Validátor-csomópont egy átlagos laptopon is futtatható. A letéti alapok lehetővé teszik, hogy a felhasználók akkor is részt vegyenek, ha nincs 32 ETH-jük. | A proof-of-stake fiatalabb és még kevésbé tesztelt, mint a proof-of-work. | -| A letétbe helyezés decentralizáltabb. A méretgazdaságosság nem úgy érvényesül, mint a PoW-bányászat esetén. | A proof-of-stake esetén a megvalósítás bonyolultabb, mint a proof-of-work konszenzusnál. | -| A proof-of-stake erősebb kriptogazdasági védelmet kínál, mint a proof-of-work. | A felhasználóknak három szoftvert kell futtatniuk, hogy részt vehessenek az Ethereum proof-of-stake konszenzusában. | -| Kevesebb új ETH-t kell kibocsátani a hálózati résztvevők ösztönzéséhez. | | - -### Összehasonlítása a proof-of-work mechanizmussal {#comparison-to-proof-of-work} - -Az Ethereum eredetileg proof-of-work mechanizmust használt, amelyről proof-of-stake mechanizmusra váltott 2022 szeptemberében. A PoS számos előnnyel jár a PoW-vel szemben: - -- nagyobb energiahatékonyság – nincs szükség sok energia felhasználására a proof-of-work számításokhoz; -- alacsonyabb belépési korlát, csökkentett hardverkövetelmények – nincs szükség csúcstechnológiás hardverre ahhoz, hogy esélyünk legyen új blokkot létrehozni; -- kisebb centralizációs kockázat – a proof-of-stake architektúra több csomópont részvételét eredményezi a hálózat biztosításában; -- az alacsony energiaszükséglet miatt kevesebb ETH-t kell kibocsátani a részvételre ösztönzéshez; -- a szabálytalan viselkedés gazdasági büntetése miatt a proof-of-work architektúrához képest magasabb költséggel jár az 51%-os típusú támadás a támadó számára; -- ha egy 51%-os támadás legyűri a kriptogazdasági védelmi rendszert, a közösség dönthet egy becsületes blokklánc közösségi visszaállítása mellett. - -## További olvasnivaló {#further-reading} - -- [Proof-of-stake (letéti igazolás) GYIK](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ -- [Mi az a Proof-of-Stake?](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ -- [Mi az a Proof-of-Stake és miért fontos?](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ -- [Miért a proof-of-stake (2020. november)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ -- [Proof-of-Stake: Hogyan tanultam meg szeretni a gyenge szubjektivitást](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ -- [Proof-of-stake Ethereum – támadás és védekezés](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) -- [A proof-of-stake tervezési filozófiája](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ -- [Videó: Vitalik Buterin elmagyarázza a proof-of-stake mechanizmust Lex Fridmannak](https://www.youtube.com/watch?v=3yrqBG-7EVE) - -## Kapcsolódó témák {#related-topics} - -- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/) -- [Proof-of-authority (jogosultsági igazolás)](/developers/docs/consensus-mechanisms/poa/) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" deleted file mode 100644 index bc2fcecc6fb..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/keys/index.md" +++ /dev/null @@ -1,96 +0,0 @@ ---- -title: Kulcsok a proof-of-stake Ethereumban -description: Az Ethereum proof-of-stake konszenzusmechanizmusában használt kulcsok ismertetése -lang: hu ---- - -Az Ethereum a nyilvános-privát kulcspáron alapuló kriptográfia segítségével biztosítja a felhasználói eszközöket. A nyilvános kulcs az Ethereum-cím alapjául szolgál, tehát látható a nyilvánosság számára, és egyedi azonosítóként használják. A privát (vagy titkos) kulcshoz mindig csak a számla tulajdonosa férhet hozzá. A privát kulcsot tranzakciók és adatok aláírására használják, hogy a kriptográfia bizonyítani tudja, hogy a tulajdonos jóváhagyja az adott privát kulcs műveletét. - -Az Ethereum kulcsait [elliptikus görbe kriptográfiával](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) generálják. - -Amikor azonban az Ethereum [proof-of-work](/developers/docs/consensus-mechanisms/pow) mechanizmusról [proof-of-stake-re](/developers/docs/consensus-mechanisms/pos) váltott, egy új típusú kulcs került az Ethereumba. Az eredeti kulcsok továbbra is pontosan ugyanúgy működnek, mint korábban – a számlákat biztosító elliptikus görbén alapuló kulcsok nem változtak. A felhasználóknak azonban új típusú kulcsra volt szükségük ahhoz, hogy részt vehessenek a proof-of-stake-ben az ETH letétbe helyezésével és a validátorok futtatásával. Ez az igény a skálázhatóság miatt érdekes, hogy a nagyszámú validátorok közötti üzenetekhez olyan kriptográfiai módszer legyen, amely könnyen aggregálható, így csökkenti a hálózati konszenzus kommunikációs igényét. - -Ez az új típusú kulcs a [**Boneh-Lynn-Shacham (BLS)** aláírási sémát használja](https://wikipedia.org/wiki/BLS_digital_signature). A BLS lehetővé teszi az aláírások nagyon hatékony aggregálását, ugyanakkor az aggregált egyedi validátorkulcsok visszafejtését is, és ideális a validátorok közötti műveletek kezelésére. - -## A validátorkulcsok két típusa {#two-types-of-keys} - -A proof-of-stake-re való átállás előtt az Ethereum-felhasználóknak csak egyetlen elliptikus görbén alapuló privát kulccsal volt hozzáférésük a pénzükhöz. A proof-of-stake bevezetésével az önálló letétbe helyezőknek szükségük volt egy **validátorkulcsra** és egy **kivételi kulcsra** is. - -### A validátorkulcs {#validator-key} - -A validátor aláírókulcs két elemből áll: - -- Validátor **privát** kulcs -- Validátori **nyilvános** kulcs - -A validátor privát kulcsának célja a láncon belül végrehajtott műveletek, például a blokkjavaslatok és a tanúsítások aláírása. Emiatt ezeket a kulcsokat egy „forró” tárcában kell tartani (mindig online és elérhető legyen). - -Ennek a rugalmasságnak az az előnye, hogy a validátor aláírókulcsok gyorsan mozgathatók egyik eszközről a másikra, azonban ha elvesznek vagy ellopják azokat, a tolvaj többféleképpen is képes lehet **visszaélni** azokkal: - -- A validátort súlyos és kizárással járó büntetés éri: - - Amikor blokkelőterjesztő, akkor két különböző Beacon blokkot javasol és ír alá ugyanarra a slotra - - Tanúsítóként olyan tanúsítást hagy jóvá, amely „körbeölel” egy másikat - - Tanúsítóként két eltérő tanúsítást ír alá ugyanarra a dologra -- Önkéntes kilépésre kényszeríti, amely a validátor letétjét feloldja és a kivételi kulcs tulajdonosa hozzáfér az ETH-egyenleghez - -A **validátor nyilvános kulcsa** szerepel a tranzakció adataiban, amikor egy felhasználó ETH-t fizet be a letéti szerződésbe. Ez az úgynevezett _letéti adat_, amely lehetővé teszi az Ethereum számára a validátor azonosítását. - -### Kivételi hitelesítő adatok {#withdrawal-credentials} - -Minden validátor rendelkezik egy tulajdonsággal, amelyet _visszavonási hitelesítő adatoknak_ neveznek. Ez a 32 bájtos mező vagy `0x00`-val kezdődik, ami a BLS kivonási hitelesítő adatokat jelenti, vagy az eleje` 0x01`, ami a végrehajtási címre mutató hitelesítő adatokat jelenti. - -A `0x00` BLS kulcsokkal rendelkező validátoroknak frissíteniük kell ezeket a hitelesítő adatokat, hogy azok egy végrehajtási címre mutassanak a többletegyenleg kifizetéséhez vagy a letétkivonáshoz. Ezt úgy lehet megtenni, hogy a kezdeti kulcsgenerálás során a letétbe helyezési adatokban megadunk egy végrehajtási címet, _VAGY_ úgy, hogy a kivételi kulcsot egy későbbi időpontban felhasználjuk egy `BLSToExecutionChange` üzenet aláírására és továbbítására. - -### A kivételi kulcs {#withdrawal-key} - -A kivételi kulcsra a kivételi hitelesítő adatok frissítéséhez van szükség, hogy azok egy végrehajtási címre mutassanak, ha a kezdeti befizetés során ezt nem állították be. Ez lehetővé teszi a felhasználók számára a többletegyenleg-kifizetések feldolgozásának elindítását, és a letétbe helyezett ETH teljes kivételét is. - -Ahogy a validátorkulcsok, a kivételi kulcsok is két elemből állnak: - -- Kivételi **privát** kulcs -- Kivételi **nyilvános** kulcs - -Ennek a kulcsnak az elvesztése a kivételi hitelesítő adatok `0x01` típusra történő frissítése előtt a validátoregyenleghez való hozzáférés elvesztését jelenti. A validátor továbbra is aláírhatja a tanúsításokat és a blokkokat, mivel ezekhez a műveletekhez a validátor privát kulcsa szükséges, azonban a kivételi kulcsok elvesztése miatt erre igen kevés a motivációja. - -A validátorkulcsok és az Ethereum-számlakulcsok szétválasztása lehetővé teszi, hogy egyetlen felhasználó több validátort is futtasson. - -![validátorkulcs ábrája](validator-key-schematic.png) - -## Kulcsok származtatása egy kulcsmondatból {#deriving-keys-from-seed} - -Ha minden 32 ETH feltöltéséhez 2 független kulcsból álló új készletre lenne szükség, a kulcskezelés nehézkessé válna, különösen a több validátort futtató felhasználók számára. Ehelyett több validátorkulcsot lehet egyetlen titokból levezetni, és ennek a titoknak a tárolása lehetővé teszi a hozzáférést több validátorkulcshoz. - -[Az emlékeztető kódszó](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) és az útvonalak olyan kiemelkedő jellemzők, amelyekkel a felhasználók gyakran találkoznak, amikor [hozzáférnek](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) a tárcájukhoz. Az emlékeztető kódszó egy szavakból álló sorozat, amely a privát kulcs kezdeti magjaként szolgál. További adatokkal kombinálva az emlékeztető kódszó egy „mesterkulcs” néven ismert hasht generál. Ezt úgy lehet elképzelni, mint egy fa gyökerét. Ebből a gyökérből hierarchikus útvonal segítségével elágazások vezethetők le, így a gyermek csomópontok a szülői csomópont hashjének és a fán belüli indexének kombinációjaként létezhetnek. Tekintse meg a [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) és [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) szabványokat az emlékeztetőkódszó-alapú kulcsgeneráláshoz. - -Ezek az útvonalak a következőképpen néznek ki, ami ismerős lehet azoknak, akik már dolgoztak hardvertárcákkal: - -``` -m/44'/60'/0'/0` -``` - -Az ebben az elérési útvonalban lévő perjelek a következőképpen választják el a privát kulcs összetevőit: - -``` -master_key / purpose / coin_type / account / change / address_index -``` - -Ez a logika lehetővé teszi a felhasználók számára, hogy egyetlen **emlékeztető kódszóhoz** a lehető legtöbb validátort csatolják, mivel a fa gyökere közös lehet, és a differenciálás az elágazásokban történhet. A felhasználó **az emlékeztető kódszóból tetszőleges számú kulcsot** származtathat. - -``` - [m / 0] - / - / -[m] - [m / 1] - \ - \ - [m / 2] -``` - -Az egyes ágakat `/` választja el egymástól, így `m/2` azt jelenti, hogy a mesterkulccsal kezdjük, és a 2. ágat követjük. Az alábbi ábrán egyetlen emlékeztető kódszót használunk három kivételi kulcs tárolására, mindegyikhez két validátor tartozik. - -![validátorkulcs-logika](multiple-keys.png) - -## További olvasnivaló {#further-reading} - -- [Ethereum Alapítvány blogbejegyzés Carl Beekhuizentől](https://blog.ethereum.org/2020/05/21/keys/) -- [EIP-2333 BLS12-381 kulcsgenerálás](https://eips.ethereum.org/EIPS/eip-2333) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" deleted file mode 100644 index 36d344276db..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md" +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: A proof-of-stake és a proof-of-work összehasonlítása -description: Az Ethereum proof-of-stake és proof-of-work alapú konszenzusmechanizmusának összehasonlítása -lang: hu ---- - -Amikor az Ethereumot bevezették, a proof-of-stake (letéti igazolás) még sok kutatást és fejlesztést igényelt, mielőtt erre alapozhatták volna az Ethereum biztosítását. A proof-of-work (munkaigazolás) egy egyszerűbb mechanizmus volt, ami már működött a Bitcoinnál, így a központi fejlesztők egyszerűen implementálni tudták, hogy elindulhasson az Ethereum. Ezután a proof-of-stake mechanizmusát még nyolc évig fejlesztették, mielőtt áttérek volna rá. - -Ez az oldal az Ethereum proof-of-work mechanizumusról proof-of-stake mechanizmusra való áttérésének okait és a szükséges kompromisszumokat magyarázza el. - -## Biztonság {#security} - -Az Ethereum kutatói biztonságosabbnak tartják a proof-of-stake-et, mint a proof-of-worköt. Ez nemrég került bevezetésre a valódi Ethereum főhálózatra, és kevésbé bizonyított, mint a proof-of-work. A következő részben a proof-of-stake biztonsági modelljének előnyeit és hátrányait tárgyaljuk a proof-of-workhöz képest. - -### A támadás költsége {#cost-to-attack} - -A proof-of-stake-ben a validátoroknak letétbe kell helyezniük 32 ETH-t egy okosszerződésben. Az Ethereum a rosszhiszemű validátorokat büntetheti azzal, hogy megsemmisíti a letétbe helyezett ethert. A konszenzushoz a teljes letétbe helyezett ether legalább 66%-a kell szavazzon a blokkok egy bizonyos halmazára. A letét >=66%-a által megszavazott blokkok „véglegesítetté” válnak, ami azt jelenti, hogy nem lehet őket eltávolítani vagy átszervezni. - -A hálózat elleni támadás jelentheti azt, hogy megakadályozzák a lánc véglegesítését, vagy a blokkokat a támadó számára előnyös sorrendbe rendezik a kanonikus láncban. Ehhez a támadónak el kell térítenie a helyes konszenzus útját azzal, hogy nagy mennyiségű ethert halmoz fel, és közvetlenül azzal szavaz, vagy úgy, hogy becsapja a becsületes validátorokat, hogy egy bizonyos módon szavazzanak. A kifinomult, kis valószínűséggel bíró támadások során a jóhiszemű validátorokat eltérítik, ekkor az Ethereum megtámadásának költsége azonos a letéttel, amelyet a támadónak fel kell halmoznia ahhoz, hogy a konszenzust a maga javára befolyásolja. - -A legalacsonyabb támadási költség a teljes letét >33%-a. A teljes letét >33%-át birtokló támadó egyszerűen offline állapotba kerülve késleltetheti a véglegesítést. Ez viszonylag kisebb probléma a hálózat számára, mivel létezik egy „inaktivitási elszivárgási” mechanizmus, amely addig redukálja a letéteket az offline validátoroktól, amíg az online többség a letét 66%-át nem képviseli, és újra véglegesíteni tudja a láncot. Elméletileg az is lehetséges, hogy egy támadó a teljes letét valamivel több mint 33%-ával kettős véglegesítést idézzen elő azáltal, hogy egy helyett két blokkot hoz létre, amikor felkérik, hogy legyen blokkelőterjesztő, majd az összes validátorral együtt kétszeresen szavazzon. Mindkét elágazáshoz csak a megmaradt becsületes validátorok 50%-ának kell először látni az egyes blokkokat, így ha sikerül pontosan időzíteniük az üzeneteiket, akkor képesek lehetnek mindkét elágazást véglegesíteni. Ennek kicsi a valószínűsége, de ha egy támadó képes lenne kettős véglegesítést előidézni, akkor az Ethereum közösségének úgy kellene döntenie, hogy az egyik elágazást követi, és ebben az esetben a támadó validátorait a másik elágazáson súlyosan megbüntetnék és kizárnák. - -A teljes letét >33%-ával egy támadónak esélye van arra, hogy kisebb (véglegesítés késleltetése) vagy komolyabb (dupla véglegesítés) hatást gyakoroljon az Ethereum-hálózatra. Több mint 14 000 000 ETH letétje van a hálózaton és egy reprezentatív 1000 dollár/ETH árral, az ilyen támadások minimális költsége `1000 × 14 000 000 × 0,33 = 4 620 000 000 dollár`. A támadó ezt a pénzt elveszítené a súlyos büntetés következtében, és kiesne a hálózatból. Az újbóli támadáshoz a letét >33%-át kellene (újra) felhalmozniuk és (újra) elégetniük. Minden egyes támadási kísérlet a hálózat megtámadására >4,6 milliárd dollárba kerülne (1000 dollár/ETH és 14 millió ETH letét mellett). A támadót kidobják a hálózatból a súlyos büntetés következtében, és egy aktiválási sorba kell beállnia, hogy újra csatlakozhasson. Ez azt jelenti, hogy az ismételt támadás mértéke nemcsak arra az arányra korlátozódik, amivel a támadó a teljes letét >33%-át fel tudja halmozni, hanem arra az időre is, amíg az összes validátorát fel tudja venni a hálózatra. Minden egyes támadással a támadó sokkal szegényebbé válik, a közösség többi tagja pedig gazdagabb lesz az ebből eredő drasztikus kínálati változásnak köszönhetően. - -Más támadások, mint például az 51%-os támadás vagy a teljes letét 66%-ával történő véglegesség visszafordítása, lényegesen több ETH-t igényelnek, és sokkal költségesebbek a támadó számára. - -Összehasonlítjuk a proof-of-work mechanizmussal. A proof-of-work Ethereum elleni támadás indításának költsége az volt, hogy a teljes hálózati hashráta >50%-át folyamatosan birtokolni kellett. Ez az elegendő számítási teljesítmény hardver- és üzemeltetési költségét jelentette ahhoz, hogy a proof-of-work megoldások kiszámításában lehagyja a többi bányászt. Az Ethereumon többnyire GPU-t használtak a bányászathoz, nem ASIC-et, ami alacsonyan tartotta a költségeket (ha a proof-of-work rendszer fennmaradt volna, az ASIC-alapú bányászat népszerűbb lehetett volna). Egy támadónak rengeteg hardverre lett volna szüksége, illetve fizethette volna a működtetés költségeit, hogy megtámadhasson egy proof-of-work Ethereum-hálózatot, de ez kevesebb, mint a támadáshoz szükséges ETH felhalmozása. Egy 51%-os támadás a proof-of-work esetében [kb. 20x olcsóbb](https://youtu.be/1m12zgJ42dI?t=1562), mint a proof-of-stake esetében. Ha a támadást észlelték, és a lánc elágazott (hard fork), hogy eltávolítsák a támadó hatását, a támadó ismételten ugyanazt a hardvert használhatná az új elágazás megtámadásához. - -### Bonyolultság {#complexity} - -A proof-of-stake kivitelezése a proof-of-workhöz képest sokkal bonyolultabb. Ez a proof-of-work mellett szólhat, mivel az egyszerűbb protokollokba sokkal nehezebb véletlen hibákat vagy nem kívánt hatásokat bevinni. Habár a komplexitást sikerült megszelídíteni több éves kutatás és fejlesztés, szimulációk és teszthálózati megvalósítások révén. A proof-of-stake protokollt öt független csapat (a végrehajtási és konszenzusrétegen is), öt programozási nyelven valósította meg, ami ellenállást biztosít a klienshibákkal szemben. - -A proof-of-stake konszenzus logikájának biztonságos fejlesztése és tesztelése érdekében a Beacon lánc két évvel azelőtt indult el, hogy a proof-of-stake-et az Ethereum főhálózatra bevezették volna. A Beacon lánc a proof-of-stake tesztelési helyeként működött, mivel élő blokklánc volt proof-of-stake konszenzuslogikával, de nem kezelt valódi Ethereum-tranzakciókat, gyakorlatilag csak önmagában jutott konszenzusra. Amint ez kellő ideig stabil és hibamentes volt, a Beacon láncot „beolvasztották” az Ethereum főhálózatba. Mindez hozzájárult ahhoz, hogy a proof-of-stake összetettsége kezelhetővé váljon, és a nem kívánt következmények vagy a klienshibák kockázata alacsony legyen. - -### Támadási felület {#attack-surface} - -A proof-of-stake összetettebb, mint a proof-of-work, ami azt jelenti, hogy több potenciális támadási vektorral kell megbirkózni. A klienseket összekötő peer-to-peer hálózatból kettő van, külön protokollal. Mivel előre kiválasztanak egy validátort, hogy egy adott slotban blokkot javasoljon, így lehetőség nyílik a szolgáltatásmegtagadásra, amikor az adott validátort annyi feladattal árasztják el, hogy nem tudja végrehajtani a fő funkcióját. - -Vannak olyan módszerek is, amelyekkel a támadók gondosan időzíthetik blokkjaik vagy tanúsításaik közzétételét, hogy azokat a becsületes hálózat egy bizonyos hányada megkapja, és így bizonyos módon szavaznak. Végül egy támadó egyszerűen elegendő ETH letétet képezhet ahhoz, hogy uralja a konszenzusmechanizmust. E [támadási vektorok mindegyikének vannak kapcsolódó védekezési lehetőségei](/developers/docs/consensus-mechanisms/pos/attack-and-defense), ugyanakkor ezek nem léteznek a proof-of-work mechanizmusban. - -## Decentralizáció {#decentralization} - -A proof-of-stake decentralizáltabb, mint a proof-of-work, mivel a bányászhardverek versenyében a magánszemélyek és a kis szervezetek kiszorulnak a versenyből. Bár technikailag bárki elkezdheti a bányászatot szerény hardverrel, annak a valószínűsége, hogy jutalmat kap, elenyészően kicsi az intézményes bányászathoz képest. A proof-of-stake esetében a letét költsége és százalékos megtérülése mindenki számára azonos. Jelenleg 32 ETH-be kerül egy validátor működtetése. - -Másrészt a likvid letéti derivatívák centralizációs aggályokhoz vezettek, mivel néhány nagy szolgáltató nagy mennyiségű letétbe helyezett ETH-t kezel. Ez problémás, és minél előbb korrigálni kell, de árnyaltabb is, mint amilyennek látszik. A központosított letéti alapok nem feltétlenül központosítják a validátorok irányítását – gyakran ez egy módja annak, hogy egy központi ETH-állományt sok független csomópont-üzemeltető adjon össze anélkül, hogy minden résztvevőnek 32 saját ETH-re lenne szüksége. - -Az Ethereum számára a legjobb megoldás az, ha a validátorokat helyben, otthoni számítógépeken futtatják, maximalizálva a decentralizációt. Ezért ellenzi az Ethereum azokat a változtatásokat, amelyek növelik a csomópont és a validátor futtatásának hardverigényét. - -## Fenntarthatóság {#sustainability} - -A proof-of-stake energiafogyasztása miatt ez gazdaságos módja a blokklánc biztosításának. A proof-of-work rendszerben a bányászok versenyeznek a blokkbányászat jogáért. A bányászok sikeresebbek, ha gyorsabban tudják elvégezni a számításokat, ami miatt többet fektetnek hardverbe és nagyobb az energiafogyasztás. Ez jellemezte az Ethereumot, mielőtt átállt volna a proof-of-stake-re. Nem sokkal a proof-of-stake-re való áttérés előtt az Ethereum körülbelül 78 TWh/év mennyiséget fogyasztott, akár egy kisebb ország. A proof-of-stake-re való áttérés azonban kb. 99,98%-kal csökkentette ezt az energiafelhasználást. Ez tehát az Ethereumot egy energiahatékony, alacsony szén-dioxid-kibocsátású platformmá tette. - -[Bővebben az Ethereum energiafogyasztásáról](/energy-consumption) - -## Kibocsátás {#issuance} - -A proof-of-stake Ethereum kevesebb érmekibocsátással tudja fenntartani a biztonságát, mint a proof-of-work rendszerben, mivel a validátoroknak nem kell magas áramköltséget fizetniük. Ennek eredményeképpen az ETH inflációja csökkenhet, vagy akár deflálódhat is, ha nagy mennyiségű ETH-t égetnek el. Az alacsonyabb inflációs szintek azt jelentik, hogy az Ethereum biztonságát olcsóbb fenntartani, mint amikor proof-of-work mechanizmust használt. - -## Ön inkább vizuális típus? {#visual-learner} - -Tekintse meg Justin Drake magyarázatát a proof-of-stake előnyeiről a proof-of-workhöz képest: - - - -## További olvasnivaló {#further-reading} - -- [Vitalik proof-of-stake tervezési filozófiája](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) -- [Vitalik proof-of-stake GYIK](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) -- [„Simply Explained” (egyszerű magyarázat) videó a proof-of-stake és a proof-of-woork mechanizmusokról](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" deleted file mode 100644 index 77c227c7940..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md" +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Proof-of-stake jutalmak és büntetések -description: Ismerje meg a protokollon belüli ösztönzőket a proof-of-stake Ethereumban. -lang: hu ---- - -Az Ethereumot a natív kriptovaluta, az ether (ETH) biztosítja. Azok a csomópont-üzemeltetők, akik részt kívánnak venni a blokkok validálásában és a lánc fejének azonosításában, ethert helyeznek el az Ethereumon egy [letéti szerződésben](/staking/deposit-contract/). Ezután etherben fizetnek nekik a validátorszoftver futtatásáért, amely ellenőrzi a peer-to-peer hálózaton keresztül érkező új blokkok érvényességét, és a lánc fejének azonosítására az elágazásválasztó-algoritmust alkalmazza. - -A validátornak két fő szerepe van: 1) az új blokkok ellenőrzése és „tanúsítása”, hogy érvényesek-e, 2) új blokk előterjesztése, amikor véletlenszerűen kiválasztják a validátorállományból. Ha a validátor nem végzi el e feladatok egyikét sem, amikor erre felkérik, akkor lemarad az ether kifizetéséről. A validátorokat felkérhetik az aláírások összesítésére és a szinkronizáló bizottságokban való részvételre is. - -Vannak olyan műveletek, amelyeket nehéz lenne véletlenül elvégezni, ezért valamilyen rosszindulatú szándékot jeleznek, például több blokkot javasolni vagy tanúsítani ugyanarra a slotra. Ezek súlyos büntetést vonnak maguk után, amelyek azt eredményezik, hogy a validátor egyenlegéből bizonyos mennyiségű ethert (legfeljebb 1 ETH-t) elégetnek, mielőtt eltávolításra kerül a hálózatból, ami 36 napot vesz igénybe. A súlyos büntetést kapott validátor ether egyenlege lassan fogy a kilépési időszak alatt, de a 18. napon „korrelációs büntetést” kap, amely nagyobb, ha több validátor egy időben kerül kizárásra. A konszenzusmechanizmus ösztönző struktúrája tehát a helyes viselkedésért jutalmat fizet, a rossz szereplőket pedig bünteti. - -Minden jutalom és büntetés korszakonként egyszer kerül alkalmazásra. - -Tekintse meg a további részleteket... - -## Jutalmak és büntetések {#rewards} - -### Jutalmak {#rewards} - -A validátorok jutalomban részesülnek, ha a többi validátorral összhangban adnak szavazatokat, ha blokkokat javasolnak, és ha részt vesznek a szinkronizáló bizottságokban. A jutalmak értékét minden egyes korszakban egy `base_reward` (alapjutalom) alapján számítják ki. Ez az alapegység, amelyből a többi jutalmat számolják. A `base_reward` az egy validátor által optimális körülmények között kapott átlagos jutalom korszakonként. Ezt a validátor tényleges egyenlegéből és az aktív validátorok teljes számából számítják ki: - -``` -base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) -``` - -ahol `base_reward_factor` 64, `base_rewards_per_epoch` 4 és `sum(active balance)` az összes aktív validátor letétbe helyezett ether egyenlege. - -Ez azt jelenti, hogy az alapjutalom arányos a validátor tényleges egyenlegével és fordítottan arányos a hálózaton lévő validátorok számával. Minél több validátor van, annál nagyobb a teljes kibocsátás (mint `sqrt(N)`, de annál kisebb az egy validátorra jutó `base_reward` alapjutalom (mint `1/sqrt(N)`). Ezek a tényezők befolyásolják a letétbe helyező csomópontra vonatkozó APR-t (éves ráta). Tekintse meg ennek indoklását [Vitalik jegyzeteiben](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards). - -A teljes jutalmat ezután öt összetevő összegeként számítják ki, amelyek mindegyike súlyozással rendelkezik, amely meghatározza, hogy az egyes összetevők mennyivel járulnak hozzá a teljes jutalomhoz. Az összetevők a következők: - -``` -1. source vote: the validator has made a timely vote for the correct source checkpoint -2. target vote: the validator has made a timely vote for the correct target checkpoint -3. head vote: the validator has made a timely vote for the correct head block -4. sync committee reward: the validator has participated in a sync committee -5. proposer reward: the validator has proposed a block in the correct slot -``` - -Az összetevők súlyozása a következő: - -``` -TIMELY_SOURCE_WEIGHT uint64(14) -TIMELY_TARGET_WEIGHT uint64(26) -TIMELY_HEAD_WEIGHT uint64(14) -SYNC_REWARD_WEIGHT uint64(2) -PROPOSER_WEIGHT uint64(8) -``` - -A súlyok összege 64. A jutalom kiszámítása az alkalmazandó súlyok összege osztva 64-gyel. Az a validátor, aki időben leadta a forrás-, cél- és fejszavazatokat, blokkot javasolt és részt vett a szinkronizáló bizottságban az a következőt kaphatja: `64/64 * base_reward == base_reward`. Egy validátor azonban általában nem szokott blokkot javasolni, így a maximális jutalma: `64-8 /64 * base_reward == 7/8 * base_reward`. Azok a validátorok, akik nem blokkelőterjesztők és nem is tagjai szinkronizáló bizottságnak, a következőképpen kaphatnak: ` 64-8-2 / 64 * base_reward == 6,75/8 * base_reward`. - -A gyors tanúsítások ösztönzésére további jutalom jár. Ez az `inclusion_delay_reward`. Ennek értéke megegyezik a `base_reward` és `1/delay` szorzatával, ahol a `delay` a blokkjavaslat és a tanúsítás között eltelt slotok száma. Például, ha a tanúsítás a blokkjavaslat slotján belül kerül benyújtásra, a tanúsító `base_reward * 1/1 == base_reward` jutalmat kap. Ha a tanúsítás a következő slotban érkezik, akkor a tanusító `base_reward * 1/2` jutalmat kap és így tovább. - -A blokkot javaslók `8 / 64 * base_reward` jutalmat kapnak **minden egyes, a blokkban szereplő érvényes tanúsításért **, így a jutalom tényleges értéke a tanúsító validátorok számával növekszik. A blokkot javaslók növelhetik jutalmukat azáltal is, hogy a javasolt blokkjukba más validátorok helytelen viselkedésére vonatkozó bizonyítékokat is beillesztenek. Ezek azok az ösztönzők, amelyek a validátorokat őszinteségre motiválják. A súlyos büntetést tartalmazó blokkelőterjesztőt `slashed_validators_effective_balance / 512` értékkel jutalmazzák. - -### Büntetések {#penalties} - -Eddig a jól viselkedő validátorokat vettük figyelembe, de mi a helyzet azokkal, akik nem vagy csak lassan teszik meg a fej-, forrás- és célszavazatokat? - -A cél- és forrásszavazatok elmaradásáért járó büntetés megegyezik azzal a jutalommal, amelyet az igazoló kapott volna, ha leadja azokat. Ez azt jelenti, hogy ahelyett, hogy a jutalom hozzáadódna az egyenlegükhöz, ugyanekkora értéket vonnak el abból. A fejszavazás elmulasztásáért nincs büntetés (azt csak jutalmazzák, nem büntetik). Az `inclusion_delay` kapcsán nincs büntetés, a jutalom egyszerűen nem kerül hozzáadásra a validátor egyenlegéhez. Nincs büntetés azért sem, ha valaki nem javasol blokkot. - -Tudjon meg többet a jutalmakról és büntetésekről a [konszenzusspecifikációból](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md). A jutalmakat és büntetéseket a Bellatrix frissítéssel módosították – nézze meg Danny Ryan és Vitalik beszélgetését erről ebben a [Peep an EIP videóban](https://www.youtube.com/watch?v=iaAEGs1DMgQ). - -## Slashing {#slashing} - -A súlyos büntetés (slash) egy komoly művelet, amely eltávolítja a validátort a hálózatból, aki a letétbe helyezett ethert is elveszti. Három oka lehet egy validátor súlyos megbüntetésének, amelyek mindegyike a blokkok rosszhiszemű felajánlását vagy tanúsítását jelenti: - -- Két különböző blokk előterjesztése és aláírása ugyanarra a slotra -- Egy olyan blokk tanúsítása, amely „magába foglal” egy másikat (gyakorlatilag megváltoztatva a historikus adatokat) -- „Kettős szavazás”, amikor két jelöltet tanúsít ugyanarra a blokkra - -Ha ezeket a műveleteket észlelik, a validátort súlyosan megbüntetik. Ez azt jelenti, hogy a letétbe helyezett etherük 1/32-ét (maximum 1 etherig) azonnal elégetik, majd egy 36 napos eltávolítási időszak kezdődik. Ezen eltávolítási időszak alatt a validátor letétje fokozatosan elszivárog. Félidőben (18. nap) további büntetést kap, amelynek nagysága a büntetés előtti 36 napban az összes megbüntetett (slashed) validátor összes letétbe helyezett etherének nagyságával arányos. Ez azt jelenti, hogy ha több validátor kap súlyos büntetést és kizárást, akkor a büntetés mértéke növekszik. A maximális büntetés az összes megbüntetett validátor teljes tényleges egyenlege (ha sok validátor kap súlyos büntetést, akkor elveszíthetik a teljes letétjüket). Másrészt egyetlen, elszigetelt súlyos büntetés a validátor letétjének csak kis részét égeti el. Ezt a középtájt kiszabott extra büntetést, amely a megbüntetett validátorok számával skálázódik, korrelációs büntetésnek nevezzük. - -## Inaktivitási elszivárgás {#inactivity-leak} - -Ha a konszenzusréteg több mint négy korszakot tölt el véglegesítés nélkül, akkor egy „inaktivitási szivárgás” vészhelyzeti protokoll aktiválódik. Az inaktivitási elszivárgás célja, hogy megteremtse a lánc véglegessé válásához szükséges feltételeket. A véglegességhez a teljes feltett ether 2/3-os többsége szükséges ahhoz, hogy a forrás- és célellenőrzési pontok megegyezzenek. Ha a validátorok több mint 1/3-a offline állapotba kerül, vagy nem küld helyes tanúsításokat, akkor nem lehetséges, hogy a 2/3-os szupertöbbség véglegesítse az ellenőrzési pontokat. Az inaktivitási elszivárgás lehetővé teszi, hogy az inaktív validátorok letétje fokozatosan elszivárogjon addig, amíg a hozzájuk tartozó letét 1/3 alá csökkent, így a megmaradt aktív validátorok véglegesíthetik a láncot. Bármilyen nagy is legyen az inaktív validátorok csoportja, a megmaradó aktív validátorok végül a letét >2/3-át birtokolják. A letét elvesztése erősen ösztönzi az inaktív érvényesítőket arra, hogy minél hamarabb újra aktiválódjanak! A Medalla teszthálózaton életbe lépett már az inaktivitási elszivárgás, amikor is az aktív validátorok <66%-a képes volt konszenzusra jutni a blokklánc aktuális fejével kapcsolatban. Az inaktivitási elszivárgás aktiválódott, és a véglegesség végül helyreállt! - -A konszenzusmechanizmus jutalom-, büntetés- és súlyos büntetési konstrukciója arra ösztönzi a validáltorokat, hogy jóhiszeműen viselkedjenek. Ezekből a tervezési döntésekből következik, hogy a rendszer érdekében a validátoroknak egyenlően kell megoszlaniuk a kliens között, és fel kell oldani az egyklienses dominanciát. - -## További olvasnivaló {#further-reading} - -- [Ethereum frissítése: Az ösztönzési réteg](https://eth2book.info/altair/part2/incentives) -- [Ösztönzők az Ethereum hibrid Casper-protokolljában](https://arxiv.org/pdf/1903.04205.pdf) -- [Vitalik jegyzetekkel ellátott specifikációja](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) -- [Eth2 – a súlyos büntetés elkerülésének módjai](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) - -_Források_ - -- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" "b/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" deleted file mode 100644 index 0d73cf8f920..00000000000 --- "a/public/content/translations/hu/16) Foundational Docs \342\200\223 Proof-of-Stake/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md" +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Gyenge szubjektivitás -description: A gyenge szubjektivitásnak és a proof-of-stake Ethereumban elfoglalt szerepének bemutatása. -lang: hu ---- - -A szubjektivitás a blokkláncban arra utal, hogy a jelenlegi státuszról való megegyezés közösségi információkon alapszik. Több érvényes elágazás is létezhet, amelyek közül a hálózati társaktól gyűjtött információk alapján választanak. Ennek ellentéte az objektivitás, amely olyan láncokra vonatkozik, ahol csak egy lehetséges érvényes lánc van, amelyben minden csomópont egyetért a kódolt szabályok alkalmazásával. A harmadik helyzet a gyenge szubjektivitás. Ez egy olyan lánc, amely objektíven haladhat előre, miután bizonyos kezdeti információt közösségileg megszerzett. - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértéséhez tekintse meg a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) alapjairól szóló oldalt. - -## Milyen problémákat old meg a gyenge szubjektivitás? {#problems-ws-solves} - -A szubjektivitás a proof-of-stake blokkláncok velejárója, mivel a helyes lánc kiválasztása több elágazás közül a korábbi szavazatok számolásával történik. Ez számos támadási vektornak teszi ki a blokkláncot, beleértve a hosszú távú támadásokat, amelyek során a láncban nagyon korán részt vevő csomópontok fenntartanak egy alternatív elágazást, amelyet később saját érdekükből kifolyólag kiadnak. Alternatív megoldásként, ha a validátorok 33%-a visszavonja a letétjét, de továbbra is tanúsít és blokkokat állít elő, akkor létrehozhatnak egy alternatív elágazást, amely ütközik a kanonikus lánccal. Az új vagy a hosszú ideje offline csomópontok nem biztos, hogy tudják, hogy ezek a támadó validátorok visszavonták a letétüket, így rávehetik őket, hogy egy helytelen láncot kövessenek. Az Ethereum olyan korlátozásokkal tudja megoldani a támadási vektorokat, amelyek a mechanizmus szubjektív aspektusait, beleértve a bizalmi feltételezéseket is, a minimálisra csökkenti. - -## A gyenge szubjektivitás ellenőrzőpontjai {#ws-checkpoints} - -A gyenge szubjektivitás a proof-of-stake Ethereumban az erre vonatkozó ellenőrzőpontokkal valósul meg. Ezek olyan státuszgyökerek, amelyek a hálózat összes csomópontja szerint a kanonikus láncba tartoznak. Ezek is az „egyetemes igazság” célját szolgálják, mint a genezis blokkok, azzal a különbséggel, hogy nem a genezis pozícióban helyezkednek el a blokkláncban. Az elágazásválasztó-algoritmus bízik abban, hogy az adott ellenőrzőpontban meghatározott blokkláncstátusz helyes, és hogy ettől a ponttól kezdve függetlenül és objektíven ellenőrzi a láncot. Az ellenőrzési pontok adják az adott blokk visszafordíthatóságának korlátját, mivel a gyenge szubjektivitás ellenőrzési pontjai előtti blokkok nem módosíthatók. Ez aláássa a nagy hatótávolságú támadásokat azzal, hogy a mechanizmus érvénytelennek minősíti a nagy hatótávolságú elágazásokat. Azzal, hogy a gyenge szubjektivitás ellenőrzési pontjai közelebb vannak, mint a validátor letétkivételi ideje, az elágazást készítő validátort meg tudja bünteti valamekkora összegig, mielőtt kivehetné a letétet, és így az új belépőket nem tudja eltéríteni a téves elágazásokra. - -## A gyenge szubjektivitás ellenőrzési pontjai és a véglegesített blokkok közötti különbség {#difference-between-ws-and-finalized-blocks} - -Az Ethereum-csomópontok másképp kezelik a véglegesített blokkokat és a gyenge szubjektivitás ellenőrzési pontjait. Ha egy csomópont két egymással versengő véglegesített blokkról szerez tudomást, akkor a kettő között vacilál – nem tudja automatikusan azonosítani, hogy melyik a kanonikus elágazás. Ez a konszenzuskudarc tünete. Ezzel szemben egy csomópont egyszerűen elutasít minden olyan blokkot, amely ütközik a gyenge szubjektivitás ellenőrzési pontjával. A csomópont szempontjából a gyenge szubjektivitás ellenőrzési pontja olyan abszolút igazságot képvisel, amelyet nem lehet aláásni a társaktól jövő információkkal. - -## Mennyire gyenge a gyenge? {#how-weak-is-weak} - -Az Ethereum proof-of-stake szubjektív aspektusa az, hogy a szinkronizáláshoz egy megbízható forrásból származó friss státuszra van szükség (ez a gyenge szubjektivitás ellenőrzési pontja). Annak kockázata, hogy a gyenge szubjektivitás ellenőrzési pontja rossz, nagyon alacsony, mivel több független nyilvános forrással is ellenőrizhetők, mint amilyenek a blokkfelfedezők vagy más csomópontok. Egy szoftver futtatásához azonban szükség van bizonyos fokú bizalomra, például bíznunk kell abban, hogy a fejlesztők tisztességes szoftvert készítettek. - -A gyenge szubjektivitás ellenőrzési pontja a kliensszoftver részeként is megjelenhet. Vitatható, hogy egy támadó megrongálhatja a szoftverben lévő ellenőrzőpontot, és ugyanilyen könnyen magát a szoftvert is. Nincs kriptogazdasági megoldás ennek a problémának a megkerülésére, de a megbízhatatlan fejlesztők hatása az Ethereumban minimálisra csökkenthető azáltal, hogy több független klienscsapat van, amelyek különböző nyelveken készítenek egyenértékű szoftvert, és érdekeltek a tisztességes lánc fenntartásában. A blokkfelfedezők gyenge szubjektivitást ellenőrző pontokat is biztosíthatnak, vagy a kapott ellenőrzési pontokat további forrással is össze lehet vetni. - -Végül, ellenőrzőpontokat lehet kérni más csomópontoktól; például egy másik Ethereum-felhasználó, aki teljes csomópontot futtat, adhat egy ellenőrzőpontot, amelyet a validátorok ellenőrizhetnek a blokkfelfedezőből származó adatokkal. Összességében a gyenge szubjektivitás ellenőrzési pontjának szolgáltatójában való bizalom csak annyira problémás, mint megbízni a kliensfejlesztőkben. A szükséges bizalom alacsony szintű. Fontos megjegyezni, hogy ezek a megfontolások abban a valószínűtlen esetben válnak fontossá, ha a validátorok többsége összeesküvést sző, hogy létrehozza a blokkláncnak egy alternatív elágazását. Bármilyen más körülmények között nem létezik több Ethereum-lánc, amelyek közül választani kellene. - -## További olvasnivaló {#further-reading} - -- [Gyenge szubjektivitás az Eth2-ben](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) -- [Vitalik: Hogyan tanultam meg szeretni a gyenge szubjektivitást](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) -- [Gyenge szubjektivitás (Teku dokumentációk)](https://docs.teku.consensys.net/en/latest/Concepts/Weak-Subjectivity/) -- [0. fázisú gyenge szubjektivitási útmutató](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) -- [A gyenge szubjektivitás elemzése az Ethereum 2.0-n](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" deleted file mode 100644 index f3bf74f01d0..00000000000 --- "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/poa/index.md" +++ /dev/null @@ -1,79 +0,0 @@ ---- -title: Jogosultsági igazolás (proof-of-authority/PoA) -description: A jogosultsági igazolás konszenzusprotokoll bemutatása és az Ethereumban betöltött szerepe. -lang: hu ---- - -**A jogosultsági igazolás (POA)** egy reputációalapú konszenzusalgoritmus, amely a [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) módosított verziója. Főleg privát láncok, teszthálózatok és helyi fejlesztői hálózatok használják. PoA egy olyan reputációalapú konszenzusalgoritmus, amelynél felhatalmazott aláírók egy csoportját bízzák meg a blokkok létrehozásával, nem a PoS-nél ismert letéti alapú mechanizmus szerint végzik. - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértéséhez érdemes áttekinteni a [tranzakciók](/developers/docs/transactions/), [blokkok](/developers/docs/blocks/) és a [konszenzusmechanizmus](/developers/docs/consensus-mechanisms/) oldalakat. - -## Mi az a jogosultsági igazolás (PoA)? {#what-is-poa} - -A jogosultsági igazolás a **[proof-of-stake](/developers/docs/consensus-mechanisms/pos/) (PoS)** módosított változata, ami egy reputációalapú konszenzusalgoritmus, nem pedig letéti alapú mechanizmus, mint a PoS esetében. A kifejezést Gavin Wood használta először 2017-ben, és ez a konszenzusalgoritmus főleg privát láncok, teszthálózatok és helyi fejlesztési hálózatok esetén működik, mely megoldja a PoW esetében szükséges jó minőségű források igényét, illetve a PoS esetében fellépő skálázási gondokat, mivel a csomópontok kis csoportja tárolja a blokkláncot és gyártja a blokkokat. - -A jogosultsági igazolásnál felhatalmazott aláírók csoportját bízzák meg, mely benne van a [genezis blokkban](/glossary/#genesis-block). A jelenlegi felhasználásoknál minden felhatalmazott aláíró ugyanolyan hatalommal és jogosultsággal bír, amikor a lánc konszenzusát meghatározza. A reputációalapú letét mögött az az elképzelés húzódik, hogy a felhatalmazott validátorok jól ismertek mindenki előtt, vegyük az ismerd meg a vevődet (KYC) módszert vagy ha az egyetlen validátor egy jól ismert szervezet - így ha a validátor rosszat tesz, az identitása egyértelműen kiderül. - -A PoA-nak számos implementációja létezik, de a sztenderd Ethereum módja a **clique**, mely az [EIP-225](https://eips.ethereum.org/EIPS/eip-225) fejlesztést vezette be. A clique egy fejlesztőbarát és könnyen bevezethető szabvány, amely mindenféle kliensszinkronizálást támogat. Más implementációk felölelik az [IBFT 2.0](https://besu.hyperledger.org/stable/private-networks/concepts/poa) és az [Aura](https://openethereum.github.io/Chain-specification) módozatokat. - -## Hogyan működik {#how-it-works} - -A PoA esetében a felhatalmazott aláírók csoportja készíti az új blokkokat. Az aláírókat a reputációjuk alapján választják, és csak ők hozhatnak létre blokkot. Az aláírókat körmérkőzéses módon választják, és mindegyik egy adott időszakban hozhat létre blokkot. A blokk létrehozásának ideje rögzített, és ekkor kell az aláíróknak előállítani azt. - -A reputáció ebben a kontextusban nem egy mérhető dolog, hanem a Microsoft és a Google esetében jól ismert módszer, így a kiválasztás se algoritmikus, hanem _bizalomalapú_, ahol az entitás, például a Microsoft, létrehoz egy PoA privát hálózatot startup-ok százai vagy ezrei részvételével, ő maga a megbízott aláíró, aki új aláírókat adhat a rendszerhez, mint például a Google-t, így a startup-ok kétely nélkül bíznak abban, hogy a Microsoft jóhiszeműen jár el és így használja a hálózatot. Ez megoldja a különböző kis/privát hálózatokban való letétek szükségességét, amelyeket különböző célokra építettek, hogy decentralizáltak és működőképesek maradjanak, valamint a bányászok szükségességét, ami sok energiát és erőforrást igényel. Néhány privát hálózat a PoA szabványt használja, mint a VeChain, és néhány módosította azt, mint a Binance, mely [PoSA](https://academy.binance.com/en/glossary/proof-of-staked-authority-posa) verziót használ, ami egy személyre szabott PoA és PoS verzió. - -A szavazási folyamatot az aláírók végzik. Minden aláíró szavaz egy adott aláíró bevétele vagy eltávolítása mellett a saját blokkjában, amikor azt létrehozza. A szavazatokat összegzik a csomópontok, így az aláírók bekerülnek vagy kikerülnek, ha a szavazatok elérik a SIGNER_LIMIT határt. - -Bizonyos esetekben apróbb elágazások történhetnek, a blokk nehézsége azon múlik, hogy soron belül vagy kívül írták alá. A soron belüli blokkok 2-es nehézséggel bírnak, a soron kívüliek 1-essel. A kisebb elágazások esetén az a lánc lesz az összetettebb és ezáltal a nyertes, amely a legtöbb soron belüli aláírót tudja felmutatni. - -## Támadási vektorok {#attack-vectors} - -### Rosszhiszemű aláírók {#malicious-signers} - -Lehetséges, hogy egy rosszhiszemű aláíró kerül be az aláírók listájába, vagy kompromittálódik egy aláírási kulcs/gép. Ilyen helyzetben a protokollnak meg kell védenie magát az átszervezések és a teleszemetelés (spamming) ellen. A javasolt megoldás az, hogy ha van egy N elemű aláírólista, mindegyik aláíró egy blokkot hoz létre minden K-ból. Így a kár korlátozott, a validátorok többi része pedig ki tudja szavazni a rosszhiszemű felhasználót. - -### Cenzúrázás {#censorship-attack} - -Egy másik érdekes támadási vektor, ha egy aláíró (vagy az aláírók egy csoportja) megpróbálja cenzúrázni a blokkokat azáltal, hogy kiszavazza azokat a jóváhagyott listából. Ennek elkerüléséhez az aláírók blokk-készítését 1-re kell korlátozni N/2-ből. Ekkor a rosszhiszemű aláíróknak legalább 51%-nyi aláírószámlát kell kontrollálniuk, és ekkor ők mondják meg mi a lánc új státusza. - -### Szemetelés (spam) {#spam-attack} - -Egy másik kisebb támadási vektor az, amikor a rosszhiszemű aláírók új szavazási javaslatot adnak az általuk készített blokkban. Mivel a csomópontoknak egyesíteni kell a szavazatokat, hogy létrehozzák az felhatalmazott aláírók listáját, így az összes szavazatot rögzíteniük kell. Ha a szavazási ablaknak nincs határa, akkor ez lassan, de a végtelenségig növekedhet. Ennek megoldása az, hogy W blokk kap egy _mozgó_ ablakot, ami után a szavazatok már elévülnek. _Az ablak 1–2 korszak hosszúságú lehetne._ - -### Párhuzamos blokkok {#concurrent-blocks} - -Egy PoA-alapú hálózatban, ha N felhatalmazott aláíró van, minden aláíró K-ból 1 blokkot hozhat létre, ami azt jelenti, hogy N-K+1 validátornak van lehetősége bármely adott időpontban blokkot készíteni. Ahhoz, hogy a validátorok ne versenyezzenek a blokkokért, minden aláírónak egy kis véletlenszerű „elmozdulást” kell adni az időhöz, amikor az új blokkot készíti. Bár ezzel a kisebb elágazások ritkák, de mégis megtörténhetnek, ahogy a főhálózatnál is. Ha egy aláíró visszaél a hatalmával és káoszt csinál, akkor a többi aláíró kiszavazhatja. - -Ha például 10 felhatalmazott aláíró van, és mindegyik készíthet 1 blokkot a 20-ból, akkor bármelyik időben 11 validátor blokkot készíthet. Ahhoz, hogy a validátorok ne versenyezzenek a blokkokért, minden aláírónak egy kis véletlenszerű „elmozdulást” kell adni az időhöz, amikor az új blokkot készíti. Bár ezzel a kisebb elágazások ritkák, de mégis megtörténhetnek, ahogy a főhálózatnál is. Ha egy aláíró visszaél a hatalmával és káoszt csinál, akkor a többi aláíró kiszavazhatja. - -## Előnyök és hátrányok {#pros-and-cons} - -| Előnyök | Hátrányok | -| --------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Sokkal jobban skálázható, mint más népszerű mechanizmusok, mint a PoS és a PoW, és behatárolt blokkaláírón alapszik | A PoA-hálózatok általában kevés validáló csomóponttal működnek. Emiatt a PoA-hálózat sokkal centralizáltabb. | -| A PoA-blokkláncokat rendkívül olcsó futtatni és fenntartani | Az átlagos felhasználó nem válik felhatalmazott aláíróvá, mert a blokklánchoz olyan entitások kellenek, amelyek reputációja jól megalapozott. | -| A tranzakciókat gyorsan konfirmálják, akár 1 másodpercen belül, mert csak korlátozott számú aláíró kell az új blokk validálásához | A rosszhiszemű aláírók képesek átrendezésre, dupla költésre, tranzakciócenzúrára a hálózaton belül, amelyeket lehet mitigálni, de ettől még lehetségesek | - -## További olvasnivaló {#further-reading} - -- [EIP-225](https://eips.ethereum.org/EIPS/eip-225) _Clique szabvány_ -- [A jogosultsági igazolásról készült tanulmány](https://github.com/cryptoeconomics-study/website/blob/master/docs/sync/2.4-lecture.md) _Cryptoeconomics_ -- [Mi az a jogosultsági igazolás](https://forum.openzeppelin.com/t/proof-of-authority/3577) _OpenZeppelin_ -- [A jogosultsági igazolás magyarázata](https://academy.binance.com/en/articles/proof-of-authority-explained) _binance_ -- [PoA a blokkláncban](https://medium.com/techskill-brew/proof-of-authority-or-poa-in-blockchain-part-11-blockchain-series-be15b3321cba) -- [A clique magyarázata](https://medium.com/@Destiner/clique-cross-client-proof-of-authority-algorithm-for-ethereum-8b2a135201d) -- [Elavult PoA, Aura-specifikáció](https://openethereum.github.io/Chain-specification) -- [IBFT 2.0, egy másik PoA-implementáció](https://besu.hyperledger.org/stable/private-networks/concepts/poa) - -### Ön inkább vizuális típus? {#visual-learner} - -Tekintse meg a jogosultsági igazolás vizuális magyarázatát: - - - -## Kapcsolódó témák {#related-topics} - -- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/) -- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/) diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" deleted file mode 100644 index c3db9756ccc..00000000000 --- "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/index.md" +++ /dev/null @@ -1,109 +0,0 @@ ---- -title: Proof-of-work (PoW) -description: A proof-of-work (munkaigazolás) konszenzusprotokoll bemutatása és az Ethereumban betöltött szerepe. -lang: hu ---- - -Az Ethereum-hálózat kezdetben egy olyan konszenzusmechanizmust használt, amely a **[proof-of-work (PoW)](/developers/docs/consensus-mechanisms/pow)** koncepciót használta. Ez lehetővé tette az Ethereum-hálózat csomópontjai számára, hogy az összes Ethereum-blokkláncra feljegyzett információ állapotáról megegyezzenek és kivédjenek bizonyos gazdasági támadásokat. Ugyanakkor az Ethereum 2022-ben leváltotta a proof-of-work mechanizmust, és helyette a [proof-of-stake (letéti igazolás)](/developers/docs/consensus-mechanisms/pos) koncepcióját vezette be. - - - A proof-of-work ezzel kivezetésre került. A konszenzusmechanizmusnak többé nem része a proof-of-work az Ethereumon. Ehelyett a proof-of-stake mechanizmus működik. Tudjon meg többet a proof-of-stake-ről és a letétbe helyezésről. - - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértéséhez érdemes áttekinteni a [tranzakciók](/developers/docs/transactions/), [blokkok](/developers/docs/blocks/) és a [konszenzusmechanizmus](/developers/docs/consensus-mechanisms/) oldalakat. - -## Mi az a proof-of-work (PoW)? {#what-is-pow} - -A Nakamoto konszenzus, amely a proof-of-work (PoW) mechanizmust használja, egykor lehetővé tette a decentralizált Ethereum-hálózat számára, hogy konszenzusra jusson (tehát minden csomópont egyetértsen) olyanok felett, mint a számlaegyenlegek vagy a tranzakciók sorrendje. Ez megakadályozta, hogy a felhasználók „duplán elköltsék” a coinokat és biztosította azt, hogy az Ethereum-láncot hihetetlenül nehéz volt megtámadni vagy átírni. Ezek a biztonsági jellemzők most a proof-of-stake mechanizmusból erednek, amely a [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) nevű konszenzust használja. - -## Proof-of-work és bányászat {#pow-and-mining} - -A proof-of-work a mögöttes algoritmus, amely a nehézséget és a szabályokat határozza meg a munkához, amelyet a bányászok végeznek proof-of-work blokkláncokon. A bányászat maga a „munka”. Érvényes blokkok hozzáadását jelenti a lánchoz. Ez azért fontos, mert a lánc hossza segíti a hálózatot abban, hogy kövesse a blokklánc megfelelő elágazását. Minél több „munka” van elvégezve, annál hosszabb a lánc, és minél magasabb a blokkszám, annál inkább biztosabb lehet a hálózat a dolgok jelenlegi állapotában. - -[Többet a bányászatról](/developers/docs/consensus-mechanisms/pow/mining/) - -## Hogyan működött az Ethereum proof-of-work mechanizmusa? {#how-it-works} - -Az Ethereum-tranzakciókat blokkokba dolgozzák fel. A már kivezetett proof-of-work-alapú Ethereumon minden blokkban volt: - -- blokk nehézsége – például: 3,324,092,183,262,715 -- mixHash-e – például: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` -- nonce-a – például: `0xd3ee432b4fb3d26b` - -Ezek a blokkadatok közvetlen kapcsolatban álltak a proof-of-work mechanizmussal. - -### A munka a proof-of-work-ben {#the-work} - -A proof-of-work protokoll, melyet Ethashnek hívnak, arra ösztönözte a bányászokat, hogy egy intenzív verseny keretében próba szerencse alapon megtalálják a nonce-t egy blokkhoz. Csak érvényes nonce-szal rendelkező blokkokat lehetett hozzáadni a lánchoz. - -Amikor a blokk létrehozásáért versenyeztek, egy adott bányász ismételten betett egy adathalmazt, melyet csak a teljes lánc letöltésével és futtatásával (ahogy a bányászok csinálják) lehetett megszerezni, egy matematikai függvényen keresztül. Az adathalmazt arra használták, hogy készítsenek egy mixHasht, ami a blokk nehézsége által megadott tartományon belül marad. Ezt a legjobban a próba és hiba módszerrel kiszámítani. - -A nehézség határozta meg a hash célját. Minél alacsonyabb a cél, annál kisebb az érvényes hashek halmaza. Amint legenerálta valaki, onnantól már rendkívül egyszerű a többi bányász és kliens számára hitelesíteni. Ha akár egy tranzakciót is megváltoztattak volna, akkor a hash teljesen más lett volna, ami egyértelműen jelzi a csalást. - -A hashing egyszerűvé teszi, hogy észrevegyük a csalásokat. Emellett a proof-of-work folyamata elrettentő erővel bírt a lánc megtámadásával szemben. - -### Proof-of-work és biztonság {#security} - -A bányászokat ösztönözték, hogy elvégezzék ezt a munkát az Ethereum láncon. A bányászok számára nem volt mérvadó az a motiváció, hogy saját láncot indítsanak, és ezzel aláássák a rendszert. A blokkláncok egy állapotra hagyatkoznak az igazság forrásaként. - -A proof-of-work célkitűzése a lánc kiterjesztése volt. A leghosszabb lánc a leghihetőbb érvényes lánc volt, mivel itt végezték el a legtöbb számítási munkát ahhoz, hogy létrehozzák. Az Ethereum proof-of-work rendszerén belül szinte lehetetlen volt olyan új blokkokat létrehozni, melyek korábbi tranzakciókat törölnének ki vagy hamis tranzakciókat tartalmaznának, vagy egy másik láncok építenének. Ennek az az oka, hogy egy rosszindulatú bányásznak mindig gyorsabban kéne megoldania a blokk nonce-ot, mint bárki másnak. - -Ahhoz, hogy valaki konzisztensen rosszindulatú, de mégis érvényes blokkokat hozhasson létre, a hálózat bányászati erejének több mint az 51%-ával rendelkeznie kellett volna. Ez a mennyiségű „munka” rengeteg, drága számítási kapacitást igényel, és az erre költött ráfordítás talán meg is haladja a támadással járó előnyöket. - -### A proof-of-work gazdaságtana {#economics} - -A proof-of-work másik feladata az volt, hogy új coinokat bocsásson ki a rendszerbe és ezzel ösztönözze a bányászokat a munka elvégzésére. - -A [Constantinople-frissítés](/history/#constantinople) után a bányászok, akik sikeresen létrehoztak egy blokkot, két frissen kibocsátott ETH-t kaptak, valamint a tranzakciós díjak egy része is az övék lett. Az ommer blokkokért is járt 1,75 ETH. Az ommerek olyan érvényes blokkok, melyeket ugyanabban az időben készítenek, mint a kanonikus blokkot, ami végül a lánc folytatása lesz. Ezek általában hálózati késedelemkor fordultak elő. - -## Véglegesség {#finality} - -A tranzakció végleges az Ethereumon, amikor egy olyan blokk része, amit már nem lehet megváltoztatni. - -Mivel a bányászok decentralizáltan dolgoztak, lehetséges volt, hogy egyszerre két érvényes blokk jöjjön létre. Ez egy átmeneti elágazást (fork) eredményez. Végül az egyik lánc lett az elfogadott, amint egy későbbi blokkot kibányásztak és hozzáfűztek, ami miatt hosszabbá vált. - -Tovább bonyolította, hogy a tranzakciók, melyek el lettek utasítva az átmeneti elágazásban, nem feltétlenül kerültek be az elfogadott láncba. Ez azt jelentette, hogy vissza lehetett azokat fordítani. A véglegesség tehát arra az időre utal, amennyit a felhasználónak várnia kell, hogy a tranzakciót visszafordíthatatlannak tekintsük. A korábbi proof-of-work-alapú Ethereumon minél több blokkot bányásztak egy adott `N` blokk tetejére, annál inkább meg lehetett bízni abban, hogy az `N` blokk tranzakciói sikeresek és nem lehet azokat visszafordítani. A jelenlegi proof-of-stake rendszerben a véglegesség a blokk kifejezett jellemzője, nem annyira valószínűségi. - -## A proof-of-work energiafelhasználása {#energy} - -A proof-of-work egyik legnagyobb hibája az energiamennyiség volt, melyet a hálózat biztonságosságáért el kellett fogyasztani. Az Ethereum proof-of-work rendszere sok energiát igényelt ahhoz, hogy biztonságos és decentralizált legyen. Röviddel a proof-of-stake-re való áttérés előtt az Ethereum-bányászok együttesen kb. 70 TWh/év energiát fogyasztottak (akár a Cseh Köztársaság a [digiconomist](https://digiconomist.net/) szerint, melyet 2022. július 18-án publikáltak). - -## Előnyök és hátrányok {#pros-and-cons} - -| Előnyök | Hátrányok | -| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| A proof-of-work egy semleges rendszer. Nincs szükség ETH-re, hogy valaki elkezdje, és a blokk jutalmaknak köszönhetően 0 ETH-ről pozitívba mehet át az egyenlege. A [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) esetében ETH-re van szükség, hogy valaki belekezdjen. | A proof-of-work sok energiát használ fel, ami káros a környezetnek. | -| A proof-of-work egy kipróbált és letesztelt konszenzusos mechanizmus, amely éveken keresztül biztonságban és decentralizáltan tartotta a Bitcoint és az Ethereumot. | Ha valaki bányászni szeretne, akkor speciális felszerelésre van szüksége, mely kezdetnek nagy befektetés. | -| A proof-of-stake-kel szemben viszonylag egyszerűbb implementálni. | A folyamatosan növekvő számítási igény miatt, a bányászati alapok potenciálisan dominálhatják a bányászvilágot, mely centralizációhoz és biztonsági kockázatokhoz vezet. | - -## Összehasonlítás a proof-of-stake megoldással {#compared-to-pos} - -Nagy vonalakban a proof-of-stake-nek ugyanaz a végcélja, mint a proof-of-work-nek: biztonságosan segítse elérni a konszenzust a decentralizált hálózaton. De van egy pár különbség a folyamatban és a személyekben: - -- A proof-of-stake leváltja a számítási kapacitás fontosságát a letétbe helyezett ETH-re. -- A proof-of-stake lecseréli a bányászokat validátorokra. A validátorok letétbe helyezik az ETH-jüket, hogy aktiválják a képességüket új blokkok létrehozására. -- A validátorok nem versenyeznek a blokk létrehozásért, ehelyett egy algoritmus választja ki őket véletlenszerűen. -- A véglegesség tisztább: ha bizonyos ellenőrzési pontokon a validátorok 2/3 része egyetért a blokk állapotát illetően, akkor a blokkot véglegesnek tekintjük. A validátorok a tejles letétüket felteszik erre, így ha megpróbálnak összejátszani, akkor a teljes letétüket elveszítik. - -[A proof-of-stake-ről bővebben](/developers/docs/consensus-mechanisms/pos/) - -## Ön inkább vizuális típus? {#visual-learner} - - - -## További olvasnivaló {#further-reading} - -- [Többségi támadás](https://en.bitcoin.it/wiki/Majority_attack) -- [Az elszámolási véglegességről](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) - -### Videók {#videos} - -- [A proof-of-work protokollok technikai magyarázata](https://youtu.be/9V1bipPkCTU) - -## Kapcsolódó témák {#related-topics} - -- [Bányászat](/developers/docs/consensus-mechanisms/pow/mining/) -- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/) -- [Proof-of-authority (jogosultsági igazolás)](/developers/docs/consensus-mechanisms/poa/) diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" deleted file mode 100644 index dfbe113cc15..00000000000 --- "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/index.md" +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Bányászat -description: Áttekintés – hogyan működött a bányászat az Ethereumon. -lang: hu ---- - - -A proof-of-work (munkaigazolás) már nem az Ethereum konszenzusmechanizmus alapja, tehát a bányászatot kikapcsolták. Ehelyett az Ethereumot úgy biztosítják a validátorok, hogy letétbe helyeznek ETH-t. Ön is letétbe helyezheti a rendelkezésére álló ETH-t. Tudjon meg többet a egyesítés (Merge), proof-of-stake (letéti igazolás) és letétbe helyezés témákról. Ez az oldal csak elavult témákat tartalmaz. - - -## Előfeltételek {#prerequisites} - -Javasoljuk, hogy olvassa el a [tranzakciók](/developers/docs/transactions/), [blokkok](/developers/docs/blocks/) és a [proof-of-work](/developers/docs/consensus-mechanisms/pow/) oldalakat is. - -## Mi az az Ethereum bányászat? {#what-is-ethereum-mining} - -A bányászat az a tevékenység, amikor tranzakciókból álló blokkokat hoznak létre, hogy azokat hozzáadják az Ethereum-blokklánchoz abban a proof-of-work architektúrában, melyet már kivezettek az Ethereumból. - -A bányászat kifejezés a kriptovaluták aranyhoz hasonló kinyerésére vonatkozott. Az arany vagy más nemesfémek ritkák, ahogy a digitális tokenek is, ezért a mennyiséget egy proof-of-work-alapú rendszerben a bányászattal lehetett növelni. A proof-of-work-alapú Ethereumban a kibocsátás egyetlen módja a bányászat volt. Az arany és más bányászatához képest ugyanakkor az Ethereumban ez volt a hálózat biztosításának módja a blokkláncba létrehozott, ellenőrzött, publikált és elterjesztett blokkok révén. - -Ether bányászata = A hálózat biztosítása - -A bányászat a proof-of-work blokkláncok lényege. Az Ethereum-bányászok – szoftvert futtató számítógépek – az idejüket és számítási kapacitásukat fordították a tranzakciók feldolgozására és blokkok létrehozására a proof-of-stake mechanizmus bevezetése előtt. - -## Miért léteznek a bányászok? {#why-do-miners-exist} - -Az Ethereumhoz hasonló decentralizált rendszerek esetében biztosítanunk kell, hogy mindenki egyetért a tranzakciók sorrendjében. A bányászok segítettek, hogy ez megtörténjen úgy, hogy számítás szempontjából nehéz rejtvényeket oldottak meg azért, hogy blokkokat hozhassanak létre, amely így megvédte a hálózatot a támadásoktól. - -[Bővebben a proof-of-work mechanizmusról](/developers/docs/consensus-mechanisms/pow/) - -Korábban bárki bányászhatott az Ethereum hálózaton a számítógépét használva. Ugyanakkor nem mindenkit tudott nyereségesen bányászni ethert (ETH). A legtöbb esetben a bányászoknak dedikált számítógépes hardvereket kellett szerezniük, és hozzá kellett férniük az energiaforrásokhoz. Egy átlagos számítógép nem valószínű, hogy elég blokkjutalmat tudott szerezni, hogy fedezze a bányászat költségeit. - -### A bányászat költsége {#cost-of-mining} - -- Annak a hardvernek a valószínű költsége, mely a bányászati eszköz felépítéséhez és fenntartásához szükséges -- A bányászati eszközt működtető elektromosság költsége -- Ha egy bányászati alapban vett részt valaki, akkor az alap általában egy %-os általánydíjat számolt fel minden létrehozott blokk után -- A bányászati eszköz támogatásához szükséges dolgok költségei (szellőztető, energiamonitorozás, elektromos vezetékek stb.) - -A bányászat nyereségességét olyan bányászati kalkulátor segítségével ellenőrizheti, mint amilyen az [Etherscan](https://etherscan.io/ether-mining-calculator) oldalon is található. - -## Hogyan bányászták ki az Ethereum-tranzakciókat {#how-ethereum-transactions-were-mined} - -A következőkben a tranzakciók bányászatáról olvashat egy áttekintés az Ethereum proof-of-work mechanizmusa idejéből. Az Ethereum proof-of-stake mechanizmusára vonatkozó leírást [itt](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) találja. - -1. A felhasználó létrehoz és aláír egy [tranzakciós](/developers/docs/transactions/) kérvényt valamely [számla](/developers/docs/accounts/) privát kulcsával. -2. A felhasználó közvetíti a tranzakciós kérelmet a teljes hálózat számára valamilyen [csomópontról](/developers/docs/nodes-and-clients/). -3. Amint tudomást szereznek a tranzakció kérvényről, az Ethereum hálózat valamennyi csomópontja hozzáadja a kérvényt a lokális mempooljához, ami azokat a tranzakciós kérvényeket tartalmazza, amikről már tudomást szereztek, de még nem adták hozzá a blokklánchoz egy blokkban. -4. Egy bizonyos ponton egy bányászcsomópont több tucat vagy több száz tranzakciós kérvényt összesít egy potenciális [blokkba](/developers/docs/blocks/) úgy, hogy a begyűjtött [tranzakciós díj](/developers/docs/gas/) maximális legyen, de ne lépje túl a blokk gázkorlátozását. Ezután a bányász csomópont: - 1. Ellenőrzi az egyes tranzakciós kérelmek érvényességét (azaz senki nem próbál ethert átutalni olyan számláról, amelyhez nem készített aláírást, a kérés nem hibás, stb.), majd végrehajtja a kérés kódját, megváltoztatva az EVM helyi másolatának állapotát. A bányász a tranzakciós díjat minden ilyen tranzakciós kérvényért a saját számlájára teszi. - 2. Elindítja a proof-of-work “megbízhatósági bizonyítvány” előállításának folyamatát a potenciális blokkra, amint az összes tranzakciós kérelmet érvényesítette és végrehajtotta a helyi EVM másolaton. -5. Végül egy bányász befejezi a bizonyítvány elkészítését egy blokkra, mely tartalmazza a mi specifikus tranzakciós kérelmünket. A bányász ezután közvetíti a kész blokkot, mely tartalmazza a bizonyítványt és az ellenőrző összeget az új, kiállított EVM állapotról. -6. A többi csomópont is tudomást szerez a blokkról. Érvényesítik a bizonyítványt, saját maguk is végrehajtják a blokk összes tranzakcióját (beleértve azt is, amit eredetileg a felhasználónk közvetített), és megbizonyosodnak arról, hogy az új tranzakciók végrehajtása utáni EVM állapotuk ellenőrző összege megegyezik a bányász által kiállított blokk állapotának összegével. Csak ezután fűzik hozzá ezek a csomópontok ezt a blokkot a blokkláncuk végére, és fogadják el az új EVM állapotot, mint kanonikus új állapot. -7. Minden csomópont eltávolítja az új blokkban lévő összes tranzakciót a teljesítetlen tranzakciós kérvényeket tartalmazó helyi mempooljából. -8. A hálózatba újonnan becsatlakozó csomópontok letöltik az összes blokkot a sorrendet betartva, beleértve azt a blokkot is, mely a szóban forgó tranzakciónkat tartalmazza. Inicializálnak egy helyi EVM másolatot (mely egy üres állapotú EVM-ként indul), ezután végig mennek az összes blokkban található összes tranzakció végrehajtásának folyamatán a helyi EVM másolatukon, miközben érvényesítik a blokkok állapotainak ellenőrző összegeit. - -Minden tranzakciót egyszer bányásznak ki (blokkba foglalják és első alkalommal közvetítik), de minden résztvevő végrehajtja és érvényesíti azokat a kanonikus EVM-állapot előrevitelének folyamatában. Ez kiemeli a blokklánc egyik központi mantráját: **Nem kell megbíznia senkiben. Csak ellenőrizni.**. - -## Ommer (nagybácsi) blokkok {#ommer-blocks} - -A proof-of-work mechanizmusban végzett blokkbányászat valószínűségen alapult, tehát néha a hálózati késedelem miatt két érvényes blokkot is publikáltak egyszerre. Ebben az esetben a protokoll kiválasztotta a leghosszabb láncot (amelyik érvényesebb volt), miközben díjazta azt a bányászt is egy részleges jutalommal, akinek nem került be a javasolt blokkja. Ez bátorította a hálózat decentralizációját, mert a kisebb bányászok, akiknél nagyobb volt a csúszás, még mindig tudtak nyereséget szerezni az [ommer](/glossary/#ommer) blokkok jutalmából. - -Az „ommer” kifejezés a szülőblokk testvérblokkjának semleges formája, de néha nagybácsi/uncle formában is hivatkoznak rá. **Mióta az Ethereum átállt a proof-of-stake mechanizmusra, többé nincsenek ommer blokkok**, mivel csak egy előterjesztő van minden slotban. Ezt a változást megtekintheti a kibányászott ommer blokkok [előzményábráján](https://ycharts.com/indicators/ethereum_uncle_rate) is. - -## Egy vizuális bemutató {#a-visual-demo} - -Tekintse meg, ahogy Austin elmagyarázza a bányászatot és a proof-of-work blokkláncot. - - - -## A bányászati algoritmus {#mining-algorithm} - -Az Ethereum főhálózat csak egy bányászati algoritmust használt, az [Ethash-t](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Az Ethash a [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) néven ismert R&D algoritmus utódja volt. - -[Bővebben a bányászati algoritmusokról](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). - -## Kapcsolódó témák {#related-topics} - -- [Gáz](/developers/docs/gas/) -- [EVM](/developers/docs/evm/) -- [Proof-of-work](/developers/docs/consensus-mechanisms/pow/) diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" deleted file mode 100644 index 112d79e5d00..00000000000 --- "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md" +++ /dev/null @@ -1,334 +0,0 @@ ---- -title: Dagger-Hashimoto -description: A Dagger-Hashimoto algoritmus részletes áttekintése. -lang: hu ---- - -A Dagger-Hashimoto volt az Ethereum bányászati algoritmusának eredeti fejlesztési implementációja és specifikációja. A Dagger-Hashimoto algoritmust az [Ethash](#ethash) váltotta le. A bányászatot teljesen kikapcsolták az [egyesítés (Merge)](/roadmap/merge/) frissítés életbe lépésekor, 2022. szeptember 15-én. Azóta az Ethereumot a [proof-of-stake (letéti igazolás)](/developers/docs/consensus-mechanisms/pos) mechanizmusa biztosítja. Ez az oldal elavult témákat tartalmaz, amelyek többé már nem relevánsak az egyesítés (Merge) utáni Ethereummal kapcsolatban. - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértéséhez javasoljuk, hogy tekintse meg a [proof-of-work konszenzus](/developers/docs/consensus-mechanisms/pow), a [bányászat](/developers/docs/consensus-mechanisms/pow/mining), és a [bányászati algoritmusok](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) témáit. - -## Dagger-Hashimoto {#dagger-hashimoto} - -A Dagger-Hashimoto két célt szolgál: - -1. **ASIC-ellenálló**: az algoritmus futtatásához a specializált hardver kialakításából adódó előny a lehető legkisebb legyen -2. **Könnyű kliens általi ellenőrizhetőség**: a blokkot egy könnyű kliens is le tudja ellenőrizni hatékonyan. - -Egy újabb módosítással meghatározhatjuk, hogyan tud egy harmadik célt is kielégíteni, de ez a komplexitás növekedésével jár: - -**A teljes lánc tárolása**: a bányászathoz a teljes blokklánc státuszát le kell tárolni (az Ethereum státuszfa szabálytalan struktúrája miatt talán lehetséges ennek megrövidítése, főleg a gyakori szerződéseknél, de ezt minimalizálni szeretnénk). - -## DAG létrehozása {#dag-generation} - -Az algoritmus kódját pythonban alább találja. Először az `encode_int` kódot adjuk meg, hogy a megadott pontosságú nem aláírt egész számokat sztringekké alakítsa. Ennek fordítottja is megadásra kerül: - -```python -NUM_BITS = 512 - -def encode_int(x): - "Encode an integer x as a string of 64 characters using a big-endian scheme" - o = '' - for _ in range(NUM_BITS / 8): - o = chr(x % 256) + o - x //= 256 - return o - -def decode_int(s): - "Unencode an integer x from a string using a big-endian scheme" - x = 0 - for c in s: - x *= 256 - x += ord(c) - return x -``` - -Ezután, feltételezve, hogy az `sha3` egy olyan függvény, ami egész számot kap és azt is ad ki eredményként, továbbá a `dbl_sha3` egy dupla sha3 függvény; ha ezt a referenciakódot implementációvá alakítjuk: - -```python -from pyethereum import utils -def sha3(x): - if isinstance(x, (int, long)): - x = encode_int(x) - return decode_int(utils.sha3(x)) - -def dbl_sha3(x): - if isinstance(x, (int, long)): - x = encode_int(x) - return decode_int(utils.sha3(utils.sha3(x))) -``` - -### Paraméterek {#parameters} - -Az algoritmushoz a következő paramétereket használjuk: - -```python -SAFE_PRIME_512 = 2**512 - 38117 # Largest Safe Prime less than 2**512 - -params = { - "n": 4000055296 * 8 // NUM_BITS, # Size of the dataset (4 Gigabytes); MUST BE MULTIPLE OF 65536 - "n_inc": 65536, # Increment in value of n per period; MUST BE MULTIPLE OF 65536 - # with epochtime=20000 gives 882 MB growth per year - "cache_size": 2500, # Size of the light client's cache (can be chosen by light - # client; not part of the algo spec) - "diff": 2**14, # Difficulty (adjusted during block evaluation) - "epochtime": 100000, # Length of an epoch in blocks (how often the dataset is updated) - "k": 1, # Number of parents of a node - "w": w, # Used for modular exponentiation hashing - "accesses": 200, # Number of dataset accesses during hashimoto - "P": SAFE_PRIME_512 # Safe Prime for hashing and random number generation -} -``` - -A `P` ebben az esetben egy olyan prímszám, hogy a `log₂(P)` éppen csak kisebb legyen, mint 512, ami az 512 bithez kapcsolódik, amit a számok reprezentálására használunk. Érdemes megjegyezni, hogy a DAG-nek csak a második felét kell eltárolni, így a RAM-igény 1 GB-tól indul és 441 MB-tal növekszik évente. - -### Dagger-gráfépítés {#dagger-graph-building} - -A dagger-gráfépítési függvényt a következőképpen definiáljuk: - -```python -def produce_dag(params, seed, length): - P = params["P"] - picker = init = pow(sha3(seed), params["w"], P) - o = [init] - for i in range(1, length): - x = picker = (picker * init) % P - for _ in range(params["k"]): - x ^= o[x % i] - o.append(pow(x, params["w"], P)) - return o -``` - -Lényegében a gráfot egy egyszerű csomópontként kezdi (`sha3(seed)`), és innen ad hozzá szekvenciálisan újabb csomópontokat a véletlenszerű előzők csomópontok alapján. Egy új csomópont létrehozásakor a mag moduláris hatványát kiszámítjuk, hogy véletlenszerűen kiválasszunk néhány `i`-nél kisebb indexet (a fenti `x % i` használatával), és az ezeknél az indexeknél lévő csomópontok értékeit egy számításban felhasználjuk az `x` új értékének létrehozásához, amelyet aztán egy kis (XOR-alapú) proof-of-work függvénybe táplálunk, hogy végül az `i` indexnél lévő gráf értékét generáljuk. E sajátos kialakítás értelme az, hogy a DAG-hoz szekvenciális hozzáférést biztosítson; a DAG következő értékét nem lehet meghatározni addig, amíg a jelenlegi nem ismert. Végül a moduláris exponenciálás hasheli tovább az eredményt. - -Ez az algoritmus a számelmélet számos eredményén alapszik. Az alábbi függelékben megtalálhatja az erről szóló beszélgetést. - -## Könnyű kliens általi értékelés {#light-client-evaluation} - -Ez a gráfkonstrukció arra való, hogy a gráf minden csomópontja újraépíthető legyen egy kis számú csomópontból álló alfa segítségével, és csak kevés kiegészítő memória kelljen hozzá. Vegye figyelembe, hogy ha k=1, akkor az alfastruktúra csak az értékek egy olyan lánca, ami a DAG első eleméig tart. - -A DAG-re a következőképpen működik a könnyű kliens számítási függvénye: - -```python -def quick_calc(params, seed, p): - w, P = params["w"], params["P"] - cache = {} - - def quick_calc_cached(p): - if p in cache: - pass - elif p == 0: - cache[p] = pow(sha3(seed), w, P) - else: - x = pow(sha3(seed), (p + 1) * w, P) - for _ in range(params["k"]): - x ^= quick_calc_cached(x % p) - cache[p] = pow(x, w, P) - return cache[p] - - return quick_calc_cached(p) -``` - -Lényegében ez a fenti algoritmus átirata, ami kiveszi a teljes DAG számítási ciklusát, és a korábbi csomópontkereső függvényt cseréli le egy rekurzív hívásra vagy egy cache-keresőre. Érdemes megjegyezni, hogy `k=1` esetén a cache szükségtelen, bár egy további optimalizálással a DAG első néhány ezer értékét előre kiszámítja, és statikus cache-ként tárolja a számításokhoz; ennek kódmegvalósítását tekintse meg a függelékben. - -## A DAG-ek dupla puffere {#double-buffer} - -Egy teljes kliensben 2 DAG [_dupla pufferét_](https://wikipedia.org/wiki/Multiple_buffering) használják, melyet a fenti képlet ad meg. Az elképzelés szerint a DAG-eket minden `epochtime` (korszakban) blokkszámonként készítik a fenti paramétereknek megfelelően. Ahelyett, hogy a kliens a legutóbbi DAG-et használná, az eggyel korábbit veszi figyelembe. Ennek előnye az, hogy a DAG-eket le lehet cserélni idővel anélkül, hogy a bányászoknak hirtelen az összes adatot újra kellene számolniuk. Máskülönben felmerül egy hirtelen, átmeneti lelassulás esélye a láncfeldolgozásnak, ami drasztikusan növeli a centralizációt. Így megnő az 51%-os támadás kockázata is az adat újraszámítása előtti percekben. - -A blokkhoz szükséges munka kiszámításához használt DAG-ek halmazának létrehozására használt algoritmus a következő: - -```python -def get_prevhash(n): - from pyethereum.blocks import GENESIS_PREVHASH - from pyethereum import chain_manager - if n <= 0: - return hash_to_int(GENESIS_PREVHASH) - else: - prevhash = chain_manager.index.get_block_by_number(n - 1) - return decode_int(prevhash) - -def get_seedset(params, block): - seedset = {} - seedset["back_number"] = block.number - (block.number % params["epochtime"]) - seedset["back_hash"] = get_prevhash(seedset["back_number"]) - seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) - seedset["front_hash"] = get_prevhash(seedset["front_number"]) - return seedset - -def get_dagsize(params, block): - return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] - -def get_daggerset(params, block): - dagsz = get_dagsize(params, block) - seedset = get_seedset(params, block) - if seedset["front_hash"] <= 0: - # No back buffer is possible, just make front buffer - return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), - "block_number": 0}} - else: - return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), - "block_number": seedset["front_number"]}, - "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), - "block_number": seedset["back_number"]}} -``` - -## Hashimoto {#hashimoto} - -Az eredeti Hashimoto lényege, hogy a blokkláncot adathalmazként használja, és olyan számítást végez, amely kiválaszt N indexet a blokkláncból, összegyűjti a tranzakciókat ezeken az indexeken, elvégzi a XOR-t ezekre az adatokra, és visszaadja az eredmény hashét. Thaddeus Dryja eredeti algoritmusa, Pythonra átfordítva a konzisztencia érdekében, így néz ki: - -```python -def orig_hashimoto(prev_hash, merkle_root, list_of_transactions, nonce): - hash_output_A = sha256(prev_hash + merkle_root + nonce) - txid_mix = 0 - for i in range(64): - shifted_A = hash_output_A >> i - transaction = shifted_A % len(list_of_transactions) - txid_mix ^= list_of_transactions[transaction] << i - return txid_mix ^ (nonce << 192) -``` - -Sajnálatos módon, miközben a Hashimoto nagy RAM-igényű, 256 bites aritmetikán alapszik, ami jelentős számítási többletköltséggel jár. Ugyanakkor a Dagger-Hashimoto csak a legkevésbé szignifikáns 64 bitet használja az adathalmaz indexálására, hogy ezt a problémát kezelje. - -```python -def hashimoto(dag, dagsize, params, header, nonce): - m = dagsize / 2 - mix = sha3(encode_int(nonce) + header) - for _ in range(params["accesses"]): - mix ^= dag[m + (mix % 2**64) % m] - return dbl_sha3(mix) -``` - -A dupla SHA3 használata lehetővé teszi a nulla adatot tartalmazó, szinte azonnali előzetes ellenőrzést, amely csak azt ellenőrzi, hogy a helyes közbenső értéket adták meg. A proof-of-worknek ez a külső rétege rendkívül ASIC-barát és meglehetősen gyenge, de azért létezik, hogy még nehezebbé tegye a DDoS-t, mivel ezt a kis mennyiségű munkát kell elvégezni ahhoz, hogy egy olyan blokkot hozzanak létre, amelyet nem utasítanak el azonnal. Ez a könnyű kliens verziója: - -```python -def quick_hashimoto(seed, dagsize, params, header, nonce): - m = dagsize // 2 - mix = sha3(nonce + header) - for _ in range(params["accesses"]): - mix ^= quick_calc(params, seed, m + (mix % 2**64) % m) - return dbl_sha3(mix) -``` - -## Bányászat és ellenőrzés {#mining-and-verifying} - -Most vezessük be mindezt a bányászati algoritmusba: - -```python -def mine(daggerset, params, block): - from random import randint - nonce = randint(0, 2**64) - while 1: - result = hashimoto(daggerset, get_dagsize(params, block), - params, decode_int(block.prevhash), nonce) - if result * params["diff"] < 2**256: - break - nonce += 1 - if nonce >= 2**64: - nonce = 0 - return nonce -``` - -Ez az ellenőrzési algoritmus: - -```python -def verify(daggerset, params, block, nonce): - result = hashimoto(daggerset, get_dagsize(params, block), - params, decode_int(block.prevhash), nonce) - return result * params["diff"] < 2**256 -``` - -Ez a könnyű kliens általi barátságos ellenőrzés: - -```python -def light_verify(params, header, nonce): - seedset = get_seedset(params, block) - result = quick_hashimoto(seedset["front_hash"], get_dagsize(params, block), - params, decode_int(block.prevhash), nonce) - return result * params["diff"] < 2**256 -``` - -Emellett érdemes megjegyezni, hogy a Dagger-Hashimoto a blokkfejlécre egyéb követelményeket is megfogalmazott: - -- A kétszintű ellenőrzéshez a blokkfejlécnek tartalmaznia kell a nonce-t és az sha3 előtti köztes értéket -- Valahol a blokkfejlécnek tárolnia kell a jelenlegi seed-halmaz sha3-ját - -## További olvasnivaló {#further-reading} - -_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ - -## Függelék {#appendix} - -Mint fentebb említettük, a DAG generálásához használt RNG a számelmélet néhány eredményére támaszkodik. Először is biztosítjuk, hogy a `picker` változó alapjául szolgáló Lehmer RNG széles periódussal rendelkezik. Másodszor, megmutatjuk, hogy a `pow(x,3,P)` nem fogja `x` kódot `1` vagy `P-1` értékre leképezni, feltéve, hogy `x ∈ [2,P-2]`. Végül megmutatjuk, hogy a `pow(x,3,P)` alacsony ütközési rátával rendelkezik, ha hash függvényként kezeljük. - -### Lehmer véletlenszám-generátor {#lehmer-random-number} - -Bár a `produce_dag` függvénynek nem kell torzítatlan véletlen számokat produkálnia, és potenciális veszélyt jelent, hogy a `seed**i % P` csak néhány értéket vesz fel. Ez előnyt jelenthet azoknak a bányászoknak, akik felismerik a mintát, miközben mások nem. - -Ennek elkerülése érdekében egy számelméleti eredményre hivatkozunk. A [_biztonságos prímszám_](https://en.wikipedia.org/wiki/Safe_prime) egy olyan prím `P`, amelynél a `(P-1)/2` szintén prímszám. A [multiplikatív csoport](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) egy `x` tagjának _rendje_ a `ℤ/nℤ` meghatározása szerint a minimális `m` úgy, hogy 
xᵐ mod P ≡ 1
-Ezen definíciók szerint: - -> 1. megfigyelés. Legyen `x` a `ℤ/Pℤ` multiplikatív csoport tagja egy biztonságos `P` prímszámhoz. Ha `x mod P ≠ 1 mod P` és `x mod P ≠ P-1 mod P`, akkor `x` rendje vagy `P-1` vagy `(P-1)/2`. - -_Bizonyítás_. Mivel `P` egy biztonságos prímszám, akkor a \[Lagrange-tétel\]\[lagrange\] alapján azt kell mondanunk, hogy `x` rendje vagy `1`, `2`, `(P-1)/2` vagy `P-1`. - -A `x` sorrendje nem lehet `1` Fermat kis tételéből következően: - -
xP-1 mod P ≡ 1
- -Ezért `x` a `ℤ/nℤ` multiplikatív azonosságának kell lennie, ami egyedi. Mivel feltételezésünk szerint `x ≠ 1`, ez nem lehetséges. - -Az `x` sorrendje nem lehet `2`, kivéve, ha `x = P-1`, mivel ez sértené, hogy `P` prímszám. - -A fenti tételből felismerhetjük, hogy a `(picker * init) % P` ismétlése legalább `(P-1)/2` ciklushosszúságú lesz. Ennek az az oka, hogy a `P` értékének egy biztonságos prímszámot választottunk, amely megközelítőleg egyenlő a kettő nagyobb hatványával, és `init` a `[2,2**256+1]` intervallumban van. A `P` nagyságát tekintve a moduláris exponenciálástól nem várhatunk ciklust. - -A DAG első cellájának (az `init` feliratú változó) hozzárendelésekor kiszámítjuk a `pow(sha3(seed) + 2, 3, P)` értékét. Első pillantásra ez nem garantálja, hogy az eredmény nem `1` és nem `P-1`. Mivel azonban `P-1` egy biztonságos prímszám, a következő további bizonyosságunk van, amely az 1. megfigyelés következménye: - -> 2. megfigyelés. Legyen `x` a `ℤ/Pℤ` multiplikatív csoport tagja egy biztonságos `P` prímszámhoz, és legyen `w` egy természetes szám. Ha `x mod P ≠ 1 mod P` és `x mod P ≠ P-1 mod P`, valamint `w mod P ≠ P-1 mod P` és `w mod P ≠ 0 mod P`, akkor `xʷ mod P ≠ 1 mod P` és `xʷ mod P ≠ P-1 mod P` - -### Moduláris exponenciálás hashfüggvényként {#modular-exponentiation} - -A `P` és `w` bizonyos értékei esetén a `pow(x, w, P)` függvénynek sok ütközése lehet. Például a `pow(x,9,19)` csak `{1,18}` értékeket vesz fel. - -Adott, hogy `P` prímszám, akkor egy megfelelő `w` moduláris exponenciálási hashfüggvényhez a következő eredmény segítségével választható ki: - -> 3. megfigyelés. Legyen `P` egy prímszám; `w` és `P-1` akkor, és csak akkor relatív prímszámok, ha minden `a` és `b` esetén `ℤ/Pℤ`: -> ->
-> `aʷ mod P ≡ bʷ mod P`, ha és csak ha `a mod P ≡ b mod P` ->
- -Így, feltéve, hogy `P` prím és `w` relatíve prím `P-1`-hez, akkor `|{pow(x, w, P) : x ∈ ℤ}| = P`, ami azt jelenti, hogy a hashfüggvény a lehető legkisebb ütközési rátával rendelkezik. - -Abban a speciális esetben, ha `P` egy biztonságos prímszám, ahogyan azt választottuk, akkor `P-1` csak 1, 2, `(P-1)/2` és `P-1` faktorokkal rendelkezik. Mivel `P` > 7, tudjuk, hogy 3 relatív prím a `P-1`-hez, ezért `w=3` kielégíti a fenti tételt. - -## Hatékonyabb cache-alapú kiértékelő algoritmus {#cache-based-evaluation} - -```python -def quick_calc(params, seed, p): - cache = produce_dag(params, seed, params["cache_size"]) - return quick_calc_cached(cache, params, p) - -def quick_calc_cached(cache, params, p): - P = params["P"] - if p < len(cache): - return cache[p] - else: - x = pow(cache[0], p + 1, P) - for _ in range(params["k"]): - x ^= quick_calc_cached(cache, params, x % p) - return pow(x, params["w"], P) - -def quick_hashimoto(seed, dagsize, params, header, nonce): - cache = produce_dag(params, seed, params["cache_size"]) - return quick_hashimoto_cached(cache, dagsize, params, header, nonce) - -def quick_hashimoto_cached(cache, dagsize, params, header, nonce): - m = dagsize // 2 - mask = 2**64 - 1 - mix = sha3(encode_int(nonce) + header) - for _ in range(params["accesses"]): - mix ^= quick_calc_cached(cache, params, m + (mix & mask) % m) - return dbl_sha3(mix) -``` diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" deleted file mode 100644 index 93bb55dcc10..00000000000 --- "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md" +++ /dev/null @@ -1,1014 +0,0 @@ ---- -title: Ethash -description: Az Ethash algoritmus részletes bemutatása. -lang: hu ---- - - - Az Ethash volt az Ethereum proof-of-work (munkaigazolás) bányászati algoritmusa. A proof-of-work jelenleg **teljesen ki van kapcsolva**, az Ethereumot pedig a proof-of-stake mechanizmus biztosítja. Tudjon meg többet az egyesítés (Merge), proof-of-stake (letéti igazolás) és letétbe helyezés témákról. Ez az oldal elavult témákat tartalmaz! - - -Az [Ethash](https://github.com/ethereum/wiki/wiki/Ethash) a [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) algoritmus módosított változata. Az Ethash proof-of-work egy [ memóriaigényes (memory hard)](https://wikipedia.org/wiki/Memory-hard_function) működés, ami miatt ez az algoritmus ASIC-ellenálló. Az Ethash ASIC-t végül kifejlesztették, de a GPU-bányászat még mindig működő opció volt addig, amíg a proof-of-work metódust ki nem kapcsolták. Az Ethasht még használják más érmék bányászatánál, nem Ethereumon és nem proof-of-work hálózatokon. - -## Hogyan működik az Ethash? {#how-does-ethash-work} - -A memóriaigényt (memory hardness) egy proof-of-work algoritmussal lehet elérni, amelynek egy rögzített erőforrás részhalmazait kell kiválasztania a nonce és a blokkfejléc alapján. Ezt az erőforrást (ami néhány gigabájt nagyságú) DAG-nek (irányított aciklikus gráf/Directed Acyclic Graph) nevezik. A DAG minden 30 000. blokknál megváltozik, ami nagyjából 125 órás időtartamnak felel meg – ezt korszaknak nevezik (kb. 5,2 nap) és időbe telik, amíg létrejön. Mivel a DAG csak a blokk magasságán múlik, ezért előre el lehet készíteni, de ha nincs, akkor a kliensnek meg kell várnia a folyamat végét ahhoz, hogy blokkot készítsen. Ha a kliensek nem hozzák létre és cache-elik a DAG-eket korábban, akkor a hálózat komoly blokk-késedelmet szenved el minden korszakváltásnál (epoch). Fontos megjegyezni, hogy a DAG nem szükséges a proof-of-work ellenőrzéséhez, így ezt a folyamatot alacsony CPU-val és kevés memóriával is lehet végezni. - -Az algoritmus a következő általános utat teszi meg: - -1. Létezik egy **mag (seed)**, amelyet ki lehet számolni minden blokkra úgy, hogy a blokkfejléceket addig a pontig végigszkennelik. -2. Ebből a magból ki lehet számolni egy **16 MB álvéletlenszerű cache-t**. A könnyű kliensek tárolják a cache-t. -3. A gyorsítótárból egy **1 GB adathalmazt** lehet létrehozni, amelyben minden elem csak kevés gyorsítótár elemtől függ. A teljes kliensek és bányászok tárolják az adathalmazt. Az adathalmaz az idővel egyre növekszik. -4. A bányászat során az adathalmaz véletlenszerű szeleteit felkapják és összehashelik. Az ellenőrzést alacsony memóriával is lehet végezni, a cache-t használva arra, hogy újragenerálja az adathalmaz szükséges részeit, ezért csak a cache-t kell tárolni. - -A nagy adathalmaz minden 30 000. blokk után frissül, ezért a bányászok erőfeszítéseinek legjava az adatkészlet olvasására összpontosít, nem pedig a változtatására. - -## Definíciók {#definitions} - -A következő definíciókat használjuk: - -``` -WORD_BYTES = 4 # bytes in word -DATASET_BYTES_INIT = 2**30 # bytes in dataset at genesis -DATASET_BYTES_GROWTH = 2**23 # dataset growth per epoch -CACHE_BYTES_INIT = 2**24 # bytes in cache at genesis -CACHE_BYTES_GROWTH = 2**17 # cache growth per epoch -CACHE_MULTIPLIER=1024 # Size of the DAG relative to the cache -EPOCH_LENGTH = 30000 # blocks per epoch -MIX_BYTES = 128 # width of mix -HASH_BYTES = 64 # hash length in bytes -DATASET_PARENTS = 256 # number of parents of each dataset element -CACHE_ROUNDS = 3 # number of rounds in cache production -ACCESSES = 64 # number of accesses in hashimoto loop -``` - -### Az SHA3 használata {#sha3} - -Az Ethereum fejlesztése egybe esett az SHA3 szabvány kifejlesztésével, és a standard folyamat egy változtatást vitt véghez a végső hashalgoritmussal kapcsolatban, így az Ethereum „sha3_256” és „sha3_512” hashek nem szabványos sha3 hashek, hanem variánsok, melyre gyakran „Keccak-256” és „Keccak-512” néven hivatkoznak más kontextusban. Tekintse meg a kapcsolódó beszélgetéseket, például [itt](https://eips.ethereum.org/EIPS/eip-1803), [itt](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use) vagy [itt](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057). - -Vegye figyelembe, hogy az alábbi leírás SHA3-hashekre hivatkozik az algoritmus tekintetében. - -## Paraméterek {#parameters} - -Az Ethash-cache és adathalmaz paraméterei a blokkszámtól függenek. A cache és az adathalmaz mérete egyenes arányosságban növekszik; ugyanakkor mindig a legnagyobb prímszámot választjuk a lineárisan növekvő határ alatt, hogy kevesebb kockázata legyen valamilyen szokatlan dolognak, ami ciklikus viselkedéshez vezet. - -```python -def get_cache_size(block_number): - sz = CACHE_BYTES_INIT + CACHE_BYTES_GROWTH * (block_number // EPOCH_LENGTH) - sz -= HASH_BYTES - while not isprime(sz / HASH_BYTES): - sz -= 2 * HASH_BYTES - return sz - -def get_full_size(block_number): - sz = DATASET_BYTES_INIT + DATASET_BYTES_GROWTH * (block_number // EPOCH_LENGTH) - sz -= MIX_BYTES - while not isprime(sz / MIX_BYTES): - sz -= 2 * MIX_BYTES - return sz -``` - -Az adathalmaznak és a cache-méret értékeinek táblázatát a függelékben találja. - -## Cache létrehozása {#cache-generation} - -Most meghatározzuk a cache létrehozásának függvényét: - -```python -def mkcache(cache_size, seed): - n = cache_size // HASH_BYTES - - # Sequentially produce the initial dataset - o = [sha3_512(seed)] - for i in range(1, n): - o.append(sha3_512(o[-1])) - - # Use a low-round version of randmemohash - for _ in range(CACHE_ROUNDS): - for i in range(n): - v = o[i][0] % n - o[i] = sha3_512(map(xor, o[(i-1+n) % n], o[v])) - - return o -``` - -A cache létrehozása először 32 MB-nyi memória szekvenciális feltöltését igényli, majd Sergio Demian Lerner _RandMemoHash_ algoritmusának két végrehajtását a [_Strict Memory Hard Hashing Functions-ből_ (2014)](http://www.hashcash.org/papers/memohash.pdf). Az eredmény egy 524 288 db 64-bájtos elemből álló készlet. - -## Adataggregálási függvény {#date-aggregation-function} - -Olyan algoritmust használunk, amit az [FNV hash](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) inspirált néhány esetben, mint a XOR nem-asszociatív helyettesítője. Vegye figyelembe, hogy a prímszámot a teljes 32 bites bemeneti adattal megszorozzuk, ellentétben az FNV-1 specifikációval, ami a prímszámot egy bájttal (octet) szorozza. - -```python -FNV_PRIME = 0x01000193 - -def fnv(v1, v2): - return ((v1 * FNV_PRIME) ^ v2) % 2**32 -``` - -Vegye figyelembe, hogy még a Sárgakönyv is úgy határozza meg az fnv-t, mint v1\*(FNV_PRIME ^ v2), és minden jelenlegi implementáció konzisztensen ezt használja. - -## Teljes adathalmaz kiszámítása {#full-dataset-calculation} - -Minden 64 bájtos elem a teljes 1 GB-nyi adathalmazban a következőképpen kerül kiszámolásra: - -```python -def calc_dataset_item(cache, i): - n = len(cache) - r = HASH_BYTES // WORD_BYTES - # initialize the mix - mix = copy.copy(cache[i % n]) - mix[0] ^= i - mix = sha3_512(mix) - # fnv it with a lot of random cache nodes based on i - for j in range(DATASET_PARENTS): - cache_index = fnv(i ^ j, mix[j % r]) - mix = map(fnv, mix, cache[cache_index % n]) - return sha3_512(mix) -``` - -Lényegében a 256 álvéletlenszerűen kiválasztott cache-csomópontokból származó adatot kombináljuk, és ezeket hasheljük, hogy kiszámoljuk az adathalmaz csomópontját. Ezután a teljes adathalmazt létrehozzuk: - -```python -def calc_dataset(full_size, cache): - return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] -``` - -## Fő ciklus {#main-loop} - -Most meghatározzuk a fő „hashimoto”-szerű ciklust, ahol aggregáljuk a teljes adathalmazból vett adatokat azért, hogy egy bizonyos fejléchez és nonce-hoz végső értéket rendeljünk. A lenti kódban a `header` (fejléc) az SHA3-256 _hasht_ képviseli, ami az RLP reprezentációja egy _csonka_ blokkfejlécnek, tehát olyan fejléc, amiben nincs benne a **mixHash** és a **nonce**. A `nonce` egy 64 bites, nem aláírt egész szám nyolc bájtja big-endian sorban. Tehát a `nonce[::-1]` a nyolc bájtos kis-endian reprezentációja ennek az értéknek: - -```python -def hashimoto(header, nonce, full_size, dataset_lookup): - n = full_size / HASH_BYTES - w = MIX_BYTES // WORD_BYTES - mixhashes = MIX_BYTES / HASH_BYTES - # combine header+nonce into a 64 byte seed - s = sha3_512(header + nonce[::-1]) - # start the mix with replicated s - mix = [] - for _ in range(MIX_BYTES / HASH_BYTES): - mix.extend(s) - # mix in random dataset nodes - for i in range(ACCESSES): - p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes - newdata = [] - for j in range(MIX_BYTES / HASH_BYTES): - newdata.extend(dataset_lookup(p + j)) - mix = map(fnv, mix, newdata) - # compress mix - cmix = [] - for i in range(0, len(mix), 4): - cmix.append(fnv(fnv(fnv(mix[i], mix[i+1]), mix[i+2]), mix[i+3])) - return { - "mix digest": serialize_hash(cmix), - "result": serialize_hash(sha3_256(s+cmix)) - } - -def hashimoto_light(full_size, cache, header, nonce): - return hashimoto(header, nonce, full_size, lambda x: calc_dataset_item(cache, x)) - -def hashimoto_full(full_size, dataset, header, nonce): - return hashimoto(header, nonce, full_size, lambda x: dataset[x]) -``` - -Lényegében egy 128 bájt széles „mixet” készítünk, és ismétlődő módon, szekvenciálisan felkapunk 128 bájtot a teljes adathalmazból, és az `fnv` függvénnyel összekombináljuk a mix-szel. Azért 128 bájtnyi szekvenciális bemenetet használunk, hogy az algoritmus minden egyes köre a RAM egy teljes oldalát felkapja, így minimalizálva az átfordítás hibáit, melyeket az ASIC elméletileg el tudna kerülni. - -Ha az algoritmus kimenete a várt eredményt adja, akkor a nonce érvényes. Fontos megjegyezni, hogy az `sha3_256` extra alkalmazása a végén azt biztosítja, hogy létezik egy köztes nonce, ami bizonyítja, hogy legalább egy kis munkavégzés történt; ezt a gyors, külső proof-of-work-ellenőrzést DDoS elleni célokra lehet használni. Emellett statisztikai biztosítást is ad, hogy az eredmény egy helyes 256 bites szám. - -## Bányászat {#mining} - -A bányászati algoritmust a következőképpen definiáljuk: - -```python -def mine(full_size, dataset, header, difficulty): - # zero-pad target to compare with hash on the same digit - target = zpad(encode_int(2**256 // difficulty), 64)[::-1] - from random import randint - nonce = randint(0, 2**64) - while hashimoto_full(full_size, dataset, header, nonce) > target: - nonce = (nonce + 1) % 2**64 - return nonce -``` - -## A seed hash meghatározása {#seed-hash} - -A seed hash kiszámolásához, amellyel egy adott blokk tetején lehet bányászni, a következő algoritmust használjuk: - -```python - def get_seedhash(block): - s = '\x00' * 32 - for i in range(block.number // EPOCH_LENGTH): - s = serialize_hash(sha3_256(s)) - return s -``` - -Vegye figyelembe, hogy a zavartalan bányászat és ellenőrzés érdekében érdemes előre kiszámolni a jövőbeli seed hasheket és adathalmazokat egy másik helyen. - -## További olvasnivaló {#further-reading} - -_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ - -## Függelék {#appendix} - -A következő kódot kell beilleszteni, ha Ön a fenti python-specifikációt akarja futtatni kódként. - -```python -import sha3, copy - -# Assumes little endian bit ordering (same as Intel architectures) -def decode_int(s): - return int(s[::-1].encode('hex'), 16) if s else 0 - -def encode_int(s): - a = "%x" % s - return '' if s == 0 else ('0' * (len(a) % 2) + a).decode('hex')[::-1] - -def zpad(s, length): - return s + '\x00' * max(0, length - len(s)) - -def serialize_hash(h): - return ''.join([zpad(encode_int(x), 4) for x in h]) - -def deserialize_hash(h): - return [decode_int(h[i:i+WORD_BYTES]) for i in range(0, len(h), WORD_BYTES)] - -def hash_words(h, sz, x): - if isinstance(x, list): - x = serialize_hash(x) - y = h(x) - return deserialize_hash(y) - -def serialize_cache(ds): - return ''.join([serialize_hash(h) for h in ds]) - -serialize_dataset = serialize_cache - -# sha3 hash function, outputs 64 bytes -def sha3_512(x): - return hash_words(lambda v: sha3.sha3_512(v).digest(), 64, x) - -def sha3_256(x): - return hash_words(lambda v: sha3.sha3_256(v).digest(), 32, x) - -def xor(a, b): - return a ^ b - -def isprime(x): - for i in range(2, int(x**0.5)): - if x % i == 0: - return False - return True -``` - -### Adatméretek {#data-sizes} - -A következő tábla kb. 2048 korszak adat- és cache-méreteit mutatja meg. - -```python -def get_datasize(block_number): - return data_sizes[block_number // EPOCH_LENGTH] - -def get_cachesize(block_number): - return cache_sizes[block_number // EPOCH_LENGTH] - -data_sizes = [ -1073739904, 1082130304, 1090514816, 1098906752, 1107293056, -1115684224, 1124070016, 1132461952, 1140849536, 1149232768, -1157627776, 1166013824, 1174404736, 1182786944, 1191180416, -1199568512, 1207958912, 1216345216, 1224732032, 1233124736, -1241513344, 1249902464, 1258290304, 1266673792, 1275067264, -1283453312, 1291844992, 1300234112, 1308619904, 1317010048, -1325397376, 1333787776, 1342176128, 1350561664, 1358954368, -1367339392, 1375731584, 1384118144, 1392507008, 1400897408, -1409284736, 1417673344, 1426062464, 1434451072, 1442839168, -1451229056, 1459615616, 1468006016, 1476394112, 1484782976, -1493171584, 1501559168, 1509948032, 1518337664, 1526726528, -1535114624, 1543503488, 1551892096, 1560278656, 1568669056, -1577056384, 1585446272, 1593831296, 1602219392, 1610610304, -1619000192, 1627386752, 1635773824, 1644164224, 1652555648, -1660943488, 1669332608, 1677721216, 1686109312, 1694497664, -1702886272, 1711274624, 1719661184, 1728047744, 1736434816, -1744829056, 1753218944, 1761606272, 1769995904, 1778382464, -1786772864, 1795157888, 1803550592, 1811937664, 1820327552, -1828711552, 1837102976, 1845488768, 1853879936, 1862269312, -1870656896, 1879048064, 1887431552, 1895825024, 1904212096, -1912601216, 1920988544, 1929379456, 1937765504, 1946156672, -1954543232, 1962932096, 1971321728, 1979707264, 1988093056, -1996487552, 2004874624, 2013262208, 2021653888, 2030039936, -2038430848, 2046819968, 2055208576, 2063596672, 2071981952, -2080373632, 2088762752, 2097149056, 2105539712, 2113928576, -2122315136, 2130700672, 2139092608, 2147483264, 2155872128, -2164257664, 2172642176, 2181035392, 2189426048, 2197814912, -2206203008, 2214587264, 2222979712, 2231367808, 2239758208, -2248145024, 2256527744, 2264922752, 2273312128, 2281701248, -2290086272, 2298476672, 2306867072, 2315251072, 2323639168, -2332032128, 2340420224, 2348808064, 2357196416, 2365580416, -2373966976, 2382363008, 2390748544, 2399139968, 2407530368, -2415918976, 2424307328, 2432695424, 2441084288, 2449472384, -2457861248, 2466247808, 2474637184, 2483026816, 2491414144, -2499803776, 2508191872, 2516582272, 2524970368, 2533359232, -2541743488, 2550134144, 2558525056, 2566913408, 2575301504, -2583686528, 2592073856, 2600467328, 2608856192, 2617240448, -2625631616, 2634022016, 2642407552, 2650796416, 2659188352, -2667574912, 2675965312, 2684352896, 2692738688, 2701130624, -2709518464, 2717907328, 2726293376, 2734685056, 2743073152, -2751462016, 2759851648, 2768232832, 2776625536, 2785017728, -2793401984, 2801794432, 2810182016, 2818571648, 2826959488, -2835349376, 2843734144, 2852121472, 2860514432, 2868900992, -2877286784, 2885676928, 2894069632, 2902451584, 2910843008, -2919234688, 2927622784, 2936011648, 2944400768, 2952789376, -2961177728, 2969565568, 2977951616, 2986338944, 2994731392, -3003120256, 3011508352, 3019895936, 3028287104, 3036675968, -3045063808, 3053452928, 3061837696, 3070228352, 3078615424, -3087003776, 3095394944, 3103782272, 3112173184, 3120562048, -3128944768, 3137339264, 3145725056, 3154109312, 3162505088, -3170893184, 3179280256, 3187669376, 3196056704, 3204445568, -3212836736, 3221224064, 3229612928, 3238002304, 3246391168, -3254778496, 3263165824, 3271556224, 3279944576, 3288332416, -3296719232, 3305110912, 3313500032, 3321887104, 3330273152, -3338658944, 3347053184, 3355440512, 3363827072, 3372220288, -3380608384, 3388997504, 3397384576, 3405774208, 3414163072, -3422551936, 3430937984, 3439328384, 3447714176, 3456104576, -3464493952, 3472883584, 3481268864, 3489655168, 3498048896, -3506434432, 3514826368, 3523213952, 3531603584, 3539987072, -3548380288, 3556763264, 3565157248, 3573545344, 3581934464, -3590324096, 3598712704, 3607098752, 3615488384, 3623877248, -3632265856, 3640646528, 3649043584, 3657430144, 3665821568, -3674207872, 3682597504, 3690984832, 3699367808, 3707764352, -3716152448, 3724541056, 3732925568, 3741318016, 3749706368, -3758091136, 3766481536, 3774872704, 3783260032, 3791650432, -3800036224, 3808427648, 3816815488, 3825204608, 3833592704, -3841981568, 3850370432, 3858755968, 3867147904, 3875536256, -3883920512, 3892313728, 3900702592, 3909087872, 3917478784, -3925868416, 3934256512, 3942645376, 3951032192, 3959422336, -3967809152, 3976200064, 3984588416, 3992974976, 4001363584, -4009751168, 4018141312, 4026530432, 4034911616, 4043308928, -4051695488, 4060084352, 4068472448, 4076862848, 4085249408, -4093640576, 4102028416, 4110413696, 4118805632, 4127194496, -4135583104, 4143971968, 4152360832, 4160746112, 4169135744, -4177525888, 4185912704, 4194303616, 4202691968, 4211076736, -4219463552, 4227855488, 4236246656, 4244633728, 4253022848, -4261412224, 4269799808, 4278184832, 4286578048, 4294962304, -4303349632, 4311743104, 4320130432, 4328521088, 4336909184, -4345295488, 4353687424, 4362073472, 4370458496, 4378852736, -4387238528, 4395630208, 4404019072, 4412407424, 4420790656, -4429182848, 4437571456, 4445962112, 4454344064, 4462738048, -4471119232, 4479516544, 4487904128, 4496289664, 4504682368, -4513068416, 4521459584, 4529846144, 4538232704, 4546619776, -4555010176, 4563402112, 4571790208, 4580174464, 4588567936, -4596957056, 4605344896, 4613734016, 4622119808, 4630511488, -4638898816, 4647287936, 4655675264, 4664065664, 4672451968, -4680842624, 4689231488, 4697620352, 4706007424, 4714397056, -4722786176, 4731173248, 4739562368, 4747951744, 4756340608, -4764727936, 4773114496, 4781504384, 4789894784, 4798283648, -4806667648, 4815059584, 4823449472, 4831835776, 4840226176, -4848612224, 4857003392, 4865391488, 4873780096, 4882169728, -4890557312, 4898946944, 4907333248, 4915722368, 4924110976, -4932499328, 4940889728, 4949276032, 4957666432, 4966054784, -4974438016, 4982831488, 4991221376, 4999607168, 5007998848, -5016386432, 5024763776, 5033164672, 5041544576, 5049941888, -5058329728, 5066717056, 5075107456, 5083494272, 5091883904, -5100273536, 5108662144, 5117048192, 5125436032, 5133827456, -5142215296, 5150605184, 5158993024, 5167382144, 5175769472, -5184157568, 5192543872, 5200936064, 5209324928, 5217711232, -5226102656, 5234490496, 5242877312, 5251263872, 5259654016, -5268040832, 5276434304, 5284819328, 5293209728, 5301598592, -5309986688, 5318374784, 5326764416, 5335151488, 5343542144, -5351929472, 5360319872, 5368706944, 5377096576, 5385484928, -5393871232, 5402263424, 5410650496, 5419040384, 5427426944, -5435816576, 5444205952, 5452594816, 5460981376, 5469367936, -5477760896, 5486148736, 5494536832, 5502925952, 5511315328, -5519703424, 5528089984, 5536481152, 5544869504, 5553256064, -5561645696, 5570032768, 5578423936, 5586811264, 5595193216, -5603585408, 5611972736, 5620366208, 5628750464, 5637143936, -5645528192, 5653921408, 5662310272, 5670694784, 5679082624, -5687474048, 5695864448, 5704251008, 5712641408, 5721030272, -5729416832, 5737806208, 5746194304, 5754583936, 5762969984, -5771358592, 5779748224, 5788137856, 5796527488, 5804911232, -5813300608, 5821692544, 5830082176, 5838468992, 5846855552, -5855247488, 5863636096, 5872024448, 5880411008, 5888799872, -5897186432, 5905576832, 5913966976, 5922352768, 5930744704, -5939132288, 5947522432, 5955911296, 5964299392, 5972688256, -5981074304, 5989465472, 5997851008, 6006241408, 6014627968, -6023015552, 6031408256, 6039796096, 6048185216, 6056574848, -6064963456, 6073351808, 6081736064, 6090128768, 6098517632, -6106906496, 6115289216, 6123680896, 6132070016, 6140459648, -6148849024, 6157237376, 6165624704, 6174009728, 6182403712, -6190792064, 6199176064, 6207569792, 6215952256, 6224345216, -6232732544, 6241124224, 6249510272, 6257899136, 6266287744, -6274676864, 6283065728, 6291454336, 6299843456, 6308232064, -6316620928, 6325006208, 6333395584, 6341784704, 6350174848, -6358562176, 6366951296, 6375337856, 6383729536, 6392119168, -6400504192, 6408895616, 6417283456, 6425673344, 6434059136, -6442444672, 6450837376, 6459223424, 6467613056, 6476004224, -6484393088, 6492781952, 6501170048, 6509555072, 6517947008, -6526336384, 6534725504, 6543112832, 6551500672, 6559888768, -6568278656, 6576662912, 6585055616, 6593443456, 6601834112, -6610219648, 6618610304, 6626999168, 6635385472, 6643777408, -6652164224, 6660552832, 6668941952, 6677330048, 6685719424, -6694107776, 6702493568, 6710882176, 6719274112, 6727662976, -6736052096, 6744437632, 6752825984, 6761213824, 6769604224, -6777993856, 6786383488, 6794770816, 6803158144, 6811549312, -6819937664, 6828326528, 6836706176, 6845101696, 6853491328, -6861880448, 6870269312, 6878655104, 6887046272, 6895433344, -6903822208, 6912212864, 6920596864, 6928988288, 6937377152, -6945764992, 6954149248, 6962544256, 6970928768, 6979317376, -6987709312, 6996093824, 7004487296, 7012875392, 7021258624, -7029652352, 7038038912, 7046427776, 7054818944, 7063207808, -7071595136, 7079980928, 7088372608, 7096759424, 7105149824, -7113536896, 7121928064, 7130315392, 7138699648, 7147092352, -7155479168, 7163865728, 7172249984, 7180648064, 7189036672, -7197424768, 7205810816, 7214196608, 7222589824, 7230975104, -7239367552, 7247755904, 7256145536, 7264533376, 7272921472, -7281308032, 7289694848, 7298088832, 7306471808, 7314864512, -7323253888, 7331643008, 7340029568, 7348419712, 7356808832, -7365196672, 7373585792, 7381973888, 7390362752, 7398750592, -7407138944, 7415528576, 7423915648, 7432302208, 7440690304, -7449080192, 7457472128, 7465860992, 7474249088, 7482635648, -7491023744, 7499412608, 7507803008, 7516192384, 7524579968, -7532967296, 7541358464, 7549745792, 7558134656, 7566524032, -7574912896, 7583300992, 7591690112, 7600075136, 7608466816, -7616854912, 7625244544, 7633629824, 7642020992, 7650410368, -7658794112, 7667187328, 7675574912, 7683961984, 7692349568, -7700739712, 7709130368, 7717519232, 7725905536, 7734295424, -7742683264, 7751069056, 7759457408, 7767849088, 7776238208, -7784626816, 7793014912, 7801405312, 7809792128, 7818179968, -7826571136, 7834957184, 7843347328, 7851732352, 7860124544, -7868512384, 7876902016, 7885287808, 7893679744, 7902067072, -7910455936, 7918844288, 7927230848, 7935622784, 7944009344, -7952400256, 7960786048, 7969176704, 7977565312, 7985953408, -7994339968, 8002730368, 8011119488, 8019508096, 8027896192, -8036285056, 8044674688, 8053062272, 8061448832, 8069838464, -8078227328, 8086616704, 8095006592, 8103393664, 8111783552, -8120171392, 8128560256, 8136949376, 8145336704, 8153726848, -8162114944, 8170503296, 8178891904, 8187280768, 8195669632, -8204058496, 8212444544, 8220834176, 8229222272, 8237612672, -8246000768, 8254389376, 8262775168, 8271167104, 8279553664, -8287944064, 8296333184, 8304715136, 8313108352, 8321497984, -8329885568, 8338274432, 8346663296, 8355052928, 8363441536, -8371828352, 8380217984, 8388606592, 8396996224, 8405384576, -8413772672, 8422161536, 8430549376, 8438939008, 8447326592, -8455715456, 8464104832, 8472492928, 8480882048, 8489270656, -8497659776, 8506045312, 8514434944, 8522823808, 8531208832, -8539602304, 8547990656, 8556378752, 8564768384, 8573154176, -8581542784, 8589933952, 8598322816, 8606705024, 8615099264, -8623487872, 8631876992, 8640264064, 8648653952, 8657040256, -8665430656, 8673820544, 8682209152, 8690592128, 8698977152, -8707374464, 8715763328, 8724151424, 8732540032, 8740928384, -8749315712, 8757704576, 8766089344, 8774480768, 8782871936, -8791260032, 8799645824, 8808034432, 8816426368, 8824812928, -8833199488, 8841591424, 8849976448, 8858366336, 8866757248, -8875147136, 8883532928, 8891923328, 8900306816, 8908700288, -8917088384, 8925478784, 8933867392, 8942250368, 8950644608, -8959032704, 8967420544, 8975809664, 8984197504, 8992584064, -9000976256, 9009362048, 9017752448, 9026141312, 9034530688, -9042917504, 9051307904, 9059694208, 9068084864, 9076471424, -9084861824, 9093250688, 9101638528, 9110027648, 9118416512, -9126803584, 9135188096, 9143581312, 9151969664, 9160356224, -9168747136, 9177134464, 9185525632, 9193910144, 9202302848, -9210690688, 9219079552, 9227465344, 9235854464, 9244244864, -9252633472, 9261021824, 9269411456, 9277799296, 9286188928, -9294574208, 9302965888, 9311351936, 9319740032, 9328131968, -9336516736, 9344907392, 9353296768, 9361685888, 9370074752, -9378463616, 9386849408, 9395239808, 9403629184, 9412016512, -9420405376, 9428795008, 9437181568, 9445570688, 9453960832, -9462346624, 9470738048, 9479121536, 9487515008, 9495903616, -9504289664, 9512678528, 9521067904, 9529456256, 9537843584, -9546233728, 9554621312, 9563011456, 9571398784, 9579788672, -9588178304, 9596567168, 9604954496, 9613343104, 9621732992, -9630121856, 9638508416, 9646898816, 9655283584, 9663675776, -9672061312, 9680449664, 9688840064, 9697230464, 9705617536, -9714003584, 9722393984, 9730772608, 9739172224, 9747561088, -9755945344, 9764338816, 9772726144, 9781116544, 9789503872, -9797892992, 9806282624, 9814670464, 9823056512, 9831439232, -9839833984, 9848224384, 9856613504, 9865000576, 9873391232, -9881772416, 9890162816, 9898556288, 9906940544, 9915333248, -9923721088, 9932108672, 9940496512, 9948888448, 9957276544, -9965666176, 9974048384, 9982441088, 9990830464, 9999219584, -10007602816, 10015996544, 10024385152, 10032774016, 10041163648, -10049548928, 10057940096, 10066329472, 10074717824, 10083105152, -10091495296, 10099878784, 10108272256, 10116660608, 10125049216, -10133437312, 10141825664, 10150213504, 10158601088, 10166991232, -10175378816, 10183766144, 10192157312, 10200545408, 10208935552, -10217322112, 10225712768, 10234099328, 10242489472, 10250876032, -10259264896, 10267656064, 10276042624, 10284429184, 10292820352, -10301209472, 10309598848, 10317987712, 10326375296, 10334763392, -10343153536, 10351541632, 10359930752, 10368318592, 10376707456, -10385096576, 10393484672, 10401867136, 10410262144, 10418647424, -10427039104, 10435425664, 10443810176, 10452203648, 10460589952, -10468982144, 10477369472, 10485759104, 10494147712, 10502533504, -10510923392, 10519313536, 10527702656, 10536091264, 10544478592, -10552867712, 10561255808, 10569642368, 10578032768, 10586423168, -10594805632, 10603200128, 10611588992, 10619976064, 10628361344, -10636754048, 10645143424, 10653531776, 10661920384, 10670307968, -10678696832, 10687086464, 10695475072, 10703863168, 10712246144, -10720639616, 10729026688, 10737414784, 10745806208, 10754190976, -10762581376, 10770971264, 10779356288, 10787747456, 10796135552, -10804525184, 10812915584, 10821301888, 10829692288, 10838078336, -10846469248, 10854858368, 10863247232, 10871631488, 10880023424, -10888412032, 10896799616, 10905188992, 10913574016, 10921964672, -10930352768, 10938742912, 10947132544, 10955518592, 10963909504, -10972298368, 10980687488, 10989074816, 10997462912, 11005851776, -11014241152, 11022627712, 11031017344, 11039403904, 11047793024, -11056184704, 11064570752, 11072960896, 11081343872, 11089737856, -11098128256, 11106514816, 11114904448, 11123293568, 11131680128, -11140065152, 11148458368, 11156845696, 11165236864, 11173624192, -11182013824, 11190402688, 11198790784, 11207179136, 11215568768, -11223957376, 11232345728, 11240734592, 11249122688, 11257511296, -11265899648, 11274285952, 11282675584, 11291065472, 11299452544, -11307842432, 11316231296, 11324616832, 11333009024, 11341395584, -11349782656, 11358172288, 11366560384, 11374950016, 11383339648, -11391721856, 11400117376, 11408504192, 11416893568, 11425283456, -11433671552, 11442061184, 11450444672, 11458837888, 11467226752, -11475611776, 11484003968, 11492392064, 11500780672, 11509169024, -11517550976, 11525944448, 11534335616, 11542724224, 11551111808, -11559500672, 11567890304, 11576277376, 11584667008, 11593056128, -11601443456, 11609830016, 11618221952, 11626607488, 11634995072, -11643387776, 11651775104, 11660161664, 11668552576, 11676940928, -11685330304, 11693718656, 11702106496, 11710496128, 11718882688, -11727273088, 11735660416, 11744050048, 11752437376, 11760824704, -11769216128, 11777604736, 11785991296, 11794381952, 11802770048, -11811157888, 11819548544, 11827932544, 11836324736, 11844713344, -11853100928, 11861486464, 11869879936, 11878268032, 11886656896, -11895044992, 11903433088, 11911822976, 11920210816, 11928600448, -11936987264, 11945375872, 11953761152, 11962151296, 11970543488, -11978928512, 11987320448, 11995708288, 12004095104, 12012486272, -12020875136, 12029255552, 12037652096, 12046039168, 12054429568, -12062813824, 12071206528, 12079594624, 12087983744, 12096371072, -12104759936, 12113147264, 12121534592, 12129924992, 12138314624, -12146703232, 12155091584, 12163481216, 12171864704, 12180255872, -12188643968, 12197034112, 12205424512, 12213811328, 12222199424, -12230590336, 12238977664, 12247365248, 12255755392, 12264143488, -12272531584, 12280920448, 12289309568, 12297694592, 12306086528, -12314475392, 12322865024, 12331253632, 12339640448, 12348029312, -12356418944, 12364805248, 12373196672, 12381580928, 12389969024, -12398357632, 12406750592, 12415138432, 12423527552, 12431916416, -12440304512, 12448692352, 12457081216, 12465467776, 12473859968, -12482245504, 12490636672, 12499025536, 12507411584, 12515801728, -12524190592, 12532577152, 12540966272, 12549354368, 12557743232, -12566129536, 12574523264, 12582911872, 12591299456, 12599688064, -12608074624, 12616463488, 12624845696, 12633239936, 12641631616, -12650019968, 12658407296, 12666795136, 12675183232, 12683574656, -12691960192, 12700350592, 12708740224, 12717128576, 12725515904, -12733906816, 12742295168, 12750680192, 12759071872, 12767460736, -12775848832, 12784236928, 12792626816, 12801014656, 12809404288, -12817789312, 12826181504, 12834568832, 12842954624, 12851345792, -12859732352, 12868122496, 12876512128, 12884901248, 12893289088, -12901672832, 12910067584, 12918455168, 12926842496, 12935232896, -12943620736, 12952009856, 12960396928, 12968786816, 12977176192, -12985563776, 12993951104, 13002341504, 13010730368, 13019115392, -13027506304, 13035895168, 13044272512, 13052673152, 13061062528, -13069446272, 13077838976, 13086227072, 13094613632, 13103000192, -13111393664, 13119782528, 13128157568, 13136559232, 13144945024, -13153329536, 13161724288, 13170111872, 13178502784, 13186884736, -13195279744, 13203667072, 13212057472, 13220445824, 13228832128, -13237221248, 13245610624, 13254000512, 13262388352, 13270777472, -13279166336, 13287553408, 13295943296, 13304331904, 13312719488, -13321108096, 13329494656, 13337885824, 13346274944, 13354663808, -13363051136, 13371439232, 13379825024, 13388210816, 13396605056, -13404995456, 13413380224, 13421771392, 13430159744, 13438546048, -13446937216, 13455326848, 13463708288, 13472103808, 13480492672, -13488875648, 13497269888, 13505657728, 13514045312, 13522435712, -13530824576, 13539210112, 13547599232, 13555989376, 13564379008, -13572766336, 13581154432, 13589544832, 13597932928, 13606320512, -13614710656, 13623097472, 13631477632, 13639874944, 13648264064, -13656652928, 13665041792, 13673430656, 13681818496, 13690207616, -13698595712, 13706982272, 13715373184, 13723762048, 13732150144, -13740536704, 13748926592, 13757316224, 13765700992, 13774090112, -13782477952, 13790869376, 13799259008, 13807647872, 13816036736, -13824425344, 13832814208, 13841202304, 13849591424, 13857978752, -13866368896, 13874754688, 13883145344, 13891533184, 13899919232, -13908311168, 13916692096, 13925085056, 13933473152, 13941866368, -13950253696, 13958643584, 13967032192, 13975417216, 13983807616, -13992197504, 14000582272, 14008973696, 14017363072, 14025752192, -14034137984, 14042528384, 14050918016, 14059301504, 14067691648, -14076083584, 14084470144, 14092852352, 14101249664, 14109635968, -14118024832, 14126407552, 14134804352, 14143188608, 14151577984, -14159968384, 14168357248, 14176741504, 14185127296, 14193521024, -14201911424, 14210301824, 14218685056, 14227067264, 14235467392, -14243855488, 14252243072, 14260630144, 14269021568, 14277409408, -14285799296, 14294187904, 14302571392, 14310961792, 14319353728, -14327738752, 14336130944, 14344518784, 14352906368, 14361296512, -14369685376, 14378071424, 14386462592, 14394848128, 14403230848, -14411627392, 14420013952, 14428402304, 14436793472, 14445181568, -14453569664, 14461959808, 14470347904, 14478737024, 14487122816, -14495511424, 14503901824, 14512291712, 14520677504, 14529064832, -14537456768, 14545845632, 14554234496, 14562618496, 14571011456, -14579398784, 14587789184, 14596172672, 14604564608, 14612953984, -14621341312, 14629724288, 14638120832, 14646503296, 14654897536, -14663284864, 14671675264, 14680061056, 14688447616, 14696835968, -14705228416, 14713616768, 14722003328, 14730392192, 14738784128, -14747172736, 14755561088, 14763947648, 14772336512, 14780725376, -14789110144, 14797499776, 14805892736, 14814276992, 14822670208, -14831056256, 14839444352, 14847836032, 14856222848, 14864612992, -14872997504, 14881388672, 14889775744, 14898165376, 14906553472, -14914944896, 14923329664, 14931721856, 14940109696, 14948497024, -14956887424, 14965276544, 14973663616, 14982053248, 14990439808, -14998830976, 15007216768, 15015605888, 15023995264, 15032385152, -15040768384, 15049154944, 15057549184, 15065939072, 15074328448, -15082715008, 15091104128, 15099493504, 15107879296, 15116269184, -15124659584, 15133042304, 15141431936, 15149824384, 15158214272, -15166602368, 15174991232, 15183378304, 15191760512, 15200154496, -15208542592, 15216931712, 15225323392, 15233708416, 15242098048, -15250489216, 15258875264, 15267265408, 15275654528, 15284043136, -15292431488, 15300819584, 15309208192, 15317596544, 15325986176, -15334374784, 15342763648, 15351151744, 15359540608, 15367929728, -15376318336, 15384706432, 15393092992, 15401481856, 15409869952, -15418258816, 15426649984, 15435037568, 15443425664, 15451815296, -15460203392, 15468589184, 15476979328, 15485369216, 15493755776, -15502146944, 15510534272, 15518924416, 15527311232, 15535699072, -15544089472, 15552478336, 15560866688, 15569254528, 15577642624, -15586031488, 15594419072, 15602809472, 15611199104, 15619586432, -15627975296, 15636364928, 15644753792, 15653141888, 15661529216, -15669918848, 15678305152, 15686696576, 15695083136, 15703474048, -15711861632, 15720251264, 15728636288, 15737027456, 15745417088, -15753804928, 15762194048, 15770582656, 15778971008, 15787358336, -15795747712, 15804132224, 15812523392, 15820909696, 15829300096, -15837691264, 15846071936, 15854466944, 15862855808, 15871244672, -15879634816, 15888020608, 15896409728, 15904799104, 15913185152, -15921577088, 15929966464, 15938354816, 15946743424, 15955129472, -15963519872, 15971907968, 15980296064, 15988684928, 15997073024, -16005460864, 16013851264, 16022241152, 16030629248, 16039012736, -16047406976, 16055794816, 16064181376, 16072571264, 16080957824, -16089346688, 16097737856, 16106125184, 16114514816, 16122904192, -16131292544, 16139678848, 16148066944, 16156453504, 16164839552, -16173236096, 16181623424, 16190012032, 16198401152, 16206790528, -16215177344, 16223567744, 16231956352, 16240344704, 16248731008, -16257117824, 16265504384, 16273898624, 16282281856, 16290668672, -16299064192, 16307449216, 16315842176, 16324230016, 16332613504, -16341006464, 16349394304, 16357783168, 16366172288, 16374561664, -16382951296, 16391337856, 16399726208, 16408116352, 16416505472, -16424892032, 16433282176, 16441668224, 16450058624, 16458448768, -16466836864, 16475224448, 16483613056, 16492001408, 16500391808, -16508779648, 16517166976, 16525555328, 16533944192, 16542330752, -16550719616, 16559110528, 16567497088, 16575888512, 16584274816, -16592665472, 16601051008, 16609442944, 16617832064, 16626218624, -16634607488, 16642996096, 16651385728, 16659773824, 16668163712, -16676552576, 16684938112, 16693328768, 16701718144, 16710095488, -16718492288, 16726883968, 16735272832, 16743661184, 16752049792, -16760436608, 16768827008, 16777214336, 16785599104, 16793992832, -16802381696, 16810768768, 16819151744, 16827542656, 16835934848, -16844323712, 16852711552, 16861101952, 16869489536, 16877876864, -16886265728, 16894653056, 16903044736, 16911431296, 16919821696, -16928207488, 16936592768, 16944987776, 16953375616, 16961763968, -16970152832, 16978540928, 16986929536, 16995319168, 17003704448, -17012096896, 17020481152, 17028870784, 17037262208, 17045649536, -17054039936, 17062426496, 17070814336, 17079205504, 17087592064, -17095978112, 17104369024, 17112759424, 17121147776, 17129536384, -17137926016, 17146314368, 17154700928, 17163089792, 17171480192, -17179864192, 17188256896, 17196644992, 17205033856, 17213423488, -17221811072, 17230198912, 17238588032, 17246976896, 17255360384, -17263754624, 17272143232, 17280530048, 17288918912, 17297309312, -17305696384, 17314085504, 17322475136, 17330863744, 17339252096, -17347640192, 17356026496, 17364413824, 17372796544, 17381190016, -17389583488, 17397972608, 17406360704, 17414748544, 17423135872, -17431527296, 17439915904, 17448303232, 17456691584, 17465081728, -17473468288, 17481857408, 17490247552, 17498635904, 17507022464, -17515409024, 17523801728, 17532189824, 17540577664, 17548966016, -17557353344, 17565741184, 17574131584, 17582519168, 17590907008, -17599296128, 17607687808, 17616076672, 17624455808, 17632852352, -17641238656, 17649630848, 17658018944, 17666403968, 17674794112, -17683178368, 17691573376, 17699962496, 17708350592, 17716739968, -17725126528, 17733517184, 17741898112, 17750293888, 17758673024, -17767070336, 17775458432, 17783848832, 17792236928, 17800625536, -17809012352, 17817402752, 17825785984, 17834178944, 17842563968, -17850955648, 17859344512, 17867732864, 17876119424, 17884511872, -17892900224, 17901287296, 17909677696, 17918058112, 17926451072, -17934843776, 17943230848, 17951609216, 17960008576, 17968397696, -17976784256, 17985175424, 17993564032, 18001952128, 18010339712, -18018728576, 18027116672, 18035503232, 18043894144, 18052283264, -18060672128, 18069056384, 18077449856, 18085837184, 18094225792, -18102613376, 18111004544, 18119388544, 18127781248, 18136170368, -18144558976, 18152947328, 18161336192, 18169724288, 18178108544, -18186498944, 18194886784, 18203275648, 18211666048, 18220048768, -18228444544, 18236833408, 18245220736] - -cache_sizes = [ -16776896, 16907456, 17039296, 17170112, 17301056, 17432512, 17563072, -17693888, 17824192, 17955904, 18087488, 18218176, 18349504, 18481088, -18611392, 18742336, 18874304, 19004224, 19135936, 19267264, 19398208, -19529408, 19660096, 19791424, 19922752, 20053952, 20184896, 20315968, -20446912, 20576576, 20709184, 20840384, 20971072, 21102272, 21233216, -21364544, 21494848, 21626816, 21757376, 21887552, 22019392, 22151104, -22281536, 22412224, 22543936, 22675264, 22806464, 22935872, 23068096, -23198272, 23330752, 23459008, 23592512, 23723968, 23854912, 23986112, -24116672, 24247616, 24378688, 24509504, 24640832, 24772544, 24903488, -25034432, 25165376, 25296704, 25427392, 25558592, 25690048, 25820096, -25951936, 26081728, 26214208, 26345024, 26476096, 26606656, 26737472, -26869184, 26998208, 27131584, 27262528, 27393728, 27523904, 27655744, -27786688, 27917888, 28049344, 28179904, 28311488, 28441792, 28573504, -28700864, 28835648, 28966208, 29096768, 29228608, 29359808, 29490752, -29621824, 29752256, 29882816, 30014912, 30144448, 30273728, 30406976, -30538432, 30670784, 30799936, 30932672, 31063744, 31195072, 31325248, -31456192, 31588288, 31719232, 31850432, 31981504, 32110784, 32243392, -32372672, 32505664, 32636608, 32767808, 32897344, 33029824, 33160768, -33289664, 33423296, 33554368, 33683648, 33816512, 33947456, 34076992, -34208704, 34340032, 34471744, 34600256, 34734016, 34864576, 34993984, -35127104, 35258176, 35386688, 35518528, 35650624, 35782336, 35910976, -36044608, 36175808, 36305728, 36436672, 36568384, 36699968, 36830656, -36961984, 37093312, 37223488, 37355072, 37486528, 37617472, 37747904, -37879232, 38009792, 38141888, 38272448, 38403392, 38535104, 38660672, -38795584, 38925632, 39059264, 39190336, 39320768, 39452096, 39581632, -39713984, 39844928, 39974848, 40107968, 40238144, 40367168, 40500032, -40631744, 40762816, 40894144, 41023552, 41155904, 41286208, 41418304, -41547712, 41680448, 41811904, 41942848, 42073792, 42204992, 42334912, -42467008, 42597824, 42729152, 42860096, 42991552, 43122368, 43253696, -43382848, 43515712, 43646912, 43777088, 43907648, 44039104, 44170432, -44302144, 44433344, 44564288, 44694976, 44825152, 44956864, 45088448, -45219008, 45350464, 45481024, 45612608, 45744064, 45874496, 46006208, -46136768, 46267712, 46399424, 46529344, 46660672, 46791488, 46923328, -47053504, 47185856, 47316928, 47447872, 47579072, 47710144, 47839936, -47971648, 48103232, 48234176, 48365248, 48496192, 48627136, 48757312, -48889664, 49020736, 49149248, 49283008, 49413824, 49545152, 49675712, -49807168, 49938368, 50069056, 50200256, 50331584, 50462656, 50593472, -50724032, 50853952, 50986048, 51117632, 51248576, 51379904, 51510848, -51641792, 51773248, 51903296, 52035136, 52164032, 52297664, 52427968, -52557376, 52690112, 52821952, 52952896, 53081536, 53213504, 53344576, -53475776, 53608384, 53738816, 53870528, 54000832, 54131776, 54263744, -54394688, 54525248, 54655936, 54787904, 54918592, 55049152, 55181248, -55312064, 55442752, 55574336, 55705024, 55836224, 55967168, 56097856, -56228672, 56358592, 56490176, 56621888, 56753728, 56884928, 57015488, -57146816, 57278272, 57409216, 57540416, 57671104, 57802432, 57933632, -58064576, 58195264, 58326976, 58457408, 58588864, 58720192, 58849984, -58981696, 59113024, 59243456, 59375552, 59506624, 59637568, 59768512, -59897792, 60030016, 60161984, 60293056, 60423872, 60554432, 60683968, -60817216, 60948032, 61079488, 61209664, 61341376, 61471936, 61602752, -61733696, 61865792, 61996736, 62127808, 62259136, 62389568, 62520512, -62651584, 62781632, 62910784, 63045056, 63176128, 63307072, 63438656, -63569216, 63700928, 63831616, 63960896, 64093888, 64225088, 64355392, -64486976, 64617664, 64748608, 64879424, 65009216, 65142464, 65273792, -65402816, 65535424, 65666752, 65797696, 65927744, 66060224, 66191296, -66321344, 66453056, 66584384, 66715328, 66846656, 66977728, 67108672, -67239104, 67370432, 67501888, 67631296, 67763776, 67895104, 68026304, -68157248, 68287936, 68419264, 68548288, 68681408, 68811968, 68942912, -69074624, 69205568, 69337024, 69467584, 69599168, 69729472, 69861184, -69989824, 70122944, 70253888, 70385344, 70515904, 70647232, 70778816, -70907968, 71040832, 71171648, 71303104, 71432512, 71564992, 71695168, -71826368, 71958464, 72089536, 72219712, 72350144, 72482624, 72613568, -72744512, 72875584, 73006144, 73138112, 73268672, 73400128, 73530944, -73662272, 73793344, 73924544, 74055104, 74185792, 74316992, 74448832, -74579392, 74710976, 74841664, 74972864, 75102784, 75233344, 75364544, -75497024, 75627584, 75759296, 75890624, 76021696, 76152256, 76283072, -76414144, 76545856, 76676672, 76806976, 76937792, 77070016, 77200832, -77331392, 77462464, 77593664, 77725376, 77856448, 77987776, 78118336, -78249664, 78380992, 78511424, 78642496, 78773056, 78905152, 79033664, -79166656, 79297472, 79429568, 79560512, 79690816, 79822784, 79953472, -80084672, 80214208, 80346944, 80477632, 80608576, 80740288, 80870848, -81002048, 81133504, 81264448, 81395648, 81525952, 81657536, 81786304, -81919808, 82050112, 82181312, 82311616, 82443968, 82573376, 82705984, -82835776, 82967744, 83096768, 83230528, 83359552, 83491264, 83622464, -83753536, 83886016, 84015296, 84147776, 84277184, 84409792, 84540608, -84672064, 84803008, 84934336, 85065152, 85193792, 85326784, 85458496, -85589312, 85721024, 85851968, 85982656, 86112448, 86244416, 86370112, -86506688, 86637632, 86769344, 86900672, 87031744, 87162304, 87293632, -87424576, 87555392, 87687104, 87816896, 87947968, 88079168, 88211264, -88341824, 88473152, 88603712, 88735424, 88862912, 88996672, 89128384, -89259712, 89390272, 89521984, 89652544, 89783872, 89914816, 90045376, -90177088, 90307904, 90438848, 90569152, 90700096, 90832832, 90963776, -91093696, 91223744, 91356992, 91486784, 91618496, 91749824, 91880384, -92012224, 92143552, 92273344, 92405696, 92536768, 92666432, 92798912, -92926016, 93060544, 93192128, 93322816, 93453632, 93583936, 93715136, -93845056, 93977792, 94109504, 94240448, 94371776, 94501184, 94632896, -94764224, 94895552, 95023424, 95158208, 95287744, 95420224, 95550016, -95681216, 95811904, 95943872, 96075328, 96203584, 96337856, 96468544, -96599744, 96731072, 96860992, 96992576, 97124288, 97254848, 97385536, -97517248, 97647808, 97779392, 97910464, 98041408, 98172608, 98303168, -98434496, 98565568, 98696768, 98827328, 98958784, 99089728, 99220928, -99352384, 99482816, 99614272, 99745472, 99876416, 100007104, -100138048, 100267072, 100401088, 100529984, 100662592, 100791872, -100925248, 101056064, 101187392, 101317952, 101449408, 101580608, -101711296, 101841728, 101973824, 102104896, 102235712, 102366016, -102498112, 102628672, 102760384, 102890432, 103021888, 103153472, -103284032, 103415744, 103545152, 103677248, 103808576, 103939648, -104070976, 104201792, 104332736, 104462528, 104594752, 104725952, -104854592, 104988608, 105118912, 105247808, 105381184, 105511232, -105643072, 105774784, 105903296, 106037056, 106167872, 106298944, -106429504, 106561472, 106691392, 106822592, 106954304, 107085376, -107216576, 107346368, 107478464, 107609792, 107739712, 107872192, -108003136, 108131392, 108265408, 108396224, 108527168, 108657344, -108789568, 108920384, 109049792, 109182272, 109312576, 109444928, -109572928, 109706944, 109837888, 109969088, 110099648, 110230976, -110362432, 110492992, 110624704, 110755264, 110886208, 111017408, -111148864, 111279296, 111410752, 111541952, 111673024, 111803456, -111933632, 112066496, 112196416, 112328512, 112457792, 112590784, -112715968, 112852672, 112983616, 113114944, 113244224, 113376448, -113505472, 113639104, 113770304, 113901376, 114031552, 114163264, -114294592, 114425536, 114556864, 114687424, 114818624, 114948544, -115080512, 115212224, 115343296, 115473472, 115605184, 115736128, -115867072, 115997248, 116128576, 116260288, 116391488, 116522944, -116652992, 116784704, 116915648, 117046208, 117178304, 117308608, -117440192, 117569728, 117701824, 117833024, 117964096, 118094656, -118225984, 118357312, 118489024, 118617536, 118749632, 118882112, -119012416, 119144384, 119275328, 119406016, 119537344, 119668672, -119798464, 119928896, 120061376, 120192832, 120321728, 120454336, -120584512, 120716608, 120848192, 120979136, 121109056, 121241408, -121372352, 121502912, 121634752, 121764416, 121895744, 122027072, -122157632, 122289088, 122421184, 122550592, 122682944, 122813888, -122945344, 123075776, 123207488, 123338048, 123468736, 123600704, -123731264, 123861952, 123993664, 124124608, 124256192, 124386368, -124518208, 124649024, 124778048, 124911296, 125041088, 125173696, -125303744, 125432896, 125566912, 125696576, 125829056, 125958592, -126090304, 126221248, 126352832, 126483776, 126615232, 126746432, -126876608, 127008704, 127139392, 127270336, 127401152, 127532224, -127663552, 127794752, 127925696, 128055232, 128188096, 128319424, -128449856, 128581312, 128712256, 128843584, 128973632, 129103808, -129236288, 129365696, 129498944, 129629888, 129760832, 129892288, -130023104, 130154048, 130283968, 130416448, 130547008, 130678336, -130807616, 130939456, 131071552, 131202112, 131331776, 131464384, -131594048, 131727296, 131858368, 131987392, 132120256, 132250816, -132382528, 132513728, 132644672, 132774976, 132905792, 133038016, -133168832, 133299392, 133429312, 133562048, 133692992, 133823296, -133954624, 134086336, 134217152, 134348608, 134479808, 134607296, -134741056, 134872384, 135002944, 135134144, 135265472, 135396544, -135527872, 135659072, 135787712, 135921472, 136052416, 136182848, -136313792, 136444864, 136576448, 136707904, 136837952, 136970048, -137099584, 137232064, 137363392, 137494208, 137625536, 137755712, -137887424, 138018368, 138149824, 138280256, 138411584, 138539584, -138672832, 138804928, 138936128, 139066688, 139196864, 139328704, -139460032, 139590208, 139721024, 139852864, 139984576, 140115776, -140245696, 140376512, 140508352, 140640064, 140769856, 140902336, -141032768, 141162688, 141294016, 141426496, 141556544, 141687488, -141819584, 141949888, 142080448, 142212544, 142342336, 142474432, -142606144, 142736192, 142868288, 142997824, 143129408, 143258944, -143392448, 143523136, 143653696, 143785024, 143916992, 144045632, -144177856, 144309184, 144440768, 144570688, 144701888, 144832448, -144965056, 145096384, 145227584, 145358656, 145489856, 145620928, -145751488, 145883072, 146011456, 146144704, 146275264, 146407232, -146538176, 146668736, 146800448, 146931392, 147062336, 147193664, -147324224, 147455936, 147586624, 147717056, 147848768, 147979456, -148110784, 148242368, 148373312, 148503232, 148635584, 148766144, -148897088, 149028416, 149159488, 149290688, 149420224, 149551552, -149683136, 149814976, 149943616, 150076352, 150208064, 150338624, -150470464, 150600256, 150732224, 150862784, 150993088, 151125952, -151254976, 151388096, 151519168, 151649728, 151778752, 151911104, -152042944, 152174144, 152304704, 152435648, 152567488, 152698816, -152828992, 152960576, 153091648, 153222976, 153353792, 153484096, -153616192, 153747008, 153878336, 154008256, 154139968, 154270912, -154402624, 154533824, 154663616, 154795712, 154926272, 155057984, -155188928, 155319872, 155450816, 155580608, 155712064, 155843392, -155971136, 156106688, 156237376, 156367424, 156499264, 156630976, -156761536, 156892352, 157024064, 157155008, 157284416, 157415872, -157545536, 157677248, 157810496, 157938112, 158071744, 158203328, -158334656, 158464832, 158596288, 158727616, 158858048, 158988992, -159121216, 159252416, 159381568, 159513152, 159645632, 159776192, -159906496, 160038464, 160169536, 160300352, 160430656, 160563008, -160693952, 160822208, 160956352, 161086784, 161217344, 161349184, -161480512, 161611456, 161742272, 161873216, 162002752, 162135872, -162266432, 162397888, 162529216, 162660032, 162790976, 162922048, -163052096, 163184576, 163314752, 163446592, 163577408, 163707968, -163839296, 163969984, 164100928, 164233024, 164364224, 164494912, -164625856, 164756672, 164887616, 165019072, 165150016, 165280064, -165412672, 165543104, 165674944, 165805888, 165936832, 166067648, -166198336, 166330048, 166461248, 166591552, 166722496, 166854208, -166985408, 167116736, 167246656, 167378368, 167508416, 167641024, -167771584, 167903168, 168034112, 168164032, 168295744, 168427456, -168557632, 168688448, 168819136, 168951616, 169082176, 169213504, -169344832, 169475648, 169605952, 169738048, 169866304, 169999552, -170131264, 170262464, 170393536, 170524352, 170655424, 170782016, -170917696, 171048896, 171179072, 171310784, 171439936, 171573184, -171702976, 171835072, 171966272, 172097216, 172228288, 172359232, -172489664, 172621376, 172747712, 172883264, 173014208, 173144512, -173275072, 173407424, 173539136, 173669696, 173800768, 173931712, -174063424, 174193472, 174325696, 174455744, 174586816, 174718912, -174849728, 174977728, 175109696, 175242688, 175374272, 175504832, -175636288, 175765696, 175898432, 176028992, 176159936, 176291264, -176422592, 176552512, 176684864, 176815424, 176946496, 177076544, -177209152, 177340096, 177470528, 177600704, 177731648, 177864256, -177994816, 178126528, 178257472, 178387648, 178518464, 178650176, -178781888, 178912064, 179044288, 179174848, 179305024, 179436736, -179568448, 179698496, 179830208, 179960512, 180092608, 180223808, -180354752, 180485696, 180617152, 180748096, 180877504, 181009984, -181139264, 181272512, 181402688, 181532608, 181663168, 181795136, -181926592, 182057536, 182190016, 182320192, 182451904, 182582336, -182713792, 182843072, 182976064, 183107264, 183237056, 183368384, -183494848, 183631424, 183762752, 183893824, 184024768, 184154816, -184286656, 184417984, 184548928, 184680128, 184810816, 184941248, -185072704, 185203904, 185335616, 185465408, 185596352, 185727296, -185859904, 185989696, 186121664, 186252992, 186383552, 186514112, -186645952, 186777152, 186907328, 187037504, 187170112, 187301824, -187429184, 187562048, 187693504, 187825472, 187957184, 188087104, -188218304, 188349376, 188481344, 188609728, 188743616, 188874304, -189005248, 189136448, 189265088, 189396544, 189528128, 189660992, -189791936, 189923264, 190054208, 190182848, 190315072, 190447424, -190577984, 190709312, 190840768, 190971328, 191102656, 191233472, -191364032, 191495872, 191626816, 191758016, 191888192, 192020288, -192148928, 192282176, 192413504, 192542528, 192674752, 192805952, -192937792, 193068608, 193198912, 193330496, 193462208, 193592384, -193723456, 193854272, 193985984, 194116672, 194247232, 194379712, -194508352, 194641856, 194772544, 194900672, 195035072, 195166016, -195296704, 195428032, 195558592, 195690304, 195818176, 195952576, -196083392, 196214336, 196345792, 196476736, 196607552, 196739008, -196869952, 197000768, 197130688, 197262784, 197394368, 197523904, -197656384, 197787584, 197916608, 198049472, 198180544, 198310208, -198442432, 198573632, 198705088, 198834368, 198967232, 199097792, -199228352, 199360192, 199491392, 199621696, 199751744, 199883968, -200014016, 200146624, 200276672, 200408128, 200540096, 200671168, -200801984, 200933312, 201062464, 201194944, 201326144, 201457472, -201588544, 201719744, 201850816, 201981632, 202111552, 202244032, -202374464, 202505152, 202636352, 202767808, 202898368, 203030336, -203159872, 203292608, 203423296, 203553472, 203685824, 203816896, -203947712, 204078272, 204208192, 204341056, 204472256, 204603328, -204733888, 204864448, 204996544, 205125568, 205258304, 205388864, -205517632, 205650112, 205782208, 205913536, 206044736, 206176192, -206307008, 206434496, 206569024, 206700224, 206831168, 206961856, -207093056, 207223616, 207355328, 207486784, 207616832, 207749056, -207879104, 208010048, 208141888, 208273216, 208404032, 208534336, -208666048, 208796864, 208927424, 209059264, 209189824, 209321792, -209451584, 209582656, 209715136, 209845568, 209976896, 210106432, -210239296, 210370112, 210501568, 210630976, 210763712, 210894272, -211024832, 211156672, 211287616, 211418176, 211549376, 211679296, -211812032, 211942592, 212074432, 212204864, 212334016, 212467648, -212597824, 212727616, 212860352, 212991424, 213120832, 213253952, -213385024, 213515584, 213645632, 213777728, 213909184, 214040128, -214170688, 214302656, 214433728, 214564544, 214695232, 214826048, -214956992, 215089088, 215219776, 215350592, 215482304, 215613248, -215743552, 215874752, 216005312, 216137024, 216267328, 216399296, -216530752, 216661696, 216790592, 216923968, 217054528, 217183168, -217316672, 217448128, 217579072, 217709504, 217838912, 217972672, -218102848, 218233024, 218364736, 218496832, 218627776, 218759104, -218888896, 219021248, 219151936, 219281728, 219413056, 219545024, -219675968, 219807296, 219938624, 220069312, 220200128, 220331456, -220461632, 220592704, 220725184, 220855744, 220987072, 221117888, -221249216, 221378368, 221510336, 221642048, 221772736, 221904832, -222031808, 222166976, 222297536, 222428992, 222559936, 222690368, -222820672, 222953152, 223083968, 223213376, 223345984, 223476928, -223608512, 223738688, 223869376, 224001472, 224132672, 224262848, -224394944, 224524864, 224657344, 224788288, 224919488, 225050432, -225181504, 225312704, 225443776, 225574592, 225704768, 225834176, -225966784, 226097216, 226229824, 226360384, 226491712, 226623424, -226754368, 226885312, 227015104, 227147456, 227278528, 227409472, -227539904, 227669696, 227802944, 227932352, 228065216, 228196288, -228326464, 228457792, 228588736, 228720064, 228850112, 228981056, -229113152, 229243328, 229375936, 229505344, 229636928, 229769152, -229894976, 230030272, 230162368, 230292416, 230424512, 230553152, -230684864, 230816704, 230948416, 231079616, 231210944, 231342016, -231472448, 231603776, 231733952, 231866176, 231996736, 232127296, -232259392, 232388672, 232521664, 232652608, 232782272, 232914496, -233043904, 233175616, 233306816, 233438528, 233569984, 233699776, -233830592, 233962688, 234092224, 234221888, 234353984, 234485312, -234618304, 234749888, 234880832, 235011776, 235142464, 235274048, -235403456, 235535936, 235667392, 235797568, 235928768, 236057152, -236190272, 236322752, 236453312, 236583616, 236715712, 236846528, -236976448, 237108544, 237239104, 237371072, 237501632, 237630784, -237764416, 237895232, 238026688, 238157632, 238286912, 238419392, -238548032, 238681024, 238812608, 238941632, 239075008, 239206336, -239335232, 239466944, 239599168, 239730496, 239861312, 239992384, -240122816, 240254656, 240385856, 240516928, 240647872, 240779072, -240909632, 241040704, 241171904, 241302848, 241433408, 241565248, -241696192, 241825984, 241958848, 242088256, 242220224, 242352064, -242481856, 242611648, 242744896, 242876224, 243005632, 243138496, -243268672, 243400384, 243531712, 243662656, 243793856, 243924544, -244054592, 244187072, 244316608, 244448704, 244580032, 244710976, -244841536, 244972864, 245104448, 245233984, 245365312, 245497792, -245628736, 245759936, 245889856, 246021056, 246152512, 246284224, -246415168, 246545344, 246675904, 246808384, 246939584, 247070144, -247199552, 247331648, 247463872, 247593536, 247726016, 247857088, -247987648, 248116928, 248249536, 248380736, 248512064, 248643008, -248773312, 248901056, 249036608, 249167552, 249298624, 249429184, -249560512, 249692096, 249822784, 249954112, 250085312, 250215488, -250345792, 250478528, 250608704, 250739264, 250870976, 251002816, -251133632, 251263552, 251395136, 251523904, 251657792, 251789248, -251919424, 252051392, 252182464, 252313408, 252444224, 252575552, -252706624, 252836032, 252968512, 253099712, 253227584, 253361728, -253493056, 253623488, 253754432, 253885504, 254017216, 254148032, -254279488, 254410432, 254541376, 254672576, 254803264, 254933824, -255065792, 255196736, 255326528, 255458752, 255589952, 255721408, -255851072, 255983296, 256114624, 256244416, 256374208, 256507712, -256636096, 256768832, 256900544, 257031616, 257162176, 257294272, -257424448, 257555776, 257686976, 257818432, 257949632, 258079552, -258211136, 258342464, 258473408, 258603712, 258734656, 258867008, -258996544, 259127744, 259260224, 259391296, 259522112, 259651904, -259784384, 259915328, 260045888, 260175424, 260308544, 260438336, -260570944, 260700992, 260832448, 260963776, 261092672, 261226304, -261356864, 261487936, 261619648, 261750592, 261879872, 262011968, -262143424, 262274752, 262404416, 262537024, 262667968, 262799296, -262928704, 263061184, 263191744, 263322944, 263454656, 263585216, -263716672, 263847872, 263978944, 264108608, 264241088, 264371648, -264501184, 264632768, 264764096, 264895936, 265024576, 265158464, -265287488, 265418432, 265550528, 265681216, 265813312, 265943488, -266075968, 266206144, 266337728, 266468032, 266600384, 266731072, -266862272, 266993344, 267124288, 267255616, 267386432, 267516992, -267648704, 267777728, 267910592, 268040512, 268172096, 268302784, -268435264, 268566208, 268696256, 268828096, 268959296, 269090368, -269221312, 269352256, 269482688, 269614784, 269745856, 269876416, -270007616, 270139328, 270270272, 270401216, 270531904, 270663616, -270791744, 270924736, 271056832, 271186112, 271317184, 271449536, -271580992, 271711936, 271843136, 271973056, 272105408, 272236352, -272367296, 272498368, 272629568, 272759488, 272891456, 273022784, -273153856, 273284672, 273415616, 273547072, 273677632, 273808448, -273937088, 274071488, 274200896, 274332992, 274463296, 274595392, -274726208, 274857536, 274988992, 275118656, 275250496, 275382208, -275513024, 275643968, 275775296, 275906368, 276037184, 276167872, -276297664, 276429376, 276560576, 276692672, 276822976, 276955072, -277085632, 277216832, 277347008, 277478848, 277609664, 277740992, -277868608, 278002624, 278134336, 278265536, 278395328, 278526784, -278657728, 278789824, 278921152, 279052096, 279182912, 279313088, -279443776, 279576256, 279706048, 279838528, 279969728, 280099648, -280230976, 280361408, 280493632, 280622528, 280755392, 280887104, -281018176, 281147968, 281278912, 281411392, 281542592, 281673152, -281803712, 281935552, 282066496, 282197312, 282329024, 282458816, -282590272, 282720832, 282853184, 282983744, 283115072, 283246144, -283377344, 283508416, 283639744, 283770304, 283901504, 284032576, -284163136, 284294848, 284426176, 284556992, 284687296, 284819264, -284950208, 285081536] -``` diff --git "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" "b/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" deleted file mode 100644 index 3767d2f369c..00000000000 --- "a/public/content/translations/hu/17) Foundational Docs \342\200\223 Proof-of-Work/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md" +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Bányászati algoritmusok -description: Az Ethereum-bányászat algoritmusainak bemutatása. -lang: hu ---- - - -A proof-of-work (munkaigazolás) már nem az Ethereum konszenzusmechanizmus alapja, tehát a bányászatot kikapcsolták. Ehelyett az Ethereumot úgy biztosítják a validátorok, hogy letétbe helyeznek ETH-t. Ön is letétbe helyezheti a rendelkezésére álló ETH-t. Tudjon meg többet a egyesítés (Merge), proof-of-stake (letéti igazolás) és letétbe helyezés témákról. Ez az oldal csak elavult témákat tartalmaz. - - -Az Ethereum-bányászat egy Ethash nevű algoritmust használt. k az algoritmusnak az a lényege, hogy a bányász megpróbál egy nonce értéket találni nagy számítási kapacitás révén, hogy a létrejövő hash kisebb legyen, mint a kiszámolt nehézség határértéke. Ez a nehézségi szint dinamikusan változtatható, így a blokkok létrehozása rendszeresen meg tud történni. - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértéséhez javasoljuk, hogy előbb tekintse meg a [proof-of-work konszenzusról](/developers/docs/consensus-mechanisms/pow) és a [bányászatról](/developers/docs/consensus-mechanisms/pow/mining) szóló oldalakat. - -## Dagger Hashimoto {#dagger-hashimoto} - -A Dagger Hashimoto az Ethereum-bányászat korábbi algoritmusa volt a fejlesztés idején, melyet az Ethash váltott le. Ez két különböző algoritmus, a Dagger és a Hashimoto, összeolvadása volt. Ezt a fejlesztés idején használták, és az Ethereum főhálózat bevezetésekor már az Ethash működött. - -A [Dagger](http://www.hashcash.org/papers/dagger.html) bevezette az [irányított aciklikus gráf (Directed Acyclic Graph)](https://en.wikipedia.org/wiki/Directed_acyclic_graph) generációját, melyeknek véletlenszerű szeleteit hashelik össze. A lényegi elve az, hogy a nonce a nagy adatfából csak egy kis részt igényel. A bányászatnál nem lehet újrakalkulálni a nonce-hoz az alfát – tehát tárolni kell a fát –, de az egy nonce értékű ellenőrzésnél ez rendben van. A Dagger a létező algoritmusok, mint a Scrypt, alternatívája volt, ami sok memóriát igényelt (memory hard), de nehéz volt ellenőrizni, hogy a memóriahasználat mikor éri el a valóban biztonságos szintet. A Dagger ugyanakkor sebezhető volt a megosztott memóriaalapú hardver-gyorsítás esetén, ezért a kutatás során elvetették. - -A [Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) egy olyan algoritmus, amely ASIC-ellenállást biztosít az I/O bound révén (mivel a memóriaolvasások a bányászat behatároló tényezői). A lényeg az, hogy a RAM elérhetőbb, mint a számítási kapacitás; sok milliárd dollárnyi kutatás már optimalizálta a RAM használatot különféle esetekre, ami gyakran szinte véletlenszerű elérési mintákat (tehát a véletlenszerű memóriaelérést is) foglal magában. Ennek eredményeként a meglévő RAM elég közel van az optimálishoz, hogy értékelje az algoritmust. A Hashimoto a blokkláncot adatforrásnak használta, így megfelelt a fenti (1) és (3) pontoknak. - -A Dagger-Hashimoto a Dagger és a Hashimoto algoritmusok módosított változatát használta. A Dagger-Hashimoto és a Hashimoto között az a különbség, hogy nem blokkláncot használ adatforrásként, hanem egy személyre szabott adathalmazt, amely a blokkadatokból frissül minden N-edik blokknál. Az adathalmaz a Dagger-algoritmussal készült, amellyel hatékonyan lehetett minden nonce-ra egy alhalmazt kikalkulálni a könnyű kliens ellenőrzéshez. A Dagger-Hashimoto és a Dagger közötti különbség az, hogy a blokklekérdezéshez használt adathalmaz félig állandó, és esetileg frissítik (például hetente). Így az adathalmaz létrehozásának erőfeszítése nullához közelít, így a megosztott memória felgyorsításával kapcsolatos problémák (lásd Sergio Lerner) elhanyagolhatóvá váltak. - -Bővebben a [Dagger-Hashimoto algoritmusról](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto). - -## Ethash {#ethash} - -Az Ethash az a bányászati algoritmus, melyet az Ethereum főhálózaton használtak a ma már kivezetett proof-of-work architektúrában. Az Ethash az új neve a Dagger-Hashimoto egy specifikus verziójának, mivel azt jelentősen megváltoztatták, de mégis megmaradtak az alapvető elvei az elődjének. Az Ethereum-főhálózat csak az Ethasht használta, mivel a Dagger-Hashimoto a kutatás-fejlesztés idején működött, és még a bányászat megkezdése előtt lecserélték. - -[Bővebben az Ethash-ről](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash). - -## További olvasnivaló {#further-reading} - -_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" deleted file mode 100644 index 31dc9b44563..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/backend/index.md" +++ /dev/null @@ -1,207 +0,0 @@ ---- -title: Backend API könyvtárak -description: Bevezetés az Ethereum kliens API-okba, melyek lehetővé teszik, hogy interakcióba lépj a blokklánccal az alkalmazásodban. -lang: hu ---- - -Ahhoz, hogy egy szoftver alkalmazás interakcióba lépjen az Ethereum blokklánccal (vagyis képes legyen blokklánc adatok olvasására és/vagy tranzakció küldésre a hálózatra), rá kell csatlakoznia egy Ethereum csomópontra. - -Erre a célra minden Ethereum-kliens implementálja a [JSON-RPC](/developers/docs/apis/json-rpc/) specifikációt, így egységes [metódusok](/developers/docs/apis/json-rpc/#json-rpc-methods) állnak rendelkezésre, amelyekre az alkalmazások támaszkodhatnak. - -Ha egy bizonyos programnyelvet szeretne használni, hogy kapcsolódjon egy Ethereum csomóponttal, akkor számos könyvtár létezik az ökoszisztémán belül, melyek megkönnyítik ezt. Ezekkel a könyvtárakkal a fejlesztők intuitív, egysoros metódusokat írhatnak, hogy kezdeményezzenek egy JSON RPC kérést (a háttérben), mely interakcióba lép az Ethereummal. - -## Előfeltételek {#prerequisites} - -Érdemes lehet előbb alaposan megismerni az [Ethereum stacket](/developers/docs/ethereum-stack/) és az [Ethereum-klienseket](/developers/docs/nodes-and-clients/). - -## Miért használj egy könyvtárat? {#why-use-a-library} - -Ezek a könyvtárak elveszik a komplexitás nagy részét, mely Ethereum csomóponthoz történő közvetlen csatlakozással jár. Ezenkívül használati függvényeket is szolgáltatnak (pl.: ETH konvertálása Gwei-be), így fejlesztőként kevesebb időt kell az Ethereum kliensek bonyodalmaival foglalkoznod és több időd jut egyedi funkcionalitást kialakítani az alkalmazásodnak. - -## Elérhető könyvtárak {#available-libraries} - -### Infrastruktúra és csomóponti szolgáltatások {#infrastructure-and-node-services} - -**Alchemy -** **_Ethereum Fejlesztési Platform._** - -- [alchemy.com](https://www.alchemy.com/) -- [Dokumentáció](https://docs.alchemy.com/) -- [GitHub](https://github.com/alchemyplatform) -- [Discord](https://discord.com/invite/alchemyplatform) - -**All That Node -** **_Csomópont mint szolgáltatás._** - -- [All That Node.com](https://www.allthatnode.com/) -- [Dokumentáció](https://docs.allthatnode.com) -- [Discord](https://discord.gg/GmcdVEUbJM) - -**Blast by Bware Labs -** **_Decentralizált API-k az Ethereum főhálózatra és teszthálózatokra._** - -- [blastapi.io](https://blastapi.io/) -- [Dokumentáció](https://docs.blastapi.io) -- [Discord](https://discord.gg/bwarelabs) - -**BlockPi -** **_Hatékonyabb és gyorsabb RPC-szolgáltatások_** - -- [blockpi.io](https://blockpi.io/) -- [Dokumentáció](https://docs.blockpi.io/) -- [GitHub](https://github.com/BlockPILabs) -- [Discord](https://discord.com/invite/xTvGVrGVZv) - -**Cloudflare Ethereum Gateway.** - -- [cloudflare-eth.com](https://www.cloudflare.com/application-services/products/web3/) - -**Etherscan - Blokkfelfedező és tranzakciós API-ok** -- [Dokumentáció](https://docs.etherscan.io/) - -**GetBlock-** **_Blokklánc mint szolgáltatás a Web3 fejlesztéshez_** - -- [GetBlock.io](https://getblock.io/) -- [Dokumentáció](https://getblock.io/docs/) - -**Infura -** **_Az Ethereum API, mint szolgáltatás._** - -- [infura.io](https://infura.io) -- [Dokumentáció](https://docs.infura.io/api) -- [GitHub](https://github.com/INFURA) - -**Node RPC - _Költséghatékony EVM JSON-RPC szolgáltató_** - -- [noderpc.xyz](https://www.noderpc.xyz/) -- [Dokumentáció](https://docs.noderpc.xyz/node-rpc) - -**NOWNodes – _Teljes csomópontok és blokkfelfedezők._** - -- [NOWNodes.io](https://nownodes.io/) -- [Dokumentáció](https://documenter.getpostman.com/view/13630829/TVmFkLwy#intro) - -**QuickNode -** **_Blokklánc-infrastruktúra mint szolgáltatás._** - -- [quicknode.com](https://quicknode.com) -- [Dokumentáció](https://www.quicknode.com/docs/welcome) -- [Discord](https://discord.gg/quicknode) - -**Rivet -** **_Ethereum és Ethereum Classic API-k mint szolgáltatás, amelyeket nyílt forráskódú szoftver működtet._** - -- [rivet.cloud](https://rivet.cloud) -- [Dokumentáció](https://rivet.cloud/docs/) -- [GitHub](https://github.com/openrelayxyz/ethercattle-deployment) - -**Zmok -** **_Sebességorientált Ethereum-csomópontok mint JSON-RPC/WebSockets API._** - -- [zmok.io](https://zmok.io/) -- [GitHub](https://github.com/zmok-io) -- [Dokumentáció](https://docs.zmok.io/) -- [Discord](https://discord.gg/fAHeh3ka6s) - -### Fejlesztőeszközök {#development-tools} - -ethers-kt – **_Async, nagy teljesítményű Kotlin/Java/Android könyvtár EVM-alapú blokkláncokhoz._** - -- [GitHub](https://github.com/Kr1ptal/ethers-kt) -- [Példák](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) -- [Discord](https://discord.gg/rx35NzQGSb) - -**Nethereum -** **_Egy nyílt forráskódú .NET integrációs könyvtár blokkláncoknak._** - -- [GitHub](https://github.com/Nethereum/Nethereum) -- [Dokumentáció](http://docs.nethereum.com/en/latest/) -- [Discord](https://discord.com/invite/jQPrR58FxX) - -**Python Tooling -** **_Különféle Ethereum-könyvtárak Python-nal való interakciókhoz_** - -- [py.ethereum.org](https://python.ethereum.org/) -- [web3.py GitHub](https://github.com/ethereum/web3.py) -- [web3.py Chat](https://gitter.im/ethereum/web3.py) - -**Tatum -** **_A végső blokklánc-fejlesztési platform._** - -- [Tatum](https://tatum.io/) -- [GitHub](https://github.com/tatumio/) -- [Dokumentáció](https://docs.tatum.io/) -- [Discord](https://discord.gg/EDmW3kjTC9) - -**web3j -** **_Java/Android/Kotlin/Scala integrációs könyvtár Ethereumra._** - -- [GitHub](https://github.com/web3j/web3j) -- [Dokumentáció](https://docs.web3j.io/) -- [Gitter](https://gitter.im/web3j/web3j) - -### Blockchain-szolgáltatások {#blockchain-services} - -**BlockCypher -** **_Ethereum Web API-k._** - -- [blockcypher.com](https://www.blockcypher.com/) -- [Dokumentáció](https://www.blockcypher.com/dev/ethereum/) - -**Chainbase -** **_Teljes web3-adatinfrastruktúra az Ethereumra._** - -- [chainbase.com](https://chainbase.com/) -- [Dokumentáció](https://docs.chainbase.com/) -- [Discord](https://discord.gg/Wx6qpqz4AF) - -**Chainstack -** **_Osztott és dedikált Ethereum-csomópontok mint szolgáltatás._** - -- [chainstack.com](https://chainstack.com) -- [Dokumentáció](https://docs.chainbase.com/docs) -- [Ethereum API reference](https://docs.chainstack.com/reference/ethereum-getting-started) - -**Coinbase Cloud Node -** **_Blokklánc-infrastruktúra API._** - -- [Coinbase Cloud Node](https://www.coinbase.com/cloud) -- [Dokumentáció](https://docs.cloud.coinbase.com/) - -**DataHub by Figment -** **_Web3 API szolgáltatások az Ethereum főhálózattal és teszthálózatokkal._** - -- [DataHub](https://www.figment.io/) -- [Dokumentáció](https://docs.figment.io/) - -**Moralis -** **_Vállalati szintű EVM API-szolgáltató._** - -- [moralis.io](https://moralis.io) -- [Dokumentáció](https://docs.moralis.io/) -- [GitHub](https://github.com/MoralisWeb3) -- [Discord](https://moralis.io/joindiscord/) -- [Fórum](https://forum.moralis.io/) - -**NFTPort -** **_Ethereum-adatok és Mint API-k._** - -- [nftport.xyz](https://www.nftport.xyz/) -- [Dokumentáció](https://docs.nftport.xyz/) -- [GitHub](https://github.com/nftport/) -- [Discord](https://discord.com/invite/K8nNrEgqhE) - -**Tokenview -** **_Az általános multikripto blokklánc API-k platformja._** - -- [services.tokenview.io](https://services.tokenview.io/) -- [Dokumentáció](https://services.tokenview.io/docs?type=api) -- [GitHub](https://github.com/Tokenview) - -**Watchdata -** **_Egyszerű és megbízható API-hozzáférés az Ethereum-blokklánchoz._** - -- [Watchdata](https://watchdata.io/) -- [Dokumentáció](https://docs.watchdata.io/) -- [Discord](https://discord.com/invite/TZRJbZ6bdn) - -**Covalent –** **_Gazdagított blokklánc API-ok 200+ lánchoz._** - -- [covalenthq.com](https://www.covalenthq.com/) -- [Dokumentáció](https://www.covalenthq.com/docs/api/) -- [GitHub](https://github.com/covalenthq) -- [Discord](https://www.covalenthq.com/discord/) - - -## További olvasnivaló {#further-reading} - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) -- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) - -## Kapcsolódó útmutatók {#related-tutorials} - -- [Web3js beállítása az Ethereum-blokklánc használatához JavaScriptben](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Útmutató a web3.js projektben való beállításához.._ -- [Okosszerződés hívása JavaScriptből](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– A DAI token használatával tekintse meg, hogyan hívhat be szerződéseket a JavaScript segítségével._ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" deleted file mode 100644 index 8356791c6f7..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/javascript/index.md" +++ /dev/null @@ -1,295 +0,0 @@ ---- -title: JavaScript API könyvtárak -description: Bevezetés az JavaScript kliens könyvtárakba, melyek lehetővé teszik, hogy interakcióba lépj a blokklánccal az alkalmazásodban. -lang: hu ---- - -Ahhoz, hogy egy web alkalmazás interakcióba lépjen az Ethereum blokklánccal (vagyis képes legyen blokklánc adatok olvasására és/vagy tranzakció küldésre a hálózatra), rá kell csatlakoznia egy Ethereum csomópontra. - -Erre a célra minden Ethereum-kliens implementálja a [JSON-RPC](/developers/docs/apis/json-rpc/) specifikációt, így egységes [módszerek](/developers/docs/apis/json-rpc/#json-rpc-methods) állnak rendelkezésre, amelyekre az alkalmazások támaszkodhatnak. - -Ha JavaScript programnyelvet szeretne használni, hogy kapcsolódjon egy Ethereum csomóponthoz, lehetősége van vanilla JavaScriptet használni, de számos könyvtár létezik az ökoszisztémán belül, melyek megkönnyítik ezt. Ezekkel a könyvtárakkal a fejlesztők intuitív, egysoros metódusokat írhatnak, hogy kezdeményezzenek egy JSON RPC kérést (a háttérben), mely interakcióba lép az Ethereummal. - -Az [egyesítés (Merge)](/roadmap/merge/) után, az Ethereum szoftver két kapcsolódó darabja – egy végrehajtó kliens és egy konszenzus kliens – kell a csomópont futtatásához. Gondoskodjon arról, hogy a csomópont mindkét kliens benne legyen. Ha a csomópont nem a helyi gépen van (pl. egy AWS-en fut), akkor az IP-címet frissíteni kell az útmutatóban. Bővebb információért érdemes felkeresni a [csomópont futtatása](/developers/docs/nodes-and-clients/run-a-node/) oldalt. - -## Előfeltételek {#prerequisites} - -A JavaScript megértése mellett lehet érdemes lehet előbb alaposan megismerni az [Ethereum stacket](/developers/docs/ethereum-stack/) és az [Ethereum-klienseket](/developers/docs/nodes-and-clients/). - -## Miért használj könyvtárat? {#why-use-a-library} - -Ezek a könyvtárak elveszik a komplexitás nagy részét, mely Ethereum csomóponthoz történő közvetlen csatlakozással jár. Ezen kívül használati függvényeket is szolgáltatnak (pl.: ETH konvertálása Gwei-be), így fejlesztőként kevesebb időt kell az Ethereum kliensek bonyodalmaival foglalkoznod és több időd jut egyedi funkcionalitást kialakítani az alkalmazásodnak. - -## Könyvtár tulajdonságok {#library-features} - -### Csatlakozás Ethereum csomóponthoz {#connect-to-ethereum-nodes} - -Szolgáltatók használatakor ezen könyvtárak használatával rácsatlakozhat az Ethereumra és kiolvashatja az adatait, függetlenül attól, hogy JSON-RPC, INFURA, Etherscan, Alchemy vagy MetaMask rendszeren keresztül történik. - -**Példa az Ethers-re** - -```js -// Egy BrowserProvider bewrappol egy standard Web3 szolgáltatót, ez az -// amit a MetaMask beinjektál minden oldalra úgy mint, window.ethereum -const provider = new ethers.BrowserProvider(window.ethereum) - -// A MetaMask plugin továbbá lehetővé teszi tranzakciók aláírását -// ether küldésekor és hogy kifizessük az állapotváltást a blokkláncon. -// Ehhez kell egy számla aláíró (account signer)... -const signer = provider.getSigner() -``` - -**Példa a Web3js-re** - -```js -var web3 = new Web3("http://localhost:8545") -// vagy -var web3 = new Web3(new Web3.providers.HttpProvider("http://localhost:8545")) - -// szolgáltató (provider) váltás -web3.setProvider("ws://localhost:8546") -// vagy -web3.setProvider(new Web3.providers.WebsocketProvider("ws://localhost:8546")) - -// IPC provider használata a node.js-ben -var net = require("net") -var web3 = new Web3("/Users/myuser/Library/Ethereum/geth.ipc", net) // mac os path -// vagy -var web3 = new Web3( - new Web3.providers.IpcProvider("/Users/myuser/Library/Ethereum/geth.ipc", net) -) // mac os elérési út -// windows rendszerben az elérési út: "\\\\.\\pipe\\geth.ipc" -// linux rendszerben az elérési út: "/users/myuser/.ethereum/geth.ipc" -``` - -Amint be van állítva, lekérdezéseket indíthat a blokkláncon a következőkre: - -- blokkszámok -- gas becslések -- okosszerződés események (events) -- hálózati azonosító -- és még sok mást... - -### Tárca funkcionalitás {#wallet-functionality} - -Ezek a könyvtárak funkcionalitást adnak, hogy tárcákat hozzon létre, kulcsokat kezeljen és tranzakciókat írjon alá. - -Íme egy példa az Ethers-re - -```js -//Tárca instance létrehozása emlékeztető erősítőből... -mnemonic = - "announce room limb pattern dry unit scale effort smooth jazz weasel alcohol" -walletMnemonic = Wallet.fromPhrase(mnemonic) - -// ...or from a private key -walletPrivateKey = new Wallet(walletMnemonic.privateKey) - -walletMnemonic.address === walletPrivateKey.address -// true - -// The address as a Promise per the Signer API -walletMnemonic.getAddress() -// { Promise: '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' } - -// A Wallet address is also available synchronously -walletMnemonic.address -// '0x71CB05EE1b1F506fF321Da3dac38f25c0c9ce6E1' - -// The internal cryptographic components -walletMnemonic.privateKey -// '0x1da6847600b0ee25e9ad9a52abbd786dd2502fa4005dd5af9310b7cc7a3b25db' -walletMnemonic.publicKey -// '0x04b9e72dfd423bcf95b3801ac93f4392be5ff22143f9980eb78b3a860c4843bfd04829ae61cdba4b3b1978ac5fc64f5cc2f4350e35a108a9c9a92a81200a60cd64' - -// The wallet mnemonic -walletMnemonic.mnemonic -// { -// locale: 'en', -// path: 'm/44\'/60\'/0\'/0/0', -// phrase: 'announce room limb pattern dry unit scale effort smooth jazz weasel alcohol' -// } - -// Note: A wallet created with a private key does not -// have a mnemonic (the derivation prevents it) -walletPrivateKey.mnemonic -// null - -// Signing a message -walletMnemonic.signMessage("Hello World") -// { Promise: '0x14280e5885a19f60e536de50097e96e3738c7acae4e9e62d67272d794b8127d31c03d9cd59781d4ee31fb4e1b893bd9b020ec67dfa65cfb51e2bdadbb1de26d91c' } - -tx = { - to: "0x8ba1f109551bD432803012645Ac136ddd64DBA72", - value: utils.parseEther("1.0"), -} - -// Signing a transaction -walletMnemonic.signTransaction(tx) -// { Promise: '0xf865808080948ba1f109551bd432803012645ac136ddd64dba72880de0b6b3a7640000801ca0918e294306d177ab7bd664f5e141436563854ebe0a3e523b9690b4922bbb52b8a01181612cec9c431c4257a79b8c9f0c980a2c49bb5a0e6ac52949163eeb565dfc' } - -// The connect method returns a new instance of the -// Wallet connected to a provider -wallet = walletMnemonic.connect(provider) - -// Querying the network -wallet.getBalance() -// { Promise: { BigNumber: "42" } } -wallet.getTransactionCount() -// { Promise: 0 } - -// Sending ether -wallet.sendTransaction(tx) -``` - -[Olvassa el a teljes dokumentációt](https://docs.ethers.io/v5/api/signer/#Wallet) - -Amint be van állítva, a következőket teheti: - -- számlákat létrehozni -- tranzakciókat küldeni -- tranzakciókat aláírni -- és még sok mást... - -### Interakció okosszerződés függvényekkel {#interact-with-smart-contract-functions} - -A Javascript-kliens könyvtárai lehetővé teszik az alkalmazás számára, hogy okosszerződés-függvényeket hívjanak meg egy befordított szerződés Application Binary Interface-ének (ABI) olvasásával. - -Az ABI lényegében elmagyarázza a szerződés függvényeit egy JSON formátumban és lehetővé teszi, hogy normális Javascript-objektumként használja. - -A következő Solidity szerződés tehát: - -```solidity -contract Test { - uint a; - address d = 0x12345678901234567890123456789012; - - function Test(uint testInt) { a = testInt;} - - event Event(uint indexed b, bytes32 c); - - event Event2(uint indexed b, bytes32 c); - - function foo(uint b, bytes32 c) returns(address) { - Event(b, c); - return d; - } -} -``` - -A következő JSON-t adná: - -```json -[{ - "type":"constructor", - "payable":false, - "stateMutability":"nonpayable" - "inputs":[{"name":"testInt","type":"uint256"}], - },{ - "type":"function", - "name":"foo", - "constant":false, - "payable":false, - "stateMutability":"nonpayable", - "inputs":[{"name":"b","type":"uint256"}, {"name":"c","type":"bytes32"}], - "outputs":[{"name":"","type":"address"}] - },{ - "type":"event", - "name":"Event", - "inputs":[{"indexed":true,"name":"b","type":"uint256"}, {"indexed":false,"name":"c","type":"bytes32"}], - "anonymous":false - },{ - "type":"event", - "name":"Event2", - "inputs":[{"indexed":true,"name":"b","type":"uint256"},{"indexed":false,"name":"c","type":"bytes32"}], - "anonymous":false -}] -``` - -Ez azt jelenti, hogy: - -- Tranzakciókat küldhetsz az okosszerződésnek és végrehajthatod a metódusát -- Megbecsülheted a gast, melyet egy metódus végrehajtás fog használni, amikor lefut az EVM-en -- Telepíthetsz egy szerződést -- És még sok mást... - -### Használati függvények {#utility-functions} - -A használati függvények praktikus könnyítéseke adnak, hogy egyszerűbb legyen az Ethereumon való építés. - -Az ETH értékei alapvetően Wei-ben vannak megadva. 1 ETH = 1,000,000,000,000,000,000 WEI – ez azt jelenti, hogy sok számmal kell foglalkoznia! `web3.utils.toWei` átkonvertálja az ethert Wei-re. - -Az ethers-ben így néz ki: - -```js -// Egy számla egyenlege (cím vagy ENS név alapján) -balance = await provider.getBalance("ethers.eth") -// { BigNumber: "2337132817842795605" } - -// Gyakran formáznod kell a kimenetet a felhasználó számára -// aki etherben szeretné látni az értéket (wei helyett) -ethers.utils.formatEther(balance) -// '2.337132817842795605' -``` - -- [Web3js használati függvények](https://docs.web3js.org/api/web3-utils) -- [Ethers használati függvények](https://docs.ethers.io/v5/api/utils/) - -## Elérhető könyvtárak {#available-libraries} - -**Web3.js -** **_Ethereum JavaScript API._** - -- [Dokumentáció](https://docs.web3js.org/) -- [GitHub](https://github.com/ethereum/web3.js/) - -**Ethers.js -** **_Teljes Ethereum-tárcaimplementáció és segédprogramok JavaScript-ben és TypeScript-ben._** - -- [Dokumentáció](https://docs.ethers.io/) -- [GitHub](https://github.com/ethers-io/ethers.js/) - -**The Graph -** **_Egy Ethereum- és IPFS-adatindexelési és -lekérdezési protokoll a GraphQL használatával._** - -- [The Graph](https://thegraph.com/) -- [Graph Explorer](https://thegraph.com/explorer/) -- [Dokumentáció](https://thegraph.com/docs/) -- [GitHub](https://github.com/graphprotocol/) -- [Discord](https://thegraph.com/discord) - -**light.js -** **_Egy magas szintű, reaktív JS könyvtár könnyű kliensekre optimalizálva._** - -- [GitHub](https://github.com/openethereum/js-libs/tree/master/packages/light.js) - -**Web3-wrapper -** **_A Typescript Web3.js alternatíva._** - -- [Dokumentáció](https://0x.org/docs/web3-wrapper#introduction) -- [GitHub](https://github.com/0xProject/0x-monorepo/tree/development/packages/web3-wrapper) - -**Alchemyweb3 -** **_Egy Web3.js wrapper automatikus újrapróbálkozásokkal és továbbfejlesztett API-kkal._** - -- [Dokumentáció](https://docs.alchemy.com/reference/api-overview) -- [GitHub](https://github.com/alchemyplatform/alchemy-web3) - -**Alchemy NFT API -** **_API az NFT adat megszerzésére, beleértve a tulajdonjogot, metaadatok attribútumait stb._** - -- [Dokumentáció](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) -- [GitHub](https://github.com/alchemyplatform/alchemy-web3) - -**viem -** **_TypeScript-interfész az Ethereumra._** - -- [Dokumentáció](https://viem.sh) -- [GitHub](https://github.com/wagmi-dev/viem) - -## További olvasnivaló {#further-reading} - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) -- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) - -## Kapcsolódó útmutatók {#related-tutorials} - -- [Web3js beállítása az Ethereum-blokklánc használatához JavaScriptben](/developers/tutorials/set-up-web3js-to-use-ethereum-in-javascript/) _– Útmutató a web3.js projektben való beállításához.._ -- [Okosszerződés hívása JavaScriptből](/developers/tutorials/calling-a-smart-contract-from-javascript/) _– A DAI token használatával tekintse meg, hogyan hívhat be szerződéseket a JavaScript segítségével._ -- [Tranzakció küldése web3-mal és Alchemy-vel](/developers/tutorials/sending-transactions-using-web3-and-alchemy/) _– Egy részletes útmutató arról, hogyan lehet tranzakciókat küldeni a backendből._ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" deleted file mode 100644 index e0da2db6df4..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/apis/json-rpc/index.md" +++ /dev/null @@ -1,1773 +0,0 @@ ---- -title: JSON-RPC API -description: Egy státuszmentes, könnyű remote procedure call (RPC) protokoll az Ethereum-kliensekhez. -lang: hu ---- - -Ahhoz, hogy egy szoftveralkalmazás interakcióba lépjen az Ethereum blokklánccal –a blokkláncadatokat olvasva vagy tranzakciókat küldve a hálózatra –, rá kell csatlakoznia egy Ethereum-csomópontra. - -Ebből a célból minden [Ethereum-kliens](/developers/docs/nodes-and-clients/#execution-clients) implementálja a [JSON-RPC specifikációt](https://github.com/ethereum/execution-apis), így az alkalmazások egységesen egyféle metóduscsomagra támaszkodhatnak, függetlenül az adott csomópont vagy kliens fajtájától. - -A [JSON-RPC](https://www.jsonrpc.org/specification) egy státuszmentes, könnyű remote procedure call (RPC) protokoll. Számos adatstruktúrát, valamint ezek feldolgozásának szabályait is meghatározza. Ez a megoldás nem függ az átadási módoktól, mivel a koncepciókat használni lehet ugyanabban a folyamatban, socketeknél, HTTP-vel és számos más üzenetküldő környezetben. Az adatformátum JSON (RFC 4627). - -## Kliensimplementációk {#client-implementations} - -Az Ethereum-kliensek mindegyike használhat különböző programozási nyelveket, amikor a JSON-RPC specifikációt implementálja. Tekintse meg az egyéni [kliensdokumentációt](/developers/docs/nodes-and-clients/#execution-clients) további részletekért a specifikus programozási nyelvekről. Érdemes megnézni a kliensdokumentációt a legutóbbi API-támogatási információ miatt is. - -## Kényelmi könyvtárak {#convenience-libraries} - -Választhatja, hogy az Ethereum-kliensekkel közvetlenül kapcsolódik a JSON-RPC API révén, de az alkalmazásfejlesztők rendelkezésére állnak egyszerűbb opciók is. Számos [JavaScript](/developers/docs/apis/javascript/#available-libraries) és [backend API](/developers/docs/apis/backend/#available-libraries) könyvtár létezik, hogy a JSON-RPC API tetejére egy wrappert (burkoló réteget) adjon. Ezekkel a könyvtárakkal a fejlesztők intuitív, egysoros metódusokat írhatnak, hogy JSON-RPC-kérést kezdeményezzenek (a háttérben), amely interakcióba lép az Ethereummal. - -## Konszenzusos kliens API-k {#consensus-clients} - -Ez az írás főleg a JSON-RPC API-val foglalkozik, melyet az Ethereum végrehajtási kliensei használnak. Ugyanakkor a konszenzusos klienseknek is van egy RPC API-ja, amellyel a felhasználók lekérhetnek információkat a csomópontról, Beacon-blokkokról, Beacon-státuszokról és más konszenzussal kapcsolatos adatokról közvetlenül a csomópontról. Ez az API a [Beacon API honlapon](https://ethereum.github.io/beacon-APIs/#/) van dokumentálva. - -Egy belső API-t használnak a kliensek közötti kommunikációra a csomóponton belül, így a konszenzusos kliens és a végrehajtási kliens képes adatot cserélni. Ezt nevezik Motor API-nak, amelynek specifikációja a [GitHubon](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) érhető el. - -## Végrehajtási kliens specifikációi {#spec} - -[Tekintse meg a teljes JSON-RPC API specifikációt a GitHubon](https://github.com/ethereum/execution-apis). Ez az API a [Végrehajtási API oldalon](https://ethereum.github.io/execution-apis/api-documentation/) van dokumentálva, és tartalmaz egy ellenőrt, hogy a rendelkezésre álló metódusokat ki lehessen próbálni. - -## Egyezmények {#conventions} - -### Hexadecimális értékű kódolás {#hex-encoding} - -Két fontos adattípus megy át a JSON-ön: formázatlan bájttömbök és mennyiségek. Mindkettő hexadecimális kódolásban van elküldve, de más a formázási követelmény. - -#### Mennyiségek {#quantities-encoding} - -A mennyiségek (egész számok, számok) kódolásánál: hexadecimálisban, „0x” előtaggal, a legtömörebb kifejeződésben kell kódolni (kivéve a nullát, mert az „0x0” lesz). - -Néhány példa: - -- 0x41 (65 decimálisban) -- 0x400 (1024 decimálisban) -- HELYTELEN: 0x (legalább egy számjegy még szükséges, a nulla írása „0x0”) -- HELYTELEN: 0x0400 (nem kezdődhet nullával a szám) -- HELYTELEN: ff (a 0x előtagot ki kell tenni) - -### Formázatlan adat {#unformatted-data-encoding} - -Amikor formázatlan adatot (bájtsorok, számlacímek, hashek, bájtkódtömbök) kell kódolni: hexadecimálisban, „0x” előtaggal, két hex számjegy bájtonként. - -Néhány példa: - -- 0x41 (1-es méret, „A”) -- 0x004200 (3-as méret, „0B0”) -- 0x (size 0, "") -- HELYTELEN: 0xf0f0f (páros számú kell legyen) -- HELYTELEN: 004200 (a 0x előtagot ki kell tenni) - -### Az alapértelmezett blokkparaméter {#default-block} - -A következő metódusok egy extra alapértelmezett blokkparaméterrel rendelkeznek: - -- [eth_getBalance](#eth_getbalance) -- [eth_getCode](#eth_getcode) -- [eth_getTransactionCount](#eth_gettransactioncount) -- [eth_getStorageAt](#eth_getstorageat) -- [eth_call](#eth_call) - -Amikor az Ethereum státuszát érintő kérések érkeznek, akkor a legutolsó alapértelmezett blokkparaméter határozza meg a blokk méretét. - -A defaultBlock paraméter a következők lehetnek: - -- `HEX String` – egy egész szám mint blokkszám -- `String "earliest"` – a legkorábbi/genezis blokk -- `String "latest"` – a legutóbb javasolt blokk -- `String "safe"` – a blokk legutóbbi biztonságos feje -- `String "finalized"` – a legutóbbi véglegesedett blokk -- `String "pending"` – a függőben lévő státusz/tranzakciók esetében - -## Példák - -Ebben a leírásban példákat mutatunk be, hogyan lehet használni az egyéni JSON_RPC API végpontokat a parancssoreszközzel, ami a [curl](https://curl.se). Ezek az egyéni végpontpéldák a [Curl példák](#curl-examples) szekciókban találhatók alább. Ezek után bemutatunk egy [példát az elejétől a végéig](#usage-example) egy okosszerződés átfordítására és telepítésére egy Geth csomópont, a JSON_RPC API és a curl használatával. - -## Példák a curlre {#curl-examples} - -Alább láthatók azok a példák, amikor a JSON_RPC API-t használjuk egy [curl](https://curl.se) kérést létrehozva egy Ethereum-csomópontnak. Minden példa tartalmazza az adott végpont specifikációit, paramétereit, visszatérési típusát és egy működő példát arról, hogyan kell használni. - -A curl-kérések hibát adhatnak vissza a tartalom típusa miatt. Ennek az az oka, hogy a `--data` opció beállítja a tartalomtípust `application/x-www-form-urlencoded` értékre. Ha az Ön által használt csomópontnak ez nem tetszik, akkor manuálisa állítsa át a fejlécet, hogy a `-H "Content-Type: application/json"` a hívás elején legyen. A példák nem tartalmazzák az URL/IP és port kombinációját, amit a curl utolsó változójaként kell megadni (például `127.0.0.1:8545`). Egy komplett curl-kérés, amely ezeket a plusz adatokat is tartalmazza, így néz ki: - -```shell -curl -H "Content-Type: application/json" -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' 127.0.0.1:8545 -``` - -## Pletyka, státusz, előzményadatok {#gossip-state-history} - -Néhány központi JSON-RPC metódushoz szükség van az Ethereum hálózati adataira, amelyek általában háromfélék lehetnek: _Pletyka, státusz és előzményadatok_. Az ebben a részben található hivatkozások segítségével az adott metódusra tud lépni, de a tartalomjegyzéket is használhatja a metódusok teljes listájának megtekintéséhez. - -### Pletyka metódusok {#gossip-methods} - -> Ezek a metódusok a lánc fejét követik nyomon. Így kerülnek be tranzakciók a hálózatra, találják meg az útjukat a blokkokba, és az, a kliensek így szereznek tudomást az új blokkokról. - -- [eth_blockNumber](#eth_blocknumber) -- [eth_sendRawTransaction](#eth_sendrawtransaction) - -### Státusz metódusok {#state_methods} - -> Olyan metódusok, melyek az összes tárolt adat jelenlegi státuszát riportálják. A „státusz” olyan, akár egy nagy, megosztott RAM rész, ami számlaegyenlegeket, szerződésadatokat és gázbecsléseket tartalmaz. - -- [eth_getBalance](#eth_getbalance) -- [eth_getStorageAt](#eth_getstorageat) -- [eth_getTransactionCount](#eth_gettransactioncount) -- [eth_getCode](#eth_getcode) -- [eth_call](#eth_call) -- [eth_estimateGas](#eth_estimategas) - -### Előzményadatok metódusok {#history_methods} - -> Minden egyes blokkból képes előzményadatokat lekérni egészen a genezisig. Olyan mint egy hatalmas, egyre bővülő fájl, amely tartalmazza az összes blokkfejlécet, blokkadatot, a szülőblokk testvérblokkjait (ommer/uncle) és a tranzakció-visszaigazolásokat. - -- [eth_getBlockTransactionCountByHash](#eth_getblocktransactioncountbyhash) -- [eth_getBlockTransactionCountByNumber](#eth_getblocktransactioncountbynumber) -- [eth_getUncleCountByBlockHash](#eth_getunclecountbyblockhash) -- [eth_getUncleCountByBlockNumber](#eth_getunclecountbyblocknumber) -- [eth_getBlockByHash](#eth_getblockbyhash) -- [eth_getBlockByNumber](#eth_getblockbynumber) -- [eth_getTransactionByHash](#eth_gettransactionbyhash) -- [eth_getTransactionByBlockHashAndIndex](#eth_gettransactionbyblockhashandindex) -- [eth_getTransactionByBlockNumberAndIndex](#eth_gettransactionbyblocknumberandindex) -- [eth_getTransactionReceipt](#eth_gettransactionreceipt) -- [eth_getUncleByBlockHashAndIndex](#eth_getunclebyblockhashandindex) -- [eth_getUncleByBlockNumberAndIndex](#eth_getunclebyblocknumberandindex) - -## JSON-RPC API próbafelület - -Az API-módszerek felfedezéséhez és kipróbálásához használhatja a [próbaeszközt](https://ethereum-json-rpc.com). Azt is megmutatja, hogy a különböző csomópontszolgáltatók milyen metódusokat és hálózatokat támogatnak. - -## JSON-RPC API metódusok {#json-rpc-methods} - -### web3_clientVersion {#web3_clientversion} - -Visszaadja a jelenlegi kliensverziót. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`String` – A jelenlegi kliensverzió - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":67}' -// Result -{ - "id":67, - "jsonrpc":"2.0", - "result": "Geth/v1.12.1-stable/linux-amd64/go1.19.1" -} -``` - -### web3_sha3 {#web3_sha3} - -Visszaadja az adott adat keccak-256 szerinti értékét (_nem_ a szabványosított SHA3-256 szerintit). - -**Paraméterek** - -1. `DATA` – Az adatok átkonvertálva SHA3 hash formátumba - -```js -params: ["0x68656c6c6f20776f726c64"] -``` - -**Visszaad** - -`DATA` – Az adott sztring SHA3-eredménye. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"web3_sha3","params":["0x68656c6c6f20776f726c64"],"id":64}' -// Result -{ - "id":64, - "jsonrpc": "2.0", - "result": "0x47173285a8d7341e5e972fc677286384f802f8ef42a5ec5f03bbfa254cb01fad" -} -``` - -### net_version {#net_version} - -Visszaadja a jelenlegi hálózati azonosítót. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`String` – Jelenlegi hálózati azonosító. - -A jelenlegi hálózati azonosítók teljes listája a [chainlist.org](https://chainlist.org) oldalon érhető el. Néhány jellemző példa: - -- `1`: Ethereum főhálózata -- `5`: Goerli teszthálózat -- `11155111`: Sepolia teszthálózat - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"net_version","params":[],"id":67}' -// Result -{ - "id":67, - "jsonrpc": "2.0", - "result": "3" -} -``` - -### net_listening {#net_listening} - -A `true` értéket adja vissza, ha a kliens aktívan hallgatja a hálózati kapcsolatokat. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`Boolean` – `true`, amikor hallgatja, máskülönben `false`. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"net_listening","params":[],"id":67}' -// Result -{ - "id":67, - "jsonrpc":"2.0", - "result":true -} -``` - -### net_peerCount {#net_peercount} - -Visszaadja a társak számát, amelyek jelenleg a klienshez kapcsolódnak. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`QUANTITY` – a kapcsolódó társak száma egész számként. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":74}' -// Result -{ - "id":74, - "jsonrpc": "2.0", - "result": "0x2" // 2 -} -``` - -### eth_protocolVersion {#eth_protocolversion} - -A jelenlegi Ethereum-protokollverziót adja vissza. Vegye figyelembe, hogy ez a metódus [a Geth-ben nem érhető el](https://github.com/ethereum/go-ethereum/pull/22064#issuecomment-788682924). - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`String` – Az Ethereum jelenlegi protokollverziója - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_protocolVersion","params":[],"id":67}' -// Result -{ - "id":67, - "jsonrpc": "2.0", - "result": "54" -} -``` - -### eth_syncing {#eth_syncing} - -Egy objektumot ad vissza a szinkronizálási státuszról szóló adattal vagy `false`. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -A pontos visszakapott adat a kliensimplementációk szerint változik. Minden kliens `false` értéket küld, amikor a csomópont nem szinkronizál, és mindegyik elküldi a következő mezőket. - -`Object|Boolean`, egy objektum a szinkronizálási státuszról szóló adattal vagy `false`, amikor nem szinkronizál: - -- `startingBlock`: `QUANTITY` – Az a blokk, amelynél az importálása kezdődött (csak akkor lesz visszaállítva, miután a szinkronizálás elérte a fejet) -- `currentBlock`: `QUANTITY` – A jelenlegi blokk, azonos az eth_blockNumber mezővel -- `highestBlock`: `QUANTITY` – A becsült legnagyobb számú blokk - -Ugyanakkor az egyéni kliensek további adatokat is adhatnak. A Geth például ezt küldi vissza: - -```json -{ - "jsonrpc": "2.0", - "id": 1, - "result": { - "currentBlock": "0x3cf522", - "healedBytecodeBytes": "0x0", - "healedBytecodes": "0x0", - "healedTrienodes": "0x0", - "healingBytecode": "0x0", - "healingTrienodes": "0x0", - "highestBlock": "0x3e0e41", - "startingBlock": "0x3cbed5", - "syncedAccountBytes": "0x0", - "syncedAccounts": "0x0", - "syncedBytecodeBytes": "0x0", - "syncedBytecodes": "0x0", - "syncedStorage": "0x0", - "syncedStorageBytes": "0x0" - } -} -``` - -Amíg a Besu ezt küldi vissza: - -```json -{ - "jsonrpc": "2.0", - "id": 51, - "result": { - "startingBlock": "0x0", - "currentBlock": "0x1518", - "highestBlock": "0x9567a3", - "pulledStates": "0x203ca", - "knownStates": "0x200636" - } -} -``` - -Tekintse meg az adott kliens dokumentációját a további adatokért. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": { - startingBlock: '0x384', - currentBlock: '0x386', - highestBlock: '0x454' - } -} -// Or when not syncing -{ - "id":1, - "jsonrpc": "2.0", - "result": false -} -``` - -### eth_coinbase {#eth_coinbase} - -A kliens coinbase-címét adja vissza. - -> **Megjegyzés:** Ez a metódus a **v1.14.0** óta elavult, és már nem támogatott. Ha megpróbálja használni ezt a metódust, a „Nem támogatott metódus” hibaüzenetet kapja. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`DATA`, 20 bájt – a jelenlegi coinbase címe. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_coinbase","params":[],"id":64}' -// Result -{ - "id":64, - "jsonrpc": "2.0", - "result": "0x407d73d8a49eeb85d32cf465507dd71d507100c1" -} -``` - -### eth_chainId {#eth_chainId} - -Visszaadja a láncazonosítót, amellyel az újrajátszástól védett tranzakciókat írják alá. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`chainId`, hexadecimális érték mint sztring, amely a jelenlegi láncazonosítót mutatja egész számként. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":67}' -// Result -{ - "id":67, - "jsonrpc": "2.0", - "result": "0x1" -} -``` - -### eth_mining {#eth_mining} - -A visszaadott érték `true`, ha a kliens aktívan bányászik új blokkokat. Ez csak proof-of-work hálózatok esetén küld vissza `true` értéket, és talán a [egyesítés (Merge)](/roadmap/merge/) óta nincs is benne minden kliensben. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`Boolean` – `true` értéket ad vissza, ha a kliens bányászik, különben `false`. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_mining","params":[],"id":71}' -// -{ - "id":71, - "jsonrpc": "2.0", - "result": true -} -``` - -### eth_hashrate {#eth_hashrate} - -Visszaadja a hashek számát másodpercenként, amellyel a csomópont a bányászatot végzi. Ez csak proof-of-work hálózatok esetén küld vissza `true` értéket, és talán a [egyesítés (Merge)](/roadmap/merge/) óta nincs is benne minden kliensben. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`QUANTITY` – hashek száma másodpercenként. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_hashrate","params":[],"id":71}' -// Result -{ - "id":71, - "jsonrpc": "2.0", - "result": "0x38a" -} -``` - -### eth_gasPrice {#eth_gasprice} - -Visszaadja a jelenlegi becsült gázárat wei-ben. Például a Besu kliens megvizsgálja az utolsó 100 blokkot, és a gáz egységárának mediánját küldi vissza alapból. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`QUANTITY` – a jelenlegi gázár wei-ben egész számként. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_gasPrice","params":[],"id":73}' -// Result -{ - "id":73, - "jsonrpc": "2.0", - "result": "0x1dfd14000" // 8049999872 Wei -} -``` - -### eth_accounts {#eth_accounts} - -A kliens által birtokolt címek listáját adja vissza. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`Array of DATA`, 20 bájt – a kliens által birtokolt címek. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": ["0x407d73d8a49eeb85d32cf465507dd71d507100c1"] -} -``` - -### eth_blockNumber {#eth_blocknumber} - -A legutóbbi blokk számát adja vissza. - -**Paraméterek** - -Egyik sem - -**Visszaad** - -`QUANTITY` – a legutóbbi blokk száma egész számként, amelynél a kliens tart. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":83}' -// Result -{ - "id":83, - "jsonrpc": "2.0", - "result": "0x4b7" // 1207 -} -``` - -### eth_getBalance {#eth_getbalance} - -Az adott cím számlaegyenlegét adja vissza. - -**Paraméterek** - -1. `DATA`, 20 bájt – cím, melynek az egyenlegét ellenőrizzük. -2. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) - -```js -params: ["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"] -``` - -**Visszaad** - -`QUANTITY` – a jelenlegi egyenleg wei-ben egész számként. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBalance","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1", "latest"],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x0234c8a3397aab58" // 158972490234375000 -} -``` - -### eth_getStorageAt {#eth_getstorageat} - -Egy adott címen lévő tárhely pozícióját adja vissza. - -**Paraméterek** - -1. `DATA`, 20 bájt – a tárhely címe. -2. `QUANTITY` – a tárhelyben lévő pozíció egész számként. -3. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) - -**Visszaad** - -`DATA` – az adott tárhelypozíció értéke. - -**Példa** Kiszámolja a pontos pozíciót, a visszakapott tárhely függvényében. Vegyük a következő szerződést, ami itt van telepítve: `0x295a70b2de5e3953354a6a8344e616ed314d7251`, ezzel a címmel:`0x391694e7e0b0cce554cb130d723a9d27458f9298`. - -``` -contract Storage { - uint pos0; - mapping(address => uint) pos1; - function Storage() { - pos0 = 1234; - pos1[msg.sender] = 5678; - } -} -``` - -A pos0 érték megszerzése egyértelmű: - -```js -curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 -{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} -``` - -A térkép egyik elemének megszerzése már nehezebb. A térképen egy elem pozícióját így kalkuláljuk: - -```js -keccak(LeftPad32(key, 0), LeftPad32(map position, 0)) -``` - -Ahhoz, hogy megszerezzük a tárhelyet a pos1["0x391694e7e0b0cce554cb130d723a9d27458f9298"] tekintetében, a pozíciót így kell kalkulálni: - -```js -keccak( - decodeHex( - "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + - "0000000000000000000000000000000000000000000000000000000000000001" - ) -) -``` - -A web3-könyvtárban található Geth konzolt lehet használni a kalkulációhoz: - -```js -> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" -undefined -> web3.sha3(key, {"encoding": "hex"}) -"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" -``` - -Most pedig a tárhely megszerzése: - -```js -curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 -{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} -``` - -### eth_getTransactionCount {#eth_gettransactioncount} - -Visszaadja a tranzakciók számát, amelyeket egy adott címről _küldtek_. - -**Paraméterek** - -1. `DATA`, 20 bájt – cím. -2. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) - -```js -params: [ - "0x407d73d8a49eeb85d32cf465507dd71d507100c1", - "latest", // state at the latest block -] -``` - -**Visszaad** - -`QUANTITY` – a tranzakciók száma egész számként, amit erről a címről küldtek. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionCount","params":["0x407d73d8a49eeb85d32cf465507dd71d507100c1","latest"],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x1" // 1 -} -``` - -### eth_getBlockTransactionCountByHash {#eth_getblocktransactioncountbyhash} - -Visszaadja a tranzakciók számát egy blokkban, egy olyan blokkból, mely egyezik a megadott blokkhashsel. - -**Paraméterek** - -1. `DATA`, 32 bájt – blokkhash - -```js -params: ["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"] -``` - -**Visszaad** - -`QUANTITY` – ebben a blokkban lévő tranzakciók száma egész számként. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash","params":["0xd03ededb7415d22ae8bac30f96b2d1de83119632693b963642318d87d1bece5b"],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x8b" // 139 -} -``` - -### eth_getBlockTransactionCountByNumber {#eth_getblocktransactioncountbynumber} - -Visszaadja a tranzakciók számát egy blokkban, amely az adott blokkszámnak felel meg. - -**Paraméterek** - -1. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek az [alapértelmezett blokkparaméterek](/developers/docs/apis/json-rpc/#default-block) szerint. - -```js -params: [ - "0x13738ca", // 20396234 -] -``` - -**Visszaad** - -`QUANTITY` – ebben a blokkban lévő tranzakciók száma egész számként. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByNumber","params":["0x13738ca"],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x8b" // 139 -} -``` - -### eth_getUncleCountByBlockHash {#eth_getunclecountbyblockhash} - -Visszaadja az uncle-blokkok számát egy olyan blokkból, ami a blokkhashnek megfelel. - -**Paraméterek** - -1. `DATA`, 32 bájt – blokkhash - -```js -params: ["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"] -``` - -**Visszaad** - -`QUANTITY` – ebben a blokkban az uncle-blokkok száma egész számként. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockHash","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2"],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x1" // 1 -} -``` - -### eth_getUncleCountByBlockNumber {#eth_getunclecountbyblocknumber} - -Visszaadja az uncle-blokkok számát egy olyan blokkból, ami egy adott blokkszámnak megfelel. - -**Paraméterek** - -1. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) - -```js -params: [ - "0xe8", // 232 -] -``` - -**Visszaad** - -`QUANTITY` – ebben a blokkban az uncle-blokkok száma egész számként. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleCountByBlockNumber","params":["0xe8"],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x0" // 0 -} -``` - -### eth_getCode {#eth_getcode} - -Visszaadja az adott címen lévő kódot. - -**Paraméterek** - -1. `DATA`, 20 bájt – cím -2. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) - -```js -params: [ - "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", - "0x5daf3b", // 6139707 -] -``` - -**Visszaad** - -`DATA` – a kód az adott címről. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getCode","params":["0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2", "0x5daf3b"],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x6060604052600436106100af576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146100b9578063095ea7b31461014757806318160ddd146101a157806323b872dd146101ca5780632e1a7d4d14610243578063313ce5671461026657806370a082311461029557806395d89b41146102e2578063a9059cbb14610370578063d0e30db0146103ca578063dd62ed3e146103d4575b6100b7610440565b005b34156100c457600080fd5b6100cc6104dd565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561010c5780820151818401526020810190506100f1565b50505050905090810190601f1680156101395780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561015257600080fd5b610187600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061057b565b604051808215151515815260200191505060405180910390f35b34156101ac57600080fd5b6101b461066d565b6040518082815260200191505060405180910390f35b34156101d557600080fd5b610229600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803590602001909190505061068c565b604051808215151515815260200191505060405180910390f35b341561024e57600080fd5b61026460048080359060200190919050506109d9565b005b341561027157600080fd5b610279610b05565b604051808260ff1660ff16815260200191505060405180910390f35b34156102a057600080fd5b6102cc600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610b18565b6040518082815260200191505060405180910390f35b34156102ed57600080fd5b6102f5610b30565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561033557808201518184015260208101905061031a565b50505050905090810190601f1680156103625780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b341561037b57600080fd5b6103b0600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091908035906020019091905050610bce565b604051808215151515815260200191505060405180910390f35b6103d2610440565b005b34156103df57600080fd5b61042a600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610be3565b6040518082815260200191505060405180910390f35b34600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055503373ffffffffffffffffffffffffffffffffffffffff167fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c346040518082815260200191505060405180910390a2565b60008054600181600116156101000203166002900480601f0160208091040260200160405190810160405280929190818152602001828054600181600116156101000203166002900480156105735780601f1061054857610100808354040283529160200191610573565b820191906000526020600020905b81548152906001019060200180831161055657829003601f168201915b505050505081565b600081600460003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b60003073ffffffffffffffffffffffffffffffffffffffff1631905090565b600081600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054101515156106dc57600080fd5b3373ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff16141580156107b457507fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205414155b156108cf5781600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541015151561084457600080fd5b81600460008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055505b81600360008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000206000828254039250508190555081600360008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825401925050819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205410151515610a2757600080fd5b80600360003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020600082825403925050819055503373ffffffffffffffffffffffffffffffffffffffff166108fc829081150290604051600060405180830381858888f193505050501515610ab457600080fd5b3373ffffffffffffffffffffffffffffffffffffffff167f7fcf532c15f0a6db0bd6d0e038bea71d30d808c7d98cb3bf7268a95bf5081b65826040518082815260200191505060405180910390a250565b600260009054906101000a900460ff1681565b60036020528060005260406000206000915090505481565b60018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610bc65780601f10610b9b57610100808354040283529160200191610bc6565b820191906000526020600020905b815481529060010190602001808311610ba957829003601f168201915b505050505081565b6000610bdb33848461068c565b905092915050565b60046020528160005260406000206020528060005260406000206000915091505054815600a165627a7a72305820deb4c2ccab3c2fdca32ab3f46728389c2fe2c165d5fafa07661e4e004f6c344a0029" -} -``` - -### eth_sign {#eth_sign} - -Az aláírás metódus kikalkulál egy Ethereum-specifikus aláírást a következővel: `sign(keccak256("\x19Ethereum Signed Message:\n" + len(message) + message)))`. - -Ha az üzenethez egy előtagot adunk, akkor a kikalkulált aláírást úgy ismeri fel, mint Ethereum-specifikus aláírás. Ez megakadályozza a rosszhiszemű felhasználást, amikor egy támadó alkalmazás tetszőleges adatokat (például tranzakciókat) ír alá, és arra használja az aláírást, hogy megszemélyesítse áldozatát. - -Megjegyzés: az aláíráshoz olyan cím kell, amely nincs zárolva. - -**Paraméterek** - -1. `DATA`, 20 bájt – cím -2. `DATA`, N bájt – az aláírandó üzenet - -**Visszaad** - -`DATA`: Aláírás - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sign","params":["0x9b2055d370f73ec7d8a03e965129118dc8f5bf83", "0xdeadbeaf"],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" -} -``` - -### eth_signTransaction {#eth_signtransaction} - -Aláír egy olyan tranzakciót, amelyet egy későbbi időpontban be lehet küldeni a hálózatra az [eth_sendRawTransaction](#eth_sendrawtransaction) segítségével. - -**Paraméterek** - -1. `Object` – A tranzakcióobjektum - -- `type`: -- `from`: `DATA`, 20 bájt – A cím, amelyről a tranzakció érkezett. -- `to`: `DATA`, 20 bájt – (opcionális új szerződés létrehozásakor) A tranzakció címzettjének címe. -- `gas`: `QUANTITY` – (opcionális, alapértelmezett: 90 000) A tranzakció végrehajtásához biztosított gáz egész számban megadva. Visszaküldi a fel nem használt gázt. -- `gasPrice`: `QUANTITY` – (opcionális, alapértelmezett: To-Be-Determined) a gasPrice (gázár) egész számként, ami a wei-ben fizetendő gázra vonatkozik. -- `value`: `QUANTITY` – (opcionális) a tranzakcióban küldött érték egész számként, wei-ben. -- `data`: `DATA` – A szerződés kódjának átfordítása VAGY a meghívott metódus aláírásának és kódolt paramétereinek a hashe. -- `nonce`: `QUANTITY` – (opcionális) A nonce egész számmal megadva. Ez lehetővé teszi a saját függőben lévő tranzakciók felülírását, amelyek ugyanazt a nonce-t használják. - -**Visszaad** - -`DATA`, Az RLP-kódolású tranzakcióobjektum, melyet a specifikus számla aláírt. - -**Példa** - -```js -// Request -curl -X POST --data '{"id": 1,"jsonrpc": "2.0","method": "eth_signTransaction","params": [{"data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675","from": "0xb60e8dd61c5d32be8058bb8eb970870f07233155","gas": "0x76c0","gasPrice": "0x9184e72a000","to": "0xd46e8dd67c5d32be8058bb8eb970870f07244567","value": "0x9184e72a"}]}' -// Result -{ - "id": 1, - "jsonrpc": "2.0", - "result": "0xa3f20717a250c2b0b729b7e5becbff67fdaef7e0699da4de7ca5895b02a170a12d887fd3b17bfdce3481f10bea41f45ba9f709d39ce8325427b57afcfc994cee1b" -} -``` - -### eth_sendTransaction {#eth_sendtransaction} - -Készít egy új üzenetküldési tranzakciót vagy szerződéslétrehozást, ha az adatmezőben kód van, és aláírja a `from` mezőben definiált számlával. - -**Paraméterek** - -1. `Object` – A tranzakcióobjektum - -- `from`: `DATA`, 20 bájt – A cím, amelyről a tranzakció érkezett. -- `to`: `DATA`, 20 bájt – (opcionális új szerződés létrehozásakor) A tranzakció címzettjének címe. -- `gas`: `QUANTITY` – (opcionális, alapértelmezett: 90 000) A tranzakció végrehajtásához biztosított gáz egész számban megadva. Visszaküldi a fel nem használt gázt. -- `gasPrice`: `QUANTITY` – (opcionális, alapértelmezett: To-Be-Determined) a gasPrice (gázár) egész számként, ami a fizetendő gázra vonatkozik. -- `value`: `QUANTITY` – (opcionális) a tranzakcióban küldött érték egész számként. -- `input`: `DATA` – A szerződés kódjának átfordítása VAGY a meghívott metódus aláírásának és kódolt paramétereinek a hashe. -- `nonce`: `QUANTITY` – (opcionális) A nonce egész számmal megadva. Ez lehetővé teszi a saját függőben lévő tranzakciók felülírását, amelyek ugyanazt a nonce-t használják. - -```js -params: [ - { - from: "0xb60e8dd61c5d32be8058bb8eb970870f07233155", - to: "0xd46e8dd67c5d32be8058bb8eb970870f07244567", - gas: "0x76c0", // 30400 - gasPrice: "0x9184e72a000", // 10000000000000 - value: "0x9184e72a", // 2441406250 - input: - "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", - }, -] -``` - -**Visszaad** - -`DATA`, 32 bájt – a tranzakció hashe vagy a nulla hash, ha a tranzakció még nem elérhető. - -Használja az [eth_getTransactionReceipt](#eth_gettransactionreceipt) parancsot, hogy megszerezze a szerződéscímet, miután a tranzakciót egy blokkban előterjesztették, és amikor létrehozta a szerződést. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{see above}],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" -} -``` - -### eth_sendRawTransaction {#eth_sendrawtransaction} - -Egy új üzenetküldési tranzakciót vagy szerződéslétrehozást hoz létre az aláírt tranzakciókhoz. - -**Paraméterek** - -1. `DATA`, az aláírt tranzakciós adatok. - -```js -params: [ - "0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675", -] -``` - -**Visszaad** - -`DATA`, 32 bájt – a tranzakció hashe vagy a nulla hash, ha a tranzakció még nem elérhető. - -Használja az [eth_getTransactionReceipt](#eth_gettransactionreceipt) parancsot, hogy megszerezze a szerződéscímet, miután a tranzakciót egy blokkban előterjesztették, és amikor létrehozta a szerződést. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_sendRawTransaction","params":[{see above}],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331" -} -``` - -### eth_call {#eth_call} - -Azonnal végrehajt egy új üzenethívást anélkül, hogy létrehozna egy tranzakciót a blokkláncon. Gyakran használják arra, hogy csak olvasási (read-only) okosszerződés-függvényeket hajtsanak végre, például a `balanceOf` kód egy ERC-20-as szerződésnél. - -**Paraméterek** - -1. `Object` – A tranzakcióhívás objektuma - -- `from`: `DATA`, 20 bájt – (opcionális) A tranzakció küldőjének címe. -- `to`: `DATA`, 20 bájt – A tranzakció címzettjének címe. -- `gas`: `QUANTITY` – (opcionális) A tranzakció végrehajtásához adott gáz egész számként. Az eth_call nulla gázt fogyaszt, de néhány végrehajtásnak szüksége lehet rá. -- `gasPrice`: `QUANTITY` – (opcionális) a gasPrice (gázár) egész számként, ami a fizetendő gázra vonatkozik -- `value`: `QUANTITY` – (opcionális) a tranzakcióban küldött érték egész számként -- `input`: `DATA` – (opcionális) a metódus aláírásának és kódolt paramétereinek a hashe. A részletekért tekintse meg az [Ethereum-szerződés ABI-ját a Solidity dokumentációban](https://docs.soliditylang.org/en/latest/abi-spec.html). - -2. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek – nézze meg az [alapértelmezett blokkparamétereket](/developers/docs/apis/json-rpc/#default-block) - -**Visszaad** - -`DATA` – a végrehajtott szerződés visszatérési értéke. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_call","params":[{see above}],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x" -} -``` - -### eth_estimateGas {#eth_estimategas} - -Megbecsüli, hogy egy tranzakció végrehajtásához mennyi gázra lesz szükség. A tranzakció nem kerül hozzáadásra a blokklánchoz. Vegye figyelembe, hogy a becslés szignifikánsan több is lehet, mint amennyit elhasznál a tranzakció, melynek számos oka van, beleértve az EVM működési módját és a csomópontok teljesítményét. - -**Paraméterek** - -Nézze meg az [eth_call](#eth_call) paramétereit az összes opcionális paraméter kivételével. Ha nincs megadva gázkorlátozás, akkor a Geth a függőben lévő blokk gázkorlátozását használja felső értékként. Ennek eredményeként a visszakapott becslés talán nem elég a hívás/tranzakció végrehajtásához, amikor a gáz mennyisége magasabb, mint a függőben lévő blokk gázkorlátozása. - -**Visszaad** - -`QUANTITY` – a felhasznált gáz mennyisége. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_estimateGas","params":[{see above}],"id":1}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x5208" // 21000 -} -``` - -### eth_getBlockByHash {#eth_getblockbyhash} - -Egy blokkról ad információt hash alapján. - -**Paraméterek** - -1. `DATA`, 32 bájt – egy blokk hashe. -2. `Boolean` – Ha `true`, akkor visszaadja a teljes tranzakcióobjektumot, ha `false`, akkor csak a tranzakciók hashét. - -```js -params: [ - "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", - false, -] -``` - -**Visszaad** - -`Object` – Egy blokkobjektum, vagy `null`, amikor nem talál blokkot: - -- `number`: `QUANTITY` – a blokkszám. `null`, amikor a blokk függőben van. -- `hash`: `DATA`, 32 bájt – a blokk hashe. `null`, amikor a blokk függőben van. -- `parentHash`: `DATA`, 32 bájt – a szülőblokk hashe. -- `nonce`: `DATA`, 8 bájt – a létrehozott proof-of-work hashe. `null`, amikor a blokk függőben van. -- `sha3Uncles`: `DATA`, 32 bájt – a blokkban lévő uncle blokkok SHA3-ja. -- `logsBloom`: `DATA`, 256 bájt – a bloom-szűrés a blokkok naplózására. `null`, amikor a blokk függőben van. -- `transactionsRoot`: `DATA`, 32 bájt – a blokk tranzakciós fájának a gyökere. -- `stateRoot`: `DATA`, 32 bájt – a blokk végső státuszfájának a gyökere. -- `receiptsRoot`: `DATA`, 32 bájt – a blokk visszaigazolás-fájának a gyökere. -- `miner`: `DATA`, 20 bájt – annak a címe, akinek a bányászati jutalom jár. -- `difficulty`: `QUANTITY` – erre a blokkra vonatkozó nehézség egész számként. -- `totalDifficulty`: `QUANTITY` – a lánc teljes nehézsége eddig a blokkig, egész számként. -- `extraData`: `DATA` – ennek a blokknak a „további adatok” mezője. -- `size`: `QUANTITY` – a blokk mérete bájtban, egész számként. -- `gasLimit`: `QUANTITY` – a maximálisan megengedett gáz ebben a blokkban. -- `gasUsed`: `QUANTITY` – a tranzakciók által elhasznált összes gáz ebben a blokkban. -- `timestamp`: `QUANTITY` – a unix időbélyege, amikor a blokkot összeállították. -- `transactions`: `Array` – Tranzakcióobjektumok tömbje, vagy 32 bájtos tranzakcióhashek az utolsó megadott paraméter alapján. -- `uncles`: `Array` – Az uncle hashek sora. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByHash","params":["0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", false],"id":1}' -// Result -{ -{ -"jsonrpc": "2.0", -"id": 1, -"result": { - "difficulty": "0x4ea3f27bc", - "extraData": "0x476574682f4c5649562f76312e302e302f6c696e75782f676f312e342e32", - "gasLimit": "0x1388", - "gasUsed": "0x0", - "hash": "0xdc0818cf78f21a8e70579cb46a43643f78291264dda342ae31049421c82d21ae", - "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", - "miner": "0xbb7b8287f3f0a933474a79eae42cbca977791171", - "mixHash": "0x4fffe9ae21f1c9e15207b1f472d5bbdd68c9595d461666602f2be20daf5e7843", - "nonce": "0x689056015818adbe", - "number": "0x1b4", - "parentHash": "0xe99e022112df268087ea7eafaf4790497fd21dbeeb6bd7a1721df161a6657a54", - "receiptsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", - "sha3Uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", - "size": "0x220", - "stateRoot": "0xddc8b0234c2e0cad087c8b389aa7ef01f7d79b2570bccb77ce48648aa61c904d", - "timestamp": "0x55ba467c", - "totalDifficulty": "0x78ed983323d", - "transactions": [ - ], - "transactionsRoot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", - "uncles": [ - ] -} -} -``` - -### eth_getBlockByNumber {#eth_getblockbynumber} - -Egy blokkról ad információt a blokkszám alapján. - -**Paraméterek** - -1. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek az [alapértelmezett blokkparaméterek](/developers/docs/apis/json-rpc/#default-block) szerint. -2. `Boolean` – Ha `true`, akkor visszaadja a teljes tranzakcióobjektumot, ha `false`, akkor csak a tranzakciók hashét. - -```js -params: [ - "0x1b4", // 436 - true, -] -``` - -**Visszaküldött információk** Nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x1b4", true],"id":1}' -``` - -Az eredményeket nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél - -### eth_getTransactionByHash {#eth_gettransactionbyhash} - -Információt ad egy tranzakcióról a tranzakció hashe alapján. - -**Paraméterek** - -1. `DATA`, 32 bájt – tranzakció-hash - -```js -params: ["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"] -``` - -**Visszaad** - -`Object` – Egy tranzakcióobjektum, vagy `null`, amikor nem talál tranzakciót: - -- `blockHash`: `DATA`, 32 bájt – a blokk-hash, amelyben ez a tranzakció volt. `null`, amikor függőben van. -- `blockNumber`: `QUANTITY` – a blokkszám, amelyben ez a tranzakció volt. `null`, amikor függőben van. -- `from`: `DATA`, 20 bájt – a küldő címe. -- `gas`: `QUANTITY` – a küldő által adott gáz. -- `gasPrice`: `QUANTITY` – a küldő által megadott gázár wei-ben. -- `hash`: `DATA`, 32 bájt – a tranzakció hashe. -- `input`: `DATA` – a tranzakcióval együtt küldött adatok. -- `nonce`: `QUANTITY` – a tranzakciók száma, melyet a küldő az adott tranzakció előtt végzett. -- `to`: `DATA`, 20 bájt – a fogadó címe. `null`, amikor ez egy szerződéslétrehozó tranzakció. -- `transactionIndex`: `QUANTITY` – a tranzakcióindex pozíciója a blokkban, egész számként. `null`, amikor függőben van. -- `value`: `QUANTITY` – a küldött érték wei-ben. -- `v`: `QUANTITY` – ECDSA visszaállítási azonosító -- `r`: `QUANTITY` – ECDSA aláírás r -- `s`: `QUANTITY` – ECDSA aláírás s - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b"],"id":1}' -// Result -{ - "jsonrpc":"2.0", - "id":1, - "result":{ - "blockHash":"0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", - "blockNumber":"0x5daf3b", // 6139707 - "from":"0xa7d9ddbe1f17865597fbd27ec712455208b6b76d", - "gas":"0xc350", // 50000 - "gasPrice":"0x4a817c800", // 20000000000 - "hash":"0x88df016429689c079f3b2f6ad39fa052532c56795b733da78a91ebe6a713944b", - "input":"0x68656c6c6f21", - "nonce":"0x15", // 21 - "to":"0xf02c1c8e6114b1dbe8937a39260b5b0a374432bb", - "transactionIndex":"0x41", // 65 - "value":"0xf3dbb76162000", // 4290000000000000 - "v":"0x25", // 37 - "r":"0x1b5e176d927f8e9ab405058b2d2457392da3e20f328b16ddabcebc33eaac5fea", - "s":"0x4ba69724e8f69de52f0125ad8b3c5c2cef33019bac3249e2c0a2192766d1721c" - } -} -``` - -### eth_getTransactionByBlockHashAndIndex {#eth_gettransactionbyblockhashandindex} - -Egy tranzakcióról ad információt a blokk-hash és a tranzakcióindex pozíciója alapján. - -**Paraméterek** - -1. `DATA`, 32 bájt – egy blokk hashe. -2. `QUANTITY` – a tranzakcióindex pozíciója egész számként. - -```js -params: [ - "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", - "0x0", // 0 -] -``` - -**Visszaküldött információk** Nézze meg az [eth_getTransactionByHash](#eth_gettransactionbyhash) résznél - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' -``` - -Az eredményeket nézze meg az [eth_getTransactionByHash](#eth_gettransactionbyhash) résznél - -### eth_getTransactionByBlockNumberAndIndex {#eth_gettransactionbyblocknumberandindex} - -Egy tranzakcióról ad információt a blokkszám és a tranzakcióindex pozíciója alapján. - -**Paraméterek** - -1. `QUANTITY|TAG` – a blokk száma egész számként, vagy a `„latest”`, `„earliest”`, `„pending”`, `„safe”` vagy `„finalized”` sztringek az [alapértelmezett blokkparaméterek](/developers/docs/apis/json-rpc/#default-block) szerint. -2. `QUANTITY` – a tranzakcióindex pozíciója. - -```js -params: [ - "0x9c47cf", // 10241999 - "0x24", // 36 -] -``` - -**Visszaküldött információk** Nézze meg az [eth_getTransactionByHash](#eth_gettransactionbyhash) résznél - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionByBlockNumberAndIndex","params":["0x9c47cf", "0x24"],"id":1}' -``` - -Az eredményeket nézze meg az [eth_getTransactionByHash](#eth_gettransactionbyhash) résznél - -### eth_getTransactionReceipt {#eth_gettransactionreceipt} - -Egy tranzakció visszaigazolását adja meg a tranzakció-hash alapján. - -**Megjegyzés:** A visszaigazolás nem érthető el függőben lévő tranzakciók esetében. - -**Paraméterek** - -1. `DATA`, 32 bájt – tranzakció-hash - -```js -params: ["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"] -``` - -**Visszaküldött információk** `Object` – Egy tranzakció visszaigazolási objektuma, vagy `null`, amikor a visszaigazolást nem találja: - -- `transactionHash`: `DATA`, 32 bájt – a tranzakció hashe. -- `transactionIndex`: `QUANTITY` – a tranzakcióindex pozíciója a blokkban, egész számként. -- `blockHash`: `DATA`, 32 bájt – a blokk-hash, amelyben ez a tranzakció volt. -- `blockNumber`: `QUANTITY` – a blokkszám, amelyben ez a tranzakció volt. -- `from`: `DATA`, 20 bájt – a küldő címe. -- `to`: `DATA`, 20 bájt – a fogadó címe. null, amikor ez egy szerződéslétrehozó tranzakció. -- `cumulativeGasUsed` : `QUANTITY` – A gáz teljes mennyisége, amikor ez a tranzakció végrehajtásra került a blokkban. -- `effectiveGasPrice` : `QUANTITY` – Az alapdíj és a borravaló összege a gáz egységére vonatkozóan. -- `gasUsed`: `QUANTITY` – A felhasznált gáz mennyisége erre az adott tranzakcióra vonatkozóan. -- `contractAddress`: `DATA`, 20 bájt – A létrehozott szerződéscím, ha ez a tranzakció szerződéslétrehozásról szól, máskülönben `null`. -- `logs`: `Array` – A naplózási objektumok tömbje, amelyet ez a tranzakció generált. -- `logsBloom`: `DATA`, 256 bájt – Bloom-szűrés a könnyű kliensekhez, hogy gyorsan elérjék a kapcsolódó naplóbejegyzéseket. -- `type`: `QUANTITY` – a tranzakciótípus egész számként, `0x0` a korábbi tranzakciókért, `0x1` a hozzáférési lista típusért, `0x2` a dinamikus díjakért. - -Emellett megadja _a kettő közül az egyiket_ : - -- `root` : `DATA` 32 bájt tranzakció utáni státuszgyökér (pre Byzantium) -- `status`: `QUANTITY` vagy `1` (sikeres), vagy `0` (sikertelen) - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5"],"id":1}' -// Result -{ - "jsonrpc": "2.0", - "id": 1, - "result": { - "blockHash": - "0xa957d47df264a31badc3ae823e10ac1d444b098d9b73d204c40426e57f47e8c3", - "blockNumber": "0xeff35f", - "contractAddress": null, // string of the address if it was created - "cumulativeGasUsed": "0xa12515", - "effectiveGasPrice": "0x5a9c688d4", - "from": "0x6221a9c005f6e47eb398fd867784cacfdcfff4e7", - "gasUsed": "0xb4c8", - "logs": [{ - // logs as returned by getFilterLogs, etc. - }], - "logsBloom": "0x00...0", // 256 byte bloom filter - "status": "0x1", - "to": "0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2", - "transactionHash": - "0x85d995eba9763907fdf35cd2034144dd9d53ce32cbec21349d4b12823c6860c5", - "transactionIndex": "0x66", - "type": "0x2" - } -} -``` - -### eth_getUncleByBlockHashAndIndex {#eth_getunclebyblockhashandindex} - -Egy blokk uncle-blokkjáról ad információt a hash és az uncle-index pozíciója alapján. - -**Paraméterek** - -1. `DATA`, 32 bájt – egy blokk hashe. -2. `QUANTITY` – az uncle-index pozíciója. - -```js -params: [ - "0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", - "0x0", // 0 -] -``` - -**Visszaküldött információk** Nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockHashAndIndex","params":["0x1d59ff54b1eb26b013ce3cb5fc9dab3705b415a67127a003c3e61eb445bb8df2", "0x0"],"id":1}' -``` - -Az eredményeket nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél - -**Megjegyzés**: A nagybácsi nem tartalmaz egyedi tranzakciókat. - -### eth_getUncleByBlockNumberAndIndex {#eth_getunclebyblocknumberandindex} - -Egy blokk uncle-blokkjáról ad információt a blokkszám és az uncle-index pozíciója alapján. - -**Paraméterek** - -1. `QUANTITY|TAG` – a blokk száma egész számként, vagy az `„earliest”`, `„latest”`, `„pending”`, `„safe”`, `„finalized”` sztringek az [alapértelmezett blokkparaméterek](/developers/docs/apis/json-rpc/#default-block) szerint. -2. `QUANTITY` – az uncle-index pozíciója. - -```js -params: [ - "0x29c", // 668 - "0x0", // 0 -] -``` - -**Visszaküldött információk** Nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél - -**Megjegyzés**: A nagybácsi nem tartalmaz egyedi tranzakciókat. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getUncleByBlockNumberAndIndex","params":["0x29c", "0x0"],"id":1}' -``` - -Az eredményeket nézze meg az [eth_getBlockByHash](#eth_getblockbyhash) résznél - -### eth_newFilter {#eth_newfilter} - -Egy szűrőobjektumot hoz létre a szűrőopciók alapján, hogy értesítsen, amikor a státusz változik (a naplóban). A státusz megváltozásának ellenőrzéséhez az [eth_getFilterChanges](#eth_getfilterchanges) metódust kell meghívni. - -**Megjegyzés a témaszűrők meghatározásához:** A témák sorrendfüggők. Egy tranzakció egy olyan naplóval, melyben [A, B] téma (topic) van, a következő témaszűrőkhöz lesz hozzáillesztve: - -- `[]` „bármi” -- `[A]` „A az első helyen (utána bármi)” -- `[null, B]` „bármi az első helyen ÉS B a második helyen (és utána bármi)” -- `[A, B]` „A az első helyen ÉS B a második helyen (és utána bármi)” -- `[[A, B], [A, B]]` „(A VAGY B) az első helyen ÉS (A VAGY B) a második helyen (és utána bármi)” -- **Paraméterek** - -1. `Object` – A szűrőopciók: - -- `fromBlock`: `QUANTITY|TAG` – (opcionális, alapértelmezett: `„latest”`) blokkszám egész számként, vagy `„latest”` az utolsó előterjesztett blokkra, `„safe”` az utolsó biztosított blokkra, `„finalized”` az utolsó véglegesített blokkra, vagy `„pending”`, `„earliest”` a még blokkba nem került tranzakciókra. -- `toBlock`: `QUANTITY|TAG` – (opcionális, alapértelmezett: `„latest”`) blokkszám egész számként, vagy `„latest”` az utolsó előterjesztett blokkra,`„safe”` az utolsó biztosított blokkra, `„finalized”` az utolsó véglegesített blokkra, vagy `„pending”`, `„earliest”` a még blokkba nem került tranzakciókra. -- `address`: `DATA|Array`, 20 bájt – (opcionális) A szerződéscím vagy címek listája, amelyekről a naplók származnak. -- `topics`: `Array of DATA`, – (opcionális) a `DATA` témák (topics) 32 bájtos tömbje. A témák sorrendfüggők. Minden téma egy DATA tömb lehet „vagy” opciókkal. - -```js -params: [ - { - fromBlock: "0x1", - toBlock: "0x2", - address: "0x8888f1f195afa192cfee860698584c030f4c9db1", - topics: [ - "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", - null, - [ - "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", - "0x0000000000000000000000000aff3454fce5edbc8cca8697c15331677e6ebccc", - ], - ], - }, -] -``` - -**Visszaküldött információk** `QUANTITY` – Egy szűrő id. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newFilter","params":[{"topics":["0x12341234"]}],"id":73}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x1" // 1 -} -``` - -### eth_newBlockFilter {#eth_newblockfilter} - -Létrehoz egy szűrőt a csomópontban, hogy értesítsen az új blokk érkezéséről. A státusz megváltozásának ellenőrzéséhez az [eth_getFilterChanges](#eth_getfilterchanges) metódust kell meghívni. - -**Paraméterek** Egyik sem - -**Visszaküldött információk** `QUANTITY` – Egy szűrő id. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newBlockFilter","params":[],"id":73}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x1" // 1 -} -``` - -### eth_newPendingTransactionFilter {#eth_newpendingtransactionfilter} - -Létrehoz egy szűrőt a csomópontban, hogy értesítsen új függőben lévő tranzakciók érkezéséről. A státusz megváltozásának ellenőrzéséhez az [eth_getFilterChanges](#eth_getfilterchanges) metódust kell meghívni. - -**Paraméterek** Egyik sem - -**Visszaküldött információk** `QUANTITY` – Egy szűrő id. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_newPendingTransactionFilter","params":[],"id":73}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": "0x1" // 1 -} -``` - -### eth_uninstallFilter {#eth_uninstallfilter} - -Egy adott azonosító alatti szűrő eltávolítása. Mindig érdemes meghívni, ha már nincs szükség az adott ellenőrzésre. Emellett a szűrőket ideiglenesen leállíthatja, amikor egy időszakban nincs azokra szükség az [eth_getFilterChanges](#eth_getfilterchanges) metódussal. - -**Paraméterek** - -1. `QUANTITY` – A szűrő azonosítója. - -```js -params: [ - "0xb", // 11 -] -``` - -**Visszaküldött információk** `Boolean` – `true`, ha a szűrőt sikeresen eltávolította, máskülönben `false`. - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_uninstallFilter","params":["0xb"],"id":73}' -// Result -{ - "id":1, - "jsonrpc": "2.0", - "result": true -} -``` - -### eth_getFilterChanges {#eth_getfilterchanges} - -Egy szűrőre vonatkozó szelektív hívás, ami a naplótömböt adja vissza, amely az utolsó szelektív hívás óta történteket foglalja magában. - -**Paraméterek** - -1. `QUANTITY` – A szűrő azonosítója. - -```js -params: [ - "0x16", // 22 -] -``` - -**Visszaküldött információk** `Array` – Naplóobjektumok tömbje, vagy egy üres tömb, ha semmi sem változott a legutóbbi szelektív hívás óta. - -- Az `eth_newBlockFilter` által létrehozott szűrőkre a visszakapott értékek a blokkhashek (`DATA`, 32 bájt), például `["0x3454645634534..."]`. -- Az `eth_newPendingTransactionFilter` által létrehozott szűrőkre a visszakapott értékek a tranzakcióhashek (`DATA`, 32 bájt), például `["0x6345343454645..."]`. -- Az `eth_newFilter` által készített szűrőkre a naplók olyan objektumok lesznek, melyek a következő paraméterekkel rendelkeznek: - - `removed`: `TAG` – `true`, amikor a naplót törölték a lánc újrarendezése miatt. `false`, ha ez egy érvényes napló. - - `logIndex`: `QUANTITY` – a naplóindex pozíciója a blokkban, egész számként. `null`, amikor a napló függőben van. - - `transactionIndex`: `QUANTITY` – a tranzakcióindex pozíciója, amelyből a napló készült, egész számként. `null`, amikor a napló függőben van. - - `transactionHash`: `DATA`, 32 bájt – a tranzakció hashe, amelyből ez a napló készült. `null`, amikor a napló függőben van. - - `blockHash`: `DATA`, 32 bájt – a blokk-hash, amelyben ez a napló volt. `null`, amikor függőben van. `null`, amikor a napló függőben van. - - `blockNumber`: `QUANTITY` – a blokkszám, ahol ez a napló volt. `null`, amikor függőben van. `null`, amikor a napló függőben van. - - `address`: `DATA`, 20 bájt – a cím, ahonnan ez a napló származik. - - `data`: `DATA` – nullát vagy a napló több 32 bájtos nem indexált argumentumát tartalmazza. - - `topics`: `Array of DATA` – 0-tól 4-ig tartó tömbje a 32 bájtos, indexált naplóargumentumok `DATA` részleteinek. (A _Solidity-ben_: Az első téma (topic) az esemény aláírásának a _hashe_ (például `Deposit(address,bytes32,uint256)`), kivéve ha az eseményt az `anonymous` specifikációval deklarálták.) -- **Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterChanges","params":["0x16"],"id":73}' -// Result -{ - "id":1, - "jsonrpc":"2.0", - "result": [{ - "logIndex": "0x1", // 1 - "blockNumber":"0x1b4", // 436 - "blockHash": "0x8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcfdf829c5a142f1fccd7d", - "transactionHash": "0xdf829c5a142f1fccd7d8216c5785ac562ff41e2dcfdf5785ac562ff41e2dcf", - "transactionIndex": "0x0", // 0 - "address": "0x16c5785ac562ff41e2dcfdf829c5a142f1fccd7d", - "data":"0x0000000000000000000000000000000000000000000000000000000000000000", - "topics": ["0x59ebeb90bc63057b6515673c3ecf9438e5058bca0f92585014eced636878c9a5"] - },{ - ... - }] -} -``` - -### eth_getFilterLogs {#eth_getfilterlogs} - -Visszaadja a megadott azonosítóval rendelkező szűrőnek megfelelő összes napló tömbjét. - -**Paraméterek** - -1. `QUANTITY` – A szűrő azonosítója. - -```js -params: [ - "0x16", // 22 -] -``` - -**Visszaküldött információk** Nézze meg az [eth_getFilterChanges](#eth_getfilterchanges) résznél - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getFilterLogs","params":["0x16"],"id":74}' -``` - -Az eredményeket nézze meg az [eth_getFilterChanges](#eth_getfilterchanges) résznél - -### eth_getLogs {#eth_getlogs} - -Visszaadja az adott szűrőobjektumnak megfelelő összes naplótömböt. - -**Paraméterek** - -1. `Object` – A szűrőopciók: - -- `fromBlock`: `QUANTITY|TAG` – (opcionális, alapértelmezett: `„latest”`) blokkszám egész számként, vagy `„latest”` az utolsó előterjesztett blokkra, `„safe”` az utolsó biztosított blokkra, `„finalized”` az utolsó véglegesített blokkra, vagy `„pending”`, `„earliest”` a még blokkba nem került tranzakciókra. -- `toBlock`: `QUANTITY|TAG` – (opcionális, alapértelmezett: `„latest”`) blokkszám egész számként, vagy `„latest”` az utolsó előterjesztett blokkra,`„safe”` az utolsó biztosított blokkra, `„finalized”` az utolsó véglegesített blokkra, vagy `„pending”`, `„earliest”` a még blokkba nem került tranzakciókra. -- `address`: `DATA|Array`, 20 bájt – (opcionális) A szerződéscím vagy címek listája, amelyekről a naplók származnak. -- `topics`: `Array of DATA`, – (opcionális) a `DATA` témák (topics) 32 bájtos tömbje. A témák sorrendfüggők. Minden téma egy DATA tömb lehet „vagy” opciókkal. -- `blockhash`: `DATA`, 32 bájt – (opcionális, **jövő**) Az EIP-234 bevezetésével a `blockHash` egy új szűrőopció lesz, amely egyetlen blokkra redukálja a visszakapott naplókat egy 32-bájtos hashsel rendelkező `blockHash` segítségével. A `blockHash` használata azonos a `fromBlock` = `toBlock` = blokkszám hashsel (`blockHash`). Ha a `blockHash` benne van a szűrőkritériumban, akkor nem engedélyezett se a `fromBlock`, se a `toBlock`. - -```js -params: [ - { - topics: [ - "0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b", - ], - }, -] -``` - -**Visszaküldött információk** Nézze meg az [eth_getFilterChanges](#eth_getfilterchanges) résznél - -**Példa** - -```js -// Request -curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"topics":["0x000000000000000000000000a94f5374fce5edbc8e2a8697c15331677e6ebf0b"]}],"id":74}' -``` - -Az eredményeket nézze meg az [eth_getFilterChanges](#eth_getfilterchanges) résznél - -## Használati példa {#usage-example} - -### Egy szerződés telepítése JSON_RPC-vel {#deploying-contract} - -Ez a rész azt mutatja be, hogyan lehet egy szerződést telepíteni kizárólag az RPC-interfésszel. Alternatív utak állnak rendelkezésre a szerződéstelepítéshez, ahol ez a komplexitás csökken, például az RPC-interfészre épített könyvtárak segítségével, mint amilyen a [web3.js](https://web3js.readthedocs.io/) és a [web3.py](https://github.com/ethereum/web3.py). Ezek az absztrakciók általában könnyebben érthetők és nem annyira hajlamosak a hibára, de akkor is érdemes megérteni, hogy mi is zajlik a háttérben. - -A következő egy egyszerű, `Multiply7` nevű okosszerződés, amelyet a JSON-RPC-interfésszel telepítünk egy Ethereum-csomópontra. Ez az útmutató azt feltételezi, hogy Ön már futtat egy Geth-csomópontot. A csomópontokról és a kliensekről bővebben [itt](/developers/docs/nodes-and-clients/run-a-node) olvashat. Tekintse meg az egyéni [kliensdokumentációt](/developers/docs/nodes-and-clients/), hogy hogyan lehet HTTP JSON-RPC-t indítani nem Geth-klienseken. A legtöbb kliens alapértelmezés szerint a `localhost:8545` kódon működik. - -```javascript -contract Multiply7 { - event Print(uint); - function multiply(uint input) returns (uint) { - Print(input * 7); - return input * 7; - } -} -``` - -Az első dolog, hogy a HTTP RPC-interfész engedélyezve legyen. Ez azt jelenti, hogy a Geth-nek a beállításkor megadjuk a `--http` jelölőt (flag). Ebben a példában egy Geth-csomópontot használunk egy privát fejlesztési láncon. Ehhez a megközelítéshez nincs szükség etherre, mint egy valódi hálózaton. - -```bash -geth --http --dev console 2>>geth.log -``` - -Ez elindítja a HTTP RPC interfészt a `http://localhost:8545` kódon. - -A coinbase címének lekérdezésével (az első cím megszerzésével a számlák tömbjéből) és a [curl](https://curl.se) használatával ellenőrizhetjük, hogy az interfész fut-e. Vegye figyelembe, hogy e példában az adatok mások, mint az Ön lokális csomópontján. Ha ki szeretné próbálni ezeket a parancsokat, akkor a lekérdezés paramétereit a második curl kérésben cserélje le az első kérésre kapott eredményekre. - -```bash -curl --data '{"jsonrpc":"2.0","method":"eth_accounts","params":[]", "id":1}' -H "Content-Type: application/json" localhost:8545 -{"id":1,"jsonrpc":"2.0","result":["0x9b1d35635cc34752ca54713bb99d38614f63c955"]} - -curl --data '{"jsonrpc":"2.0","method":"eth_getBalance", "params": ["0x9b1d35635cc34752ca54713bb99d38614f63c955", "latest"], "id":2}' -H "Content-Type: application/json" localhost:8545 -{"id":2,"jsonrpc":"2.0","result":"0x1639e49bba16280000"} -``` - -Mivel a számok hexadecimálisan vannak kódolva, ezért a visszakapott egyenleg wei-ben egy hexadecimális sztring. Ha az egyenleget etherben, számként szeretnénk megkapni, akkor használhatjuk a web3-at a Geth-konzolból. - -```javascript -web3.fromWei("0x1639e49bba16280000", "ether") -// "410" -``` - -Most, hogy ethert tettünk a privát fejlesztési láncra, telepíthetjük a szerződést. Az első lépés, hogy a Multiply7 szerződést át kell fordítani bájtkódra, hogy el lehessen küldeni az EVM-nek. A solc, a Solidity átfordító telepítéséhez kövesse a [Solidity dokumentációt](https://docs.soliditylang.org/en/latest/installing-solidity.html). (Előfordulhat, hogy egy régebbi `solc` kiadást szeretne használni, hogy az illeszkedjen [a példában szereplő átfordító verziójához](https://github.com/ethereum/solidity/releases/tag/v0.4.20).) - -Most tehát átfordíthatjuk a Multiply7 szerződést bájtkódra, hogy el lehessen küldeni az EVM-nek. - -```bash -echo 'pragma solidity ^0.4.16; contract Multiply7 { event Print(uint); function multiply(uint input) public returns (uint) { Print(input * 7); return input * 7; } }' | solc --bin - -======= :Multiply7 ======= -Binary: -6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029 -``` - -Megvan az átfordított kód, úgyhogy most meghatározzunk, mennyi gázköltséget igényel a telepítése. Az RPC-interfésznek van egy `eth_estimateGas` metódusa, ami megadja a becsült értéket. - -```bash -curl --data '{"jsonrpc":"2.0","method": "eth_estimateGas", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 5}' -H "Content-Type: application/json" localhost:8545 -{"jsonrpc":"2.0","id":5,"result":"0x1c31e"} -``` - -Végül telepítjük a szerződést. - -```bash -curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0x9b1d35635cc34752ca54713bb99d38614f63c955", "gas": "0x1c31e", "data": "0x6060604052341561000f57600080fd5b60eb8061001d6000396000f300606060405260043610603f576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063c6888fa1146044575b600080fd5b3415604e57600080fd5b606260048080359060200190919050506078565b6040518082815260200191505060405180910390f35b60007f24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da600783026040518082815260200191505060405180910390a16007820290509190505600a165627a7a7230582040383f19d9f65246752244189b02f56e8d0980ed44e7a56c0b200458caad20bb0029"}], "id": 6}' -H "Content-Type: application/json" localhost:8545 -{"id":6,"jsonrpc":"2.0","result":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"} -``` - -A tranzakciót elfogadta a csomópont, és visszaküldte a tranzakcióhasht. Ezzel a hashsel lehet nyomon követni a tranzakciót. A következő lépés, hogy meghatározzuk a címet, ahová a szerződés telepítésre került. Minden végrehajtott tranzakció egy visszaigazolást ad. Ez a visszaigazolás számos információt tartalmaz a tranzakcióról, például melyik blokkba került be és mennyi gázt használt fel az EVM. Ha egy tranzakció létrehoz egy szerződést, akkor a szerződés címe is benne lesz a visszaigazolásban. A visszaigazolást megszerezhetjük az `eth_getTransactionReceipt` RPC metódussal. - -```bash -curl --data '{"jsonrpc":"2.0","method": "eth_getTransactionReceipt", "params": ["0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf"], "id": 7}' -H "Content-Type: application/json" localhost:8545 -{"jsonrpc":"2.0","id":7,"result":{"blockHash":"0x77b1a4f6872b9066312de3744f60020cbd8102af68b1f6512a05b7619d527a4f","blockNumber":"0x1","contractAddress":"0x4d03d617d700cf81935d7f797f4e2ae719648262","cumulativeGasUsed":"0x1c31e","from":"0x9b1d35635cc34752ca54713bb99d38614f63c955","gasUsed":"0x1c31e","logs":[],"logsBloom":"0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","status":"0x1","to":null,"transactionHash":"0xe1f3095770633ab2b18081658bad475439f6a08c902d0915903bafff06e6febf","transactionIndex":"0x0"}} -``` - -A szerződést a `0x4d03d617d700cf81935d7f797f4e2ae719648262` címen hozta létre. Ha nullát kapunk eredményül, akkor a tranzakció még nem került be a blokkba. Várjon egy kicsit, ellenőrizze, hogy a konszenzuskliens fut-e, és próbálja meg újra. - -#### Interakció okosszerződésekkel {#interacting-with-smart-contract} - -Ebben a példában elküldünk egy tranzakciót az `eth_sendTransaction` metódussal a szerződés `multiply` metódusának. - -Az `eth_sendTransaction` számos argumentumot igényel, mint a `from`, `to` és `data`. `From` a számla nyilvános címe, a `to` pedig a szerződés címe. A `data` tartalmazza a csomagot, hogy melyik metódust milyen argumentumokkal kell meghívni. Itt jön képbe az [ABI (application binary interface)](https://docs.soliditylang.org/en/latest/abi-spec.html). Az ABI egy JSON-fájl, amely meghatározza, hogyan kell az EVM számára megadni és kódolni az adatokat. - -Az adattörzs bájtjai határozzák meg, hogy a szerződés melyik metódusát hívják meg. Ez a Kessak-hash első 4 bájtja a függvénynév és az argumentumtípusok felett, hexadecimálisan kódolva. A szorzás függvény uint-et fogad el, ami azonos az uint256-tal. Ez a következőt jelenti: - -```javascript -web3.sha3("multiply(uint256)").substring(0, 10) -// "0xc6888fa1" -``` - -A következő lépés az argumentumok kódolása. Egyetlen uint256 van csak, amelynek értéke legyen 6. Az ABI egyik része azt mutatja be, hogy miként kell kódolni az uint256 típusokat. - -`int: enc(X)` az X két kiegészítős big-endian kódolása, a magasabb rendű (bal) oldalon 0xff-el feltöltve negatív X esetén és nulla > bájttal pozitív X esetén úgy, hogy a hossza a 32 bájt többszöröse legyen. - -Ennek a kódolása a következő: `0000000000000000000000000000000000000000000000000000000000000006`. - -A függvényválasztót és a kódolt argumentumot kombinálva az adatunk a következő: `0xc6888fa10000000000000000000000000000000000000000000000000000000000000006`. - -Ezt el lehet küldeni a csomópontnak: - -```bash -curl --data '{"jsonrpc":"2.0","method": "eth_sendTransaction", "params": [{"from": "0xeb85a5557e5bdc18ee1934a89d8bb402398ee26a", "to": "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", "data": "0xc6888fa10000000000000000000000000000000000000000000000000000000000000006"}], "id": 8}' -H "Content-Type: application/json" localhost:8545 -{"id":8,"jsonrpc":"2.0","result":"0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74"} -``` - -Mivel egy tranzakciót küldtünk, ezért egy hasht kapunk vissza. A visszaigazolás megérkezésekor a következőt látjuk: - -```javascript -{ - blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55", - blockNumber: 268, - contractAddress: null, - cumulativeGasUsed: 22631, - gasUsed: 22631, - logs: [{ - address: "0x6ff93b4b46b41c0c3c9baee01c255d3b4675963d", - blockHash: "0xbf0a347307b8c63dd8c1d3d7cbdc0b463e6e7c9bf0a35be40393588242f01d55", - blockNumber: 268, - data: "0x000000000000000000000000000000000000000000000000000000000000002a", - logIndex: 0, - topics: ["0x24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da"], - transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74", - transactionIndex: 0 - }], - transactionHash: "0x759cf065cbc22e9d779748dc53763854e5376eea07409e590c990eafc0869d74", - transactionIndex: 0 -} -``` - -A visszaigazolás tartalmaz egy naplót. Ezt a naplót az EVM generálta a tranzakció-végrehajtáskor és beletette a visszaigazolásba. A `multiply` függvény azt mutatja, hogy a `Print` eseményt a bemeneti érték 7-szeresével indította el. Mivel a `Print` eseményre az argumentum egy uint256 volt, kódolhatjuk az ABI szabályai szerint, ami a várt 42-es decimális értéket adja. Az adat mellett érdemes megjegyezni, hogy a témák (topics) révén meghatározható, hogy melyik esemény hozta létre a naplót: - -```javascript -web3.sha3("Print(uint256)") -// "24abdb5865df5079dcc5ac590ff6f01d5c16edbc5fab4e195d9febd1114503da" -``` - -Ez csak egy rövid bevezető volt a leggyakoribb feladatokba, a JSON-RPC közvetlen használatát demonstrálandó. - -## Kapcsolódó témák {#related-topics} - -- [JSON-RPC specifikáció](http://www.jsonrpc.org/specification) -- [ Csomópontok és kliensek](/developers/docs/nodes-and-clients/) -- [JavaScript API-ok](/developers/docs/apis/javascript/) -- [Backend API-ok](/developers/docs/apis/backend/) -- [Végrehajtási kliensek](/developers/docs/nodes-and-clients/#execution-clients) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" deleted file mode 100644 index b6654f87528..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/block-explorers/index.md" +++ /dev/null @@ -1,258 +0,0 @@ ---- -title: Blokk felfedezők -description: Egy bevezetés a blokkfelfedezőkbe, a blokklánc adatok portáljába, ahol információs lekérdezéseket indíthatsz tranzakciókról, számlákról, szerződésekről és más egyébről. -lang: hu -sidebarDepth: 3 ---- - -A blokkfelfedezők a portálod az Ethereum adataihoz. Használatukkal valós idejű adatokat kaphat a blokkokról, tranzakciókról, validátorokról, számlákról és más on-chain tevékenységekről. - -## Előfeltételek {#prerequisites} - -Először meg kellene értened az Ethereum alapvető fogalmait ahhoz, hogy értelmezni tudd az adatokat, melyet egy blokkfelfedező biztosít neked. Kezdjen itt: [bevezetés az Ethereumba](/developers/docs/intro-to-ethereum/). - -## Szolgáltatások {#services} - -- [Etherscan](https://etherscan.io/) –_ elérhető kínai, koreai, orosz és japán nyelven is_ -- [3xpl](https://3xpl.com/ethereum) -- [Beaconcha.in](https://beaconcha.in/) -- [Blockchair](https://blockchair.com/ethereum) –_ Spanyol, francia, olasz, holland, portugál, orosz, kínai és fárszi nyelven is elérhető_ -- [Blockscout](https://eth.blockscout.com/) -- [Chainlens](https://www.chainlens.com/) -- [DexGuru Block Explorer](https://ethereum.dex.guru/) -- [Etherchain](https://www.etherchain.org/) -- [Ethernow](https://www.ethernow.xyz/) -- [Ethplorer](https://ethplorer.io/) –_Kínai, spanyol, francia, török, orosz, koreai és vietnámi nyelven is elérhető_ -- [EthVM](https://www.ethvm.com/) -- [OKLink](https://www.oklink.com/eth) -- [Rantom](https://rantom.app/) -- [Ethseer](https://ethseer.io) - -## Nyílt forráskódú eszközök {#open-source-tools} - -- [Otterscan](https://otterscan.io/) -- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) - -## Adat {#data} - -Az Ethereum tervezése folytán transzparens, így minden ellenőrizhető. A blokkfelfedezők egy felületet biztosítanak, hogy ez az információ elérhető legyen. És ez igaz az Ethereum főhálózatára és a teszt hálózatokra, ha szükséged van az adatokra. Az adatok végrehajtási adatokra és konszenzusadatokra oszthatók. A „végrehajtási adatok” megnevezés egy konkrét blokkban végrehajtott tranzakciókra vonatkoznak. A „konszenzusadatok” megnevezés magukra a blokkokra és a blokkokat előterjesztő validátorokra vonatkozik. - -Itt egy összefoglaló azokról az adatokról, melyet egy blokkfelfedezőről megszerezhetsz. - -### Végrehajtási adatok {#execution-data} - -Az Ethereum hálózata minden 12 másodpercben új blokkal bővül (kivéve, ha a blokkelőterjesztő elszalasztja a lehetőségét), így van egy közel állandó adatfolyam, amely hozzáadódik a blokkfelfedezőkhöz. A blokkok sok fontos adatot tartalmaznak, melyeket hasznosnak találhatsz: - -**Standard adat** - -- Blokkmagasság – a blokklánc hossza és a benne foglalt blokkok száma (blokkokban kifejezve) az aktuális blokk létrehozásakor. -- Időbélyegző – a blokkjavaslat megjelenésének időpontja. -- Tranzakciók – a blokkban foglalt tranzakciók száma. -- Díj címzettje – az a cím, amely a tranzakciókból származó gasdíjtételeket megkapta. -- Blokkjutalom – a blokkot előterjesztő validátornak megítélt ETH-összeg. -- Méret – a blokkban foglalt adat mérete (bájtban kifejezve). -- Felhasznált gas – a teljes gasmennyiség, amelyet a blokkban foglalt tranzakciók felhasználtak. -- Gaskorlátozás – a blokkban foglalt tranzakciók által beállított teljes gaskorlátozás. -- Alapdíj/gas – az a minimumszorzó, amely egy tranzakció felvételéhez szükséges az adott blokkba. -- Elégetett díjak – a blokkban elégetett ETH mennyisége. -- Extra adat – Bármely extra adat, amelyet a blokképítő belefoglalt a blokkba - -**Haladó adat** - -- Hash – a kriptográfiai hash, amely a blokkfejlécét adja (a blokk egyedi azonosítója). -- Anyahash – az aktuális blokk előtt kiadott blokk hashértéke. -- StateRoot – A Merkle-fa gyökérhash-értéke, amely a rendszer teljes állapotát tárolja. - -### Üzemanyag {#gas} - -A blokkfelfedezők nemcsak a tranzakciók és blokkok gasfelhasználásáról adnak információt, hanem némelyik a hálózat aktuális gasárairól is tájékoztat. Ez segít megérteni a hálózathasználatot, biztonságos tranzakciókat indítani, és nem túlkölteni a gast. Keressen olyan API-kat, amelyek segítenek felvinni ezt az információt a terméke felületére. A gasspecifikus adat a következőket fedi le: - -- A biztonságos, de lassú tranzakcióhoz szükséges gasmennyiség becslése (+ becsült ár és idő) -- Az átlagos tranzakcióhoz szükséges gasmennyiség becslése (+ becsült ár és idő) -- A gyors tranzakcióhoz szükséges gasmennyiség becslése (+ becsült ár és idő) -- Átlagos megerősítési idő a gasár alapján -- gasfogyasztó szerződések – más szóval olyan népszerű termékek, amelyeket sokat használnak a hálózaton. -- gasköltő számlák – más szóval a rendszeres hálózathasználók. - -### Tranzakciók {#transactions} - -A blokkfelfedezők bevett eszközzé váltak az emberek kezében, hogy nyomon kövessék a tranzakcióik alakulását. Ennek az az oka, hogy az elérhető részletesség extra bizonyosságot nyújt. A tranzakcióadatok a következőket tartalmazzák: - -**Standard adatok** - -- Tranzakcióhash – a tranzakció elküldésekor a rendszer által generált hashérték. -- Állapot – jelzés arról, hogy a tranzakció függőben van, meghiúsult vagy sikeres volt. -- Blokk – a blokk, amely a tranzakciót tartalmazza. -- Időbélyegző – Annak időpontja, amikor a tranzakció bekerült a blokkba, melyet a validátor javasolt -- Feladó (From) – a tranzakciót elküldő számla címe. -- Címzett (To) – a fogadó fél vagy az okosszerződés címe, amellyel a tranzakció interakcióba lép. -- Átutalt tokenek – olyan tokenekből álló lista, amelyek át lettek utalva a tranzakcióban. -- Érték – Az átutalt ETH összértéke. -- Tranzakciós díj – A validátornak fizetett összeg, hogy feldolgozza a tranzakciót (számítása: gázár * felhasznált gáz) - -**Részletes adatok** - -- Gaskorlátozás – a gasegységek maximális száma, amelyet ez a tranzakció elfogyaszthat. -- Felhasznált gas – a tényleges gasmennyiség, amelyet ez a tranzakció elfogyasztott. -- Gasár – egy gasegységre beállított ár. -- Nonce – a `from` cím tranzakciószáma (ne feledje, hogy a számozás nullánál kezdődik, így a `100`-as nonce valójában az adott számláról küldött 101. tranzakciót jelenteni). -- Bemeneti adat – a tranzakció által megkövetelt bármely extra adat. - -### Számlák {#accounts} - -Egy adott számláról rengeteg adat elérhető. Ezért gyakran javasoljuk több számla használatát, hogy az eszközök és az érték ne legyen könnyen követhető. Vannak azonban fejlesztés alatt álló megoldások, amelyek nagyobb védelmet nyújtanak a tranzakció- és számlaadatoknak. De most nézzük meg a számlákról elérhető adatokat: - -**Felhasználói számlák** - -- Számlacím – a nyilvános cím, amelyre pénzt küldhet. -- ETH egyenleg – a számlához tartozó ETH mennyisége. -- Teljes ETH érték – az ETH értéke. -- Tokenek – a számlához tartozó tokenek és értékeik. -- Tranzakciótörténet – az összes tranzakciót tartalmazó lista, ahol a számla volt a küldő vagy a címzett. - -**Okosszerződések** - -Az okosszerződés-számlák rendelkeznek az összes adattal, amivel a felhasználói számlák is, de némelyik blokkfelfedező némi kódinformációt is szolgáltat. Többek között például: - -- Szerződés létrehozója – a cím, amelyik feltöltötte a szerződést a fő hálózatra. -- Létrehozó tranzakció – a tranzakció, amely tartalmazta a telepítést a fő hálózatra. -- Forráskód – az okosszerződés solidity vagy vyper kódja. -- Szerződés ABI – a szerződés Application Binary Interface-e (alkalmazásprogramozói interfésze) – a szerződés általi hívásokat és a kapott adatokat tartalmazza. -- Szerződés létrehozási kódja – az okosszerződés lefordított bájtkódja – akkor jön létre, amikor Ön Solidityben vagy Vyperben stb. írt okosszerződést fordít. -- Szerződésesemények – az okosszerződésben lehívott módszerek előzményei. Alapvetően azt mutatja meg, hogyan és milyen gyakran használják a szerződést. - -### Tokenek {#tokens} - -A token egy szerződéstípus, így az okosszerződésekhez hasonló adatokkal rendelkezik. De mivel van értéke és lehet vele kereskedni, ezért további adatpontjai is vannak: - -- Típus – lehet ERC-20, ERC-721 vagy más tokenszabvány. -- Árfolyam – ha egy ERC-20, akkor van aktuális piaci értéke. -- Piaci kapitalizáció – ha ERC-20, akkor van piaci kapitalizációja (számítása: árfolyam × teljes kínálat). -- Teljes kínálat – a forgalomban lévő tokenek száma. -- Tulajdonosok – a tokent birtokló címek száma. -- Átutalások – a számlák közötti tokenátutalások esetszáma. -- Tranzakciótörténet – az adott tokent tartalmazó összes korábbi tranzakció. -- Szerződéscím – a fő hálózatra feltelepített token címe. -- Tizedesjegyek – az ERC-20 tokenek oszthatók és vannak tizedes helyeik. - -### Hálózat {#network} - -Egyes blokkadatok holisztikusabb módon foglalkoznak az Ethereum-hálózat egészségével. - -- Összes tranzakció – az Ethereum létrehozása óta végbement összes tranzakció száma. -- Tranzakció/másodperc – az egy másodperc alatt feldolgozható tranzakciók száma. -- ETH-árfolyam – 1 ETH aktuális értéke. -- Teljes ETH-kínálat – a forgalomban lévő ETH-mennyiség – ne feledje, hogy minden egyes blokk létrejöttével új ETH jön létre blokkjutalom formájában. -- Piaci kapitalizáció – számítása: árfolyam × kínálat. - -## Konszenzusréteg-adatok {#consensus-layer-data} - -### Korszak {#epoch} - -Biztonsági okokból minden korszak végén (vagyis 6,4 percenként) véletlenszerűen összeállított validátorbizottságok jönnek létre. A korszakadatok a következőket tartalmazzák: - -- Korszak száma -- Véglegesített állapot – véglegessé vált-e a korszak (Igen/Nem). -- Idő – az idő, amikor véget ért a korszak. -- Tanúsítások – a korszakon belüli tanúsítások száma (szavazás blokkokra a slotokon belül). -- Letétek – a korszakban foglalt ETH-letétek száma (a validátoroknak ETH-t kell letenniük, hogy validátorok lehessenek). -- Megvágások – a blokkelőterjesztőknek és tanúsítóknak kirótt büntetések száma. -- Szavazási részvétel – a letétbe helyezett ETH-mennyiség, amelyet blokktanúsításra használtak. -- Validátorok – a korszakban aktív validátorok száma. -- Átlagos validátoregyenleg – az aktív validátorok átlagos egyenlege. -- Slotok – a korszakban lévő slotok száma (a slotok egy érvényes blokkot tartalmaznak). - -### Slot {#slot} - -A slotok blokklétrehozási lehetőségek. Az egyes slotokra elérhető adat a következőket tartalmazza: - -- Korszak – a korszak, amelyben érvényes a slot. -- Slot száma -- Állapot – a slot állapota (javasolt/kihagyott). -- Idő – a slot időbélyegzője. -- Előterjesztő – a validátor, aki javasolta a blokkot a slotba. -- Blokkgyökér – a BeaconBlock hash-fa-gyökere. -- Anyagyökér – a megelőző blokk hashértéke. -- Állapotgyökér – a BeaconState hash-fa-gyökere. -- Aláírás -- Randao megjelenítés -- Graffiti – a blokkelőterjesztő belefoglalhat egy 32 bájt hosszú üzenetet a blokkjavaslatába. -- Végrehajtási adatok - - Blokkhash - - Letétszám - - Letétgyökér -- Tanúsítások – a tanúsítások száma a slotban erre a blokkra. -- Letétek – a letétek száma a slot alatt. -- Önkéntes kilépők – a kilépő validátorok száma a slot alatt. -- Megvágások – a blokkelőterjesztőknek és tanúsítóknak kirótt büntetések száma. -- Szavazatok – a validátorok, akik a blokkra szavaztak ebben a slotban. - -### Blokkok {#blocks-1} - -A proof-of-stake mechanizmus az időt slotokra és korszakokra osztja. Tehát ez új adatokat jelent! - -- Előterjesztő – az a validátor, akit algoritmussal választott ki a rendszer, hogy új blokkra tegyen javaslatot. -- Korszak – a korszak, amelyben a blokkot előterjesztették. -- Slot – a slot, amelyben a blokkot előterjesztették. -- Tanúsítások – a slotban foglalt tanúsítások száma. A tanúsítások olyanok, mint a szavazatok, amelyek azt jelzik, hogy a blokk már továbbítható a Beacon láncra. - -### Validátorok {#validators} - -A validátorok felelnek a blokkok előterjesztéséért és tanúsításáért a slotokon belül. - -- Validátorszám – egyedi szám, amely a validátort jelöli. -- Aktuális egyenleg – a validátor egyenlege a jutalmakkal együtt. -- Tényleges egyenleg – a validátor letéthez használt egyenlege. -- Bevétel – a validátor által kapott jutalmak vagy büntetések. -- Állapot – éppen online és aktív a validátor, vagy sem. -- Tanúsítási hatékonyság – az átlagos idő, amely a validátor tanúsításának lánchoz adásához szükséges. -- Aktiválási jogosultság – dátum (és korszak), amikor a validátor számára elérhetővé vált a validálás. -- Aktív ettől – dátum (és korszak), amikor a validátor aktívvá vált. -- Javasolt blokkok – a validátor által előterjesztett blokkok. -- Tanúsítások – a validátor által biztosított tanúsítások. -- Letétek – a küldő címe, a tranzakció hashértéke, a blokk száma, időbélyegzője, a validátori letét összege és állapota. - -### Tanúsítások {#attestations} - -A tanúsítások „igen” szavazatok arra, hogy a blokkot a lánchoz adják. Az adataik kapcsolódnak a tanúsítások nyilvántartásához és a tanúsító validátorokhoz. - -- Slot – a slot, amelyben a tanúsítás történt. -- Bizottságindex – a bizottság indexe az adott slotban. -- Összesítő bitek – az aggregált tanúsítást mutatja a tanúsításban részt vevő minden validátorra. -- Validátorok – a tanúsításokat szolgáltató validátorok. -- Beacon-blokkgyökér – arra a blokkra mutat, amelyet a validátorok tanúsítanak. -- Forrás – a legutolsó igazolt korszakra mutat. -- Cél – a legutolsó korszakhatárra mutat. -- Aláírás - -### Hálózat {#network-1} - -A konszenzusréteg felső szintű adatai a következők: - -- Aktuális korszak -- Aktuális slot -- Aktív validátorok – aktív validátorok száma. -- Függőben lévő validátorok – az aktiválásra váró validátorok száma. -- Letétbe helyezett ETH – a hálózaton letétbe helyezett ETH-mennyiség. -- Átlagos egyenleg – a validátorok átlagos ETH-egyenlege. - -## Blokk felfedezők {#block-explorers} - -- [Etherscan](https://etherscan.io/) – egy blokkfelfedező, amelyben adatokat kérhet le az Ethereum-főhálózatról és a Goerli tesztelőhálózatról. -- [3xpl](https://3xpl.com/ethereum) - reklámmentes nyílt forráskódú Ethereum felfedező, melyből le lehet tölteni az adatokat -- [Beaconcha.in](https://beaconcha.in/) – egy nyílt forráskódú blokkfelfedező az Ethereum főhálózatra és a Goerli teszthálózatra -- [Blockchair](https://blockchair.com/ethereum) – a legdiszkrétebb Ethereum-felfedező. Alkalmas (memóriakészlet) adatok szűrésére és válogatására is -- [Etherchain](https://www.etherchain.org/) – egy Ethereum-főhálózati blokkfelfedező -- [Ethplorer](https://ethplorer.io/) – egy blokkfelfedező, amely az Ethereum-főhálózaton és a Kovan tesztelőhálózaton található tokenekre fókuszál -- [Rantom](https://rantom.app/) – egy felhasználóbarát, nyílt forráskódú DeFi- és NFT-tranzakciómegtekintő a részletesebb betekintéshez -- [Ethernow](https://www.ethernow.xyz/) – egy valós idejű tranzakciókereső, amely lehetővé teszi az Ethereum főhálózat lánc előtti rétegének megtekintését - -## További olvasnivaló {#further-reading} - -_Ismer olyan közösségi információforrást, amely a hasznára vált? Módosítsa az oldalt, és adja hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Tranzakciók](/developers/docs/transactions/) -- [Fiókok](/developers/docs/accounts/) -- [Hálózatok](/developers/docs/networks/) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" deleted file mode 100644 index c043605dfd2..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/data-and-analytics/index.md" +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: Adat és elemzések -description: Hogyan használjon on-chain elemzéseket és adatokat a dappjában -lang: hu ---- - -## Bevezetés {#Introduction} - -Ahogy a hálózat használata tovább fejlődik, a láncon belüli adatokban egyre növekszik az értékes információk mennyisége. Az adatok mennyiségének gyors növekedésével sok idő és kapacitás kell ahhoz, hogy ezeket az információkat kalkulálni és aggregálni tudjuk, hogy riportálható legyen vagy egy alkalmazást vezéreljen. - -A jelenlegi adatszolgáltatók használata előmozdíthatja a fejlesztést, sokkal pontosabb eredményeket adhat és csökkentheti a fenntartáshoz szükséges erőfeszítéseket. Ezáltal a fejlesztők koncentrálhatnak a projektjük fő funkcionalitására, melyet elérhetővé szeretnének tenni. - -## Előfeltételek {#prerequisites} - -Érdemes áttekinteni a [blokkfelfedezők](/developers/docs/data-and-analytics/block-explorers/) alapkoncepcióját, hogy hogyan használhatók adatelemzési területen. Emellett az [index](/glossary/#index) koncepciójának megértése is fontos, hogy egyértelművé váljon, a rendszerterv részeként milyen előnyöket hozhat. - -Az architektúra alapjaiból fontos ismerni, mi az az [API](https://www.wikipedia.org/wiki/API) és a [REST](https://www.wikipedia.org/wiki/Representational_state_transfer), akár csak elméletben. - -## Blokk felfedezők {#block-explorers} - -Néhány [blokkfelfedező](/developers/docs/data-and-analytics/block-explorers/) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API)-kapcsolatokat ajánl, hogy a fejlesztőknek rálátásuk legyen a blokkok, tranzakciók, validátorok, számlák és más láncon folyó tevékenységek aktuális adataira. - -A fejlesztők ezáltal ezeket az adatokat feldolgozzák és átalakítják, hogy a felhasználóiknak egyedi rálátásuk legyen a [blokkláncra](/glossary/#blockchain) és interakcióba léphessenek vele. Például az [Etherscan](https://etherscan.io) végrehajtási és konszenzusok adatokat biztosít minden 12 másodperces slotról. - -## The Graph {#the-graph} - -A [Graph Network](https://thegraph.com/) egy decentralizált indexáló protokoll a blokkláncadatok összerendezésére. Ahelyett, hogy láncon kívüli és centralizált adattárházakat építenének és menedzselnének a láncon belüli adatok aggregálására, a The Graph révén a fejlesztők szerver nélküli alkalmazásokat építhetnek, melyek teljes mértékben nyilvános infrastruktúrán működnek. - -A [GraphQL](https://graphql.org/) lekérdezési nyelv használatával a fejlesztők lekérdezhetik bármelyik gondozott, nyílt API-t, más néven algráfot (subgraph), hogy megszerezzék az alkalmazás működéséhez szükséges információkat. Az indexált algráfok lekérdezésével a riportok és alkalmazások nemcsak teljesítmény- és skálázási előnyhöz jutnak, hanem a hálózati konszenzus által biztosított adathelyességet is élvezhetik. A hálózatba kerülő új fejlesztésekkel és algráfokkal az Ön projektje is gyorsan előnyt kovácsolhat ezekből az újdonságokból. - -## Kliensdiverzitás - -A [kliensdiverzitás](/developers/docs/nodes-and-clients/client-diversity/) rendkívül fontos az egész Ethereum-hálózat átfogó egészsége szempontjából, mivel védelmet biztosít a hibák és támadások ellen. Számos kliensdiverzitásról szóló kimutatás elérhető, mint a [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) és az [Ethernodes](https://ethernodes.org/). - -## Dune-elemzések {#dune-analytics} - -A [Dune-elemzések](https://dune.com/) előre feldolgozzák a blokkláncadatokat relációs adatbázistáblákba (DuneSQL), hogy a felhasználók lekérdezhessék a blokklánc adatait SQL segítségével és ennek eredményéből további kimutatásokat építhessenek. A láncon lévő adatok 4 nyerstáblába rendeződnek: `blocks` (blokkok), `transactions` (tranzakciók), `logs` (eseménynaplózás) és `traces` (meghívások nyomai). A népszerű szerződéseket és protokollokat dekódolják, és mindegyik rendelkezik a maga eseményeket és meghívásokat tartalmazó tábláival. Ezeket az esemény- és hívástáblákat tovább dolgozzák és absztrakciós táblákba szervezik a protokollok típusa szerint, mint amilyen a DEX, kölcsönzés, stabilérmék stb. - -## SubQuery hálózat {#subquery-network} - -A [SubQuery](https://subquery.network/) egy vezető adatindexelő, amely gyors, megbízható, decentralizált és testreszabott API-okat biztosít a fejlesztőknek web3 projektjeikhez. A SubQuery több mint 165 ökoszisztéma (beleértve az Ethereumot is) fejlesztőinek ad lehetőséget indexált adatokkal, hogy intuitív és magával ragadó élményt nyújtsanak felhasználóiknak. A SubQuery Network egy rugalmas és decentralizált infrastrukturális hálózattal támogatja a megállíthatatlan alkalmazásokat. Használja a SubQuery blokklánc fejlesztői eszköztárát a jövő web3 alkalmazásainak létrehozásához, anélkül, hogy időt kellene fordítania az adatfeldolgozási tevékenységekhez szükséges egyedi backend létrehozására. - -A kezdéshez látogasson el az [Ethereum gyors kezdés útmutatóhoz](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html), hogy percek alatt elkezdhesse az Ethereum blokkláncadatok indexelését egy helyi Docker-környezetben tesztelés céljából, mielőtt élesben elindulna egy [SubQuery menedzselt szolgáltatáson](https://managedservice.subquery.network/) vagy [SubQuery decentralizált hálózaton](https://app.subquery.network/dashboard). - -## Ethernow - Mempool Data Program {#ethernow} -A [Blocknative](https://www.blocknative.com/) nyílt hozzáférést biztosít az Ethereum historikus [mempool adatarchívumához](https://www.ethernow.xyz/mempool-data-archive). Ez lehetővé teszi a kutatók és a közösségi célú projektek számára, hogy feltárják az Ethereum főhálózat lánc előtti rétegét. Az adatkészletet folyamatosan karbantartják, és az Ethereum ökoszisztémán belül ez adja a mempool tranzakciós események legátfogóbb historikus nyilvántartását. Tudjon meg többet az [Ethernow](https://www.ethernow.xyz/) működéséről. - -## További olvasnivaló {#further-reading} - -- [A gráfhálózat áttekintése](https://thegraph.com/docs/en/about/network/) -- [Gráflekérdezési próbafelület (playground)](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) -- [API-kódpéldák az EtherScan oldalon](https://etherscan.io/apis#contracts) -- [Beaconcha.in – Beaconlánc-felfedező](https://beaconcha.in) -- [A Dune alapjai](https://docs.dune.com/#dune-basics) -- [SubQuery Ethereum gyors használati útmutató](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" deleted file mode 100644 index 7a9fa7487e3..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/development-networks/index.md" +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Fejlesztői hálózatok -description: Áttekintés az fejlesztői hálózatokról és az eszközökről, melyek segítségével Ethereum applikációk fejleszthetőek. -lang: hu ---- - -Amikor okosszerződéseket tartalmazó Ethereum alkalmazást épít, fontos, hogy egy lokális hálózaton lefuttassa azt, hogy megnézze hogyan működik telepítés előtt. - -Hasonlóan ahhoz, amikor egy lokális szervert futtat a számítógépén webfejlesztés céljából, használhat fejlesztői hálózatokat egy lokális blokkláncpéldány létrehozásához, ahol tesztelheti a dappot. Ezek az Ethereum fejlesztői hálózatok olyan tulajdonságokkal rendelkeznek, melyek lehetővé teszik a gyorsabb iterációt, mint egy nyilvános teszthálózat (például nem kell azzal bajlódnia, hogy ETH-t szerezz egy teszthálózati csapból). - -## Előfeltételek {#prerequisites} - -Először meg kell értenie az [Ethereum stack alapjait](/developers/docs/ethereum-stack/) és az [Ethereum hálózatokat](/developers/docs/networks/) mielőtt elmélyedne a fejlesztői hálózatokban. - -## Mi a fejlesztői hálózat? {#what-is-a-development-network} - -A fejlesztői hálózatok lényegében olyan Ethereum kliensek (Ethereum implementációk), melyeket kimondottan a lokális fejlesztéshez terveztek. - -**Miért ne futtassunk standard Ethereum csomópontot lokálisan?** - -_Akár _ [saját csomópontot is futtathat](/developers/docs/nodes-and-clients/#running-your-own-node), de mivel a fejlesztői hálózatok célzottan a fejlesztésre vannak létrehozva, olyan kényelmi funkciók is be vannak építve, mint például: - -- A lokális blokklánc determinisztikus feltöltése adatokkal (például számlák ETH egyenleggel) -- Azonnali blokklétrehozás minden egyes megkapott tranzakciónál, sorrendben és késés nélkül -- Fejlett hibakeresés és naplózási funkciók - -## Elérhető eszközök {#available-projects} - -**Megjegyzés**: A legtöbb [fejlesztői keretrendszer](/developers/docs/frameworks/) egy beépített fejlesztői hálózatot tartalmaz. Ajánljuk, hogy egy keretrendszer segítségével [állítsa be a helyi fejlesztési környezetét](/developers/local-environment/). - -### Hardhat Network {#hardhat-network} - -Egy helyi Ethereum hálózat fejlesztésre tervezve. Szerződéseket telepíthet, teszteket futtathat, hibakeresést és javítást végezhet a kódján. - -A Hardhat Network a beépített Hardhat-tel jön, ami egy Ethereum fejlesztői környezet szakembereknek. - -- [Honlap](https://hardhat.org/) -- [GitHub](https://github.com/nomiclabs/hardhat) - -### Helyi Beacon láncok {#local-beacon-chains} - -Néhány konszenzusos kliens rendelkezik olyan beépített eszközökkel, amellyel fel lehet állítani helyi Beacon láncokat a teszteléshez. Elérhető instrukciók a Lighthouse, Nimbus és Lodestar kliensekhez: - -- [Helyi teszthálózat a Lodestarhoz](https://chainsafe.github.io/lodestar/usage/local/) -- [Helyi teszthálózat a Lighthouse-hoz](https://lighthouse-book.sigmaprime.io/setup.html#local-testnets) -- [Helyi teszthálózat a Nimbushoz](https://github.com/status-im/nimbus-eth1/blob/master/fluffy/docs/local_testnet.md) - -### Nyilvános Ethereum-tesztláncok {#public-beacon-testchains} - -Az Ethereum két karbantartott, nyilvános tesztimplementációval is rendelkezik: Goerli és Sepolia. A Goerli a javasolt teszthálózat, mely hosszú távú támogatással bír, és mindenkinek ingyenesen használható validálásra. A Sepolia egy újabb, kisebb lánc, melyet szintén fenn akarnak tartani a jövőben, és amelynek része egy engedélyhez kötött validátorszett (nem működhet bárki validátorként). A Ropsten lánc 2022. 4. negyedévében, a Rinkeby lánc pedig 2023. 2./3. negyedévében kerül lezárásra. - -- [Goerli letétbe helyezési indítópult](https://goerli.launchpad.ethereum.org/) -- [Ropsten, Rinkeby és Kiln kivezetési bejelentés](https://blog.ethereum.org/2022/06/21/testnet-deprecation) - -### Kurtosis Ethereum csomag {#kurtosis} - -A Kurtosis egy felépített rendszer a több konténeres tesztkörnyezetekhez, amellyel a fejlesztők lokálisan felállíthatják a reprodukálható példányait a blokklánchálózatoknak. - -Az Ethereum Kurtosis csomag segítségével gyorsan létrehozható egy paraméterezhető, nagymértékben skálázható és privát Ethereum teszthálózat a Docker vagy a Kubernetes segítségével. A csomag támogatja az összes főbb végrehajtási (EL) és konszenzusréteg (CL) klienst. A Kurtosis elegánsan kezeli az összes helyi port hozzárendelést és szolgáltatáskapcsolatot egy reprezentatív hálózathoz, amelyet az Ethereum fő infrastruktúrával kapcsolatos validálási és tesztelési munkafolyamatokban lehet használni. - -- [Ethereum hálózati csomag](https://github.com/kurtosis-tech/ethereum-package) -- [Honlap](https://www.kurtosis.com/) -- [GitHub](https://github.com/kurtosis-tech/kurtosis) -- [Dokumentáció](https://docs.kurtosis.com/) - -## További olvasnivaló {#further-reading} - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) -- [Helyi fejlesztői környezet felállítása](/developers/local-environment/) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" deleted file mode 100644 index b6f21851595..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ethereum-stack/index.md" +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Bevezetés az Ethereum stack-be -description: Egy áttekintő az Ethereum stack különböző rétegeiről és arról, hogyan illenek egymásba. -lang: hu ---- - -Mint bármely szoftverstack, az „Ethereum-stack” is változni fog projektről projektre az Ön céljaitól függően. - -Vannak azonban alap Ethereum technológiák, melyek segítenek egy mentális modellt szolgáltatni arról, hogy a szoftver alkalmazások hogyan lépnek interakcióba az Ethereum blokklánccal. A stack rétegeinek megértése segíteni fog megérteni az Ethereum szoftver projektekbe történő integrálásának különböző módjait. - -## Első szint: Ethereum Virtuális Gép {#ethereum-virtual-machine} - -Az [Ethereum virtuális gép (EVM)](/developers/docs/evm/) egy futtatókörnyezet az Ethereumon az okosszerződések számára. Az Ethereum blokkláncon minden okosszerződést és állapot változást [tranzakciók](/developers/docs/transactions/) hajtanak végre. Az EVM kezeli az összes tranzakció feldolgozását az Ethereum hálózaton. - -Mint bármilyen virtuális gép esetében, az EVM egy absztrakciós szintet hoz létre a kód végrehajtás és a végrehajtó gép (egy Ethereum csomópont) között. Az EVM jelenleg több ezer csomóponton fut szerte a világban. - -A háttérben az EVM opcode utasítások sorozatát használja meghatározott feladatok végrehajtásához. Ez a (140 egyedi) operációs kód lehetővé teszi az EVM számára, hogy [Turing-teljes](https://en.wikipedia.org/wiki/Turing_completeness) legyen, tehát az EVM bármit ki tud számolni, ha elég erőforrás áll rendelkezésre. - -Dapp fejlesztőként nem kell sokat tudnod az EVM-ről azon kívül, hogy létezik és megbízhatóan működteti az összes Ethereum alkalmazást állásidő nélkül. - -## Második szint: Okosszerződések {#smart-contracts} - -Az [okosszerződések](/developers/docs/smart-contracts/) olyan futtatható programok, melyek az Ethereum blokkláncon futnak. - -Az okosszerződéseket specifikus [programozási nyelveken](/developers/docs/smart-contracts/languages/) írják, melyek EVM bájtkódra fordítódnak (alacsony szintű gépi instrukciók, melyeket opcode-nak nevezünk). - -Az okosszerződések nem csak nyílt forráskódú könyvtáraknak felelnek meg, hanem lényegében nyílt API szolgáltatásokként működnek, melyek 24/7-ben futnak és nem lehet őket leállítani. Az okosszerződések nyilvános függvényeket szolgáltatnak, amelyeket a felhasználók és az alkalmazások ([dappok](/developers/docs/dapps/)) engedély nélkül meghívhatnak. Bármelyik alkalmazás összekapcsolható a működő okosszerződésekkel, hogy valamilyen funkcionalitást alkosson, mint például [adatok használata](/developers/docs/oracles/), illetve támogassa a tokenek átváltását. Bárki telepíthet új okosszerződéseket az Ethereumra, hogy tetszőleges funkcionalitást adjon, mely egyezik az alkalmazás szükségleteivel. - -Dapp fejlesztőként csak akkor kell okosszerződéseket írnia, ha szeretne egyedi funkciókat hozzáadni az Ethereum blokklánchoz. Hamar rájöhetsz, hogy a projekted legtöbb célját elérheted csupán a létező okosszerződések integrálásával, például ha szeretnéd használni a stablecoin fizetéseket vagy lehetővé tenni a tokenek decentralizált cseréjét. - -## Harmadik szint: Ethereum csomópontok {#ethereum-nodes} - -Ahhoz, hogy az alkalmazás az Ethereum-blokklánccal működni tudjon, egy [Ethereum-csomóponthoz](/developers/docs/nodes-and-clients/) kell kapcsolódnia. Egy ilyen csomópont lehetővé teszi, hogy elérje a blokkláncon lévő adatokat és/vagy tranzakciókat küldjön a hálózatnak. - -Az Ethereum csomópontok egy szoftvert - Ethereum klienst - futtató számítógépek. Egy kliens egy Ethereum implementáció, mely hitelesíti az összes tranzakciót az egyes blokkokban, így a hálózat biztonságos marad az adatok pedig pontosak. **Az Ethereum-csomópontok összessége az Ethereum-blokklánc**. Kollektívan tárolják az Ethereum blokklánc állapotát és konszenzust érnek el a tranzakciókon, melyek a blokklánc állapotot megváltoztatják. - -Hogyha összekapcsolja az alkalmazást egy Ethereum-csomóponttal ([JSON RPC-n](/developers/docs/apis/json-rpc/) keresztül), akkor az alkalmazás képes lesz adatokat leolvasni a blokkláncról (például felhasználóiszámla-egyenlegek), illetve új tranzakciókat közvetíteni a hálózatra (például ETH-átutalás felhasználói számlák között, illetve okosszerződés-függvények futtatása). - -## Négyes szint: Ethereum kliens API-ok {#ethereum-client-apis} - -Sok kényelmi könyvtár (melyet az Ethereum nyílt forráskódú közössége fejleszt és tart karban) lehetővé teszi a végfelhasználói alkalmazásodnak, hogy rácsatlakozzon és kommunikáljon az Ethereum blokklánccal. - -Ha a felhasználó oldali alkalmazásod egy web app, akkor érdemes `npm install`-lal telepítened egy [JavaScript API-t](/developers/docs/apis/javascript/) közvetlenül a frontendedre. Vagy lehet, hogy érdemesebb ezt a funkcionalitást a szerver oldalon implementálni egy [Python](/developers/docs/programming-languages/python/) vagy egy [Java](/developers/docs/programming-languages/java/) API-on keresztül. - -Annak ellenére, hogy ezek az API-ok nem szükséges elemei a stack-nek, sok komplexitást egyszerűsítenek le, amikor egy Ethereum csomóponttal szeretnénk kommunikálni. Ezen kívül használati függvényeket is szolgáltatnak (pl.: ETH konvertálása Gwei-be), így fejlesztőként kevesebb időt kell az Ethereum kliensek bonyodalmaival foglalkoznod és több időd jut egyedi funkcionalitást kialakítani az alkalmazásodnak. - -## Ötös szint: Végfelhasználói alkalmazások {#end-user-applications} - -A stack tetején a felhasználó oldali alkalmazások állnak. Ezek a standard alkalmazások, melyeket rendszeresen használsz és fejlesztesz manapság: főleg web és mobil alkalmazások. - -Ahogy ezeket a felhasználói felületeket fejleszted lényegében nem változott. Gyakran a felhasználóknak nem kell tudniuk arról, hogy az alkalmazás amit használnak, egy blokkláncot használ. - -## Készen áll kiválasztani a stacket? {#ready-to-choose-your-stack} - -Nézze meg az útmutatónkat, hogy[felállítson egy helyi fejlesztői környezetet](/developers/local-environment/) az Ethereum alkalmazásának. - -## További olvasnivaló {#further-reading} - -- [A web 3.0 alkalmazások architektúrája](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) – _Preethi Kasireddy_ - -_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" deleted file mode 100644 index 58675256c7a..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/frameworks/index.md" +++ /dev/null @@ -1,149 +0,0 @@ ---- -title: Dapp Fejlesztői Keretrendszerek -description: Fedezd fel a keretrendszerek tulajdonságait és hasonlítsd össze az elérhető lehetőségeket. -lang: hu ---- - -## Bevezetés a keretrendszerekbe {#introduction-to-frameworks} - -Egy teljes értékű dapp fejlesztése több technológiát is igényel. A szoftver keretrendszerek sok szükséges funkciót tartalmaznak, vagy egyszerű plugin rendszereket biztosítanak, melyek segítenek kiválasztani a kívánt eszközt. - -A keretrendszerek olyan dobozon-kívüli funkciókat kínálnak, melyekkel: - -- Felállíthatsz vele egy helyi blokkláncot. -- Eszközök az okos szerződéseid fordítására és tesztelésére. -- Kliens fejlesztési addonok, hogy ugyanabban a projektben/repóban fejleszthess felhasználói alkalmazásokat. -- Ethereum hálózatokhoz és szerződések telepítésére való konfiguráció, legyen az helyileg futó instance vagy valamelyik publikus Ethereum hálózat. -- Decentralizált app elosztás - IPFS-hez hasonló tárhely integrációk. - -## Előfeltételek {#prerequisites} - -Mielőtt elmerülne a keretrendszerekben, javasoljuk, hogy olvassa át a bevezetés a [dappokba](/developers/docs/dapps/) és a [Ethereum stack](/developers/docs/ethereum-stack/) cikkeket. - -## Elérhető keretrendszerek {#available-frameworks} - -**Foundry** – **_A Foundry egy gyors, hordozható és moduláris eszközrendszer az Ethereum alkalmazásfejlesztésre._** - -- [Foundry telepítése](https://book.getfoundry.sh/) -- [Foundry könyv](https://book.getfoundry.sh/) -- [Foundry közösségi csevegés Telegramon](https://t.me/foundry_support) -- [Lenyűgöző Foundry](https://github.com/crisgarner/awesome-foundry) - -**Hardhat -** **_Ethereum fejlesztői környezet profiknak._** - -- [hardhat.org](https://hardhat.org) -- [GitHub](https://github.com/nomiclabs/hardhat) - -**Ape -** **_Az okosszerződés-fejlesztői eszköz a pythonisták, adattudósok és biztonsági szakértők számára._** - -- [Dokumentáció](https://docs.apeworx.io/ape/stable/) -- [GitHub](https://github.com/ApeWorX/ape) - -**Web3j -** **_Platform a blokklánc alkalmazások fejlesztésére a JVM-n._** - -- [Honlap](https://www.web3labs.com/web3j-sdk) -- [Dokumentáció](https://docs.web3j.io) -- [GitHub](https://github.com/web3j/web3j) - -ethers-kt – **_Async, nagy teljesítményű Kotlin/Java/Android könyvtár EVM-alapú blokkláncokhoz._** - -- [GitHub](https://github.com/Kr1ptal/ethers-kt) -- [Példák](https://github.com/Kr1ptal/ethers-kt/tree/master/examples) -- [Discord](https://discord.gg/rx35NzQGSb) - -**Create Eth App -** **_Készítsen Ethereum-alapú appokat egy paranccsal. UI-keretrendszerek és DeFi-sablonok széles választék._** - -- [GitHub](https://github.com/paulrberg/create-eth-app) -- [Sablonok](https://github.com/PaulRBerg/create-eth-app/tree/develop/templates) - -**Scaffold-Eth -** **_Ethers.js + Hardhat + React komponensek és hook-ok web3-hoz: minden, amire szükség van, hogy el tudjon kezdeni okosszerződések által működtetett decentralizált alkalmazásokat fejleszteni._** - -- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) - -**Tenderly -** **_Web3 fejlesztői platform, amely lehetővé teszi a blokklánc-fejlesztőknek, hogy okosszerződéseket építsenek, teszteljenek, debuggoljanak, felügyeljenek és üzemeltessenek, illetve fejlesszék a dapp UX-t._** - -- [Honlap](https://tenderly.co/) -- [Dokumentáció](https://docs.tenderly.co/ethereum-development-practices) - -**The Graph -** **_Blokkláncadatok hatékony lekérdezése a The Graph segítségével._** - -- [Honlap](https://thegraph.com/) -- [Útmutató](/developers/tutorials/the-graph-fixing-web3-data-querying/) - -**Alchemy -** **_Ethereum Fejlesztési Platform._** - -- [alchemy.com](https://www.alchemy.com/) -- [GitHub](https://github.com/alchemyplatform) -- [Discord](https://discord.com/invite/alchemyplatform) - -**NodeReal -** **_Ethereum fejlesztői platform._** - -- [Nodereal.io](https://nodereal.io/) -- [GitHub](https://github.com/node-real) -- [Discord](https://discord.gg/V5k5gsuE) - -**thirdweb SDK -** **_Építsen web3 alkalmazásokat, amelyek interakcióba lépnek az okosszerződésével az erőteljes SDK-kat és CLI-t használva._** - -- [Dokumentáció](https://portal.thirdweb.com/sdk/) -- [GitHub](https://github.com/thirdweb-dev/) - -**Chainstack -** **_Web3 (Ethereum és egyéb) fejlesztői platform._** - -- [chainstack.com](https://www.chainstack.com/) -- [GitHub](https://github.com/chainstack) -- [Discord](https://discord.gg/BSb5zfp9AT) - -**Crossmint -** **_Vállalat szintű web3 fejlesztési platform, amely lehetővé teszi, hogy NFT alkalmazásokat építsen minden nagyobb EVM (és más) láncra._** - -- [Honlap](https://www.crossmint.com) -- [Dokumentáció](https://docs.crossmint.com) -- [Discord](https://discord.com/invite/crossmint) - -**Brownie -** **_Python-alapú fejlesztői környezet és tesztelési keretrendszer._** - -- [Dokumentáció](https://eth-brownie.readthedocs.io/en/latest/) -- [GitHub](https://github.com/eth-brownie/brownie) -- **A Brownie karbantartása jelenleg szünetel** - -**OpenZeppelin SDK -** **_The Ultimate Smart Contract Toolkit: egy eszköztár okosszerződések fejlesztéséhez, összeállításához, továbbfejlesztéséhez, telepítéséhez és az okosszerződésekkel való interakciókhoz._** - -- [OpenZeppelin SDK](https://openzeppelin.com/sdk/) -- [GitHub](https://github.com/OpenZeppelin/openzeppelin-sdk) -- [Közösségi Fórum](https://forum.openzeppelin.com/c/support/17) -- **Az OpenZeppelin SDK fejlesztése befejeződött** - -**Catapulta -** **_Több láncos okosszerződések telepítési eszköze, automatizálja az ellenőrzéseket a blokkfelfedezőkben, nyomon követi a telepített okosszerződéseket és megosztja a telepítési jelentéseket, plug-n-play a Foundry és Hardhat projektekhez._** - -- [Honlap](https://catapulta.sh/) -- [Dokumentáció](https://catapulta.sh/docs) -- [Github](https://github.com/catapulta-sh) - -**Covalent –** **_Gazdagított blokklánc API-ok 200+ lánchoz._** - -- [covalenthq.com](https://www.covalenthq.com/) -- [Dokumentáció](https://www.covalenthq.com/docs/api/) -- [GitHub](https://github.com/covalenthq) -- [Discord](https://www.covalenthq.com/discord/) - -**Wake -** **_Minden az egyben Python keretrendszer a szerződéseknek a teszteléshez, fuzzinghoz, telepítéshez, sebezhetőségi vizsgálathoz és kódnavigációhoz._** - -- [Honlap](https://getwake.io/) -- [Dokumentáció](https://ackeeblockchain.com/wake/docs/latest/) -- [GitHub](https://github.com/Ackee-Blockchain/wake) -- [VS Code Extension](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity) - -**Veramo -** **_Egy nyílt forráskódú, moduláris és agnosztikus keretrendszer, amely megkönnyíti a decentralizált alkalmazások fejlesztői számára a decentralizált identitások és ellenőrizhető hitelesítő adatok beépítését az alkalmazásaikba._** - -- [Honlap](https://veramo.io/) -- [Dokumentáció](https://veramo.io/docs/basics/introduction) -- [GitHub](https://github.com/uport-project/veramo) -- [Discord](https://discord.com/invite/FRRBdjemHV) -- [NPM csomag](https://www.npmjs.com/package/@veramo/core) - -## További olvasnivaló {#further-reading} - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Helyi fejlesztői környezet felállítása](/developers/local-environment/) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" deleted file mode 100644 index cc50ecb9db6..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/ides/index.md" +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Integrált Fejlesztői Környezetek (IDE-k) -description: -lang: hu ---- - -Amikor egy [integrált fejlesztői környezet (IDE)](https://wikipedia.org/wiki/Integrated_development_environment) felállításáról van szó, az Ethereumon történő fejlesztés hasonló bármely más szoftveres projekthez. Sok lehetőség közül lehet választani, ezért azt az IDE-t vagy kódszerkesztőt válassza, amely a legjobban megfelel a preferenciáinak. Nagy valószínűséggel a legjobb IDE az Ethereum fejlesztéséhez éppen az, amit a hagyományos szoftverfejlesztéshez is használ. - -## Web alapú IDE-k {#web-based-ides} - -Ha szeretne eljátszani a kóddal, mielőtt [felállítana egy helyi fejlesztői környezetet](/developers/local-environment/), a következő webes alkalmazások az Ethereum okosszerződések fejlesztésére letteki kialakítva. - -**[Remix](https://remix.ethereum.org/)** – **_Webalapú IDE beépített statikus analízissel, és egy teszt blokklánc virtuális géppel._** - -- [Dokumentáció](https://remix-ide.readthedocs.io/en/latest/#) -- [Gitter](https://gitter.im/ethereum/remix) - -**[ChainIDE](https://chainide.com/)** – **_Egy felhőalapú, többláncos IDE_** - -- [Dokumentáció](https://chainide.gitbook.io/chainide-english-1/) -- [Súgófórum](https://forum.chainide.com/) - -**[Replit (Solidity Starter – Beta)](https://replit.com/@replit/Solidity-starter-beta)** – **_Testre szabható fejlesztői környezet az Ethereum számára, gyors újratöltéssel, hibaellenőrzéssel és első osztályú testnet-támogatással_** - -- [Dokumentáció](https://docs.replit.com/) - -**[Tenderly Sandbox](https://sandbox.tenderly.co/)** – **_Gyors prototípus-készítő környezet, ahol okosszerződéseket tud írni, elindítani és debuggolni a böngészőben Solidity-t és JavaScriptet használva_** - -**[EthFiddle](https://ethfiddle.com/)** – **_Webalapú IDE, amivel megírhatja, összeállíthatja és debuggolhatja okosszerződéseit_** - -- [Gitter](https://gitter.im/loomnetwork/ethfiddle) - -## Asztali IDE-k {#desktop-ides} - -A legtöbb megalapozott IDE-nek vannak beépített pluginjai, amelyek tovább fokozzák az Ethereum fejlesztői élményt. Legalább egy syntax kijelölést biztosítanak az [okosszerződés nyelveknek](/developers/docs/smart-contracts/languages/). - -**Visual Studio Code -** **_Professzionális keresztplatformos IDE hivatalos Ethereum-támogatással_** - -- [Visual Studio Code](https://code.visualstudio.com/) -- [Kódminták](https://github.com/Azure-Samples/blockchain/blob/master/blockchain-workbench/application-and-smart-contract-samples/readme.md) -- [GitHub](https://github.com/microsoft/vscode) - -**JetBrains IDE-k (IntelliJ IDEA, etc.) –** **_Elengedhetetlen eszközök szoftverfejlesztőknek és csapatoknak_** - -- [JetBrains](https://www.jetbrains.com/) -- [GitHub](https://github.com/JetBrains) -- [IntelliJ Solidity](https://github.com/intellij-solidity/intellij-solidity/) - -**Remix Desktop – ** **_Próbálja ki a Remix IDE-t a saját gépén_** - -- [Letöltés](https://github.com/ethereum/remix-desktop/releases) -- [GitHub](https://github.com/ethereum/remix-desktop) - -## Plugin-ok és kiterjesztések {#plugins-extensions} - -- [solidity](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) – Ethereum Solidity nyelv a Visual Studio-kódhoz -- [Solidity + Hardhat for VS Code](https://marketplace.visualstudio.com/items?itemName=NomicFoundation.hardhat-solidity) – Solidity és Hardhat a Hardhat csapat által támogatva -- [Prettier Solidity](https://github.com/prettier-solidity/prettier-plugin-solidity) – Kódformázó használata - -## További olvasnivaló {#further-reading} - -- [Ethereum IDEs](https://www.alchemy.com/list-of/web3-ides-on-ethereum) _ – Alchemy listája az Ethereum IDE-okról_ - -_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" deleted file mode 100644 index 92e02f00860..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dart/index.md" +++ /dev/null @@ -1,28 +0,0 @@ ---- -title: Ethereum Dart-fejlesztők számára -description: Sajátítsa el az Ethereum-fejlesztést a Dart programozási nyelv használatával -lang: hu -incomplete: true ---- - -## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} - -## Oktatóanyagok {#tutorials} - -- [Flutter és blokklánc – Hello World Dapp](https://www.geeksforgeeks.org/flutter-and-blockchain-hello-world-dapp/) átvezeti Önt a kezdeti lépéseken: - 1. Okosszerződés megírása [Solidity](https://soliditylang.org/) nyelven - 2. Felhasználói felület megírása Dart nyelven -- A [mobilalkalmazások építése a Flutterrel](https://medium.com/dash-community/building-a-mobile-dapp-with-flutter-be945c80315a) sokkal rövidebb, amely jobb lehet, ha már ismeri az alapokat -- Ha videók segítségével jobban szeret tanulni, akkor nézze meg az [Építse meg első blokkláncos Flutter alkalmazását](https://www.youtube.com/watch?v=3Eeh3pJ6PeA) videót, amely nagyjából egy óra hosszú -- Ha ennél kevesebb ideje van, akkor talán tetszeni fog az [Egy blokklánc decentralizált alkalmazás építése a Flutterrel és a Darttal az Ethereumon](https://www.youtube.com/watch?v=jaMFEOCq_1s) videó, amely csak húsz percet veszi igénybe -- [A MetaMask integrációja a Flutter alkalmazásban a WalletConnect által nyújtott Web3Modal használatával](https://www.youtube.com/watch?v=v_M2buHCpc4) – ez a rövid videó bemutatja, hogyan kell a MetaMaskot beintegrálni a Flutter alkalmazásokba a [Web3Modal](https://pub.dev/packages/web3modal_flutter) könyvtárral, melyet a WalletConnect biztosít -- [Mobil blokkláncfejlesztői képzés Solidity-val és Flutterrel](https://youtube.com/playlist?list=PL4V4Unlk5luhQ26ERO6hWEbcUwHDSSmVH) – mobil blokkláncfejlesztői tanfolyam a teljes stack-kel (lejátszási lista) - -## Munka Ethereum kliensekkel {#working-with-ethereum-clients} - -Az Ethereumot decentralizált alkalmazások (dappok) fejlesztésére használhatja, amelyek a kriptovaluták és a blokklánc-technológia nyújtotta összes előnyét kiélvezhetik. A Darthoz legalább két könyvtárat tartanak karban, hogy a [JSON-RPC API-t](/developers/docs/apis/json-rpc/) használja az Ethereumra. - -1. [Web3dart a simonbutler.eu forrásból](https://pub.dev/packages/web3dart) -1. [Ethereum 5.0.0 a darticulate.com forrásból](https://pub.dev/packages/ethereum) - -Vannak még emellett olyan könyvtárak is, amelyekkel bizonyos Ethereum címeket lehet kezelni, vagy különféle kriptovaluták árait lehet lekérdezni. [Ezek teljes listája itt látható](https://pub.dev/dart/packages?q=ethereum). diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" deleted file mode 100644 index aa8c739a3d4..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/delphi/index.md" +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: Ethereum Delphi-fejlesztők számára -description: Tanulja meg az Ethereum fejlesztést a Delphi programozási nyelv használatával -lang: hu -incomplete: true ---- - - - -Tanulja meg az Ethereum fejlesztést a Delphi programozási nyelv használatával - - - -Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. - -Fejlesszen decentralizált alkalmazásokat Ethereumra, és lépjen interakcióba okosszerződésekkel a Delphi programozási nyelv használatával! - -## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-the-solidity-language} - -**Tegye meg az első lépést, hogy integrálja a Delphi-t az Ethereummal** - -Szükséged van egy még kezdetlegesebb alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. - -- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) -- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) - -## Referenciák és hivatkozások kezdők számára {#beginner-references-and-links} - -**Bevezetés a Delphereum könyvtárba** - -- [Mi az a Delphereum?](https://github.com/svanas/delphereum/blob/master/README.md) -- [A Delphi összekapcsolása egy lokális (in-memory) blokklánccal](https://medium.com/@svanas/connecting-delphi-to-a-local-in-memory-blockchain-9a1512d6c5b0) -- [Delphi összekapcsolása az Ethereum főhálózattal](https://medium.com/@svanas/connecting-delphi-to-the-ethereum-main-net-5faf1feffd83) -- [Delphi összekapcsolása okosszerződésekkel](https://medium.com/@svanas/connecting-delphi-to-smart-contracts-3146b12803a1) - -**Szeretné kihagyni a telepítést, és egyenesen a mintákra ugrani?** - -- [3 perces okosszerződés és Delphi - Első rész](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-61d998571d) -- [3 perces okosszerződés és Delphi - Második rész](https://medium.com/@svanas/a-3-minute-smart-contract-and-delphi-part-2-446925faa47b) - -## Köztes cikkek {#intermediate-articles} - -- [Egy Ethereumon aláírt üzenetaláírás generálása Delphi-ben](https://medium.com/@svanas/generating-an-ethereum-signed-message-signature-in-delphi-75661ce5031b) -- [Ether átutalás Delphi-vel](https://medium.com/@svanas/transferring-ether-with-delphi-b5f24b1a98a4) -- [ERC-20 token átutalás Delphi-vel](https://medium.com/@svanas/transferring-erc-20-tokens-with-delphi-bb44c05b295d) - -## Speciális használati minták {#advanced-use-patterns} - -- [Delphi és az Ethereum Name Service (ENS)](https://medium.com/@svanas/delphi-and-ethereum-name-service-ens-4443cd278af7) -- [QuikNode, Ethereum és Delphi](https://medium.com/@svanas/quiknode-ethereum-and-delphi-f7bfc9671c23) -- [Delphi és az Ethereumi sötét erdő](https://svanas.medium.com/delphi-and-the-ethereum-dark-forest-5b430da3ad93) -- [Tokenátváltás a Delphiben](https://svanas.medium.com/swap-one-token-for-another-in-delphi-bcb999c47f7) - -Még több anyagot keresel? Tekintsd meg az [ethereum.org/developers](/developers/) oldalt. diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" deleted file mode 100644 index ebd7aedeba5..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/dot-net/index.md" +++ /dev/null @@ -1,86 +0,0 @@ ---- -title: Ethereum .NET-fejlesztők számára -description: Tanuljon meg Ethereumon fejleszteni .NET-alapú projektek és eszközök használatával -lang: hu -incomplete: true ---- - -Tanuljon meg Ethereumon fejleszteni .NET-alapú projektek és eszközök használatával - -Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. - -Építsen decentralizált alkalmazásokat Ethereumra és lépjen kapcsolatba okosszerződésekkel a Microsoft tech stack használatával, mely támogatja a C#, # Visual Basic .NET, F# nyelveket VSCode és Visual Studio eszközökkel a .NET Framework/.NET Core/.NET Standard-on keresztül. Telepítsen percek alatt egy Ethereum blokkláncot Azure-ra a Microsoft Azure Blockchain használatával. Hozza el a .NET szeretetét az Ethereumra! - -## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-the-solidity-language} - -**Tegye meg az első lépést, hogy integrálja a .NET-et az Ethereummal** - -Szükséged van egy még kezdetlegesebb alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. - -- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) -- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) - -## Referenciák és hivatkozások kezdők számára {#beginner-references-and-links} - -**Bemutatjuk a Nethereum könyvtárat és a VS Code Solidity-t** - -- [Nethereum, Első Lépések](https://docs.nethereum.com/en/latest/getting-started/) -- [VS Code Solidity Telepítése](https://marketplace.visualstudio.com/items?itemName=JuanBlanco.solidity) -- [Egy .NET fejlesztő workflow-ja Ethereum Okosszerződések írására és hívására](https://medium.com/coinmonks/a-net-developers-workflow-for-creating-and-calling-ethereum-smart-contracts-44714f191db2) -- [Okosszerződés integráció Nethereummal](https://kauri.io/#collections/Getting%20Started/smart-contracts-integration-with-nethereum/#smart-contracts-integration-with-nethereumm) -- [A .NET és az Ethereum blokklánc okosszerződések interfészelése a Nethereummal](https://medium.com/my-blockchain-development-daily-journey/interfacing-net-and-ethereum-blockchain-smart-contracts-with-nethereum-2fa3729ac933), elérhető kínai verzió: [中文版](https://medium.com/my-blockchain-development-daily-journey/%E4%BD%BF%E7%94%A8nethereum%E9%80%A3%E6%8E%A5-net%E5%92%8C%E4%BB%A5%E5%A4%AA%E7%B6%B2%E5%8D%80%E5%A1%8A%E9%8F%88%E6%99%BA%E8%83%BD%E5%90%88%E7%B4%84-4a96d35ad1e1) -- [Nethereum – Egy nyílt forráskódú .NET integrációs könyvtár blokkláncra](https://kauri.io/#collections/a%20hackathon%20survival%20guide/nethereum-an-open-source-.net-integration-library/) -- [Ethereum tranzakciók írása SQL adatbázisba Nethereum használatával](https://medium.com/coinmonks/writing-ethereum-transactions-to-sql-database-using-nethereum-fd94e0e4fa36) -- [Nézze meg, hogy lehet egyszerűen Ethereum okosszerződéseket telepíteni C# és VisualStudio használatával](https://koukia.ca/deploy-ethereum-smart-contracts-using-c-and-visualstudio-5be188ae928c) - -**Szeretnéd kihagyni a telepítést és egyenesen a mintákra ugrani?** - -- [Playground](http://playground.nethereum.com/) - Lépjen kapcsolatba az Ethereummal, és tanulja meg a Nethereum használatát a böngészőn keresztül. - - Számlaegyenleg Lekérdezés [C#](http://playground.nethereum.com/csharp/id/1001) [VB.NET](http://playground.nethereum.com/vb/id/2001) - - ERC20 Okosszerződés Egyenleglekérdezés [C#](http://playground.nethereum.com/csharp/id/1005) [VB.NET](http://playground.nethereum.com/vb/id/2004) - - Ether utalása egy számlára [C#](http://playground.nethereum.com/csharp/id/1003) [VB.NET](http://playground.nethereum.com/vb/id/2003) - - ... És még sok más! - -## Köztes cikkek {#intermediate-articles} - -- [Nethereum Munkafüzet/Minta Lista](http://docs.nethereum.com/en/latest/Nethereum.Workbooks/docs/) -- [Telepítse saját fejlesztői tesztláncait](https://github.com/Nethereum/Testchains) -- [VSCode Codegen Plugin Solidity-re](https://docs.nethereum.com/en/latest/nethereum-codegen-vscodesolidity/) -- [Unity és Ethereum: Miért és hogyan](https://www.raywenderlich.com/5509-unity-and-ethereum-why-and-how) -- [Készítsen ASP.NET Core Web API-t Ethereum dappokra](https://tech-mint.com/blockchain/create-asp-net-core-web-api-for-ethereum-dapps/) -- [A Nethereum Web3 használata egy ellátási lánc nyomon követési rendszer implementálására](http://blog.pomiager.com/post/using-nethereum-web3-to-implement-a-supply-chain-traking-system4) -- [Nethereum blokk feldolgozás](https://nethereum.readthedocs.io/en/latest/nethereum-block-processing-detail/), egy[ C# Playground mintával](http://playground.nethereum.com/csharp/id/1025) -- [Nethereum Websocket Streaming](https://nethereum.readthedocs.io/en/latest/nethereum-subscriptions-streaming/) -- [Kaleido és Nethereum](https://kaleido.io/kaleido-and-nethereum/) -- [Quorum és Nethereum](https://github.com/Nethereum/Nethereum/blob/master/src/Nethereum.Quorum/README.md) - -## Speciális használati minták {#advanced-use-patterns} - -- [Azure Key Vault és Nethereum](https://github.com/Azure-Samples/bc-community-samples/tree/master/akv-nethereum) -- [Nethereum.DappHybrid](https://github.com/Nethereum/Nethereum.DappHybrid) -- [Ujo Nethereum backend referencia architektúra](https://docs.nethereum.com/en/latest/nethereum-ujo-backend-sample/) - -## .NET projektek, eszközök és más érdekes dolgok {#dot-net-projects-tools-and-other-fun-stuff} - -- [Nethereum Playground](http://playground.nethereum.com/) - _Fordítson, készítsen és futtasson Nethereum kódrészleteket böngészőben_ -- [Nethereum Codegen Blazor](https://github.com/Nethereum/Nethereum.CodeGen.Blazor) - _Nethereum kódgenerátor UI-jal Blazor-ben_ -- [Nethereum Blazor](https://github.com/Nethereum/NethereumBlazor) - _A .NET Wasm SPA könnyű blokklánc felfedező és egyszerű tárca_ -- [Wonka Business Rules Engine](https://docs.nethereum.com/en/latest/wonka/) - _Egy üzleti szabályokat alkalmazó program (a .NET és az Ethereum platformra is), mely örökletesen metaadat vezérelt._ -- [Nethermind](https://github.com/NethermindEth/nethermind) – _A .NET Core Ethereum-kliens Linux, Windows, macOS rendszerhez_ -- [eth-utils](https://github.com/ethereum/eth-utils/) - _használati funkciók Ethereumhoz kapcsolódó kódbázisokkal való munkához_ -- [TestChains](https://github.com/Nethereum/TestChains) - _Előre konfigurált .NET fejlesztői láncok gyors válaszra (PoA)_ - -Még több anyagot keresel? Tekintsd meg az [ethereum.org/developers](/developers/) oldalt. - -## .NET közösségi közreműködők {#dot-net-community-contributors} - -Mi a Nethereumon főleg a [Gitteren](https://gitter.im/Nethereum/Nethereum) kommunikálunk, ahol bárki nyugodtan kérdezhet/válaszolhat, segítséget kaphat vagy csak velünk lehet. Bátran készítsen egy PR-t vagy nyisson egy „problémát” (issue) a [Nethereum Github mappában](https://github.com/Nethereum), vagy csak böngésszen a rengeteg mellék-/mintaprojektjeink között. Megtalál minket [Discord-on](https://discord.gg/jQPrR58FxX) is! - -Ha Önnek új a Nethermind és segítségre van szüksége a kezdéshez, akkor csatlakozzon a [Discord](http://discord.gg/PaCMRFdvWT) csatornánkhoz. Fejlesztőink készséggel válaszolnak a kérdéseire. PR-okért vagy issue-kért tekintse meg a [Nethermind Github mappát](https://github.com/NethermindEth/nethermind). - -## Egyéb összesített listák {#other-aggregated-lists} - -[Hivatalos Nethereum Oldal](https://nethereum.com/) -[Hivatalos Nethermind Oldal](https://nethermind.io/) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/elixir/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/elixir/index.md" deleted file mode 100644 index 4b187418e5a..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/elixir/index.md" +++ /dev/null @@ -1,55 +0,0 @@ ---- -title: Ethereum Elixir-fejlesztők számára -description: Tanuljon meg Ethereumra fejleszteni Elixir-alapú projektek és eszközök használatával. -lang: hu -incomplete: false ---- - -Tanuljon meg Ethereumra fejleszteni Elixir-alapú projektek és eszközök használatával. - -Használjon Ethereumot decentralizált alkalmazások (dappok) fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok nem igényelnek bizalmat a felhasználó oldaláról, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel az újfajta pénzügyi alkalmazások számra. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. - -## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} - -**Tegye meg az első lépést, hogy integrálja a Elixirt az Ethereummal** - -Szüksége van egy kezdőknek szóló bevezetőre? Tekintse meg az [ethereum.org/learn](/learn/) vagy az [ethereum.org/developers](/developers/) oldalakat. - -- [Blokklánc magyarázat](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) -- [Okosszerződések megértése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [Írja meg első okosszerződését](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Tanulja meg a Solidity átfordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) - -## Cikkek kezdőknek {#beginner-articles} - -- [Az Ethereum számlák megértése](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) -- [Ethers — Elsőrangú Ethereum web3 könyvtár az Elixirhez](https://medium.com/@alisinabh/announcing-ethers-a-first-class-ethereum-web3-library-for-elixir-1d64e9409122) - -## Cikkek középhaladóknak {#intermediate-articles} - -- [Hogyan lehet nyers Ethereum szerződéses tranzakciót aláírni az Elixirrel](https://kohlerjp.medium.com/how-to-sign-raw-ethereum-contract-transactions-with-elixir-f8822bcc813b) -- [Ethereum okosszerződések és az Elixir](https://medium.com/agile-alpha/ethereum-smart-contracts-and-elixir-c7c4b239ddb4) - -## Elixir projektek és eszközök {#elixir-projects-and-tools} - -### Aktív {#active} - -- [block_keys](https://github.com/ExWeb3/block_keys) - _BIP32 & BIP44 implementáció Elixirben (többszámlás hierarchia a determinisztikus tárcákhoz)_ -- [ethereumex](https://github.com/mana-ethereum/ethereumex) - _Elixir JSON-RPC kliens az Ethereum blokklánchoz_ -- [ethers](https://github.com/ExWeb3/elixir_ethers) - _Egy átfogó web3 könyvtár az Ethereum-on lévő okosszerődésekkel való interakcióra az Elixirrel_ -- [ethers_kms](https://github.com/ExWeb3/elixir_ethers_kms) - _Egy KMS aláíró könyvtár az Ethers-hez (a tranzakciók aláírása AWS KMS révén)_ -- [ex_abi](https://github.com/poanetwork/ex_abi) - _Ethereum ABI értelmező/dekódoló/kódoló implementáció Elixirben_ -- [ex_keccak](https://github.com/ExWeb3/ex_keccak) - _Elixir könyvtár a Keccak SHA3-256 hash-ek kiszámolásához egy NIF által épített mini-keccak Rust tároló használatával_ -- [ex_rlp](https://github.com/mana-ethereum/ex_rlp) - _Az Ethereum RLP (Rekurzív hosszúságú prefixum) kódolásának Elixir implementációja_ - -### Archivált / a karbantartás megszűnt {#archived--no-longer-maintained} - -- [eth](https://hex.pm/packages/eth) - _Ethereum szolgáltatások az Elixirhez_ -- [exw3](https://github.com/hswick/exw3) - _Magas szintű Ethereum RPC kliens az Elixirhez_ -- [mana](https://github.com/mana-ethereum/mana) - _Ethereum teljes csomópont implementáció Elixir nyelven írva_ - -Több anyagra lenne szüksége? Tekintse meg [Fejlesztői kezdőlapot](/developers/). - -## Elixir közösségi közreműködők {#elixir-community-contributors} - -Az [Elixir Slack #ethereum channel](https://elixir-lang.slack.com/archives/C5RPZ3RJL) egy gyorsan növekvő közösség szervezője, egy dedikált erőforrás a fenti projektek és kapcsolódó témák megvitatására. diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" deleted file mode 100644 index 613a92534fa..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/golang/index.md" +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Ethereum Go fejlesztőknek -description: Tanuljon meg Ethereumra fejleszteni Go-alapú projektek és eszközök használatával -lang: hu -incomplete: true ---- - -Tanuljon meg Ethereumra fejleszteni Go-alapú projektek és eszközök használatával - -Használja az Ethereumot decentralizált alkalmazások (dappok) fejlesztésére. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Decentralizáltak, ami azt jelenti, hogy egy peer-to-peer hálózaton futnak és nincs lehetőség egyetlen hiba miatti leállásra (single point of failure). Nincs olyan entitás vagy személy, ami irányítaná őket és szinte lehetetlen őket cenzúrázni. Digitális eszközöket irányíthatnak, lehetőséget teremtve ezzel újfajta alkalmazások létrejöveteléhez. - -## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} - -**Tegye meg az első lépést, hogy integrálja a Go-t az Ethereummal** - -Szükséged van egy méginkább kezdőknek szóló alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. - -- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) -- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) -- [Szerződésútmutató](https://github.com/ethereum/go-ethereum/wiki/Contract-Tutorial) - -## Cikkek és könyvek kezdőknek {#beginner-articles-and-books} - -- [Kezdő lépések Geth-tel](https://medium.com/@tzhenghao/getting-started-with-geth-c1a30b8d6458) -- [Golang használata Ethereumra való kapcsolódásra](https://www.youtube.com/watch?v=-7uChuO_VzM) -- [Ethereum okosszerződések telepítése Golang használatával](https://www.youtube.com/watch?v=pytGqQmDslE) -- [Egy útmutató, arról, hogy hogyan kell Ethereum okosszerződéseket tesztelni és telepíteni lépésről lépésre](https://hackernoon.com/a-step-by-step-guide-to-testing-and-deploying-ethereum-smart-contracts-in-go-9fc34b178d78) -- [eBook: Ethereum fejlesztése a Go-val](https://goethereumbook.org/) – _Ethereum alkalmazások fejlesztése Go-val_ - -## Cikkek és dokumentációk haladóknak {#intermediate-articles-and-docs} - -- [Go Ethereum dokumentácó](https://geth.ethereum.org/docs/) – _A hivatalos Ethereum Golang dokumentáció_ -- [Erigon útmutató programozóknak](https://github.com/ledgerwatch/erigon/blob/devel/docs/programmers_guide/guide.md) – _Illusztrált útmutató, amely bemutatja az állapotfát, többszöri bizonyítékokat és a tranzakciófeldolgozást_ -- [Erigon és a státuszmentes Ethereum](https://youtu.be/3-Mn7OckSus?t=394) – _2020-as Ethereum Közösségi Konferencia (EthCC 3)_ -- [Erigon: Ethereum-kliensek optimalizálása](https://www.youtube.com/watch?v=CSpc1vZQW2Q) – _2018. Devcon 4_ -- [Go Ethereum GoDoc](https://godoc.org/github.com/ethereum/go-ethereum) -- [Egy dapp készítése Go-ban a Geth segítségével](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/creating-a-dapp-in-go-with-geth/) -- [Dolgozzon az Ethereum privát hálózaton a Golanggal és Geth-tel](https://myhsts.org/tutorial-learn-how-to-work-with-ethereum-private-network-with-golang-with-geth.php) -- [Solidity szerződések egységtesztje az Ethereumon a Go-val](https://medium.com/coinmonks/unit-testing-solidity-contracts-on-ethereum-with-go-3cc924091281) -- [Gyors hivatkozás, hogyan használja a Geth-t könyvtárként](https://medium.com/coinmonks/web3-go-part-1-31c68c68e20e) - -## Speciális használati minták {#advanced-use-patterns} - -- [A GETH szimulált Backend](https://kauri.io/#collections/An%20ethereum%20test%20toolkit%20in%20Go/the-geth-simulated-backend/#_top) -- [A blokklánc mint szolgáltatás alkalmazások az Ethereum és a Quorum használatával](https://blockchain.dcwebmakers.com/blockchain-as-a-service-apps-using-ethereum-and-quorum.html) -- [Elosztott tárhely IPFS és Swarm az Ethereum blokklánc alkalmazásokban](https://blockchain.dcwebmakers.com/work-with-distributed-storage-ipfs-and-swarm-in-ethereum.html) -- [Mobilkliensek: könyvtárak és inproc Ethereum csomópontok](https://github.com/ethereum/go-ethereum/wiki/Mobile-Clients:-Libraries-and-Inproc-Ethereum-Nodes) -- [Natív dappok: Go-megkötések az Ethereum szerződésekre](https://github.com/ethereum/go-ethereum/wiki/Native-DApps:-Go-bindings-to-Ethereum-contracts) - -## Go-projektek és -eszközök {#go-projects-and-tools} - -- [Geth / Go Ethereum](https://github.com/ethereum/go-ethereum) - _Az Ethereum protokoll hivatalos Go implementációja_ -- [Go Ethereum Code Analysis](https://github.com/ZtesoftCS/go-ethereum-code-analysis) - _Go Ethereum forráskód áttekintése és elemzése_ -- [Erigon](https://github.com/ledgerwatch/erigon) – _A Go Ethereum gyorsabb változata, mely az archív csomópontokra fókuszál_ -- [Golem](https://github.com/golemfactory/golem) - _A Golem egy globális piacot teremt a számítási teljesítmény számára_ -- [Quorum](https://github.com/jpmorganchase/quorum) - _Egy engedélyköteles Ethereum implementáció, mely támogatja az adatvédelmet_ -- [Prysm](https://github.com/prysmaticlabs/prysm) - _Ethereum 'Serenity' 2.0 Go implementáció_ -- [Eth Tweet](https://github.com/yep/eth-tweet) - _Decentralizált Twitter: Egy mikroblogolási szolgáltatás, mely az Ethereum blokkláncon fut_ -- [Plasma MVP Golang](https://github.com/kyokan/plasma) — _A Minimum Viable Plasma specifikációjának Golang implementációja és kiterjesztése_ -- [Open Ethereum Mining Pool](https://github.com/sammy007/open-ethereum-pool) - _Egy nyílt forráskódú Ethereum bányászalap_ -- [Ethereum HD Wallet](https://github.com/miguelmota/go-ethereum-hdwallet) - _Ethereum HD Wallet levezetések Go-ban_ -- [Multi Geth](https://github.com/multi-geth/multi-geth) - _Az Ethereum hálózatok több fajtáját támogatja_ -- [Geth Light Client](https://github.com/zsfelfoldi/go-ethereum/wiki/Geth-Light-Client) - _Light Ethereum Subprotocol Geth implementációja_ -- [Ethereum Golang SDK](https://github.com/everFinance/goether) – _Egy egyszerű Ethereum-tárcaimplementáció és eszközök Golangban_ -- [Covalent Golang SDK](https://github.com/covalenthq/covalent-api-sdk-go) - _hatékony blokklánc-adatelérés Go SDK-n keresztül 200+ blokklánchoz_ - -Még több anyagot keresel? Tekintse meg az [ethereum.org/developers](/developers/) oldalt - -## Go közösségi hozzájárulók {#go-community-contributors} - -- [Geth Discord](https://discordapp.com/invite/nthXNEv) -- [Geth Gist](https://gitter.im/ethereum/go-ethereum) -- [Gophers Slack](https://invite.slack.golangbridge.org/) - [#ethereum channel](https://gophers.slack.com/messages/C9HP1S9V2) -- [StackExchange - Ethereum](https://ethereum.stackexchange.com/) -- [Multi Geth Gitter](https://gitter.im/ethoxy/multi-geth) -- [Ethereum Gitter](https://gitter.im/ethereum/home) -- [Geth light Client Gitter](https://gitter.im/ethereum/light-client) - -## Egyéb összesített listák {#other-aggregated-lists} - -- [Awesome Ethereum](https://github.com/btomashvili/awesome-ethereum) -- [Consensys: Az Ethereum fejlesztői eszközök döntő listája](https://media.consensys.net/an-definitive-list-of-ethereum-developer-tools-2159ce865974) | [GitHub forrás](https://github.com/ConsenSys/ethereum-developer-tools-list) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" deleted file mode 100644 index f5f16f24c7e..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/index.md" +++ /dev/null @@ -1,30 +0,0 @@ ---- -title: Programozási nyelvek -description: -lang: hu ---- - -Egy általános félreértés az, hogy a fejlesztőknek [okosszerződéseket](/developers/docs/smart-contracts/) kell írniuk ahhoz, hogy az Ethereumra építhessenek. Ez nem igaz. Az Ethereum hálózat és közösség egyik szépsége, hogy szinte bármiyen programozási nyelvvel [részt lehet venni](/community/). - -Az Ethereum és a közössége befogadja az nyílt forráskódot. Közösségi projekteket – kliens implementációkat, API-okat, fejlesztési keretrendszereket, tesztelő eszközöket – sokféle különböző nyelven is megtalálhat. - -## Válasszon nyelvet {#data} - -Válasszon nyelvet, hogy megtalálja a kapcsolódó projekteket, anyagokat és a virtuális közösségeket: - -- [Ethereum Dart-fejlesztők számára](/developers/docs/programming-languages/dart/) -- [Ethereum Delphi fejlesztőknek](/developers/docs/programming-languages/delphi/) -- [Ethereum .NET fejlesztőknek](/developers/docs/programming-languages/dot-net/) -- [Ethereum Elixir-fejlesztők számára](/developers/docs/programming-languages/elixir/) -- [Ethereum Go fejlesztőknek](/developers/docs/programming-languages/golang/) -- [Ethereum Java fejlesztőknek](/developers/docs/programming-languages/java/) -- [Ethereum JavaScript fejlesztőknek](/developers/docs/programming-languages/javascript/) -- [Ethereum Python-fejlesztők számára](/developers/docs/programming-languages/python/) -- [Ethereum Ruby-fejlesztők számára](/developers/docs/programming-languages/ruby/) -- [Ethereum Rust fejlesztőknek](/developers/docs/programming-languages/rust/) - -### Mi a helyzet, ha az én nyelvem nem támogatott {#other-lang} - -Ha egy másik programozói nyelvhez szeretne forrásokat megjeleníteni vagy egy virtuális közösséget feltüntetni, akkor úgy kérhet új oldalt, hogy [egy „problémát” (issue) nyit](https://github.com/ethereum/ethereum-org-website/issues/new/choose). - -Ha csak kódot szeretne írni, hogy a blokklánccal kapcsolatba lépjen, és egy jelenleg nem támogatott nyelvet használ erre, akkor a [JSON-RPC interfésszel](/developers/docs/apis/json-rpc/) tud az Ethereum hálózatához kapcsolódni. Minden olyan nyelv alkalmas erre, amelyik képes TCP/IP használatra. diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" deleted file mode 100644 index b32ffe1dacb..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/java/index.md" +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Ethereum Java-fejlesztők számára -description: Tanuljon meg Ethereumon fejleszteni Java alapú projektek és eszközök használatával -lang: hu -incomplete: true ---- - -Tanuljon meg Ethereumon fejleszteni Java alapú projektek és eszközök használatával - -Használjon Ethereumot decentralizált alkalmazások (dappok) fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. - -## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} - -**Tegye meg az első lépést, hogy a Java-t integrálja az Ethereummal** - -Szüksége van egy kezdőknek szóló bevezetőre? Tekintse meg az [ethereum.org/learn](/learn/) vagy az [ethereum.org/developers](/developers/) oldalt. - -- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) -- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [Írja meg az első okosszerződését](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Tanulja meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) - -## Az Ethereum-kliensek használata {#working-with-ethereum-clients} - -Tanulja meg a [Web3J](https://github.com/web3j/web3j) és a Hyperledger Besu, a két vezető Java Ethereum kliens használatát - -- [Csatlakozás Ethereum klienshez Java-val, Eclipse-szel és Web3J-vel](https://kauri.io/article/b9eb647c47a546bc95693acc0be72546/connecting-to-an-ethereum-client-with-java-eclipse-and-web3j) -- [Egy Ethereum számla kezelése Java-val és Web3J-vel](https://kauri.io/article/925d923e12c543da9a0a3e617be963b4/manage-an-ethereum-account-with-java-and-web3j) -- [Generáljon egy Java Wrappert az okosszerződéséből](https://kauri.io/article/84475132317d4d6a84a2c42eb9348e4b/generate-a-java-wrapper-from-your-smart-contract) -- [Kapcsolódás egy Ethereum okosszerződéshez](https://kauri.io/article/14dc434d11ef4ee18bf7d57f079e246e/interacting-with-an-ethereum-smart-contract-in-java) -- [Ethereum okosszerződés események hallgatása](https://kauri.io/article/760f495423db42f988d17b8c145b0874/listening-for-ethereum-smart-contract-events-in-java) -- [Besu (Pantheon), a Java Ethereum kliens használata Linux-szal](https://kauri.io/article/276dd27f1458443295eea58403fd6965/using-pantheon-the-java-ethereum-client-with-linux) -- [Egy Hyperledger Besu (Pantheon) csomópont futtatása Java integrációs teszteken](https://kauri.io/article/7dc3ecc391e54f7b8cbf4e5fa0caf780/running-a-pantheon-node-in-java-integration-tests) -- [Web3j Puska](https://kauri.io/web3j-cheat-sheet-(java-ethereum)/5dfa1ea941ac3d0001ce1d90/c) - -Ismerje meg az [ethers-kt](https://github.com/Kr1ptal/ethers-kt) használatát, ami egy aszinkron, nagy teljesítményű Kotlin könyvtár az EVM-alapú blokkláncokkal való interakcióhoz. JVM és Android platformokat céloz meg. -- [ERC-20 tokenek transzferje](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/abi/TransferERC20.kt) -- [UniswapV2 átváltás eseményfigyeléssel](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/tokenswapwitheventlistening/TokenSwapWithEventListening.kt) -- [ETH / ERC-20 egyenlegkövetés](https://github.com/Kr1ptal/ethers-kt/blob/master/examples/src/main/kotlin/io/ethers/examples/balancetracker/BalanceTracker.kt) - -## Köztes cikkek {#intermediate-articles} - -- [Tárhelykezelés Java alkalmazásokban IPFS-szel](https://kauri.io/article/3e8494f4f56f48c4bb77f1f925c6d926/managing-storage-in-a-java-application-with-ipfs) -- [ERC20 tokenek kezelése Java-ban Web3j-vel](https://kauri.io/article/d13e911bbf624108b1d5718175a5e0a0/manage-erc20-tokens-in-java-with-web3j) -- [Web3j tranzakciókezelők](https://kauri.io/article/4cb780bb4d0846438d11885a25b6d7e7/web3j-transaction-managers) - -## Speciális használati minták {#advanced-use-patterns} - -- [Ethereum használata Java okosszerződés adat cache építésére](https://kauri.io/article/fe81ee9612eb4e5a9ab72790ef24283d/using-eventeum-to-build-a-java-smart-contract-data-cache) - -## Java-projektek és -eszközök {#java-projects-and-tools} - -- [Hyperledger Besu (Pantheon) (Ethereum kliens)](https://docs.pantheon.pegasys.tech/en/stable/) -- [Web3J (könyvtár az Ethereum kliensekkel való interakcióhoz)](https://github.com/web3j/web3j) -- [ethers-kt (aszinkron, nagy teljesítményű Kotlin/Java/Android könyvtár EVM-alapú blokkláncokhoz)](https://github.com/Kr1ptal/ethers-kt) -- [Eventeum (Event Listener)](https://github.com/ConsenSys/eventeum) -- [Mahuta (IPFS Fejlesztői Eszközök)](https://github.com/ConsenSys/mahuta) - -Több anyagra lenne szüksége? Tekintsd meg az [ethereum.org/developers](/developers/) oldalt - -## Java közösségi hozzájárulók {#java-community-contributors} - -- [IO Builders](https://io.builders) -- [Kauri](https://kauri.io) -- [Besu HL chat](https://chat.hyperledger.org/channel/besu) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" deleted file mode 100644 index bca0b0fc20e..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/javascript/index.md" +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Ethereum JavaScript fejlesztőknek -description: Tanuljon meg Ethereumon fejleszteni JavaScript alapú projektek és eszközök használatával. -lang: hu ---- - -A Javascript a legnépszerűbb nyelvek között van az Ethereum ökoszisztémában. Valójában van egy [csapat](https://github.com/ethereumjs), mely célul tűzte ki, hogy a lehető legtöbb Ethereumot vigye be a JavaScriptbe. - -Lehetőség van JavaScriptet írni (vagy valami hasonlót) a [stack összes szintjén](/developers/docs/ethereum-stack/). - -## Interakció az Ethereummal {#interact-with-ethereum} - -### JavaScript API könyvtárak {#javascript-api-libraries} - -Ha JavaScriptet szeretne írni a blokklánc lekérdezéséhez, tranzakció küldéséhez vagy máshoz, akkor ennek a legkézenfekvőbb módja egy [JavaScript API könyvtár](/developers/docs/apis/javascript/) használata. Ezek az API-k lehetővé teszik a fejlesztőknek, hogy interakcióba lépjenek az [Ethereum-hálózat csomópontjaival](/developers/docs/nodes-and-clients/). - -Ezekkel a könyvtárakkal okosszerződésekkel léphet kapcsolatba az Ethereumon, így létre lehet hozni egy dappot, ahol elég csak a JavaScriptet használni már létező okosszerződésekkel történő interakcióhoz. - -**Nézze meg** - -- [Web3.js](https://web3js.readthedocs.io/) -- [Ethers.js](https://docs.ethers.io/) _– tartalmaz egy Ethereum tárca implementációt és más segédprogramokat JavaScriptben és TypeScriptben._ -- [viem](https://viem.sh) – egy TypeScript interfész az Ethereumhoz, amely alacsony szintű, státuszmentes alapokat biztosít az Ethereummal való interakcióhoz. - -### Okosszerződések {#smart-contracts} - -Ha Ön Javascript-fejlesztő, és szeretné megírni saját okosszerződését, akkor érdemes megismerkednie a [Solidity-vel](https://solidity.readthedocs.io). Ez a legnépszerűbb okosszerződésnyelv, és szintaktikailag hasonló a JavaScript-hez, ami miatt könnyebb lehet elsajátítani azt. - -Többet az [okosszerződésekről](/developers/docs/smart-contracts/). - -## Értse meg a protokollt {#understand-the-protocol} - -### Az Ethereum virtuális gép (EVM) {#the-ethereum-virtual-machine} - -Az [Ethereum virtuális géphez](/developers/docs/evm/) létezik egy JavaScript-implementáció is. Támogatja a legfrissebb elágazási (fork) szabályokat. Az elágazási szabályok az EVM-en végzett tervezett frissítésekből adódó szabályok. - -Különböző JavaScript csomagokra oszlik, amelyeket áttekinthet a jobb megértés érdekében: - -- Számlák -- Blokkok -- A blokklánc maga -- Tranzakciók -- És még sok más... - -Ez segít megérteni olyan dolgokat, mint például, „mi a számla adatstruktúrája”. - -Ha inkább el szeretné olvasni a kódot, ez a JavaScript nagyszerű alternatíva lehet a dokumentumaink áttekintéséhez. - -**Nézze meg a kapcsolódó mappát** -[`ethereumjs`](https://github.com/ethereumjs/ethereumjs-vm) - -### Csomópontok és kliensek {#nodes-and-clients} - -Az Ethereumjs kliens aktív fejlesztés alatt áll, így Önnek lehetősége van elmélyedni abban, hogyan működnek az Ethereum-kliensek az Ön által ismert nyelven: JavaScript-ben! - -Korábban egy különálló [`mappában`](https://github.com/ethereumjs/ethereumjs-client) tárolták, de azután beolvadt az EthereumVM monorepóba egy csomagként. - -**Nézze meg a klienst** -[`ethereumjs-client`](https://github.com/ethereumjs/ethereumjs-monorepo/tree/master/packages/client) - -## Egyéb projektek {#other-projects} - -Rengeteg más dolog is zajlik az Ethereum JavaScript világában, mint például: - -- könyvtárak és tárcaeszközök. -- eszközök Ethereum kulcsok generálására, importálására és exportálására. -- a `merkle-patricia-tree` (Merkle Patricia-fa) implementációja – egy adatstruktúra, melyet az Ethereum Sárgakönyv részletez. - -Mélyedjen bele abba, ami a leginkább érdekli a [EthereumJS mappában](https://github.com/ethereumjs) - -## További olvasnivaló {#further-reading} - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" deleted file mode 100644 index 2ac739389b2..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/python/index.md" +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Ethereum Python fejlesztőknek -description: Tanuljon meg Ethereumra fejleszteni Python alapú projektek és eszközök használatával -lang: hu -incomplete: true ---- - -Tanuljon meg Ethereumra fejleszteni Python alapú projektek és eszközök használatával - -Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. - -## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} - -**Tegye meg az első lépést, hogy integrálja a Pythont az Ethereummal** - -Szükséged van egy méginkább kezdőknek szóló alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. - -- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) -- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) - -## Cikkek kezdőknek {#beginner-articles} - -- [Egy (Python) fejlesztői útmutató az Ethereumra](https://snakecharmers.ethereum.org/a-developers-guide-to-ethereum-pt-1/) -- [A Python helyzete a 2023-as blokklánc riportban](https://tradingstrategy.ai/blog/the-state-of-python-in-blockchain-in-2023) -- [Bevezetés az okosszerződésekbe Vyper-rel](https://kauri.io/#collections/Getting%20Started/an-introduction-to-smart-contracts-with-vyper/) -- [Telepítse a saját ERC20-as tokenjét Pythonnal és Brownie-val](https://betterprogramming.pub/python-blockchain-token-deployment-tutorial-create-an-erc20-77a5fd2e1a58) -- [Hogyan kell Ethereum szerződést fejleszteni Python Flask használatával?](https://medium.com/coinmonks/how-to-develop-ethereum-contract-using-python-flask-9758fe65976e) -- [Bevezetés Web3.py-ba · Ethereum Python fejlesztőknek](https://www.dappuniversity.com/articles/web3-py-intro) -- [Hogyan kell egy okosszerződés függvényt meghívni Python és web3.py használatával](https://stackoverflow.com/questions/57580702/how-to-call-a-smart-contract-function-using-python-and-web3-py) - -## Köztes cikkek {#intermediate-articles} - -- [Dapp fejlesztés Python programozóknak](https://levelup.gitconnected.com/dapps-development-for-python-developers-f52b32b54f28) -- [Python Ethereum felület létrehozása: Első rész](https://hackernoon.com/creating-a-python-ethereum-interface-part-1-4d2e47ea0f4d) -- [Ethereum okosszerződések Pythonban: egy átfogó útmutató](https://hackernoon.com/ethereum-smart-contracts-in-python-a-comprehensive-ish-guide-771b03990988) -- [Okosszerződések telepítése Brownie-val és Pythonnal](https://dev.to/patrickalphac/using-brownie-for-to-deploy-smart-contracts-1kkp) -- [NFT-k létrehozása az OpenSea piactérre a Brownie-val](https://www.freecodecamp.org/news/how-to-make-an-nft-and-render-on-opensea-marketplace/) - -## Speciális használati minták {#advanced-use-patterns} - -- [Ethereum okosszerződések fordítása, telepítése és hívása Python használatával](https://yohanes.gultom.id/2018/11/28/compiling-deploying-and-calling-ethereum-smartcontract-using-python/) -- [Solidity okosszerződések elemzése Slitherrel](https://kauri.io/#collections/DevOps/analyze-solidity-smart-contracts-with-slither/#analyze-solidity-smart-contracts-with-slither) -- [Blokklánc pénzügyi technológiai (fintech) útmutató: kölcsönadás és kölcsönvétel Pythonnal](https://blog.chain.link/blockchain-fintech-defi-tutorial-lending-borrowing-python/) - -## Python projektek és eszközök {#python-projects-and-tools} - -### Aktív: {#active} - -- [Web3.py](https://github.com/ethereum/web3.py) – _Python könyvtár az Ethereummal történő interakciókra_ -- [Vyper](https://github.com/ethereum/vyper/) – _Pythonikus okosszerződés nyelv az EVM-re_ -- [Ape](https://github.com/ApeWorX/ape) – _ Az okosszerződés fejlesztői eszköz a pythonisták, adatkutatók és biztonsági szakértők számára._ -- [py-evm](https://github.com/ethereum/py-evm) – _Az Ethereum virtuális gép implementációja_ -- [eth-tester](https://github.com/ethereum/eth-tester) – _Eszközök az Ethereum-alapú alkalmazások teszteléséhez_ -- [eth-utils](https://github.com/ethereum/eth-utils/) - _használati funkciók Ethereumhoz kapcsolódó kódbázisokkal való munkához_ -- [py-solc-x](https://pypi.org/project/py-solc-x/) – _Python wrapper a solc solidity fordító köré 0.5.x támogatással_ -- [pymaker](https://github.com/makerdao/pymaker) – _Python API Maker szerződésekre_ -- [siwe](https://github.com/spruceid/siwe-py) – _Bejelentkezés az Ethereummal (siwe) Pythonra_ -- [Web3 decentralizált pénzügyek (DeFi) Ethereum integrációhoz](https://github.com/tradingstrategy-ai/web3-ethereum-defi) – _Egy Python csomag, mely készen áll az ERC-20, Uniswap és más népszerű projektekkel való integrációra_ -- [Wake](https://getwake.io) - _Minden az egyben Python keretrendszer a szerződéseknek a teszteléshez, fuzzinghoz, telepítéshez, sebezhetőségi vizsgálathoz és kódnavigációhoz (nyelvi szerver - [eszközök a Solidity-hez](https://marketplace.visualstudio.com/items?itemName=AckeeBlockchain.tools-for-solidity))_ - -### Archivált / a karbantartás megszűnt: {#archived--no-longer-maintained} - -- [Trinity](https://github.com/ethereum/trinity) – _Ethereum Python-kliens_ -- [Mamba](https://github.com/arjunaskykok/mamba) – _Keretrendszer Vyper nyelven írt okosszerződések írására, fordítására és telepítésére_ -- [Brownie](https://github.com/eth-brownie/brownie) – _Python keretrendszer Ethereum okosszerződések telepítésére, tesztelésére és alkalmazására_ -- [pydevp2p](https://github.com/ethereum/pydevp2p) – _Az Ethereum P2P stack implementációja_ -- [py-wasm](https://github.com/ethereum/py-wasm) – _A web assembly interpreter Python-implementációja_ - -Még több anyagot keresel? Tekintse meg az [ethereum.org/developers](/developers/) oldalt. - -## Python-eszközöket használó projektek {#projects-using-python-tooling} - -A következő Ethereum-alapú projektek a fent említett eszközöket használják. A kapcsolódó mappák jó referenciaként szolgálnak például a kódok és a bevált gyakorlatok tekintetében. - -- [Yearn Finance](https://yearn.finance/) és [Yearn Vault Contracts mappa](https://github.com/yearn/yearn-vaults) -- [Curve](https://curve.fi/) és [Curve okosszerződések mappa](https://github.com/curvefi/curve-contract) -- [BadgerDAO](https://badger.com/) és [Brownie eszközkészletet használó okosszerződések](https://github.com/Badger-Finance/badger-system) -- [Sushi](https://sushi.com/) [Pythont használ arra, hogy a megbízási szerződéseket kezelje és telepítse](https://github.com/sushiswap/sushi-vesting-protocols) -- [Alpha Finance](https://alphafinance.io/), amelyet az Alpha Homora révén ismerünk, [Brownie-t használ, hogy az okosszerződéseket tesztelje és telepítse](https://github.com/AlphaFinanceLab/alpha-staking-contract) - -## Python közösségi egyeztetések {#python-community-contributors} - -- [Ethereum Python közösségi Discord csatorna](https://discord.gg/9zk7snTfWe) a Web3.py és más Python keretrendszerhez kapcsolódó beszélgetésekhez -- [Vyper Discord](https://discord.gg/SdvKC79cJk) a Vyper okosszerződés programozással kapcsolatos beszélgetésekre - -## Egyéb összesített listák {#other-aggregated-lists} - -A Vyper wiki egy [rendkívüli listát tartalmaz a Vyper-forrásokról](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources). \ No newline at end of file diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" deleted file mode 100644 index 2cacd55e59f..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/ruby/index.md" +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Ethereum Ruby-fejlesztők számára -description: Tanuljon meg Ethereumra fejleszteni Ruby-alapú projektek és eszközök használatával. -lang: hu -incomplete: false ---- - -Tanuljon meg Ethereumra fejleszteni Ruby-alapú projektek és eszközök használatával. - -Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok nem igényelnek bizalmat a felhasználó oldaláról, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel az újfajta pénzügyi alkalmazások számra. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. - -## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} - -**Tegye meg az első lépést a Ruby Ethereumra való integrálásához** - -Szükséged van egy méginkább kezdőknek szóló alapozóra? Tekintsd meg az [ethereum.org/learn](/learn/) oldalt vagy az [ethereum.org/developers](/developers/) oldalt. - -- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) -- [Okos Szerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) - -## Cikkek kezdőknek {#beginner-articles} - -- [Az Ethereum-számlák megértése](https://dev.to/q9/finally-understanding-ethereum-accounts-1kpe) -- [Rails-felhasználók hitelesítése a MetaMask használatával](https://dev.to/q9/finally-authenticating-rails-users-with-metamask-3fj) -- [Bejelentkezés az Ethereummal – Ruby-könyvtár és Rails-példák kiadása](https://blog.spruceid.com/sign-in-with-ethereum-ruby-library-release-and-rails-examples/) -- [Hogyan lehet az Ethereum-hálózathoz kapcsolódni a Ruby-val](https://www.quicknode.com/guides/web3-sdks/how-to-connect-to-the-ethereum-network-using-ruby) -- [Hogyan lehet új Ethereum-címet létrehozni a Ruby-val](https://www.quicknode.com/guides/web3-sdks/how-to-generate-a-new-ethereum-address-in-ruby) - -## Köztes cikkek {#intermediate-articles} - -- [Blokkláncalkalmazás a Ruby-val](https://www.nopio.com/blog/blockchain-app-ruby/) -- [A Ruby használata az Ethereumon az okosszerződés végrehajtására](https://titanwolf.org/Network/Articles/Article?AID=87285822-9b25-49d5-ba2a-7ad95fff7ef9) - -## Ruby-projektek és -eszközök {#ruby-projects-and-tools} - -### Aktív {#active} - -- [eth.rb](https://github.com/q9f/eth.rb) – _Ruby könyvtár és RPC-kliens az Ethereum-számlák, üzenetek és tranzakciók kezelésére_ -- [keccak.rb](https://github.com/q9f/keccak.rb) – _Az Ethereum által használt keccak (SHA3) hash_ -- [siwe-ruby](https://github.com/spruceid/siwe-ruby) – _Ruby általi implementáció az Ethereummal való bejelentkezéshez_ -- [siwe_rails](https://github.com/spruceid/siwe_rails) – _SIWE lokális bejelentkezési utakat adó Rails gem_ -- [siwe-rails-examples](https://github.com/spruceid/siwe-rails-examples) – _SIWE-példa Ruby használatával a Railsen személyre szabott irányítóval_ -- [omniauth-siwe](https://github.com/spruceid/omniauth-siwe) – _OmniAuth-stratégia az Ethereummal (SIWE) való bejelentkezéshez_ -- [omniauth-nft](https://github.com/valthon/omniauth-nft) – _OmniAuth stratégia az NFT tulajdonjogon keresztüli hitelesítésre_ -- [ethereum-on-rails](https://github.com/q9f/ethereum-on-rails) – _Ethereum a Rails-en sablon, mellyel a MetaMaskot a Ruby-hoz lehet kapcsolni a Rails-en_ - -### Archivált / a karbantartás megszűnt {#archived--no-longer-maintained} - -- [web3-eth](https://github.com/spikewilliams/vtada-ethereum) – _Az Ethereum-csomópontok RPC metódusainak meghívása Ruby-val_ -- [ethereum_tree](https://github.com/longhoangwkm/ethereum_tree) – _Ruby könyvtár az ETH-címek létrehozására egy hierarchikusan determinált tárcából a BIP32 szabvány szerint_ -- [etherlite](https://github.com/budacom/etherlite) – _Ethereum integráció Ruby-ra a Rails-en_ -- [ethereum.rb](https://github.com/EthWorks/ethereum.rb) – _Ruby Ethereum-kliens, amely JSON-RPC interfészt használ a tranzakciók küldésére, a szerződések létrehozására és az azokkal való interakcióra, valamint hasznos eszközkészlet az Ethereum-csomópontokkal való együttműködéshez_ -- [omniauth-ethereum.rb](https://github.com/q9f/omniauth-ethereum.rb) – _Az Ethereum-szolgáltatóstratégia bevezetése az OmniAuth-ra_ - -Még több anyagot keresel? Tekintse meg [Fejlesztőink](/developers/) oldalait. - -## Ruby közösségi hozzájárulók {#ruby-community-contributors} - -Az [Ethereum Ruby Telegram csoport](https://t.me/ruby_eth) egy gyorsan növekvő közösség szervezője, egy dedikált erőforrás a fenti projektek és kapcsolódó témák megvitatására. diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" deleted file mode 100644 index e2402118a6d..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/programming-languages/rust/index.md" +++ /dev/null @@ -1,63 +0,0 @@ ---- -title: Ethereum Rust-fejlesztők számára -description: Tanuljon meg Ethereumra fejleszteni Rust alapú projektek és eszközök használatával -lang: hu -incomplete: true ---- - -Tanuljon meg Ethereumra fejleszteni Rust alapú projektek és eszközök használatával - -Használj Ethereumot decentralizált alkalmazások (avagy "dappok") fejlesztésére, melyek kihasználják a kriptovaluta és a blokklánc technológia nyújtotta előnyöket. Ezek a dappok megbízhatóak, ami azt jelenti, hogyha egyszer telepítették az Ethereumba, akkor mindig úgy fognak futni, ahogy programozták őket. Digitális vagyontárgyakat irányíthatnak, lehetőséget teremtve ezzel újfajta pénzügyi alkalmazások létrejöveteléhez. Decentralizáltak lehetnek, mely azt jelenti, hogy semmilyen entitás vagy személy nem irányítja őket és közel lehetetlen őket cenzúrázni. - -## Kezdő lépések az okosszerződésekkel és a Solidity nyelvvel {#getting-started-with-smart-contracts-and-solidity} - -**Tegye meg az első lépést, hogy integrálja a Rust-ot az Ethereummal** - -Szükséged van egy méginkább kezdőknek szóló alapozóra? Tekintse meg az [ethereum.org/learn](/learn/) vagy az [ethereum.org/developers](/developers/) oldalt. - -- [Blokklánc ismertetése](https://kauri.io/article/d55684513211466da7f8cc03987607d5/blockchain-explained) -- [Okosszerződések értelmezése](https://kauri.io/article/e4f66c6079e74a4a9b532148d3158188/ethereum-101-part-5-the-smart-contract) -- [Írd meg az első Okosszerződésed](https://kauri.io/article/124b7db1d0cf4f47b414f8b13c9d66e2/remix-ide-your-first-smart-contract) -- [Tanuld meg a Solidity fordítását és telepítését](https://kauri.io/article/973c5f54c4434bb1b0160cff8c695369/understanding-smart-contract-compilation-and-deployment) - -## Cikkek kezdőknek {#beginner-articles} - -- [A Rust Ethereum-kliens](https://openethereum.github.io/) \* **Felhívjuk figyelmét, hogy az OpenEthereum [támogatása megszűnt](https://medium.com/openethereum/gnosis-joins-erigon-formerly-turbo-geth-to-release-next-gen-ethereum-client-c6708dd06dd), karbantartása nem biztosított.** Használja körültekintően, és inkább térjen át másik kliensimplementációra. -- [Tranzakció küldése Ethereumra Rust használatával](https://kauri.io/#collections/A%20Hackathon%20Survival%20Guide/sending-ethereum-transactions-with-rust/) -- [Részletes útmutató arról, hogyan lehet szerződéseket írni Rust Wasm nyelven Kovanra](https://github.com/paritytech/pwasm-tutorial) - -## Köztes cikkek {#intermediate-articles} - -## Speciális használati minták {#advanced-use-patterns} - -- [pwasm_ethereum externs könyvtár Ethereum-szerű hálózatokkal való interakciókhoz](https://github.com/openethereum/pwasm-ethereum) -- [Építsen egy decentralizált csevegőprogramot JavaScript és Rust használatával](https://medium.com/perlin-network/build-a-decentralized-chat-using-javascript-rust-webassembly-c775f8484b52) -- [Építsen egy decentralizált teendők listája alkalmazást Vue.js-szel & Rust-tal](https://medium.com/@jjmace01/build-a-decentralized-todo-app-using-vue-js-rust-webassembly-5381a1895beb) - -- [Blokklánc építése Rust nyelven](https://blog.logrocket.com/how-to-build-a-blockchain-in-rust/) - -## Rust-projektek és -eszközök {#rust-projects-and-tools} - -- [pwasm-ethereum](https://github.com/paritytech/pwasm-ethereum) – _Külső elemek gyűjteménye az Ethereum-szerű hálózattal való interakcióhoz_ -- [Lighthouse](https://github.com/sigp/lighthouse) – _Gyors Ethereum-konszenzusrétegkliens_ -- [Ethereum WebAssembly](https://ewasm.readthedocs.io/en/mkdocs/) – _Az Ethereum okosszerződés végrehajtási rétegének javasolt újratervezése a WebAssembly egy determinisztikus részét használva_ -- [oasis_std](https://docs.rs/oasis-std/latest/oasis_std/index.html) - _OASIS API referencia_ -- [Solaris](https://github.com/paritytech/sol-rs) – _Solidity okosszerződések egységtesztelésének irányítása a natív Parity kliens EVM használatával._ -- [SputnikVM](https://github.com/rust-blockchain/evm) – _Rust Ethereum virtuálisgép-implementáció_ -- [Wavelet](https://wavelet.perlin.net/docs/smart-contracts) – _Wavelet okosszerződés Rust-ban_ -- [Foundry](https://github.com/foundry-rs/foundry) – _Eszközkészlet az Ethereum-alkalmazások fejlesztéséhez_ -- [Alloy](https://alloy.rs) - _Magas teljesítményű, alaposan tesztelt és dokumentált könyvtárak az Ethereummal és más EVM-alapú lánccal való interakcióhoz._ -- [Ethers_rs](https://github.com/gakonst/ethers-rs) – _Ethereum könyvtár- és tárcaimplementáció_ -- [SewUp](https://github.com/second-state/SewUp) – _Egy könyvtár, amely segít az Ethereum webassembly szerződés Rust-ban való megépítésében, mintha egy általános backend lenne_ -- [Substreams](https://github.com/streamingfast/substreams) – _Párhuzamos blokkláncadat-indexálási technológia_ -- [Reth](https://github.com/paradigmxyz/reth) A Reth (Rust Ethereum rövidítése) egy új teljescsomópont-implementáció az Ethereumon -- [Awesome Ethereum Rust](https://github.com/Vid201/awesome-ethereum-rust) – _Az Ethereum ökoszisztéma Rust nyelven írt projektjeinek gyűjteménye_ - -Még több anyagot keresel? Tekintse meg az [ethereum.org/developers](/developers/) oldalt. - -## Rust közösségi hozzájárulók {#rust-community-contributors} - -- [Ethereum WebAssembly](https://gitter.im/ewasm/Lobby) -- [Oasis Gitter](https://gitter.im/Oasis-official/Lobby) -- [Parity Gitter](https://gitter.im/paritytech/parity) -- [Enigma](https://discord.gg/SJK32GY) diff --git "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" "b/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" deleted file mode 100644 index 3baa100807c..00000000000 --- "a/public/content/translations/hu/18) Docs \342\200\223 Tech Stack Pages/developers/docs/storage/index.md" +++ /dev/null @@ -1,216 +0,0 @@ ---- -title: Decentralizált tárhely -description: Áttekintés a decentralizált tárhelyről és az elérhető eszközökről, amellyekkel integrálhatóak a dappokba. -lang: hu ---- - -A központilag elhelyezett, egyetlen vállalat vagy szervezet által működtetett szerverrel szemben a decentralizált tárolórendszerek a felhasználói operátorok peer-to-peer hálózatából állnak, akik az összes adat egy részét tárolják egy rugalmas fájltárolási és -megosztási rendszert létrehozva. Ezek lehetnek blokklánc-alapú alkalmazásokban vagy bármilyen, közvetítő nélküli hálózatokban. - -Magát az Ethereumot is lehet decentralizált tárolórendszerként használni, és úgy is működik, amikor az okosszerződések kódjait kell tárolni. Ugyanakkor az Ethereumot nem arra tervezték, hogy nagy adathalmazokat tároljon. A lánc stabilan növekszik, a jelen írás idején az Ethereum lánc kb. 500 GB – 1TB méretű ([a klienstől függően](https://etherscan.io/chartsync/chaindefault)), és a hálózat minden csomópontjának tárolnia kell ezt az adatmennyiséget. Ha a lánc nagy adatmennyiségre növekedne meg (mondjuk 5 TB méretre), akkor már nem minden csomópont tudna működni. Ezen túl ennyi adat bevitele a főhálózatra is ellehetetlenítő módon drága lenne a [gázdíjak](/developers/docs/gas) miatt. - -Ezen megszorítások miatt egy másik láncra vagy módszerre van szükség, hogy az adatok nagy tömegét decentralizált módon tároljuk. - -Amikor decentralizált tárhely (dStorage) opcióról beszélünk, akkor a felhasználónak néhány dolgot fontos figyelembe vennie. - -- Megtartási mechanizmus / ösztönzési struktúra -- Adatmegtartás kényszere -- Decentralitás -- Konszenzus - -## Megtartási mechanizmus / ösztönzési struktúra {#persistence-mechanism} - -### Blokkláncalapú {#blockchain-based} - -Ahhoz, hogy egy adat örökké létezzen, valamilyen megtartási mechanizmusra van szükség. Például az Ethereumon az a megtartási mechanizmus, hogy a csomópont futtatásánál az egész láncra szükség van. Az új adat a lánchoz kerül, és így az folyamatosan növekszik – az összes csomópontnak replikálnia kell az összes beágyazott adatot. - -Ezt úgy nevezik, hogy **blokkláncalapú** megtartás. - -A blokkláncalapú megtartással az a gond, hogy a lánc túl nagyra nőket, hogy fenntartsa és tárolja az összes adatot (például [számos forrás](https://healthit.com.au/how-big-is-the-internet-and-how-do-we-measure-it/) úgy becsli, hogy az Internet több mint 40 zettabájt tárhelyet igényel). - -A blokkláncnak emellett valamilyen ösztönzési struktúrát kell alkalmaznia. A blokkláncalapú megtartáshoz a validátorok fizetséget kapnak. Amikor az adat hozzákerül a lánchoz, a validátorok jutalmat kapnak a bekerülés intézéséért. - -Blokkláncalapú megtartással működő platformok: - -- Ethereum -- [Arweave](https://www.arweave.org/) - -### Szerződésalapú {#contract-based} - -A **szerződésalapú** megtartás úgy véli, hogy az adatot nem replikálhatja és tárolhatja örökké minden csomópont, ehelyett inkább szerződéses megállapodással kell azt fenntartani. Ezeket a megállapodásokat számos csomóponttal kötik, amelyek megígérik, hogy egy adott időszakra megtartják az adatot. Ezt vissza kell fizetni vagy meg kell újítani, amikor már nem tartják meg az adatot. - -A legtöbb esetben nem az adatot tárolják a láncon, hanem azt a hasht, ami az adat tárolási helyét mutatja. Így a teljes láncot nem kell skálázni, hogy minden adat elférjen. - -Szerződésalapú megtartással működő platformok: - -- [Filecoin](https://docs.filecoin.io/about-filecoin/what-is-filecoin/) -- [Skynet](https://siasky.net/) -- [Storj](https://storj.io/) -- [Züs](https://zus.network/) -- [Crust Network](https://crust.network) -- [Swarm](https://www.ethswarm.org/) -- [4EVERLAND](https://www.4everland.org/) - -### További megfontolások {#additional-consideration} - -Az IPFS (InterPlanetary File System) egy elosztott rendszer fájlok, honlapok, alkalmazások és adatok tárolására és elérésére. Nincs beépített ösztönzési sémája, de használható bármelyik szerződésalapú ösztönzési megoldással a hosszú távú megtartásért. Egy másik módja annak, hogy az IPFS-en megmaradjon az adat, az az odatűzési (pinning) szolgáltatás, mely rögzíti az Önnek fontos adatokat, hogy Ön elérje azokat. Ön is futtathat saját IPFS csomópontot és hozzájárulhat a hálózathoz, hogy fenntartja a saját és más adatait ingyen! - -- [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/) -- [Pinata](https://www.pinata.cloud/) _(IPFS pinning service)_ -- [web3.storage](https://web3.storage/) _(IPFS/Filecoin pinning service)_ -- [Infura](https://infura.io/product/ipfs) _(IPFS pinning service)_ -- [IPFS Scan](https://ipfs-scan.io) _(IPFS pinning explorer)_ -- [4EVERLAND](https://www.4everland.org/)_（IPFS pinning service）_ -- [Filebase](https://filebase.com) _(IPFS Pinning Service)_ -- [Spheron Network](https://spheron.network/) _(IPFS/Filecoin pinning szolgáltatás)_ - -A SWARM egy decentralizáld adattárhely és elosztási technológia, mely tárolási ösztönzőrendszerrel és egy tárhelybérleti-költséges orákulummal működik. - -## Adatmegőrzés {#data-retention} - -Az adat megtartásához a rendszereknek valamilyen mechanizmusra van szükségük, hogy ezt biztosítsák. - -### Kihívásalapú mechanizmus {#challenge-mechanism} - -Az egyik legnépszerűbb módszer az adatmegtartásra, hogy valamilyen kriptográfiai kihívást használnak, amelyet a csomópontokhoz küldenek annak ellenőrzésére, hogy azok tényleg rendelkeznek-e az adattal. Egy egyszerű példa az Arweave hozzáférés-bizonyítása. Egy kihívást küldenek a csomópontoknak, hogy azoknál megvan-e a legutóbbi blokk és egy tetszőleges korábbi blokk. Ha a csomópont nem tud válaszolni, akkor megbüntetik. - -A kihívásmechanizmussal rendelkező decentralizált tárhelyek típusai: - -- Züs -- Skynet -- Arweave -- Filecoin -- Crust Network -- 4EVERLAND - -### Decentralitás {#decentrality} - -A platformok decentralitását nem lehet könnyen mérni, de általában olyan eszközt válasszon, amelyik nem valamilyen KYC-féle (ismerje meg ügyfelét) dolgot használ arra, hogy bizonyítékot adjon a decentralitásáról. - -Decentralizált eszközök KYC nélkül: - -- Skynet -- Arweave -- Filecoin -- IPFS -- Ethereum -- Crust Network -- 4EVERLAND - -### Konszenzus {#consensus} - -A legtöbb eszköz rendelkezik valamilyen [konszenzusmechanizmussal](/developers/docs/consensus-mechanisms/), általában [**proof-of-work (PoW)**](/developers/docs/consensus-mechanisms/pow/) vagy [**proof-of-stake (PoS)** mechanizmust használnak](/developers/docs/consensus-mechanisms/pos/). - -Proof-of-work-alapú: - -- Skynet -- Arweave - -Proof-of-stake-alapú: - -- Ethereum -- Filecoin -- Züs -- Crust Network - -## Kapcsolódó eszközök {#related-tools} - -**IPFS – _InterPlanetary File System egy decentralizált tárhely és fájlreferencia-rendszer Ethereumra._** - -- [Ipfs.io](https://ipfs.io/) -- [Dokumentáció](https://docs.ipfs.io/) -- [GitHub](https://github.com/ipfs/ipfs) - -**Storj DCS – _Biztonságos, privát és S3-kompatibilis, decentralizált felhőobjektum-tárhely fejlesztőknek._** - -- [Storj.io](https://storj.io/) -- [Dokumentáció](https://docs.storj.io/) -- [GitHub](https://github.com/storj/storj) - -**Skynet – _A Skynet egy decentralizált PoW lánc, ami a decentralizált web felé elkötelezett._** - -- [Skynet.net](https://siasky.net/) -- [Dokumentáció](https://siasky.net/docs/) -- [GitHub](https://github.com/SkynetLabs/) - -**Filecoin – _Filecoint az IPFS mögötti csapat hozta létre. Ez egy ösztönzőréteg az IPFS ideálok tetején._** - -- [Filecoin.io](https://filecoin.io/) -- [Dokumentáció](https://docs.filecoin.io/) -- [GitHub](https://github.com/filecoin-project/) - -**Arweave – _Az Arweave egy dStorage platform adattárolásra._** - -- [Arweave.org](https://www.arweave.org/) -- [Dokumentáció](https://docs.arweave.org/info/) -- [Arweave](https://github.com/ArweaveTeam/arweave/) - -**Züs – _A Züs egy proof-of-stake dStorage platform shardinggal és blobberekkel._** - -- [zus.network](https://zus.network/) -- [Dokumentáció](https://0chaindocs.gitbook.io/zus-docs) -- [GitHub](https://github.com/0chain/) - -**Crust Network – _Crust egy dStorage platform az IPFS tetején._** - -- [Crust.network](https://crust.network) -- [Dokumentáció](https://wiki.crust.network) -- [GitHub](https://github.com/crustio) - -**Swarm – _Egy elosztott tárhely platform és tartalom elosztó szolgáltatás az Ethereum web3-stackhez._** - -- [EthSwarm.org](https://www.ethswarm.org/) -- [Dokumentáció](https://docs.ethswarm.org/docs/) -- [GitHub](https://github.com/ethersphere/) - -**OrbitDB – _Egy decentralizált peer-to-peer adatbázis az IPFS tetején._** - -- [OrbitDB.org](https://orbitdb.org/) -- [Dokumentáció](https://github.com/orbitdb/field-manual/) -- [GitHub](https://github.com/orbitdb/orbit-db/) - -**Aleph.im – _Decentralizált felhőprojekt (adatbázis, fájltárolás, számítás és DID). A láncon kívüli és belüli, közvetítőmentes (peer-to-peer) technológia egyedi keveréke. IPFS-sel és többféle lánccal kompatibilis._** - -- [Aleph.im](https://aleph.im/) -- [Dokumentáció](https://aleph.im/#/developers/) -- [GitHub](https://github.com/aleph-im/) - -**Ceramic – _Felhasználó által kontrollált IPFS-adatbázis az adatgazdag alkalmazásokért._** - -- [Ceramic.network](https://ceramic.network/) -- [Dokumentáció](https://developers.ceramic.network/learn/welcome/) -- [GitHub](https://github.com/ceramicnetwork/js-ceramic/) - -**Filebase – _S3-kompatibilis decentralizált tárhely és georedundáns IPFS pinning szolgáltatás. Az IPFS-re a Filebase-en keresztül feltöltött összes fájlt automatikusan hozzátűzi a Filebase infrastruktúrához 3-szoros replikációval világszerte._** - -- [Filebase.com](https://filebase.com/) -- [Dokumentáció](https://docs.filebase.com/) -- [GitHub](https://github.com/filebase) - -**4EVERLAND – _Egy Web 3.0 felhőszámítási platform, ami integrálja a tárolás, számítás és hálózatépítés lényegi képességeit, S3-kompatibilis és szinkron adattárolást kínál olyan decentralizált tárolóhálózatokon, mint amilyen az IPFS és az Arweave._** - -- [4everland.org](https://www.4everland.org/) -- [Dokumentáció](https://docs.4everland.org/) -- [GitHub](https://github.com/4everland) - -**Kaleido – _Egy blokklánc mint szolgáltatás platform gombnyomásos IPFS csomópontokkal_** - -- [Kaleido](https://kaleido.io/) -- [Dokumentáció](https://docs.kaleido.io/kaleido-services/ipfs/) -- [GitHub](https://github.com/kaleido-io) - -**Spheron Network - _A Spheron egy platform mint szolgáltatás (PaaS), amelyet olyan dappok számára terveztek, amelyek jó teljesítményű decentralizált infrastruktúrán szeretnék elindítani alkalmazásaikat. Számítási kapacitást, decentralizált tárolást, CDN & web hosting szolgáltatás kínál._** - -- [spheron.network](https://spheron.network/) -- [Dokumentáció](https://docs.spheron.network/) -- [GitHub](https://github.com/spheronFdn) - -## További olvasnivaló {#further-reading} - -- [Mi az a decentralizált tárhely?](https://coinmarketcap.com/alexandria/article/what-is-decentralized-storage-a-deep-dive-by-filecoin) – _CoinMarketCap_ -- [Öt gyakori mítosz lerombolása a decentralizált tárhelyről](https://www.storj.io/blog/busting-five-common-myths-about-decentralized-storage) – _Storj_ - -_Ismer olyan közösségi információforrást, amely a hasznára vált? Módosítsa az oldalt, és adja hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) diff --git a/public/content/translations/hu/19) Learn Pages 2/glossary/index.md b/public/content/translations/hu/19) Learn Pages 2/glossary/index.md deleted file mode 100644 index fc0d796c447..00000000000 --- a/public/content/translations/hu/19) Learn Pages 2/glossary/index.md +++ /dev/null @@ -1,499 +0,0 @@ ---- -title: Ethereum szótár -description: Szójegyzék az Ethereumhoz kapcsolódó technikai és nem technikai szavakról, a teljesség igénye nélkül -lang: hu ---- - -# Szójegyzék {#ethereum-glossary} - -## \# {#section-numbers} - - - - - -## A {#section-a} - - - - - - - - - - - - - - - - - - - - - -## B {#section-b} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -## C {#section-c} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -## D {#section-d} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -## E {#section-e} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -## F {#section-f} - - - - - - - - - - - - - - - - - - - -## G {#section-g} - - - - - - - - - - - - - - - -## H {#section-h} - - - - - - - - - - - - - -## I {#section-i} - - - - - - - - - - - - - -## K {#section-k} - - - - - - - - - - - -## L {#section-l} - - - - - - - - - - - - - - - - - -## M {#section-m} - - - - - - - - - - - - - - - - - - - - - - - - - -## N {#section-n} - - - - - - - - - - - - - -## O {#section-o} - - - - - - - - - - - - - -## P {#section-p} - - - - - - - - - - - - - - - - - - - - - - - - - - - -## R {#section-r} - - - - - - - - - - - - - - - -## S {#section-s} - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -## T {#section-t} - - - - - - - - - - - - - - - - - - - -## V {#section-v} - - - - - - - - - - - - - -## W {#section-w} - - - - - - - - - -## Z {#section-z} - - - - - - - - - -## Források {#sources} - -_Részben [Andreas M. Antonopoulos és Gavin Wood](https://ethereumbook.info) [Mastering Ethereum](https://github.com/ethereumbook/ethereumbook) műve alapján lett létrehozva, a CC-BY-SA licence keretében_ - - - -## Járuljon hozzá az oldalhoz {#contribute-to-this-page} - -Kihagytunk valamit? Valami nem helyes? Segítsen nekünk jobbá tenni úgy, hogy közreműködik a szójegyzék fejlesztésében a GitHubon! - -[Tudjon meg többet a közreműködésről](/contributing/adding-glossary-terms) diff --git a/public/content/translations/hu/19) Learn Pages 2/history/index.md b/public/content/translations/hu/19) Learn Pages 2/history/index.md deleted file mode 100644 index 4d80eed3846..00000000000 --- a/public/content/translations/hu/19) Learn Pages 2/history/index.md +++ /dev/null @@ -1,623 +0,0 @@ ---- -title: Az Ethereum története és elágazásai -description: Az Ethereum blokklánc története a nagyobb mérföldkövekkel, frissítésekkel és elágazásokkal. -lang: hu -sidebarDepth: 1 ---- - -# Az Ethereum története {#the-history-of-ethereum} - -Az Ethereum blokklánc összes fontos mérföldkövének, elágazásának és frissítésének idővonala. - - - -Az elágazások a hálózat nagyobb technikai frissítései vagy változtatásai esetében jönnek létre – általában az Ethereum-fejlesztési javaslatokból (EIP) származnak és megváltoztatják a protokoll „szabályait”. - -Amikor a hagyományos, központi irányítású szoftverek esetében szükséges egy frissítés, a cég csak kibocsájt egy új verziót a végfelhasználó részére. A blokkláncok máshogy működnek, mivel nincsen központi tulajdonjog. Az Ethereum-klienseknek frissíteni kell a szoftverjét, hogy az új elágazási szabályokat életbe léptessék. Ezenkívül a blokklétrehozóknak (bányászok egy proof-of-work rendszerben, validátorok egy proof-of-stake rendszerben) és a csomópontoknak blokkokat kell létrehozniuk és az új szabályokkal szembemenően kell validálniuk. Bővebben a konszenzusmechanizmusokról - -Ezek a szabályváltozások létrehozhatnak egy átmeneti szétválást a hálózatban. Új blokkok jöhetnek létre az új szabályok vagy a régiek szerint. Az elágazásokról általában előzetes egyezség születik, így a kliensek együttesen vezetik be a változtatásokat és a változásokkal rendelkező elágazás válik a fő lánccá. Azonban néha előfordul nézeteltérés az elágazásokat illetően, mely a lánc megmaradó kettészakadását eredményezi – a legismertebb ilyen eset az Ethereum Classic létrejötte volt a DAO elágazással. - - - - - -Az Ethereum alapját képező szoftver két részből áll, ezek a [végrehajtási réteg](/glossary/#execution-layer) és a [consensus layer](/glossary/#consensus-layer). - -**Végrehajtási frissítés elnevezése** - -2021 óta a **végrehajtási rétegre** történő frissítéseket a [korábbi Devcon-helyek] (https://devcon.org/en/past-events/) városnevei szerint nevezik el, időrendi sorrendben: - -| Frissítés neve | Devcon év | Devcon szám | Frissítés dátuma | -| ------------ | ----------- | ------------- | ------------ | -| Berlin | 2015 | 0 | 2021. április 15. | -| London | 2016 | I | 2021. augusztus 5. | -| Shanghai | 2017 | II | 2023. április 12. | -| **Cancun** | 2018 | III | 2024. március 13. | -| _Prága_ | 2019 | IV | TBD | -| _Oszaka_ | 2020 | V | TBD | -| _Bogota_ | 2022 | VI | TBD | -| _Bangkok_ | 2024 | VII | TBD | - -**Konszenzusos frissítés elnevezése** - -A [Beacon Chain](/glossary/#beacon-chain) elindítása óta a **konszenzus réteg** frissítéseit az égi csillagokról nevezték el, amelyek betűkkel kezdődnek, amelyek ábécé sorrendben haladnak: - -| Frissítés neve | Frissítés dátuma | -| -------------------------------------------------- --------- | ------------ | -| Beacon Chain genesis | 2020. december 1. | -| [Altair](https://en.wikipedia.org/wiki/Altair) | 2021. október 27. | -| [Bellatrix](https://en.wikipedia.org/wiki/Bellatrix) | 2022. szeptember 6. | -| [Capella](https://en.wikipedia.org/wiki/Capella) | 2023. április 12. | -| [**Deneb**](https://en.wikipedia.org/wiki/Deneb) | 2024. március 13. | -| [_Electra_]() | TBD | - -**Kombinált elnevezés** - -A végrehajtás és a konszenzusos frissítések kezdetben különböző időpontokban kerültek bevezetésre, de a [The Merge](/roadmap/merge/) 2022-es verzióját követően ezeket egyidejűleg telepítették. Így a köznyelvi kifejezések azért jelentek meg, hogy leegyszerűsítsék az ezekre a frissítésekre való hivatkozásokat egyetlen összevont kifejezés használatával. Ez a _Shanghai-Capella_ frissítéssel kezdődött, amelyet általában "**Shapella**-ként emlegetnek", és folytatódik a _Cancun-Deneb_ frissítéssel, amelyre "**Dencun**-ként" hivatkozhatunk. - -| Végrehajtás frissítése | Konszenzus frissítése | Rövid név | -| ------------------ | ------------------ | ---------- | -| Shanghai | Capella | „Shapella” | -| Cancun | Deneb | „Dencun” | - - - -Akár egy lépéssel is elnavigálhat néhány rendkívül fontos frissítéshez: [A Beacon lánc](/roadmap/beacon-chain/); [A Beolvadás](/roadmap/merge/); és [EIP-1559](#london) - -A jövőbeli protokollfrissítések érdeklik? [Tudjon meg többet a következő frissítésekről az Ethereum ütemtervéből](/roadmap/). - - - -## 2024 {#2024} - -### Cancun-Deneb („Dencun”) {#dencun} - - - -#### Cancun összefoglalója {#cancun-summary} - -A Cancun frissítés az Ethereum _végrehajtásának_ javítását tartalmazza, amelynek célja a skálázhatóság fejlesztése, párhuzamosan a Deneb konszenzusfrissítésekkel. - -Ide tartozik az EIP-4844, az úgynevezett **Proto-Danksharding**, amely jelentősen csökkenti a második blokkláncréteg (L2) rollupok adattárolási költségeit. Ezt az adatblobok bevezetésével érik el, amely lehetővé teszi, hogy az összevont tranzakcióok az adatokat csak rövid ideig tárolják a főhálózaton. Ez jelentősen alacsonyabb tranzakciós díjakat eredményez az L2 rollupok felhasználói számára. - - - -
    -
  • EIP-1153 - Átmeneti tárolási opkódok
    • -
  • EIP-4788 - Beaconblokk-gyökér az EVM-ben
    • -
  • EIP-4844 - Shard blob tranzakciók (Proto-Danksharding)
    • -
  • EIP-5656 - MCOPY - Memóriamásolási instrukció
    • -
  • EIP-6780 - SELFDESTRUCT (önmegsemmisítés) csak ugyanabban a tranzakcióban
    • -
  • EIP-7516 - BLOBBASEFEE opkód
    • -
- - - -- [Második blokkláncréteg (L2) rollup-ok](/layer-2/) -- [Proto-Danksharding](/roadmap/scaling/#proto-danksharding) -- [Dank-féle párhuzamos futtatás (Danksharding)](/roadmap/danksharding/) -- [Olvassa el a Cancun frissítés specifikációit](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/cancun.md) - -#### Deneb összefoglaló {#deneb-summary} - -A Deneb frissítés az Ethereum _konszenzusának_ javítását tartalmazza, amelynek célja a skálázhatóság fejlesztése. Ez a frissítés a Cancun végrehajtási frissítésekkel párhuzamosan történik a Proto-Danksharding (EIP-4844) engedélyezéséhez, valamint a Beacon Chain egyéb fejlesztéseihez. - -Az előre generált, aláírt „önkéntes kilépési üzenetek” többé nem járnak le, így a felhasználók nagyobb kontrollt kapnak a csomópont-üzemeltetőknél elhelyezett pénzeszközeik felett. Ezzel az aláírt kilépési üzenettel a letétbe helyezők delegálhatják a csomópont működését, miközben továbbra is képesek biztonságosan kilépni és bármikor kivenni a pénzüket anélkül, hogy bárkitől engedélyt kellene kérniük. - -Az EIP-7514 szigorítja az ETH-kibocsátást azáltal, hogy maximálja a validátorok becsatlakozási arányát úgy, hogy korszakonként nyolcan (8) kapcsolódhatnak be a hálózatba. Mivel az ETH-kibocsátás arányos az összes letétbe helyezett ETH-szel, a csatlakozó validátorok számának korlátozása korlátozza az újonnan kibocsátott ETH _növekedési ütemét_, miközben csökkenti a csomópontüzemeltetők hardverigényét, segítve a decentralizációt. - - - -
    -
  • EIP-4788 - Beaconblokk-gyökér az EVM-ben
    • -
  • EIP-4844 - Shard blob tranzakciók
    • -
  • EIP-7044 - Örökké érvényes aláírt önkéntes kilépések
    • -
  • EIP-7045 - Növeli a maximális tanúsításbeszámítási slotot
    • -
  • EIP-7514 - Maximálja a korszakonként belépő validátorok számát
    • -
- - - -- [Olvassa el a Deneb frissítés specifikációit](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/) -- [Cancun-Deneb („Dencun”) FAQ](/roadmap/dencun/) - - - -## 2023 {#2023} - -### Shanghai-Capella ("Shapella") {#shapella} - - - -#### Shanghai összefoglaló {#shanghai-summary} - -A Shanghai frissítés vezette be a letétek kivonási lehetőségét a végrehajtási rétegen. A Capella frissítéssel együtt ez lehetővé tette, hogy a blokkok kivonási műveletet fogadjanak el, amivel a letétesek ki tudják venni az ETH a Beacon láncról a végrehajtási rétegre. - - - -
    -
  • EIP-3651 – A COINBASE címmelegítés elkezdése
    • -
  • EIP-3855 – Új PUSH0 parancs
    • -
  • EIP-3860 – Az initkód behatárolása és mérése
    • -
  • EIP-4895 – A Beacon lánc kivételeket küld műveletként
    • -
  • EIP-6049 – ASELFDESTRUCT érvénytelenítése
    • -
- - - -- [Olvassa el a Shanghai frissítés specifikációit](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md) - -#### Capella összefoglaló {#capella-summary} - -A Capella frissítés a harmadik legnagyobb frissítés volt a konszenzusrétegen (Beacon lánc) és lehetővé tette a letétek kivételét. A Capella egyszerre történt a Shanghai frissítéssel, ami a végrehajtási réteget változtatta meg, és így lehetővé vált a letét kivétele. - -Ez a konszenzusréteg frissítés megengedte a letétbe helyezőknek, hogy ha a letét kezdetén nem adtak meg kivételi adatokat, akkor most megtehessék. - -Emellett bevezették az automatikus számlasöprési funkciót, ami folyamatosan átnézi a validátorok számláit, hogy van-e kifizetendő jutalom vagy teljes kivétel. - -- [Bővebben a letétek visszavonásáról](/staking/withdrawals/). -- [Olvassa el a Capella frissítés specifikációit](https://github.com/ethereum/consensus-specs/blob/dev/specs/capella/) - - - -## 2022 {#2022} - -### Paris (a Beolvadás) {#paris} - - - -#### Összegzés {#paris-summary} - -A Paris frissítést az váltotta ki, hogy a proof-of-work blokklánc meghaladta a [végső teljes nehézséget](/glossary/#terminal-total-difficulty), melynek mértéke 58 750 000 000 000 000 000 000 volt. Az a 15 537 393. blokknál történt 2022. szeptember 15-én, így kiváltva a következő blokktól a Paris frissítést. A Paris volt [a Beolvadásra](/roadmap/merge/) való áttérés, melynek fő jellemzője a [proof-of-work](/developers/docs/consensus-mechanisms/pow) bányászó algoritmus és a kapcsolódó konszenzuslogika kikapcsolása, ehelyett pedig a [proof-of-stake](/developers/docs/consensus-mechanisms/pos) bekapcsolása. A Paris egyúttal frissítette a [végrehajtási klienseket](/developers/docs/nodes-and-clients/#execution-clients) is (a Bellatrix-hoz hasonlóan, ami a konszenzusrétegen tette), hogy instrukciókat tudjanak fogadni a velük kapcsolódó [konszenzuskliensektől](/developers/docs/nodes-and-clients/#consensus-clients). Ehhez szükség volt arra, hogy a belső API-metódusok egy új készletét, az [Engine API-kat](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) aktiválják. Ez kétségtelenül az Ethereum történetének legjelentősebb frissítése volt a [Homestead](#homestead) óta! - -- [Olvassa el a Paris frissítés specifikációit](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/paris.md) - - - -
    -
  • EIP-3675 – A konszenzus frissítése proof-of-stake-re
    • -
  • EIP-4399 – A DIFFICULTY opkód kiváltása PREVRANDAO-val
    • -
- - - ---- - -### Bellatrix {#bellatrix} - - - -#### Összegzés {#bellatrix-summary} - -A Bellatrix frissítés a második betervezett frissítés volt a [Beacon láncra](/roadmap/beacon-chain), hogy előkészítse a láncot a [a Beolvadásra](/roadmap/merge/). Ezzel a validátorok büntetései teljes értékűek lettek az aktivitás hiányára és a súlyos büntetésekre vonatkozóan. A Bellatrix szintén hozott egy frissítést az elágazásválasztás szabályaiba, hogy felkészítse a láncot a Beolvadásra és arra, hogy az utolsó proof-of-work blokk után az első proof-of-stake blokk következzen. A konszenzuskliensek ezzel tudatosak lettek az 58 750 000 000 000 000 000 000 [végső teljes nehézségről](/glossary/#terminal-total-difficulty). - -- [Olvassa el a Bellatrix frissítés specifikációit](https://github.com/ethereum/consensus-specs/tree/dev/specs/bellatrix) - ---- - -### Gray Glacier {#gray-glacier} - - - -#### Összegzés {#gray-glacier-summary} - -A Gray Glacier hálózati frissítés eltolta a [nehézségi bombát](/glossary/#difficulty-bomb) három hónappal. Ez a frissítés csak ezt változtatta meg, és így természetében hasonlít a [Arrow Glacier](#arrow-glacier) és a [Muir Glacier](#muir-glacier) frissítésekhez. Hasonló változtatások történtek a [Byzantium](#byzantium), [Constantinople](#constantinople) és [London](#london) hálózati frissítéseknél is. - -- [EF Blog – Gray Glacier frissítés bejelentése](https://blog.ethereum.org/2022/06/16/gray-glacier-announcement/) - - - -
    -
  • EIP-5133 – A nehézségi bomba elhalasztása 2022. szeptemberig
    • -
- - - - - -## 2021 {#2021} - -### Arrow Glacier {#arrow-glacier} - - - -#### Összegzés {#arrow-glacier-summary} - -Az Arrow Glacier hálózati frissítés eltolta a [nehézségi bombát](/glossary/#difficulty-bomb) néhány hónappal. Ez a frissítés csak ezt változtatta meg, és így természetében hasonlít a [Muir Glacier](#muir-glacier) frissítéshez. Hasonló változtatások történtek a [Byzantium](#byzantium), [Constantinople](#constantinople) és [London](#london) hálózati frissítéseknél is. - -- [EF Blog – Arrow Glacier frissítés bejelentése](https://blog.ethereum.org/2021/11/10/arrow-glacier-announcement/) -- [Ethereum Cat Herders – Ethereum Arrow Glacier frissítés](https://medium.com/ethereum-cat-herders/ethereum-arrow-glacier-upgrade-e8d20fa4c002) - - - -
    -
  • EIP-4345 – A nehézségi bomba elhalasztása 2022. júniusig
    • -
- - - ---- - -### Altair {#altair} - - - -#### Összegzés {#altair-summary} - -Az Altair frissítés a [Beacon lánc](/roadmap/beacon-chain) első tervezett változtatása volt. A „szinkronizálási bizottságokhoz” adott támogatást, mint a könnyű kliensek bevezetése, valamint megnövelte a validátor nem aktivitás és súlyos büntetések mértékét, hogy előkészítse a Beolvadást. - -- [Olvassa el az Altair frissítés specifikációit](https://github.com/ethereum/consensus-specs/tree/dev/specs/altair) - -#### Érdekesség! {#altair-fun-fact} - -Az Altair volt az első nagyobb hálózati frissítés, aminek konkrét bevezetési ideje volt. Az összes korábbi frissítés egy adott blokkszám alapján történt a proof-of-work láncon, ahol a blokkonkénti idő változó. A Beacon láncnak nem kellett igazodnia a proof-of-workhöz, így időalapú korszakok rendszerén alapszik, amelyek 32 darab 12 másodperces slotból állnak, és a validátorok ezekben tudnak blokkot javasolni. Így pontosan lehetett tudni, hogy mikor következik a 74 240. korszak, hogy az Altair életbe léphessen! - -- [Blokk idő](/developers/docs/blocks/#block-time) - ---- - -### London {#london} - - - -#### Összegzés {#london-summary} - -A London frissítés bevezette az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) változást, amely megreformálta a tranzakciós illeték piacát, azzal együtt, hogyan kezelik a gázvisszatérítéseket, valamint betervezte az [Ice Age](/glossary/#ice-age) ütemtervet. - -#### Mi volt a London-frissítés (EIP-1559) lényege? {#eip-1559} - -A London-frissítés előtt az Ethereum fix méretű blokkokkal működött. A magas hálózati kereslet idején ezek a blokkok teljes kapacitással működtek. Ennek eredményeképp a felhasználóknak sokszor várni kellett a kereslet csökkenésére, hogy bekerülhessenek egy blokkba, ami rontott a felhasználói élményen. A London-frissítés bevezette a változó méretű blokkokat az Ethereumon. - -A tranzakciós díjak számításának módja 2021. augusztusában megváltozott [a London-frissítéssel](/history/#london) az Ethereum hálózatán. A London Upgrade előtt a díjakat úgy kalkulálták, hogy elkülönítették az `alapdíjat` és az `elsőbbségi díjat`: - -Tegyük fel, hogy Alice-nek fizetnie kell Bobnak 1 ETH-t. A tranzakcióban a gázkorlátozás 21 000 egység, a gázdíj pedig 200 gwei. - -A teljes díj: `gáz mennyisége (határ) * egységenkénti gázdíj `, vagyis `21 000 * 200 = 4 200 000 gwei` vagy 0,0042 ETH - -Az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) bevezetése a London-frissítés során bonyolultabbá tette a tranzakciós illetékek működését, de megjósolhatóbb lett a gázdíj, ami egy sokkal hatékonyabb tranzakciósilleték-piacot eredményezett. A felhasználók megadhatják a `maxFeePerGas` értékét, vagyis azt, hogy legfeljebb mennyit hajlandók fizetni a tranzakció végrehajtásáért, annak tudatában, hogy nem fognak többet fizetni érte, mint a gáz piaci ára (`baseFeePerGas`), és a borravalót leszámítva visszakapják a különbözetet. - -Ez a videó elmagyarázza az EIP-1559-et és annak előnyeit: [EIP-1559 magyarázat](https://www.youtube.com/watch?v=MGemhK9t44Q) - -- [Ön egy dapp-fejlesztő? Feltétlenül frissítse a könyvtárakat és az eszközkészletet.](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/london-ecosystem-readiness.md) -- [Olvassa el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2021/07/15/london-mainnet-announcement/) -- [Olvassa el az Ethereum Cat Herder magyarázatát](https://medium.com/ethereum-cat-herders/london-upgrade-overview-8eccb0041b41) - - - -
    -
  • EIP-1559 – fejleszti a tranzakciós illeték piacát
    • -
  • EIP-3198 – visszaküldi a BASEFEE mezőt a blokkból
    • -
  • EIP-3529 – csökkenti a gázvisszatérítést az EVM-műveletekre
    • -
  • EIP-3541 – megakadályozza olyan szerződések telepítését, melyek 0xEF kóddal kezdődnek
    • -
  • EIP-3554 – elhalasztja az Ice Age korszakot 2021. decemberig
    • -
- - - ---- - -### Berlin {#berlin} - - - -#### Összegzés {#berlin-summary} - -A Berlin frissítés optimalizálta a gázköltséget bizonyos EVM műveleteknél, és több támogatást adott a többszörös tranzakció típusokra. - -- [Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2021/03/08/ethereum-berlin-upgrade-announcement/) -- [Olvasd el az Ethereum Cat Herder magyarázatát](https://medium.com/ethereum-cat-herders/the-berlin-upgrade-overview-2f7ad710eb80) - - - -
    -
  • EIP-2565 – csökkenti a ModExp gázköltséget
    • -
  • EIP-2718 – könnyebb támogatást tesz lehetővé a többszörös tranzakciótípusokra
    • -
  • EIP-2929 – a gázköltséget megnöveli a státuszelérő opkódokra
    • -
  • EIP-2930 – opcionális hozzáférési listákat hoz létre
    • -
- - - - - -## 2020 {#2020} - -### Beacon lánc genezise {#beacon-chain-genesis} - - - -#### Összegzés {#beacon-chain-genesis-summary} - -A [Beacon lánc](/roadmap/beacon-chain/) biztonságos elindításához 16384 darab 32 ETH-nyi letétre volt szükség. Ez november 27-én történt meg, vagyis a Beacon lánc a blokkok létrehozását 2020. december 1-jén kezdte meg. Ez az [Ethereum-vízió](/roadmap/vision/) elérésének fontos első lépése volt. - -[Olvassa el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2020/11/27/eth2-quick-update-no-21/) - - - A Beacon Chain - - ---- - -### A letétbe helyezési szerződés aktiválása {#staking-deposit-contract} - - - -#### Összegzés {#deposit-contract-summary} - -A letétbe helyezési szerződés vezette be a [letétbe helyezés](/glossary/#staking) rendszerét az Ethereum ökoszisztémába. Habár ez egy szerződés a [főhálózaton](/glossary/#mainnet), közvetlen hatást gyakorolt a [Beacon lánc](/roadmap/beacon-chain/) bevezetési idejére, ami egy fontos [Ethereum frissítés](/roadmap/). - -[Olvassa el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2020/11/04/eth2-quick-update-no-19/) - - - Letétbe helyezés - - ---- - -### Muir Glacier {#muir-glacier} - - - -#### Összegzés {#muir-glacier-summary} - -A Muir Glacier nevű elágazás késleltetést vezetett be a [nehézségi bombához](/glossary/#difficulty-bomb). A blokknehézség növelése a [proof-of-work](/developers/docs/consensus-mechanisms/pow/) konszenzusmechanizmusában azzal fenyegetett, hogy az Ethereum használhatósága csökkenni fog, mert a tranzakciók küldése és a dappok használata több időt fog igénybe venni. - -- [Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2019/12/23/ethereum-muir-glacier-upgrade-announcement/) -- [Olvasd el az Ethereum Cat Herder magyarázatát](https://medium.com/ethereum-cat-herders/ethereum-muir-glacier-upgrade-89b8cea5a210) - - - -
    -
  • EIP-2384 – eltolta a nehézségi bomba bevezetését újabb 4 000 000 blokkal vagy kb. 611 nappal.
    • -
- - - - - -## 2019 {#2019} - -### Istanbul {#istanbul} - - - -#### Összegzés {#istanbul-summary} - -Az Istanbul elágazás: - -- Bizonyos műveletek [gázdíjának](/glossary/#gas) optimalizálása az [EVM-ben](/developers/docs/ethereum-stack/#ethereum-virtual-machine). -- Fejlettebb védekezés a szolgáltatásmegtagadásos támadások ellen. -- A SNARKokon és a STARKokon alapuló [második blokkláncréteg (L2) skálázási](/developers/docs/scaling/#layer-2-scaling) megoldások teljesítményének javítása. -- Az Ethereum és a Zcash közötti együttműködés bevezetése. -- Az okosszerződésekben kreatívabb függvényeket tett lehetővé. - -[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2019/11/20/ethereum-istanbul-upgrade-announcement/) - - - -
    -
  • EIP-152 – az Ethereum együtt tud működni az adatvédelmet megőrző valutával, mint amilyen a Zcash is.
    • -
  • EIP-1108 – olcsóbb kriptográfia, hogy javuljon a gázdíj.
    • -
  • EIP-1344 – az Ethereumot védi az újrajátszási támadással szemben a CHAINID opkód bevezetésével.
    • -
  • EIP-1884 – optimalizálja az opkód gázdíjait a fogyasztás alapján.
    • -
  • EIP-2028 – a CallData költségének csökkentése, hogy több adat férjen be a blokkokba, ami támogatja az L2 skálázást.
    • -
  • EIP-2200 – az opkód gázdíjának egyéb változtatásai.
    • -
- - - ---- - -### Constantinople {#constantinople} - - - -#### Összegzés {#constantinople-summary} - -A Constantinople elágazás: - -- A [blokkbányászat](/developers/docs/consensus-mechanisms/pow/mining/) jutalmának csökkentése 3 ETH-ről 2-re. -- A blokklánc lefagyásának megakadályozása, mielőtt a [proof-of-stake bevezetésre kerülne](#beacon-chain-genesis). -- Bizonyos műveletek [gázdíjának](/glossary/#gas) optimalizálása az [EVM-ben](/developers/docs/ethereum-stack/#ethereum-virtual-machine). -- Lehetőség olyan címekkel történő interakcióra, melyek még nem jöttek létre. - -[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/) - - - -
    -
  • EIP-145 – optimalizálja bizonyos láncon futó műveletek költségét.
    • -
  • EIP-1014 – lehetővé teszi az interakciót olyan szerződésekkel, amelyeket még nem hoztak létre.
    • -
  • EIP-1052 – a EXTCODEHASH művelet bevezetése, hogy egy másik szerződés kódjának hash-ét vissza lehessen kapni.
    • -
  • EIP-1234 – megakadályozza, hogy a blokklánc lefagyjon a proof-of-stake bevezetése előtt, és 3 ETH-ről 2-re csökkenti a blokkjutalmat.
    • -
- - - - - -## 2017 {#2017} - -### Byzantium {#byzantium} - - - -#### Összegzés {#byzantium-summary} - -A Byzantium elágazás: - -- A [blokkbányászat](/developers/docs/consensus-mechanisms/pow/mining/) jutalmának csökkentése 5 ETH-ről 3-re. -- A [nehézségi bomba](/glossary/#difficulty-bomb) késleltetése egy évvel. -- Bevezették azt a lehetőséget, hogy állapotot nem befolyásoló hívásokat lehet indítani más szerződések felé. -- Bizonyos kriptográfiai módszerek hozzáadása, hogy támogassa az [L2 skálázást](/developers/docs/scaling/#layer-2-scaling). - -[Olvassa el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/) - - - -
    -
  • EIP-140 – a REVERT opkód bevezetése.
    • -
  • EIP-658 – a tranzakció-visszaigazolásba bekerült a státuszmező, hogy mutassa a sikeres vagy sikertelen végrehajtást.
    • -
  • EIP-196 – az elliptikus görbe és a skaláris szorzás bevezetése, hogy támogassa a ZK-SNARK-okat.
    • -
  • EIP-197 – az elliptikus görbe és a skaláris szorzás bevezetése, hogy támogassa a ZK-SNARK-okat.
    • -
  • EIP-198 – az RSA aláírásellenőrzés lehetővé tétele.
    • -
  • EIP-211 – a változó hosszúságú visszatérési értékek támogatása.
    • -
  • EIP-214 – a STATICCALL opkód bevezetése, hogy állapotot nem befolyásoló hívásokat lehessen indítani más szerződések felé.
    • -
  • EIP-100 – a nehézség beállítási formulájának változtatása.
    • -
  • EIP-649 – a nehézségi bomba elhalasztása 1 évvel, és a blokkjutalom csökkentése 5 ETH-ről 3-ra.
    • -
- - - - - -## 2016 {#2016} - -### Spurious Dragon {#spurious-dragon} - - - -#### Összegzés {#spurious-dragon-summary} - -A Spurious Dragon elágazás volt a második válasz a szolgáltatásmegtagadásos (DoS) támadásokkal szemben a hálózaton (2016. szeptember/október), amely az alábbiakat tartalmazta: - -- opkód-díjszabás finomhangolása a jövőbeli támadások megakadályozása érdekében. -- a blokkláncállapot „leeresztésének” lehetővé tétele. -- visszajátszásos támadás elleni védelem hozzáadása. - -[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/) - - - -
    -
  • EIP-155 – megakadályozza, hogy egy Ethereum-láncról a tranzakciókat újra elküldjék egy alternatív láncon, például egy teszthálózati tranzakciót lejátszanak a főhálózaton.
    • -
  • EIP-160 – az EXP opkód árának korrigálása, hogy ezáltal nehezebb legyen lelassítani a hálózatot az intenzív számítást igénylő szerződésműködésekkel.
    • -
  • EIP-161 – az üres számlák eltávolítása, melyeket a szolgáltatásmegtagadási (DoS) támadások alatt hoztak létre.
    • -
  • EIP-170 – a láncon lévő szerződés maximális kódméretének megnövelése 24 576 bájtra.
    • -
- - - ---- - -### Tangerine whistle {#tangerine-whistle} - - - -#### Összegzés {#tangerine-whistle-summary} - -A Tangerine Whistle elágazás volt a első válasz a szolgáltatásmegtagadásos (DoS) támadásokkal szemben a hálózaton (2016. szeptember/október), mely az alábbiakat tartalmazta: - -- az alulárazott opkódokkal kapcsolatos sürgős hálózati kérdések kezelése. - -[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/) - - - -
    -
  • EIP-150 – megnöveli azon opkódok gázköltségeit, melyeket teleszemetelési (spam) támadásokra lehet használni.
    • -
  • EIP-158 – csökkenti a státuszméretet azáltal, hogy eltávolítja az üres számlákat, melyeket alacsony költségen küldtek be a státuszba a korábbi Ethereum-protokoll hibái miatt.
    • -
- - - ---- - -### DAO elágazás {#dao-fork} - - - -#### Összegzés {#dao-fork-summary} - -A DAO elágazás volt a válasz a [2016-os DAO-támadásra](https://www.coindesk.com/learn/understanding-the-dao-attack/), amikor egy sérülékeny [DAO](/glossary/#dao) szerződésből 3,6 millió ETH-t ürítettek le a támadás során. Az elágazás átmozgatta a pénzt a hibás szerződésből egy [új szerződésbe](https://etherscan.io/address/0xbf4ed7b27f1d666546e30d74d50d173d20bca754), amelynek csak kiutalási funkciója volt. Bárki, aki veszteséget szenvedett el, kivehetett 1 ETH-t a tárcájában lévő minden 100 DAO tokenre. - -Ennek az akciónak a menetét megszavazták az Ethereum közösségen belül. Bármely ETH tulajdonos szavazhatott egy tranzakción keresztül [egy szavazási platformon](https://web.archive.org/web/20170620030820/http://v1.carbonvote.com/). A fork mellett több mint a szavazók 85%-a voksolt. - -Némely bányász nem támogatta az elágazást, mivel a DAO incidens nem a protokollból származó hibából eredt. Ők ezután létrehozták az [Ethereum Classicot](https://ethereumclassic.org/). - -[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2016/07/20/hard-fork-completed/) - ---- - -### Homestead {#homestead} - - - -#### Összegzés {#homestead-summary} - -A Homestead elágazás a jövőbe tekintett. Számos protokollváltoztatást és egy hálózati módosítást tartalmazott, mely lehetővé tette az Ethereum számára a további hálózati változtatásokat. - -[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2016/02/29/homestead-release/) - - - -
    -
  • EIP-2 – a szerződéslétrehozási folyamat szerkesztése.
    • -
  • EIP-7 – a DELEGATECALL új opkód bevezetése
    • -
  • EIP-8 – bevezették a devp2p jövőkompatibilitási (forward compatibility) követelményeket
    • -
- - - - - -## 2015 {#2015} - -### Frontier thawing {#frontier-thawing} - - - -#### Összegzés {#frontier-thawing-summary} - -A Frontier thawing elágazás megemelte az 5000-es [gázhatárt](/glossary/#gas) [blokkonként](/glossary/#block) és beállította az alapértelmezett gázárat 51 [gweire](/glossary/#gwei). Ez lehetővé tette a tranzakciók létrejöttét, mivel azokhoz 21 000 gázra van szükség. Bevezették a [nehézségi bombát](/glossary/#difficulty-bomb), hogy lehetőség legyen egy jövőbeli végleges elágazásra (hard fork) a [proof-of-stake](/glossary/#pos) mechanizmusra való áttérésnél. - -- [Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2015/08/04/the-thawing-frontier/) -- [Tekintse meg az Ethereum 1. protokollfrissítéséről szóló cikket](https://blog.ethereum.org/2015/08/04/ethereum-protocol-update-1/) - ---- - -### Frontier {#frontier} - - - -#### Összegzés {#frontier-summary} - -A Frontier egy működő, de teljesen leegyszerűsített implementációja volt az Ethereum projektnek. A sikeres Olympic tesztelési fázist követte. A műszaki felhasználóknak, kimondottan a fejlesztőknek készült. A [blokkoknak](/glossary/#block) 5000-es [gázhatár](/glossary/#gas) volt beállítva. Ez a „kiolvasztási” időszak lehetővé tette a bányászok számára, hogy elindítsák a tevékenységüket, és a korai felhasználóknak, hogy telepítsék a klienseiket anélkül, hogy sietniük kellene. - -[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2015/07/22/frontier-is-coming-what-to-expect-and-how-to-prepare/) - - - -## 2014 {#2014} - -### Ether-értékesítés {#ether-sale} - - - -Az Ether értékesítése hivatalosan 42 napig tartott. BTC-vel lehetett érte fizetni. - -[Olvasd el az Ethereum Alapítvány közleményét](https://blog.ethereum.org/2014/07/22/launching-the-ether-sale/) - ---- - -### Sárgakönyv kiadása {#yellowpaper} - - - -A Sárgakönyv, melynek a szerzője Dr. Gavin Wood, az Ethereum protokoll műszaki meghatározása. - -[A Sárgakönyv megtekintése](https://github.com/ethereum/yellowpaper) - - - -## 2013 {#2013} - -### A Fehérkönyv kiadása {#whitepaper} - - - -A bemutatkozó kiadvány, melyet Vitalik Buterin, az Ethereum alapítója adott ki 2013-ban, a projekt 2015-ös indulása előtt. - - - Fehérkönyv - diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" deleted file mode 100644 index 6d6d4364b23..00000000000 --- "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/anatomy/index.md" +++ /dev/null @@ -1,658 +0,0 @@ ---- -title: A okosszerződések anatómiája -description: Egy részletes betekintés az okosszerződések felépítésébe, beleértve a függvényeket, adatokat és változókat. -lang: hu ---- - -Az okosszerződés egy olyan program, mely egy cím alatt fut az Ethereumon. Adatokból és függvényekből állnak, melyeket végre lehet hajtani bemenő tranzakciók által. Ez az áttekintés az okosszerződések felépítéséről szól. - -## Előfeltételek {#prerequisites} - -Először tekintse meg az [okosszerződésekről](/developers/docs/smart-contracts/) szóló cikket. Ez a dokumentum feltételezi, hogy már jártas a programozási nyelvekben, mint a JavaScript vagy a Python. - -## Adat {#data} - -Minden szerződésadatot hozzá kell rendelni egy lokációhoz, mely lehet a `storage` vagy a `memory`. Költséges a tárhelyet módosítani egy okosszerződésben, tehát érdemes fontolóra venni, hogy hol legyen az adat. - -### Tárhely {#storage} - -Az állandó adatokat tárolásnak nevezzük, és állapotváltozók reprezentálják őket. Ezeket az értékeket permanensen a blokkláncon tároljuk. Deklarálnia kell a típust, hogy a szerződés számon tudja tartani, hogy mekkora tárhelyre lesz szüksége a blokkláncon az átfordításkor. - -```solidity -// Solidity példa -contract SimpleStorage { - uint storedData; // Állapotváltozó - // ... -} -``` - -```python -# Vyper példa -storedData: int128 -``` - -Ha Ön programozott már objektumorientált nyelven, akkor a legtöbb típus valószínűleg ismerős lesz. Ugyanakkor az `address` típus új lesz, ha még csak most ismerkedik az Ethereum fejlesztéssel. - -Az `address` típus egy Ethereum címet tud tárolni, mely 20 bájttal vagy 160 bittel egyenlő. Hexadecimális értéket ad vissza vezető 0x-szel. - -A többi típus: - -- boolean -- egész (integer) -- fixpontos szám -- fix méretű bájttömb -- dinamikus méretű bájttömb -- Racionális és egész szám literálok -- String literálok -- Hexadecimális literálok -- Enum - -További magyarázatért tekintse meg az alábbi dokumentumokat: - -- [Vyper típusok megtekintése](https://vyper.readthedocs.io/en/v0.1.0-beta.6/types.html#value-types) -- [Solidity típusok megtekintése](https://solidity.readthedocs.io/en/latest/types.html#value-types) - -### Memória {#memory} - -Memóriaváltozóknak nevezzük azokat az értékeket, melyek csak a szerződésfunkció végrehajtása alatt tárolódnak. Mivel nem kell őket permanensen a blokkláncon tárolni, így sokkal olcsóbb a használatuk. - -Tudjon meg többet az EVM adattárolási módszeréről a [Solidity dokumentációból](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html?highlight=memory#storage-memory-and-the-stack) (a „Storage, Memory and the Stack” szekcióból). - -### Környezeti változók {#environment-variables} - -A szerződésben meghatározott változók mellett van néhány speciális globális változó is. Elsősorban a blokklánccal vagy az aktuális tranzakcióval kapcsolatos információk nyújtására szolgálnak. - -Példák: - -| **Tul.** | **Állapotváltozó** | **Leírás** | -| ----------------- | ------------------ | ----------------------------------- | -| `block.timestamp` | uint256 | Jelenlegi blokk korszak időbélyege | -| `msg.sender` | address | Az üzenet küldője (jelenlegi hívás) | - -## Függvények {#functions} - -A legegyszerűbben megfogalmazva, a függvények információkat kaphatnak vagy információkat állíthatnak be válaszul a bejövő tranzakciókra. - -Kétfajta függvényhívás létezik: - -- `internal` – ezek nem okoznak EVM hívást - - A belső (internal) függvényeket és állapotváltozókat csak belülről lehet elérni (vagyis a jelenlegi szerződésből vagy a származtatott szerződésekből) -- `external` – ezek EVM hívást okoznak - - A külső (external) függvények a szerződés felületének részei, mely azt jelenti, hogy meg lehet őket hívni más szerződésekből vagy tranzakciókon keresztül. Egy külső függvény `f` kódját nem lehet belülről meghívni (vagyis az `f()` nem működik, de a `this.f()` igen). - -Ezenkívül lehetnek `public` vagy `private` típusúak is - -- a `public` függvényeket belülről lehet meghívni vagy kívülről üzenetek által -- a `private` függvények csak abban a szerződésben láthatóak, amiben definiálták őket, a származtatott szerződésekben nem - -A függvények és az állapotváltozók is lehetnek publikusak vagy privátak - -Íme egy függvény, mely egy állapotváltozó értékét állítja be egy szerződésben: - -```solidity -// Solidity példa -function update_name(string value) public { - dapp_name = value; -} -``` - -- A `string` típusú `value` paraméter kerül be a függvénybe: `update_name` -- Ez `public` módon lett deklarálva, így mindenki hozzáfér -- Nem `view` módon lett deklarálva, így módosíthatja a szerződésállapotot - -### Nézet (view) függvények {#view-functions} - -Ezek a függvények azt ígérik, hogy nem módosítják a szerződés adatainak állapotát. Általános példák a „getter” függvények – ezeket használhatja például egy felhasználó egyenlegének lekérdezésére. - -```solidity -// Solidity példa -function balanceOf(address _owner) public view returns (uint256 _balance) { - return ownerPizzaCount[_owner]; -} -``` - -```python -dappName: public(string) - -@view -@public -def readName() -> string: - return dappName -``` - -Mi számít állapotmódosításnak: - -1. Állapotváltozókba írás. -2. [Események kibocsátása](https://solidity.readthedocs.io/en/v0.7.0/contracts.html#events). -3. [Másik szerződés létrehozás](https://solidity.readthedocs.io/en/v0.7.0/control-structures.html#creating-contracts). -4. A `selfdestruct` használata. -5. Ether küldése hívásokkal. -6. Bármely függvény meghívása, mely nincs `view` vagy `pure` jelöléssel ellátva. -7. Alacsony szintű hívások. -8. Egysoros assembly használata, mely bizonyos opkódot tartalmaz. - -### Konstruktor függvények {#constructor-functions} - -A `constructor` csak egyszer fut le, amikor a szerződést először telepítik. Mint a `constructor` számos osztályalapú programozási nyelv esetében, ezek a függvények gyakran inicializálják az állapotváltozókat a meghatározott értékeikre. - -```solidity -// Solidity példa -// Inicializálja a szerződés adatait, beállítja az 'owner-t' -// a szerződés létrehozó címére. -constructor() public { - // Minden okosszerződés külső tranzakciókra hagyatkozik a függvényeik végrehajtására. - // az `msg` globális változó, mely az adott tranzakcióhoz tartozó adatot tartalmaz, - // mint a küldő címe és az ETH mennyisége a tranzakcióban. - // Több infó: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties - owner = msg.sender; -} -``` - -```python -# Vyper példa - -@external -def __init__(_beneficiary: address, _bidding_time: uint256): - self.beneficiary = _beneficiary - self.auctionStart = block.timestamp - self.auctionEnd = self.auctionStart + _bidding_time -``` - -### Beépített függvények {#built-in-functions} - -A szerződésben meghatározott függvények és változók mellett van néhány speciális beépített függvény is. A legnyilvánvalóbb példák: - -- `address.send()` – Solidity -- `send(address)` – Vyper - -Ez lehetőséget ad a szerződéseknek, hogy ETH-t küldjenek más számláknak. - -## Függvények írása {#writing-functions} - -A függvénynek szüksége van: - -- egy paraméterváltozóra és egy típusra (ha elfogad paramétereket) -- a belső/külső deklarációra -- a pure/view/payable deklarációra -- a visszatérítési érték típusára (ha van visszatérítési értéke) - -```solidity -pragma solidity >=0.4.0 <=0.6.0; - -contract ExampleDapp { - string dapp_name; // state variable - - // Called when the contract is deployed and initializes the value - constructor() public { - dapp_name = "My Example dapp"; - } - - // Get Function - function read_name() public view returns(string) { - return dapp_name; - } - - // Set Function - function update_name(string value) public { - dapp_name = value; - } -} -``` - -Egy kész szerződés nagyjából így nézne ki. Itt a `constructor` függvény biztosítja a `dapp_name` változó kezdeti értékét. - -## Események és naplózások {#events-and-logs} - -Az eseményeken keresztül tud kommunikálni az okosszerződés és a frontend vagy más feliratkozó alkalmazás. Amikor egy tranzakciót validálnak, az okosszerződések eseményeket és naplófájlokat bocsáthatnak ki, melyet a frontend feldolgozhat és hasznosíthat. - -## Jegyzetekkel ellátott példák {#annotated-examples} - -Íme néhány példa, amelyet Solidity-ben írtak. Ha szeretne megismerkedni a kóddal, akkor kipróbálhatja a [Remixben](http://remix.ethereum.org). - -### Hello world {#hello-world} - -```solidity -// A Solidity verziószámát írja elő szemantikailag. -// Több információ: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#pragma -pragma solidity ^0.5.10; - -// Egy `HelloWorld` nevű szerződés definiálása. -// A szerződés egy függvények és adatok (az állapota) gyűjteménye. -// Telepítés után a szerződés egy bizonyos címen él az Ethereum blokkláncon. -//További információ: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html -contract HelloWorld { - - // Deklarálja a `string` típusú `message` állapotváltozót. - // Az állapotváltozók olyan változók, melyeknek értékei permanensen tárolódnak a szerződés tárhelyén. - // A `public` kulcsszó lehetővé teszi a változó szerződésen kívüli elérését - // és függvényt hoz létre, mellyel más szerződések vagy kliensek le tudják kérdezni az értéket. - string public message; - - // Más osztály alapú nyelvhez hasonlóan a konstruktor egy - // speciális függvény, mely csak egyszer fut le a szerződés létrehozáskor. - // A konstruktorokat az szerződés adatainak inicializálásra lehet használni. - // További információ: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constructors - constructor(string memory initMessage) public { - // Az `initMessage` string paramétert fogadja el és beállítja - // a szerződés `message` tárhely változójába). - message = initMessage; - } - - // Egy publikus függvény, mely egy string paramétert fogad el - // és frissíti a `message` tárhely változót. - function update(string memory newMessage) public { - message = newMessage; - } -} -``` - -### Token {#token} - -```solidity -pragma solidity ^0.5.10; - -contract Token { - // Egy `address` olyan, mint egy email cím - az Ethereum számlák beazonosítására szolgál. - // A címek okosszerződéseket vagy külső (felhasználói) számlákat jelölnek. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#address - address public owner; - - // A `mapping` lényegében egy hash tábla adatszerkezet. - // Ez a `mapping` egy unsigned integert (a token egyenleget) rendel hozzá egy címhez (a token tartóhoz). - // További információ: https://solidity.readthedocs.io/en/v0.5.10/types.html#mapping-types - mapping (address => uint) public balances; - - // Az eseményekkel lehet tevékenységet logolni a blokkláncon. - // Az Ethereum kliensek figyelhetik az eseményeket, hogy reagáljanak az szerződés állapotváltozásokra. - // További információ: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#events - event Transfer(address from, address to, uint amount); - - // Inicializálja a szerződés adatot, beállítja az `owner` - // változót a szerződés létrehozó címére. - constructor() public { - // Minden okosszerződés külső tranzakciókra hagyatkozik a függvényeik végrehajtására. - // az `msg` globális változó, mely az adott tranzakcióhoz tartozó adatot tartalmaz, - // mint a küldő címe és az ETH mennyisége a tranzakcióban. - //További információ: https://solidity.readthedocs.io/en/v0.5.10/units-and-global-variables.html#block-and-transaction-properties - owner = msg.sender; - } - - // Új tokeneket hoz létre és elküldi egy címre. - function mint(address receiver, uint amount) public { - // A `require` egy kontrol struktúra, mely bizonyos feltételek betartatására szolgál. - // Ha a `require` állítás `false` értéket ad, egy kivétel triggerelődik, - // mely visszaállít minden állapotváltozást a jelenlegi hívás alatt. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions - - // Only the contract owner can call this function - require(msg.sender == owner, "You are not the owner."); - - // Enforces a maximum amount of tokens - require(amount < 1e60, "Maximum issuance exceeded"); - - // Increases the balance of `receiver` by `amount` - balances[receiver] += amount; - } - - // Sends an amount of existing tokens from any caller to an address. - function transfer(address receiver, uint amount) public { - // A küldőnek elég tokennel kell rendelkeznie - require(amount <= balances[msg.sender], "Insufficient balance."); - - // Beállítja a token a két cím token mennyiségét - balances[msg.sender] -= amount; - balances[receiver] += amount; - - // Kibocsájtja a korábban definiált eseményt - emit Transfer(msg.sender, receiver, amount); - } -} -``` - -### Egyedi digitális eszköz {#unique-digital-asset} - -```solidity -pragma solidity ^0.5.10; - -// Szimbólumokat importál be más fájlokból a jelenlegi szerződésbe. -// Ebben az esetben egy pár segítő szerződést az OpenZeppelinről. -// További információ: https://solidity.readthedocs.io/en/v0.5.10/layout-of-source-files.html#importing-other-source-files - -import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721.sol"; -import "../node_modules/@openzeppelin/contracts/token/ERC721/IERC721Receiver.sol"; -import "../node_modules/@openzeppelin/contracts/introspection/ERC165.sol"; -import "../node_modules/@openzeppelin/contracts/math/SafeMath.sol"; - -// Az `is` kulcsszót használjuk, hogy külső szerződések függvényeit és kulcsszavait örököltessük. -// Ebben az esetben, `CryptoPizza` örököl az `IERC721` és az `ERC165` szerződésekből. -// További információ: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#inheritance -contract CryptoPizza is IERC721, ERC165 { - // Az OpenZeppelin SafeMath könyvtárát használja aritmetikai számítások biztonságos elvégzésére. - // További információ: https://docs.openzeppelin.com/contracts/2.x/api/math#SafeMath - using SafeMath for uint256; - - // A konstans állapotváltozók a Solidity-ben hasonlóak más nyelvekhez - // de a fordítás ideje alatt konstans kifejezésből kell hozzárendelni. - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#constant-state-variables - uint256 constant dnaDigits = 10; - uint256 constant dnaModulus = 10 ** dnaDigits; - bytes4 private constant _ERC721_RECEIVED = 0x150b7a02; - - // Struct types let you define your own type - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/types.html#structs - struct Pizza { - string name; - uint256 dna; - } - - // Creates an empty array of Pizza structs - Pizza[] public pizzas; - - // Mapping from pizza ID to its owner's address - mapping(uint256 => address) public pizzaToOwner; - - // Mapping from owner's address to number of owned token - mapping(address => uint256) public ownerPizzaCount; - - // Mapping from token ID to approved address - mapping(uint256 => address) pizzaApprovals; - - // You can nest mappings, this example maps owner to operator approvals - mapping(address => mapping(address => bool)) private operatorApprovals; - - // Internal function to create a random Pizza from string (name) and DNA - function _createPizza(string memory _name, uint256 _dna) - // The `internal` keyword means this function is only visible - // within this contract and contracts that derive this contract - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#visibility-and-getters - internal - // `isUnique` is a function modifier that checks if the pizza already exists - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/structure-of-a-contract.html#function-modifiers - isUnique(_name, _dna) - { - // Adds Pizza to array of Pizzas and get id - uint256 id = SafeMath.sub(pizzas.push(Pizza(_name, _dna)), 1); - - // Checks that Pizza owner is the same as current user - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/control-structures.html#error-handling-assert-require-revert-and-exceptions - - // note that address(0) is the zero address, - // indicating that pizza[id] is not yet allocated to a particular user. - - assert(pizzaToOwner[id] == address(0)); - - // Maps the Pizza to the owner - pizzaToOwner[id] = msg.sender; - ownerPizzaCount[msg.sender] = SafeMath.add( - ownerPizzaCount[msg.sender], - 1 - ); - } - - // Creates a random Pizza from string (name) - function createRandomPizza(string memory _name) public { - uint256 randDna = generateRandomDna(_name, msg.sender); - _createPizza(_name, randDna); - } - - // Generates random DNA from string (name) and address of the owner (creator) - function generateRandomDna(string memory _str, address _owner) - public - // Functions marked as `pure` promise not to read from or modify the state - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#pure-functions - pure - returns (uint256) - { - // Generates random uint from string (name) + address (owner) - uint256 rand = uint256(keccak256(abi.encodePacked(_str))) + - uint256(_owner); - rand = rand % dnaModulus; - return rand; - } - - // Returns array of Pizzas found by owner - function getPizzasByOwner(address _owner) - public - // Functions marked as `view` promise not to modify state - // Learn more: https://solidity.readthedocs.io/en/v0.5.10/contracts.html#view-functions - view - returns (uint256[] memory) - { - // Uses the `memory` storage location to store values only for the - // lifecycle of this function call. - // További info: https://solidity.readthedocs.io/en/v0.5.10/introduction-to-smart-contracts.html#storage-memory-and-the-stack - uint256[] memory result = new uint256[](ownerPizzaCount[_owner]); - uint256 counter = 0; - for (uint256 i = 0; i < pizzas.length; i++) { - if (pizzaToOwner[i] == _owner) { - result[counter] = i; - counter++; - } - } - return result; - } - - // Átadja a Pizza tulajdonjogot és másik címnek - function transferFrom(address _from, address _to, uint256 _pizzaId) public { - require(_from != address(0) && _to != address(0), "Invalid address."); - require(_exists(_pizzaId), "Pizza does not exist."); - require(_from != _to, "Cannot transfer to the same address."); - require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); - - ownerPizzaCount[_to] = SafeMath.add(ownerPizzaCount[_to], 1); - ownerPizzaCount[_from] = SafeMath.sub(ownerPizzaCount[_from], 1); - pizzaToOwner[_pizzaId] = _to; - - // Kibocsájt egy eseményt, mely az importált IERC721 szerződésben van definiálva - emit Transfer(_from, _to, _pizzaId); - _clearApproval(_to, _pizzaId); - } - - /** - * Biztonságosan átadja a egy adott token ID tulajdonjogát egy másik címnek - * Ha a cél cím egy szerződés, akkor az `onERC721Received`-nek implementálva kell lennie, - * mely egy biztonságos átadáskor meghívódik és visszaadja a bűvös értéket - * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * ellenkező esetben a transfer visszafordul. - */ - function safeTransferFrom(address from, address to, uint256 pizzaId) - public - { - // solium-disable-next-line arg-overflow - this.safeTransferFrom(from, to, pizzaId, ""); - } - - /** - * Biztonságosan átadja a egy adott token ID tulajdonjogát egy másik címnek - * Ha a cél cím egy szerződés, akkor az `onERC721Received`-nek implementálva kell lennie, - * mely egy biztonságos átadáskor meghívódik és visszaadja a bűvös értéket - * `bytes4(keccak256("onERC721Received(address,address,uint256,bytes)"))`; - * ellenkező esetben a transfer visszafordul. - */ - function safeTransferFrom( - address from, - address to, - uint256 pizzaId, - bytes memory _data - ) public { - this.transferFrom(from, to, pizzaId); - require(_checkOnERC721Received(from, to, pizzaId, _data), "Must implement onERC721Received."); - } - - /** - * Internal function to invoke `onERC721Received` on a target address - * The call is not executed if the target address is not a contract - */ - function _checkOnERC721Received( - address from, - address to, - uint256 pizzaId, - bytes memory _data - ) internal returns (bool) { - if (!isContract(to)) { - return true; - } - - bytes4 retval = IERC721Receiver(to).onERC721Received( - msg.sender, - from, - pizzaId, - _data - ); - return (retval == _ERC721_RECEIVED); - } - - // Burns a Pizza - destroys Token completely - // The `external` function modifier means this function is - // part of the contract interface and other contracts can call it - function burn(uint256 _pizzaId) external { - require(msg.sender != address(0), "Invalid address."); - require(_exists(_pizzaId), "Pizza does not exist."); - require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); - - ownerPizzaCount[msg.sender] = SafeMath.sub( - ownerPizzaCount[msg.sender], - 1 - ); - pizzaToOwner[_pizzaId] = address(0); - } - - // Returns count of Pizzas by address - function balanceOf(address _owner) public view returns (uint256 _balance) { - return ownerPizzaCount[_owner]; - } - - // Returns owner of the Pizza found by id - function ownerOf(uint256 _pizzaId) public view returns (address _owner) { - address owner = pizzaToOwner[_pizzaId]; - require(owner != address(0), "Invalid Pizza ID."); - return owner; - } - - // Approves other address to transfer ownership of Pizza - function approve(address _to, uint256 _pizzaId) public { - require(msg.sender == pizzaToOwner[_pizzaId], "Must be the Pizza owner."); - pizzaApprovals[_pizzaId] = _to; - emit Approval(msg.sender, _to, _pizzaId); - } - - // Returns approved address for specific Pizza - function getApproved(uint256 _pizzaId) - public - view - returns (address operator) - { - require(_exists(_pizzaId), "Pizza does not exist."); - return pizzaApprovals[_pizzaId]; - } - - /** - * Private function to clear current approval of a given token ID - * Reverts if the given address is not indeed the owner of the token - */ - function _clearApproval(address owner, uint256 _pizzaId) private { - require(pizzaToOwner[_pizzaId] == owner, "Must be pizza owner."); - require(_exists(_pizzaId), "Pizza does not exist."); - if (pizzaApprovals[_pizzaId] != address(0)) { - pizzaApprovals[_pizzaId] = address(0); - } - } - - /* - * Sets or unsets the approval of a given operator - * An operator is allowed to transfer all tokens of the sender on their behalf - */ - function setApprovalForAll(address to, bool approved) public { - require(to != msg.sender, "Cannot approve own address"); - operatorApprovals[msg.sender][to] = approved; - emit ApprovalForAll(msg.sender, to, approved); - } - - // Tells whether an operator is approved by a given owner - function isApprovedForAll(address owner, address operator) - public - view - returns (bool) - { - return operatorApprovals[owner][operator]; - } - - // Takes ownership of Pizza - only for approved users - function takeOwnership(uint256 _pizzaId) public { - require(_isApprovedOrOwner(msg.sender, _pizzaId), "Address is not approved."); - address owner = this.ownerOf(_pizzaId); - this.transferFrom(owner, msg.sender, _pizzaId); - } - - // Checks if Pizza exists - function _exists(uint256 pizzaId) internal view returns (bool) { - address owner = pizzaToOwner[pizzaId]; - return owner != address(0); - } - - // Checks if address is owner or is approved to transfer Pizza - function _isApprovedOrOwner(address spender, uint256 pizzaId) - internal - view - returns (bool) - { - address owner = pizzaToOwner[pizzaId]; - // Disable solium check because of - // https://github.com/duaraghav8/Solium/issues/175 - // solium-disable-next-line operator-whitespace - return (spender == owner || - this.getApproved(pizzaId) == spender || - this.isApprovedForAll(owner, spender)); - } - - // Check if Pizza is unique and doesn't exist yet - modifier isUnique(string memory _name, uint256 _dna) { - bool result = true; - for (uint256 i = 0; i < pizzas.length; i++) { - if ( - keccak256(abi.encodePacked(pizzas[i].name)) == - keccak256(abi.encodePacked(_name)) && - pizzas[i].dna == _dna - ) { - result = false; - } - } - require(result, "Pizza with such name already exists."); - _; - } - - // Returns whether the target address is a contract - function isContract(address account) internal view returns (bool) { - uint256 size; - // Currently there is no better way to check if there is a contract in an address - // than to check the size of the code at that address. - // Lásd https://ethereum.stackexchange.com/a/14016/36603 - // hogy hogyan működik ez. - // TODO A Serenity release előtt ellenőrizni, mivel azután minden cím - // szerződés lesz. - // solium-disable-next-line security/no-inline-assembly - assembly { - size := extcodesize(account) - } - return size > 0; - } -} -``` - -## További olvasnivaló {#further-reading} - -Tekintse meg a Solidity és a Vyper dokumentációit az okosszerződések teljesebb áttekintésért: - -- [Solidity](https://solidity.readthedocs.io/) -- [Vyper](https://vyper.readthedocs.io/) - -## Kapcsolódó témák {#related-topics} - -- [Okosszerződések](/developers/docs/smart-contracts/) -- [Ethereum virtuális gép](/developers/docs/evm/) - -## Kapcsolódó útmutatók {#related-tutorials} - -- [A szerződések méretének csökkentése, hogy ne okozzon gondot a méretkorlát](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– Gyakorlati tanácsok az okosszerződés méretének redukálására._ -- [Okosszerződések adatnaplózása az események mentén](/developers/tutorials/logging-events-smart-contracts/) _– Bevezetés az okossszerződések eseményeibe, s azok használata az adatnaplózáshoz._ -- [Más szerződésekkel való interakció a Solidity által](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– Hogyan telepítsen okosszerződést egy létező szerződésből és kapcsolódjon azzal._ diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" deleted file mode 100644 index ba918afa274..00000000000 --- "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/compiling/index.md" +++ /dev/null @@ -1,282 +0,0 @@ ---- -title: Okos szerződések fordítása -description: Magyarázat arról, hogy miért kell az okosszerződéseket átfordítani, és hogy pontosan mit csinál az átfordítás. -lang: hu -incomplete: true ---- - -Át kell fordítani a szerződéseket, hogy a webalkalmazás és az Ethereum virtuális gép (EVM) meg tudja érteni azokat. - -## Előfeltételek {#prerequisites} - -Segítségére lehetnek az [okosszerződésekről](/developers/docs/smart-contracts/) és az [Ethereum virtuális gépről](/developers/docs/evm/) szóló cikkek, mielőtt belekezdene az átfordításba. - -## Az EVM {#the-evm} - -Ahhoz, hogy az [EVM](/developers/docs/evm/) le tudja futtatni a szerződésedet, **bytecode-ban** kell lennie. Az átfordítás során ebből: - -```solidity -pragma solidity 0.4.24; - -contract Greeter { - - function greet() public constant returns (string) { - return "Hello"; - } - -} -``` - -**ez lesz:** - -``` -PUSH1 0x80 PUSH1 0x40 MSTORE PUSH1 0x4 CALLDATASIZE LT PUSH2 0x41 JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0xCFAE3217 EQ PUSH2 0x46 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST CALLVALUE DUP1 ISZERO PUSH2 0x52 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH2 0x5B PUSH2 0xD6 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP4 DUP2 DUP2 MLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 MLOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP1 DUP4 DUP4 PUSH1 0x0 JUMPDEST DUP4 DUP2 LT ISZERO PUSH2 0x9B JUMPI DUP1 DUP3 ADD MLOAD DUP2 DUP5 ADD MSTORE PUSH1 0x20 DUP2 ADD SWAP1 POP PUSH2 0x80 JUMP JUMPDEST POP POP POP POP SWAP1 POP SWAP1 DUP2 ADD SWAP1 PUSH1 0x1F AND DUP1 ISZERO PUSH2 0xC8 JUMPI DUP1 DUP3 SUB DUP1 MLOAD PUSH1 0x1 DUP4 PUSH1 0x20 SUB PUSH2 0x100 EXP SUB NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP JUMPDEST POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x60 PUSH1 0x40 DUP1 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 PUSH1 0x5 DUP2 MSTORE PUSH1 0x20 ADD PUSH32 0x48656C6C6F000000000000000000000000000000000000000000000000000000 DUP2 MSTORE POP SWAP1 POP SWAP1 JUMP STOP LOG1 PUSH6 0x627A7A723058 KECCAK256 SLT 0xec 0xe 0xf5 0xf8 SLT 0xc7 0x2d STATICCALL ADDRESS SHR 0xdb COINBASE 0xb1 BALANCE 0xe8 0xf8 DUP14 0xda 0xad DUP13 LOG1 0x4c 0xb4 0x26 0xc2 DELEGATECALL PUSH7 0x8994D3E002900 -``` - -Ezeket **opkódoknak** nevezzük. Az EVM opkódok olyan alacsony szintű utasítások, amelyeket az Ethereum virtuális gép (EVM) képes végrehajtani. Minden opkód egy adott műveletet képvisel, például aritmetikai műveleteket, logikai műveleteket, adatmanipulációt, vezérlésáramlást stb. - -[Bővebben az opkódokról](/developers/docs/evm/opcodes/) - -## Webalkalmazások {#web-applications} - -Az átfordító ezenkívül létrehozza az **Application Binary Interface-t (ABI)**, amire szüksége lesz, hogy az Ön alkalmazása megértse a szerződést, és meg tudja hívni a szerződés függvényeit. - -Az ABI egy JSON fáj, mely leírja a telepített szerződést és az okosszerződés függvényeit. Ez segít áthidalni a szakadékot a web2 és a web3 között. - -Egy [Javascript klienskönyvtár](/developers/docs/apis/javascript/) fogja az **ABI-t** olvasni, hogy Ön meghívhassa az okosszerződését a webalkalmazás felületén. - -Alább látható az ERC-20 tokenszerződés ABI-ja. Az ERC-20 egy token, mellyel az Ethereumon kereskedhetsz. - -```json -[ - { - "constant": true, - "inputs": [], - "name": "name", - "outputs": [ - { - "name": "", - "type": "string" - } - ], - "payable": false, - "stateMutability": "view", - "type": "function" - }, - { - "constant": false, - "inputs": [ - { - "name": "_spender", - "type": "address" - }, - { - "name": "_value", - "type": "uint256" - } - ], - "name": "approve", - "outputs": [ - { - "name": "", - "type": "bool" - } - ], - "payable": false, - "stateMutability": "nonpayable", - "type": "function" - }, - { - "constant": true, - "inputs": [], - "name": "totalSupply", - "outputs": [ - { - "name": "", - "type": "uint256" - } - ], - "payable": false, - "stateMutability": "view", - "type": "function" - }, - { - "constant": false, - "inputs": [ - { - "name": "_from", - "type": "address" - }, - { - "name": "_to", - "type": "address" - }, - { - "name": "_value", - "type": "uint256" - } - ], - "name": "transferFrom", - "outputs": [ - { - "name": "", - "type": "bool" - } - ], - "payable": false, - "stateMutability": "nonpayable", - "type": "function" - }, - { - "constant": true, - "inputs": [], - "name": "decimals", - "outputs": [ - { - "name": "", - "type": "uint8" - } - ], - "payable": false, - "stateMutability": "view", - "type": "function" - }, - { - "constant": true, - "inputs": [ - { - "name": "_owner", - "type": "address" - } - ], - "name": "balanceOf", - "outputs": [ - { - "name": "balance", - "type": "uint256" - } - ], - "payable": false, - "stateMutability": "view", - "type": "function" - }, - { - "constant": true, - "inputs": [], - "name": "symbol", - "outputs": [ - { - "name": "", - "type": "string" - } - ], - "payable": false, - "stateMutability": "view", - "type": "function" - }, - { - "constant": false, - "inputs": [ - { - "name": "_to", - "type": "address" - }, - { - "name": "_value", - "type": "uint256" - } - ], - "name": "transfer", - "outputs": [ - { - "name": "", - "type": "bool" - } - ], - "payable": false, - "stateMutability": "nonpayable", - "type": "function" - }, - { - "constant": true, - "inputs": [ - { - "name": "_owner", - "type": "address" - }, - { - "name": "_spender", - "type": "address" - } - ], - "name": "allowance", - "outputs": [ - { - "name": "", - "type": "uint256" - } - ], - "payable": false, - "stateMutability": "view", - "type": "function" - }, - { - "payable": true, - "stateMutability": "payable", - "type": "fallback" - }, - { - "anonymous": false, - "inputs": [ - { - "indexed": true, - "name": "owner", - "type": "address" - }, - { - "indexed": true, - "name": "spender", - "type": "address" - }, - { - "indexed": false, - "name": "value", - "type": "uint256" - } - ], - "name": "Approval", - "type": "event" - }, - { - "anonymous": false, - "inputs": [ - { - "indexed": true, - "name": "from", - "type": "address" - }, - { - "indexed": true, - "name": "to", - "type": "address" - }, - { - "indexed": false, - "name": "value", - "type": "uint256" - } - ], - "name": "Transfer", - "type": "event" - } -] -``` - -## További olvasnivaló {#further-reading} - -- [ABI specifikáció](https://solidity.readthedocs.io/en/v0.7.0/abi-spec.html) _– Solidity_ - -## Kapcsolódó témák {#related-topics} - -- [Javascript klienskönyvtárak](/developers/docs/apis/javascript/) -- [Ethereum virtuális gép](/developers/docs/evm/) diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" deleted file mode 100644 index 2e69c8ec918..00000000000 --- "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/deploying/index.md" +++ /dev/null @@ -1,81 +0,0 @@ ---- -title: Okos szerződések telepítése -description: -lang: hu ---- - -Telepítenie kell az okosszerződését azért, hogy az Ethereum hálózat felhasználói számára elérhető legyen. - -Egy okosszerződés telepítéséhez csak el kell küldenie egy Ethereum-tranzakciót, mely tartalmazza az átfordított kódot címzett megadása nélkül. - -## Előfeltételek {#prerequisites} - -Érdemes tisztában lennie az [Ethereum hálózatokkal](/developers/docs/networks/), a [tranzakciókkal](/developers/docs/transactions/) és az [okosszerződések anatómiájával](/developers/docs/smart-contracts/anatomy/) mielőtt belefog az okosszerződéstelepítésbe. - -A szerződés telepítéséért ETH-t kell fizetni, így érdemes ismernie a [gázt és a díjakat](/developers/docs/gas/) az Ethereumon. - -Végül át kell fordítani a szerződést telepítés előtt, ezért előtte tekintse meg az [okosszerződések telepítése](/developers/docs/smart-contracts/compiling/) című cikket. - -## Hogyan telepítse az okosszerződését {#how-to-deploy-a-smart-contract} - -### Mire lesz szükséged {#what-youll-need} - -- A szerződés bájtkódjára – ez az [átfordítás](/developers/docs/smart-contracts/compiling/) alatt generálódik -- ETH a gázra – meg kell adni a gázlimitet, mint bármely más tranzakciónál, de fontos tudni, hogy a szerződéstelepítés sokkal több gázt igényel, mint egy egyszerű ETH átutalás -- egy telepítőszkript vagy plugin -- hozzáférés egy [Ethereum-csomóponthoz](/developers/docs/nodes-and-clients/) a sajátja futtatásával, egy nyilvános csomóponthoz történő csatlakozással vagy egy API-kulcson keresztül egy [csomópontszolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service/) használatával - -### Az okosszerződés telepítésének lépései {#steps-to-deploy} - -A konkrét lépések az adott fejlesztői keretrendszertől függenek. Például megtekintheti a [Hardhat dokumentációt a szerződéstelepítésről](https://hardhat.org/guides/deploying.html) vagy a [Foundry dokumentációt az okosszerződések telepítéséről és ellenőrzéséről](https://book.getfoundry.sh/forge/deploying). A telepítés után a szerződésének lesz egy Ethereum-címe, ahogy a többi [számlának](/developers/docs/accounts/) is, és ez a [forráskód-ellenőrző eszközök](/developers/docs/smart-contracts/verifying/#source-code-verification-tools) segítségével lesz ellenőrizhető. - -## Kapcsolódó eszközök {#related-tools} - -**Remix – _A Remix IDE lehetővé teszi az okosszerződések fejlesztését, telepítését és kezelését az Ethereumhoz hasonló blokkláncokon_** - -- [Remix](https://remix.ethereum.org) - -**Tenderly – _Web3-fejlesztői platform, amely okosszerződés fejlesztéséhez, teszteléséhez, felügyeletéhez és működtetéséhez biztosít hibakeresési, megfigyelési és infrastruktúrához kapcsolódó építőelemeket_** - -- [tenderly.co](https://tenderly.co/) -- [Dokumentáció](https://docs.tenderly.co/) -- [GitHub](https://github.com/Tenderly) -- [Discord](https://discord.gg/eCWjuvt) - -**Hardhat – _Fejlesztői környezet Ethereum-szoftverek átfordításához, telepítéséhez, teszteléséhez és a hibakereséshez_** - -- [hardhat.org](https://hardhat.org/getting-started/) -- [Dokumentáció a szerződéstelepítésről](https://hardhat.org/guides/deploying.html) -- [GitHub](https://github.com/nomiclabs/hardhat) -- [Discord](https://discord.com/invite/TETZs2KK4k) - -**thirdweb – _Könnyű telepítés bármely szerződés esetében bármelyik EVM-kompatibilis láncra egyetlen parancssorral_** - -- [Dokumentáció](https://portal.thirdweb.com/deploy/) - -**Crossmint _– Vállalati szintű web3 fejlesztési platform okosszerződések telepítéséhez, hitelkártyás és láncok közötti fizetések lehetővé tételéhez, valamint API-ok használatára NFT-k létrehozása, terjesztése, értékesítése, tárolása és szerkesztése érdekében._** - -- [crossmint.com](https://www.crossmint.com) -- [Dokumentáció](https://docs.crossmint.com) -- [Discord](https://discord.com/invite/crossmint) -- [Blog](https://blog.crossmint.com) - -## Kapcsolódó útmutatók {#related-tutorials} - -- [Az első okosszerződés telepítése](/developers/tutorials/deploying-your-first-smart-contract/) _– Bevezetés az első okosszerződés telepítésébe egy Ethereum-teszthálózaton._ -- [Hello World | okosszerződés-útmutató](/developers/tutorials/hello-world-smart-contract/) _– Egyszerűen követhető útmutató egy alap okosszerződés létrehozásához és telepítéséhez az Ethereumon._ -- [Más szerződésekkel való interakció a Solidity által](/developers/tutorials/interact-with-other-contracts-from-solidity/) _– Hogyan telepítsen okosszerződést egy létező szerződésből és kapcsolódjon azzal._ -- [Hogyan csökkenthető a szerződés mérete](/developers/tutorials/downsizing-contracts-to-fight-the-contract-size-limit/) _– Hogyan csökkentheti a szerződés méretét, hogy a határ alatt legyen és gázt takarítson meg_ - -## További olvasnivaló {#further-reading} - -- [https://docs.openzeppelin.com/learn/deploying-and-interacting](https://docs.openzeppelin.com/learn/deploying-and-interacting) – _OpenZeppelin_ -- [Telepítse szerződéseit a Hardhat segítségével](https://hardhat.org/guides/deploying.html) – _Nomic Labs_ - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ - -## Kapcsolódó témák {#related-topics} - -- [Fejlesztői keretrendszerek](/developers/docs/frameworks/) -- [Ethereum-csomópont futtatása](/developers/docs/nodes-and-clients/run-a-node/) -- [Csomópont, mint szolgáltatás](/developers/docs/nodes-and-clients/nodes-as-a-service) diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" deleted file mode 100644 index dfcac198f89..00000000000 --- "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/index.md" +++ /dev/null @@ -1,112 +0,0 @@ ---- -title: Bevezetés az okosszerződésekbe -description: Áttekintés az okosszerződésekről, kiemelve az egyedi jellemzőiket és korlátaikat. -lang: hu ---- - -## Mi az az okosszerződés? {#what-is-a-smart-contract} - -Az „okosszerződés” egy program, mely az Ethereum blokkláncon fut. Kód (a függvényei) és adat (az állapota/státusza) gyűjteménye, mely egy bizonyos címen létezik az Ethereum blokkláncon. - -Az okosszerződés egyfajta [Ethereum-számla](/developers/docs/accounts/). Ennélfogva egyenlegük van és tranzakciók irányulhatnak feléjük. Azonban nem egy felhasználó kezeli őket, ehelyett telepítve vannak a hálózatra, és a programjuk szerint futnak. A felhasználói számlák interakcióba léphetnek az okosszerződésekkel tranzakciók indításával, melyek egy függvényt hajtanak végre az okosszerződésen. Az okosszerződések szabályokat fektethetnek le, mint egy rendes szerződés, és automatikusan betartatják azokat a kód által. Az okosszerződéseket nem lehet törölni, és a velük való interakció visszafordíthatatlan. - -## Előfeltételek {#prerequisites} - -Ha Ön most ismerkedik a témával vagy egy kevésbé technikai bevezetést keres, akkor tekintse meg a [bevezetés az okosszerződésekbe](/smart-contracts/) című cikket. - -Olvassa el a [számlákról](/developers/docs/accounts/), [tranzakciókról](/developers/docs/transactions/) és az [Ethereum virtuális gépről szóló cikkeket](/developers/docs/evm/) mielőtt belevetné magát az okosszerződések világába. - -## Egy digitális ételautomata {#a-digital-vending-machine} - -Talán a legjobb metafora az okosszerződésre egy ételautomata, ahogy azt [Nick Szabo](https://unenumerated.blogspot.com/) bemutatta. A megfelelő bemenetekkel egy bizonyos kimenet jön létre. - -Ahhoz, hogy megkapja az ételt az automatából: - -``` -pénz + nasi választás = kiadott nasi -``` - -Ez a logika be van programozva az ételautomatába. - -Az okosszerződésbe logika van programozva, akár egy ételautomatába. Egy egyszerű példa, hogyan nézne ki ez az ételautomata, ha egy okosszerződés lenne Solidity nyelven: - -```solidity -pragma solidity 0.8.7; - -contract VendingMachine { - - // A szerződés állapotváltozóinak deklarálása - address public owner; - mapping (address => uint) public cupcakeBalances; - - // Amikor a 'VendingMachine' szerződést telepítik: - // 1. beállítja a telepítő címet a szerződés tulajdonosaként - // 2. set the deployed smart contract's cupcake balance to 100 - constructor() { - owner = msg.sender; - cupcakeBalances[address(this)] = 100; - } - - // Allow the owner to increase the smart contract's cupcake balance - function refill(uint amount) public { - require(msg.sender == owner, "Only the owner can refill."); - cupcakeBalances[address(this)] += amount; - } - - // Allow anyone to purchase cupcakes - function purchase(uint amount) public payable { - require(msg.value >= amount * 1 ether, "You must pay at least 1 ETH per cupcake"); - require(cupcakeBalances[address(this)] >= amount, "Not enough cupcakes in stock to complete this purchase"); - cupcakeBalances[address(this)] -= amount; - cupcakeBalances[msg.sender] += amount; - } -} -``` - -Mint ahogy az ételautomaták szükségtelenné teszik az árusító alkalmazottat, az okosszerződések is számos iparágban leválthatják a közvetítőket. - -## Nem engedélyköteles {#permissionless} - -Bárki írhat okosszerződést és telepítheti azt a hálózatra. A szerződés telepítéséhez elég csak megtanulnia egy [okosszerződésnyelven](/developers/docs/smart-contracts/languages/) programozni, illetve a szükséges ETH-val kell rendelkeznie. Az okosszerződés telepítése lényegében egy tranzakció, így ugyanúgy ki kell fizetnie a [gázt](/developers/docs/gas/), mint egy egyszerű ETH-átutalás esetében. Ugyanakkor a szerződéstelepítés gázköltsége magasabb. - -Az Ethereum fejlesztőbarát okosszerződésnyelvekkel rendelkezik: - -- Solidity -- Vyper - -[Többet a nyelvekről](/developers/docs/smart-contracts/languages/) - -Azonban be kell őket fordítani telepítés előtt, hogy az Ethereum virtuális gép értelmezni és tárolni tudja majd a szerződést. [Többet a befordításról](/developers/docs/smart-contracts/compiling/) - -## Összeilleszthetőség {#composability} - -Az okosszerződések nyilvánosak az Ethereumon, így nyílt API-ként is tekinthetünk rájuk. Ez azt jelenti, hogy meghívhat más okosszerződéseket az Ön szerződésében, hogy nagymértékben kiterjeszthesse a lehetőségeket. A szerződések még más szerződéseket is tudnak telepíteni. - -Tudjon meg többet az [okosszerződések összeilleszthetőségről](/developers/docs/smart-contracts/composability/). - -## Korlátok {#limitations} - -Az okosszerződések önmagukban nem képesek információt lekérni a „külvilági” eseményekről, mivel nem tudnak adatot szerezni a láncon kívüli forrásokból. Tehát nem tudnak válaszolni a világ történéseire. Ez a tervezett logikájuk. A külső információkra való támaszkodás veszélyeztetheti a biztonság és a decentralizáció szempontjából fontos konszenzust. - -Ugyanakkor fontos a blokklánchoz tartozó alkalmazásoknak, hogy láncon kívüli adatokat használhassanak. A megoldás az [orákulum](/developers/docs/oracles/), amely egy olyan eszköz, ami láncon kívüli adatokat kap fel és tesz elérhetővé az okosszerződések számára. - -Az okosszerződések másik korlátja a maximális méret. Legfeljebb 24 KB méretű lehet egy okosszerződés, különben nem lesz elegendő gáz a működéséhez. Ezt meg lehet kerülni a [gyémántminta](https://eips.ethereum.org/EIPS/eip-2535) használatával. - -## Több aláírásos szerződések {#multisig} - -A több aláírásos szerződések olyan okosszerződésszámlák, amelyeknek több érvényes aláírás kell, hogy egy tranzakciót végrehajtsanak. Ez nagyon hasznos az egyetlen meghibásodási pont elkerülésére az olyan szerződéseknél, amelyek jelentős mennyiségű ethert vagy más tokent tartanak. A több aláírásos szerződések megosztják a szerződés­-végrehajtási és kulcskezelési felelősséget több fél között, és így nem kell attól tartani, hogy az egyetlen privát kulcs elveszik, és így a pénzeszközök elérhetetlenné válnak. Ebből az okból kifolyólag a több aláírásos szerződéseket egyszerű DAO irányításra is lehet használni. A több aláírásos szerződés N aláírást igényel M lehetséges elfogadható aláírásból (ahol N ≤ M, és M > 1) ahhoz, hogy végrehajtsa a tranzakciót. Gyakran használják a következő kombinációkat: `N = 3, M = 5` és `N = 4, M = 7`. A 4/7 több aláírásos szerződés négyet igényel a hét lehetséges érvényes aláírásból. Tehát a pénzeszközökhöz akkor is hozzáférnek, ha három aláírás elveszik. Ebben az esetben a kulcsokbirtokosok többségének egyet kell értenie és alá kell írnia ahhoz, hogy a szerződés végrehajtható legyen. - -## Okosszerződés-erőforrások {#smart-contract-resources} - -**OpenZeppelin Contracts –** **_Könyvtár a biztonságos okosszerződésfejlesztéshez._** - -- [openzeppelin.com/contracts/](https://openzeppelin.com/contracts/) -- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) -- [Közösségi Fórum](https://forum.openzeppelin.com/c/general/16) - -## További olvasnivaló {#further-reading} - -- [Coinbase: Mi az az okosszerződés?](https://www.coinbase.com/learn/crypto-basics/what-is-a-smart-contract) -- [Chainlink: Mi az az okosszerződés?](https://chain.link/education/smart-contracts) -- [Video: Egyszerű magyarázat: Okosszerződések](https://youtu.be/ZE2HxTmxfrI) -- [Cyfrin Updraft: Web3 tanulási és ellenőrzési platform](https://updraft.cyfrin.io) diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" deleted file mode 100644 index a2ab093066e..00000000000 --- "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/languages/index.md" +++ /dev/null @@ -1,326 +0,0 @@ ---- -title: Okosszerződés nyelvek -description: Áttekintjük és összehasonlítjuk a két fő nyelvet, a Solidity-t és a Vypert, melyen az okosszerződések készülnek. -lang: hu ---- - -Az Ethereum egyik kiváló jellemzője, hogy az okosszerződéseket viszonylag fejlesztőbarát nyelveken lehet programozni. Ha Ön járatos a Pythonban vagy bármilyen [kerek zárójeles nyelvben](https://wikipedia.org/wiki/List_of_programming_languages_by_type#Curly-bracket_languages), akkor találhat olyan nyelvet, melynek a szintaxisa ismerős lesz. - -A két legaktívabb és leginkább karbantartott nyelv: - -- Solidity -- Vyper - -A Remix IDE egy átfogó fejlesztési környezetet nyújt a szerződések létrehozásához és teszteléséhez Solidity és Vyper nyelveken. [Próbálja ki a böngészőben elérhető Remix IDE](https://remix.ethereum.org) használatát a kódoláshoz. - -A tapasztaltabb fejlesztők kipróbálhatják a Yul nyelvet, mely egy haladó nyelv az [Ethereum virtuális gépre](/developers/docs/evm/), vagy ennek kiterjesztését, melynek neve Yul+. - -Amennyiben Ön kíváncsi típus, és szeret olyan új nyelvek tesztelésében segíteni, amelyek még komoly fejlesztés előtt állnak, akkor fedezze fel a Fe-t, egy kialakulóban lévő okosszerződésnyelvet, amely még gyerekcipőben jár. - -## Előfeltételek {#prerequisites} - -A programozási nyelvek, különösen a JavaScript vagy a Python korábbi ismerete segíthet az okosszerződés nyelvekben mutatkozó különbségek értelmezésében. Javasoljuk, hogy először értse meg az okosszerződést, mint koncepciót, mielőtt túl mélyre ásna a nyelvi összehasonlításokban. [Bevezetés az okosszerződésekbe](/developers/docs/smart-contracts/). - -## Solidity {#solidity} - -- Objektumorientált, magas szintű nyelv az okosszerződések telepítésére. -- Kerek zárójeles nyelv, amelyet a leginkább a C++ befolyásolt. -- Statikusan típusos (a változó típusa ismert az átfordítási időben). -- A következőket támogatja: - - Öröklődés (kiterjeszthet más szerződéseket). - - Könyvtárak (újrafelhasználható kódot írhat, melyet meghívhat különböző szerződésekből – mint a statikus függvényeket statikus osztályokban más objektumorientált programozási nyelveken). - - Komplex, felhasználó által definiált típusok. - -### Fontos linkek {#important-links} - -- [Dokumentáció](https://docs.soliditylang.org/en/latest/) -- [Solidity Nyelvportál](https://soliditylang.org/) -- [Solidity példák alapján](https://docs.soliditylang.org/en/latest/solidity-by-example.html) -- [GitHub](https://github.com/ethereum/solidity/) -- [Solidity Gitter Chatroom](https://gitter.im/ethereum/solidity) összekötve a [Solidity Matrix Chatroom](https://matrix.to/#/#ethereum_solidity:gitter.im)-mal -- [Puska](https://reference.auditless.com/cheatsheet) -- [Solidity Blog](https://blog.soliditylang.org/) -- [Solidity Twitter](https://twitter.com/solidity_lang) - -### Példaszerződés {#example-contract} - -```solidity -// SPDX-License-Identifier: GPL-3.0 -pragma solidity >= 0.7.0; - -contract Coin { - // A "public" kulcsszó a változókat - // elérhetővé teszi más szerződések számára - address public minter; - mapping (address => uint) public balances; - - // Az események lehetővé teszik, hogy a kliensek - // általad deklarált szerződés változásokra reagáljanak - event Sent(address from, address to, uint amount); - - // A konstruktor csak a szerződés létrehozásakor - // fut le - constructor() { - minter = msg.sender; - } - - // Az újonnan létrehozott tokeneket elküldi egy címre - // Csak a szerződés létrehozó hívhatja meg - function mint(address receiver, uint amount) public { - require(msg.sender == minter); - require(amount < 1e60); - balances[receiver] += amount; - } - - // Elküld valamennyi létező tokent - // bármely hívótól egy címre - function send(address receiver, uint amount) public { - require(amount <= balances[msg.sender], "Insufficient balance."); - balances[msg.sender] -= amount; - balances[receiver] += amount; - emit Sent(msg.sender, receiver, amount); - } -} -``` - -Ez a példa azt mutathatja meg Önnek, hogyan néz ki a Solidity szerződés szintaxisa. A függvények és a változók részletesebb leírásáért [tekintse meg a dokumentációt](https://docs.soliditylang.org/en/latest/contracts.html). - -## Vyper {#vyper} - -- Pythonikus programozási nyelv -- Erősen típusos -- Kicsi és érthető fordító kód -- Hatékony bájtkód-generálás -- Szándékosan kevesebb elemmel rendelkezik, mint a Solidity, azzal a céllal, hogy a szerződések biztonságosabbak és könnyebben auditálhatóak legyenek. A Vyper nem támogatja a következőket: - - Módosítókat (modifier) - - Öröklést - - Soron belüli assembly - - Függvénytúlterhelés - - Operátortúlterhelés - - Rekurzív hívás - - Végtelen hosszú ciklusok - - Bináris fix pontok - -További információkért [tekintse meg a Vyper magyarázatát](https://vyper.readthedocs.io/en/latest/index.html). - -### Fontos linkek {#important-links-1} - -- [Dokumentáció](https://vyper.readthedocs.io) -- [Vyper példa alapján](https://vyper.readthedocs.io/en/latest/vyper-by-example.html) -- [Még több Vyper példák alapján](https://vyper-by-example.org/) -- [GitHub](https://github.com/vyperlang/vyper) -- [A Vyper-közösség Discord-csevegése](https://discord.gg/SdvKC79cJk) -- [Cheat Sheet](https://reference.auditless.com/cheatsheet) -- [Okosszerződés-fejlesztési keretrendszerek és eszközök Vyperre](/developers/docs/programming-languages/python/) -- [VyperPunk – tanulja meg a Vyper okosszerződéseket biztosítását és meghackelését](https://github.com/SupremacyTeam/VyperPunk) -- [VyperExamples – Példák a Vyper sebezhetőségére](https://www.vyperexamples.com/reentrancy) -- [Vyper Hub fejlesztéshez](https://github.com/zcor/vyper-dev) -- [Példák a Vyper legjobb okosszerződéseire](https://github.com/pynchmeister/vyper-greatest-hits/tree/main/contracts) -- [A Vyper által gondozott kiváló források](https://github.com/spadebuilders/awesome-vyper) - -### Példa {#example} - -```python -# Nyílt Aukció - -# Aukció paraméterek -# A kedvezményezett pénzt kap a legnagyobb licitálótól -beneficiary: public(address) -auctionStart: public(uint256) -auctionEnd: public(uint256) - -# Az aukció jelenlegi állapota -highestBidder: public(address) -highestBid: public(uint256) - -# Legyen igaz a végén, bármely változást elutasít -ended: public(bool) - -# Számontartja a visszafizetett liciteket, így követni tudjuk a kiutalási mintát -pendingReturns: public(HashMap[address, uint256]) - -# Egy egyszerű aukció létrehozása `_bidding_time` -# másodpercnyi licit idővel a kedvezményezett cím -# `_beneficiary` nevében. -@external -def __init__(_beneficiary: address, _bidding_time: uint256): - self.beneficiary = _beneficiary - self.auctionStart = block.timestamp - self.auctionEnd = self.auctionStart + _bidding_time - -# Licitálás az aukción -# a tranzakcióval küldött értékkel. -# Az érték csak akkor kerül visszautalásra -# ha az aukció nincs megnyerve. -@external -@payable -def bid(): - # Ellenőrzi, hogy a licit idő véget ért-e már. - assert block.timestamp < self.auctionEnd - # Ellenőrzi, hogy elég magas-e a licit - assert msg.value > self.highestBid - # Nyomonköveti az előző legmagasabb licit visszatérítését - self.pendingReturns[self.highestBidder] += self.highestBid - # Nyomonköveti a legmagasabb licitet - self.highestBidder = msg.sender - self.highestBid = msg.value - -# Kiutalja az előzőleg visszatérített licitet. A kiutalási mintát használjuk itt, -# hogy elkerüljünk egy biztonsági rést. Ha a visszatérítés közvetlenül -# a bid() része lenne, egy ártalmas licit szerződés blokkolhatná -# ezeket a visszatérítéseket, így blokkolná a magasabb bejövő liciteket. -@external -def withdraw(): - pending_amount: uint256 = self.pendingReturns[msg.sender] - self.pendingReturns[msg.sender] = 0 - send(msg.sender, pending_amount) - -# Vége az aukciónak és elküldi a legmagasabb licitet -# a kedvezményezettnek. -@external -def endAuction(): - # It is a good guideline to structure functions that interact - # 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) - # 3. interakció más szerződésekkel - # Ha ezt a sorrendet felcseréljük, akkor más szerződés visszahívhat - # a jelenlegi szerződésbe és módosíthatja az állapotot vagy - # többszörösen elvégzett műveletet eredményezhet (ether kifizetés). - # Ha a belsőleg meghívott függvény külső szerződéssel történő - # interakciót tartalmaz, akkor azokat is külső szerződéssel történő - # interakcióként kell kezelni. - - # 1. Feltételek - # Ellenőrzi, hogy elértük-e az aukció végét - assert block.timestamp >= self.auctionEnd - # Ellenőrzi, hogy függvény meg lett-e már hívva - assert not self.ended - - # 2. Hatások - self.ended = True - - # 3. Interakció - send(self.beneficiary, self.highestBid) -``` - -Ez a példa megmutathatja Önnek, hogyan néz ki a Vyper szerződés szintaxisa. A függvények és a változók részletesebb leírásáért [tekintse meg a dokumentációt](https://vyper.readthedocs.io/en/latest/vyper-by-example.html#simple-open-auction). - -## Yul és Yul+ {#yul} - -Ha Önnek új az Ethereum és nem programozott okosszerződésnyelveken, akkor azt javasoljuk, hogy kezdjen először a Solidity-vel és a Vyperrel. Csak akkor kezdjen bele a Yul vagy Yul+ nyelvekbe, ha már ismeri az okosszerződésre vonatkozó biztonsági gyakorlatokat és az EVM-mel kapcsolatos munka részleteit. - -**Yul** - -- Haladó nyelv Ethereumra. -- Támogatja az [EVM-et](/developers/docs/evm) és az [Ewasm-ot](https://github.com/ewasm), amely egy Ethereummal fűszerezett WebAssembly, és amelyet a két platform közös nevezőjének terveztek. -- Jó cél a magas szintű optimizációs szinteknek, melyek az EVM és Ewasm platformokból egyaránt tudnak profitálni. - -**Yul+** - -- A Yul alacsony szintű, nagy hatékonyságú kiterjesztése. -- Eredetileg az [optimista összesítéses](/developers/docs/scaling/optimistic-rollups/) szerződésként fejlesztették ki. -- A Yul+ egy kísérleti fejlesztési javaslatként is tekinthető, melyhez új funkciók tartoznak. - -### Fontos linkek {#important-links-2} - -- [Yul Dokumentáció](https://docs.soliditylang.org/en/latest/yul.html) -- [Yul+ Dokumentáció](https://github.com/fuellabs/yulp) -- [Yul+ Játszótér](https://yulp.fuel.sh/) -- [Yul+ Bevezető poszt](https://medium.com/@fuellabs/introducing-yul-a-new-low-level-language-for-ethereum-aa64ce89512f) - -### Példa szerződés {#example-contract-2} - -Az alábbi egyszerű példa egy hatványfüggvényt implementál. A `solc --strict-assembly --bin input.yul` használatával lehet befordítani. Ezt a példát az input.yul fájlnak kell tartalmaznia. - -``` -{ - function power(base, exponent) -> result - { - switch exponent - case 0 { result := 1 } - case 1 { result := base } - default - { - result := power(mul(base, base), div(exponent, 2)) - if mod(exponent, 2) { result := mul(base, result) } - } - } - let res := power(calldataload(0), calldataload(32)) - mstore(0, res) - return(0, 32) -} -``` - -Ha már nagy tapasztalatra tett szert az okosszerződésekkel kapcsolatban, akkor a teljes ERC20 implementáció Yul-ban [itt érhető el](https://solidity.readthedocs.io/en/latest/yul.html#complete-erc20-example). - -## Fe {#fe} - -- Statikusan típusos nyelv az Ethereum virtuális géphez (EVM). -- A Python és a Rust inspirálta. -- Lényege, hogy könnyen tanulható, még azoknak a fejlesztőknek is, akiknek új az Ethereum ökoszisztémája. -- A Fe fejlesztése még nagyon korai szakaszban tart, az alfa kiadása 2021. januárban történt. - -### Fontos linkek {#important-links-3} - -- [GitHub](https://github.com/ethereum/fe) -- [Fe bejelentés](https://snakecharmers.ethereum.org/fe-a-new-language-for-the-ethereum-ecosystem/) -- [Fe 2021-es ütemterv](https://notes.ethereum.org/LVhaTF30SJOpkbG1iVw1jg) -- [Fe Discord-csevegés](https://discord.com/invite/ywpkAXFjZH) -- [Fe Twitter](https://twitter.com/official_fe) - -### Példa szerződés {#example-contract-3} - -Ez a példa egy egyszerű szerződés Fe nyelven telepítve. - -``` -type BookMsg = bytes[100] - -contract GuestBook: - pub guest_book: map - - event Signed: - book_msg: BookMsg - - pub def sign(book_msg: BookMsg): - self.guest_book[msg.sender] = book_msg - - emit Signed(book_msg=book_msg) - - pub def get_msg(addr: address) -> BookMsg: - return self.guest_book[addr].to_mem() - -``` - -## Hogyan válasszunk {#how-to-choose} - -Mint minden más programozási nyelvnél, itt is leginkább a megfelelő eszköz kiválasztása a megfelelő munkához, valamint a személyes preferenciák döntenek. - -Íme néhány szempont, amelyet érdemes figyelembe venni, ha még nem próbálta egyik nyelvet sem: - -### Mi a jó a Solidity-ben? {#solidity-advantages} - -- A kezdőknek sok útmutató és tanulási anyag áll rendelkezésükre. További anyagért látogasson el a [Tanulás kódolással](/developers/learning-tools/) című részhez. -- Remek fejlesztői eszközök érhetők el. -- A Solidity-nek kiterjedt a fejlesztői közössége, ami azt jelenti, hogy nagy valószínűséggel gyorsan választ kap a kérdéseire. - -### Mi a jó a Vyperben? {#vyper-advatages} - -- Nagyszerű módszer a Python fejlesztők számára az első okosszerződések megírására. -- A Vyper kevesebb funkcióval rendelkezik, így kiválóan alkalmas arra, hogy az ötleteiből gyorsan prototípust készítsen. -- A Vyper célja, hogy könnyen auditálható és az emberek számára olvasható legyen. - -### Mi a jó a Yul és a Yul+ nyelvekben? {#yul-advantages} - -- Egyszerűsített és funkcionális alacsony szintű nyelv. -- Közelebb enged a nyers EVM-hez, így Ön könnyebben tudja a szerződések gázfelhasználását optimalizálni. - -## Nyelv-összehasonlítások {#language-comparisons} - -Az alapvető szintaxis, szerződés-életciklus, interfészek, operátorok, adatszerkezetek, függvények, control flow és további szempontok alapján történő összehasonlításért olvassa el a [Puska az Auditless-től](https://reference.auditless.com/cheatsheet/) című cikket - -## További olvasnivaló {#further-reading} - -- [Solidity szerződéskönyvtár az OpenZeppelintől](https://docs.openzeppelin.com/contracts) -- [Solidity egy példa alapján](https://solidity-by-example.org) diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" deleted file mode 100644 index 49dabb58139..00000000000 --- "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/libraries/index.md" +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: Okosszerződés könyvtárak -description: -lang: hu ---- - -Nem kell minden okosszerződést a nulláról megírni. Számos nyílt forráskódú okosszerződés könyvtár áll rendelkezésedre, amelyek újrafelhasználható építőelemeket kínálnak a projektedhez, így megkímélnek attól, hogy újra fel kelljen találni a kereket. - -## Előfeltételek {#prerequisites} - -Mielőtt belevetnéd magad az okosszerződés könyvtárakba, érdemes tisztában lenned az okosszerződések felépítésével. Irány az [okosszerződés anatómia](/developers/docs/smart-contracts/anatomy/) cikk, ha még nem olvastad el. - -## Mi van egy könyvtárban {#whats-in-a-library} - -Az okosszerződés könyvtárakban általában kétféle építőelem található: újrafelhasználható eljárások, amelyeket hozzáadhatsz a szerződéseidhez, valamint különféle szabványok megvalósítása. - -### Eljárások {#behaviors} - -Okosszerződés írás közben jó esély van rá, hogy újra és újra hasonló minták megírásán találod magad, mint például hozzárendelsz egy _admin_ címet védett operációk véghezviteléhez, vagy egy vészeseti _szünet_ gombot adsz hozzá egy váratlan esemény miatt. - -Az okosszerződéses könyvtárak általában ezeknek a viselkedéseknek az újrafelhasználható megvalósítását biztosítják [könyvtárakon](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#libraries) vagy [öröklésen keresztül](https://solidity.readthedocs.io/en/v0.7.2/contracts.html#inheritance) Solidity-ben. - -Példaként az alábbiakban bemutatjuk az [`Ownable` szerződés](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.2.0/contracts/access/Ownable.sol) egyszerűsített verzióját az [OpenZeppelin Szerződés könyvtárból](https://github.com/OpenZeppelin/openzeppelin-contracts), mely egy címet jelöl ki tulajdonosként a szerződésben, és egy módosítóval lekorlátozza az adott metódus hozzáférését az adott tulajdonosra. - -```solidity -contract Ownable { - address public owner; - - constructor() internal { - owner = msg.sender; - } - - modifier onlyOwner() { - require(owner == msg.sender, "Ownable: caller is not the owner"); - _; - } -} -``` - -Egy ehhez hasonló építőelem használatához a szerződésedben, először be kell importálnod, majd kiterjesztened belőle a szerződéseidet. Ez lehetővé teszi az `Ownable` szerződés által biztosított módosító használatát, hogy bebiztosítsd a saját függvényeidet. - -```solidity -import ".../Ownable.sol"; // Az importált könyvtár útvonala - -contract MyContract is Ownable { - // Az alábbi függvényt csak a tulajdonos hívhatja meg - function secured() onlyOwner public { - msg.sender.transfer(1 ether); - } -} -``` - -Egy másik népszerű példa a [SafeMath](https://docs.openzeppelin.com/contracts/3.x/utilities#math) vagy a [DsMath](https://dappsys.readthedocs.io/en/latest/ds_math.html). Ezek olyan könyvtárak (szemben az alapszerződésekkel), amelyek számtani függvényeket biztosítanak túlcsordulás-ellenőrzésekkel, amelyeket a nyelv nem biztosít. Jó gyakorlat ezeknek a könyvtáraknak az alkalmazása a natív számtani műveletek helyett, hogy megvédd a szerződésed a túlcsordulástól, amelynek katasztrofális következményei lehetnek! - -### Szabványok {#standards} - -Hogy elősegítsük az [összeilleszthetőséget és az interoperabilitást](/developers/docs/smart-contracts/composability/), az Ethereum közösség számos szabványt vezetett be **ERC-k** formájában. Többet olvashatsz róluk a [szabványok](/developers/docs/standards/) részben. - -Amikor egy ERC-t szeretne betenni a szerződésbe, célszerű sztenderd megvalósításokat keresni ahelyett, hogy megpróbálná a sajátját bevezetni. Számos okosszerződés könyvtár tartalmazza a legnépszerűbb ERC-k megvalósításait. Például a mindenütt jelen levő [ERC20 felcserélhető tokenszabvány](/developers/tutorials/understand-the-erc-20-token-smart-contract/) megtalálható a [HQ20](https://github.com/HQ20/contracts/blob/master/contracts/token/README.md), [DappSys](https://github.com/dapphub/ds-token/) és [OpenZeppelin](https://docs.openzeppelin.com/contracts/3.x/erc20) platformon. Ezenkívül, egyes ERC-k kanonikus megvalósításokat is biztosítanak az ERC részeként. - -Érdemes megemlíteni, hogy egyes ERC-k nem önállóak, hanem kiegészítenek más ERC-ket. Például az [ERC2612](https://eips.ethereum.org/EIPS/eip-2612) kiterjeszti az ERC20-as szabványt a használhatóság javítása érdekében. - -## Hogyan lehet könyvtárt hozzáadni {#how-to} - -Mindig nézd át a könyvtár dokumentációját, amit használsz a projektedben specifikus instrukciókért arról, hogyan kell használni. Számos Solidity szerződés könyvtár az `npm` használatával van csomagolva, így elég csak `npm install` módon telepíteni őket. A legtöbb szerződés [fordító](/developers/docs/smart-contracts/compiling/) eszköz végig nézi a `node_modules` mappát okosszerződés könyvtárak után kutatva, így megteheted a következőt: - -```solidity -// Ez betölti az @openzeppelin/contracts könyvtárat a node_modules könyvtárból -import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; - -contract MyNFT is ERC721 { - constructor() ERC721("MyNFT", "MNFT") public { } -} -``` - -Az általad használt módszertől függetlenül, ha könyvtárat importálsz be, mindig ellenőrizd le a [nyelv](/developers/docs/smart-contracts/languages/) verziót. Például nem használhatsz könyvtárat a Solidity 0.6-hoz, ha a szerződéseidet a Solidity 0.5-ben írod. - -## Mikor használjuk {#when-to-use} - -Egy okosszerződés könyvtár használatának számos előnye van. Először is, időt takarít meg azzal, hogy használatra kész építőelemeket biztosít, amelyeket beépíthetsz a rendszeredbe, ahelyett, hogy saját magadnak kellene leprogramozni őket. - -A biztonság is egy fontos pozitívum. A nyílt forráskódú okosszerződés könyvtárakat gyakran alaposan megvizsgálják. Tekintettel arra, hogy sok projekt függ tőlük, a közösségnek erős ösztönzője van arra, hogy folyamatosan felülvizsgálja őket. Sokkal gyakrabban lehet hibákat találni az alkalmazáskódban, mint az újrafelhasználható szerződés könyvtárakban. Némely könyvtár [külső auditnak](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits) veti alá magát magasabb fokú biztonságért. - -Az okosszerződés könyvtárak használata azonban azt a kockázatot hordozza magával, hogy számodra ismeretlen kódot veszel fel a projektbe. Csábító egy szerződést importálni és közvetlenül beilleszteni a projektbe, de anélkül, hogy megértenéd, hogy ez a szerződés mit csinál pontosan, véletlenül bevihetsz egy hibát a rendszerbe egy váratlan viselkedésből kifolyólag. Mindig feltétlenül olvasd el az importált kód dokumentációját, majd nézd át magát a kódot, mielőtt a projekt részévé tennéd! - -Végül, amikor eldöntöd, hogy felveszel-e egy könyvtárat, vedd figyelembe annak általános használatát. Egy széles körben elfogadott szerződés előnye, hogy nagyobb a közössége, és többen tudnak foglalkozni a problémákkal. A biztonság legyen az elsődleges szempont okosszerződés fejlesztéskor! - -## Kapcsolódó eszközök {#related-tools} - -**OpenZeppelin Contracts -** **_A legnépszerűbb könyvtár biztonságos okosszerződés fejlesztéshez._** - -- [Dokumentáció](https://docs.openzeppelin.com/contracts/) -- [GitHub](https://github.com/OpenZeppelin/openzeppelin-contracts) -- [Közösségi Fórum](https://forum.openzeppelin.com/c/general/16) - -**DappSys -** **_Biztonságos, egyszerű, flexibilis okosszerződés építőelemek._** - -- [Dokumentáció](https://dappsys.readthedocs.io/) -- [GitHub](https://github.com/dapphub/dappsys) - -**HQ20 -** **_Egy Solidity projekt szerződésekkel, könyvtárakkal és példákkal, melyek segítenek teljesértékű alkalmazásokat fejleszteni a külvilágnak_** - -- [GitHub](https://github.com/HQ20/contracts) - -**thirdweb Solidity SDK –** **_Olyan eszközöket biztosít, melyekkel hatékonyan lehet személyre szabott okosszerződéseket létrehozni_** - -- [Dokumentáció](https://portal.thirdweb.com/solidity/) -- [GitHub](https://github.com/thirdweb-dev/contracts) - -## Kapcsolódó útmutatók {#related-tutorials} - -- [Security considerations for Ethereum developers](/developers/docs/smart-contracts/security/) _– Egy biztonsági megfontolásokról szóló útmutató okosszerződés-fejlesztéshez könyvtárhasználattal._ -- [Az ERC-20 tokenes okosszerződés megértése](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _-Útmutató az ERC20 szabványról több könyvtáron keresztül._ - -## További olvasnivaló {#further-reading} - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ diff --git "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" "b/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" deleted file mode 100644 index 5e0e193f707..00000000000 --- "a/public/content/translations/hu/19) Smart Contracts \342\200\223 Basics/developers/docs/smart-contracts/security/index.md" +++ /dev/null @@ -1,580 +0,0 @@ ---- -title: Okosszerződés biztonság -description: Útmutató a biztonságos Ethereum-okosszerződések építéséhez -lang: hu ---- - -Az okosszerződések rendkívüli módon rugalmasak és képesek nagy mennyiségű értéket és adatot irányítani, miközben egy megváltoztathatatlan logika alapján, a blokkláncra telepített kód szerint futnak. Ezáltal létrejött a bizalmat nem igénylő és decentralizált alkalmazások élénk ökoszisztémája, mely számos előnyt kínál a hagyományos rendszerekkel szemben. Emellett lehetőséget is jelentenek a támadók számára, akik abból akarnak nyereséget szerezni, hogy kihasználják az okosszerződések gyenge pontjait. - -A nyilvános blokkláncok, mint az Ethereum, tovább bonyolítják az okosszerződések biztosításának problémáját. A telepített szerződéskód _általában_ nem módosítható, hogy ezzel a biztonsági kockázatokat elkerüljék, eközben az okosszerződésekből ellopott eszközöket rendkívül nehéz lekövetni és a legtöbb esetben visszaszerezhetetlenek a megváltoztathatatlanság miatt. - -Bár a számok változnak, de úgy becsülik, hogy a biztonsági hibák miatt az okosszerződésből ellopott vagy onnan elvesztett értékek teljes összege könnyen meghaladhatja az 1 milliárd dollárt is. Ez magába foglal olyan nagy horderejű incidenseket is, mint amilyen a [DAO-hackelés volt](https://hackingdistributed.com/2016/06/18/analysis-of-the-dao-exploit/) (3,6 millió ETH-t loptak, ami meghaladja az 1 milliárd dollárt mai áron), [Parity több aláírásos tárca hackelését](https://www.coindesk.com/30-million-ether-reported-stolen-parity-wallet-breach) (30 millió USD-t veszett el), és a [Parity befagyasztott tárcaproblémát](https://www.theguardian.com/technology/2017/nov/08/cryptocurrency-300m-dollars-stolen-bug-ether) (300 millió USD-nyi ETH örökre elérhetetlenné vált). - -Ezek az esetek kötelezővé teszik a fejlesztők számára, hogy folyamatosan azon dolgozzanak, hogy az okosszerződések biztonságosak, robusztusak és ellenállók legyenek. Az okosszerződésbiztonság komoly téma, melyet minden fejlesztőnek a maga érdekében meg kell ismerni. Ez az útmutató lefedi azokat a biztonsági megfontolásokat, amelyek az Ethereum-fejlesztőknek fontosak, és forrásokat tár fel az okosszerződésbiztonság továbbfejlesztésére. - -## Előfeltételek {#prerequisites} - -Tisztában kell lennie az [okosszerződés-fejlesztés alapjaival](/developers/docs/smart-contracts/), mielőtt a biztonsági kérdésekkel foglalkozna. - -## Iránymutatások a biztonságos Ethereum-okosszerződések építéséhez {#smart-contract-security-guidelines} - -### 1. Tervezzen megfelelő hozzáférés-szabályozást {#design-proper-access-controls} - -Az okosszerződésekben a `public` (publikus) vagy `external` (külső) jelölésű függvényeket bármelyik külső tulajdonú számla (EOA) vagy szerződésszámla meghívhatja. A függvényeket szükséges nyilvánossá tenni, ha Ön azt akarja, hogy mások interakcióba lépjenek a szerződésével. A `private` (privát) jelölésű függvényeket csak az okosszerződésen belüli függvények hívhatják meg, külső számlák nem. Problémás lehet az összes hálózati résztvevőnek hozzáférést adni bizonyos szerződésfüggvényekhez, főleg ha így bárki végrehajthat fontos műveleteket (pl. új tokenek kibocsátása). - -Ahhoz, hogy megakadályozzuk az okosszerződés függvényeinek nem hitelesített használatát, biztonságos hozzáférés-szabályozásra van szükség. A hozzáférés-szabályozás mechanizmusai az okosszerződés bizonyos függvényeinek használatát a jóváhagyott entitások csoportjára, például a szerződés kezeléséért felelős számlákra korlátozzák. A **tulajdonosi minta** és a **szerepalapú irányítás** két hasznos minta az okosszerződésben beállítható hozzáférés-szabályozásra: - -#### Tulajdonosi minta (ownable pattern) {#ownable-pattern} - -A tulajdonosi mintában beállítható egy cím, mint a szerződés „tulajdonosa” a szerződés létrehozása folyamán. A védett függvényekhez hozzárendelnek egy `OnlyOwner`-módosítót, így a szerződés azonosítani fogja az identitását a hívást végző címnek, mielőtt végrehajtaná a függvényt. A védett függvények meghívását csak akkor engedi, ha az a szerződés tulajdonosának címéről érkezik, különben elveti azt, megakadályozva az akaratlan hozzáférést. - -#### Szerepalapú hozzáférés-szabályozás {#role-based-access-control} - -Ha az okosszerződésben egyetlen címet regisztrálnak, mint `Owner` (tulajdonos), az a centralizáció kockázatát hordozza és felmerül az egyetlen meghibásodási pont lehetősége. Ha a tulajdonos számlakulcsa nyilvánossá válik, akkor a támadók hozzáférhetnek ehhez a tulajdonolt szerződéshez. Emiatt jobb opció lehet a szerepalapú hozzáférés-szabályozás mintája, ahol több adminisztratív számla van. - -A szerepalapú hozzáférés-szabályozásban a fontos függvényekhez való hozzáférést elosztják a megbízott résztvevők között. Például az egyik számla felel a tokenek kibocsátásáért, miközben egy másik számla frissítéseket végez vagy megállítja a szerződést. A decentralizált hozzáférés-szabályozás ily módon kivédi az egyetlen meghibásodási pont lehetőségét és csökkenti a felhasználók részéről igényelt bizalmat. - -##### Több aláírásos tárca használata - -A biztonságos hozzáférés-szabályozásra egy másik megközelítés a [több aláírásos számla](/developers/docs/smart-contracts/#multisig) használata, ami a szerződést kezeli. Az általános külső tulajdonú számlához (EOA) képest a több aláírásos számlákat több entitás birtokolja, és a tranzakciók végrehajtásához egy adott számú aláírásra van szükség, például 5-ből 3-ra. - -Ennek használata egy újabb biztonsági réteget vezet be, mivel a szerződésen végrehajtandó akciókba több félnek is bele kell egyeznie. Ez különösen hasznos, ha a tulajdonosi mintát (ownable pattern) kell használni, mert még nehezebb a támadó vagy egy rosszhiszemű belső fél számára, hogy rossz célokra használja fel a fontos szerződésfüggvényeket. - -### 2. Használja a require(), assert() és revert() parancsokat, hogy óvja a szerződés működését {#use-require-assert-revert} - -Amint az okosszerződés telepítésre kerül a blokkláncon, bárki meg tudja hívni a benne lévő publikus függvényeket. Mivel nem lehet tudni előre, hogy a külső tulajdonú számlák hogyan fognak interakciókat folytatni a szerződéssel, ezért ideális esetben belső óvintézkedéseket kell tenni a problémás működésekkel kapcsolatban a telepítés előtt. Az okosszerződésben elő lehet írni a megfelelő viselkedést a `require()`, `assert()` és `revert()` parancsokkal, hogy ha bizonyos feltételek nem teljesülnek, akkor leálljon és visszaforgassa a változásokat. - -**`require()`**: a `require` (szükséges) parancsot a függvények elején kell meghatározni, és biztosítja, hogy a megadott feltételek teljesülnek, mielőtt a függvény végrehajtásra kerül. A `require` parancs révén validálni lehet a felhasználó által adott adatokat, ellenőrizhetők az állapotváltozók, vagy hitelesíteni lehet a meghívó számla identitását, mielőtt a függvény elindulna. - -**`assert()`**: az `assert()` (állítás) parancsot a belső hibák felderítésére használják, illetve a kódban lévő „konstansok” megsértését ellenőrzik ezáltal. A konstans egy logikai állítás a szerződés státuszáról, amelynek teljesülnie kell minden függvénymeghívás esetén. Például egy tokenszerződés maximális teljes kínálata vagy egyenlege. Az `assert()` használata biztosítja, hogy a szerződés nem kerül sebezhető státuszba, és ha mégis, akkor az állapotváltozók visszaállnak a korábbi értékekre. - -**`revert()`**: a `revert()` (visszatér) kódot egy if-else parancsban használhatjuk, ami egy kivételt ad, ha a szükséges feltételek nem teljesülnek. Az alábbi példaszerződés a `revert()` kódot arra használja, hogy védje a függvények végrehajtását: - -``` -pragma solidity ^0.8.4; - -contract VendingMachine { - address owner; - error Unauthorized(); - function buy(uint amount) public payable { - if (amount > msg.value / 2 ether) - revert("Not enough Ether provided."); - // Perform the purchase. - } - function withdraw() public { - if (msg.sender != owner) - revert Unauthorized(); - - payable(msg.sender).transfer(address(this).balance); - } -} -``` - -### 3. Tesztelje az okosszerződéseket és ellenőrizze a kód helyességét {#test-smart-contracts-and-verify-code-correctness} - -Az [Ethereum virtuális gépen](/developers/docs/evm/) érvényes kódváltoztathatatlanság miatt az okosszerződéseknél jelentős minőség-ellenőrzésre van szükség a fejlesztési időszakban. Tesztelje szerződését kiterjedt módon, és figyelje meg, hogy kap-e váratlan eredményeket, így fejlesztheti a biztonságot és megvédheti a felhasználókat hosszú távon is. - -Ennek megszokott módja, hogy kicsi egységteszteket ír tesztadattal, melyet a szerződés a felhasználóktól kapna. Az [egységtesztelés](/developers/docs/smart-contracts/testing/#unit-testing) arra jó, hogy bizonyos függvények működését kipróbálja, és így biztosítja, hogy az okosszerződés az elvárt módon működik. - -Sajnos az egységtesztelés minimálisan növeli az okosszerződés biztonságát, ha azt izolációban használják. Az egységteszt megmutathatja, hogy egy függvény megfelelően működik-e a tesztadatokra, de csak annyira hatásos, amennyire jó tesztet írnak hozzá. Nehéz beazonosítani a kimaradt eseteket és sebezhetőségeket, amelyek kompromittálhatják az okosszerződés biztonságát. - -Jobb megközelítés az egységtesztelés tulajdonságalapú teszteléssel (property-based testing) való kombinálása, amely [statikus és dinamikus elemzést](/developers/docs/smart-contracts/testing/#static-dynamic-analysis) használ. A statikus elemzés olyan alacsony szintű reprezentációkon alapul, mint amilyen a [kontrollfolyamat-grafikon](https://en.wikipedia.org/wiki/Control-flow_graph) és az [absztrakt szintaxisfák](https://deepsource.io/glossary/ast/), hogy elemezze az elérhető programstátuszokat és végrehajtási utakat. A dinamikus elemzési technikák, mint az [okosszerződés fuzzing](https://www.cyfrin.io/blog/smart-contract-fuzzing-and-invariants-testing-foundry), a szerződéskódot véletlenszerű értékekkel hajtják végre, hogy feltárják azokat a működéseket, amelyek nem felelnek meg a biztonsági tulajdonságoknak. - -A [formális ellenőrzés (formal verification)](/developers/docs/smart-contracts/formal-verification) egy másik technika az okosszerződések biztonsági tulajdonságainak igazolására. A megszokott teszteléshez képest a formális ellenőrzés képes egyértelműen bizonyítani, hogy nincsenek hibák az okosszerződésben. Ezt úgy éri el, hogy egy formális specifikációt hoz létre, amely a kívánt biztonsági tulajdonságokat rögzíti, majd bizonyítja, hogy a szerződések formális modellje megfelel ennek a specifikációnak. - -### 4. Kérjen egy független átvizsgálást a kódjára {#get-independent-code-reviews} - -Miután tesztelte a szerződését, kérjen meg másokat is, hogy ellenőrizzék le a kódot a lehetséges biztonsági problémák szempontjából. A tesztelés nem tárja fel az okosszerződés minden hibáját, de egy független vizsgálat megnöveli annak valószínűségét, hogy kiderülnek a sebezhető pontok. - -#### Auditok {#audits} - -Az okosszerződés auditálása az egyik módja a független kódvizsgálatnak. Az auditorok fontos szerepet játszanak abban, hogy az okosszerződések biztonságosak legyenek és ne legyenek bennük minőségi és tervezési hibák. - -Mindazonáltal fontos megjegyezni, hogy az audit nem old meg minden problémát. Az okosszerződés-auditok nem tárnak fel minden egyes hibát, és a terv általában egy második körös ellenőrzés, hogy azokat a problémákat kiszúrja, ami a fejlesztőknek nem vált világossá a fejlesztés és tesztelés során. Kövesse a bevált gyakorlatokat az auditorokkal való munka kapcsán, mint amilyen a kód megfelelő dokumentálása és a sorokhoz kapcsolt kommentek, amelyek révén az okosszerződés-auditból a lehető legtöbb előnyt ki lehet hozni. - -- [Okosszerződés auditáláshoz tippek és trükkök](https://twitter.com/tinchoabbate/status/1400170232904400897) - _@tinchoabbate_ -- [Hozza ki a legtöbbet az auditból](https://inference.ag/blog/2023-08-14-tips/) - _Inference_ - -#### Hibavadászatok {#bug-bounties} - -Egy másik megoldás lehet a hibavadászat-program felállítása, amellyel külsődleges kódvizsgálatot lehet végezni. A hibavadászat pénzügyi jutalommal jár olyan egyéneknek (általában fehérkalapos hackereknek), akik sebezhető pontokat fedeznek fel az alkalmazásban. - -Ez a jutalom a hibavadászatért, ha megfelelően használják, kellő motivációt jelenthet a hackerközösség bizonyos tagjai számára, hogy átnézzék az Ön kódját is kritikus hibákat keresve. Valós példa lehet a „végtelen mennyiségű pénz hiba”, ami egy támadónak lehetővé teszi, hogy határtalan mennyiségű ethert hozzon létre az [Optimism-mal](https://www.optimism.io/), egy [második blokkláncréteg (L2)](/layer-2/) protokollal az Ethereumon. Szerencsére egy fehérkalapos hacker [felfedezte a hibát](https://www.saurik.com/optimism.html) és értesítette a csapatot, [amelyet jelentős pénzösszeggel jutalmaztak](https://cryptoslate.com/critical-bug-in-ethereum-l2-optimism-2m-bounty-paid/). - -Hasznos stratégia lehet, ha a kifizetés összegét arányosan kezelik a hiba által veszélybe kerülő pénzeszközök értékével. Ezt „[skálázódó hibavadászatnak](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7)” is nevezhetjük, ami pénzügyi motivációt ad az egyéneknek, hogy inkább feltárják a gyenge pontokat és ne kihasználják azokat. - -### 5. Kövesse a bevált gyakorlatokat az okosszerződésfejlesztés során {#follow-smart-contract-development-best-practices} - -Az auditok és hibavadászatok nem csökkentik az Ön felelősségét, hogy jó minőségű kódot írjon. A megfelelő okosszerződés-biztonság azzal kezdődik, hogy megfelelő tervezési és fejlesztési folyamatokat követ: - -- Tárolja az összes kódot egy verziókövető rendszerben, mint amilyen a git - -- Minden kódmódosítást pull requesteken (változtatási kérelem) keresztül végezzen - -- A pull requesteknek legalább egy független ellenőrzője legyen – ha Ön egyedül dolgozik egy projekten, akkor fontolja meg, hogy más fejlesztőkkel összefogva elvégzik egymás számára a kódellenőrzéseket - -- Használjon [fejlesztői környezetet](/developers/docs/frameworks/) az okosszerződések tesztelésére, átfordítására és telepítésére - -- Futtassa le a kódját olyan alapvető kódelemző eszközökön, mint a [Cyfrin Aaderyn](https://github.com/Cyfrin/aderyn), Mythril és Slither. Ideális esetben ezt minden egyes pullrequest-beolvasztás előtt meg kell tenni, majd összehasonlítani az eredmények különbségeit - -- Biztosítsa, hogy a kód hibák nélkül kerül átfordításra, és a Solidity átfordító nem ad figyelmeztetéseket - -- Dokumentálja megfelelően a kódot (a [NatSpec](https://solidity.readthedocs.io/en/develop/natspec-format.html) használatában), és magyarázza el a részleteket a szerződés architektúrájáról egyszerű nyelven. Ezáltal könnyebb lesz másoknak auditálni és ellenőrizni a kódot. - -### 6. Vezessen be komoly leállást követő helyreállítási tervet {#implement-disaster-recovery-plans} - -A biztonságos hozzáférés-szabályozási terv, a függvénymódosítók bevezetése és más javaslatok fejlesztik az okosszerződés biztonságát, de nem zárhatják ki a lehetőségét egy ártó szándékú támadásnak. A biztonságos okosszerződés építése megkívánja azt is, hogy „felkészüljön a hibára”, és kidolgozzon egy tervet, amely alapján hatásosan tud reagálni egy támadásra. Egy megfelelő hibát vagy leállást követő helyreállítási terv (disaster recovery plan) a következő komponensek néhány vagy összes elemét tartalmazza: - -#### Szerződésfrissítések {#contract-upgrades} - -Miközben az Ethereum-okosszerződések alapvetően megváltozhatatlanok, mégis el lehet érni egy bizonyos fokú változtathatóságot a frissítési minták alkalmazásával. A szerződések frissítése elkerülhetetlen ha egy kritikus hiba miatt a régi szerződés használhatatlan lesz, és az új logika bevezetése a legjobb megoldás. - -A szerződésfrissítési mechanizmusok másképp működnek, de a „proxyminta” az egyik legnépszerűbb megközelítés az okosszerződések frissítésére. A [proxyminta](https://www.cyfrin.io/blog/upgradeable-proxy-smart-contract-pattern) az alkalmazás státuszát és logikáját _két_ szerződésre választja szét. Az első szerződés (a proxyszerződés) tárolja az állapotváltozókat (például a felhasználó egyenlegét), miközben a második szerződés (a logikaszerződés) tartalmazza a szerződés függvényeinek végrehajtási kódját. - -A számlák a proxyszerződéssel kerülnek interakcióba, amely elküldi a függvénymeghívásokat a logikaszerződésbe a [`delegatecall()`](https://docs.soliditylang.org/en/v0.8.16/introduction-to-smart-contracts.html?highlight=delegatecall#delegatecall-callcode-and-libraries) kódot, egy alacsony szintű meghívást használva. A `delegatecall()` a megszokott üzenethíváshoz képest biztosítja, hogy a kód a logikaszerződés címén lefut a meghívó szerződés kontextusában. Tehát a logikaszerződés mindig a proxy tárhelyére ír (nem a sajátjába) és megőrzi a `msg.sender` és `msg.value` eredeti értékeit. - -Ahhoz, hogy hívást lehessen delegálni a logikai szerződésnek, a címét el kell tárolni a proxyszerződés tárhelyén. Tehát a szerződés logikáját úgy lehet frissíteni, hogy egy új logikai szerződést kell telepíteni és eltárolni az új címet a proxyszerződésben. Mivel az ezt követő hívások a proxyszerződés felől automatikusan az új logikaszerződéshez kerülnek átirányításra, a kód változtatása nélkül végülis „frissítésre” kerül a szerződés. - -[Bővebben a szerződések frissítéséről](/developers/docs/smart-contracts/upgrading/). - -#### Vészleállítások {#emergency-stops} - -Ahogy már említettük, sem a kiterjedt audit, sem a tesztelés nem képes felfedezni az okosszerződés összes hibáját. Ha a telepítés után sebezhető pont jelenik meg a kódjában, akkor azt nem lehet kijavítani, mert a szerződés címén futó kód megváltoztathatatlan. Emellett a frissítési mechanizmust (például a proxymintákat) időbe telik bevezetni (gyakran több jóváhagyást is igényelnek), ami csak időt ad a támadóknak, hogy több kárt okozzanak. - -A radikális megoldás egy „vészleállítás” bevezetése, ami blokkolja azokat a hívásokat, melyek a szerződés sérülékeny függvényeire vonatkoznak. A vészleállítás általában a következő komponensekből áll: - -1. Egy globális boolean változó, mely jelzi, ha az okosszerződés leállított állapotban van vagy nem. Ezt a változót `false` értékre állítják a szerződés telepítésekor, de átvált `true` értékre, amint a szerződés leáll. - -2. Függvények, melyek a boolean-változóra hivatkoznak a végrehajtásuk során. Ezek a függvények akkor érhetők el, amikor az okosszerződés nincs leállítva, és elérhetetlenné válnak, amikor a vészleállítás megtörténik. - -3. Egy entitás, amelynek hozzáférése van a vészleállítási funkcióhoz, és a boolean változót `true` értékre állítja. Az esetleges visszaélés miatt ezt a funkciót csak egy megbízott cím hívhatja meg (például a szerződés tulajdonosa). - -Amint a szerződés aktiválja a vészleállást, bizonyos függvényeket nem lehet meghívni. Ezt úgy érik el, hogy a select függvényeket becsomagolják egy módosítóba, amely a globális változóra hivatkozik. Alább [egy példa](https://github.com/fravoll/solidity-patterns/blob/master/EmergencyStop/EmergencyStop.sol) látható, amely ennek a mintának a szerződésbe való bevezetését mutatja be: - -```solidity -// This code has not been professionally audited and makes no promises about safety or correctness. Use at your own risk. - -contract EmergencyStop { - - bool isStopped = false; - - modifier stoppedInEmergency { - require(!isStopped); - _; - } - - modifier onlyWhenStopped { - require(isStopped); - _; - } - - modifier onlyAuthorized { - // Check for authorization of msg.sender here - _; - } - - function stopContract() public onlyAuthorized { - isStopped = true; - } - - function resumeContract() public onlyAuthorized { - isStopped = false; - } - - function deposit() public payable stoppedInEmergency { - // Deposit logic happening here - } - - function emergencyWithdraw() public onlyWhenStopped { - // Emergency withdraw happening here - } -} -``` - -Ez a példa a vészleállás alapvető jellemzőit ismerteti: - -- Az `isStopped` egy boolean, melynek értéke `false` az elején és `true`, amikor a szerződés vészmódba lép. - -- Az `onlyWhenStopped` és `stoppedInEmergency` függvénymódosítók ellenőrzik az `isStopped` változót. A `stoppedInEmergency` azokat a függvényeket kontrollálja, amelyeknek elérhetetlennek kell maradniuk, amikor a szerződés sebezhető (például a `deposit()`). Az ezekre a függvényekre vonatkozó hívások egyszerűen visszafordulnak. - -Az `onlyWhenStopped` azokhoz a függvényekhez használandó, amelyek vészhelyzetben is elérhetők (például az `emergencyWithdraw()`). Ezek a függvények segíthetnek megoldani a helyzetet, ezért nem részei a „korlátozott függvények” listájának. - -A vészleállítási lehetőség egy hatásos hézagpótlás ahhoz, hogy a fejlesztő a komoly sebezhetőségeket kezelni tudja az okosszerződésében. Ugyanakkor a felhasználóktól több bizalmat igényel a fejlesztők felé, hogy nem használják ki ezt a funkciót önös érdekeikre. Erre lehetséges megoldást jelenthet a vészleállítás decentralizált kontrollja, mint például egy láncon belüli szavazás, időzár alkalmazása vagy egy több aláírásos tárca általi jóváhagyás. - -#### Eseményfigyelés {#event-monitoring} - -Az [események](https://docs.soliditylang.org/en/v0.8.15/contracts.html#events) lehetővé teszik az okosszerződéshez érkező hívások trekkelését és az állapotváltozók változásának felügyeletét. Bevált gyakorlatnak számít, ha az okosszerződés mindig kiad eseményt, amikor valaki egy biztonságkritikus tevékenységet végez (például kiveszi a pénzeszközöket). - -Az események naplózása és felügyelete láncon kívül betekintést enged a szerződés működésébe, valamint az ártalmas tetteket hamarabb fel lehet fedezni általuk. Így a csapat gyorsabban tud reagálni a hackelésre, és azonnal cselekedni tud, hogy a felhasználókat ez ne érintse negatívan, például leállíthatják a függvényeket vagy frissítést indíthatnak el. - -Választhat egy előre összeállított felügyeleti eszközt, amely automatikusan figyelmeztetéseket küld, amikor valaki interakcióba lép az Ön szerződéseivel. Ezek az eszközök segítenek személyre szabott figyelmeztetéseket is létrehozni különféle paraméterek alapján, mint amilyen a tranzakciómennyiség, a függvénymeghívások gyakorisága vagy az érintett függvények. Például beállíthat egy figyelmeztetést, ha a kivett pénzmennyiség egy tranzakcióban egy bizonyos határ felett van. - -### 7. Tervezzen biztonságos irányítási rendszert {#design-secure-governance-systems} - -Talán szeretné, hogy az alkalmazása decentralizált legyen, így a központi okosszerződések kontrollját a közösségi tagoknak adná. Ebben az esetben az okosszerződés rendszere felölel egy irányítási modult is – egy olyan mechanizmust, amellyel a közösségi tagok jóváhagyhatnak adminisztratív változásokat egy láncon belüli irányítási rendszer segítségével. Például azt a javaslatot, hogy a proxyszerződést egy új verzióra frissítsék, megszavaztathatja a tokennel rendelkező felhasználókkal. - -A decentralizált irányítás előnyös lehet, főleg mivel összeegyezteti a fejlesztők és a felhasználók érdekeit. Mindazonáltal az okosszerződés irányításimechanizmusa új kockázatokat is jelenthet, ha nem megfelelően vezetik be. Kézenfekvő probléma, ha egy támadó nagyon magas szavazatierőt szerez (amit az általa birtokolt tokenek száma ad) azáltal, hogy [villámhitelt](/defi/#flash-loans) vesz fel, majd egy ártó változásra tesz javaslatot. - -A láncon működő irányítási modell problémáit meg lehet oldani az [időzár használatával](https://blog.openzeppelin.com/protect-your-users-with-smart-contract-timelocks/) is. Az időzár megakadályozza, hogy az okosszerződés végrehajtson bizonyos műveleteket addig, amíg nem telt el egy adott idő. Más stratégia lehet a tokenekhez rendelt „szavazati súly” az alapján, hogy azt mennyi időre kötötték le, vagy egy adott cím szavazati erejét hosszabb periódusra is nézhetik (például 2–3 korábbi blokkra) a jelenlegi blokk helyett. Ezek csökkentik a lehetőségét annak, hogy valaki gyorsan jelentős szavazati erőre tegyen szert, hogy a láncon zajló szavazást eltérítse. - -Többet megtudhat a [biztonságos kormányzási rendszerek tervezéséről](https://blog.openzeppelin.com/smart-contract-security-guidelines-4-strategies-for-safer-governance-systems/), a [különböző szavazási mechanizmusokról a DAO-kban](https://hackernoon.com/governance-is-the-holy-grail-for-daos) és [a DeFi-t kihasználó gyakori DAO támadási vektorokról](https://dacian.me/dao-governance-defi-attacks) a megosztott linkeken. - -### 8. Csökkentse a kód komplexitását a minimumra {#reduce-code-complexity} - -A hagyományos szoftverfejlesztők elve az, hogy a lehető legegyszerűbb legyen a kód (KISS-elv), és így nem vezetnek be fölösleges bonyolításokat a tervben. Ennek alapja az az elgondolás, hogy az „összetett rendszerek összetett módokon vallhatnak kudarcot”, és sokkal hajlamosabbak a költséges hibákra. - -A minél egyszerűbb megközelítés kiemelten fontos az okosszerződések írásánál is, mivel ezek nagy értékeket is kontrollálhatnak. Ennek eléréséhez érdemes létező könyvtárakat használni, mint amilyen az [OpenZeppelin szerződések](https://docs.openzeppelin.com/contracts/4.x/), amikor ez lehetséges. Mivel ezeket a könyvtárakat a fejlesztők már alaposan tesztelték, auditálták, így kisebb a hiba valószínűsége, mintha a nulláról kell megírni egy új funkcionalitást. - -Másik követendő tanács az, hogy rövid függvényeket kell írni és a szerződést modulárisan kell felállítani, az üzleti logikát több szerződés között felosztva. Az egyszerű kódok írása kevesebb teret ad a támadásra, emellett a teljes rendszer helyességét is jobban lehet igazolni, és a lehetséges tervezési hibák is korán kiderülhetnek. - -### 9. Védekezzen az okosszerződés általános sebezhetőségei ellen {#mitigate-common-smart-contract-vulnerabilities} - -#### Újrabelépés {#reentrancy} - -Az EVM nem engedi a párhuzamosságot, tehát két szerződés egy üzenethívásban nem futhat egyszerre. Egy külső hívás megállítja a meghívó szerződés végrehajtását és memóriáját addig, amíg a hívás vissza nem tér, amikor is a végrehajtás normálisan megtörténik. Ezt a folyamatot hivatalosan úgy nevezik, hogy a [kontrollfolyamat](https://www.computerhope.com/jargon/c/contflow.htm) átadása egy másik szerződésnek. - -Habár általában nem jelent problémát, a kontrollfolyamat nem megbízható szerződéseknek való átadása okozhat némi gondot, például az újrabelépés lehetőségét. Újrabelépéses támadás akkor történik, amikor egy ártó szerződés visszahívást csinál egy sebezhető szerződésbe mielőtt az eredeti függvény meghívása lezárulna. Ezt a támadási fajtát a következő példával jobban elmagyarázzuk. - -Vegyünk egy egyszerű okosszerződést („áldozat/victim”), ami megengedi, hogy bárki ethert helyezzen letétbe és vegyen ki: - -```solidity -// This contract is vulnerable. Do not use in production - -contract Victim { - mapping (address => uint256) public balances; - - function deposit() external payable { - balances[msg.sender] += msg.value; - } - - function withdraw() external { - uint256 amount = balances[msg.sender]; - (bool success, ) = msg.sender.call.value(amount)(""); - require(success); - balances[msg.sender] = 0; - } -} -``` - -Ez a szerződés elérhetővé teszi a `withdraw()` (kivétel) függvényt a felhasználóknak, hogy a korábban letétbe helyezett ETH-t ki tudják venni. Amikor egy ilyen kivétel történik, a szerződés a következő műveleteket hajtja végre: - -1. Ellenőrzi a felhasználó ETH-egyenlegét -2. Pénzeszközt küld a meghívó címére -3. Átállítja az egyenleget 0-ra, hogy ne lehessen kivenni innen pénzt - -A `withdraw()` függvény az `victim` (áldozat) szerződésében tehát egy „ellenőrzés-interakciók-eredmény” mintát követ. _Ellenőrzi_, hogy a végrehajtáshoz szükséges feltételek teljesülnek-e (a felhasználónak pozitív ETH-egyenlege van) és elvégzi az _interakciót_ azáltal, hogy ETH-t küld a meghívó címére, majd a tranzakció _eredményeit_ alkalmazza (lecsökkenti a felhasználó egyenlegét). - -Ha a `withdraw()` kódot egy külső tulajdonú számláról (EOA) hívják meg, akkor a vártnak megfelelően megy végbe: `msg.sender.call.value()` ETH-t küld a meghívónak. Azonban, ha a `msg.sender` egy okosszerződéses számla, ami meghívja a `withdraw()` kódot, akkor a `msg.sender.call.value()` révén indított pénzküldés szintén beindítja a címen tárolt programkódot. - -Tegyük fel, hogy a szerződéscímen ez a kód van telepítve: - -```solidity - contract Attacker { - function beginAttack() external payable { - Victim(victim_address).deposit.value(1 ether)(); - Victim(victim_address).withdraw(); - } - - function() external payable { - if (gasleft() > 40000) { - Victim(victim_address).withdraw(); - } - } -} -``` - -Ez a szerződés három dolgot csinál: - -1. Letétet fogad el egy másik számlától (valószínűleg a támadó/attacker EOA-ja) -2. Letétbe helyez 1 ETH-t az áldozat szerződésében -3. Kivesz 1 ETH-t, amelyet az okosszerződés tárol - -Ebben még nincs semmi rossz, viszont a `attacker` (támadó) szerződésben van egy másik függvény is, amely meghívja a `withdraw()` kódot a `victim` (áldozat) esetében újra, ha a maradék gáz a bejövő `msg.sender.call.value` esetén több mint 40 000. Ezáltal a `attacker` újra beléphet az `victim` szerződésbe és kivehet több pénzt _mielőtt_ a `withdraw` (kivétel) első meghívása lezárulna. A ciklus így néz ki: - -```solidity -- Attacker's EOA calls `Attacker.beginAttack()` with 1 ETH -- `Attacker.beginAttack()` deposits 1 ETH into `Victim` -- `Attacker` calls `withdraw() in `Victim` -- `Victim` checks `Attacker`’s balance (1 ETH) -- `Victim` sends 1 ETH to `Attacker` (which triggers the default function) -- `Attacker` calls `Victim.withdraw()` again (note that `Victim` hasn’t reduced `Attacker`’s balance from the first withdrawal) -- `Victim` checks `Attacker`’s balance (which is still 1 ETH because it hasn’t applied the effects of the first call) -- `Victim` sends 1 ETH to `Attacker` (which triggers the default function and allows `Attacker` to reenter the `withdraw` function) -- The process repeats until `Attacker` runs out of gas, at which point `msg.sender.call.value` returns without triggering additional withdrawals -- `Victim` finally applies the results of the first transaction (and subsequent ones) to its state, so `Attacker`’s balance is set to 0 -``` - -Összességében, mivel a meghívó egyenlege nem lesz 0 mindaddig, amíg a függvényvégrehajtás nem zárul le, a rákövetkező meghívások sikeresek lesznek, és megengedik a meghívónak, hogy kivegye az egyenlegét többször is. Ez a támadás alkalmas arra, hogy egy okosszerződés pénzeszközeit kifolyassák, ahogy az a [2016-os DAO hackelésnél](https://www.coindesk.com/learn/2016/06/25/understanding-the-dao-attack/) megtörtént. Az újrabelépéses támadás még mindig kritikus probléma az okosszerződéseknél, ahogy azt az [újrabelépéses támadások nyilvános listája](https://github.com/pcaversaccio/reentrancy-attacks) mutatja. - -##### Hogyan lehet megakadályozni egy újrabelépéses támadást - -Az újrabelépés ellen az [ellenőrzés-eredmények-interakciók mintát](https://docs.soliditylang.org/en/develop/security-considerations.html#use-the-checks-effects-interactions-pattern) lehet alkalmazni. Ez a minta a függvények végrehajtását úgy rendezi, hogy az a kód jön először, amely a szükséges ellenőrzéseket végzi, azután a szerződés státuszát változtatják meg, végül a más szerződésekkel vagy külső tulajdonú számlákkal (EOA) való interakció következik. - -Az ellenőrzés-eredmények-interakciók minta a következőképpen néz ki a `victim` (áldozat) szerződésének új verziójában: - -```solidity -contract NoLongerAVictim { - function withdraw() external { - uint256 amount = balances[msg.sender]; - balances[msg.sender] = 0; - (bool success, ) = msg.sender.call.value(amount)(""); - require(success); - } -} -``` - -Ez a szerződés _ellenőrzi_ a felhasználó egyenlegét, érvényesíti a `withdraw()` függvény _eredményét_ (azáltal, hogy az egyenleget 0-ra állítja), és végül elvégzi az _interakciót_ (ETH-t küld a felhasználó címére). Ezáltal a szerződés először befrissíti a tárolt adatot, és csak utána végzi a külső hívást, így nincs lehetőség az újrabelépésre, mint korábban. Az `attacker` szerződés még mindig vissza tudja hívni a `NoLongerAVictim` (nem áldozat) szerződést, de mivel a `balances[msg.sender]` (egyenlege) már 0, a többi kivétel hibára fut. - -Másik lehetőség egy kölcsönös kizárás (más néven mutex), amely lezárja a szerződés státuszának egy részét addig, amíg a függvénymeghívás teljesül. Ezt egy boolean változóval lehet bevezetni, ami először `true` (igaz) a függvényvégrehajtás előtt, majd `false` (hamis) lesz a meghívás befejeztével. Ahogy az alábbi példából látszik, a mutex használata megvédi a függvényt attól, hogy újra meghívják, miközben az eredeti meghívás még zajlik, így hatásosan kivédi az újrabelépést. - -```solidity -pragma solidity ^0.7.0; - -contract MutexPattern { - bool locked = false; - mapping(address => uint256) public balances; - - modifier noReentrancy() { - require(!locked, "Blocked from reentrancy."); - locked = true; - _; - locked = false; - } - // This function is protected by a mutex, so reentrant calls from within `msg.sender.call` cannot call `withdraw` again. - // The `return` statement evaluates to `true` but still evaluates the `locked = false` statement in the modifier - function withdraw(uint _amount) public payable noReentrancy returns(bool) { - require(balances[msg.sender] >= _amount, "No balance to withdraw."); - - balances[msg.sender] -= _amount; - bool (success, ) = msg.sender.call{value: _amount}(""); - require(success); - - return true; - } -} -``` - -Továbbá a [„fizetéskérés”](https://docs.openzeppelin.com/contracts/4.x/api/security#PullPayment) rendszere is használható, amelynél a felhasználó vesz ki pénzt az okosszerződésből ahelyett, hogy a szerződés „fizetésküldést” végezne a számlák felé. Így nem lehet véletlenül elindítani egy kódot ismeretlen címeken (és bizonyos szolgálatmegtagadási támadásokat is ki tud védeni). - -#### Egész szám túlfolyása lefelé vagy felfelé {#integer-underflows-and-overflows} - -Egy egész szám akkor folyik túl felfelé, amikor egy aritmetikai művelet eredménye kívül esik az elfogadható tartományon, így az „tovább gördül” a legalacsonyabb megjeleníthető értékre. Például egy `uint8` csak 2^8-1=255 értéket tud tárolni. Az aritmetikai művelet, amelynek eredménye nagyobb mint `255`, túlfolyik és visszaállítja az `uint` kódot `0` értékre, ahhoz hasonlóan, ahogy egy autóban a megtett távolságot mérő óra is 0-ra fordul át, ha elérte a maximális értékét (999 999). - -Az egész szám lefelé való túlfolyása hasonló okokból következik be: az aritmetikai művelet eredménye az elfogadható tartomány alá esik. Tegyük fel, Ön szeretné lecsökkenteni a `0` értéket egy `uint8` típusú mezőben, így az egyszerűen átfordul a maximális megjeleníthető értékre (`255`). - -Mindkét irányú túlfolyás a szerződés állapotváltozóiban váratlan változásokat eredményezhet, így nem tervezett végrehajtást okozhat. Az alábbi példa bemutatja, hogyan tudja egy támadó kihasználni az aritmetikai túlfolyást egy okosszerződésben, hogy érvénytelen műveletet hajtson végre: - -``` -pragma solidity ^0.7.6; - -// This contract is designed to act as a time vault. -// User can deposit into this contract but cannot withdraw for at least a week. -// User can also extend the wait time beyond the 1 week waiting period. - -/* -1. Deploy TimeLock -2. Deploy Attack with address of TimeLock -3. Call Attack.attack sending 1 ether. You will immediately be able to - withdraw your ether. - -What happened? -Attack caused the TimeLock.lockTime to overflow and was able to withdraw -before the 1 week waiting period. -*/ - -contract TimeLock { - mapping(address => uint) public balances; - mapping(address => uint) public lockTime; - - function deposit() external payable { - balances[msg.sender] += msg.value; - lockTime[msg.sender] = block.timestamp + 1 weeks; - } - - function increaseLockTime(uint _secondsToIncrease) public { - lockTime[msg.sender] += _secondsToIncrease; - } - - function withdraw() public { - require(balances[msg.sender] > 0, "Insufficient funds"); - require(block.timestamp > lockTime[msg.sender], "Lock time not expired"); - - uint amount = balances[msg.sender]; - balances[msg.sender] = 0; - - (bool sent, ) = msg.sender.call{value: amount}(""); - require(sent, "Failed to send Ether"); - } -} - -contract Attack { - TimeLock timeLock; - - constructor(TimeLock _timeLock) { - timeLock = TimeLock(_timeLock); - } - - fallback() external payable {} - - function attack() public payable { - timeLock.deposit{value: msg.value}(); - /* - if t = current lock time then we need to find x such that - x + t = 2**256 = 0 - so x = -t - 2**256 = type(uint).max + 1 - so x = type(uint).max + 1 - t - */ - timeLock.increaseLockTime( - type(uint).max + 1 - timeLock.lockTime(address(this)) - ); - timeLock.withdraw(); - } -} -``` - -##### Hogyan akadályozható meg egy egész szám túlfolyása lefelé vagy felfelé - -A 0.8.0 verzió szerint a Solidity átfordító elutasítja azokat a kódokat, amelyek az egész szám túlfolyását eredményezik. Ugyanakkor az alacsonyabb verziójú átfordítóval készült szerződések esetén ellenőrizni kell azokat a függvényeket, amelyek aritmetikai műveleteket hajtanak végre, vagy egy olyan könyvtárat lehet használni (például [SafeMath](https://docs.openzeppelin.com/contracts/2.x/api/math)), amely ellenőrzi a túlfolyásokat. - -#### Orákulum manipulációja {#oracle-manipulation} - -Az [orákulumok](/developers/docs/oracles/) láncon kívüli információkat gyűjtenek és beküldik azokat a láncra, hogy az okosszerződések használhassák. Az orákulumok révén Ön olyan okosszerződéseket tervezhet, amelyek együtt tudnak működni láncon kívüli rendszerekkel, mint a tőkepiacok, ezzel nagy mértékben kiterjesztve az alkalmazási körüket. - -Ha viszont az orákulum korrupttá válik és nem helyes információkat küld a láncra, az okosszerződések hibás bejövő adatok alapján fognak működni, ez pedig problémákat okoz. Ez az „orákulumprobléma” alapja, amely miatt biztosítani kell, hogy a blokklánc-orákulum által adott információ pontos, friss és időben elérhető legyen. - -Az ehhez kapcsolódó biztonsági probléma az, amikor például egy decentralizált tőzsde a láncon belüli orákulumot használja arra, hogy megszerezze egy eszköz azonnali (spot) árát. A kölcsönző platformok a [decentralizált pénzügyek (DeFi)](/defi/) iparágában gyakran csinálják ezt, hogy meghatározzák a felhasználó fedezetének értékét, és ezáltal a kölcsön mértékét. - -A DEX árak gyakran igen pontosak, akár nagy mértékben is, mivel az arbitrázst kihasználók helyreállítják a piacokon az egyensúlyt. Ugyanakkor teret adnak a manipulációra, főleg ha a láncon futó orákulum az eszköz árát a korábbi kereskedelmi minták alapján számolja (ami általában igaz). - -Például egy támadó mesterségesen fel tudja pumpálni egy eszköz azonnali árát azáltal, hogy egy villámkölcsönt vesz fel éppen a kölcsönszerződés megkötése előtt. Ekkor a DEX lekérdezés az eszköz áráról egy magasabb értéket fog mutatni (mivel a támadó nagy összegű vételi igénye elmozdította az eszköz keresletét), így magasabb kölcsönt vehetnek fel, mint amit lehetne. Az ilyen „villámkölcsön-támadások” kihasználták azt, hogy a DeFi alkalmazások az orákulumokra támaszkodnak az árakat tekintve, és így sok milliónyi elveszett pénzeszközt eredményeztek a protokolloknak. - -##### Hogyan lehet elkerülni az oracle manipulációt - -A minimum követelmény az [oracle manipuláció elkerülésére](https://www.cyfrin.io/blog/price-oracle-manipultion-attacks-with-examples) az, hogy decentralizált oracle-hálózatokat kell használni, amelyek több forrásból szerzik be az információkat, így elkerülhető az egyetlen meghibásodási pont lehetősége. A legtöbb esetben a decentralizált orákulumoknak beépített kriptogazdasági ösztönzőik vannak, hogy az orákulum-csomópontok a helyes információt jelentsék, így sokkal biztonságosabbak, mint a centralizált társaik. - -Ha Ön azt tervezi, hogy egy láncon lévő orákulumot kérdez le eszközárakért, akkor használjon olyat, amely idővel súlyozott átlagárat (TWAP) számol. A [TWAP-orákulum](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) egy adott eszköz árát két különböző időpontban (ami módosítható) kérdezi le, és a megszerzett átlaga alapján kalkulálja az azonnali árat. A hosszabb időtartomány használata megvédi a protokollt az ármanipulációtól, mert a közelmúltban végrehajtott nagy rendelések nem befolyásolják az árat. - -## Okosszerződés-biztonsággal kapcsolatos anyagok fejlesztők számára {#smart-contract-security-resources-for-developers} - -### Eszközök az okosszerződések elemzéséhez és a kód helyességének ellenőrzéséhez {#code-analysis-tools} - -- **[Tesztelő eszközök és könyvtárak](/developers/docs/smart-contracts/testing/#testing-tools-and-libraries)** – _Iparági standard eszközök és könyvtárak gyűjteménye az okosszerződések egységteszteléséhez, valamint a statikus és dinamikus elemzéséhez._ - -- **[Formális ellenőrzési (formal verification) eszközök](/developers/docs/smart-contracts/formal-verification/#formal-verification-tools)** – _Eszközök arra, hogy ellenőrizzék az okosszerződések funkcionális helyességét és az állandókat._ - -- **[Okosszerződés auditálásra vonatkozó szolgáltatások](/developers/docs/smart-contracts/testing/#smart-contract-auditing-services)** – _Szervezetek listája, amelyek auditszolgáltatást kínálnak okosszerződésekre az Ethereum fejlesztési projektek számára._ - -- **[Hibavadász platformok](/developers/docs/smart-contracts/testing/#bug-bounty-platforms)** – _Platformok a hibavadászatok és a jutalmak koordinálására, hogy azok feltárják az okosszerződésekben lévő kritikus sebezhetőségeket._ - -- **[Fork Checker](https://forkchecker.hashex.org/)** – _Egy ingyenes online eszköz arra, hogy információt kapjon egy elágaztatott szerződésről._ - -- **[ABI Encoder](https://abi.hashex.org/)** – _Egy ingyenes online szolgáltatás a Solidity szerződés függvényeinek és constructor parancsainak kódolására._ - -- **[Aderyn](https://github.com/Cyfrin/aderyn)** – _Solidity statikus elemző, amely végigjárja az absztrakt szintaxisfákat (AST), hogy kiszűrje a feltételezett sebezhetőségeket, és könnyen érthető markdown formátumban kiírja a problémákat._ - -### Eszközök az okosszerződések felügyeletére {#smart-contract-monitoring-tools} - -- **[OpenZeppelin Defender Sentinels](https://docs.openzeppelin.com/defender/v1/sentinel)** – _Egy eszköz az okosszerződés automatikus felügyeletére, valamint az eseményekre, függvényekre és tranzakcióparaméterekre való válaszadásra._ - -- **[Tenderly Real-Time Alerting](https://tenderly.co/alerting/)** – _Egy eszköz, amellyel valós idejű értesítést kaphat, amikor az okosszerződésén vagy tárcáján szokatlan vagy váratlan események történnek._ - -### Eszközök az okosszerződések biztonságos adminisztrálásához {#smart-contract-administration-tools} - -- **[OpenZeppelin Defender Admin](https://docs.openzeppelin.com/defender/v1/admin)** – _Interfész az okosszerződések adminisztrációjának kezeléséhez, beleértve a hozzáférés-kezelést, frissítéseket és leállítást is._ - -- **[Safe](https://safe.global/)** – _Egy okosszerződéses tárca az Ethereumon, amelynél adott számú embernek jóvá kell hagynia a tranzakciót, mielőtt az megtörténhetne (N számú tagból M-nek)._ - -- **[OpenZeppelin Contracts](https://docs.openzeppelin.com/contracts/4.x/)** – _Szerződéskönyvtárak az adminisztrációs jellemzők bevezetésére, beleértve a szerződés tulajdonlását, frissítéseket, hozzáférés-kezelést, irányítást, leállíthatóság és még sok mást._ - -### Okosszerződés auditálására kínált szolgáltatások {#smart-contract-auditing-services} - -- **[ConsenSys Diligence](https://consensys.net/diligence/)** – _Okosszerződés auditálására kínált szolgáltatások, amelyek támogatják a blokklánc-ökoszisztéma projektjeit, hogy a protokolljaik készen állnak-e a bevezetésre és úgy épültek-e meg, hogy védik a felhasználókat._ - -- **[CertiK](https://www.certik.com/)** – _Egy blokkláncbiztonsággal foglalkozó cég, amely úttörőként használja az élvonalbeli formális ellenőrzés technológiáját az okosszerződésekre és a blokklánchálózatokra._ - -- **[Trail of Bits](https://www.trailofbits.com/)** – _Kiberbiztonsági cég, amely kombinálja a biztonsági kutatást és a támadói mentalitást, hogy csökkentse a kockázatot és megerősítse a kódot._ - -- **[PeckShield](https://peckshield.com/)** – _Blokkláncbiztonsággal foglalkozó cég, amely a teljes blokklánc-ökoszisztémához kínál termékeket és szolgáltatásokat a biztonság, adatvédelem és használhatóság területein._ - -- **[QuantStamp](https://quantstamp.com/)** – _Auditszolgáltatás, amely elősegíti a blokklánctechnológia kiterjedt használatát a biztonsági és kockázatelemzési szolgáltatásokkal._ - -- **[OpenZeppelin](https://www.openzeppelin.com/security-audits)** – _Okosszerződés-biztonsággal foglalkozó cég, amely a megosztott rendszerek számára biztosít biztonsági auditokat._ - -- **[Runtime Verification](https://runtimeverification.com/)** – _Biztonsági cég, amely az okosszerződések formális modellezésére és ellenőrzésére specializálódott._ - -- **[Hacken](https://hacken.io)** – _Web3 kiberbiztonsági auditor, amely 360 fokos megközelítést alkalmaz a blokkláncbiztonságban._ - -- **[Nethermind](https://nethermind.io/smart-contracts-audits)** – _Solidity és Cairo auditszolgáltatások, amelyekkel az okosszerződések integritása, valamint a felhasználók biztonsága is biztosíthat az Ethereumon és a Starkneten._ - -- **[HashEx](https://hashex.org/)** – _A HashEx a blokkláncok és okosszerződések auditálásra szakosodott a kriptovaluták biztonságának biztosítása céljából, illetve olyan szolgáltatásokat nyújt, mint az okosszerződés-fejlesztés, sérülékenység-vizsgálat, blokklánctanácsadás._ - -- **[Code4rena](https://code4rena.com/)** – _Versenyképes auditplatform, amely arra ösztönzi az okosszerződés-biztonsági szakértőket, hogy sebezhetőséget találjanak és segítsenek a web3-at biztonságosabbá tenni._ - -- **[CodeHawks](https://codehawks.com/)** – _Versenyképes auditplatform, amely okosszerződések auditálási versenyeit tartja a biztonsági szakértők számára._ - -- **[Cyfrin](https://cyfrin.io)** – _Web3 biztonsági erőmű, elősegíti kriptobiztonságot termékeken és okosszerződés-ellenőrzési szolgáltatásokon keresztül._ - -- **[ImmuneBytes](https://www.immunebytes.com//smart-contract-audit/)** – _Web3 biztonsági cég, amely a blokkláncrendszerek biztonsági ellenőrzését kínálja tapasztalt auditorcsapattal és a legjobb eszközökkel._ - -- **[Oxorio](https://oxor.io/)** - _Okosszerződés-auditok és blokkláncbiztonsági szolgáltatások, szakértelem az EVM, Solidity, ZK, kriptocégek láncok közötti technológiái és DeFi projektek területén._ - -- **[Inference](https://inference.ag/)** - _Biztonsági auditot végző cég, az EVM-alapú blokkláncok okosszerződés-auditjára specializálódva. A tapasztalt auditorok beazonosítják a lehetséges problémákat és megvalósítható megoldásokat javasolnak, hogy telepítés előtt ki legyenek javítva._ - -### Hibavadászplatformok {#bug-bounty-platforms} - -- **[Immunefi](https://immunefi.com/)** – _Hibavadászplatform okosszerződésekhez és DeFi-projektekhez, ahol a biztonsági kutatók átnézik a kódot, kizárják a sebezhetőségeket, ezért jutalmat kapnak, és biztonságosabbá teszik a kripto világát._ - -- **[HackerOne](https://www.hackerone.com/)** – _Sebezhetőségi koordináció és hibavadászplatform, amely összeköti a vállalkozásokat a sebezhetőségi tesztelőkkel és kiberbiztonsági kutatókkal._ - -- **[HackenProof](https://hackenproof.com/)** – _Szakértői hibavadászplatform kriptoprojektek (DeFi, okosszerződések, tárcák, CEX stb.) számára, ahol a biztonsági szakértők prioritási sorrendszolgáltatást nyújtanak, a kutatók pedig jutalmat kapnak a releváns, igazolt hibák jelentéséért._ - -- **[Sherlock](https://www.sherlock.xyz/)** - _Biztosítja a web3-ban az okosszerződések biztonságát, az auditorok kifizetéseit okosszerződéseken keresztül kezelik, hogy biztosítsák a releváns hibák kifizetését._ - -- **[CodeHawks](https://www.codehawks.com/)** - _Versenyképes hibavadász platform, ahol az auditorok biztonsági vetélkedőkben és kihívásokban vesznek részt, majd a saját privát auditjukban._ - -### Publikációk az okosszerződések ismert sebezhetőségeiről és azok kihasználásáról {#common-smart-contract-vulnerabilities-and-exploits} - -- **[Consensys: az okosszerződéseket ért ismert támadások](https://consensys.github.io/smart-contract-best-practices/attacks/)** – _Egyszerűen megfogalmazott magyarázat a legkomolyabb sérülékenységekről a szerződésekben, a legtöbb esetben mintakódokkal együtt._ - -- **[SWC Registry](https://swcregistry.io/)** – _A Közös gyengeségek felsorolásának (CWE) gondozott listája, amelyen az Ethereum okosszerződésekre vonatkozó tételek szerepelnek._ - -- **[Rekt](https://rekt.news/)** – _Rendszeresen frissített publikáció a nagy jelentőségű kriptohackelésekről és támadásokról, az esemény után készült részletes riportokkal._ - -### Kihívások az okosszerződés-biztonság elsajátításában {#challenges-for-learning-smart-contract-security} - -- **[Awesome BlockSec CTF](https://github.com/blockthreat/blocksec-ctfs)** – _Blokkláncbiztonsági háborús játékok, kihívások és [szerezd meg a zászlót (Capture The Flag)](https://www.webopedia.com/definitions/ctf-event/amp/) versenyek és megoldások gondozott listája._ - -- **[Damn Vulnerable DeFi](https://www.damnvulnerabledefi.xyz/)** – _Háborús játék a DeFi okosszerződések támadó biztonságának elsajátításához, valamint készségek fejlesztéséhez a hibavadászatban és a biztonsági auditban._ - -- **[Ethernaut](https://ethernaut.openzeppelin.com/)** – _Web3/Solidity-alapú háborús játék, ahol minden szint egy okosszerződés, amelyet meg kell „hackelni”._ - -- **[HackenProof x HackTheBox](https://app.hackthebox.com/tracks/HackenProof-Track)** - _Okosszerződés hackelési kihívás egy fantáziakalandba ágyazva. A kihívás sikeres teljesítése egy privát hibavadász programhoz ad hozzáférést._ - -### Bevált gyakorlatok az okosszerződések biztonságossá tételére {#smart-contract-security-best-practices} - -- **[ConsenSys: az Ethereum okosszerződés-biztonság bevált gyakorlatai](https://consensys.github.io/smart-contract-best-practices/)** – _Részletes útmutatók az Ethereum-okosszerződések biztonságossá tételére._ - -- **[Nascent: Egyszerű biztonsági eszközrendszer](https://github.com/nascentxyz/simple-security-toolkit)** – _Hasznos biztonságközpontú útmutatók és ellenőrző listák gyűjteménye okosszerződés-fejlesztéshez._ - -- **[Solidity Patterns](https://fravoll.github.io/solidity-patterns/)** – _Biztonsági minták és bevált gyakorlatok hasznos gyűjteménye Solidity programnyelven írt okosszerződésekhez._ - -- **[Solidity Docs: Biztonsági megfontolások](https://docs.soliditylang.org/en/v0.8.16/security-considerations.html)** – _Útmutatók a biztonságos okosszerződések írásához Solidity nyelven._ - -- **[Smart Contract Security Verification Standard](https://github.com/securing/SCSVS)** – _Egy tizennégy részes ellenőrző lista fejlesztők, architektúrával foglalkozók, biztonság-ellenőrzők és beszállítók számára az okosszerződések biztonságának szabványosításához._ - -- **[Az okosszerződések biztonságának és auditálásának elsajátítása](https://updraft.cyfrin.io/courses/security) – _Az okosszerződések biztonságát és auditálását oktató tanfolyamot olyan fejlesztőknek hozták létre, akik a legjobb biztonsági gyakorlatok mentén szeretnének fejleszteni és biztonsági kutatókká válni._ - -### Útmutatók az okosszerződés-biztonságról {#tutorials-on-smart-contract-security} - -- [Hogyan lehet biztonságosabb okosszerződéskódot írni](/developers/tutorials/secure-development-workflow/) - -- [A Slither használata okosszerződés bugok felderítésére](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) - -- [A Manticore használata okosszerződés bugok felderítésére](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) - -- [Okosszerződések biztonsági irányelvei](/developers/tutorials/smart-contract-security-guidelines/) - -- [Hogyan lehet biztonságosan integrálni a tokenszerződést tetszőleges tokenekkel](/developers/tutorials/token-integration-checklist/) - -- [Cyfrin Updraft – Okosszerződések biztonsága és auditálása tanfolyam](https://updraft.cyfrin.io/courses/security) diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" deleted file mode 100644 index 23cb43578e0..00000000000 --- "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/composability/index.md" +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Okosszerződés összeilleszthetőség -description: -lang: hu -incomplete: true ---- - -## Egy rövid bevezető {#a-brief-introduction} - -Az okosszerződések nyilvánosak az Ethereumon, így nyílt API-ként is tekinthetünk rájuk. A dapp fejlesztővé váláshoz nem kell saját okosszerződéseket írnia, csak tudnia kell, hogyan lépjen interakcióba azokkal. Például használhatja a [Uniswap](https://uniswap.exchange/swap) meglévő okosszerződéseit, egy decentralizált tőzsdét, mely kezeli a tokenváltási logikát az appban – nem kell a legelejéről kezdeni. Tekintsen meg néhány [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) és [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts) szerződést. - -## Mi az az összeilleszthetőség? {#what-is-composability} - -Az összeilleszthetőség a különböző komponensek kombinálása új rendszerek vagy kimenetek létrehozása érdekében. A szoftverfejlesztésben az összeilleszthetőség azt jelenti, hogy a fejlesztők a meglévő szoftverkomponenseket új alkalmazások létrehozásához újra felhasználhatják. Az összeilleszthetőséget úgy is el lehet képzelni, hogy az elemei a LEGO kockákra hasonlítanak. Minden egyes LEGO kombinálható egy másikkal, így a különböző elemek kombinálásával összetett szerkezeteket építhet. - -Az Ethereumban minden okosszerződés egyfajta LEGO – Ön is használhat más projektekből származó okosszerződéseket saját projektje építőköveként. Ez azt jelenti, hogy nem kell időt töltenie a kerék újbóli feltalálásával vagy a nulláról való építkezéssel. - -## Hogyan működik az összeilleszthetőség? {#how-does-composability-work} - -Az Ethereum-okosszerződések olyanok, mint a nyilvános API-ok, így bárki kölcsönhatásba léphet a szerződéssel, vagy integrálhatja azokat dappokba a hozzáadott funkciók érdekében. Az okosszerződések összeilleszthetősége három alapelv szerint működik – ez a modularitás, az autonómia és a felfedezhetőség: - -**1. Modularitás**: Az egyes komponensek képessége egy adott feladat elvégzésére. Az Ethereumban minden okosszerződésnek van egy konkrét felhasználási esete (ahogy az Uniswap példában is látható). - -**2. Autonómia**: Az összeilleszthető komponenseknek képesnek kell lenniük az önálló működésre. Az Ethereumban minden okosszerződés önvégrehajtó, és a rendszer más részei nélkül képes működni. - -**3. Felfedezhetőség**: A fejlesztők nem tudnak külső szerződéseket hívni vagy szoftverkönyvtárakat integrálni az alkalmazásokba, ha az előbbiek nem nyilvánosak. Az okosszerződések eleve nyílt forráskódúak; bárki meghívhat egy okosszerződést vagy elágaztathat egy kódot. - -## Az összeilleszthetőség előnyei {#benefits-of-composability} - -### Rövidebb fejlesztési ciklus {#shorter-development-cycle} - -Az összeilleszthetőség leveszi a munkaterhelést a fejlesztők válláról a [dappok](/dapps/#what-are-dapps) létrehozásakor. [Ahogy Naval Ravikant fogalmaz:](https://twitter.com/naval/status/1444366754650656770) „A nyílt forráskód azt jelenti, hogy egy adott problémát csak egyszer kell megoldani.” - -Ha van egy okosszerződés, amely megold egy problémát, más fejlesztők újra felhasználhatják, így nem kell ugyanazt a problémát megoldaniuk. Ezáltal a fejlesztők a meglévő szoftverkönyvtárakat felhasználhatják, és extra funkciókat adhatnak hozzá, hogy új dappokat hozzanak létre. - -### Nagyobb innováció {#greater-innovation} - -Az összeilleszthetőség ösztönzi az innovációt és a kísérletezést, mivel a fejlesztők szabadon újrafelhasználhatják, módosíthatják, duplikálhatják vagy integrálhatják a nyílt forráskódot a kívánt eredmények érdekében. Ennek eredményeképpen a fejlesztőcsapatok kevesebb időt töltenek az alapvető funkciókkal, és több időt fordíthatnak az új funkciókkal való kísérletezésre. - -### Jobb felhasználói élmény {#better-user-experience} - -Az Ethereum-ökoszisztéma összetevői közötti átjárhatóság javítja a felhasználói élményt. A felhasználók nagyobb funkcionalitáshoz férhetnek hozzá, ha a dappok külső okosszerződéseket integrálnak, mint egy széttagolt ökoszisztémában, ahol az alkalmazások nem tudnak kommunikálni. - -Az interoperabilitás előnyeit az arbitrázskereskedelemből vett példával szemléltetjük: - -Ha egy token magasabb árfolyamon kereskedik az `A tőzsdén`, mint a `B tőzsdén`, akkor kihasználhatja az árkülönbséget, hogy profitot termeljen. Ezt azonban csak akkor teheti meg, ha elegendő tőkével rendelkezik a tranzakció finanszírozásához (azaz megvásárolja a tokent a `B tőzsdén`, és eladja az `A tőzsdén`). - -Abban az esetben, amikor nincs elég pénze a kereskedés fedezésére, ideális lehet egy gyorskölcsön. A [gyorskölcsönök](/defi/#flash-loans) nagyon technikai jellegűek, de az alapötlet az, hogy Ön (fedezet nélkül) kölcsönvehet eszközöket, és ugyanezt _egy_ tranzakción belül visszaadhatja. - -Visszatérve a kezdeti példánkhoz, egy arbitrázskereskedő felvehet egy nagy összegű gyorskölcsönt, vásárolhat tokeneket a `B tőzsdén`, eladhatja azokat az `A tőzsdén`, visszafizetheti a tőkét és a kamatot, és megtarthatja a nyereséget ugyanazon tranzakción belül. Ez az összetett logika több szerződés meghívásának kombinálását igényli, ami nem lenne lehetséges, ha az okosszerződések nem lennének interoperábilisak. - -## Az összeilleszthetőség példái az Ethereumon {#composability-in-ethereum} - -### Tokenátváltások {#token-swaps} - -Ha olyan dappot hoz létre, amelyben a tranzakciókat ETH-ben kell kifizetni, a tokenátváltás-logika integrálásával lehetővé teheti a felhasználók számára, hogy más ERC-20 tokenekkel fizessenek. A kód automatikusan átváltja a felhasználó tokenjét ETH-re, mielőtt a szerződés végrehajtja a meghívott funkciót. - -### Irányítás {#governance} - -Az egyedi irányítási rendszerek kiépítése a [DAO-k](/dao/) számára költséges és időigényes lehet. Ehelyett használhat egy nyílt forráskódú irányítási eszközkészletet, például az [Aragon Client](https://client.aragon.org/) megoldást, hogy gyorsan megalkossa a DAO irányítási keretrendszerét. - -### Identitáskezelés {#identity-management} - -Ahelyett, hogy egyéni hitelesítési rendszert építene vagy központi szolgáltatókra támaszkodna, decentralizált identitás (DID) eszközöket integrálhat a felhasználók hitelesítésének kezelésére. Ilyen például a [SpruceID](https://www.spruceid.com/), egy nyílt forráskódú eszközkészlet, amely „Bejelentkezés az Ethereummal” funkciót kínál, ez pedig lehetővé teszi a felhasználók számára, hogy Ethereum-tárcával hitelesítsék az identitásukat. - -## Kapcsolódó útmutatók {#related-tutorials} - -- [Indítsa el a dapp frontend fejlesztését a create-eth-app segítségével](/developers/tutorials/kickstart-your-dapp-frontend-development-with-create-eth-app/) _– Egy áttekintés arról, hogyan használja a create-eth-appot a népszerű okosszerződésekkel rendelkező alkalmazások készítéséhez._ - -## További olvasnivaló {#further-reading} - -_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ - -- [Az összeilleszthetőség az innováció](https://future.a16z.com/how-composability-unlocks-crypto-and-everything-else/) -- [Miért fontos az összeilleszthetőség a web3-nak](https://hackernoon.com/why-composability-matters-for-web3) -- [Mi az az összeilleszthetőség?](https://blog.aragon.org/what-is-composability/#:~:text=Aragon,connect%20to%20every%20other%20piece.) diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" deleted file mode 100644 index b5593597862..00000000000 --- "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/formal-verification/index.md" +++ /dev/null @@ -1,283 +0,0 @@ ---- -title: Az okosszerződések formális ellenőrzése -description: Az Ethereum-okosszerződések formális ellenőrzésének áttekintése -lang: hu ---- - -Az [okosszerződések](/developers/docs/smart-contracts/) lehetővé teszik a decentralizált, bizalomigény nélküli és robusztus alkalmazások létrehozását, amelyek új felhasználási módokat vezetnek be és értéket teremtenek a felhasználók számára. Mivel az okosszerződések nagy mennyiségű értéket kezelnek, a biztonság kritikus szempont a fejlesztőknek. - -A formális ellenőrzés az egyik ajánlott technika az [okosszerződések biztonságának](/developers/docs/smart-contracts/security/) javítására. A formális ellenőrzést, amely [formális módszereket](https://www.brookings.edu/techstream/formal-methods-as-a-path-toward-better-cybersecurity/) használ a programok specifikálására, tervezésére és ellenőrzésére, már évek óta használják a kritikus hardver- és szoftverrendszerek helyességének biztosítására. - -Az okosszerződésekben megvalósított formális ellenőrzéssel bizonyítani lehet, hogy a szerződés üzleti logikája megfelel egy előre meghatározott specifikációnak. A szerződéskód helyességének értékelésére szolgáló más módszerekkel összehasonlítva, mint amilyen a tesztelés, a formális ellenőrzés erősebb garanciát nyújt arra, hogy az okosszerződés funkcionálisan helyes. - -## Mi az a formális ellenőrzés? {#what-is-formal-verification} - -A formális ellenőrzés során egy rendszer helyességét egy formális specifikáció alapján értékeljük. Egyszerűbben, a formális ellenőrzéssel ellenőrizhetjük, hogy egy rendszer viselkedése kielégít-e meghatározott követelményeket (azt teszi-e, amit szeretnénk). - -A rendszer (jelen esetben egy okosszerződés) várható viselkedését formális modellezéssel írják le, a specifikációs nyelvek pedig lehetővé teszik a formális tulajdonságok létrehozását. A formális ellenőrzési technikákkal ellenőrizni lehet, hogy a szerződés megvalósítása megfelel-e a specifikációjának, és matematikai bizonyítékot nyerhetünk a helyességére. Ha egy szerződés megfelel a specifikációjának, akkor azt „funkcionálisan helyesnek”, „tervezési szempontból helyesnek” vagy „konstrukciós szempontból helyesnek” nevezik. - -### Mi az a formális modell? {#what-is-a-formal-model} - -Az informatikában a [formális modell](https://en.wikipedia.org/wiki/Model_of_computation) egy számítási folyamat matematikai leírása. A programokat matematikai függvényekké (egyenletekké) absztrahálják, és a modell leírja, hogy a függvények kimenetei hogyan számíthatók ki egy bemenet alapján. - -A formális modellek olyan absztrakciós szintet biztosítanak, amelyen a program viselkedésének elemzése kiértékelhető. A formális modellek létezése lehetővé teszi egy _formális specifikáció_ létrehozását, amely leírja az adott modell kívánt tulajdonságait. - -A formális ellenőrzésnél különböző technikákat használnak az okosszerződések modellezésére. Egyes modelleket például arra használnak, hogy egy okosszerződés magas szintű viselkedéséről gondolkodjanak. Ezek a modellezési technikák feketedobozos szemléletet alkalmaznak az okosszerződésekre, olyan rendszereknek tekintve őket, amelyek bemeneteket fogadnak el, és ezek alapján számításokat hajtanak végre. - -A magas szintű modellek az okosszerződések és a külső szereplők közötti kapcsolatra összpontosítanak, mint amilyenek a külső tulajdonú számlák (EOA), a szerződésszámlák és a blokklánckörnyezet. Az ilyen modellek hasznosak olyan tulajdonságok definiálásához, amelyek meghatározzák, hogy a szerződésnek hogyan kell viselkednie bizonyos felhasználói interakciók hatására. - -Ezzel szemben más formális modellek az okosszerződés alacsony szintű viselkedésére összpontosítanak. Míg a magas szintű modellek segíthetnek a szerződés funkcionalitásáról való gondolkodásban, a végrehajtás belső működésének részleteit nem feltétlenül rögzítik. Az alacsony szintű modellek fehérdobozos szemléletet alkalmaznak a programelemzésre, és az okosszerződés-alkalmazások alacsonyabb szintű reprezentációira, például programnyomokra és [kontrollfolyamat-ábrákra](https://en.wikipedia.org/wiki/Control-flow_graph) támaszkodnak, hogy a szerződés végrehajtása szempontjából releváns tulajdonságokra következtessenek. - -Az alacsony szintű modellek ideálisnak számítanak, mivel az Ethereum végrehajtási környezetében ([EVM](/developers/docs/evm/)) egy okosszerződés tényleges végrehajtását reprezentálják. Az alacsony szintű modellezési technikák különösen hasznosak az okosszerződések kritikus biztonsági tulajdonságainak megállapításában és a potenciális sebezhetőségek felderítésében. - -### Mi az a formális specifikáció? {#what-is-a-formal-specification} - -A specifikáció egyszerűen egy műszaki követelmény, amelynek egy adott rendszernek meg kell felelnie. A programozásban a specifikációk általános elképzeléseket jelentenek egy program végrehajtásáról (a programnak mit kell tennie). - -Az okosszerződésekkel összefüggésben a formális specifikációk _tulajdonságokra_ utalnak – azoknak a követelményeknek a formális leírására, amelyeknek egy szerződésnek meg kell felelnie. Az ilyen tulajdonságokat „konstansoknak” nevezik, és olyan logikai állításokat képviselnek a szerződés végrehajtásáról, amelyeknek minden lehetséges körülmény között, kivételek nélkül igaznak kell maradniuk. - -Így a formális specifikációra úgy gondolhatunk, mint egy formális nyelven írt kijelentésgyűjteményére, amelyek leírják az okosszerződés tervezett végrehajtását. A specifikációk a szerződés tulajdonságaira vonatkoznak, és meghatározzák, hogy a szerződésnek hogyan kell viselkednie különböző körülmények között. A formális ellenőrzés célja annak meghatározása, hogy egy okosszerződés rendelkezik-e ezekkel a tulajdonságokkal (konstansokkal), és hogy ezek a tulajdonságok nem sérülnek-e a végrehajtás során. - -A formális specifikációk kritikusak az okosszerződések biztonságos implementációinak fejlesztésében. Azok a szerződések, amelyek nem teljesítik a konstansokat, vagy tulajdonságaikat a végrehajtás során megsértik, hajlamosak olyan sebezhetőségekre, amelyek károsíthatják a funkcionalitást vagy rosszindulatú kihasználást okozhatnak. - -## Az okosszerződések formális specifikációinak típusai {#formal-specifications-for-smart-contracts} - -A formális specifikációk lehetővé teszik a programvégrehajtás helyességére vonatkozó matematikai következtetéseket. A formális modellekhez hasonlóan a formális specifikációk is rögzíthetik a szerződés implementációjának magas szintű tulajdonságait vagy alacsony szintű viselkedését. - -A formális specifikációkat a [programlogika](https://en.wikipedia.org/wiki/Logic_programming) elemeinek felhasználásával vezetik le, amelyek lehetővé teszik a program tulajdonságairól való formális következtetést. A programlogika formális szabályokat tartalmaz, amelyek (matematikai nyelven) kifejezik a program várható viselkedését. A formális specifikációk létrehozásához különböző programlogikákat használnak, többek között [elérhetőségi logikát](https://en.wikipedia.org/wiki/Reachability_problem), [időbeli logikát](https://en.wikipedia.org/wiki/Temporal_logic) és [Hoare-logikát](https://en.wikipedia.org/wiki/Hoare_logic). - -Az okosszerződések formális specifikációi nagy vonalakban **magas** vagy **alacsony szintű** specifikációk közé sorolhatók. Függetlenül attól, hogy egy specifikáció milyen kategóriába tartozik, megfelelően és egyértelműen le kell írnia az elemzett rendszer tulajdonságát. - -### Magas szintű specifikációk {#high-level-specifications} - -Ahogy a neve is mutatja, a magas szintű specifikáció (más néven „modellorientált specifikáció”) egy program magas szintű viselkedését írja le. A magas szintű specifikációk az okosszerződést egy [véges állapotú gépként (FSM)](https://en.wikipedia.org/wiki/Finite-state_machine) modellezik, amely műveletek végrehajtásával képes státuszt váltani, időbeli logikát használva az FSM-modell formális tulajdonságainak meghatározásához. - -[Az időbeli logika](https://en.wikipedia.org/wiki/Temporal_logic) olyan szabály, mely az idő szempontjából minősített állításokról szól (például _mindig_ éhes vagyok vagy _végül_ éhes leszek). A formális verifikációban az időbeli logikát a státuszgépekként modellezett rendszerek helyes viselkedésére vonatkozó állítások megfogalmazására használják. Pontosabban, egy időbeli logika leírja, hogy egy okosszerződés milyen státuszokban lehet, és hogyan vált azok között. - -A magas szintű specifikációk általában két kritikus időbeli tulajdonságot rögzítenek az okosszerződések esetében: **biztonság** és **elérhetőség (liveness)**. A biztonsági tulajdonságok azt képviselik, hogy „nem történik semmi rossz”, és változatlanságot fejeznek ki. Egy biztonsági tulajdonság meghatározhat általános szoftverkövetelményeket, mint a [holtpontmentesség (deadlock)](https://www.techtarget.com/whatis/definition/deadlock), vagy kifejezheti a szerződések területspecifikus tulajdonságait (például a függvények hozzáférés-szabályozásának konstansai, a státuszváltozók megengedett értékei vagy a tokenátvitel feltételei). - -Vegyük például ezt a biztonsági követelményt, amely az ERC-20 tokenszerződésekben a `transfer()` vagy `transferFrom()` használatának feltételeit tartalmazza: _„A feladó egyenlege soha nem lehet alacsonyabb, mint a küldendő tokenek kért mennyisége.”_. A szerződéskonstans természetes nyelvű leírása lefordítható formális (matematikai) specifikációvá, amelyet ellenőrizni lehet érvényességi szempontból. - -Az elérhetőségtulajdonságok azt állítják, hogy „valami jó történik”, tehát a szerződés képes-e különböző státuszokon keresztül haladni. Egy példa az elérhetőségtulajdonságra a „likviditás”, tehát a szerződés képes-e a felhasználóknak átadni az egyenleget kérés alapján. Ha ez a tulajdonság sérül, a felhasználók nem tudnák kivenni a szerződésben tárolt eszközöket, ahogy az a [Parity-tárca incidens](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html) esetében történt. - -### Alacsony szintű specifikációk {#low-level-specifications} - -A magas szintű specifikációk kiindulópontja egy szerződés véges státuszú modellje, és meghatározzák e modell kívánt tulajdonságait. Ezzel szemben az alacsony szintű specifikációk (más néven „tulajdonságorientált specifikációk”) gyakran matematikai függvények gyűjteményéből álló rendszerekként modellezik a programokat (okosszerződéseket), és leírják ezek helyes viselkedését. - -Egyszerűbben fogalmazva, az alacsony szintű specifikációk _programnyomokat_ elemeznek, és megpróbálják meghatározni egy okosszerződés tulajdonságait ezeken keresztül. A nyomvonalak az okosszerződés státuszát változtató funkcióvégrehajtások sorozataira utalnak, ezért az alacsony szintű specifikációk meghatározzák a szerződés belső végrehajtásának követelményeit. - -Az alacsony szintű formális specifikációkat Hoare-stílusú tulajdonságokként vagy végrehajtási útvonalakra vonatkozó konstansokként lehet megadni. - -### Hoare-stílusú tulajdonságok {#hoare-style-properties} - -A [Hoare-logika](https://en.wikipedia.org/wiki/Hoare_logic) egy sor formális szabályt biztosít a programok, köztük az okosszerződések helyességére vonatkozó érveléshez. Egy Hoare-stílusú tulajdonságot egy Hoare-hármas {_P_}_c_{_Q_} reprezentál, ahol _c_ egy program, _P_ és _Q_ állítások a _c_ státuszára (a programra) vonatkozóan, amelyeket formálisan _előfeltételekkel_ és _utófeltételekkel_ írunk le. - -Az előfeltétel egy állítás, amely leírja a függvény helyes végrehajtásához szükséges feltételeket; a szerződést meghívó felhasználóknak meg kell felelniük ennek a követelménynek. Az utófeltétel egy állítás, amely azt a feltételt írja le, amelyet egy függvény helyesen végrehajtva állít fel; a felhasználók elvárhatják, hogy ez a feltétel igaz legyen a függvény meghívása után. A _konstans_ a Hoare-logikában olyan állítás, amely egy függvény végrehajtása során megmarad (nem változik). - -A Hoare-stílusú specifikációk garantálhatják a _részleges_ vagy a _teljes helyességet_. Egy szerződésfüggvény végrehajtása „részben helyes”, ha az előfeltétel igaz a függvény végrehajtása előtt, és ha a végrehajtás befejeződik, akkor az utófeltétel is igaz. A teljes helyesség bizonyítékát akkor kapjuk meg, ha egy előfeltétel igaz a függvény végrehajtása előtt, a végrehajtás garantáltan befejeződik, és amikor ez megtörténik, az utófeltétel igaz. - -A teljes helyesség bizonyítása nehéz, mivel egyes végrehajtások késhetnek a befejezés előtt, vagy egyáltalán nem fejeződnek be. Ennek ellenére a kérdés, hogy a végrehajtás befejeződik-e, vitatható, mivel az Ethereum gázmechanizmusa megakadályozza a végtelen programhurkokat (a végrehajtás vagy sikeresen befejeződik, vagy a gázhiány miatt ér véget). - -A Hoare-logika segítségével létrehozott okosszerződés-specifikációk elő- és utófeltételekkel, valamint konstansokkal rendelkeznek a szerződésben szereplő függvények és ciklusok végrehajtásához. Az előfeltételek gyakran tartalmazzák egy függvény hibás bemeneteinek lehetőségét, az utófeltételek pedig leírják az ilyen bemenetekre várható választ (például megjelenik egy adott kivétel). Ily módon a Hoare-stílusú tulajdonságok hatékonyan biztosítják a szerződések megvalósításának helyességét. - -Számos formális ellenőrzési keretrendszer Hoare-stílusú specifikációkat használ a függvények szemantikai helyességének bizonyítására. Lehetőség van arra is, hogy a Hoare-stílusú tulajdonságokat (mint állításokat) közvetlenül a szerződéskódhoz adjuk hozzá a Solidity `require` és `assert` utasításokkal. - -A `require` utasítások előfeltételt vagy konstanst fejeznek ki, és gyakran használják a felhasználói bemenetek érvényesítésére, míg az `assert` a biztonsághoz szükséges utófeltételeket rögzíti. Például a függvények megfelelő hozzáférés-ellenőrzése (egy példa a biztonsági tulajdonságra) a `require` használatával érhető el, amely előfeltételként ellenőrzi a hívó fiók személyazonosságát. Hasonlóképpen, a szerződésben lévő státuszváltozók megengedett értékeire vonatkozó konstans (például a forgalomban lévő zsetonok teljes száma) védhető az `assert` használatával, hogy a függvény végrehajtása után igazoljuk a szerződés státuszát. - -### Nyomvonalszintű tulajdonságok {#trace-level-properties} - -A nyomvonalalapú specifikációk leírják a szerződés státuszváltozását biztosító műveleteket és az ezek közötti kapcsolatokat. Ahogy az korábban elhangzott, a nyomvonalak olyan műveletsorozatok, amelyek egy szerződés státuszát egy bizonyos módon változtatják meg. - -Ez a megközelítés az okosszerződések státuszváltozási rendszerként való modellezésére épül, előre meghatározott státuszokkal (amelyeket az státuszváltozók írnak le) és változásokkal (amelyeket a szerződésfüggvények írnak le). Továbbá egy [kontrollfolyamat-ábra (CFG)](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/), amely egy program végrehajtási folyamatának grafikus ábrázolása, gyakran használják a szerződés operációs szemantikájának leírására. Itt minden nyomvonal egy-egy útvonalként jelenik meg a kontrollfolyamat-ábrán. - -A nyomvonal-szintű specifikációkat elsősorban arra használják, hogy az okosszerződések belső végrehajtási mintáira következtessenek. A nyomvonal-szintű specifikációk létrehozásával biztosítják az okosszerződés végrehajtási útvonalait (azaz a státuszváltozásokat). Olyan technikák segítségével, mint a szimbolikus végrehajtás, formálisan ellenőrizhetjük, hogy a végrehajtás soha nem követ olyan utat, amely nem a formális modellben van definiálva. - -Vegyünk egy példát egy [DAO](/dao/) szerződésre, amely rendelkezik néhány nyilvánosan elérhető függvénnyel a nyomvonalszintű tulajdonságok leírására. Itt feltételezzük, hogy a DAO szerződés lehetővé teszi a felhasználók számára a következő műveletek végrehajtását: - -- Pénzeszközök letétbe helyezése - -- Pénzeszközök befizetése után szavazhat javaslatokról - -- Visszatérítést igényelhet, ha nem szavaz egy javaslatról - -A nyomvonalszintű tulajdonságok például a következők lehetnek: _„azok a felhasználók, akik nem fizetnek be pénzt, nem szavazhatnak egy javaslatról”_ vagy _„akik nem szavaznak egy javaslatról, mindig igényelhetnek visszatérítést”_. Mindkét tulajdonság a végrehajtás preferált sorrendjét érvényesíti (a szavazás nem történhet _előbb_, mint a pénzeszközök befizetése, és a visszatérítés igénylése nem történhet a javaslatról való szavazás _után_). - -## Az okosszerződések formális ellenőrzésének technikái {#formal-verification-techniques} - -### Modellellenőrzés {#model-checking} - -A modellellenőrzés egy olyan formális ellenőrzési technika, amelyben egy algoritmus egy okosszerződés formális modelljét ellenőrzi annak specifikációjával szemben. A modellellenőrzés során az okosszerződéseket gyakran státuszváltozási rendszerekként ábrázolják, míg a szerződés megengedett státuszaira vonatkozó tulajdonságokat időbeli logika segítségével határozzák meg. - -A modellellenőrzés egy rendszer absztrakt matematikai reprezentációjának (egy szerződésnek) a létrehozása és a rendszer tulajdonságainak kifejezése olyan formulák segítségével, amelyek az [üzleti logikában](https://www.baeldung.com/cs/propositional-logic) gyökereznek. Ez leegyszerűsíti a modellellenőrző algoritmus feladatát, nevezetesen annak bizonyítását, hogy egy matematikai modell kielégít-e egy adott logikai formulát. - -A modellellenőrzést a formális ellenőrzésben elsősorban a szerződés időbeli viselkedését leíró időbeli tulajdonságok értékelésére használják. Az okosszerződések időbeli tulajdonságai közé tartozik a _biztonság_ és az _elérhetőség_, amelyeket korábban már kifejtettünk. - -Például formális logikában leírható egy adott hozzáférés-szabályozással kapcsolatos biztonsági tulajdonság (pl. _kizárólag a szerződés tulajdonosa hívhatja meg a `selfdestruct` kódot_). Ezt követően a modellellenőrző algoritmus ellenőrizheti, hogy a szerződés megfelel-e ennek a formális specifikációnak. - -A modellellenőrzés státuszterek feltárását használja, amely magában foglalja az okosszerződés összes státuszának létrehozását, és megpróbálja megtalálni a tulajdonságokat megsértő státuszokat. Ez végtelen számú státuszhoz vezethet (az úgynevezett státuszrobbanás problémája), ezért a modellellenőrzők absztrakciós technikákra támaszkodnak, hogy hatékonyan elemezhessék az okosszerződéseket. - -### Tételbizonyítás {#theorem-proving} - -A tételbizonyítás a programok, köztük az okosszerződések helyességére vonatkozó matematikai érvelés módszere. Ez magában foglalja a szerződéses rendszer modelljének és specifikációinak matematikai formulákká (logikai kijelentésekké) történő átalakítását. - -A tételbizonyítás célja az állítások közötti logikai egyenértékűség igazolása. A „logikai egyenértékűség” (más néven logikai kettős következtetés) két állítás között az a kapcsolat, hogy az első állítás _akkor és csak akkor _ igaz, ha a második állítás igaz. - -A szerződés modelljére és tulajdonságára vonatkozó állítások közötti szükséges kapcsolatot (logikai egyenértékűséget) bizonyítható állításként (tételként) fogalmazzuk meg. Egy formális következtetési rendszer segítségével az automatizált tételvizsgáló képes ellenőrizni a tétel érvényességét. Más szóval, egy tételpróba meggyőzően bizonyítani tudja, hogy egy okosszerződés modellje pontosan megfelel a specifikációinak. - -Míg a modellellenőrzés a szerződéseket véges státuszváltozási rendszerekként modellezi, addig a tételbizonyítás végtelen státuszú rendszerek elemzését tudja kezelni. Ez azonban azt jelenti, hogy egy automatizált tételfelmérő nem mindig tudja, hogy egy logikai probléma „eldönthető” vagy sem. - -Ennek eredményeképpen gyakran emberi segítségre van szükség ahhoz, hogy a tételmegállapítót a helyességi bizonyítások levezetésében irányítani lehessen. A tételek bizonyítása emberi erőfeszítéssel drágább, mint modellellenőrzéssel, amely teljesen automatizált. - -### Szimbolikus végrehajtás {#symbolic-execution} - -A szimbolikus végrehajtás egy okosszerződést elemző módszer, amely a funkciókat _szimbolikus értékek_ (például `x > 5`) helyett _konkrét értékek_ (például `x == 5`) használatával hajtja végre. A szimbolikus végrehajtás egy olyan formális ellenőrzési technika, mellyel formálisan magyarázzák a szerződéskód nyomvonalszintű tulajdonságait. - -A szimbolikus végrehajtás egy végrehajtási nyomvonalat szimbolikus bemeneti értékek feletti matematikai képletként, más néven _útvonalállításként_ ábrázol. Egy [SMT megoldó](https://en.wikipedia.org/wiki/Satisfiability_modulo_theories) segítségével ellenőrizhetjük, hogy egy útvonalállítás „kielégíthető-e” (létezik-e olyan érték, amely kielégíti a formulát). Ha egy sérülékeny útvonal kielégíthető, az SMT megoldó egy konkrét értéket generál, amely a végrehajtást erre az útvonalra irányítja. - -Tegyük fel, hogy egy okosszerződés függvénye bemenetként egy `uint` értéket (`x`) fogad el, és akkor tér vissza, ha `x` nagyobb, mint `5` és kisebb, mint `10`. A hibát kiváltó `x` értékének megtalálása normál tesztelési eljárással több tucat teszteset (vagy még több) lefuttatását igényelné anélkül, hogy biztosan megtalálná a hibát. - -Ezzel szemben egy szimbolikus végrehajtó eszköz a függvényt a szimbolikus értékkel hajtaná végre: `X > 5 ∧ X < 10` (azaz `x` nagyobb, mint 5 ÉS `x` kisebb, mint 10). A kapcsolódó `x = X > 5 ∧ X < 10` útvonalállítást ezután egy SMT megoldónak adnánk megoldásra. Ha egy adott érték megfelel a `x = X > 5 ∧ X < 10` képletnek, az SMT megoldó kiszámítja azt – például a megoldó `7`-et adhat az `x` értékeként. - -Mivel a szimbolikus végrehajtás a program bemeneteire támaszkodik, ezek pedig végtelen számúak lehetnek az összes státusz feltárásához, ez még mindig a tesztelés egyik formája. Amint azonban a példa mutatja, a szimbolikus végrehajtás hatékonyabb a tulajdonságokat megsértő bemenetek megtalálásában, mint a rendszeres tesztelés. - -Ráadásul a szimbolikus végrehajtás kevesebb hamis pozitív eredményt produkál, mint más tulajdonságalapú technikák (például a fuzzing), amelyek véletlenszerűen generálják a függvénybemeneteket. Ha a szimbolikus végrehajtás során hiba lép fel, akkor lehetőség van a hibát kiváltó konkrét érték generálására és a probléma reprodukálására. - -A szimbolikus végrehajtás a helyesség bizonyos fokú matematikai bizonyítására is alkalmas. Tekintsük meg a következő példát egy túlcsordulás elleni védelemmel ellátott szerződésfüggvényre: - -``` -function safe_add(uint x, uint y) returns(uint z){ - - z = x + y; - require(z>=x); - require(z>=y); - - return z; -``` - -Egy egész szám túlcsordulását eredményező végrehajtási nyomvonalnak meg kell felelnie a képletnek: `z = x + y AND (z >= x) AND (z=>y) AND (z < x OR z < y)`. Egy ilyen formula valószínűleg nem oldható meg, ezért matematikai bizonyítékul szolgál arra, hogy a `safe_add` függvény nem csordul túl. - -### Miért használjunk formális ellenőrzést az okosszerződésekhez? {#benefits-of-formal-verification} - -#### Megbízhatóság iránti igény {#need-for-reliability} - -A formális ellenőrzést olyan biztonságkritikus rendszerek helyességének értékelésére használják, amelyek meghibásodása pusztító következményekkel járhat, mint például halál, sérülés vagy pénzügyi csőd. Az okosszerződések nagy értékű alkalmazások, amelyek hatalmas értékeket irányítanak, és az egyszerű tervezési hibák [visszafordíthatatlan veszteségeket okozhatnak a felhasználóknak](https://www.freecodecamp.org/news/a-hacker-stole-31m-of-ether-how-it-happened-and-what-it-means-for-ethereum-9e5dc29e33ce/amp/). A szerződés formális ellenőrzése a telepítés előtt növelheti a garanciákat arra, hogy az a blokkláncon az elvárásoknak megfelelően fog működni. - -A megbízhatóság igen kívánatos tulajdonság bármely okosszerződésben, különösen azért, mert az Ethereum virtuális gépben (EVM) telepített kód alapvetően megváltoztathatatlan. Mivel a telepítés utáni frissítés nehezen megoldható, a szerződések megbízhatóságának garantálása szükségessé teszi a formális ellenőrzést. A formális ellenőrzés képes felderíteni az olyan trükkös problémákat, mint az egész számok alul- és túlcsordulása, az újbóli belépés és a rossz gázoptimalizálás, amelyek elkerülhetik az auditorok és a tesztelők figyelmét. - -#### Funkcionális helyesség bizonyítása {#prove-functional-correctness} - -A programtesztelés a leggyakoribb bizonyítási módszer arra, hogy egy okosszerződés megfelel-e bizonyos követelményeknek. Ez magában foglalja a szerződésvégrehajtást mintaadatokkal és a viselkedéselemzést. Ha a szerződés a mintaadatokra a várt eredményeket adja, akkor a fejlesztők objektív bizonyítékkal rendelkeznek a szerződés helyességéről. - -Ez a megközelítés azonban nem tudja bizonyítani a helyes végrehajtást a mintán kívüli értékek esetében. Ezért a szerződés tesztelése segíthet a hibák felderítésében (ha egyes kódútvonalak nem a kívánt eredményt adják a végrehajtáskor), de **nem tudja bizonyítani a hibák hiányát**. - -Ezzel szemben a formális ellenőrzés bebizonyíthatja, hogy egy okosszerződés végtelen számú végrehajtás esetén _megfelel a követelményeknek anélkül, hogy a szerződést lefuttatná_. Ehhez olyan formális specifikációt kell készíteni, amely pontosan leírja a szerződés helyes viselkedését, és ki kell dolgozni a rendszer formális (matematikai) modelljét. Ezután egy formális bizonyítási eljárást követve ellenőrizhetjük a szerződés modellje és a specifikáció közötti konzisztenciát. - -A formális ellenőrzésnél az egyik matematikai tétel, hogy egy szerződés üzleti logikája megfelel-e a követelményeknek, tehát bizonyítható vagy cáfolható. Egy tétel formális bizonyításával véges számú lépéssel végtelen számú tesztszcenáriót tudunk ellenőrizni. Ily módon a formális ellenőrzésnek jobbak az esélyei annak bizonyítására, hogy egy szerződés funkcionálisan helyes a specifikációhoz képest. - -#### Ideális ellenőrzési célok {#ideal-verification-targets} - -A ellenőrzési cél a formálisan ellenőrizendő rendszert írja le. A formális ellenőrzés leginkább akkor alkalmazható, ha „beágyazott rendszerekről” van szó (kis, egyszerű szoftverdarabokról, amelyek egy nagyobb rendszer részét képezik). Ideálisak a kevés szabállyal rendelkező speciális tartományok számára is, mivel így könnyebben módosíthatók a tartományspecifikus tulajdonságok ellenőrzési eszközei. - -Az okosszerződések bizonyos mértékig mindkét követelményt teljesítik. Az Ethereum-szerződések kis mérete például lehetővé teszi a formális ellenőrzést. Hasonlóképpen, az EVM egyszerű szabályokat követ, ami megkönnyíti a rajta futó programok szemantikai tulajdonságainak megadását és ellenőrzését. - -### Gyorsabb fejlesztési ciklus {#faster-development-cycle} - -A formális ellenőrzési technikák, például a modellellenőrzés és a szimbolikus végrehajtás általában hatékonyabbak, mint az okosszerződések kódjának (tesztelés vagy auditálás általi) rendszeres elemzése. Amiatt, mert a formális ellenőrzés szimbolikus értékekre támaszkodik az állítások teszteléséhez („mi van, ha egy felhasználó megpróbál _n_ ethert felvenni?”) ellentétben a teszteléssel, amely konkrét értékeket használ („mi van, ha egy felhasználó megpróbál 5 ethert kivenni?”). - -A szimbolikus bemeneti változók a konkrét értékek több osztályát is lefedhetik, így a formális ellenőrzés megközelítései rövidebb idő alatt nagyobb kódlefedettséget ígérnek. Hatékony használatnál a formális ellenőrzés felgyorsíthatja a fejlesztési ciklust. - -A formális ellenőrzés javítja a decentralizált alkalmazások (dapp) építésének folyamatát is, mivel csökkenti a költséges tervezési hibákat. A szerződések frissítése (ahol egyáltalán lehetséges) annak érdekében, hogy kijavítsák a sebezhetőségeket, a kódbázis átfogó átírását és több fejlesztési erőfeszítést igényel. A formális ellenőrzés számos olyan hibát felfedezhet a szerződések megvalósításában, amelyek elkerülhetik a tesztelők és auditorok figyelmét, így ezeket a problémákat még a bevezetés előtt kijavíthatják. - -## A formális ellenőrzés hátrányai {#drawbacks-of-formal-verification} - -### A manuális munka költsége {#cost-of-manual-labor} - -A formális ellenőrzés, különösen a félautomata verziója, amelyben egy ember irányítja a bizonyítót a helyességi bizonyítások levezetésében, jelentős manuális munkát igényel. Ráadásul a formális specifikáció készítése összetett tevékenység, amelyhez magas szintű szakértelem szükséges. - -Ezek a tényezők (erőfeszítés és szakértelem) a formális verifikációt igényesebbé és költségesebbé teszik a szerződések helyességét értékelő módszerekhez, például a teszteléshez és az auditáláshoz képest. Mindazonáltal a teljes hitelesítési audit kifizetése lényeges lehet, tekintettel az okosszerződések megvalósításában előforduló hibák költségeire. - -### Hamis negatív eredmények {#false-negatives} - -A formális ellenőrzés csak azt tudja ellenőrizni, hogy az okosszerződés végrehajtása megfelel-e a formális specifikációnak. Ezért fontos, hogy a specifikáció megfelelően leírja az okosszerződés elvárt viselkedését. - -Ha a specifikációk rosszul vannak megírva, a tulajdonságok megsértését – amelyek sebezhető végrehajtásokra utalnak – a formális ellenőrzés nem tudja felfedezni. Ebben az esetben a fejlesztő tévesen feltételezheti, hogy a szerződés hibamentes. - -### Teljesítményproblémák {#performance-issues} - -A formális ellenőrzés számos teljesítményproblémába ütközik. Például a modell- és a szimbolikus ellenőrzés során felmerülő státusz- és útvonalrobbanási problémák befolyásolhatják az ellenőrzési eljárásokat. Emellett a formális ellenőrzési eszközök gyakran használnak SMT és más korlátozó megoldókat a mögöttes rétegben, melyek számításigényes eljárásokra támaszkodnak. - -Emellett a programellenőrzők számára nem mindig lehetséges, hogy megállapítsák, egy (logikai képletként leírt) tulajdonság teljesülhet-e vagy sem ([meghatározhatósági probléma](https://en.wikipedia.org/wiki/Decision_problem)), mivel előfordulhat, hogy egy program soha nem ér véget. Mint ilyen, lehetetlen lehet bizonyítani egy szerződés bizonyos tulajdonságait, még akkor is, ha az jól specifikált. - -## Formális ellenőrzési eszközök az Ethereum-okosszerződésekhez {#formal-verification-tools} - -### Formális specifikációk létrehozására szolgáló specifikációs nyelvek {#specification-languages} - -**Act**: _*Az Act lehetővé teszi a tárolási frissítések, az elő- és utófeltételek és a szerződéskonstansok meghatározását. Eszközkészletének bizonyítási háttértárai is vannak, amelyek számos tulajdonságot képesek bizonyítani Coq, SMT megoldók vagy hevm segítségével.** - -- [GitHub](https://github.com/ethereum/act) -- [Dokumentáció](https://ethereum.github.io/act/) - -**Scribble** – _*A Scribble a Scribble specifikációs nyelvben szereplő kódmegjelöléseket konkrét állításokká alakítja, amelyek ellenőrzik a specifikációt.** - -- [Dokumentáció](https://docs.scribble.codes/) - -**Dafny** – _*A Dafny egy ellenőrzési programozási nyelv, amely magas szintű megjegyzésekre támaszkodik a kód helyességéről való gondolkodáshoz és annak bizonyításához.** - -- [GitHub](https://github.com/dafny-lang/dafny) - -### Programellenőrzők a helyesség vizsgálatára {#program-verifiers} - -**Certora Prover** – _Certora Prover egy automatikus formális ellenőrzőeszköz az okosszerződéskódok vizsgálatához. A specifikációkat CVL-en (Certora ellenőrzési nyelv) írják, a tulajdonságok megsértését statikus elemzés és kényszermegoldás kombinációjával detektálják._ - -- [Honlap](https://www.certora.com/) -- [Dokumentáció](https://docs.certora.com/en/latest/index.html) - -**Solidity SMTChecker** – _*A Solidity SMTChecker egy beépített modellellenőrző, amely SMT- (Satisfiability Modulo Theories) és Horn-megoldáson alapul. Megerősíti, hogy a szerződés forráskódja megfelel-e a specifikációknak az átfordítás során, és statikusan ellenőrzi a biztonsági tulajdonságok megsértését.** - -- [GitHub](https://github.com/ethereum/solidity) - -**solc-verify** – _*A solc-verify a Solidity fordító egy kiterjesztett változata, amely képes automatizált formális ellenőrzést végezni a Solidity kódon megjegyzések és moduláris programellenőrzés segítségével.** - -- [GitHub](https://github.com/SRI-CSL/solidity) - -**KEVM** - _*A KEVM a K keretrendszerben írt Ethereum virtuális gép (EVM) formális szemantikája. A KEVM futtatható, és képes bizonyos tulajdonságokkal kapcsolatos állítások bizonyítására az elérhetőségi logika segítségével.** - -- [GitHub](https://github.com/runtimeverification/evm-semantics) -- [Dokumentáció](https://jellopaper.org/) - -### Logikai keretek a tételbizonyításhoz {#theorem-provers} - -**Isabelle** – _Az Isabelle/HOL egy olyan bizonyítási segédprogram, amely lehetővé teszi matematikai formulák formális nyelven történő megfogalmazását, és eszközöket biztosít e formulák bizonyításához. Fő alkalmazási területe a matematikai bizonyítások formalizálása és különösen a formális ellenőrzés, amely magában foglalja a számítógépes hardver vagy szoftver helyességének bizonyítását, valamint a számítógépes nyelvek és protokollok tulajdonságainak bizonyítását._ - -- [GitHub](https://github.com/isabelle-prover) -- [Dokumentáció](https://isabelle.in.tum.de/documentation.html) - -**Coq** – _A Coq egy interaktív tételbizonyító, amely lehetővé teszi, hogy programokat definiáljon tételek segítségével, és interaktívan generálja a helyesség gépileg ellenőrzött bizonyítékait._ - -- [GitHub](https://github.com/coq/coq) -- [Dokumentáció](https://coq.github.io/doc/v8.13/refman/index.html) - -### Szimbolikus végrehajtáson alapuló eszközök az okosszerződések sebezhető mintáinak felderítésére {#symbolic-execution-tools} - -**Manticore** – _*Egy eszköz az EVM-bájtkódelemző eszköz vizsgálatára, amely szimbolikus végrehajtáson alapul.** - -- [GitHub](https://github.com/trailofbits/manticore) -- [Dokumentáció](https://github.com/trailofbits/manticore/wiki) - -**hevm** – _*a hevm egy szimbolikus végrehajtási motor és ekvivalencia-ellenőrző az EVM-bájtkódhoz.** - -- [GitHub](https://github.com/dapphub/dapptools/tree/master/src/hevm) - -**Mythril** – _Egy szimbolikus végrehajtási eszköz az Ethereum-okosszerződések sebezhetőségének felderítésére_ - -- [GitHub](https://github.com/ConsenSys/mythril-classic) -- [Dokumentáció](https://mythril-classic.readthedocs.io/en/develop/) - -## További olvasnivaló {#further-reading} - -- [Hogyan működik az okosszerződések formális ellenőrzése](https://runtimeverification.com/blog/how-formal-verification-of-smart-contracts-works/) -- [Hogyan biztosíthatja a formális ellenőrzés a hibátlan okosszerződéseket](https://media.consensys.net/how-formal-verification-can-ensure-flawless-smart-contracts-cbda8ad99bd1) -- [Az Ethereum ökoszisztéma formális ellenőrzési projektjeinek áttekintése](https://github.com/leonardoalt/ethereum_formal_verification_overview) -- [Az Ethereum 2.0 letétbe helyezési okosszerződés formális ellenőrzése elejétől a végéig](https://runtimeverification.com/blog/end-to-end-formal-verification-of-ethereum-2-0-deposit-smart-contract/) -- [A világ legnépszerűbb okosszerződésének formális ellenőrzése](https://www.zellic.io/blog/formal-verification-weth) -- [SMTChecker és formális ellenőrzés](https://docs.soliditylang.org/en/v0.8.15/smtchecker.html) diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" deleted file mode 100644 index 18fa6d86692..00000000000 --- "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/testing/index.md" +++ /dev/null @@ -1,308 +0,0 @@ ---- -title: Okos szerződések tesztelése -description: Az Ethereum okosszerződés-tesztelési technikáinak és szempontjainak áttekintése. -lang: hu ---- - -Az Ethereumhoz hasonló nyilvános blokkláncok megváltoztathatatlanok, ami megnehezíti az okosszerződések kódjának módosítását a telepítésük után. [Léteznek szerződésfrissítési minták](/developers/docs/smart-contracts/upgrading/) a „virtuális frissítések” végrehajtására, de ezeket nehéz megvalósítani, és társadalmi konszenzust igényelnek. Ráadásul a frissítés csak a hiba _felfedezése után_ javíthatja ki azt – ha egy támadó előbb fedezi fel a sebezhetőséget, akkor az okosszerződést veszély fenyegeti. - -Ezen okok miatt az okosszerződések tesztelése a fő hálózatra való [telepítés](/developers/docs/smart-contracts/deploying/) előtt elengedhetetlen a [biztonság](/developers/docs/smart-contracts/security/) szempontjából. A szerződések tesztelésére és a kód helyességének kiértékelésére számos technika létezik; a fejlesztő igényeitől függ, hogy melyiket választja. Mindazonáltal egy különböző eszközökből és megközelítésekből álló tesztcsomag ideális a szerződéskód kisebb és nagyobb biztonsági hibáinak kiszűrésére. - -## Előfeltételek {#prerequisites} - -Ez az oldal elmagyarázza, hogyan lehet tesztelni az okosszerződéseket az Ethereum-hálózaton való telepítés előtt. Feltételezi, hogy ismeri az [okosszerződéseket](/developers/docs/smart-contracts/). - -## Mi az az okosszerződés-tesztelés? {#what-is-smart-contract-testing} - -Az okosszerződések tesztelése annak ellenőrzése, hogy a szerződés kódja az elvárásoknak megfelelően működik-e. A tesztelés egy hasznos ellenőrzés, hogy az adott okosszerződés megfelel-e a megbízhatósági, használhatósági és biztonsági követelményeknek. - -Bár a megközelítések eltérők, a legtöbb tesztelési módszerhez az okosszerződést végre kell hajtani a kezelendő adatok egy kis mintájával. Ha a szerződés helyes eredményeket ad a mintaadatokra, akkor feltételezhetően megfelelően működik. A legtöbb tesztelési eszköz forrásokat biztosít a [tesztszcenáriók](https://en.m.wikipedia.org/wiki/Test_case) megírásához és végrehajtásához, amelyekkel ellenőrizni lehet, hogy a szerződések végrehajtása megfelel-e a várt eredményeknek. - -### Miért fontos az okosszerződések tesztelése? {#importance-of-testing-smart-contracts} - -Mivel az okosszerződések gyakran nagy értékű pénzügyi eszközöket kezelnek, a kisebb programozási hibák [nagy veszteségeket okozhatnak a felhasználóknak](https://rekt.news/leaderboard/). A szigorú tesztelés segíthet abban, hogy az okosszerződés kódjában lévő hibákat és problémákat időben felfedezze és a fő hálózaton való elindítás előtt kijavítsa. - -Bár van lehetőség a szerződés frissítésére, ha hibát fedeztek fel, a frissítések összetettek, és [hibákhoz vezethetnek](https://blog.trailofbits.com/2018/09/05/contract-upgrade-anti-patterns/), ha nem megfelelően kezelik őket. A szerződés frissítése ellentmond a megváltoztathatatlanság elvének, és bizalmat igényel a felhasználóktól. Ezzel szemben az átfogó tesztelési terv csökkenti az okosszerződések biztonsági kockázatait, és a telepítés utáni komplex logikai frissítések szükségességét. - -## Az okosszerződések tesztelésének módszerei {#methods-for-testing-smart-contracts} - -Az Ethereum okosszerződések tesztelési módszerei két nagy kategóriába sorolhatók: **automatizált** és **manuális tesztelés**. Az automatizált és a manuális tesztelés egyedi előnyökkel és kompromisszumokkal jár, de mindkettőt kombinálhatja, hogy megbízható tervet hozzon létre a szerződések vizsgálatához. - -### Automatizált tesztelés {#automated-testing} - -Az automatizált tesztelés olyan eszközöket használ, amelyek automatikusan ellenőrzik az okosszerződések kódját a végrehajtási hibák szempontjából. Az automatizált tesztelés előnye a [szkriptek](https://www.techtarget.com/whatis/definition/script?amp=1) használatából származik, amelyek a szerződéses funkciók értékelését irányítják. A szkriptelt teszteket úgy lehet ütemezni, hogy minimális emberi beavatkozással ismételten fussanak, így az automatizált tesztelés hatékonyabb, mint a manuális megközelítés. - -Az automatizált tesztelés különösen akkor hasznos, ha a tesztek ismétlődők és időigényesek, manuálisan nehezen kivitelezhetők, emberi hibára hajlamosak, vagy kritikus szerződéses funkciók értékelését végzik. Ezeknek is megvannak hátrányai, mert bizonyos hibákat kihagyhatnak, és számos [hamis pozitív eredményt](https://www.contrastsecurity.com/glossary/false-positive) produkálhatnak. Ezért az okosszerződések esetében az automatizált és a manuális tesztelés párosítása az ideális. - -### Manuális tesztelés {#manual-testing} - -A manuális tesztelést ember végzi, és az okosszerződések helyességének elemzése során a tesztcsomag minden egyes tesztszcenárióját egymás után hajtja végre. Ez ellentétben áll az automatizált teszteléssel, ahol egyszerre több izolált tesztet futtathat egy szerződésen, és egy olyan jelentést kaphat, amely megmutatja az összes sikertelen és sikeres tesztet. - -A manuális tesztelést egyetlen személy is elvégezheti egy írásos teszttervet követve, amely különböző tesztszcenáriókra terjed ki. A manuális tesztelés részeként több személy vagy csoport is interakcióba léphet az okosszerződéssel egy meghatározott időszak alatt. A tesztelők összehasonlítják a szerződés tényleges és elvárt viselkedését, és minden eltérést hibaként jelölnek meg. - -A hatékony manuális tesztelés jelentős erőforrásokat igényel (szakértelem, idő, pénz és erőfeszítés), és lehetséges, hogy emberi hiba miatt a tesztek végrehajtása során bizonyos hibák nem derülnek ki. A manuális tesztelés előnyös is lehet – egy ember (például egy auditor) felismerhet olyan valós helyzeteket, amelyeket egy automatizált tesztelőeszköz kihagyna. - -## Automatizált tesztelés okosszerződésekhez {#automated-testing-for-smart-contracts} - -### Egységtesztelés {#unit-testing-for-smart-contracts} - -Az egységtesztelés külön-külön értékeli a szerződés funkcióit, és ellenőrzi, hogy minden egyes komponens megfelelően működik-e. A jó egységteszteknek egyszerűnek és gyorsan lefuttathatónak kell lenniük, és ha a teszt nem a várt eredményt adja, akkor világos képet kell adniuk arról, hogy mi a hiba. - -Az egységtesztek hasznosak annak ellenőrzésére, hogy a függvények visszaadják-e a várt értékeket, és hogy a szerződés adattárhelye megfelelően frissül-e a végrehajtás során. Továbbá a szerződések kódbázisának módosítása után az egységtesztek biztosítják, hogy az új logika hozzáadása ne okozzon hibákat. Az alábbiakban bemutatjuk a hatékony egységtesztek futtatását: - -#### Irányelvek az okosszerződések egységteszteléséhez {#unit-testing-guidelines} - -##### 1. A szerződések üzleti logikájának és munkafolyamatának megértése - -Az egységtesztek megírása előtt hasznos tudni, hogy milyen funkciókat kínál egy okosszerződés, és hogy a felhasználók hogyan fogják elérni és használni ezeket a funkciókat. Ez különösen hasznos a [boldog út (happy path) tesztek](https://en.m.wikipedia.org/wiki/Happy_path) futtatásához, amelyek meghatározzák, hogy a szerződésben szereplő függvények a helyes kimenetet adják-e vissza érvényes felhasználói bemenetek esetén. Ezt a koncepciót az [aukciós szerződés](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction) rövidített példáján keresztül magyarázzuk el - -``` -constructor( - uint biddingTime, - address payable beneficiaryAddress - ) { - beneficiary = beneficiaryAddress; - auctionEndTime = block.timestamp + biddingTime; - } - -function bid() external payable { - - if (block.timestamp > auctionEndTime) - revert AuctionAlreadyEnded(); - - if (msg.value <= highestBid) - revert BidNotHighEnough(highestBid); - - if (highestBid != 0) { - pendingReturns[highestBidder] += highestBid; - } - highestBidder = msg.sender; - highestBid = msg.value; - emit HighestBidIncreased(msg.sender, msg.value); - } - - function withdraw() external returns (bool) { - uint amount = pendingReturns[msg.sender]; - if (amount > 0) { - pendingReturns[msg.sender] = 0; - - if (!payable(msg.sender).send(amount)) { - pendingReturns[msg.sender] = amount; - return false; - } - } - return true; - } - -function auctionEnd() external { - if (block.timestamp < auctionEndTime) - revert AuctionNotYetEnded(); - if (ended) - revert AuctionEndAlreadyCalled(); - - ended = true; - emit AuctionEnded(highestBidder, highestBid); - - beneficiary.transfer(highestBid); - } -} -``` - -Ez egy egyszerű aukciós szerződés, amelynek célja, hogy a licitidőszak alatt ajánlatokat fogadjon. Ha a `highestBid` (legmagasabb ajánlat) emelkedik, az előző legmagasabb ajánlatot tevő kapja meg a pénzét; ha a licitidőszak véget ér, a `beneficiary` (kedvezményezett) meghívja a szerződést, hogy megkapja a pénzt. - -Egy ilyen szerződés egységtesztjei lefedik a különböző funkciókat, amelyeket a felhasználó meghívhat a szerződés használata során. Ilyen például egy olyan egységteszt, amely ellenőrzi, hogy a felhasználó tud-e licitálni, miközben az aukció folyamatban van (azaz a `bid()` meghívása sikeres), vagy egy olyan, amely ellenőrzi, hogy a felhasználó tud-e magasabb licitet tenni, mint az aktuális `highestBid` (legmagasabb ajánlat). - -A szerződés működési folyamatának megértése segít az egységtesztek megírásában, amelyek ellenőrzik, hogy a végrehajtás megfelel-e a követelményeknek. Az aukciós szerződés például előírja, hogy a felhasználók nem tehetnek ajánlatot, ha az aukció már véget ért (azaz ha az `auctionEndTime` alacsonyabb, mint a `block.timestamp`). Így a fejlesztő futtathat egy olyan egységtesztet, amely ellenőrzi, hogy a `bid()` függvény hívása sikeres vagy sikertelen, amikor az aukció véget ér (amikor `auctionEndTime` > `block.timestamp`). - -##### 2. A szerződés teljesítésével kapcsolatos feltételezések értékelése - -Fontos dokumentálni a szerződés végrehajtásával kapcsolatos feltételezéseket, és egységteszteket írni azok érvényességének ellenőrzésére. Amellett, hogy védelmet nyújt a nem várt végrehajtás ellen, az állítások tesztelése arra készteti a fejlesztőt, hogy átgondolja azokat a műveleteket, amelyek megtörhetik az okosszerződések biztonsági modelljét. Hasznos tipp, hogy a „boldog felhasználói teszteken” túlmenően írjunk negatív teszteket, amelyek ellenőrzik, hogy egy függvény rossz bemenetek esetén nem működik-e. - -Sok egységtesztelési keretrendszer lehetővé teszi, hogy állításokat hozzon létre – azaz egyszerű kijelentéseket, amelyek meghatározzák, hogy egy szerződés mit tehet és mit nem –, és teszteket futtasson, hogy lássa, ezek az állítások érvényesek-e a végrehajtás során. Egy fejlesztő, aki a korábban leírt aukciós szerződésen dolgozik, a negatív tesztek lefuttatása előtt a következő állításokat teheti a szerződés viselkedéséről: - -- A felhasználók nem tehetnek ajánlatot, ha az aukció már véget ért vagy még el sem kezdődött. - -- Az aukciós szerződés visszalép, ha egy ajánlat az elfogadható küszöbérték alatt van. - -- Azoknak a felhasználóknak, akik nem nyerik meg a licitet, jóváírják a pénzüket - -**Megjegyzés**: A feltételezések tesztelésének egy másik módja, hogy olyan teszteket írunk, amelyek a szerződésben [függvénymódosítókat](https://docs.soliditylang.org/en/v0.8.16/contracts.html#function-modifiers) váltanak ki, különös tekintettel a `require`, `assert` és `if... else` utasításokra. - -##### 3. Kódlefedettség mérése - -A [kódlefedettség](https://en.m.wikipedia.org/wiki/Code_coverage) egy tesztelési metrika, amely a tesztek során végrehajtott ágak, sorok és utasítások számát követi a kódban. A teszteknek jó kódlefedettséggel kell rendelkezniük, különben előfordulhat, hogy „hamis negatív eredményt” kapunk, amikor a szerződés átmegy az összes teszten, de a kódban még vannak sebezhetőségek. A magas kódlefedettség rögzítése biztosítékot ad arra, hogy az okosszerződésben szereplő összes utasítást/függvényt megfelelően tesztelték a helyesség szempontjából. - -##### 4. Jól kidolgozott tesztelési keretrendszerek használata - -Az okosszerződések egységtesztjeinek futtatásához használt eszközök minősége kulcsfontosságú. Az ideális tesztelési keretrendszert rendszeresen karbantartják, hasznos funkciókat biztosít (például naplózási és jelentéstételi képességek), és más fejlesztők már széles körben használták és vizsgálták. - -A Solidity okosszerződések egységtesztelési keretrendszerei különböző nyelveken (főként JavaScript, Python és Rust) készülnek. Az alábbi útmutatókból tájékozódhat arról, hogyan kezdheti el a tesztelési keretrendszerekkel az egységtesztek futtatását: - -- **[Egységtesztek futtatása a Brownie segítségével](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** -- **[Egységtesztek futtatása a Foundry segítségével](https://book.getfoundry.sh/forge/writing-tests)** -- **[Egységtesztek futtatása a Waffle segítségével](https://ethereum-waffle.readthedocs.io/en/latest/getting-started.html#writing-tests)** -- **[Egységtesztek futtatása a Remix segítségével](https://remix-ide.readthedocs.io/en/latest/unittesting.html#write-tests)** -- **[Egységtesztek futtatása az Ape segítségével](https://docs.apeworx.io/ape/stable/userguides/testing.html)** -- **[Egységtesztek futtatása a Hardhat segítségével](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** -- **[Egységtesztek futtatása a Wake segítségével](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - -### Integrációs tesztelés {#integration-testing-for-smart-contracts} - -Míg az egységtesztelés a szerződés funkcióit elszigetelten vizsgálja, az integrációs tesztek az okosszerződés összetevőit egészében értékelik. Az integrációs teszteléssel felderíthetők azok a problémák, melyek a szerződésközi meghívásokból vagy az okosszerződés különböző függvényei közötti kölcsönhatásokból erednek. Az integrációs tesztek például segíthetnek ellenőrizni, hogy az olyan dolgok, mint az [öröklődés](https://docs.soliditylang.org/en/v0.8.12/contracts.html#inheritance) és a függőségi befecskendezésnek megfelelően működnek-e. - -Az integrációs tesztelés akkor hasznos, ha a szerződés moduláris architektúrát alkalmaz, vagy ha a végrehajtás során más láncon belüli szerződésekhez kapcsolódik. Az integrációs tesztek futtatásának egyik módja, hogy [elágaztatja (fork) a blokkláncot](/glossary/#fork) egy adott magasságban (egy olyan eszközzel, mint a [Forge](https://book.getfoundry.sh/forge/fork-testing) vagy a [Hardhat](https://hardhat.org/hardhat-network/docs/guides/forking-other-networks), és szimulálja a szerződése és a telepített szerződések közötti kölcsönhatásokat. - -Az elágaztatott blokklánc a fő hálózathoz hasonlóan viselkedik, és számlák vannak rajta a megfelelő státuszokkal és egyenlegekkel. De ez csak egy helyi fejlesztőkörnyezet, tehát a tranzakciókhoz nincs szükség valódi ETH-re, és a változtatások nem befolyásolják a valódi Ethereum-protokollt. - -### Tulajdonságalapú tesztelés {#property-based-testing-for-smart-contracts} - -A tulajdonságalapú tesztelés annak ellenőrzése, hogy egy okosszerződés megfelel-e valamilyen meghatározott tulajdonságnak. A tulajdonságok olyan tényeket állítanak a szerződés viselkedéséről, amelyek várhatóan különböző forgatókönyvek esetén is igazak maradnak. Egy adott okosszerződés tulajdonsága például a következő: „A szerződésben szereplő aritmetikai műveletekre nem jellemző a túlcsordulás vagy alulcsordulás.” - -A **statikus** és a **dinamikus elemzés** két gyakori technika a tulajdonságalapú tesztelésre, és mindkettő képes ellenőrizni, hogy egy program (jelen esetben egy okosszerződés) kódja megfelel-e valamilyen előre meghatározott tulajdonságnak. Egyes tulajdonságalapú tesztelési eszközök előre meghatározott szabályokat tartalmaznak a szerződés várható tulajdonságairól, és a kódot ezek alapján ellenőrzik, míg mások lehetővé teszik, hogy egyéni tulajdonságokat hozzon létre az okosszerződéshez. - -#### Statikus elemzés {#static-analysis} - -A statikus elemzés bemenetként egy okosszerződés forráskódját veszi, és olyan eredményeket ad ki, amelyek kijelentik, hogy a szerződés megfelel-e egy tulajdonságnak vagy sem. A dinamikus elemzéssel ellentétben a statikus elemzés nem foglalja magában a szerződés végrehajtását, hogy megvizsgálja annak helyességét. A statikus elemzés az összes lehetséges útvonalat megvizsgálja, amelyet egy okosszerződés a végrehajtás során bejárhat (azaz a forráskód szerkezetét vizsgálja, hogy az mit jelentene a szerződések működése kapcsán a futtatásakor). - -A [linting](https://www.perforce.com/blog/qac/what-lint-code-and-why-linting-important) és a [statikus tesztelés](https://www.techtarget.com/whatis/definition/static-analysis-static-code-analysis) a szerződések statikus elemzésének általános módszerei. Mindkettő a szerződésvégrehajtás olyan alacsony szintű reprezentációinak elemzését igényli, mint az átfordító által adott [absztrakt szintaxisfák](https://en.m.wikipedia.org/wiki/Abstract_syntax_tree) és [kontrollfolyamat-ábrák](https://www.geeksforgeeks.org/software-engineering-control-flow-graph-cfg/amp/). - -A legtöbb esetben a statikus elemzés hasznos a biztonsági problémák, például a nem biztonságos konstrukciók, szintaktikai hibák vagy a kódolási szabványok megsértésének felderítésére a kódban. A statikus elemzésről azonban köztudott, hogy nem alkalmasak a mélyebb sebezhetőségek felderítésére, és sok hamis pozitív eredményt produkálhatnak. - -#### Dinamikus elemzés {#dynamic-analysis} - -A dinamikus elemzés szimbolikus bemeneteket (például [szimbolikus végrehajtásnál](https://en.m.wikipedia.org/wiki/Symbolic_execution)) vagy konkrét bemeneteket (például [fuzzing](https://owasp.org/www-community/Fuzzing) esetén) generál egy okosszerződés-függvényhez, hogy vajon egy végrehajtási nyom sért-e bizonyos tulajdonságokat. A tulajdonságalapú tesztelésnek ez a formája abban különbözik az egységtesztektől, hogy a tesztesetek több szcenárióra terjednek ki, és egy program kezeli a tesztesetek generálását. - -A [fuzzing](https://halborn.com/what-is-fuzz-testing-fuzzing/) az egyik dinamikus elemzési technika, amellyel az okosszerződések tetszőleges tulajdonságait lehet ellenőrizni. A fuzzer a célszerződésben lévő függvényeket egy meghatározott bemeneti érték véletlenszerű vagy hibás variációival hívja meg. Ha az okosszerződés hibás állapotba kerül (például egy állítás sikertelen), a problémát megjelöli, és a sérülékeny útvonalat mutató bemenetek egy jelentésben jelennek meg. - -A fuzzing hasznos az okosszerződések bemenetérvényesítési mechanizmusának értékeléséhez, mivel a váratlan bemenetek nem megfelelő kezelése eredményezhet nem szándékos végrehajtást és veszélyes hatásokat is. A tulajdonságalapú tesztelésnek ez a formája több okból is ideális lehet: - -1. **Nehéz olyan tesztszcenáriókat írni, amelyek sok szcenáriót lefednek.** A tulajdonságteszthez csak egy viselkedést és egy adattartományt kell definiálnia, amellyel a viselkedést tesztelni kívánja – a program automatikusan teszteseteket generál a megadott tulajdonság alapján. - -2. **A tesztcsomag nem feltétlenül fed le minden lehetséges útvonalat a programon belül.** Még 100%-os lefedettség esetén is lehetséges, hogy kihagyja az éles eseteket. - -3. **Az egységtesztek bizonyítják, hogy a szerződés helyesen kerül végrehajtásra a mintaadatokra, az viszont ismeretlen marad, hogy helyes-e a mintán kívüli bemenetekre.** A tulajdonságtesztek egy adott bemeneti érték több variációjával hajtják végre a célszerződést, hogy megtalálják az állításhibákat okozó végrehajtási nyomokat. Így a tulajdonságteszt több garanciát nyújt arra, hogy a szerződés helyesen kerül végrehajtásra a bemeneti adatok nagyobb osztálya esetén. - -### Irányelvek az okosszerződések tulajdonságalapú tesztelésének futtatásához {#running-property-based-tests} - -A tulajdonságalapú tesztelés futtatása általában egy tulajdonság (például [egész számok túlcsordulásának](https://github.com/ConsenSys/mythril/wiki/Integer-Overflow) hiánya) vagy tulajdonságok gyűjteményének meghatározásával kezdődik, amelyet egy okosszerződésben ellenőrizni szeretne. A tulajdonságtesztek írásakor szükség lehet egy olyan értéktartomány meghatározására is, amelyen belül a program adatokat generálhat a tranzakciós bemenetekhez. - -A megfelelő konfigurálás után a tulajdonságtesztelő eszköz véletlenszerűen generált bemenetekkel hajtja végre az okosszerződések funkcióit. Ha az állítások sérülnek, akkor a fejlesztő egy jelentést kap a konkrét bemeneti adatokkal, amelyek sértik az értékelt tulajdonságot. Tekintse meg az alábbi útmutatókat, hogy elkezdhesse a tulajdonságalapú tesztelést különböző eszközökkel: - -- **[Okosszerződések statikus elemzése a Slither segítségével](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/slither#slither)** -- **[Okosszerződések statikus elemzése a Wake segítségével](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** -- **[Tulajdonságalapú tesztelés a Brownie segítségével](https://eth-brownie.readthedocs.io/en/stable/tests-hypothesis-property.html)** -- **[Fuzzing szerződések a Foundry segítségével](https://book.getfoundry.sh/forge/fuzz-testing)** -- **[Fuzzing szerződések a Echidna segítségével](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/echidna#echidna-tutorial)** -- **[Fuzzing szerződések a Wake segítségével](https://ackeeblockchain.com/wake/docs/latest/testing-framework/fuzzing/)** -- **[Okosszerződések szimbolikus végrehajtása a Manticore segítségével](https://github.com/crytic/building-secure-contracts/tree/master/program-analysis/manticore#manticore-tutorial)** -- **[Okosszerződések szimbolikus végrehajtása a Mythril segítségével](https://mythril-classic.readthedocs.io/en/master/tutorial.html)** - -## Okosszerződések manuális tesztelése {#manual-testing-for-smart-contracts} - -Az okosszerződések manuális tesztelése gyakran a fejlesztési ciklus későbbi szakaszában, az automatizált tesztek lefuttatása után történik. A tesztelés ezen formája az okosszerződést egy teljesen integrált termékként értékeli, hogy kiderüljön, a műszaki követelményekben meghatározottak szerint teljesít-e. - -### Szerződések tesztelése helyi blokkláncon {#testing-on-local-blockchain} - -Míg a helyi fejlesztői környezetben végzett automatizált tesztelés hasznos hibakeresési információkkal szolgálhat, a fejlesztő azt is tudni szeretné, hogyan viselkedik az okosszerződése éles környezetben. A fő Ethereum-láncra való telepítés gázdíjakkal jár – arról nem is beszélve, hogy a fejlesztő vagy a felhasználók valódi pénzt veszíthetnek, ha az okosszerződés hibás. - -A szerződés tesztelését egy helyi blokkláncon ([fejlesztői hálózaton](/developers/docs/development-networks/)) ajánlott elvégezni a fő hálózat helyett. A helyi blokklánc az Ethereum egy olyan másolata, amely lokálisan fut a számítógépen, és amely a végrehajtási réteg viselkedését szimulálja. Így jelentős többletköltségek nélkül programozhat tranzakciókat a szerződéssel való interakcióra. - -A szerződések futtatása egy helyi blokkláncon hasznos lehet a manuális integrációs tesztelés egyik formájaként. [Az okosszerződések nagymértékben modulárisak](/developers/docs/smart-contracts/composability/), lehetővé téve a meglévő protokollokkal való integrációt, de továbbra is biztosítani kell, hogy az ilyen összetett láncon belüli kölcsönhatások a megfelelő eredményeket hozzák. - -[További információk a fejlesztői hálózatokról.](/developers/docs/development-networks/) - -### Szerződések tesztelése a teszthálózatokon {#testing-contracts-on-testnets} - -A teszthálózat pontosan úgy működik, mint az Ethereum fő hálózat, azzal a különbséggel, hogy a használt ethernek (ETH) nincs valós értéke. Ha a szerződést egy [teszthálózatra](/developers/docs/networks/#ethereum-testnets) telepíti, akkor bárki kapcsolatba léphet azzal (például a dapp felületén keresztül) anélkül, hogy pénzeszközt kockáztatna. - -A manuális tesztelés ezen formája hasznos az alkalmazás teljes folyamatának kiértékeléséhez a felhasználó szemszögéből. Itt a béta tesztelők próbafuttatásokat is végezhetnek, és jelenthetik a szerződés üzleti logikájával és általános funkcionalitásával kapcsolatos problémákat. - -A teszthálózatra való telepítés a helyi blokkláncon való tesztelés után ideális, mivel az előbbi közelebb áll az Ethereum virtuális gépének viselkedéséhez. Ezért számos Ethereum-projektben gyakori, hogy a dappokat teszthálózatokra telepítik, hogy valós körülmények között értékeljék az okosszerződések működését. - -[Bővebben az Ethereum teszthálózatokról.](/developers/docs/development-networks/#public-beacon-testchains) - -## A tesztelés és a formális ellenőrzés összehasonlítása {#testing-vs-formal-verification} - -Miközben a tesztelés segít annak megerősítésében, hogy a szerződés bizonyos bemeneti adatok esetében a várt eredményeket adja vissza, a nem használt bemeneti adatok esetében ugyanezt nem tudja egyértelműen bizonyítani. Az okosszerződés tesztelése nem garantálhatja a „funkcionális helyességet” (nem mutathatja meg, hogy a program _minden_ bemeneti értékre az előírt módon viselkedik-e). - -A formális ellenőrzés a szoftver helyességét vizsgálja, hogy a program formális modellje megfelel-e a formális specifikációnak. A formális modell egy program absztrakt matematikai reprezentációja, míg a formális specifikáció a program tulajdonságait (a végrehajtással kapcsolatos logikai állításokat) határozza meg. - -Mivel a tulajdonságok matematikai kifejezésekben vannak leírva, logikai következtetési szabályok segítségével ellenőrizhetővé válik, hogy a rendszer formális (matematikai) modellje megfelel-e a specifikációnak. Ezért azt mondják, hogy a formális verifikációs eszközök „matematikai bizonyítékot” állítanak elő egy rendszer helyességéről. - -A teszteléssel ellentétben a formális ellenőrzés használható arra, hogy egy okosszerződés végrehajtása megfelel-e a formális specifikációnak _minden_ végrehajtás esetén (nincs benne hiba), anélkül hogy mintaadatokkal kellene végrehajtani. Ez nem csak a több tucatnyi egységteszt futtatására fordított időt csökkenti, de hatékonyabb a rejtett sebezhetőségek felderítésében is. Ennek ellenére a formális ellenőrzési technikák haszna a megvalósítás nehézségétől és hasznosságától függ. - -[További információ az okosszerződések formális ellenőrzéséről.](/developers/docs/smart-contracts/formal-verification) - -## A tesztelés, illetve auditok és hibavadászatok összehasonlítása {#testing-vs-audits-bug-bounties} - -A szigorú tesztelés ritkán tudja garantálni, hogy egy szerződésben nincsenek hibák; a formális ellenőrzési módszerek erősebb biztosítékot nyújthatnak a helyességre, de nehéz ezeket alkalmazni, és jelentős költségekkel járnak. - -Mégis tovább növelheti a szerződéses sebezhetőségek felfedezésének lehetőségét, ha független kódellenőrzést végeztet. Az [okosszerződésaudit](https://www.immunebytes.com/blog/what-is-a-smart-contract-audit/) és a [hibavadászat](https://medium.com/immunefi/a-defi-security-standard-the-scaling-bug-bounty-9b83dfdc1ba7) két olyan módszer, amelynek révén mások is elemzik a szerződéseket. - -Az auditokat olyan auditorok végzik, akik tapasztaltak az okosszerződések biztonsági hibáinak és helytelen fejlesztési gyakorlatainak felderítésében. Az audit általában magában foglalja a tesztelést (és esetleg a formális ellenőrzést), valamint a teljes kódbázis manuális felülvizsgálatát. - -Ezzel szemben a hibavadász-program általában pénzjutalom felajánlását jelenti olyan személyeknek (általában [fehér kalapos hackereknek](https://en.wikipedia.org/wiki/White_hat_(computer_security))), akik felfedezik az okosszerződés sebezhetőségét és feltárják azt a fejlesztők előtt. A hibavadászatok hasonlítanak az auditokhoz, mivel mások segítségét kérik az okosszerződések hibáinak megtalálásában. - -A fő különbség az, hogy a hibavadász-programok nyitottak a szélesebb fejlesztői/hackerközösség számára, és etikus hackerek és független biztonsági szakemberek széles rétegét vonzzák, akik egyedi készségekkel és tapasztalattal rendelkeznek. Ez előnyt jelenthet az olyan okosszerződések ellenőrzésével szemben, amelyek főként olyan csapatokra támaszkodnak, akik korlátozott szakértelemmel rendelkezhetnek. - -## Tesztelőeszközök és könyvtárak {#testing-tools-and-libraries} - -### Egységtesztelési eszközök {#unit-testing-tools} - -- **[Solidity-coverage](https://github.com/sc-forks/solidity-coverage)** – _Kódlefedettségi eszköz Solidity nyelven írt okosszerződésekhez._ - -- **[Waffle](https://ethereum-waffle.readthedocs.io/en/latest/)** – _Keretrendszer fejlett okosszerződések fejlesztéséhez és teszteléséhez (ethers.js-alapú)_. - -- **[Remix Tests](https://github.com/ethereum/remix-project/tree/master/libs/remix-tests)** – _Eszköz a Solidity okosszerződések teszteléséhez. A Remix IDE „Solidity Unit Testing” plugin alatt működik, amely a szerződéshez tartozó tesztek írására és futtatására szolgál._ - -- **[OpenZeppelin Test Helpers](https://github.com/OpenZeppelin/openzeppelin-test-helpers)** – _Állításkönyvtár az Ethereum okosszerződések teszteléséhez. Győződjön meg arról, hogy a szerződései az elvárt módon viselkednek!_ - -- **[Brownie unit testing framework](https://eth-brownie.readthedocs.io/en/v1.0.0_a/tests.html)** – _A Brownie a Pytest-et használja, amely egy funkciógazdag tesztelési keretrendszert, és amely lehetővé teszi kis tesztek írását minimális kóddal, jól skálázható nagyobb projektekhez és nagymértékben bővíthető._ - -- **[Foundry Tests](https://github.com/foundry-rs/foundry/tree/master/forge)** – _A Foundry a Forge megoldást kínálja, amely egy gyors és rugalmas Ethereum tesztelési keretrendszert, és amely képes egyszerű egységtesztek, gázoptimalizálási ellenőrzések és szerződés fuzzing végrehajtására._ - -- **[Hardhat Tests](https://hardhat.org/hardhat-runner/docs/guides/test-contracts)** – _Keretrendszer az ethers.js, Mocha és Chai alapú okosszerződések tesztelésére._ - -- **[ApeWorx](https://docs.apeworx.io/ape/stable/userguides/testing.html)** – _Python-alapú fejlesztési és tesztelési keretrendszer az Ethereum virtuális gépen működő okosszerződésekhez._ - -- **[Wake](https://ackeeblockchain.com/wake/docs/latest/testing-framework/overview/)** - _Python-alapú keretrendszer az egységtesztelésre és fuzzingra erős hibakeresési képességekkel és láncok közötti teszttámogatással, mely a pytest és az Anvil használatával jó felhasználói élményt és teljesítményt biztosít._ - -### Tulajdonságalapú tesztelőeszközök {#property-based-testing-tools} - -#### Statikus elemzőeszközök {#static-analysis-tools} - -- **[Slither](https://github.com/crytic/slither)** – _Python-alapú Solidity statikus elemzési keretrendszer a sebezhetőségek felkutatására, a kódérthetőség javítására és az okosszerződések egyéni elemzésére._ - -- **[Ethlint](https://ethlint.readthedocs.io/en/latest/)** – _Linter a stílusra és biztonságra vonatkozó bevált gyakorlatok érvényesítésére a Solidity okosszerződések programozási nyelvéhez._ - -- **[Cyfrin Aderyn](https://cyfrin.io/tools/aderyn)** – _Rust-alapú statikus elemző, amelyet kifejezetten a web3 okosszerződések biztonságához és fejlesztéséhez terveztek._ - -- **[Wake](https://ackeeblockchain.com/wake/docs/latest/static-analysis/using-detectors/)** - _Python-alapú statikus elemzési keretrendszer sebezhetőségi és kódminőségi ellenőrzéssel, a printer minden hasznos információt kiszed a kódból és támogatja a személyre szabott almodulok készítését._ - -#### Dinamikus elemzőeszközök {#dynamic-analysis-tools} - -- **[Echidna](https://github.com/crytic/echidna/)** – _Gyors szerződésfuzzer az okosszerződések sebezhetőségének felderítésére tulajdonságalapú teszteléssel._ - -- **[Diligence Fuzzing](https://consensys.net/diligence/fuzzing/)** – _Automatizált fuzzing eszköz, amely hasznos a tulajdonságok megsértésének észlelésére az okosszerződés kódjában._ - -- **[Manticore](https://manticore.readthedocs.io/en/latest/index.html)** – _Dinamikus szimbolikus végrehajtási keretrendszer az EVM-bájtkód elemzésére._ - -- **[Mythril](https://github.com/ConsenSys/mythril-classic)** – _EVM-bájtkódértékelő eszköz a szerződéses sebezhetőségek felderítésére szennyeződéselemzés, dinamikus szimbolikus (concolic) elemzés és a kontrollfolyamat ellenőrzésének segítségével._ - -- **[Diligence Scribble](https://consensys.net/diligence/scribble/)** – _A Scribble egy specifikációs nyelv és futásidejű ellenőrzési eszköz, amely lehetővé teszi, hogy az okosszerződésekre olyan tulajdonságokat jegyezzen fel, amelyek lehetővé teszik a szerződések automatikus tesztelését olyan eszközökkel, mint a Diligence Fuzzing vagy a MythX._ - -## Kapcsolódó útmutatók {#related-tutorials} - -- [A különböző tesztelési termékek áttekintése és összehasonlítása](/developers/tutorials/guide-to-smart-contract-security-tools/) -- [Echinda használata okosszerződés teszteléshez](/developers/tutorials/how-to-use-echidna-to-test-smart-contracts/) -- [A Manticore használata az okosszerződés hibáinak felderítésére](/developers/tutorials/how-to-use-manticore-to-find-smart-contract-bugs/) -- [A Slither használata okosszerződés bugok felderítésére](/developers/tutorials/how-to-use-slither-to-find-smart-contract-bugs/) -- [Hogyan készítsen másolatot a Solidity szerződésekről teszteléshez](/developers/tutorials/how-to-mock-solidity-contracts-for-testing/) -- [Hogyan végezzen egységteszteket Solidity-ben a Foundry használatával](https://www.rareskills.io/post/foundry-testing-solidity) - -## További olvasnivaló {#further-reading} - -- [Részletes útmutató az Ethereum-okosszerződések teszteléséhez](https://iamdefinitelyahuman.medium.com/an-in-depth-guide-to-testing-ethereum-smart-contracts-2e41b2770297) -- [Hogyan tesztelje az Ethereum-okosszerződéseket](https://betterprogramming.pub/how-to-test-ethereum-smart-contracts-35abc8fa199d) -- [A MolochDAO egységtesztelési útmutatója fejlesztőknek](https://github.com/MolochVentures/moloch/tree/4e786db8a4aa3158287e0935dcbc7b1e43416e38/test#moloch-testing-guide) -- [Hogyan teszteljen okosszerződéseket, mint egy igazi rocksztár](https://forum.openzeppelin.com/t/test-smart-contracts-like-a-rockstar/1001) diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" deleted file mode 100644 index d950801ad44..00000000000 --- "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/upgrading/index.md" +++ /dev/null @@ -1,165 +0,0 @@ ---- -title: Okosszerződések frissítése -description: Az Ethereum okosszerződések frissítési mintáinak áttekintése -lang: hu ---- - -Az Ethereumban az okosszerződések olyan önvégrehajtó programok, amelyek az Ethereum virtuális gépén (EVM) futnak. Ezek a programok eleve megváltoztathatatlanok, ami megakadályozza az üzleti logika frissítését a szerződés telepítése után. - -Bár a megváltoztathatatlanság szükséges a bizalomigény nélküliséghez, decentralizáláshoz és biztonsághoz, bizonyos esetekben hátrányt jelenthet. A megváltoztathatatlan kód például lehetetlenné teheti a fejlesztők számára a sebezhető szerződések javítását. - -Ugyanakkor az okosszerződések javítására irányuló kutatások növekedése számos frissítési minta bevezetéséhez vezetett. Ezek a minták lehetővé teszik a fejlesztők számára az okosszerződések frissítését (a megváltoztathatatlanság megőrzése mellett) azáltal, hogy az üzleti logikát különböző szerződésekben helyezik el. - -## Előfeltételek {#prerequisites} - -Érdemes ismerni az [okosszerződéseket](/developers/docs/smart-contracts/), az [okosszerződések anatómiáját](/developers/docs/smart-contracts/anatomy/) és az [Ethereum virtuális gépet (EVM)](/developers/docs/evm/). Ehhez az útmutatóhoz az is hozzátartozik, hogy az olvasók értenek az okosszerződések programozásához. - -## Mi az az okosszerződés-frissítés? {#what-is-a-smart-contract-upgrade} - -Az okosszerződés frissítése magában foglalja az üzleti logika megváltoztatását, miközben megőrzi a szerződés státuszát. Fontos tisztázni, hogy a frissíthetőség és a változtathatóság nem ugyanaz, különösen az okosszerződéseknél. - -Az Ethereum-hálózat egy adott címére telepített programot továbbra sem lehet megváltoztatni. De megváltoztathatja azt a kódot, amely akkor kerül végrehajtásra, amikor a felhasználók interakcióba lépnek egy okosszerződéssel. - -Ezt a következő módszerekkel teheti meg: - -1. Az okosszerződés több verziójának létrehozása és a státusz (az adatok) migrálása a régi szerződésből az új példányába. - -2. Külön szerződések létrehozása az üzleti logika és a státusz tárolására. - -3. Proxyminták használata a funkcióhívások delegálásához egy megváltoztathatatlan proxyszerződésből egy módosítható logikai szerződésbe. - -4. Egy megváltoztathatatlan főszerződés létrehozása, amely interfészeket hoz létre és rugalmas alszerződésekre támaszkodik bizonyos funkciók végrehajtásához. - -5. A gyémántminta használata funkcióhívások delegálására egy proxyszerződésből logikai szerződésekbe. - -### 1. frissítési mechanizmus: szerződésmigráció {#contract-migration} - -A szerződésmigráció a verziókezelésen alapul – ugyanazon szoftver egyedi státuszainak létrehozásán és kezelésén. A szerződésmigráció magában foglalja egy meglévő okosszerződés új példányának telepítését, valamint a tárolás és az egyenlegek átvitelét az új szerződésre. - -Az újonnan telepített szerződés üres tárolóval rendelkezik, ami lehetővé teszi az adatok visszaállítását a régi szerződésből és írását az új példányba. Ezt követően frissítenie kell az összes olyan szerződést, amely kölcsönhatásba lépett a régivel, hogy tükrözze az új címet. - -A szerződésátállás utolsó lépése, hogy a felhasználókat meggyőzzük az új szerződés használatáról. Az új szerződésváltozat megtartja a felhasználói egyenlegeket és címeket, ami megőrzi a megváltoztathatatlanságot. Ha token-alapú szerződésről van szó, akkor a tőzsdékkel is kapcsolatba kell lépnie, hogy dobják el a régi szerződést és használják az újat. - -A szerződésmigráció egyszerű és biztonságos intézkedés az okosszerződések frissítésére a felhasználói interakciók megszakítása nélkül. A felhasználói tárolók és egyenlegek kézi migrálása az új szerződésre azonban időigényes és magas gázköltségekkel járhat. - -[További információ a szerződésmigrációról.](https://blog.trailofbits.com/2018/10/29/how-contract-migration-works/) - -### 2. frissítési mechanizmus: Az adatok szétválasztása {#data-separation} - -Az okosszerződések frissítésének másik módszere az üzleti logika és az adattárolás külön szerződésekben történő szétválasztása. Ez azt jelenti, hogy a felhasználók a logikai szerződéssel lépnek kapcsolatba, míg az adatokat a tárolási szerződésben tartják. - -A logikai szerződés tartalmazza azt a kódot, amely akkor kerül végrehajtásra, amikor a felhasználók interakcióba lépnek az alkalmazással. A tárolási szerződés címét is tartalmazza, és interakcióba lép vele az adatok lekérdezése és beállítása érdekében. - -Eközben a tárolási szerződés tartja az okosszerződéshez kapcsolódó státuszt, például a felhasználói egyenlegeket és címeket. Megjegyzendő, hogy a tárolási szerződés a logikai szerződés tulajdonában van, és telepítéskor az utóbbi címével van konfigurálva. Ez megakadályozza, hogy illetéktelen szerződések meghívják a tárolási szerződést vagy frissítsék annak adatait. - -Alapértelmezés szerint a tárolási szerződés megváltoztathatatlan, de a logikai szerződést, amelyre mutat, lecserélheti egy új implementációra. Ez megváltoztatja az EVM-ben futó kódot, miközben érintetlenül hagyja a tárolást és az egyenlegeket. - -Ennek a frissítési módszernek a használata a logikai szerződés címének frissítését igényli a tárolási szerződésben. Az új logikai szerződést is be kell konfigurálnia a tárolási szerződés címével a korábban ismertetett okok miatt. - -Az adatszétválasztás mintája könnyebben megvalósítható, mint a szerződésmigráció. Azonban több szerződést kell kezelnie, és összetett engedélyezési sémákat kell megvalósítania, hogy megvédje az okosszerződéseket a rosszindulatú frissítésektől. - -### 3. frissítési mechanizmus: Proxyminták {#proxy-patterns} - -A proxyminta szintén az adatok szétválasztását használja, hogy az üzleti logikát és az adatokat külön szerződésekben tartsa. A proxymintában azonban a tárolási szerződés (a proxyt) a kód végrehajtása során hívja meg a logikai szerződést. Ez az adatok szétválasztásának fordítottja, ahol a logikai szerződés hívja meg a tárolási szerződést. - -Az alábbi történik egy proxymintában: - -1. A felhasználók interakcióba lépnek a proxyszerződéssel, amely tárolja az adatokat, de nem tartalmazza az üzleti logikát. - -2. A proxyszerződés tárolja a logikai szerződés címét, és minden funkcióhívást a logikai szerződéshez (amely az üzleti logikát tartalmazza) delegál a `delegatecall` függvény segítségével. - -3. Miután a hívás továbbításra került a logikai szerződéshez, abból visszakeresésre kerülnek a visszaküldött adatok, és átadja azokat a felhasználónak. - -A proxyminták használata megköveteli a **delegatecall** függvény ismeretét. Alapvetően a `delegatecall` egy olyan opkód, amely lehetővé teszi egy szerződés számára, hogy egy másik szerződést hívjon, miközben a tényleges kódvégrehajtás a hívó szerződés kontextusában történik. A `delegatecall` proxymintákban való használatának egyik következménye, hogy a proxyszerződés olvas és ír a tárolójába, és úgy hajtja végre a logikai szerződésben tárolt logikát, mintha egy belső függvényt hívna. - -A [Solidity dokumentációból](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries): - -> _Létezik az üzenethívásnak egy speciális változata, a **delegatecall**, amely megegyezik az üzenethívással, eltekintve attól, hogy a célcímen lévő kódot a hívó szerződés kontextusában hajtjuk végre (annak címén), és a `msg.sender` és `msg.value` értéke nem változik._ _Ez azt jelenti, hogy egy szerződés futásidőben dinamikusan betölthet kódot egy másik címről. A tárolás, az aktuális cím és az egyenleg továbbra is a hívó szerződésre hivatkozik, csak a kódot a hívott címről veszik._ - -A proxyszerződés tudja, hogy meg kell hívnia a `delegatecall` funkciót, amikor a felhasználó meghív egy függvényt, mert van egy beépített `fallback` függvénye. A Solidity programozásban a [fallback függvény](https://docs.soliditylang.org/en/latest/contracts.html#fallback-function) akkor kerül végrehajtásra, ha a hívás nem felel meg a szerződésben meghatározott függvényeknek. - -A proxyminta működéséhez egyéni fallback függvény írása szükséges, amely meghatározza, hogy a proxyszerződés hogyan kezelje az általa nem támogatott függvényhívásokat. Ebben az esetben a proxy fallback függvénye úgy van programozva, hogy egy delegatecall funkciót kezdeményezzen, és a felhasználó kérését átirányítsa az aktuális logikai szerződés implementációjához. - -A proxyszerződés alapértelmezés szerint megváltoztathatatlan, de új logikai szerződéseket lehet létrehozni frissített üzleti logikával. A frissítés elvégzése a proxyszerződésben hivatkozott logikai szerződés címének megváltoztatásával történik. - -Azáltal, hogy a proxyszerződést egy új logikai szerződésre irányítja, a felhasználók által meghívott függvényeknél végrehajtott kód megváltozik. Ez lehetővé teszi a szerződés logikájának frissítését anélkül, hogy a felhasználóknak egy új szerződéssel kellene interakcióba lépniük. - -A proxyminta népszerű módszer az okosszerződések frissítésére, mivel kiküszöböli a szerződések migrációjával járó nehézségeket. A proxyminták használata azonban bonyolultabb, és helytelen használat esetén kritikus hibákat, például [függvényválasztó ütközéseket](https://medium.com/nomic-foundation-blog/malicious-backdoors-in-ethereum-proxies-62629adf3357) okozhatnak. - -[Bővebben a proxymintákról](https://blog.openzeppelin.com/proxy-patterns/). - -### 4. frissítési mechanizmus: Stratégiaminta {#strategy-pattern} - -Ennek a technikának az alapja a [stratégiaminta](https://en.wikipedia.org/wiki/Strategy_pattern), amely olyan szoftverek létrehozására ösztönöz, amelyek más programokkal kapcsolódnak, hogy bizonyos funkciókat megvalósítsanak. A stratégiaminta alkalmazása az Ethereum-fejlesztésre azt jelentené, hogy olyan okosszerződést kell létrehozni, amely más szerződések függvényeit hívja meg. - -Ebben az esetben a fő szerződés tartalmazza az alapvető üzleti logikát, de bizonyos funkciók végrehajtásához más okosszerződésekkel (szatellit- vagy alszerződésekkel) interfészeket hoz létre. Ez a fő szerződés tárolja az egyes alszerződések címét is, és képes váltani azok különböző implementációi között. - -Létrehozhat egy új alszerződést, és konfigurálhatja a fő szerződést az új címmel. Ez lehetővé teszi az okosszerződési _stratégiák_ megváltoztatását (azaz új logika implementálását). - -Bár hasonló a korábban tárgyalt proxymintához, a stratégiaminta mégis különbözik, mivel a fő szerződés, amellyel a felhasználók interakcióba lépnek, tartalmazza az üzleti logikát. Ennek a mintának a használata lehetőséget biztosít arra, hogy korlátozott változtatásokat hajtson végre egy okosszerződésen anélkül, hogy az alapvető infrastruktúrát befolyásolná. - -A fő hátránya, hogy ez a minta inkább kisebb frissítések bevezetésére alkalmas. Továbbá, ha a fő szerződés veszélybe kerül (például meghackelik), akkor ezt a frissítési módszert nem tudja használni. - -### 5. frissítési mechanizmus: Gyémántminta {#diamond-pattern} - -A gyémántminta a proxyminta továbbfejlesztésének tekinthető. A gyémántminták abban különböznek a proxymintáktól, hogy a gyémánt proxyszerződés egynél több logikai szerződéshez delegálhat függvényhívásokat. - -A gyémántmintában lévő logikai szerződéseket _oldalaknak (facet)_ nevezzük. Ahhoz, hogy a gyémántminta működjön, létre kell hoznia egy olyan leképezést a proxyszerződésben, amely a [függvényválasztókat](https://docs.soliditylang.org/en/latest/abi-spec.html#function-selector) különböző oldalcímekhez rendeli. - -Amikor egy felhasználó függvényhívást hajt végre, a proxyszerződés ellenőrzi a leképezést, hogy megtalálja a függvény végrehajtásáért felelős oldalt. Ezután meghívja a `delegatecall` (a fallback függvényt használva), és a hívást átirányítja a megfelelő logikai szerződéshez. - -A gyémánt frissítési mintának van néhány előnye a hagyományos proxymintákkal szemben: - -1. Lehetővé teszi a szerződés egy kis részének frissítését anélkül, hogy az egész kódot megváltoztatná. A proxyminta használata a frissítésekhez egy teljesen új logikai szerződés létrehozását igényli, még a kisebb frissítések esetében is. - -2. Minden okosszerződés (beleértve a proxymintákban használt logikai szerződéseket is) 24 KB-os méretkorlátozással rendelkezik, ami korlátot jelenthet – különösen a több funkciót igénylő összetett szerződések esetében. A gyémántminta megkönnyíti ennek a problémának a megoldását azáltal, hogy a funkciókat több logikai szerződésre osztja fel. - -3. A proxyminták a hozzáférés-ellenőrzés mindenre kiterjedő megközelítését alkalmazzák. A frissítési funkciókhoz hozzáféréssel rendelkező entitás megváltoztathatja a _teljes_ szerződést. A gyémántminta azonban lehetővé teszi a moduláris jogosultsági megközelítést, ahol az entitások korlátozhatók bizonyos funkciók frissítésére egy okosszerződésen belül. - -[Bővebben a gyémántmintáról](https://eip2535diamonds.substack.com/p/introduction-to-the-diamond-standard?s=w). - -## Az okosszerződések frissítésének előnyei és hátrányai {#pros-and-cons-of-upgrading-smart-contracts} - -| Előnyök | Hátrányok | -| --------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Az okosszerződés frissítése megkönnyítheti a telepítés utáni fázisban felfedezett sebezhetőségek javítását. | Az okosszerződések frissítése tagadja a kód megváltoztathatatlanságának elképzelését, ami hatással van a decentralizációra és a biztonságra. | -| A fejlesztők logikai frissítésekkel új funkciókat adhatnak a decentralizált alkalmazásokhoz. | A felhasználóknak bízniuk kell abban, hogy a fejlesztők nem módosítják önkényesen az okosszerződéseket. | -| Az okosszerződések frissítései javíthatják a végfelhasználók biztonságát, mivel a hibák gyorsan kijavíthatók. | A frissítési lehetőség okosszerződésekbe történő programozása újabb komplexitási réteget jelent, és növeli a kritikus hibák lehetőségét. | -| A szerződésfrissítések nagyobb teret adnak a fejlesztőknek a különböző funkciókkal való kísérletezésre és a dappok jövőbeli javítására. | Az okosszerződések frissítésének lehetősége arra ösztönözheti a fejlesztőket, hogy gyorsabban indítsák el a projekteket, anélkül hogy a fejlesztési fázisban átvilágítást végeznének. | -| | A megbízhatatlan hozzáférés-szabályozás vagy a az okosszerződésekben lévő centralizálás megkönnyítheti a rosszindulatú szereplők számára a jogosulatlan frissítések végrehajtását. | - -## Az okosszerződések frissítésére vonatkozó megfontolások {#considerations-for-upgrading-smart-contracts} - -1. Használjon biztonságos hozzáférés-szabályozási/engedélyezési mechanizmusokat a jogosulatlan okosszerződés-frissítések megakadályozására, különösen, ha proxymintákat, stratégiamintákat vagy adatszétválasztást használ. Példa a frissítési funkcióhoz való hozzáférést úgy korlátozza, hogy csak a szerződés tulajdonosa hívhatja meg azt. - -2. Az okosszerződések frissítése összetett tevékenység, és nagyfokú körültekintést igényel a sebezhetőségek megelőzése érdekében. - -3. Csökkentse a bizalmi feltételezéseket a frissítések decentralizálásával. A lehetséges stratégiák közé tartozik a [több aláírásos (multi-sig) tárcaszerződés](/developers/docs/smart-contracts/#multisig) használata a frissítések ellenőrzésére, vagy a [a DAO tagjainak](/dao/) szavazása a frissítés jóváhagyásáról. - -4. Legyen tisztában a szerződések frissítésének költségeivel. Például a státusz (pl. a felhasználói egyenlegek) átmásolása egy régi szerződésből egy új szerződésbe a migráció során egynél több tranzakciót igényelhet, ami több gázdíjat jelent. - -5. Fontolja meg **időzárak** bevezetését a felhasználók védelme érdekében. Az időzár a rendszerben végrehajtott változtatások késleltetésére utal. Az időzár kombinálható egy több aláírásos irányítási rendszerrel a frissítések ellenőrzésére: ha egy javasolt művelet eléri a szükséges jóváhagyási küszöbértéket, nem hajtják végre, amíg az előre meghatározott késleltetési időszak el nem telik. - -Az időkorlátok időt adnak a felhasználóknak arra, hogy kilépjenek a rendszerből, ha nem értenek egyet egy javasolt változtatással (például logikai frissítés vagy új díjszabás). Az időzítés nélkül a felhasználóknak bízniuk kell abban, hogy a fejlesztők nem hajtanak végre önkényes változtatásokat az okosszerződésben előzetes értesítés nélkül. Ennek hátránya, hogy az időzár korlátozza a sebezhetőségek gyors javításának lehetőségét. - -## Források {#resources} - -**OpenZeppelin Upgrades Plugins – _Egy eszközcsomag a frissíthető okosszerződések telepítéséhez és biztosításához._** - -- [GitHub](https://github.com/OpenZeppelin/openzeppelin-upgrades) -- [Dokumentáció](https://docs.openzeppelin.com/upgrades) - -## Oktatóanyagok {#tutorials} - -- [Az okosszerződések frissítése | YouTube Tutorial](https://www.youtube.com/watch?v=bdXJmWajZRY) Patrick Collinstól -- [Útmutató az Ethereum okosszerződés-migrációról](https://medium.com/coinmonks/ethereum-smart-contract-migration-13f6f12539bd) – Austin Griffith -- [A UUPS proxyminta használata az okosszerződésfrissítéshez](https://blog.logrocket.com/author/praneshas/) – Pranesh A.S -- [Web3-útmutató: frissíthető okosszerződés (proxy) írása az OpenZeppelin használatával](https://dev.to/yakult/tutorial-write-upgradeable-smart-contract-proxy-contract-with-openzeppelin-1916) – fangjun.eth - -## További olvasnivaló {#further-reading} - -- [Az okosszerződés frissítésének helyzetet](https://blog.openzeppelin.com/the-state-of-smart-contract-upgrades/) – Santiago Palladino -- [A Solidity okosszerződés frissítésének módjai](https://cryptomarketpool.com/multiple-ways-to-upgrade-a-solidity-smart-contract/) – Crypto Market Pool blog -- [Tanulja meg: okosszerződések frissítése](https://docs.openzeppelin.com/learn/upgrading-smart-contracts) – OpenZeppelin Docs -- [Proxy-minták a Solidity szerződések frissíthetőségéhez: az átlátható és UUPS proxyk összehasonlítása](https://mirror.xyz/0xB38709B8198d147cc9Ff9C133838a044d78B064B/M7oTptQkBGXxox-tk9VJjL66E1V8BUF0GF79MMK4YG0) – Naveen Sahu -- [Hogyan működik a gyémántfrissítés](https://dev.to/mudgen/how-diamond-upgrades-work-417j) – Nick Mudge diff --git "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" "b/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" deleted file mode 100644 index fb178d4bf47..00000000000 --- "a/public/content/translations/hu/20) Smart Contracts \342\200\223 Advanced/developers/docs/smart-contracts/verifying/index.md" +++ /dev/null @@ -1,107 +0,0 @@ ---- -title: Okosszerződések érvényesítése -description: Az Ethereum okosszerződések forráskódjának ellenőrzési folyamata -lang: hu ---- - -Az [okosszerződéseket](/developers/docs/smart-contracts/) úgy tervezték, hogy „bizalom nélküliek” legyenek, vagyis a felhasználóknak ne kelljen megbízniuk harmadik félben (például fejlesztőkben és vállalatokban), mielőtt kapcsolatba lépnének egy szerződéssel. A bizalomigény nélküliség feltétele, hogy a felhasználók és más fejlesztők képesek ellenőrizni az okosszerződés forráskódját. A forráskód-ellenőrzés biztosítja a felhasználók és a fejlesztők számára, hogy a közzétett szerződéskód ugyanaz, ami a szerződés címén fut az Ethereum blokkláncon. - -Fontos különbséget tenni a forráskód-ellenőrzés és a "[formális ellenőrzés](/developers/docs/smart-contracts/formal-verification/)" között. A forráskód-ellenőrzés, amelyet ez a cikk részletesen ismertet, arra vonatkozik, hogy egy okosszerződés forráskódja egy magas szintű nyelven (mint a Solidity) lefordítható-e ugyanarra a bájtkódra, amelyet a szerződés címén végre kell hajtani. A formális ellenőrzés ugyanakkor az okosszerződés helyességének ellenőrzését írja le, ami azt jelenti, hogy a szerződés az elvárásoknak megfelelően viselkedik. Bár a kontextustól függ, a szerződés-ellenőrzés általában a forráskód ellenőrzésére utal. - -## Mi az a forráskód-ellenőrzés? {#what-is-source-code-verification} - -Mielőtt egy okosszerződést a [Ethereum virtuális gépen (EVM)](/developers/docs/evm/) telepítenének, a fejlesztők [átfordítják](/developers/docs/smart-contracts/compiling/) a szerződés forráskódját – a [Solidity](/developers/docs/smart-contracts/languages/) vagy más magas szintű programozási nyelven írt utasításokat – bájtkódra. Mivel az EVM nem tudja értelmezni a magas szintű utasításokat, a forráskód bájtkódra (azaz alacsony szintű, gépi utasításokra) történő fordítása szükséges a szerződés logikájának EVM-ben való végrehajtásához. - -A forráskód-ellenőrzés az okosszerződés forráskódjának és a szerződés létrehozásakor használt átfordított bájtkódnak az összehasonlítása azért, hogy a lehetséges különbségeket észrevegyék. Az okosszerződések ellenőrzése azért fontos, mert a nyilvánossá tett szerződéskód eltérhet attól, ami a blokkláncon fut. - -Az okosszerződések ellenőrzése lehetővé teszi annak vizsgálatát, hogy mit csinál egy szerződés a magasabb szintű nyelven, amelyen meg van írva, anélkül, hogy gépi kódot kellene olvasni. A függvények, értékek és általában a változók nevei és megjegyzései ugyanazok maradnak, mint a lefordított és telepített eredeti forráskódban. Ez sokkal könnyebbé teszi a kódolvasást. A forráshitelesítés a kód dokumentációját is biztosítja, hogy a végfelhasználók tudják, mire tervezték azt. - -### Mi az a teljes körű ellenőrzés? {#full-verification} - -A forráskódnak vannak olyan részei, amelyek nem befolyásolják a lefordított bájtkódot, mint például a megjegyzések vagy a változónevek. Ez azt jelenti, hogy két különböző változónevű és különböző megjegyzésekkel rendelkező forráskód is képes lenne ugyanazt a szerződést ellenőrizni. Ezzel egy rosszindulatú szereplő megtévesztő megjegyzéseket adhat hozzá vagy félrevezető változóneveket adhat a forráskódon belül, és a szerződést az eredetitől eltérő forráskóddal hitelesítheti. - -Ezt úgy lehet elkerülni, hogy a bájtkódhoz további adatokat csatolunk, amelyek a forráskód pontosságának _kriptográfiai garanciájaként_ és az átfordítási információk _ujjlenyomataként_ szolgálnak. A szükséges információkat a [Solidity szerződési metaadataiban](https://docs.soliditylang.org/en/v0.8.15/metadata.html) találjuk, és ennek a fájlnak a hashe a szerződés bájtkódjához van csatolva. Ezt működés közben is láthatja a [metaadatok játszótéren](https://playground.sourcify.dev) - -A metaadatfájl tartalmazza a szerződés összeállítására vonatkozó információkat, beleértve a forrásfájlokat és azok hashét is. Ez azt jelenti, hogy ha bármelyik fordítási beállítás vagy akár csak egy bájt is megváltozik az egyik forrásfájlban, a metaadatfájl is megváltozik. Következésképpen a bájtkódhoz csatolt metaadatfájl hashe is megváltozik. Ez azt jelenti, hogy ha egy szerződés bájtkódja és a hozzáfűzött metaadatok hashe egyezik a megadott forráskóddal és az átfordítási beállításokkal, akkor ez pontosan ugyanaz a forráskód, amit az eredeti fordítás során használtunk, és egyetlen bájt sem különbözik. - -Ezt a metaadatok hashét használó ellenőrzést nevezzük **"[teljes vagy tökéletes ellenőrzésnek](https://docs.sourcify.dev/docs/full-vs-partial-match/)"**. Ha a metaadathashek nem egyeznek, vagy nem veszik figyelembe az ellenőrzés során, akkor „részleges egyezésről” van szó, ami jelenleg a szerződésellenőrzés elterjedtebb módja. Lehetőség van [olyan rosszindulatú kód](https://samczsun.com/hiding-in-plain-sight/) beillesztésére, amelyet csak a teljes ellenőrzés mutat ki. A legtöbb fejlesztő nem ismeri a teljes ellenőrzést, és nem őrzi meg az átfordítás metaadatfájlját, ezért eddig a részleges ellenőrzés volt az alapvető módszer. - -## Miért fontos a forráskód-ellenőrzés? {#importance-of-source-code-verification} - -### Bizalomigénytől való mentesség {#trustlessness} - -A bizalomigénytől való mentesség az okosszerződések és a [decentralizált alkalmazások (dapp)](/developers/docs/dapps/) legfontosabb előfeltétele. Az okosszerződések alapvetően megváltoztathatatlanok, nem módosíthatók; egy szerződés a telepítés időpontjában a kódban meghatározott üzleti logikát hajtja végre. Ez azt jelenti, hogy a fejlesztők és a vállalatok nem tudják manipulálni a szerződés kódját az Ethereumra való telepítés után. - -Ahhoz, hogy egy okosszerződés megbízható legyen, a szerződés kódjának elérhetőnek kell lennie független ellenőrzésre. Bár minden okosszerződés lefordított bájtkódja nyilvánosan elérhető a blokkláncon, az alacsony szintű nyelv nehezen érthető a fejlesztők és a felhasználók számára. - -A projektek a szerződések forráskódjának közzétételével csökkentik a bizalmi feltételezéseket. Ez azonban egy másik problémához vezet: nehéz ellenőrizni, hogy a közzétett forráskód megegyezik-e a szerződéses bájtkóddal. Ebben a forgatókönyvben a bizalomigénytől való mentesség elvész, mivel a felhasználóknak meg kell bízniuk a fejlesztőkben, hogy nem változtatják meg a szerződés üzleti logikáját (például a bájtkód megváltoztatásával), mielőtt azt a blokkláncra telepítenék. - -A forráskód-ellenőrző eszközök garanciát nyújtanak arra, hogy az intelligens szerződés forráskódfájljai megegyeznek az assembly (összeszerelési) kóddal. Az eredmény egy bizalomigény nélküli ökoszisztéma, ahol a felhasználók nem bíznak vakon harmadik félben, hanem a kódot ellenőrzik, mielőtt pénzt helyeznének el egy szerződésben. - -### Felhasználói biztonság {#user-safety} - -Az okosszerződések esetében sok pénz foroghat kockán. Ez magasabb biztonsági garanciákat és az okosszerződés logikájának ellenőrzését igényli a használat előtt. A probléma az, hogy a rosszhiszemű fejlesztők megtéveszthetik a felhasználókat azzal, hogy rosszindulatú kódot illesztenek az okosszerződésbe. Ellenőrzés nélkül a rosszindulatú okosszerződések [hátsó ajtókkal](https://www.trustnodes.com/2018/11/10/concerns-rise-over-backdoored-smart-contracts), ellentmondásos hozzáférés-szabályozási mechanizmusokkal, kihasználható sebezhetőségekkel és egyéb, a felhasználók biztonságát veszélyeztető dolgokkal rendelkezhetnek, amelyek észrevétlenül maradnának. - -Az okosszerződés forráskódfájljainak közzététele megkönnyíti az érdeklődők, például az auditorok számára, hogy értékeljék a szerződést a potenciális támadási vektorok szempontjából. Ha több fél egymástól függetlenül ellenőrzi az okosszerződést, a felhasználók nagyobb garanciát kapnak annak biztonságára. - -## Hogyan ellenőrizhetjük az Ethereum okosszerződések forráskódját {#source-code-verification-for-ethereum-smart-contracts} - -[Egy okosszerződés Ethereumon történő telepítéséhez](/developers/docs/smart-contracts/deploying/) egy tranzakciót kell elküldeni egy speciális címre, amely egy adatcsomagot (lefordított bájtkódot) tartalmaz. Az adatcsomag úgy jön létre, hogy a forráskódot átfordítják, valamint hozzáillesztik a tranzakcióban az adatcsomaghoz csatolt szerződéspéldány [konstruktori argumentumait](https://docs.soliditylang.org/en/v0.8.14/contracts.html#constructor). A fordítás determinisztikus, ami azt jelenti, hogy mindig ugyanazt a kimenetet (azaz szerződéses bájtkódot) produkálja, ha ugyanazokat a forrásfájlokat és fordítási beállításokat (például fordítóverzió, optimalizáló) használjuk. - -![Az okosszerződés forráskódjának ellenőrzését bemutató diagram](./source-code-verification.png) - -Az okosszerződés ellenőrzése alapvetően a következő lépésekből áll: - -1. A forrásfájlok és a fordítási beállítások bevitele a fordítóprogramba. - -2. A fordító kiadja a szerződés bájtkódját - -3. A telepített szerződés bájtkódjának lekérdezése egy adott címen - -4. A telepített bájtkód összehasonlítása az újrafordított bájtkóddal. Ha a kódok egyeznek, a szerződés a megadott forráskóddal és a fordítási beállításokkal kerül ellenőrzésre. - -5. Továbbá, ha a metaadatok hashe a bájtkód végén megegyezik, akkor ez egy teljes egyezés. - -Vegye figyelembe, hogy ez egy leegyszerűsített leírása az ellenőrzésnek, és számos olyan kivétel van, amelyek nem működik ilyen módon, mint például a [megmásíthatatlan változók](https://docs.sourcify.dev/docs/immutables/). - -## Forráskód-ellenőrző eszközök {#source-code-verification-tools} - -A szerződések ellenőrzésének hagyományos folyamata összetett lehet. Ezért vannak eszközeink az Ethereumon telepített okosszerződések forráskódjának ellenőrzésére. Ezek az eszközök automatizálják a forráskód-ellenőrzés nagy részét, és a felhasználók számára előnyös, ellenőrzött szerződéseket is összeállítanak. - -### Etherscan {#etherscan} - -Bár leginkább [Ethereum-blokkláncfelfedezőként](/developers/docs/data-and-analytics/block-explorers/) ismerik, az Etherscan [forráskód-ellenőrzési szolgáltatást](https://etherscan.io/verifyContract) is kínál az okosszerződések fejlesztőinek és felhasználóinak. - -Az Etherscan lehetővé teszi a szerződés bájtkódjának újrafordítását az eredeti adatcsomagból (forráskód, könyvtárcím, fordítói beállítások, szerződés címe stb.). Ha az újrafordított bájtkód a láncon belüli szerződés bájtkódjához (és konstruktor paramétereihez) kapcsolódik, akkor [a szerződés ellenőrzött](https://info.etherscan.com/types-of-contract-verification/). - -Ezt követően az Ön szerződésének forráskódja megkapja az „Ellenőrzött” címkét, és közzéteszik az Etherscan oldalon, hogy mások is ellenőrizhessék. A szerződés bekerül a [Hitelesített szerződések](https://etherscan.io/contractsVerified/) szekcióba, vagyis az ellenőrzött forráskódú okosszerződések tárházába. - -Az Etherscan a leggyakrabban használt eszköz a szerződések ellenőrzésére. Az Etherscan szerződés-ellenőrzésének azonban van egy hátránya: nem hasonlítja össze a láncon belüli és az újrafordított bájtkód **metaadat hash** értékét. Ezért az Etherscanben szereplő egyezések részlegesek. - -[Bővebben a szerződések ellenőrzéséről az Etherscanen](https://medium.com/etherscan-blog/verifying-contracts-on-etherscan-f995ab772327). - -### Sourcify {#sourcify} - -A [Sourcify](https://sourcify.dev/#/verifier) egy másik nyílt forráskódú és decentralizált eszköz a szerződések ellenőrzésére. Ez nem blokkfelfedező, és csak a [különböző EVM-alapú hálózatokon](https://docs.sourcify.dev/docs/chains) kötött szerződéseket ellenőrzi. Nyilvános infrastruktúraként működik, amelyre más eszközök építhetnek, és célja, hogy a metaadatfájlban található [ABI](/developers/docs/smart-contracts/compiling/#web-applications) és [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) megjegyzések segítségével felhasználóbarát szerződéses interakciókat tegyen lehetővé. - -Az Etherscannal ellentétben a Sourcify támogatja a metaadatok hashsel való teljes egyeztetést. Az ellenőrzött szerződéseket a [nyilvános adattárban](https://docs.sourcify.dev/docs/repository/) HTTP-n és [IPFS-en](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs), egy decentralizált, [tartalomcímzett](https://web3.storage/docs/concepts/content-addressing/) tárolóban jeleníti meg. Ez lehetővé teszi egy szerződés metaadatfájljának IPFS-en keresztüli lehívását, mivel a csatolt metaadat hash egy IPFS hash. - -Ezenkívül a forráskódfájlokat is lekérdezhetjük az IPFS-en keresztül, mivel a metaadatokban megtalálhatók ezen fájlok IPFS hashei is. Egy szerződés a metaadatfájl és a forrásfájlok megadásával is ellenőrizhető az API vagy [UI](https://sourcify.dev/#/verifier) révén, illetve a bővítmények használatával. A Sourcify monitoring eszköz figyeli az új blokkok szerződéseinek létrehozását is, és megpróbálja ellenőrizni a szerződéseket, ha azok metaadatait és forrásfájljait közzéteszik az IPFS-en. - -[Bővebben a szerződések ellenőrzéséről a Sourcify oldalon](https://blog.soliditylang.org/2020/06/25/sourcify-faq/). - -### Tenderly {#tenderly} - -A [Tenderly platform](https://tenderly.co/) lehetővé teszi a web3-fejlesztők számára az okosszerződések létrehozását, tesztelését, felügyeletét és működtetését. A Tenderly segít a fejlesztőknek felgyorsítani az okosszerződések fejlesztését úgy, hogy a hibakeresési eszközöket a megfigyelhetőséggel és az infrastrukturális építőelemekkel kombinálja. A Tenderly funkcióinak teljes körű használatához a fejlesztőknek [a forráskód ellenőrzését](https://docs.tenderly.co/monitoring/contract-verification) többféle módszerrel kell elvégezniük. - -Lehetőség van a szerződés privát vagy nyilvános ellenőrzésére. Privát ellenőrzés esetén az okosszerződés csak Ön (és a projekt többi tagja) számára látható. A szerződés nyilvános ellenőrzése mindenkinek látható lesz, aki a Tenderly platformot használja. - -Szerződéseit a [Dashboard](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract), a [Tenderly Hardhat plugin](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin) vagy a [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli) segítségével ellenőrizheti. - -Ha a szerződéseket a Dashboardon keresztül ellenőrzi, importálnia kell a forrásfájlt vagy a Solidity fordító által generált metaadatfájlt, a címet/hálózatot és a fordító beállításait. - -A Tenderly Hardhat-plugin használata lehetővé teszi, hogy kevesebb erőfeszítéssel nagyobb kontrollt gyakoroljon az ellenőrzési folyamat felett, mivel automatikus (kód nélküli) és kézi (kódalapú) ellenőrzést is választhat. - -## További olvasnivaló {#further-reading} - -- [A szerződés forráskódjának ellenőrzése](https://programtheblockchain.com/posts/2018/01/16/verifying-contract-source-code/) diff --git a/public/content/translations/hu/21) Whitepaper/whitepaper/index.md b/public/content/translations/hu/21) Whitepaper/whitepaper/index.md deleted file mode 100644 index e05849c4fc2..00000000000 --- a/public/content/translations/hu/21) Whitepaper/whitepaper/index.md +++ /dev/null @@ -1,517 +0,0 @@ ---- -title: Ethereum fehérkönyv -description: Az Ethereum működéséről szóló kiadvány, melyet 2013-ban adtak ki az indulása előtt. -lang: hu -sidebarDepth: 2 -hideEditButton: true ---- - -# Ethereum fehérkönyv {#ethereum-whitepaper} - -_Ezt a bemutató kiadványt eredetileg 2014-ban adta ki Vitalik Buterin, az [Ethereum](/what-is-ethereum/) alapítója, a projekt 2015-ös indulása előtt. Fontos megjegyezni, hogy az Ethereum sok másik közösség által vezetett, nyílt forráskódú szoftver projekthez hasonlóan, a kezdeti elindulás óta fejlődött._ - -_Noha több éve íródott, fenntartjuk ezt a kiadványt, mert továbbra is hasznos referenciaként szolgál és pontos ábrázolást mutat az Ethereumról és annak jövőképéről. Ha többet szeretne megtudni az Ethereum legutóbbi fejlesztéseiről és az általunk elvégzett protokollváltoztatásokról, akkor ezt az [útmutatót](/learn/) ajánljuk._ - -[Azoknak a kutatóknak és egyetemi oktatóknak, akik a (2014. decemberi) fehérkönyv előzmény- vagy kanonikus változatát keresik, érdemes ezt a PDF-et használni.](./whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf) - -## Okosszerződés- és decentralizált alkalmazásplatform következő generációja {#a-next-generation-smart-contract-and-decentralized-application-platform} - -Satoshi Nakamoto 2009-ben történő Bitcoin fejlesztését gyakran a pénz és a pénznem radikális fejlesztésének nevezték, ez az első példa egy olyan digitális eszközre, amelynek egyszerre nincs mögöttes vagy [belső értéke](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/), valamint nincs központi kibocsájtója vagy irányítója. A Bitcoin kísérlet másik – vitathatatlanul fontosabb – része azonban az alapjául szolgáló blokklánc-technológia, mint az elosztott konszenzus eszköze, és a figyelem gyorsan elkezdett áttérni ezen másik aspektusra. A blokklánc-technológiát alternatív módon alkalmazzák arra, hogy a blokkláncra épülő digitális eszközök egyéni valutákat és pénzügyi eszközöket ([színes érmék](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit)), fizikai eszköz tulajdonjogát ([okosingatlan](https://en.bitcoin.it/wiki/Smart_Property)), nem helyettesíthető eszközöket, például domainneveket ([Namecoin](http://namecoin.org)) képviselnek, emellett összetettebb alkalmazásokat működtetnek, amelyekben a digitális eszközöket közvetlenül egy tetszőleges szabályokat végrehajtó kódrészlet irányítja ([okosszerződések](http://www.fon.hum.uva.nl/rob/Courses/InformationInSpeech/CDROM/Literature/LOTwinterschool2006/szabo.best.vwh.net/idea.html)), vagy akár blokkláncalapú [decentralizált autonóm szervezeteket (DAO)](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) is alapíthatnak. Az Ethereum egy olyan beépített, teljesen kidolgozott Turing-teljes programozási nyelvvel rendelkező blokkláncot szeretne nyújtani, amely olyan „szerződések” létrehozására használható, amelyek tetszőleges státuszváltozási funkciók kódolására használhatók, lehetővé téve a felhasználók számára a fent leírt rendszerek bármelyikének létrehozását, valamint sok olyan más dolgot is, amelyre még nem gondoltunk, egyszerűen pár sornyi kódba foglalva az adott logikát. - -## Bevezetés a Bitcoinba és kapcsolódó koncepciókba {#introduction-to-bitcoin-and-existing-concepts} - -### Előzmények {#history} - -A decentralizált digitális valuta, valamint az alternatív alkalmazások, például az ingatlannyilvántartások fogalma évtizedek óta létezik. Az 1980-as és 1990-es évek anonim e-cash protokolljai, melyek főleg a Chaum-féle vakításként ismert kriptográfiai primitívre támaszkodtak, egy magas fokú adatvédelemmel rendelkező valutát kínáltak, de a protokolloknak többnyire nem sikerült elterjedniük, mivel egy centralizált közvetítőre támaszkodtak. 1998-ban Wei Dai [b-money](http://www.weidai.com/bmoney.txt) pénze volt az első javaslat a pénz létrehozására számítási kirakósok megoldásával és decentralizált konszenzussal, de nem igazán volt kidolgozva az a része, hogy miként lehetne az utóbbit megvalósítani a gyakorlatban. 2005-ben Hal Finney bemutatta az [újrafelhasználható proof of work-öket (munkabizonyítékokat)](https://nakamotoinstitute.org/finney/rpow/), egy olyan rendszert, amely a b-money pénzből származó ötleteket és Adam Back számítási szempontból nehéz Hashcash rejtvényeit használta fel a kriptovaluta koncepciójának megalkotására, de az ideálistól elmaradt azáltal, hogy egy megbízható számítási háttérre támaszkodott. Először 2009-ben vezetett be Satoshi Nakamoto a gyakorlatban egy decentralizált valutát, amely egyesítette az alapként szolgáló létező primitíveket a tulajdonjog nyilvánoskulcs-kriptográfiával történő kezelésére – egy konszenzus algoritmussal – az érmék tulajdonosainak számontartására, amelyet „proof-of-worknek” (munkabizonyíték) nevezünk. - -A proof-of-work mögötti mechanizmus egy áttörés volt, mivel egyszerre két problémára is megoldást nyújtott. Egyrészt egy olyan egyszerű és mérsékelten hatékony konszenzusalgoritmust biztosított, amely lehetővé teszi a hálózat csomópontjainak, vagyis a résztvevő számítógépeknek (csomópontoknak), hogy kollektíven egyetértsenek a Bitcoin főkönyvi állapotának kanonikus frissítéseiről. Másrészt egy olyan mechanizmust biztosított, amely szabad belépést tett lehetővé abba a konszenzusfolyamatba, amely megoldja annak a politikai problémának az eldöntését, hogy ki befolyásolja a konszenzust, emellett a Sybil-támadásokat is megelőzi. Ehhez a részvétel formális akadályát – mint például egy listán egyedi entitásként való nyilvántartás követelményét – gazdasági akadályokkal helyettesíti: egy résztvevő csomópont súlya a konszenzusos szavazási folyamatban közvetlenül arányos azzal a számítási erővel, amivel a csomópont rendelkezik. Azóta javaslattétel is született egy alternatív megközelítésre, amelyet _proof-of-stake-nek_, azaz letéti bizonyítéknak neveznek, mivel a hálózaton résztvevő számítógép vagy csomópont súlyozását a valuta letétbe helyezésének arányában számítja ki, nem a számítási kapacitása alapján; a két megközelítés relatív előnyeinek megvitatása túlmutat a cikk keretein, ugyanakkor mindkét megközelítés felhasználható egy kriptovaluta alapjaként. - -### Bitcoin mint egy státuszváltozási rendszer {#bitcoin-as-a-state-transition-system} - -![Ethereum állapot átmenet](./ethereum-state-transition.png) - -Technikai szempontból egy kriptovaluta, például a Bitcoin főkönyve egy státuszváltozási rendszernek tekinthető, ahol van egy státusz, amely számon tartja az összes létező bitcoin tulajdonosi állapotát, és egy státuszváltozási függvény, ami a státusz és a tranzakció hozzáadásával egy új státuszt eredményez. Például egy szabályos banki rendszerben a státusz a vagyonmérlegnek felel meg, a tranzakció egy kérvény $X összeg átmozgatására A-ból B-be, a státuszváltozási függvény pedig csökkenti A számlájának értékét $X összeggel és növeli B számlájának értékét $X összeggel. Ha az A számla kevesebb összeggel rendelkezik mint $X, akkor a státuszváltozási függvény hibajelzést ad vissza. Tehát így definiálható formálisan: - -``` -APPLY(S,TX) -> S' or ERROR -``` - -A fentiekben leírt banki rendszerben: - -```js -APPLY({ Alice: $50, Bob: $50 },"küld $20 Alice-tól Bob-nak") = { Alice: $30, Bob: $70 } -``` - -De: - -```js -APPLY({ Alice: $50, Bob: $50 },"küld $70 Alice-tól Bob-nak") = ERROR -``` - -A Bitcoin státusza az összes kibányászott és el nem költött érme együttvéve (technikailag az „elköltetlen tranzakciós kimenetek” vagy UTXO). Minden UTXO-nak van egy névértéke és egy tulajdonosa (melyet egy 20 bájtos cím határoz meg, lényegében egy kriptográfiai nyilvános kulcs[fn1](#jegyzetek)). Egy tranzakció egy vagy több bemenetet tartalmaz, és mindegyik bemenet tartalmaz egy meglévő UTXO-ra mutató hivatkozást, valamint egy kriptográfiai aláírást, amelyet a tulajdonos címéhez társított privát kulcs hoz létre, és egy vagy több kimenetet, ahol minden egyes kimenet egy új UTXO-t tartalmaz, amik aztán hozzáadódnak a státuszhoz. - -A státuszváltozási függvény `APPLY(S,TX) -> S'` a következő módon definiálható: - -
    -
  1. - Minden egyes bemenetre a TX-ben: -
      -
    • - Ha a hivatkozott UTXO nincs benne az S-ben, hibát küld vissza. -
      • -
    • - Ha a szolgáltatott aláírás nem egyezik az UTXO tulajdonosának aláírásával, hibát küld vissza. -
      • -
    -
    2. -
  2. - Ha az összes bemeneti UTXO összege kisebb, mint az összes kimeneti UTXO egység összege, hibát küld vissza. -
    3. -
  3. - S-t küld vissza az összes bemeneti UTXO elvételével és az összes UTXO hozzáadásával. -
    4. -
- -Az első lépés első fele megakadályozza, hogy a tranzakciók feladói nem létező érméket költsenek el, az első lépés második fele pedig megakadályozza, hogy a tranzakciók feladói mások érméit költsék el, a második lépés pedig az érték megőrzését hajtja végre. Ahhoz, hogy ezt fizetésnél használjuk, a protokoll a következő. Tegyük fel, hogy Alice 11,7 BTC-t szeretne Bob-nak átutalni. Először Alice megkeresi az általa birtokolt elérhető UTXO-k egy olyan halmazát, melynek összege legalább 11.7 BTC. A valóságban Alice nem fog pont 11.7 BTC-t találni; mondjuk, hogy a legkisebb, amit megtalált 6+4+2=12. Ezután elkészít egy tranzakciót ezzel a három bemenettel és két kimenettel. Az első kimenet 11.7 BTC lesz, aminek Bob címe lesz a tulajdonosa, a második kimenet pedig a maradék 0.3 BTC "visszajáró", melynek maga Alice a tulajdonosa. - -### Bányászat {#mining} - -![Ethereum blokkok](./ethereum-blocks.png) - -Ha hozzáférnénk egy megbízható, központosított szolgáltatáshoz, ezt a rendszert egyértelmű lenne megvalósítani; mivel pontosan a leírtak szerint lehetne kódolni egy központosított, azaz centralizált szerver merevlemezén tárolva az állapotot. Azonban a Bitcoin egy decentralizált pénzrendszert próbált kiépíteni, így a státuszváltozási rendszert egy konszenzusrendszerrel kell kombinálni, hogy biztosítsa, hogy mindenki egyetért a tranzakciók sorrendjével. A Bitcoin decentralizált konszenzus folyamata elvárja a hálózat résztvevőitől, hogy folyamatosan tranzakciókból álló csomagokat próbáljanak készíteni, melyeket '"blokkoknak" hívunk. A hálózat nagyjából egy blokkot szándékozik gyártani minden tizedik percben, ahol minden egyes blokk tartalmaz egy időbélyeget, egy nonce-t, egy hivatkozást az előző blokkra (vagyis hash-t), és az összes olyan tranzakciót tartalmazó listát, melyek az előző blokk után következtek. Idővel egy tartós, folyamatosan növekvő "blokklánc" jön létre, mely folyamatosan frissül, hogy a Bitcoin főkönyv legutóbbi állapotát reprezentálja. - -A blokkok érvényességét ellenőrző algoritmust az alábbi paradigma szerint lehet kifejezni: - -1. Ellenőrzi, hogy a blokk által hivatkozott előző blokk létezik és érvényes. -2. Ellenőrzi, hogy a blokk időbélyege későbbi-e, mint az előző blokké[fn2](#jegyzetek) és kevesebb mint 2 óra telt-e el azóta -3. Ellenőrzi, hogy a blokk proof-of-workje érvényes-e. -4. Legyen `S[0]` az előző blokk után lévő státusz. -5. Legyen `TX` a blokk tranzakciós listája `n` tranzakcióval. Minden `i`-re `0...n-1`-ig legyen beállítva `S[i+1] = APPLY(S[i],TX[i])`. Ha bármely lépés hibát ad vissza, kilép és hamis értéket ad vissza. -6. Igaz értéket ad vissza, és `S[n]`-t regisztrál státuszként a blokk végén. - -Lényegében a blokkban szereplő minden tranzakciónak érvényes státuszváltozást kell biztosítania a tranzakció lefutása előtti kanonikus állapotból egy új állapotba. Fontos megjegyezni, hogy a státusz nincs belekódolva a blokkba; pusztán absztrakció, amelyre a hálózat érvényesítő résztvevőjének emlékeznie kell, és bármely blokkra (biztonságosan) csak akkor számítható ki, ha a kezdeti státuszból indulunk ki, és minden tranzakciót egymás után lefuttatunk minden blokkban. Továbbá meg kell jegyezni, hogy az is számít, hogy a bányász a tranzakciókat milyen sorrendben helyezte el a blokkban; ha van két olyan A és B tranzakció a blokkban, ahol B az A által létrehozott UTXO-t költi el, a blokk akkor lesz érvényes, ha A előbb van mint B, fordítva nem. - -A fenti listában szereplő érvényességi feltételek közül egyedül a "munkabizonyíték" szükségessége nem található meg más rendszereknél. A pontos feltétel pedig az, hogy minden blokk dupla-SHA256 hashének, melyet egy 256 bites számként kezelünk, kisebbnek kell lennie, mint egy dinamikusan beállított célérték, mely ennek az anyagnak a megírása közben 2187. Ennek a célja, hogy a blokk létrehozása számítási szempontból "nehéz" legyen, és hogy ezáltal megakadályozza a sybil-támadókat, hogy átalakítsák a teljes blokkláncot a saját érdekükben. Mivel az SHA256-ot úgy tervezték, hogy egy teljesen megjósolhatatlan álvéletlen (pszeudo-random) függvény legyen, így a blokk létrehozásának egyetlen módja a próbaszerencse (trial and error), vagyis ismételten növelni kell a nonce-t és figyelni, hogy az új hash megfelelő-e. - -A jelenlegi 2187-es cél esetében, a hálózatnak átlagosan \~269 próbálkozást kell tennie, mielőtt valaki egy érvényes blokkot találna; általánosságban a hálózat minden 2016 blokk után újrakalibrálja a célt azért, hogy a hálózat egy résztvevője átlagosan minden tizedik percben egy új blokkot hozzon létre. Azért, hogy a bányászok kompenzálva legyenek ezért a számítási munkáért, minden blokk bányászát megilleti, hogy egy olyan tranzakciót tegyen a blokkba, amiben jóváír magának 12.5 BTC-t a semmiből. Továbbá ha bármely tranzakciónak nagyobb bemeneti egysége van, mint kimeneti, akkor a különbség a bányászokhoz került, mint egy "tranzakciós díj". Tulajdonképpen ez a BTC kibocsátásának egyetlen módja; a kezdeti állapot egyáltalán nem tartalmazott érméket. - -Hogy jobban megértsük a bányászat célját, nézzük meg, hogy mi történik egy rosszindulatú támadás esetében. Mivel a Bitcoin mögötti kriptográfia közismerten biztonságos, a támadó a rendszer azon részét fogja célba venni, melyet nem véd közvetlenül kriptográfia: a tranzakciók sorrendjét. A támadó stratégiája egyszerű: - -1. 100 BTC elküldése egy kereskedőnek valamilyen termékért cserébe (ideálisan egy digitális termék, gyors hozzáféréssel) -2. Megvárni amíg megérkezik a termék -3. Egy másik tranzakció létrehozása, amiben ugyanazt a 100 BTC-t küldi el magának -4. Meggyőzni a hálózatot, hogy a saját magának intézett tranzakció volt előbb. - -Amint az 1. lépés befejeződött, pár perc múlva valamelyik bányász beteszi a tranzakciót egy blokkba, mondjuk a 270 000-es számúba. Nagyjából egy órával később, ezután a blokk után öt új blokk kerül hozzáadásra a lánchoz, és minden egyes blokk közvetetten hivatkozik a tranzakcióra, így "megerősítve" azt. Ezen a ponton a kereskedő elfogadja a kifizetést véglegesítettként és kiszállítja a terméket; mivel feltételezzük, hogy ez egy digitális termék, a szállítás azonnali. Ekkor a támadó egy új tranzakciót hoz létre, amiben 100 BTC-t küld magának. Ha a támadó egyszerűen elküldené a tranzakciót a világba, nem kerülne feldolgozásra; mert a bányászok megpróbálják futtatni az `APPLY(S,TX)` függvényt és észreveszik, hogy a `TX` egy olyan UTXO-t akar felhasználni, ami már nem létezik a státusz szerint. Ehelyett a támadó csinál egy blokkláncelágazást (fork) úgy, hogy a 270-es blokknak egy új verzióját kezdi el bányászni, ami ugyanarra a 269-es „szülőblokkra” épül, de a régi helyett egy új tranzakcióval. Mivel a blokk adata különböző, így újra kell csinálni a proof-of-work-öt (munkaigazolás). Továbbá a támadó 270-es számú új blokk verziója egy különböző hash-sel rendelkezik, így az eredeti blokkok 271-től 275-ig nem "hivatkoznak" rá; így az eredeti lánc és a támadó új lánca teljesen különböző. Az a szabály, hogy az elágazásban a hosszabb blokkláncot kell igaznak tekinteni, így a törvényesen bányászók a 275-ös láncon fognak tovább dolgozni, míg a támadó egyedül dolgozik a 270-es láncon. Ahhoz, hogy a támadó saját blokkláncát tehesse a leghosszabbá, több számítási kapacitással kell rendelkeznie, mint a hálózat többi résztvevőjének együttvéve, hogy utolérhesse őket (innen ered az "51%-os támadás"). - -### Merkle-fák {#merkle-trees} - -![SPV Bitcoin-ban](./spv-bitcoin.png) - -_Bal: elegendő a csomópontok egy kis számát prezentálni a Merkle fában, hogy bizonyítsuk egy ág érvényességét._ - -_Jobb: bármely kísérlet, mely a Merkle fa egy részének megváltoztatására irányul, végül következetlenséghez fog vezetni valahol a láncon._ - -A Bitcoin egyik fontos skálázhatósági tulajdonsága, hogy a blokk egy több szintes adatstruktúrában van tárolva. A blokk hash valójában csak a blokk fejléc hashe, ez megközelítőleg 200 bájt adatot jelent, mely tartalmazza az időbélyeget, a nonce-t, az előző blokk hashét és a Merkle fának nevezett adat struktúra gyökér hashét, mely a blokkban lévő összes tranzakciót tárolja. A Merkle fa egyfajta bináris fa, ami csomópontokból áll; jelentős számú levél csomópontból a fa alján, amik az alapul szolgáló adatokat tartalmazzák, egy sor középső csomópontból, ahol minden csomópont két gyerekének a hashe, és végül egy gyökér csomópontból, amely szintén két gyerekének a hashéből keletkezett, és a fa "tetejét" reprezentálja. A Merkle fa célja, hogy lehetővé tegye a blokkban lévő adatok feldarabolását: egy csomópont letöltheti csak a blokk fejlécet egy forrásból; a fának számára releváns kis részét pedig egy másik forrásból, és mégis biztos lehet az adat helyességében. Az ok amiért ez működik az a hashek felfelé terjedése: ha egy rosszindulatú felhasználó megpróbál betenni egy hamis tranzakciót a Merkle fa aljára, az változást indít el az eggyel feljebb lévő csomópontban, mely megváltoztatja az afelett lévő csomópontot, végül a gyökér csomópont is megváltozik, így ezzel a blokk hash is, ebből kifolyólag a protokoll egy teljesen másik blokként regisztrálja azt (szinte biztosan érvénytelen munkabizonyítékkal). - -A Merkle fa protokoll vitathatatlanul elengedhetetlen a hosszú távú fenntarthatósághoz. Egy "teljes csomópontnak" a Bitcoin hálózatban, az amelyik az összes blokk egészét tárolja és feldolgozza, körülbelül 15 GB lemezterülettel kell rendelkeznie a Bitcoin hálózatban 2014 áprilisában, és ez havonta 1 GB-tal nő. Jelenleg ezt csak bizonyos asztali számítógépek tudják megvalósítani, telefonok nem, és a jövőben csak vállalkozások és hobbisták lesznek képesek részt venni. Egy "egyszerűsített fizetési hitelesítésnek (SPV)" nevezett protokoll lehetővé teszi egy másik csomópont típus létezését, melyeket "könnyű csomópontoknak" hívunk, ezek a hálózati résztvevők csak a blokk fejléceket töltik le, hitelesítik a munkabizonyítékot a blokk fejléceken és csak a számukra releváns tranzakciókhoz tartozó "ágakat" töltik le. Ez lehetővé teszi a könnyű csomópontoknak, hogy erős biztonsági garanciával meghatározhassák bármelyik Bitcoin tranzakció állapotát és aktuális egyenlegét, miközben a teljes blokklánc csak nagyon kis részét töltik le. - -### Alternatív blokkláncalkalmazások {#alternative-blockchain-applications} - -A mögöttes blokklánc másfajta koncepciókra történő alkalmazásának ötlete szintén hosszú történelemmel bír. 2005-ban Nick Szabo kiadta a [tulajdonosi jogokkal rendelkező biztonságos tulajdonok](https://nakamotoinstitute.org/secure-property-titles/) koncepciójával foglalkozó kiadványt. Ez a dokumentum leírja, hogy az „újdonságok a replikált adatbázis-technológiában” miként tesznek lehetővé egy blokkláncalapú rendszert, amely nyilvántartja, hogy ki milyen földterülettel rendelkezik, létrehozva ezzel egy kidolgozott keretrendszert, amely magában foglalja az olyan fogalmakat, mint a lakhatás, a hátrányos birtoklás és a grúz földadó. Abban az időben sajnos nem állt rendelkezésre hatékony replikált adatbázis-rendszer, ezért a protokollt a gyakorlatban soha nem valósították meg. 2009-től azonban a Bitcoin decentralizált konszenzusának kialakulása után számos alternatív alkalmazás kezdett gyorsan megjelenni. - -- **Namecoin** – a 2010-ben létrehozott [Namecoint](https://namecoin.org/) legjobban egy decentralizált névregisztrációs adatbázisként lehet leírni. Az olyan decentralizált protokollokban, mint a Tor, a Bitcoin és a BitMessage azért, hogy más emberek kölcsönhatásba léphessenek velük, a fiókok azonosítására van szükség valamilyen módon, de az összes létező megoldásban az egyetlen elérhető azonosítótípus egy álvéletlen hash, mint például `1LW79wp5ZBqaHW1jL5TCiBCrhQYtHagUWy`. Ideális esetben olyan számlanevet szeretnénk használni, mint a „george”. A probléma azonban az, hogy ha egy személy létrehozhat egy „george” nevű fiókot, akkor valaki más is végigmehet ugyanezen a regisztrációs folyamaton, és annak adhatja ki magát. Az egyetlen megoldás az elsőt figyelembe vevő (first-to-file) paradigma, ahol az első regisztrálónak sikerül, a másodiknak pedig meghiúsul – ez a probléma tökéletesen megfelel a Bitcoin konszenzusprotokoll számára. A Namecoin a legrégebbi és a legsikeresebb névregisztrációs rendszerimplementáció, amely ezen az ötleten alapszik. -- **Colored coins** – a [colored coinok (színes érmék)](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) célja egy olyan protokoll megtestesítése, amely lehetővé teszi az emberek számára, hogy saját digitális valutát készítsenek, vagy egy egységgel rendelkező valutát, azaz digitális tokent hozzanak létre a Bitcoin blokkláncon. A colored coins protokollban egy új pénznemet „bocsát ki” valaki azáltal, hogy nyilvánosan hozzárendel egy színt egy adott Bitcoin UTXO-hoz, és a protokoll rekurzív módon meghatározza a többi UTXO színét annak az inputnak a színével, amelyet az őket létrehozó tranzakció költött (néhány speciális szabály vonatkozik a vegyes színű bemenetekre). Ez lehetővé teszi a felhasználók számára, hogy csak bizonyos színű UTXO-t tartalmazó pénztárcákat tartsanak fenn, és a szokásos bitcoinokhoz hasonlóan küldjék el őket, visszakeresve a blokkláncon, hogy meghatározzák a kapott UTXO-k színét. -- **Metacoins** – a metacoin mögött az az alapötlet áll, hogy legyen egy olyan protokoll, amely a Bitcoinra épül, és a Bitcoin tranzakciókat használja metacoin-tranzakciók tárolására, de más státuszváltozási függvénnyel rendelkezik, ami az `APPLY'`. Mivel a metacoin-protokoll nem tudja megakadályozni, hogy érvénytelen metacoin tranzakciók jelenjenek meg a Bitcoin blokkláncon, bekerült az a szabály, hogy ha az `APPLY'(S,TX)` hibaüzenetet ad vissza, a protokoll az `APPLY'(S,TX) = S` alapértelmezett értékre áll be. Ez egy egyszerű mechanizmust biztosít egy tetszőleges kriptovaluta-protokoll létrehozására, potenciálisan fejlett funkciókkal, amelyek nem valósíthatók meg a Bitcoinon belül, de a fejlesztési költségek alacsonyak, mivel a bányászat és a hálózatépítés bonyolultságait már a Bitcoin-protokoll kezeli. Metacoinokat már néhány pénzügyi szerződésfajtánál, névregisztrációnál és decentralizált tőzsdék esetében is használtak. - -Így általánosságban két megközelítés van egy konszenzus protokoll fejlesztésére: egy független hálózat építése és egy protokoll fejlesztése a Bitcoinra. Az előbbi megközelítést, ami bár meglehetősen sikeres a Namecoinhoz hasonló alkalmazások esetében, nehéz implementálni; minden egyedi implementációnak fel kell állítania egy független blokkláncot, illetve kifejleszteni és letesztelni a szükséges státuszváltozást és a hálózati kódot. Továbbá arra számítunk, hogy a decentralizált konszenzus technológiát használó alkalmazások a hatványtörvény szerinti eloszlást fogják követni, ahol az alkalmazások túlnyomó többsége túl kicsi lesz ahhoz, hogy indokolt legyen egy saját blokkláncot fenntartaniuk, és megjegyezzük, hogy a decentralizált alkalmazásoknak nagy osztályai léteznek, különösen a decentralizált autonóm szervezetek, melyeknek interakcióba kell lépniük egymással. - -Másfelől a Bitcoin alapú megközelítésnek az a hátulütője, hogy nem örökli a Bitcoin egyszerűsített fizetéshitelesítési tulajdonságait. Az SPV (egyszerűsített fizetéshitelesítés) működik a Bitcoin esetében, mivel felhasználja a blokklánc mélységét, mint érvényességi proxy; egy ponton, amint a tranzakciónak kellő mennyiségű őse van, biztonsággal állítható, hogy ezek érvényes részei a státusznak. Másfelől a blokklánc alapú meta protokollok nem kényszeríthetik a blokkláncot, hogy ne tartalmazza azokat a tranzakciókat, melyek nem érvényesek a saját protokolljuk kontextusában. Ezért egy teljesen biztonságos SPV meta-protokoll megvalósításnak vissza kell hivatkoznia a Bitcoin blokklánc elejéig annak megállapítására, hogy biztos-e a tranzakciók érvényessége. Jelenleg a Bitcoin alapú metaprotokollok összes „könnyű” implementációja egy megbízott szerverre bízza az adatszolgáltatást, ami nem a legoptimálisabb megoldás, mert a kriptovaluták elsődleges célja a bizalomigény megszüntetése. - -### Szkriptelés {#scripting} - -Még kiterjesztés nélkül is a Bitcoin protokoll lehetővé teszi az „okosszerződések” egy kezdetleges változatát. A Bitcoinban lévő UTXO-kat nem csak publikus kulcsok birtokolhatják, hanem bonyolultabb szkriptek is, melyeket egy egyszerű stack alapú programozási nyelvvel lehet kifejezni. Ebben a paradigmában az UTXO-t elköltő tranzakcióknak adatokat kell szolgáltatni a szkriptek kielégítésére. Valójában még az alapvető publikus kulcs tulajdonjog mechanizmus is egy szkripten keresztül valósul meg: a szkript egy elliptikus görbe aláírást használ bemenetként, megerősíti a tranzakció és az UTXO-t birtokló cím szerint és 1-et ad vissza, ha az érvényesítés sikeres, ellenkező esetben 0-át. Más bonyolultabb szkriptek is léteznek további különböző felhasználási esetekre. Például létre lehet hozni egy olyan szkriptet, mely három privát kulcsból kettő aláírását igényli az érvényesítéshez ("multisig"), a vállalati számlák, biztonságos megtakarítási számlák és néhány kereskedői letét számára hasznos beállítás. A szkriptek felhasználhatók a számítási problémák megoldásáért járó jutalmak kifizetésére is, sőt össze lehet állítani egy olyan szkriptet, amely valami olyasmit mond, hogy "ez a Bitcoin UTXO a tiéd, ha tudsz egy SPV bizonyítékot nyújtani arra, hogy nekem küldtél egy ilyen címletű Dogecoin tranzakciót", mely lényegében lehetővé teszi a decentralizált kereszt-kriptovaluta váltást. - -Azonban a Bitcoinban implementált szkript nyelvnek számos fontos megkötése van: - -- **Turing-teljesség hiánya** – vagyis, bár van egy nagy számítási részhalmaz, amelyet a Bitcoin szkriptnyelv támogat, közel sem támogat mindent. A fő kategória a hiányzó ciklusok. Ennek az az oka, hogy elkerüljük a végtelen ciklusokat a tranzakció ellenőrzések során; elméletileg ez egy leküzdhetetlen akadály a szkriptprogramozók számára, mivel bármely ciklus szimulálható úgy, hogy egyszerűen megismételjük több alkalommal a mögöttes kódot egy „if” (ha) utasítással, de ez nagyon kis hatékonyságú szkriptekhez vezet. Például egy alternatív elliptikusgörbe-aláírási algoritmus implementálása valószínűleg 256 ismételt szorzási kört igényelne, melynek mindegyike egyenként szerepelne a kódban. -- **Értékvakság** – nincs olyan UTXO-szkript, amely képes lenne szofisztikáltan irányítani a kiutalható mennyiséget. Például egy orákulumszerződés komoly felhasználási területe a hedging szerződés lenne, ahova A és B 1000 USD értékű BTC-t tesz be és 30 nappal később a szkript elküld 1000 USD értékű BTC-t A részére a maradékot pedig B részére. Ez egy orákulumot igényel, mely meghatározza 1 BTC értékét USD-ben, de még így is hatalmas előrelépés a bizalom és az infrastrukturális követelmények szempontjából a teljesen centralizált megoldásokhoz képest. Azonban mivel az UTXO mindent vagy semmit elven működik, ennek az egyedüli módja, ha sok UTXO-t használunk különböző egységekkel (például egy 2k UTXO minden k-ra egészen 30-ig) és az orákulum eldönti, hogy melyik UTXO-t küldi A-nak és melyiket B-nek. -- **Státuszhiány** – az UTXO lehet elköltött vagy elköltetlen; nincs lehetőség többlépcsős szerződésekre vagy szkriptekre, amelyek megtartanak minden más belső státuszt ezen túl. Ez megnehezíti a többlépcsős opciós szerződések, decentralizált csereajánlatok vagy kétlépcsős kriptográfiai elköteleződési protokollok létrehozását (ami szükséges a biztonságos számítási kompenzációhoz). Ez azt is jelenti, hogy az UTXO csak egyszerű, egyszeri szerződések és nem bonyolultabb „státuszos” szerződések, például decentralizált szervezetek létrehozására használható, és a metaprotokollok megvalósítását megnehezíti. A bináris állapot az értékvaksággal kombinálva azt is jelenti, hogy egy másik fontos funkció, a kiutalási limitek beállítása, sem lehetséges. -- **Blokkláncvakság** – az UTXO nem tud az olyan blokkláncadatokról, mint a nonce, az időbélyeg vagy az előző blokkhash. Ez súlyosan korlátozza a szerencsejátékokban és számos más kategóriában történő alkalmazásokat azáltal, hogy megfosztja a szkriptnyelvet a véletlenszerűség értékes forrásától. - -Így meglátásunk szerint háromféleképpen lehet fejlett alkalmazásokat fejleszteni egy kriptovalutára: új blokklánc indítása, a Bitcoin szkripting használata és egy meta protokoll fejlesztése Bitcoinra. Egy új blokklánc indítása lehetővé teszi a korlátlan szabadságot a funkciókészlet építésében, de a fejlesztési idő, a bootstrapping és a biztonság árán. A szkriptek használata egyszerűen megvalósítható és szabványosítható, de nagyon korlátozott a képességeiben, és a meta protokollok, míg egyszerűek, nehezen skálázhatóak. Az Ethereummal egy olyan alternatív keretrendszert szeretnénk létrehozni, mely még jobban megkönnyíti a fejlesztést, valamint erősebb könnyű kliens tulajdonságokkal rendelkezik, egyúttal az alkalmazásoknak egy közös gazdasági környezetet és blokklánc biztonságot biztosít. - -## Ethereum {#ethereum} - -Az Ethereum célja egy alternatív protokoll létrehozása decentralizált alkalmazások fejlesztésére, különböző kompromisszumokkal, amelyről úgy hisszük, hogy nagyon hasznos lesz a decentralizált alkalmazások nagy részének, különös tekintettel az olyan esetekre, ahol fontos a gyors fejlesztési idő, a biztonság a kisméretű és ritkán használt alkalmazások számára, és a különböző alkalmazások közötti nagyon hatékony együttműködés. Az Ethereum ezt úgy éri el, hogy felépíti azt, ami lényegében a végső absztrakt alapréteg: egy blokkláncot beépített Turing-teljes programozási nyelvvel, mely lehetővé teszi bárki számára az okosszerződés írást és a decentralizált alkalmazás fejlesztést, ahol létrehozhatják a saját tetszőleges tulajdonjogi szabályaikat, tranzakció formátumukat és a státuszváltozási függvényeket. A Namecoin lecsupaszított verziója két sornyi kódból megírható, a többi protokoll, mint például a valuták és az identitás rendszerek pedig kevesebb, mint húsz sorból. Okosszerződések, olyan kriptográfiai „dobozok”, melyek értéket tartalmaznak és csak akkor nyílnak ki, amikor bizonyos feltételek teljesülnek, szintén építhetőek a platformra sokkal nagyobb erővel, mint amit a Bitcoin szkriptelés kínál, a Turing-teljesség, értéktudatosság, blokklánctudatosság és a státusz hozzáadott értéke miatt. - -### Ethereum-számlák {#ethereum-accounts} - -Az Ethereumban a státuszt „számláknak” nevezett objektumok alkotják, ahol minden egyes számla egy 20 bájtos címmel rendelkezik és a státuszváltozást a számlák közötti közvetlen érték- és információátadás végzi. Az Ethereum-számlák négy mezőt tartalmaznak: - -- A **nonce**, egy számláló, mely biztosítja, hogy minden tranzakció csak egyszer kerül feldolgozásra -- A számla aktuális **ether-egyenlege** -- A számla **szerződéskódja**, ha van -- A számla **tárhelye** (alapértelmezetten üres) - -Az „ether” az Ethereum elsődleges, belső kriptoüzemanyaga és a tranzakciós díj kifizetésére lehet használni. Általánosságban kétfajta számlatípus létezik: **külső tulajdonú számlák**, melyeket privát kulcsok irányítanak és **szerződéses számlák**, melyeket a szerződéskódjuk irányít. A külső tulajdonú számláknak nincs kódjuk, és az adott személy üzenetet küldhet egy külső tulajdonú számláról egy tranzakció létrehozásával és aláírásával; a szerződéses számla esetében minden esetben, amikor e számla üzenetet kap, aktiválódik a kódja, ami lehetővé teszi a belső tárhely írását és olvasását, új üzenetek küldését vagy szerződés létrehozását. - -Fontos megjegyezni, hogy az Ethereumban a szerződések nem olyan egyezmények, amelyet teljesíteni vagy betartani kell; inkább „önálló ügynökök”, akik az Ethereum végrehajtási környezetében élnek, és végrehajtanak egy adott kóddarabot, amikor beindítja azokat egy üzenet vagy tranzakció, továbbá közvetlen ellenőrzésük alatt tartják saját ether-egyenlegüket és saját kulcs-érték-adatbázisukat a tartós változók nyomon követésére. - -### Üzenetek és tranzakciók {#messages-and-transactions} - -A „tranzakció” kifejezést az Ethereumban egy aláírt adatcsomagra használjuk, ami egy külső tulajdonú számláról érkező üzenetet tartalmaz. A tranzakció a következőket tartalmazza: - -- Az üzenet címzettje -- A küldőt azonosító aláírás -- Az ether összeg, amit a küldő át akar utalni a címzettnek -- Egy opcionális adat mező -- A `STARTGAS` érték, ami a tranzakció-végrehajtás számítási lépéseinek maximális számát jelenti -- A `GASPRICE` érték, ami a számítás lépésenkénti díját jelenti, amit a feladó fizet - -Az első három olyan standard mező, ami minden kriptovalutánál megtalálható. Az adatmezőnek alapértelmezés szerint nincs funkciója, de a virtuális gép rendelkezik egy opkóddal, amelyet a szerződés használhat az adatok elérésére; például amikor egy szerződés domainregisztrációs szolgáltatásként működik a blokkláncon, akkor úgy értelmezheti a hozzá érkező adatot, hogy az két „mezőt” tartalmaz, az első a regisztrálandó domain, a második az IP-cím, amelyre regisztrálni kell. A szerződés kiolvassa ezeket az adatokat az üzenetből, és a megfelelő helyükre helyezi azokat az adattárban. - -A `STARTGAS` és `GASPRICE` mezők kritikusak az Ethereum szolgáltatásmegtagadás elleni védekezési modelljében. Azért, hogy megelőzzük a véletlen vagy ártó szándékú végtelen ciklusokat vagy más számítási pazarlással járó kódot, minden egyes tranzakciónak be kell állítani egy határt, hogy mennyi számítási lépést hajthat végre a kód futtatása. A számítás alapvető egysége a „gáz”; általában egy számítási lépés 1 gázba kerül, de egyes műveletek többet igényelnek, mert számítási szempontból drágábbak, vagy növelik a státuszként tárolandó adatok mennyiségét. Továbbá minden egyes tranzakciós adatban található bájt után 5 gáz is felszámításra kerül. A díjrendszer célja, hogy megkövetelje a támadótól, hogy minden általa felhasznált erőforrásért arányosan fizessen, beleértve a számítást, a sávszélességet és a tárhelyet is; ennélfogva minden olyan tranzakció esetében, amelynek eredményeként a hálózat ezeknek az erőforrásoknak bármelyikét nagyobb mennyiségben fogyasztja, az erőforrások növekedésével nagyjából arányos gázköltséggel kell számolni. - -### Üzenetek {#messages} - -A szerződéseknek megvan a lehetőségük, hogy „üzeneteket” küldjenek más szerződéseknek. Az üzenetek olyan virtuális objektumok, amelyek nincsenek sorosítva és csak az Ethereum futtatási környezetben léteznek. Az üzenet a következőket tartalmazza: - -- Az üzenet küldője (magától értetődő) -- Az üzenet címzettje -- Az üzenettel küldendő ether összege -- Egy opcionális adatmező -- A `STARTGAS` érték - -Lényegében az üzenet olyan mint a tranzakció, kivéve, hogy nem külső szereplő, hanem a szerződés hozta létre. Üzenet akkor jön létre, amikor a kódot végrehajtó szerződés azt a `CALL` opkódot futtatja, amely előállítja és végrehajtja az üzenetet. A tranzakcióhoz hasonlóan az üzenet is a címzettszámla kódjának lefuttatását eredményezi. Ezáltal a szerződéseknek is ugyanúgy lehet kapcsolatuk másik szerződésekkel, mint a külső szereplőknek. - -Megjegyzendő, hogy a tranzakciók vagy szerződések által kiszabott gázdíj a teljes gázmennyiségre vonatkozik, amit az adott tranzakció és az összes végrehajtási folyamat felhasznált. Például, ha az A külső szereplő egy tranzakciót küld B-nek 1000 gázzal, és B 600 gázt fogyaszt, mielőtt üzenetet küldene C-nek, és C belső végrehajtása 300 gázt fogyaszt, mielőtt visszatérne, akkor B még további 100 gázt költhet el. - -### Az Ethereum státuszváltozási függvénye {#ethereum-state-transition-function} - -![Ether státuszváltozás](./ether-state-transition.png) - -Az Ethereum státuszváltozási függvénye, az `APPLY(S,TX) -> S'` a következőképpen írható le: - -1. Ellenőrzi, hogy a tranzakció jól formált-e (megfelelő az értékek száma), az aláírás érvényes-e, és a nonce megegyezik-e a feladó számláján szereplő nonce-szal. Ha nem, hibát küld vissza. -2. Kiszámítja a tranzakciós illeték (`STARTGAS * GASPRICE`), és meghatározza a küldő címét az aláírásból. Levonja a díjat a küldő fél számlaegyenlegéről és növeli a küldő fél nonce-át. Ha nincs elegendő egyenleg, hibát küld vissza. -3. Beállítja a `GAS = STARTGAS` kezdőértéket, és bizonyos mennyiségű, bájtonkénti gázt elvesz a tranzakció bájtjainak kifizetéséhez. -4. Átutalja a tranzakció értékét a küldő számlájáról a fogadó számlájára. Ha a fogadó számla még nem létezik, létrehozza azt. Ha a fogadó számla egy szerződés, futtatja a szerződés kódját, addig amíg a tranzakció teljesül, vagy ameddig a végrehajtás során elfogy a gáz. -5. Ha az értékátutalás azért nem sikerült, mert a feladónak nem volt elegendő pénze, vagy a kódfuttatás során elfogyott a gáz, akkor minden állapotváltozást visszavon, kivéve a díjak kifizetését, majd a díjakat a bányász számlájához adja. -6. Máskülönben az összes fennmaradó gázdíjat visszatéríti a feladónak, az elfogyasztott gázért fizetett díjakat pedig elküldi a bányásznak. - -Tegyük fel, hogy a szerződés kódja a következő: - -```py -if !self.storage[calldataload(0)]: - self.storage[calldataload(0)] = calldataload(32) -``` - -Megjegyzendő, hogy a valóságban a szerződés alacsony szintű EVM programozási nyelven van írva; ez a példa az érthetőség kedvéért az egyik magas szintű programozási nyelven, a Serpentben íródott, és le lehet fordítani EVM-nyelvre. Tegyük fel, hogy a szerződés tárhelye az elején üres, és egy 10 ether értékű tranzakciót elküldenek 2000 gázzal, 0,001 ether gázárral, és 64 bájtnyi adattal, ahol a 0–31. bájtok a `2` számot, a 32–63. bájtok pedig a karakterláncot ábrázolják (`CHARLIE`). A státuszváltozási függvény folyamata ebben az esetben a következőképpen alakul: - -1. Ellenőrzi, hogy a tranzakció érvényes és jól formált-e. -2. Ellenőrzi, hogy a tranzakció küldőjének van-e legalább 2000 \* 0,001 = 2 ethere. Ha igen, levon 2 ethert a küldő számlájáról. -3. Beállítja a gáz = 2000 kezdőértéket; feltételezve, hogy a tranzakció 170 bájt hosszú és a bájtdíj 5, levon 850-et úgy, hogy 1150 gáz marad. -4. További 10 ethert levon a küldő számlájáról, és hozzáadja azt a szerződés számlájához. -5. Lefuttatja a kódot. Ebben az esetben ez egyszerű: a kód ellenőrzi, hogy a szerződés `2`-es indexén lévő tárhelyét használja-e; ha észreveszi, hogy nem, akkor a tárhelyindexet beállítja `2`-re, az értéket pedig `CHARLIE`-ra. Tegyük fel, hogy ez 187 gázba kerül, így a fennmaradó gáz összege 1150 – 187 = 963 -6. 963 \ * 0,001 = 0,963 ethert visszaad a feladó számlájára, és visszatér az eredményül kapott státuszhoz. - -Ha a tranzakció fogadójának oldalán nem lenne szerződés, akkor a teljes tranzakciós illeték egyszerűen megegyezne a megadott `GASPRICE` értékével megszorozva a tranzakció hosszával bájtokban, és a tranzakcióval együtt elküldött adatok lényegtelenek lennének. - -Megjegyzendő, hogy az üzenetek és a tranzakciók visszafordítása ugyanúgy működik: ha az üzenet végrehajtása során elfogy a gáz, akkor az üzenet végrehajtása és az ebből következő összes többi végrehajtás visszaáll, de a „szülő végrehajtásokat” nem kell visszaállítani. Ez azt jelenti, hogy egy szerződés „biztonságosan” meghívhat egy másik szerződést, mivel ha A G mennyiségű gázzal hívja meg B-t, akkor A végrehajtása garantáltan legfeljebb G mennyiségű gázveszteséget okoz. Végül megjegyzendő, hogy van egy műveleti kód (`CREATE`), amely létrehozza a szerződést; aminek a végrehajtási mechanikája általában hasonló a `CALL`-hoz vagy híváshoz, azzal a kivétellel, hogy a végrehajtás kimenete határozza meg az újonnan létrehozott szerződés kódját. - -### Kódfuttatás {#code-execution} - -Az Ethereum szerződésekben szereplő kód alacsony szintű, stack-alapú bájtkód nyelven íródott, amelyet Ethereum virtuális gépi (EVM) kódnak neveznek. A kód bájtok sorozatából áll, ahol mindegyik bájt egy műveletet képvisel. A kódfuttatás általában egy végtelen ciklus, ami a művelet ismételt végrehajtásából áll az aktuális programszámlálón (amely nullától kezdődik), majd eggyel növeli a számlálót addig, amíg el nem éri a kód végét, vagy egy hibát, illetve ` STOP ` vagy ` RETURN ` utasítást észlel. A műveletek háromféle helyhez férnek hozzá, ahol adatokat tárolhatnak: - -- A **stack** egy utolsóként be, elsőként ki (LIFO) tárolóhely, ahol az értékek rárakhatók (push) a stackre és levehetők (pop) a stack tetejéről -- **Memória **, egy végtelenül bővíthető bájttömb -- A szerződés hosszú távú ** tárhelye **, egy kulcs-érték tároló. A stack-től és a memóriától eltérően, amelyek a számítás befejezése után nullázódnak, ez a tároló hosszú ideig fennmarad. - -A kód hozzáférhet a bejövő üzenet értékéhez, feladójához és adataihoz, valamint a blokkfejléc adataihoz, és a kód egy bájt adattömböt is visszaadhat kimenetként. - -Az EVM-kód formális végrehajtási modellje meglepően egyszerű. Amíg az Ethereum virtuális gép fut, teljes számítási állapota meghatározható a következő értéksorral: `(block_state, transaction, message, code, memory, stack, pc, gas)`, ahol a `block_state` az összes számlát tartalmazó globális státusz, amely magában foglalja az egyenlegeket és a tárolóhelyeket. Minden egyes végrehajtási kör elején, az aktuális utasítás megtalálható a `code`-nak a `pc` által meghatározott bájtja által (vagy 0 ha `pc >= len(code)`), és minden utasításnak megvan a maga meghatározása abból a szempontból, hogy milyen hatással van az értéksorra. Például, `ADD` elvesz két elemet a stack-ből és visszarakja az összegüket, csökkenti a `gas` értékét 1-gyel, növeli a `pc` értékét 1-gyel, az `SSTORE` leveszi a stack két legfelső elemét és behelyezi a második elemet a szerződés tárhelyébe az első elem által meghatározott indexen. Bár számos módja van az Ethereum virtuális gép végrehajtás-optimalizálásának, futásidejű fordítással (röpfordítás), az Ethereum alapvető megvalósítása néhány száz kódsorban elvégezhető. - -### Blokklánc és bányászat {#blockchain-and-mining} - -![Ethereum alkalmazási blokkdiagram](./ethereum-apply-block-diagram.png) - -Az Ethereum blokklánc sok szempontból hasonló a Bitcoin blokklánchoz, bár vannak közöttük különbségek. A fő különbség az Ethereum és a Bitcoin között a blokklánc felépítésének tekintetében az, hogy a Bitcointól eltérően (amely csak a tranzakciós lista másolatát tartalmazza) az Ethereum blokkok tartalmazzák a tranzakciós lista és a legutóbbi státusz másolatát is. Emellett két másik érték, a blokk száma és a nehézsége is tárolva van a blokkban. Az Ethereum blokk validációs algoritmusa a következő: - -1. Ellenőrzi, hogy az előző blokk, amelyre a blokk hivatkozik, létezik és érvényes. -2. Ellenőrzi, hogy a blokk időbélyege nagyobb-e, mint az előző blokké és kevesebb mint 15 perc telt el azóta -3. Ellenőrzi, hogy a blokk száma, a nehézség, a tranzakciógyökér, az uncle-gyökér és a gázkorlátozás (különféle alacsony szintű, Ethereum-specifikus fogalmak) érvényesek-e. -4. Ellenőrzi, hogy a blokk proof-of-workje érvényes-e. -5. Legyen `S[0]` az előző blokk után lévő állapot. -6. Legyen `TX` a blokk tranzakciólistája `n` tranzakcióval. A `0...n-1` összes `i`-je esetében állítsa be a következőt: `S[i+1] = APPLY(S[i],TX[i])`. Ha valamelyik alkalmazás hibát ad vissza, vagy a blokkban az eddig a pontig elfogyasztott gáz összmennyisége túllépi a `GASLIMIT` értéket, hibát ad vissza. -7. Legyen az `S_FINAL` `S[n]`, de hozzáadva a bányásznak fizetett blokkjutalmat. -8. Ellenőrzi, hogy az `S_FINAL` állapot Merkle-fagyökere azonos-e a blokkfejlécben megadott végleges státusszal. Ha igen, a blokk érvényes; ellenkező esetben nem az. - -A megközelítés első pillantásra nem tűnhet túl hatékonynak, mert minden blokkal a teljes státuszt kell tárolni, de a hatékonyság a Bitcoinéhoz hasonló. Ennek az az oka, hogy a státusz fastruktúrában tárolódik, és minden blokk után a fa csak egy kis részét kell megváltoztatni. Így általában két szomszédos blokk között a fa túlnyomó részének azonosnak kell lennie, ezért az adatokat egyszer kell tárolni és kétszer lehet rájuk hivatkozni mutatók (azaz részfák hasheinek) használatával. Ennek megvalósításához egy speciális „Patricia-fát” használnak, beleértve a Merkle-fa koncepciójának módosítását is, amely lehetővé teszi a csomópontok hatékony beillesztését és törlését, nem csak megváltoztatását. Ezen túlmenően, mivel az összes státuszinformáció része az utolsó blokknak, nincs szükség a teljes blokkláncelőzmények tárolására – ez egy olyan stratégia, amely ha alkalmazható lenne a Bitcoinra, 5–20-szoros megtakarítást eredményezne a tárhelyben. - -Gyakran felmerül az a kérdés, hogy „hol” történik a szerződés kódjának végrehajtása a fizikai hardver szempontjából. Erre egyszerű a válasz: a szerződés kódjának végrehajtási folyamata a státuszváltozási függvény definíciójának része, amely a blokk validációs algoritmus része, tehát ha egy tranzakciót hozzáadunk a `B` blokkhoz, akkor a tranzakció által létrehozott kód végrehajtását minden csomópont végrehajtja, most és a jövőben is, amelyek letöltik és validálják a `B` blokkot. - -## Alkalmazások {#applications} - -Az Ethereumon általánosságban háromféle alkalmazás létezik. Az első kategória a pénzügyi alkalmazások, amelyek hatékonyabb módszereket kínálnak a felhasználóknak a pénzük kezelésére és szerződéskötésre. Ebbe beletartoznak a devizák, a derivatív pénzügyi eszközök, a fedezeti ügyletek, a megtakarításitárcák, végrendeletek, és végül akár teljes körű munkaszerződések egyes kategóriái. A második kategória a félig pénzügyi alkalmazások, amelyek a pénzzel kapcsolatosak, de a tevékenységeiknek van egy jelentős, nem pénzügyi oldala is; erre tökéletes példa az önérvényesítő jutalmak a számítási problémák megoldásért. Végül vannak olyan alkalmazások, mint az online szavazás és a decentralizált irányítás, amelyek egyáltalán nem pénzügyi vonatkozásúak. - -### Tokenrendszerek {#token-systems} - -A blokkláncon alapuló tokenrendszereknek számos alkalmazási területe van, mint az alvaluták, amelyek olyan eszközöket képviselnek, mint az USA dollár vagy az arany, a vállalati részvények, az okos tulajdont képviselő egyedi tokenek, a biztonságos és hamisíthatatlan kuponok, vagy amelyeknél semmilyen kapcsolat sincs a hagyományos értékhez, csak ösztönzéshez használják azokat. A tokenrendszereket meglepően egyszerű módon létre lehet hozni az Ethereumon. Kulcsfontosságú megérteni azt, hogy a pénznem vagy a tokenrendszer alapvetően egy műveletből álló adatbázis: vonjon le X egységet A-tól, és adjon X egységet B-nek, azzal a feltétellel, hogy 1) A-nak a tranzakció előtt legalább X egysége volt és 2) a tranzakciót A jóváhagyta. A tokenrendszer megvalósításához mindössze annyi kell, hogy ezt a logikát beépítsék egy szerződésbe. - -Az alapkód a tokenrendszer megvalósítására Serpent programnyelven a következőképpen néz ki: - -```py -def send(to, value): - if self.storage[msg.sender] >= value: - self.storage[msg.sender] = self.storage[msg.sender] - value - self.storage[to] = self.storage[to] + value -``` - -Ez lényegében a „bankrendszer” státuszváltozási függvényének szó szerinti megvalósítását jelenti, amely ebben a dokumentumban fentebb már le lett írva. Néhány extra kódsort hozzá kell adni, hogy biztosítsuk a pénzegységek elosztásának kezdeti lépését, néhány másik szélsőséges esetben is, és ideális esetben egy függvényt is hozzáadunk, ami lehetővé teszi másik szerződéseknek, hogy lekérdezzék egy cím számlaegyenlegét. De ennyi az egész. Elméletileg a pénznemként működő Ethereum-alapú tokenrendszerek tartalmazhatnak egy másik fontos jellemzőt, ami a Bitcoin-alapú blokkláncon található pénzeszközöknél hiányzik: a tranzakciós díjak közvetlen fizetése ugyanabban a pénznemben. Ez úgy lehetne megvalósítható, hogy a szerződés fenntartana egy ether egyenleget, amelyből visszatérítené a feladónak a díjakra használt ethert, és ezt úgy töltené fel, hogy összegyűjti a díjakra beszedett belső valutaegységeket, és egy folyamatosan futó aukción továbbértékesíti azokat. A felhasználóknak tehát etherrel kellene „aktiválniuk” a számláikat, de onnantól, hogy az ether ott van, újrafelhasználható, mert a szerződés minden alkalommal visszatérítené. - -### Pénzügyi derivatívák és stabil értékű valuták {#financial-derivatives-and-stable-value-currencies} - -A pénzügyi derivatívák az „okosszerződés” leggyakoribb alkalmazásai, és az egyik legegyszerűbben megvalósíthatók a kód szempontjából. A pénzügyi szerződések végrehajtása során az a fő kihívás, hogy többségük külső árfolyamra való hivatkozást igényel; például kívánatos alkalmazás egy olyan okosszerződés, amely fedezetet ad az ether (vagy más kriptovaluta) árfolyamingadozására az amerikai dollárral szemben, de ehhez a szerződésnek tudnia kell az ETH/USD értékét. Ennek legegyszerűbb módja egy adott fél (például a NASDAQ) által fenntartott „adatforrás” szerződés, amelynek célja, hogy az adott fél képes legyen a szerződés szükség szerinti frissítésére, és egy olyan felület biztosítása, amely lehetővé teszi más szerződések számára, hogy üzenetet küldjenek a szerződésnek, és a válaszban megkapják az árat. - -Tekintettel erre a kritikus összetevőre, a fedezeti szerződés a következőképpen nézne ki: - -1. Megvárja, amíg az A fél berak 1000 ethert. -2. Megvárja, amíg a B fél berak 1000 ethert. -3. Az adatforrás szerződés lekérdezésén keresztül kiszámított 1000 ether USD értékének rögzítése a tárolóhelyen, mondjuk, hogy ez x USD. -4. 30 nap elteltével hagyja, hogy A vagy B „újraaktiválja” a szerződést annak érdekében, hogy x USD értékű ethert küldjön (amelyet úgy számol ki, hogy újból lekérdezi az adatforrás szerződést az új árról) A-nak, a többit pedig B-nek. - -Egy ilyen szerződés jelentős potenciállal bírna a kriptokereskedelemben. Az egyik fő probléma, amire gyakran hivatkoznak a kriptovalutával kapcsolatban, hogy ingatag az árfolyama; bár sok felhasználó és kereskedő vágyik a kriptográfiai eszközök biztonságára és kényelmére, nem biztos, hogy vállalja azt az eshetőséget, hogy egyetlen nap alatt elveszítheti pénzeszközei értékének 23%-át. Eddig a leggyakrabban a kibocsátó által biztosított eszközöket javasolták; azon elképzelés alapján, hogy a kibocsátó létrehoz egy pénzeszközt, ahol joga van kibocsátani és visszavonni egységeket, és mindenkinek egy egységnyi pénzeszközt ad, aki (offline) cserébe ad neki egy meghatározott, egy egységnyi alapul szolgáló eszközt (például arany, USA dollár). A kibocsátó ezután megígéri, hogy az alapul szolgáló eszköz egy egységét adja annak, aki visszaküldi a kriptoeszköz egy egységét. Ez a mechanizmus lehetővé teszi a nem kriptográfiai eszköz kriptográfiai eszközzé való eszkalálását, feltéve, hogy a kibocsátó megbízható. - -A gyakorlatban azonban a kibocsátók nem mindig megbízhatóak, és egyes esetekben a banki infrastruktúra túl gyenge vagy túl ellenséges ahhoz, hogy ilyen szolgáltatások létezzenek. A pénzügyi derivatívák alternatívát kínálnak. Itt ahelyett, hogy egyetlen kibocsátó biztosítaná az eszközök fedezetére szolgáló alaptőkét, a spekulánsok decentralizált piacon való fogadásai – például arról, hogy egy kriptográfiai referencia eszköz (például az ETH) ára emelkedni fog-e – játsszák ezt a szerepet. A kibocsátóktól eltérően a spekulánsoknak nincs lehetőségük az ügylettel kapcsolatos kötelezettségük elmulasztására, mert a fedezeti szerződés letétben tartja a pénzeszközeiket. Fontos megjegyezni, hogy ez a megközelítés nincs teljesen decentralizálva, mert még mindig megbízható forrásra van szükség az árjegyző szerepének betöltésére, bár már ez is hatalmas előrelépés az infrastruktúrakövetelmények csökkentése szempontjából (ellentétben a kibocsátóval, az árfolyamkiadáshoz nem szükséges engedély, és valószínűleg a szólásszabadság kategóriájába sorolhatók), és a csalás lehetőségét is csökkenti. - -### Identitás- és hírnévrendszerek {#identity-and-reputation-systems} - -A legkorábbi alternatív kriptovaluta, a [Namecoin](http://namecoin.org/), egy Bitcoinhoz hasonló blokkláncot próbált meg használni egy névregisztrációs rendszer biztosításához, ahol a felhasználók a nevüket egy nyilvános adatbázisba regisztrálhatták több más adat mellett. A leggyakrabban idézett alkalmazási eset a [DNS](https://wikipedia.org/wiki/Domain_Name_System) rendszerre, a domain nevek, például „bitcoin.org” (vagy a Namecoin esetében „bitcoin.bit”) leképezése egy IP-címre. Egyéb alkalmazási esetek például az e-mail-hitelesítések és a potenciálisan haladóbb reputációs rendszerek. Nézzünk egy alap szerződést, amely Namecoin-féle névregisztrációt biztosít az Ethereumon: - -```py -def register(name, value): - if !self.storage[name]: - self.storage[name] = value -``` - -A szerződés nagyon egyszerű; gyakorlatilag egy adatbázis az Ethereum hálózatban, amelyhez hozzá lehet adni, de nem lehet módosítani vagy törölni belőle. Bárki regisztrálhat nevet valamilyen értékkel, majd a regisztráció örökre megmarad. Egy kifinomultabb névregisztrációs szerződésben szerepelne egy „függvényzáradék”, amely engedné a többi szerződésnek a lekérdezést, valamint a név „tulajdonosának” (azaz az első regisztrálónak) egy mechanizmust, az adat módosítására vagy a tulajdonjog átadására. Bárki hozzáadhat reputációt és digitális azonosító (web-of-trust) funkcionalitást az egész tetejére. - -### Decentralizált fájltárhely {#decentralized-file-storage} - -Az elmúlt években számos népszerű online tárhely startup tűnt fel, amelyek közül az egyik legkiemelkedőbb a Dropbox, akik lehetővé teszik ügyfeleiknek, hogy a merevlemezük biztonsági mentését feltöltsék, majd a szolgáltatással tároltassák azt, majd a felhasználó havidíj ellenében férhet hozzá az adataihoz. Azonban ezen a ponton a fájltárhely piac relatíve nem hatékony; ha megvizsgáljuk a különböző meglévő megoldásokat, láthatjuk, hogy különösen a „furcsa zónában”, a 20–200 GB szinten, ahol sem az ingyenes kvóták, sem a vállalati szintű kedvezmények nem jelennek meg, a mainstream fájltárolási költségek havi árszintje ott tart, hogy egy hónapért többet fizet az átlag felhasználó, mint egy teljes merevlemezért. Az Ethereum szerződések lehetővé teszik egy decentralizált fájltárolási ökoszisztéma fejlesztését, ahol az egyes felhasználók kis mennyiségű pénzt kereshetnek azzal, hogy bérbeadják saját merevlemezüket és a használaton kívüli tárhelyüket, ezzel is lefelé hajtva a tárolás költségeit. - -Az ilyen eszközök kulcsfontosságú megerősítő eleme az általunk „decentralizált Dropbox szerződésnek” elnevezett megoldás. A szerződés a következő módon működik. Először a kívánt adatokat blokkokra bontjuk, adatvédelmi okokból titkosítjuk, majd egy Merkle-fát építünk belőle. Ezután létrehozunk egy szerződést azzal a szabállyal, hogy minden N blokkban a szerződés egy véletlen indexet választ ki a Merkle-fában (az előző blokkhash segítségével a szerződés kódjából véletlenszerűen), majd X ethert adunk az első entitásnak, hogy egy egyszerűsített fizetéshitelesítéssel lássa el a tranzakciót, például a blokk tulajdonjogát bizonyító elemmel az adott indexen a fában. Amikor egy felhasználó újra le szeretné tölteni a fájlt, egy mikrofizetési csatornás protokollt használhat (például 1 szabo 32 kilobájt adatért) a fájl lekérésére; a leginkább költséghatékony megközelítés az, amikor a fizető félnek csak a legvégén kell publikálnia a tranzakciót, ahelyett, hogy a tranzakciót egy kissé jövedelmezőbbre cserélné le ugyanazzal a nonce-al 32 kilobájtonként. - -A protokoll egyik fontos jellemzője, hogy bár úgy tűnik, hogy valaki több véletlen csomópontot bíz meg azzal, hogy ne felejtse el a fájlt, a saját kockázatát a nullához közelire csökkentheti azzal, hogy a fájlt több részre bontja titkos megosztással, majd figyeli a szerződést, hogy lássa az egyes darabok továbbra is valamelyik csomópont birtokában maradnak. Ha egy szerződés továbbra is fizet, akkor kriptográfiai bizonyíték van arra, hogy valaki továbbra is tárolja a fájlt. - -### Decentralizált autonóm szervezetek {#decentralized-autonomous-organizations} - -A „decentralizált autonóm szervezetek” (DAO) általános koncepciója, hogy egy virtuális entitásnak, amely adott számú taggal vagy „részvényessel” rendelkezik, akár esetleg 67%-os többséggel, felhatalmazása lehet arra, hogy elköltse az entitás pénzeszközeit és módosítsa a kódját. A tagok együttesen dönthetik el, hogy a szervezet hogyan allokálja a pénzeszközöket. Egy DAO pénzeszközei allokálásának módszerei a pénzadománytól, fizetéseken át akár még egzotikusabb mechanizmusokig terjedhet, mint például egy belső valuta a munka elismerésére. Ez gyakorlatilag replikálja a hagyományos vállalatok vagy non-profit entitások jogi csapdáit, de a végrehajtásra kizárólag kriptográfiai blokklánc-technológiát használ. Eddig a DAO-kkal kapcsolatban leginkább a kapitalista „decentralizált autonóm vállalat” (DAC) modelljéről beszéltünk, ahol a részvényesek osztalékot vagy kereskedhető részvényeket kapnak; azonban van egy alternatív, talán a „decentralizált autonóm közösség” fogalommal leírható értelmezés is, ahol a tagok egyenlő mértékben vesznek részt a döntéshozatalban, és a tagok 67%-ának beleegyezése szükséges ahhoz, hogy felvegyenek vagy eltávolítsanak egy tagot. Azt a követelményt, hogy egy személy csak egy tagsággal rendelkezhet a csoportnak kollektíven kell érvényre juttatnia. - -A DAO-k kódolásának általános leírása a következő. A legegyszerűbb megoldás egy önmagát módosító kódelem alkalmazása, amely változik, ha a tagok kétharmada egyetért egy módosítással. Bár a kód elméletileg állandó, bárki megkerülheti, és de-facto megváltoztathatja, ha a kód darabjait külön szerződésekbe foglalja, majd a módosítható tárhelyen menti el azt a címet, amit a szerződéseknek meg kell hívni. Egy ilyen DAO-szerződés egyszerű implementációjában három tranzakciótípus lenne, amelyeket a tranzakcióban megadott adatok különböztetnek meg: - -- `[0,i,K,V]`, ahol a javaslatot az `i` index-szel regisztrálják, hogy módosítsa a címet a `K` tárolási indexen `V` értékre -- `[1,i]` egy szavazatot regisztrál az `i` javaslat előnyben részesítésére -- `[2,i]` az `i` javaslat véglegesítésére, ha elég szavazat érkezett be - -A szerződésben ezután mindegyikre szerepel egy záradék. Ezután rögzíti az összes nyitott tárolási módosítást, és azt a listát is, hogy ki szavazott rájuk. Tartalmazza a tagok listáját is. Amikor valamelyik tárolási módosításra a tagok kétharmada szavazott, a véglegesítési tranzakció hajtja végre a módosítást. Egy kifinomultabb vázban megvalósítható beépített szavazási lehetőség is olyan funkciókra, mint például tranzakció küldése, tagok hozzáadása vagy eltávolítása, valamint lehetővé kell tenni egy [likviddemokrácia](https://wikipedia.org/wiki/Liquid_democracy)-stílusú szavazási delegálást is (azaz egy valaki kijelölheti, hogy ki szavazzon helyette, majd a kijelölés átadható, tehát, ha A B-t bízza meg a szavazással, majd B C-t bízza meg, C határozza meg A szavazatát). A tervezés lehetővé teszi, hogy a DAO organikusan nőjön decentralizált közösségként, és a tagok végül delegálhassák azt a feladatot egy specialistának, hogy kiszűrjék a tagokat, szemben a specialisták „jelenlegi rendszerével”, akik a közösség egyes tagjait érintő változások függvényében könnyen ki- vagy beugorhatnak. - -Alternatív modell egy decentralizált vállalat részére, amikor valamelyik számlán nulla vagy több részvény van, és a döntéshozatalhoz a részvények kétharmadára van szükség. Egy teljes vázban ideális esetben benne van az eszközkezelő funkció, a lehetőség részvények vásárlására vagy eladására szóló ajánlattételre, valamint a lehetőség az ajánlatok elfogadására (lehetőség szerint a szerződésen belül egy ajánlategyeztető mechanizmussal). A delegálás szintén likvid demokrácia-stílusban létezik, általánosítva az „igazgatótanács” koncepcióját. - -### További alkalmazások {#further-applications} - -**1. Megtakarítási tárcák**. Tegyük fel, hogy Alice biztonságban szeretné tudni pénzeszközeit, azonban aggódik amiatt, hogy veszteség éri, vagy valaki feltöri a privát kulcsát. Ethert helyez el egy szerződésben Bobbal, egy bankkal, a következőképpen: - -- Alice egyedül naponta legfeljebb a pénzeszközök 1%-át tudja felvenni. -- Bob egyedül naponta a pénzeszközök legfeljebb 1%-át tudja felvenni, de Alice-nek lehetősége van arra, hogy tranzakciót végezzen a kulcsával és zárolja ezt a lehetőséget. -- Alice és Bob együtt bármennyit fel tud venni. - -Alice-nek általában elég naponta 1%, azonban, ha Alice-nek többre van szüksége, értesítheti Bobot, és segítséget kérhet. Ha Alice-t támadás éri, Bobhoz siethet, és a pénzeszközöket egy új szerződésbe tudja átmozgatni. Ha elveszíti a kulcsát, Bob tudja végül kivenni az eszközöket. Ha Bob rosszindulatúan kezd viselkedni, Alice ki tudja kapcsolni, hogy Bob pénzt vehessen fel. - -**2. Terménybiztosítás**. Bárki készíthet könnyedén származtatott szerződést, ha az árindexek helyett az időjárási adatokról érkező adatforrást használja. Ha egy iowai farmer olyan származtatott ügyletet vásárol, ami fordítottan fizet az Iowában esett csapadék alapján, majd, ha szárazság van, a farmer automatikusan pénzhez jut, ha pedig elég eső esik, a farmer szintén jól jár, mert jó termése lesz. Ez általánosságban kiterjeszthető természeti csapásra vonatkozó biztosítással. - -**3. Decentralizált adatforrás**. A pénzügyi CFD-k (nyitó- és záróérték közti különbség lekereskedése) esetében gyakorlatilag lehetőség van decentralizálni az adatforrást a [SchellingCoin](http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/) protokollal. A SchellingCoin a következőképpen működik: N fél beteszi a rendszerbe egy adott bázis értékét (például ETH/USD árfolyam), az értékeket rendezik, és mindenki, aki 25–75% között van egy tokent kap jutalmul. Ez a rendszer mindenkit arra ösztönöz, hogy olyan választ adjon, mint a többiek, és az egyetlen érték, amiben a résztvevők nagy száma realisztikusan egyet tud érteni a nyilvánvaló alap: az igazság. Ez egy decentralizált protokollt hoz létre, amely elméletileg bármilyen számú értéket adhat, ideértve az ETH/USD árát, vagy a berlini hőmérsékletet vagy egy nehéz számítási feladat eredményét. - -**4. Okos, több aláírásos fedezet**. A Bitcoin többaláírásos tranzakciós szerződéseket is enged, ahol például öt kulcsból három tudja elkölteni a pénzeszközöket. Az Ethereum ennél részletesebb lehetőségeket is kínál; például ötből négy mindent el tud költeni, ötből három naponta 10%-ot, ötből kettő pedig csak napi 0,5%-ot. Továbbá az Ethereum több aláírásos megoldás aszinkron – két fél különböző időben tudja regisztrálni az aláírását a blokkláncon, az utolsó aláírás küldi el automatikusan a tranzakciót. - -**5. Felhőben történő számítás**. Az EVM technológia szintén használható hitelesíthető számítási környezet létrehozására, ahol a felhasználók megkérhetnek másokat számítások végzésére, majd opcionálisan kérhetnek bizonyítékot arra, hogy a számítások adott, véletlenszerűen kiválasztott ellenőrzési pontokon pontosan lettek elvégezve. Így létre lehet hozni egy felhőalapú számítási piacot, amelyen bármelyik felhasználó részt vehet az asztali gépével, laptopjával vagy speciális szerverével, és együtt ellenőrizhetik szúrópróbaszerűen, hogy mely biztonsági letétek használhatók annak biztosítására, hogy a rendszer megbízható (azaz a csomópontok nem tudnak nyereségesen csalni). Bár egy ilyen rendszer nem feltétlenül felel meg minden feladatra; például nehézkes olyan feladatokat elvégezni nagyméretű felhőalapú csomópontokon, amelyek magasszintű, folyamat közbeni kommunikációt igényelnek. Más feladatokat azonban sokkal könnyebb párhuzamosan végezni; például a SETI@home, folding@home és általános algoritmusokat könnyebben meg lehet valósítani ilyen platformokon. - -**6. Közvetítő nélküli (peer-to-peer) szerencsejáték**. Tetszőleges számú peer-to-peer szerencsejáték-protokollt, például Frank Stajano és Richard Clayton [Cyberdice](http://www.cl.cam.ac.uk/~fms27/papers/2008-StajanoCla-cyberdice.pdf) protokollját, lehet megvalósítani Ethereum blokkláncon. A legegyszerűbb szerencsejáték protokoll egyszerűen egy CFD a következő blokkhashre, de ennél bonyolultabb protokollokat is lehet építeni, például szerencsejáték-szolgáltatásokat nullához közeli díjakkal, ahol ki lehet zárni a csalás lehetőségét. - -**7. Kimenetelre fogadó piacok**. Az Oracle vagy SchellingCoin környezetben futó kimenetelre fogadó piacokat könnyen meg lehet valósítani; ezek a piacok a SchellingCoin-nal együtt az első [futarchy](http://hanson.gmu.edu/futarchy.html) mainstream alkalmazássá nőhetik ki magukat a decentralizált szervezetek irányítási protokolljaként. - -**8. Láncon belüli decentralizált piacterek**, amelyek az azonosítási és elismerési rendszert használják alapként. - -## Egyebek és aggályok {#miscellanea-and-concerns} - -### Módosított GHOST implementáció {#modified-ghost-implementation} - -A „Greedy Heaviest Observed Subtree” (GHOST, „mohó legsúlyosabb részfa”) innovatív protokollt Yonatan Sompolinsky és Aviv Zohar vezette be [2013 decemberében](https://eprint.iacr.org/2013/881.pdf). A GHOST mögötti motiváció az volt, hogy azokon a blokkláncokon, ahol a megerősítési idő gyors, a magas elavulási aránynak köszönhetően csökken a biztonság – mivel a blokknak bizonyos időre van szüksége a hálózaton való terjedéshez, ha A bányász kibányász egy blokkot, majd B bányász még azelőtt kibányász egy blokkot, hogy A bányász blokkja eljutna B bányászhoz, ez utóbbi blokkja feleslegessé válik, és nem járul hozzá a hálózat biztonságához. Továbbá van egy centralizációs probléma is: ha A bányász egy 30% hasherejű bányászalap, és B bányásznak 10% hashereje van, akkor az A bányász elavult blokklétrehozási kockázata 70% (a fennmaradó 30%-ban az A bányász hozta létre az utolsó blokkot, így azonnal bányászati adathoz jut), míg B bányász az esetek 90%-ában fog létrehozni elavult blokkot. Ezért ha a blokkintervallum elég rövid ahhoz, hogy a lejárati arány magas legyen, az A bányász jelentősen hatékonyabb lesz pusztán a mérete miatt. A két hatás kombinálásával az a blokklánc, amely gyorsan gyárt blokkokat, valószínűleg vezetni fog egy bányászalapot, és elég nagy százalékot fog elfoglalni a hálózat hashteljesítményéből, hogy de facto átvegye az irányítást a bányászási folyamat fölött. - -Ahogy Sompolinsky és Zohar is leírta, a GHOST megoldja a hálózat biztonságának elvesztését érintő első problémát azzal, hogy lejárt blokkokat is belevesz annak kiszámításába, hogy melyik lánc a „leghosszabb”; azaz nem csak a blokk szülőit és elődjeit veszi figyelembe, hanem a blokk elődjeinek mellékes leszármazottjait is (Ethereum kifejezéssel élve uncle/nagybácsi) hozzáadja ahhoz a számításhoz, hogy melyik blokkon van a legtöbb proof-of-work. A centralizációval kapcsolatos második probléma megoldására túlhaladunk a Sompolinsky és Zohar által ismertetett protokollon, és blokkjutalmakat adunk az elavult blokkokra is: egy elavult blokk az alapjutalom 87,5%-át éri, míg az elavult blokkot tartalmazó unokaöccs megkapja a fennmaradó 12,5%-ot. A tranzakciós díjakat azonban nem kapják meg a nagybácsik. - -Az Ethereum a GHOST egy egyszerűsített verzióját implementálta, amely hét szintre megy le. Ez a következőképpen néz ki: - -- Egy blokknak meg kell határoznia egy szülőt, illetve 0 vagy több nagybácsit -- Egy B blokkban lévő nagybácsinak a következő tulajdonságokkal kell rendelkeznie: - - Közvetlen leszármazottnak kell lennie a k-adik generációs B ősnek, ahol `2 <= k <= 7`. - - Nem lehet a B őse - - Egy nagybácsinak érvényes blokkfejléccel kell rendelkeznie, de nem kell korábban hitelesített vagy érvényes blokknak lennie - - A nagybácsinak különböznie kell a korábbi blokkokban szereplő nagybácsiktól, illetve az ugyanabban a blokkban lévő más nagybácsiktól (nincs dupla szerepeltetés) -- Minden U nagybácsihoz a B blokkban, a B bányász további 3,125%-ot kap a jutalmához, és az U bányász 93,75% normál jutalomban részesül. - -A GHOST limitált verzióját, ahol legfeljebb 7 generációig szerepelhet nagybácsi, két ok miatt használtuk. Először is a korlátlan GHOST túl sok komplikációval járna annak kiszámításában, hogy egy adott blokkban mely nagybácsik érvényesek. Másodsorban a korlátlan GHOST, ahogy az Ethereumban használják, nem ösztönzi a bányászt, hogy a fő láncon bányásszon a nyilvános támadó által használt lánc helyett. - -### Díjak {#fees} - -Mivel a blokkláncban közzétett minden tranzakció költséget ró a hálózatra a letöltés és a hitelesítés miatt, szükség van valamilyen szabályozó mechanizmusra, általában tranzakciós díjak beiktatására, hogy meg lehessen akadályozni a rosszindulatú viselkedést. A Bitcoinban is alkalmazott alapértelmezett megközelítés szerint tisztán önkéntes díjakra van szükség, ami a bányászokra támaszkodik abban, hogy őrizzék a biztonságot és dinamikus minimumokat állítsanak be. Ezt a megközelítést nagyon kedvezően fogadták a Bitcoin közösségben, különösen azért, mert az „piaci alapú”, megengedi, hogy a bányászok és a tranzakciók küldői közötti keresletet és kínálatot határozza meg az árat. A probléma ezzel az érveléssel az, hogy a tranzakciók feldolgozása nem egy piac; bár intuitív módon vonzó a tranzakció feldolgozását olyan szolgáltatásként értelmezni, amelyet a bányász kínál küldőnek, a valóságban minden olyan tranzakciót, amelyhez bányász kell, a hálózat minden csomópontján fel kell dolgozni, így a tranzakció feldolgozási költségének jelentős részét külső felek fizetik, és nem a bányász hozza meg azt a döntést, hogy foglalkozik-e vele vagy sem. Így nagyon valószínű a „közlegelők tragédiája" típusú problémák előfordulása. - -Azonban úgy tűnik, hogy a piaci alapú mechanizmus ezen hibája, amikor pontatlan egyszerűsítő feltételezéssel élnek, mágikusan megszünteti saját magát. Az érvelés a következő. Tegyük fel, hogy: - -1. Egy tranzakció `k` művelethez vezet, `kR` jutalmat kínál minden olyan bányásznak, aki szerepel benne, ahol az `R` értéket a küldő állítja be, és a `k` és `R` (nagyjából) már előre látható a bányász oldalán. -2. Egy művelet feldolgozásához szükséges költség `C` bármely csomóponton (azaz az összes csomópont hatékonysága azonos) -3. `N` bányász csomópont van, mindegyik pontosan ugyanannyi feldolgozási teljesítménnyel (azaz `1/N` az összesből) -4. Nem létezik nem bányászó teljes csomópont. - -Egy bányász akkor hajlandó feldolgozni a tranzakciót, ha a várható jutalom nagyobb, mint a költség. Így a várható jutalom `kR/N` mivel a bányásznak `1/N` esélye van feldolgozni a következő blokkot, és a bányász feldolgozási költsége `kC`. Következésképpen a bányászok olyan tranzakciókban fognak részt venni, ahol `kR/N > kC`, vagy `R > NC`. Ne feledjük, hogy `R` a küldő által műveletenként biztosított díj, amely alulról korlátozza azt az előnyt, amit a küldő a tranzakcióból nyer, és az `NC` pedig a műveletet feldolgozó teljes hálózat költsége. Következésképpen a bányászok csak olyan tranzakcióban érdekeltek, amelyen a teljes haszonelvű előny nagyobb, mint a költség. - -Azonban a valóságban a feltételezésektől számos fontos eltérés mutatkozik: - -1. A bányász nagyobb költséget fizet a tranzakció feldolgozásáért mint a többi, hitelesítést végző csomópont, mivel az extra hitelesítéshez szükséges idő késlelteti a blokk terjedését, és növeli annak az esélyét, hogy a blokk elavulttá válik. -2. Tehát mégis létezik nem bányászó teljes csomópont. -3. A bányászati teljesítmény eloszlása a gyakorlatban radikálisan egyenlőtlenné válhat. -4. A spekulánsok, politikai ellenségek és őrültek, akiknek a használati függvényei a hálózatra nézve káros elemeket tartalmaznak okosan olyan szerződéseket készíthetnek, amelyekben a költségeik sokkal alacsonyabbak, mint a többi hitelesítő csomópont által fizetett költségek. - -(1) olyan tendenciát biztosít a bányásznak, hogy kevesebb tranzakcióba vonódjon bele, és (2) növeli az `NC` értékét; következésképpen ez a két hatás legalább részben kioltja egymást.[Hogyan?](https://github.com/ethereum/wiki/issues/447#issuecomment-316972260) A (3) és (4) a fő probléma; megoldásukra egy egyszerű lebegő limitet alkalmazunk: egyetlen blokkon sem lehet több művelet mint a hosszú távú exponenciális mozgóátlag `BLK_LIMIT_FACTOR`-szorosa. Különösképpen: - -```js -blk.oplimit = floor((blk.parent.oplimit \* (EMAFACTOR - 1) + -floor(parent.opcount \* BLK\_LIMIT\_FACTOR)) / EMA\_FACTOR) -``` - -A `BLK_LIMIT_FACTOR` és az `EMA_FACTOR` állandó, beállításuk 65 536 és 1,5 van jelenleg, amely további elemzés után változhat. - -Van még egy faktor, ami megszünteti a nagy blokkméretek iránti elköteleződést a Bitcoinban: a nagy blokkok terjedési ideje hosszabb, és így nagyobb eséllyel válnak elavulttá. Az Ethereumban a sok gázt fogyasztó blokkoknak is több időre van szüksége a terjedéshez, mivel egyrészt fizikailag hosszabbak, másrészt több időbe telik a státuszváltozási tranzakciók feldolgozásának validálása. Ez a késleltetési negatív ösztönző jelentős tényező a Bitcoin esetében, az Ethereum világában azonban kevésbé jellemző a GHOST protokoll miatt; következésképpen a szabályozott blokklimitekre való támaszkodás stabilabb alapkonfigurációt tesz lehetővé. - -### Számítás és Turing-teljesség {#computation-and-turing-completeness} - -Fontos megjegyezni, hogy az Ethereum virtuális gép Turing-teljes; azaz az EVM-kód minden olyan számítást képes titkosítani, amelyet rejtve lehet elvégezni, ideértve a végtelen hurkokat is. Az EVM-kód a hurkokat kétféleképpen teszi lehetővé. Egyfelől a `JUMP` utasítás lehetővé teszi a programnak, hogy visszaugorjon egy korábbi pontra a kódban, míg a `JUMPI` utasítás feltételhez kötött ugrást hajt végre, lehetővé téve a `while x < 27: x = x * 2` típusú állításokat. Másodsorban a szerződések más szerződéseket is meghívhatnak, ami potenciálisan lehetővé teszi a rekurzión keresztül történő hurkok alkalmazását. Ez természetesen egy problémát eredményez: a kártékony felhasználók le tudják állítani a bányászokat és a teljes csomópontokat azzal, hogy végtelen hurokba lépésre kényszerítik őket? Ez a helyzet a számítástechnikában megakadásproblémaként ismert: általánosságban nem lehet megmondani, hogy egy adott program mikor akad meg. - -Mint azt a státuszváltozási részben is leírtuk, a megoldásunk úgy működik, hogy egy tranzakcióban be kell állítani a maximálisan engedélyezett számítási lépések számát, és ha a futtatás tovább tart, a számítást visszatérítik, azonban díjat kell fizetni. Az üzenetek hasonlóképpen működnek. A megoldás mögötti motiváció bemutatására nézzük az alábbi példákat: - -- Egy támadó létrehoz egy szerződést, amely végtelen hurkot futtat, majd egy tranzakciót küld a bányásznak, amely aktiválja a hurkot. A bányász feldolgozza a tranzakciót, futtatja a végtelen hurkot, majd megvárja, amíg elfogy a gáz. Bár a futtatás közben kifogy a gáz és félúton megáll, a tranzakció továbbra is érvényes, és a bányász bekéri a díjat a támadótól minden számítási lépésért. -- Egy támadó egy nagyon hosszú végtelen hurkot hoz létre azzal a szándékkal, hogy a bányász olyan sokáig végezze a számítást, hogy a számítás végére pár új blokk is kikerüljön, és így lehetetlenné váljon a bányásznak a tranzakció belefoglalása, hogy díjat számíthasson fel. Azonban a támadónak be kell küldenie egy `STARTGAS` értéket, amely korlátozza a futtatásban használható számítások számát, így a bányász már előre tudni fogja, hogy a számítás jelentősen több lépésből fog állni. -- Egy támadó valami ilyesmit kódot lát a szerződésben `send(A,contract.storage[A]); contract.storage[A] = 0`, és pont annyi gázzal küldi el a tranzakciót, hogy futtatni lehessen az első lépést, de a másodikat már ne (azaz meglegyen a levétel, de az egyenleg ne csökkenjen le). A szerződés létrehozójának nem kell azon aggódnia, hogy védekezzen az ilyen támadások ellen, mivel ha a futtatás félúton megáll, azok vissza lesznek térítve. -- Egy pénzügyi szerződés úgy működik, hogy kilenc tulajdonos adatforrásának középértékét veszi a kockáztok minimalizálása érdekében. Amikor egy támadó átvesz egy adatforrást, amelyet úgy terveztek, hogy módosítható legyen a DAO részben ismertetett változó-cím-meghívás mechanizmuson keresztül, átkonvertálja úgy, hogy végtelen hurokban fusson, és így megpróbálja kikényszeríteni azokat a próbálkozásokat, amelyek pénzeszközöket kérnek a pénzügyi szerződéstől, amíg ki nem fogy a gáz. Azonban a pénzügyi szerződésekben be lehet állítani gázkorlátozást az üzeneten, és így meg lehet előzni a problémát. - -A Turing-teljesség alternatívája a Turing-nem-teljesség, ahol a `JUMP` és `JUMPI` nem létezik, és egyszerre csak egy szerződéspéldány létezhet a hívás-stackben. Ezzel a rendszerrel a korábban ismertetett díjrendszer és a megoldásunk hatékonyságával kapcsolatos bizonytalanságok nem feltétlenül szükségesek, mivel a szerződés futtatásának költségét annak mérete korlátozza be. Továbbá a Turing-nem-teljesség nem túl nagy korlátozást jelent; az általunk kitalált összes szerződés példa közül csupán egyhez volt szükség hurokra, és még ez az egy hurok is eltávolítható egy 26-szor ismételt, egysoros kódrészlettel. A Turing-teljesség súlyos implikációi, valamint a korlátozott haszon alapján, miért nincs egy Turing-nem-teljesség nyelv? A valóságban a Turing-nem-teljesség messze van a probléma elegáns megoldásától. Nézzük meg a következő szerződéseket, hogy ennek okát megértsük: - -```sh -C0: call(C1); call(C1); -C1: call(C2); call(C2); -C2: call(C3); call(C3); -... -C49: call(C50); call(C50); -C50: (futtasson egy lépést a programból, majd rögzítse a változtatást a tárhelyen) -``` - -Küldjön egy tranzakciót A-nak. Így 51 tranzakcióban van egy olyan szerződésünk, amely akár 250 számítási lépést is magában foglalhat. A bányászok megpróbálhatják már előre kiszűrni ezeket a logikai bombákat, ha értéket tartanak minden szerződés mellett, amely meghatározza, hogy legfeljebb mennyi számítási lépést vehet fel, és kiszámítják ezt azokhoz a szerződésekhez, amelyek rekurzívan hívnak más szerződéseket. Ez azonban arra kényszerítené a bányászokat, hogy letiltsák azokat a szerződéseket, amelyek más szerződéseket hoznak létre (mivel a fenti 26 szerződés létrehozása és futtatása könnyedén egy szerződésbe gyúrható). Másik problematikus pont, hogy az üzenet címmezője egy változó, tehát általánosságban idő előtt nem lehet megmondani, hogy milyen más szerződést fog meghívni egy adott szerződés. Ezért összességében meglepő következtetésre jutottunk: a Turing-teljességet meglepően könnyű kezelni, valamint a Turing-teljesség hiányát hasonlóképpen meglepően nehéz kezelni, kivéve, ha ugyanazokat a kontrollokat alkalmazzuk – de ebben az esetben miért ne legyen a protokoll Turing-teljes? - -### Valuta és kibocsátás {#currency-and-issuance} - -Az Ethereum rendszerben a saját beépített valuta, az ether kettős célt szolgál, egyfelől egy elsődleges likviditási réteget biztosít a különböző digitális eszközök közötti hatékony váltáshoz, másfelől fontos mechanizmust biztosít a tranzakciós költségek fizetésére. Kényelmi szempontból, valamint elkerülve a későbbi vitákat (lásd a jelenlegi mBTC/uBTC/satoshi vitát a Bitcoin kapcsán), a névértékek előre felcímkézésre kerül: - -- 1: wei -- 1012: szabo -- 1015: finney -- 1018: ether - -Ez a „dollár” és „cent”, illetve a „BTC” és „satoshi” koncepció kibővített változataként értelmezhető. A közeljövőben az „ether” lesz használatos a hagyományos tranzakciókra, a „finney” a mikrotranzakciókra, a „szabo” és a „wei” pedig a díjakkal és protokollimplementációkkal kapcsolatos technikai értekezésekben; a fennmaradó címletek pedig később lehetnek hasznosak, és jelenleg nem szerepelnek a kliensekben. - -A kibocsátási modell a következő: - -- Az ether mint valuta egy BTC-hez viszonyítva 1000–2000 ether árfolyamon fog forogni; ez a mechanizmus az Ethereum szervezet forrásait biztosítja, valamint ezzel lehet fizetni a fejlesztésekért, amelyet más platformon, például a Mastercoinon és az NXT-n már sikerrel használtak. A korai vásárlók nagyobb kedvezményekben részesülnek. Az eladásból kapott BTC-ket teljes mértékben a fejlesztők fizetésére és javadalmazására fordítják, valamint különböző profitot célzó és non-profit projektekbe fektetik az Ethereum és kriptovaluta ökoszisztémában. -- A teljes értékesített összeg (60 102 216 ETH) 0,099-szeresét a szervezet kapja a korai hozzájárulók kompenzálására, valamint az ETH-ben denominált költségekre fordítják a genezisblokk előtt. -- A teljes értékesített összeg 0,099-szeresét hosszú távú tartalékba helyezik. -- A teljes értékesített összeg 0,26-szorosa a bányászokhoz kerül évente, örökre ezután a pont után. - -| Csoport | Indításkor | Egy év után | Öt év után | -| --------------------------------- | ---------- | ----------- | ---------- | -| Pénznemegységek | 1,198 X | 1,458 X | 2,498 X | -| Vevők | 83,5% | 68,6% | 40,0% | -| Eladás előtt felhasznált tartalék | 8,26% | 6,79% | 3,96% | -| Eladás után felhasznált tartalék | 8,26% | 6,79% | 3,96% | -| Bányászok | 0% | 17,8% | 52,0% | - -#### Hosszú távú kínálati növekedési ütem (százalék) - -![Ethereum-infláció](./ethereum-inflation.png) - -_A lineáris valutakibocsátások ellenére, a Bitcoinhoz hasonlóan, a kínálati növekedési ütem nulla felé tart._ - -A fenti modellben két fő választási lehetőség van: 1) egy felnagyítási alap megléte és mérete; és 2) egy állandóan növekvő lineáris kínálat megléte, szemben a Bitcoin esetében látható felső korlátos kínálattal. A felnagyítási alap indoklása a következő. Ha nincs felnagyítási alap, és a lineáris kibocsátás 0,217x-re csökken az azonos mértékű infláció biztosítására, akkor az ether teljes mennyisége 16,5%-kal lesz kevesebb, és így minden egység 19,8%-kal értékesebb lesz. Következésképpen az egyensúlyban 19,8%-kal több ethert vásárolnak az értékesítés folyamán, így minden egység megőrzi korábbi értékét. A szervezet ezután 1,198x BTC-vel rendelkezik, amelyet két szeletre lehet bontani: az eredeti BTC és a további 0,198x-es rész. Következésképpen a helyzet _pontosan megegyezik_ a nagyítással, van azonban egy fontos különbség: a szervezetnél csupán BTC van, és így nincs ösztönözve arra, hogy támogassa az ether mértékegység értékét. - -Az állandó lineáris keresletnövekedési modell csökkenti a Bitcoin esetében sokak által túlzónak tartott vagyonkoncentráció kockázatát, és lehetőséget biztosít a jelenlegi és jövőbeli vásárlóknak, hogy reális esélyük legyen valutaegységeket venni, ugyanakkor erősen ösztönöz arra, hogy még több ethert vegyenek és tartsanak, mivel a „keresletnövekedési ütem” százalékos értéke továbbra is idővel a nulla felé közelít. Azt is feltételezzük, hogy mivel óvatlanság, haláleset stb. miatt mindig van, aki elveszti az érméit, és ez százalékosan is modellezhető az éves kínálat függvényében, a forgalomban lévő teljes valutakészlet végül a veszteség arányával elosztott éves kibocsátás értékével azonos értéken stabilizálódik (például, ha a veszteség aránya 1%, akkor amint a kínálat eléri a 26X-t, évente 0,26X lesz bányászva és 0,26X veszik el, és létrejön az egyensúly). - -Ne feledjük, hogy a jövőben valószínű, hogy az Ethereum proof-of-stake modellre vált a biztonság érdekében, és évi nulla és 0,05X közé csökken a kibocsátásra vonatkozó követelmény. Abban az esetben, ha az Ethereum-szervezet elveszíti pénzeszközeit, vagy valamilyen más okból kifolyólag eltűnik, nyitva hagyunk egy „társadalmi szerződést”: mindenkinek joga van létrehozni egy jövőbeli Ethereum-verziót azzal a feltétellel, hogy az ether mennyisége legfeljebb `60102216 * (1,198 + 0,26 * n)` lehet, ahol az `n` a genezisblokk utáni évek számát jelöli. A létrehozók a proof-of-stake által hajtott kínálatnövekedés és a maximálisan engedélyezett kínálatbővülés különbségét részben vagy egészben szabadon értékesíthetik tömeges eladás (crowd-sell) formájában, illetve kioszthatják a fejlesztés költségeinek lefedésére. Azok a frissítések, amelyek nem felelnek meg a társadalmi szerződés követelményeinek, jogosan elágaztathatók a követelményeknek megfelelő verziókba. - -### A bányászat centralizálása {#mining-centralization} - -A Bitcoin bányászati algoritmusa úgy működik, hogy a bányászok SHA256-számításokat végeznek a blokkfejléc kissé módosított verzióin egymás után több milliószor, amíg végül egy csomópont egy verzióhoz ér, amelynek hashértéke kisebb mint a cél (jelenleg körülbelül 2192). Azonban ez a bányászati algoritmus a centralizáció két formájával szemben sérülékeny. Először is a bányászati ökoszisztémát az ASIC-ok (alkalmazásspecifikus integrált körök) az erre a célra tervezett számítógép-chipek dominálják, és ezért ezek többezerszer hatékonyabbak a Bitcoin-bányászat során. Ez azt jelenti, hogy a Bitcoin-bányászat már egyáltalán nem decentralizált és egyenlőségen alapuló tér, és több millió dolláros tőkére van szükség ahhoz, hogy hatékonyan részt lehessen venni benne. Másodsorban a legtöbb Bitcoin-bányász gyakorlatilag nem helyileg validálja a blokkokat; helyette egy centralizált bányászalapra támaszkodik a blokkfejlécek megadásakor. Ez a probléma azonban még rosszabb: a jelen tartalom írásakor a legjobb három bányászalap indirekt módon a feldolgozási teljesítmény körülbelül 50%-át birtokolja, bár ezt némiképp enyhíti az a tény, hogy a bányászok átválthatnak egy másik alapra, ha az alap vagy a koalíció 51%-os támadással próbálkozik. - -Az Ethereumban jelenleg az a szándék, hogy olyan bányászati algoritmust használjanak, amelyben a bányászoknak véletlenszerűen kell adatot lekérniük a státuszból, ki kell számítaniuk néhány véletlenszerűen kiválasztott tranzakciót a blokklánc utolsó N blokkjáról, és vissza kell adniuk az eredmény hashét. Ennek két fontos előnye van. Először is az Ethereum-szerződésekben bármilyen számítás lehet, így egy Ethereum ASIC lényegében egy általános számításra használt ASIC – azaz egy jobb CPU. Másodszor, a bányászathoz hozzá kell férni a teljes blokklánchoz, ami arra kényszeríti a bányászokat, hogy a teljes blokkláncot tárolják, és legalább képesnek kell lenniük minden tranzakció hitelesítésére. Emiatt nincs szükség centralizált bányászati alapokra; bár a bányászati alapok továbbra is betöltik azt a legitim szerepet, hogy kiegyenlítik a jutalomelosztás véletlenszerűségét – ezt a funkciót ugyanígy el tudják látni a peer-to-peer alapok központi irányítás nélkül. - -Ez a modell még nincs tesztelve, és szembesülhetünk még nehézségekkel az okos optimalizálások elkerülése okán, amikor a szerződésvégrehajtást bányászati algoritmusként használják. Azonban ennek az algoritmusnak egyik érdekes funkciója, hogy bárki „megmérgezheti a kutat”, ha nagyszámú szerződést vezet be a blokkláncra kifejezetten azért, hogy megakasszon bizonyos ASIC-okat. Az ASIC gyártók számára léteznek gazdasági ösztönzők arra, hogy ezzel a trükkel megtámadják egymást. Ezért az általunk fejlesztett megoldás végeredményben egy adaptív, gazdasági, humán megoldás, és nem pusztán technikai. - -### Méretezhetőség {#scalability} - -Az Ethereummal kapcsolatos gyakori aggály a skálázhatóság kérdése. A Bitcoinhoz hasonlóan az Ethereumnak is megvan az a hibája, hogy a hálózatban minden csomópontnak fel kell dolgoznia a tranzakciókat. A Bitcoin esetében a jelenlegi blokklánc mérete körülbelül 15 GB, ami óránként mintegy 1 MB-tal nő. Ha a Bitcoin hálózatnak másodpercenként 2000 Visa-tranzakciót kellene feldolgoznia, akkor három másodpercenként nőne 1 MB-tal (1 GB óránként, 8 TB évente). Az Ethereumon is hasonló növekedési tempó figyelhető meg, amelyet tovább nehezít az, hogy az Ethereum blokkláncán számos alkalmazást futtatnak, míg a Bitcoin egy valuta; ugyanakkor javítja a helyzetet, hogy az Ethereum teljes csomópontjainak csak a státuszt és nem a teljes blokkláncelőzményt kell tárolniuk. - -A nagyméretű blokklánccal a centralizáció kockázata a fő probléma. Ha a blokklánc mérete mondjuk 100 TB-ra nő, a legvalószínűbb forgatókönyv szerint csak nagyon kevés nagyvállalat tud majd teljes csomópontot futtatni, az összes hagyományos felhasználó pedig könnyű SPV-csomópontokat fog használni. Egy ilyen helyzetben felmerülhet a lehetséges aggály, hogy a teljes csomópontok összefoghatnak, és megállapodhatnak abban, hogy profitábilis módon csaljanak (például módosítsák a blokkok után járó jutalmat, vagy BTC-t adjanak maguknak). A könnyű csomópontok nem tudják ezt azonnal felismerni. Természetesen legalább egy becsületes teljes csomópont valószínűleg létezne, és a csalás kiderülése után néhány órával már a Reddit is tele lenne a hírrel, azonban ezen a ponton már túl késő: a normál felhasználókon múlna, hogy szervezetten tiltólistára tegyék az adott blokkokat, ez a koordinációs probléma jelentős és szinte megoldhatatlan helyzetet teremt, hasonlóan egy sikeres 51%-os támadáshoz. A Bitcoin esetében ez jelenleg probléma, de létezik rá egy blokkláncmódosítási [javaslat Peter Toddtól](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/), amely enyhít a problémán. - -Az Ethereum két további stratégiát fog használni a probléma megoldására. Először a blokkláncalapú bányászati algoritmusok miatt legalább minden bányász rá lesz kényszerítve, hogy teljes csomópont legyen, ami alacsonyabb korlátot hoz létre a teljes csomópontok viszonylatában. Másodszor, ami még fontosabb, egy közbenső státuszfagyökeret szerepeltetünk a blokkláncban a tranzakciók feldolgozása után. Még akkor is, ha a blokk validálása centralizált, amíg van becsületes hitelesítő csomópont, a centralizációs probléma megkerülhető a protokoll validálásával. Ha egy bányász érvénytelen blokkot tesz közzé, akkor a blokk nincs megfelelően formázva, vagy az `S[n]` státusz pontatlan. Mivel az `S[0]` kód pontos, kell lennie egy első `S[i]` státusznak, amely hibás ott, ahol az `S[i-1]` pontos. A hitelesítő csomópont megadja az `i` indexet egy érvénytelenségi bizonyítékkal (proof of invalidity), amely olyan Patricia-facsomópontokból áll, amelyeknek fel kell dolgozniuk az `APPLY(S[i-1],TX[i]) -> S[i]` kifejezést. A csomópontok használni tudják ezeket a Patricia-csomópontokat a számítás egy részének futtatásához, és látni fogják, ha a generált `S[i]`nem egyezik a megadott `S[i]` értékkel. - -Egy másik, kifinomultabb támadásban rosszindulatú bányászok félkész blokkokat publikálnak, így a teljes információ nem is létezik annak megállapítására, hogy a blokk érvényes-e. A megoldás egy kihívásra reagáló protokoll: az ellenőrző csomópontok céltranzakciós indexek formájában „kihívásokat” adnak ki, majd amikor visszakapnak egy csomópontot, egy könnyű csomópont mindaddig érvénytelennek tekinti a blokkot, amíg egy másik csomópont, egy bányász vagy egy másik hitelesítő, vissza nem ad Patricia-csomóponti alkészleteket, igazolva az érvényességet. - -## Következtetés {#conclusion} - -Az Ethereum protokollt eredetileg egy frissített kriptovaluta-verziónak tekintették, amely haladó funkciókat is kínált, például blokkláncon lévő fedezetet, kivételi korlátokat, pénzügyi szerződéseket, szerencsejátékpiacokat és hasonlókat egy nagyon általánosított programnyelven. Az Ethereum-protokoll nem „támogatná” közvetlenül az alkalmazásokat, azonban a Turing-teljes programnyelv megléte azt jelenti, hogy tetszőleges mennyiségű szerződés hozható létre bármilyen tranzakciótípushoz vagy alkalmazáshoz. Még érdekesebb az Ethereummal kapcsolatban, hogy az Ethereum-protokoll sokkal több puszta valutánál. A decentralizált fájltárolással, számításokkal és hírtőzsdei piacokkal kapcsolatos protokollok a több tucat hasonló koncepció mellett magukban rejtik a számítási ipar jelentős hatékonyságnövelésének potenciálját, és masszív lökést adnak más peer-to-peer protokolloknak egy korábban nem látott gazdasági réteg hozzáadásával. Végezetül pedig jelentős számú alkalmazás van, amely egyáltalán nem foglalkozik pénzzel. - -Az Ethereum-protokollban implementált tetszőleges státuszváltozási függvény koncepciója egyedi potenciált rejtő platformot kínál; szemben a zárt végű, egycélú protokollokkal, amelyeket egy bizonyos típusú alkalmazásra fejlesztenek az adattárolás, pénzügy vagy szerencsejáték világában, az Ethereum egy alapvetően nyílt végű koncepció, és hiszünk abban, hogy kiválóan szolgál sok pénzügyi és nem pénzügyi protokoll alaprétegeként az elkövetkező években. - -## Jegyzetek és további olvasnivaló {#notes-and-further-reading} - -### Jegyzetek {#notes} - -1. A kifinomult olvasó észreveheti, hogy gyakorlatilag egy Bitcoin-cím az elliptikus görbe nyilvános kulcs hashe, és nem a nyilvános kulcs maga. Azonban gyakorlatilag teljesen legitim kriptográfiai terminológia a pubkey hash nyilvános kulcsként történő hivatkozása. Ez azért van, mert a Bitcoin kriptográfiáját tekinthetjük egy egyedi digitális aláírás-algoritmusnak, ahol a nyilvános kulcs az ECC pubkey hashéből áll, az aláírás az ECC pubkey és az ECC aláírás együttesen, a hitelesítő algoritmusban pedig az aláírásban lévő ECC pubkeyt a nyilvános kulcsként rendelkezésre bocsátott ECC pubkey hashsel vetik összes, majd az ECC aláírást az ECC pubkey értékével hitelesítik. -2. Gyakorlatilag a 11 előző blokk mediánja. -3. Belső értelmezésben a 2 és a „CHARLIE” egy szám[fn3](#notes), ez utóbbi big-endian bázis 256-os reprezentációjában van. A számok 0-tól legfeljebb 2256-1-ig terjedhetnek. - -### További olvasnivaló {#further-reading} - -1. [Valódi érték](http://bitcoinmagazine.com/8640/an-exploration-of-intrinsic-value-what-it-is-why-bitcoin-doesnt-have-it-and-why-bitcoin-does-have-it/) -2. [Okos tulajdonság](https://en.bitcoin.it/wiki/Smart_Property) -3. [Okosszerződések](https://en.bitcoin.it/wiki/Contracts) -4. [B-money](http://www.weidai.com/bmoney.txt) -5. [Újrahasznosítható proof-of-work](https://nakamotoinstitute.org/finney/rpow/) -6. [Biztonságos tulajdonságcímek tulajdonosi rendelkezéssel](https://nakamotoinstitute.org/secure-property-titles/) -7. [Bitcoin fehérkönyv](http://bitcoin.org/bitcoin.pdf) -8. [Namecoin](https://namecoin.org/) -9. [Zooko háromszöge](https://wikipedia.org/wiki/Zooko's_triangle) -10. [Colored coins fehérkönyv](https://docs.google.com/a/buterin.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit) -11. [Mastercoin fehérkönyv](https://github.com/mastercoin-MSC/spec) -12. [Decentralizált autonóm vállalatok, Bitcoin Magazine](http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/) -13. [Egyszerűsített fizetéshitelesítés](https://en.bitcoin.it/wiki/Scalability#Simplified_payment_verification) -14. [Merkle-fák](https://wikipedia.org/wiki/Merkle_tree) -15. [Patricia-fák](https://wikipedia.org/wiki/Patricia_tree) -16. [GHOST](https://eprint.iacr.org/2013/881.pdf) -17. [StorJ és Autonóm ügynökök, Jeff Garzik](http://garzikrants.blogspot.ca/2013/01/storj-and-bitcoin-autonomous-agents.html) -18. [Mike Hearn az Okos tulajdonságokról a Turing Fesztiválon](https://www.youtube.com/watch?v=MVyv4t0OKe4) -19. [Ethereum RLP](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP) -20. [Ethereum Merkle-Patricia-fák](https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree) -21. [Peter Todd a Merkle-összegfákról](https://web.archive.org/web/20140623061815/http://sourceforge.net/p/bitcoin/mailman/message/31709140/) - -_A fehérkönyv történetét tekintse meg ezen [a wiki](https://github.com/ethereum/wiki/blob/old-before-deleting-all-files-go-to-wiki-wiki-instead/old-whitepaper-for-historical-reference.md) oldalon._ - -_Az Ethereum, hasonlóan sok más közösség által vezetett, nyílt forráskódú szoftverprojekthez, a kezdeti elindulás óta sokat fejlődött. Ha többet szeretnél megtudni az Ethereum legutóbbi fejlesztéseiről és az általunk elvégzett protokollváltoztatásokról, akkor ezt az [útmutatót](/learn/) ajánljuk._ diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/bridges/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/bridges/index.md deleted file mode 100644 index 06f59eb954b..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/bridges/index.md +++ /dev/null @@ -1,135 +0,0 @@ ---- -title: Hidak -description: Fejlesztőknek szóló áttekintés a hidakról -lang: hu ---- - -Az L1 blokkláncok és az L2 [skálázási](/developers/docs/scaling/) megoldások elterjedésével, valamint az egyre növekvő számú, láncokon átívelő, decentralizált alkalmazással a hálózati infrastruktúra alapvető részévé vált a láncok közötti kommunikáció és eszközmozgás. Különböző típusú hidak léteznek, hogy ezt lehetővé tegyék. - -## A hidak szükségessége {#need-for-bridges} - -Léteznek hidak a blokklánc-hálózatok összekapcsolására. Lehetővé teszik a blokkláncok közötti összekapcsolhatóságot és átjárhatóságot. - -A blokkláncok elkülönült környezetben léteznek, ami azt jelenti, hogy a blokkláncok nem tudnak természetes módon kereskedni és kommunikálni más blokkláncokkal. Emiatt, bár egy ökoszisztémán belül jelentős tevékenység és innováció valósulhat meg, ezt mégis korlátozza a más ökoszisztémákkal való összekapcsolhatóság és interoperabilitás hiánya. - -A hidak lehetőséget nyújtanak arra, hogy az elszigetelt blokklánc-környezetek összekapcsolódjanak egymással. Olyan útvonalat hoznak létre a blokkláncok között, ahol tokenek, üzenetek, tetszőleges adatok és akár [okosszerződés](/developers/docs/smart-contracts/) meghívások is átvihetők egyik láncból a másikba. - -## A hidak előnyei {#benefits-of-bridges} - -A hidak számos felhasználási módot tesznek lehetővé azáltal, hogy a blokklánchálózatok számára az adatcserét és az eszközmozgatást biztosítanak. - -A blokkláncok egyedi erősségekkel, gyengeségekkel és megközelítésekkel rendelkeznek az alkalmazások építésében (például sebesség, tranzakcióátvitel, költségek stb.). A hidak azáltal is segítik a teljes kriptoökoszisztéma fejlődését, hogy a blokkláncok felhasználhatják egymás innovációit. - -A fejlesztők számára a hidak a következőket biztosítják: - -- bármely adat, információ és eszköz átadása a láncok között. -- új funkciók és felhasználási esetek bevezetése a protokollok számára, mivel a hidak kibővítik azok tervezési lehetőségeit. Például egy eredetileg az Ethereum fő hálózatra telepített hozamgyűtjő protokoll likviditási alapokat kínálhat az összes EVM-kompatibilis láncban. -- kihasználhatóvá válnak a különböző blokkláncok erősségei. A fejlesztők például kihasználhatják a különböző L2-megoldások által kínált alacsonyabb díjakat azáltal, hogy dappjaikat az összevont tranzakciókra építik, a mellékláncok és a felhasználók pedig a hidakkal használhatják ezeket. -- együttműködés a különböző blokklánc-ökoszisztémák fejlesztői között új termékek létrehozására. -- különböző ökoszisztémák felhasználóit és közösségeit vonzzák a dappjaikhoz. - -## Hogyan működnek a hidak? {#how-do-bridges-work} - -Bár számos [híddizájn](https://li.fi/knowledge-hub/blockchain-bridges-and-classification/) létezik, az eszközök láncok közötti mozgatásának három módja kiemelkedik: - -- **Zárolás és mintelés – ** Eszközök zárolása a forrásláncon és kibocsátása (mintelése) a célláncon. -- **Elégetés és mintelés –** A forrásláncban lévő eszközök égetése és azok kibocsátása (mintelés) a célláncon. -- **Atomikus átváltás –** A forrásláncon lévő eszközök átváltása a célláncon lévő eszközökre egy másik féllel. - -## Hídtípusok {#bridge-types} - -A hidak általában a következő kategóriák egyikébe esnek: - -- **Natív hidak –** Ezeket jellemzően azért építik, hogy egy adott blokkláncon a likviditást beindítsák, megkönnyítve a felhasználók számára a pénzeszközök mozgatását az ökoszisztémába. Az [Arbitrum-híd](https://bridge.arbitrum.io/) például azért jött létre, hogy a felhasználók kényelmesen át tudjanak hidalni az Ethereum fő hálózatról az Arbitrumra. Hasonló még a Polygon PoS híd, az [Optimism Gateway](https://app.optimism.io/bridge) stb. -- **Validátor- vagy orákulumalapú hidak –** Ezek külső validátorkészletre vagy orákulumokra támaszkodnak a láncközi átvitelekhez. Például a Multichain és az Across. -- **Általános üzenettovábbító hidak –** Ezek képesek eszközök, üzenetek és tetszőleges adatok láncok közötti átvitelére. Például: Axelar, LayerZero és Nomad. -- **Likviditási hálózatok –** Ezek elsősorban az eszközök egyik láncból a másikba történő átvitelére összpontosítanak atomikus átváltások révén. Általában nem támogatják a láncok közötti üzenettovábbítást. Például a Connext és a Hop. - -## A kompromisszumok, melyeket figyelembe kell venni {#trade-offs} - -A hidakra vonatkozóan nincsenek tökéletes megoldások. Ehelyett olyan kompromisszumok léteznek, melyek adott célra irányulnak. A fejlesztők és a felhasználók a következő tényezők alapján értékelhetik a hidakat: - -- **Biztonság –** Kik biztosítják a rendszert? A külső validátorok által biztosított hidak általában kevésbé biztonságosak, mint a blokklánc validátorai által helyileg vagy natívan biztosítottak. -- **Kényelem –** Mennyi ideig tart végrehajtani egy tranzakciót, és mennyit kell aláírnia a felhasználónak? A fejlesztőnek az számít továbbá, hogy mennyi ideig tart integrálni a hidat, és mennyire bonyolult ez a folyamat? -- **Csatlakozási lehetőségek –** Az adott híd milyen láncokhoz tud kapcsolódni (például összevont tranzakciókhoz, mellékláncokhoz, más L1 blokkláncokhoz stb.), és mennyire bonyolult egy új blokkláncot integrálni rá? -- **Összetettebb adatok továbbítási lehetősége –** Tud esetleg a híd üzeneteket és összetettebb, tetszőleges adatokat továbbítani a láncokra, vagy csak láncok közötti eszköztranszfert támogat? -- **Költséghatékonyság –** Mennyibe kerül az eszközök láncok közötti átadása egy hídon keresztül? A hidak jellemzően fix vagy változó díjat számítanak fel a gázköltségektől és az egyes útvonalak likviditásától függően. Az is fontos, hogy értékeljük a híd költséghatékonyságát azon tőke alapján, amelyet a biztonságának biztosításához használnak. - -A hidakat kategorizálhatjuk aszerint, hogy igényelnek bizalmat vagy sem. - -- **Bizalomigényű –** Az ilyen hidakat külsődlegesen biztosítják. A láncok közötti adatátvitelhez külső biztosítókat használnak (többaláírásos, többszereplős számítási rendszerek, orákulumhálózat). Emiatt képesek jó kapcsolódási lehetőséget és általánosított üzenettovábbítást biztosítani láncok között. Emellett a sebesség és a költséghatékonyság szempontjából is jók. Ez a biztonság rovására megy, mivel a felhasználóknak a híd biztonságára kell hagyatkozniuk. -- **Bizalomigény nélküli –** Ezek a hidak az általuk összekötött blokkláncokra és azok validátoraira támaszkodnak az üzenetek és a tokenek átvitelében. Ezek bizalomigény nélküliek, mert nem adnak hozzá új bizalmi feltételezéseket (a blokkláncokon túl). Ennek eredményeképpen a bizalomigénymentes hidak biztonságosabbnak tekinthetők, mint a bizalomigénnyel működők. - -Ahhoz, hogy a bizalomigény nélküli hidakat más tényezők alapján értékelni tudjuk, általános üzenettovábbító hidakra és likviditási hálózatokra kell bontanunk azokat. - -- **Általános üzenettovábbító hidak –** Ezek jellemzője, hogy biztonságot és összetettebb adatok láncokon keresztüli továbbítását kínálják. Jellemzően költséghatékonyak is. Ezek az erősségek azonban hátrányt okoznak más fronton: a könnyű ügyfélhidaknál (mint az IBC) az összekapcsolhatóságban, a csalási bizonyítást használó optimista hidaknál (mint a Nomad) a sebességben. -- **Likviditási hálózatok –** Ezek atomikus átváltásokat használnak az eszközök átruházására, és helyileg ellenőrzött rendszerek (a tranzakciók ellenőrzésére a mögöttes blokkláncok validálóit használják). Ennek eredményeképpen a biztonság és a gyorsaság terén is kiemelkednek. Ráadásul viszonylag költséghatékonyak és jó csatlakozási lehetőségeket kínálnak. A legnagyobb kompromisszum azonban az, hogy nem képesek összetettebb adatok továbbítására, mivel nem támogatják a láncok közötti üzenetátvitelt. - -## A hidak használatának kockázata {#risk-with-bridges} - -A hidak felelősek a [decentralizált pénzügyek (DeFi) három legnagyobb meghackelését](https://rekt.news/leaderboard/), és még a fejlesztés korai szakaszában vannak. A hidak használata a következő kockázatokkal jár: - -- **Okosszerződés-kockázat –** Bár sok híd sikeresen átment az ellenőrzéseken, elég egyetlen hiba egy okosszerződésben, hogy az eszközök sebezhetővé váljanak a hackerekkel szemben (például a [Solana féreglyukhídja](https://rekt.news/wormhole-rekt/) esetében). -- **Szisztematikus pénzügyi kockázatok** – Számos híd használja a csomagolt eszközöket arra, hogy az eredeti eszköz kanonikus változatait egy új láncon bocsássa ki (minting). Ez rendszerszintű kockázatnak teszi ki az ökoszisztémát, mivel a tokenek csomagolt változatait kihasználhatják. -- **Partnerkockázat –** Egyes hidak olyan konstrukciót használnak, amelyben a felhasználóknak bízniuk kell abban, hogy a validátorok nem játszanak össze a pénzeszközök ellopásáért. Mivel a felhasználóknak meg kell bízniuk harmadik fél szereplőkben, olyan kockázatoknak teszi ki őket, mint a rug pull (az eszköz mögül eltűnik a csapat és a pénz), a cenzúra és más rosszindulatú tevékenységek. -- **Nyitott problémák –** Mivel a hidak a fejlesztés kezdeti szakaszában vannak, számos megválaszolatlan kérdés van azzal kapcsolatban, hogyan fognak teljesíteni különböző piaci körülmények között, például hálózati torlódások idején és előre nem látható események, mint a hálózati szintű támadásoknál vagy státuszok visszaállításakor. Ez a bizonytalanság bizonyos kockázatokat rejt magában, amelyek mértéke még nem ismert. - -## Hogyan tudják a dappok a hidakat használni? {#how-can-dapps-use-bridges} - -Íme néhány gyakorlati alkalmazás, amelyet a fejlesztők megfontolhatnak a hidakkal és a dappok láncok közötti használatával kapcsolatban: - -### Hidak integrálása {#integrating-bridges} - -A fejlesztők számos módon adhatnak hozzá hidakat: - -1. **Saját híd építése –** Biztonságos és megbízható hidat építeni nem könnyű, különösen, ha a bizalomigény minimalizálása fontos. Ezenkívül többéves tapasztalatot és műszaki szakértelmet igényel a skálázhatósági és interoperabilitási tanulmányok miatt. Továbbá egy gyakorlatias csapatra lenne szükség a híd fenntartásához, és elegendő likviditás bevonása is szükséges, hogy ez megvalósítható legyen. - -2. **Több hídválasztási lehetőség megjelenítése a felhasználóknak–** Számos [dapp](/developers/docs/dapps/) megköveteli, hogy a felhasználók rendelkezzenek natív tokennel, hogy kapcsolatba léphessenek velük. Annak érdekében, hogy a felhasználók hozzáférhessenek a tokenjeikhez, különböző áthidalási lehetőségeket kínálnak a weboldalukon. Ez a módszer átmeneti megoldás a probléma megoldására, mivel a felhasználót eltávolítja a dappfelülettől, de továbbra is kölcsönhatásban kell maradnia más dappokkal és hidakkal. Emiatt nehéz a belépés, és ezzel együtt a hibák lehetősége is megnő. - -3. **Híd integrálása –** Ekkor a dappnak nem kell egy külső hídra és DEX-interfészekre küldenie a felhasználókat. Így a dappok képesek javítani a felhasználói élményt. Ennek azonban megvannak a maga korlátai: - - - A hidak kiértékelése és karbantartása nehéz és időigényes. - - Egy adott híd kiválasztása egyetlen meghibásodási pontot és függőséget hoz létre. - - A dappot bekorlátozzák a híd képességei. - - A hidak magukban nem feltétlen elegek. Előfordulhat, hogy a dappoknak DEX-ekre is szükségük van, hogy olyan funkciókat is biztosíthassanak, mint a láncok közötti átváltások. - -4. **Több híd integrálása –** Ez a megoldás számos problémát megold, amelyek akkor merülnek fel, amikor egyetlen hidat integrálunk. Ugyanakkor ennek is vannak korlátai, mivel több híd integrálása erőforrásigényes, és technikai és kommunikációs többletköltséget is jelent a fejlesztők számára – ami a kriptográfia legszűkösebb erőforrása. - -5. **Hídaggregátor integrálása –** Egy másik lehetőség a dappok számára egy hídaggregációs megoldás integrálása, amely hozzáférést biztosít több hídhoz. A hídaggregátorok a hidak erősségeit öröklik, és nem korlátozzák őket egyetlen híd képességei sem. A hídaggregátorok jellemzően fenntartják a hídintegrációkat, így a dappnak nem kell a hídintegráció technikai és üzemeltetési szempontjaival is foglalkoznia. - -Ennek ellenére a hídaggregátoroknak is megvannak a maguk korlátai. Bár több áthidalási lehetőséget kínálnak, jellemzően sokkal több híd található a piacon az aggregátor platformján kínáltakon kívül. Ráadásul a hidakhoz hasonlóan a hídaggregátorok is ki vannak téve az okosszerződésekkel és a technológiával kapcsolatos kockázatoknak (több okosszerződés = több kockázat). - -Ha egy dapp egy híd vagy egy aggregátor integrációját választja, az integráció mélységétől függően különböző lehetőségek állnak rendelkezésre. Ha például csak egy front-end integrációról van szó, amely javítja a felhasználó belépési élményét, akkor a dapp a widgetet (eszközt) integrálja. Ha azonban az integráció célja a mélyebb, láncközi stratégiák, például a letétbe helyezés, a hozamgyűjtés stb. felfedezése, akkor a dapp az SDK-t vagy az API-t integrálja. - -### Egy dapp telepítése több láncra {#deploying-a-dapp-on-multiple-chains} - -Egy dapp több láncra történő telepítéséhez a fejlesztők olyan fejlesztési platformokat használhatnak, mint az [Alchemy](https://www.alchemy.com/), [Hardhat](https://hardhat.org/), [Moralis](https://moralis.io/) stb. Ezek a platformok olyan összeállítható bővítményekkel rendelkeznek, amelyek lehetővé teszik a dappoknak a láncok közötti átjárhatóságot. A fejlesztők például használhatják a [hardhat-deploy plugin](https://github.com/wighawag/hardhat-deploy) által kínált determinisztikus telepítési proxyt. - -#### Példák: - -- [Hogyan építsünk láncok közötti dappokat](https://moralis.io/how-to-build-cross-chain-dapps/) -- [Láncközi NFT piactér létrehozása](https://youtu.be/WZWCzsB1xUE) -- [Moralis: Láncközi NFT dappok építése](https://www.youtube.com/watch?v=ehv70kE1QYo) - -### A szerződéses tevékenység nyomon követése a láncok között {#monitoring-contract-activity-across-chains} - -A láncok szerződéses tevékenységének nyomon követéséhez a fejlesztők algráfokat és fejlesztői platformokat, például a Tenderly-t használhatják az okosszerződések valós idejű megfigyelésére. Az ilyen platformok olyan eszközökkel is rendelkeznek, amelyek nagyobb adatfigyelési funkciókat kínálnak a láncközi tevékenységekhez, mint például a szerződések által kibocsátott [események ellenőrzése](https://docs.soliditylang.org/en/v0.8.14/contracts.html?highlight=events#events) stb. - -#### Eszközök - -- [The Graph](https://thegraph.com/en/) -- [Tenderly](https://tenderly.co/) - -## További olvasnivaló {#further-reading} - -- [Blokklánc-hidak](/bridges/) – ethereum.org -- [Blokklánc-hidak: Kriptohálózatok hálózatának kiépítése](https://medium.com/1kxnetwork/blockchain-bridges-5db6afac44f8) 2021. szeptember 8. – Dmitriy Berenzon -- [Az interoperabilitási trilemma](https://blog.connext.network/the-interoperability-trilemma-657c2cf69f17) 2021. október 1. – Arjun Bhuptani -- [Clusters: Hogyan alakítják a bizalomigénytől mentes és a minimális bizalomigényű hidak a többláncos képet?](https://blog.celestia.org/clusters/) 2021. október 4. – Mustafa Al-Bassam -- [LI.FI: A hidaknál a bizalomigény széles tartománya van jelen](https://blog.li.fi/li-fi-with-bridges-trust-is-a-spectrum-354cd5a1a6d8) 2022. április 28. – Arjun Chand - -Ezen kívül [James Prestwich](https://twitter.com/_prestwich) tanulságos előadásai segíthetnek a hidak mélyebb megértésében: - -- [Hidakat építsünk, ne fallal körülvett kerteket](https://youtu.be/ZQJWMiX4hT0) -- [A hidak részletes bemutatása](https://youtu.be/b0mC-ZqN8Oo) -- [Miért fontosak a hidak](https://youtu.be/c7cm2kd20j8) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md deleted file mode 100644 index c7b8f49436f..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/blockchain-data-storage-strategies/index.md +++ /dev/null @@ -1,118 +0,0 @@ ---- -title: Blokkláncadat-tárolási stratégiák -description: Többféle módon is lehet adatokat tárolni a blokklánc használatával. Ez a cikk összeveti a különféle stratégiákat, azok költségét és átváltásait, valamint a biztonságos használat feltételeit. -lang: hu ---- - -Többféle módon lehet információt tárolni vagy közvetlenül a blokkláncon, vagy olyan módon, hogy azt a blokklánc biztosítja: - -- EIP-4844 blobok -- Calldata -- Láncon kívül L1 mechanizmusokkal -- Szerződés „kódja” -- Események -- EVM-tárhely - -A módszer kiválasztása számos feltételtől függ: - -- Az információ forrása. A calldata mezőben lévő információ nem származhat közvetlenül a blokkláncról. -- Az információ célállomása. A calldata csak az általa kezdeményezett tranzakcióban érhető el. Az események egyáltalán nem érhetők el a láncon. -- Mekkora erőfeszítés elfogadható? A teljes csomópontot futtató számítógépek többet dolgoznak, mint egy könnyű kliens egy alkalmazásban, mely böngészőben fut. -- Szükséges, hogy minden csomópont könnyedén elérje az információt? -- Biztonsági követelmények. - -## Biztonsági követelmények {#security-requirements} - -Általánosságban az információs biztonság három jellemzővel bír: - -- _Titkosság_, vagyis a felhatalmazással nem rendelkező entitások nem olvashatják el az információt. Ez sok helyen fontos, de itt nem. _A blokkláncon nincsenek titkok_. A blokklánc működésének alapja, hogy bárki ellenőrzini tudja a státuszváltozásokat, ezért közvetlen módon nem használható titkok tárolására. Vannak módok, hogy bizalmas információkat tároljanak blokkláncon, de ezek valami láncon kívüli elemen alapulnak, hogy legalább egy kulcsot ott tároljanak. - -- _Integritás_, vagyis az információ korrekt, azt nem változtathatják meg olyanok, akik arra nincsenek felhatalmazva, vagy nem engedélyezett módokon (például [ERC-20 tokenek](https://eips.ethereum.org/EIPS/eip-20#events) küldése a „Transfer” esemény nélkül). A blokkláncon minden csomópont ellenőriz minden státuszváltozást, mely biztosítja az integritást. - -- _Elérhetőség_, vagyis az információ elérhető minden arra felhatalmazott entitásnak. A blokkláncon ezt úgy érik el, hogy az információ minden [teljes csomóponton](https://ethereum.org/developers/docs/nodes-and-clients#full-node) elérhető. - -Ezek a megoldások mind kiváló integritással bírnak, mert a hash-eket az L1-en rögzítik. De más elérhetőségi biztosítékaik vannak. - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértéséhez érdemes ismerni a [blokklánc alapjait](/developers/docs/intro-to-ethereum/). Ez az oldal azt is feltételezi, hogy az olvasó ismeri a [blokkokat](/developers/docs/blocks/), [tranzakciókat](/developers/docs/transactions/) és más kapcsolódó témákat. - -## EIP-4844 blobok {#eip-4844-blobs} - -[A Dencun végleges elágazás](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md) óta az Ethereum blokklánc tartalmazza az [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) változást, ami az Ethereumhoz adatblobokat illesztett, melyek rövid ideig, kb. [18 napig](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) elérhetőek. Ezeket a blobokat külön árazzák, a [végrehajtási gáztól](/developers/docs/gas) függetlenül, bár hasonló mechanizmussal. Ez egy olcsó megoldás átmeneti adatok tárolására. - -Az EIP-4844 blobok fő használati területe az összevont tranzakciók, hogy az általuk feldolgozott tranzakciók bekerüljenek az L1-re. Az [optimista rollupoknak](/developers/docs/scaling/optimistic-rollups) publikálni kell a tranzakciókat a blokkláncon. Ezeknek a tranzakcióknak elérhetőnek kell lenniük bárki számára a [megkérdőjelezési periódusban](https://docs.optimism.io/connect/resources/glossary#challenge-period), hogy a [validátorok](https://docs.optimism.io/connect/resources/glossary#validator) kijavíthassák a hibát, ha a rollup [szekvencer](https://docs.optimism.io/connect/resources/glossary#sequencer) rossz státuszgyökeret posztol. - -Ugyanakkor a megkérdőjelezési periódus után a státuszgyökér véglegessé válik, a tranzakciók további lényege az marad, hogy a lánc jelen státuszát újra lehessen alkotni. Ez a státusz elérhető a lánc csomópontjaiból is, melyhez kevesebb erőfeszítés szükséges. Így a tranzakciókról szóló információ megmarad néhány helyen, mint amilyenek a [blokkfelfedezők](/developers/docs/data-and-analytics/block-explorers), de nincs szükség arra a cenzúrának való ellenállásra, amit az Ethereum biztosít. - -A [zero-knowledge rollupok](/developers/docs/scaling/zk-rollups/#data-availability) is posztolják a tranzakciós adatokat, hogy más csomópontok replikálni tudják a státuszt és ellenőrizhessék az érvényességi bizonyítékokat, de ez is egy rövid távú igény. - -A jelen írás idején az EIP-4844-gyel a költség egy wei (10-18 ETH) bájtonként, ami elhanyagolható [a 21,000 végrehajtási gázhoz képest, amibe bármelyik tranzakció kerül, beleértve azt, ami blobokat is posztol](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index). Az EIP-4844 árakat a következő oldalon tekintheti meg: [blobscan.com](https://blobscan.com/blocks). - -A következőben láthatók azok a címek, melyekre néhány ismert rollup posztolja a blobokat. - -| Rollup | Postafiók címe | -| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | -| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://blobscan.com/address/0xFF00000000000000000000000000000000000010) | -| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://blobscan.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | -| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://blobscan.com/address/0xFF00000000000000000000000000000000008453) | - -## Calldata {#calldata} - -A calldata azokat a bájtokat jelenti, melyeket a tranzakció részeként küldenek. Ez a blokklánc állandó tárhelyének része a blokkban, amely az adott tranzakciót tartalmazza. - -Így lehet a legolcsóbban adatot tenni a blokkba állandó tárolásra. A bájtonkénti költsége 4 végrehajtási gáz (ha a bájt nulla) vagy 16 gáz (minden más értéknél). Ha az adat tömörítve van, ami egy bevett gyakorlat, akkor minden bájtérték ugyanolyan valószínű, így az átlagköltség kb. 15,95 gáz bájtonként. - -A jelen írás idején az ár 12 gwei/gáz és 2300 $/ETH, mely szerint a költség kb. 45 cent kilóbájtonként. Mivel az EIP-4844 előtt ez volt a legolcsóbb módszer, ezért a rollupok így tárolták a tranzakciós információkat, hogy azok elérhetők legyenek a [hiba kivizsgálásra](https://docs.optimism.io/stack/protocol/overview#fault-proofs), de nem kell azokat közvetlenül elérni a láncon. - -A következőben láthatóak azok a címek, melyekre néhány ismert rollup posztolja a tranzakciókat. - -| Rollup | Postafiók címe | -| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | -| [Optimism](https://www.optimism.io/) | [`0xFF00000000000000000000000000000000000010`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000000010) | -| [Arbitrum](https://arbitrum.io/) | [`0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6`](https://eth.blockscout.com/address/0x1c479675ad559DC151F6Ec7ed3FbF8ceE79582B6) | -| [Base](https://base.org/) | [`0xFF00000000000000000000000000000000008453`](https://eth.blockscout.com/address/0xFF00000000000000000000000000000000008453) | - -## Láncon kívül L1 mechanizmusokkal {#offchain-with-l1-mechs} - -A biztonsági megfontolások alapján talán elfogadható, hogy az információ máshol található, és egy mechanizmus biztosítja az elérhetőségét. Ez két feltétellel működhet: - -1. Az adat [hashét](https://en.wikipedia.org/wiki/Cryptographic_hash_function) a blokkláncra kell posztolni, melyet _input rögzítésnek_ neveznek. Ez lehet egy 32 bájtos szó, ami nem kerül sokba. Amíg az input rögzítése elérhető, az integritás biztosítva van, mert nem lesz más adat, aminek a hashe ugyanarra mutatna. Ha a helyes adat elérhető, akkor azt meg lehet találni. - -2. Szükség van egy mechanizmusra, mellyel elérhetővé válik az adat. Például a [Redstone](https://redstone.xyz/docs/what-is-redstone) esetében bármelyik csomópont indíthat elérhetőségi kihívást. Ha a szekvencer nem válaszol online a határidőig, az inputrögzítést elvetik, így az információt úgy veszik, mintha sosem lett volna beposztolva. - -Ez elfogadható az optimista rollup esetén, mert arra támaszkodunk, hogy legalább egy jóhiszemű ellenőrző van a státuszgyökérre. Egy ilyen jóhiszemű ellenőrző azt is biztosítja, hogy az adat létezik a blokk feldolgozásához, és egy elérhetőségi kihívást ad ki, ha az információ nem elérhető a láncon kívül. Ezt a fajta optimista rollupot nevezik [plazmának](/developers/docs/scaling/plasma/). - -## Szerződéskód {#contract-code} - -Az információ, melyet csak egyszer kell rögzíteni, sosem lesz felülírva, és a láncon belül elérhetőnek kell lennie, szerződéskódként is tárolható. Tehát készítünk egy „okosszerződést” az adattal, majd a [EXTCODECOPY](https://www.evm.codes/#3c?fork=shanghai) paranccsal kiolvassuk az információt. Ennek előnye az, hogy a kód másolása viszonylag olcsó. - -A memória kibővítésének költségén kívül az EXTCODECOPY 2600 gázba kerül, amikor a szerződéshez először férnek hozzá (amikor az „hideg”) és 100 gázba kerülnek a további másolatok, plusz 3 gázba 32 bájtnyi szavanként. A calldata-hoz képes, ami 15,95-be kerül bájtonként, ez kevesebb kb. 200 bájttól kezdve. [A memória kibővéítés költségének képlete](https://www.evm.codes/about#memoryexpansion) alapján, amíg nincs szükség több mint 4 MB memóriára, ez a bővítési költség kisebb, mint a calldata hozzáadása. - -Természetesen ez csak az adat _kiolvasása_. A szerződés létrehozásánek költsége kb. 32 000 gáz + 200 gáz/bájt. Ez csak akkor éri meg, ha az adott információt többször kell kiolvasni különféle tranzakciók során. - -A szerződéskód lehet értelmetlen, amíg nem kezdődik 0xEF-fel. Ha a szerződés kezdete 0xEF, akkor az egy [ethereum objektum formátum](https://notes.ethereum.org/@ipsilon/evm-object-format-overview), amelynek szigorúbb követelményeknek kell megfelelnie. - -## Események {#events} - -Az [eseményeket](https://docs.alchemy.com/docs/solidity-events) az okosszerződések adják ki, és a láncon kívüli szoftverek olvassák azokat. -Előnye az, hogy a láncon kívüli kód képes értelmezni az eseményeket. A költsége 375 [gáz](https://www.evm.codes/#a0?fork=cancun) plusz 8 gáz bájtonként. Ha 12 gwei/gáz és 2300 $/ETH, akkor ez 1 cent plusz 22 cent kilóbájtonként. - -## Tárhely {#storage} - -Az okosszerződések hozzáférnek az [állandó tárhelyhez](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory). Ez azonban nagyon drága. Egy 32 bájtos szó beírása egy üres helyre [belekerülhet akár 22 100 gázba is](https://www.evm.codes/#55?fork=cancun). Ha 12 gwei/gáz és 2300 $/ETH, akkor ez 61 cent minden írásra, vagy 19,5 $ kilóbájtonként. - -Ez a legdrágább tárolás az Ethereumon. - -## Összefoglaló {#summary} - -Ez a táblázat összefoglalja a különböző opciókat azok előnyeivel és hátrányaival együtt. - -| Tárolási típus | Adatforrás | Elérhetőségi garancia | Láncon belüli elérhetőség | További korlátozások | -| -------------------------------- | ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- | ---------------------------------------------------------- | -| EIP-4844 blobok | Láncon kívüli | Az Ethereum garantálja [kb. 18 napig](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) | Csak a hash elérhető | | -| Calldata | Láncon kívüli | Az Ethereum garantálja örökre (része a blokkláncnak) | Csak akkor elérhető, ha egy szerződésbe van írva, és abban az adott tranzakcióban | | -| Láncon kívül L1 mechanizmusokkal | Láncon kívüli | Legalább egy jóhiszemű ellenőrző garantálja a kihívási periódus alatt | Csak hash | A kihívási mechanizmus garantálja a kihívási időszak alatt | -| Szerződéskód | Láncon belüli vagy kívüli | Az Ethereum garantálja örökre (része a blokkláncnak) | Igen | Egy „véletlenszerű” címre van írva, nem kezdődhet 0xEF-fel | -| Események | Láncon belüli | Az Ethereum garantálja örökre (része a blokkláncnak) | Nem | | -| Tárhely | Láncon belüli | Az Ethereum garantálja örökre (része a blokkláncnak és a jelen státusznak addig, amíg felül nem írják) | Igen | | diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/index.md deleted file mode 100644 index bcf0000a064..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/data-availability/index.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Adatelérhetőség -description: Az adatok elérhetőségével kapcsolatos problémák és megoldások áttekintése az Ethereumban -lang: hu ---- - -„Ne bízz, ellenőrizd!” – ez az Ethereumban elterjedt alapelv. Az elképzelés lényege, hogy a csomópont önállóan ellenőrizheti a kapott információk helyességét azáltal, hogy végrehajtja a társaitól kapott blokkok összes tranzakcióját, hogy megbizonyosodjon arról, a javasolt változások megegyeznek a csomópont által kiszámítottakkal. Ez azt jelenti, hogy a csomópontoknak nem kell abban bízniuk, hogy a blokk küldői őszinték. Ez nem lehetséges, ha az adatok hiányoznak. - -**Az adatelérhetőség** arra utal, hogy a felhasználó mennyire bízhat abban, hogy a blokk ellenőrzéséhez szükséges adatok valóban rendelkezésre állnak a hálózat minden résztvevőjének. Az Ethereumon L1 rétegén lévő teljes csomópontok esetében ez viszonylag egyszerű; a teljes csomópont letölti az adott blokk összes adatának másolatát – az adatoknak _meg kell lennie_ ahhoz, hogy a letöltés lehetséges legyen. A hiányzó adatokkal rendelkező blokkot ahelyett, hogy hozzáadnák a blokklánchoz, inkább elvetnék. Ez a „láncon belüli adatelérhetőség”, és a monolitikus blokkláncok jellemzője. A teljes csomópontokat nem lehet érvénytelen tranzakciók elfogadására rávenni, mivel minden tranzakciót saját maguk töltenek le és hajtanak végre. A moduláris blokkláncok, a második blokkláncréteget (L2) képviselő összevont tranzakciók és a könnyű ügyfelek esetében azonban az adatok elérhetősége sokkal összetettebb, ami kifinomultabb ellenőrzési eljárásokat igényel. - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértéséhez érdemes ismerni a [blokklánc alapjait](/developers/docs/intro-to-ethereum/), különösen a [konszenzusmechanizmusokat](/developers/docs/consensus-mechanisms/). Ez az oldal azt is feltételezi, hogy az olvasó ismeri a [blokkok](/developers/docs/blocks/), [tranzakciók](/developers/docs/transactions/), [csomópontok](/developers/docs/nodes-and-clients/), [skálázási megoldások](/developers/docs/scaling/) és kapcsolódó témáit. - -## Az adatelérhetőség problémája {#the-data-availability-problem} - -Az adatok elérhetőségének problémája azt jelenti, hogy az egész hálózat számára bizonyítani kell, hogy a blokkláncba felvett tranzakciós adatok összegzett formája valóban érvényes tranzakciókat képvisel, mindezt anélkül, hogy minden csomópontnak le kellene töltenie az összes adatot. A teljes tranzakciós adat szükséges a blokkok független ellenőrzéséhez, de ha minden csomópontnak le kell töltenie az összeset, az akadályozza a skálázást. Az adatelérhetőség problémájára adott megoldások célja, hogy biztosítékot nyújtsanak arra, hogy a teljes tranzakciós adatot ellenőrzés céljából elérhetővé tették azoknak a résztvevőknek is, akik nem töltik le és tárolják az adatokat saját maguk. - -A [könnyű csomópontok](/developers/docs/nodes-and-clients/light-clients) és az [L2 összevont tranzakciók](/developers/docs/scaling) fontos hálózati résztvevők, akiknek erős adatelérhetőségi biztosítékokra van szükségük, de nem tudják letölteni és feldolgozni a tranzakciós adatokat. A könnyű csomópontokat épp az teszi könnyűvé, az összevont tranzakciókat pedig hatékony skálázási megoldássá, hogy nem kell tranzakciós adatokat letölteniük. - -Az adatelérhetőség kritikus szempont a jövőbeli [„státuszmentes”](/roadmap/statelessness) Ethereum-kliensek számára, amelyeknek nem kell letölteniük és tárolniuk a státuszadatokat a blokkok ellenőrzéséhez. A státuszmentes klienseknek továbbra is biztosnak kell lenniük abban, hogy az adatok rendelkezésre állnak _valahol_, és hogy azokat megfelelően feldolgozták. - -## Adatelérhetőségi megoldások {#data-availability-solutions} - -### Adatelérhetőség-mintázás (DAS) {#data-availability-sampling} - -Az adatelérhetőség-mintázás (DAS) egy módja annak, hogy a hálózat ellenőrizze, hogy az adatok rendelkezésre állnak-e anélkül, hogy túl nagy terhelést jelentene az egyes csomópontoknak. Minden csomópont (beleértve azokat is, amelyek nem helyeznek letétbe) letölti az összes adat véletlenszerűen kiválasztott, kis részhalmazát. A minták sikeres letöltése nagy biztonsággal megerősíti, hogy az összes adat rendelkezésre áll. Ez adattörlési kódolásra támaszkodik, amely egy adott adatkészletet redundáns információkkal bővít (azáltal, hogy egy _polinomiális_ függvényt illesztünk az adatokra, és ezt a polinomiálist további pontokon értékeljük ki). Ez lehetővé teszi, hogy szükség esetén a redundáns adatokból vissza lehessen állítani az eredeti adatokat. Az adatlétrehozás következménye, hogy ha az eredeti adatok közül _bármi_ hiányzik, akkor a kibővített adatok _felét_ sem kapjuk meg! Az egyes csomópontok által letöltött adatminták mennyiségét be lehet úgy állítani, hogy _nagy valószínűséggel_ hiányozzon legalább egy a kliensek által mintavételezett adatfragmentumok közül, _ha_ a csomópont az összes adatnak csak kevesebb mint a felét tárolja. - -A DAS annak biztosítására fog szolgálni, hogy az összevonttranzakció-üzemeltetők a [teljes Danksharding](/roadmap/danksharding/#what-is-danksharding) bevezetését követően rendelkezésre bocsássák tranzakciós adataikat. Az Ethereum-csomópontok véletlenszerű mintát vesznek a blobokban megadott tranzakciós adatokból a fent ismertetett redundanciaséma segítségével, hogy az összes adat meglétét biztosítsák. Ugyanezt a technikát lehetne alkalmazni arra is, hogy a blokkgyártók minden adatukat elérhetővé tegyék, így biztosítsák a könnyű kliensek működését. Hasonlóképpen, a [ javaslattevő-építő szétválasztása](/roadmap/pbs) esetén csak a blokképítőnek kell feldolgoznia egy teljes blokkot, a validátorok az adatok elérhetőségét mintavételezéssel ellenőriznék. - -### Adatelérhetőségi bizottságok {#data-availability-committees} - -Az adatelérhetőségi bizottságok (DAC) olyan megbízható felek, amelyek az adatok rendelkezésre állását biztosítják vagy tanúsítják. A DAC-k használhatók DAS helyett, [vagy azzal kombinálva](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS). A bizottságokkal járó biztonsági garanciák a konkrét felállítástól függenek. Az Ethereum a validátorok véletlenszerűen kiválasztott részhalmazait használja például a könnyű csomópontok adatelérhetőségének igazolására. - -A DAC-ket egyes validiumok is használják. A DAC egy megbízható csomópontokból álló csoport, amely offline tárolja az adatok másolatait. A DAC köteles az adatokat vita esetén rendelkezésre bocsátani. A DAC tagjai láncon belüli tanúsítványokat is közzétesznek annak igazolására, hogy az említett adatok valóban rendelkezésre állnak. Egyes validiumok a DAC-k helyébe a proof-of-stake (PoS) validátorrendszert léptetik. Itt bárki validátorrá válhat, és tárolhatja az adatokat a láncon kívül. Ehhez azonban „kötvényt” kell nyújtaniuk, amelyet egy okosszerződésben helyeznek letétbe. Rosszindulatú viselkedés esetén, például ha a validátor visszatartja az adatokat, a kötvény mértékében megbüntethető a szereplő. A proof-of-stake adatelérhetőségi bizottságok lényegesen biztonságosabbak, mint a hagyományosak, mivel közvetlen módon ösztönznek jóhiszemű viselkedésre. - -## Adatelérhetőség és a könnyű csomópontok {#data-availability-and-light-nodes} - -[A könnyű csomópontoknak](/developers/docs/nodes-and-clients/light-clients) a blokkadatok letöltése nélkül kell ellenőrizniük a kapott blokkfejlécek helyességét. Ennek a könnyű jellegnek az az ára, hogy nem tudják függetlenül ellenőrizni a blokkfejléceket úgy, ahogy egy teljes csomópont teszi azáltal, hogy helyben újrafuttatja a tranzakciókat. - -Az Ethereum a könnyű csomópontok egy _szinkronizálási bizottsághoz_ rendelt 512 validátor véletlenszerű halmazára vannak utalva. A szinkronizálási bizottság DAC-ként működik, amely kriptográfiai aláírással jelzi a könnyű klienseknek, hogy a fejlécben szereplő adatok helyesek. A Szinkronizálási bizottság minden nap frissül. Minden blokkfejléc figyelmezteti a könnyű csomópontokat, hogy melyik validátoroktól várják a _következő_ blokk aláírását, így nem lehet őket rászedni, hogy megbízzanak egy rosszindulatú csoportban, amely szinkronizálási bizottságnak adja ki magát. - -Mi történik akkor, ha egy támadó valahogyan egy hamis blokkfejlécet _továbbít_ a könnyű klienseknek, és meggyőzi őket arról, hogy azt egy becsületes szinkronizálási bizottság írta alá? Ebben az esetben a támadó érvénytelen tranzakciókat is betehet, és a könnyű kliens elfogadja azokat, mivel nem ellenőrzi független módon a blokkfejlécbe foglalt összes státuszváltozást. Ez ellen a könnyű kliens csalási bizonyítékokat használhat. - -Ezek a csalási bizonyítékok úgy működnek, hogy egy teljes csomópont, ha látja, hogy egy érvénytelen státuszváltozásról pletykálnak a hálózatban, gyorsan létrehozhat egy kis adatot, amely bizonyítja, hogy a javasolt státuszváltozás nem származhat egy adott tranzakcióhalmazból, és ezt az adatot továbbítja a társainak. A könnyű csomópontok felkaphatják ezeket a csalási bizonyítékokat, és felhasználhatják azokat a rossz blokkfejlécek elvetésére, így biztosítva, hogy ugyanabban a helyes láncban maradjanak, mint a teljes csomópontok. - -Ennek feltétele, hogy a teljes csomópontok hozzáférjenek a teljes tranzakciós adatokhoz. Egy olyan támadó, aki rossz blokkfejlécet küld szét, és a tranzakciós adatokat sem teszi elérhetővé, képes lenne megakadályozni, hogy a teljes csomópontok csalási bizonyítékokat generáljanak. A teljes csomópontok képesek lennének figyelmeztetést adni egy rossz blokkról, de nem tudnák a figyelmeztetésüket bizonyítékkal alátámasztani, mert az adatok nem álltak rendelkezésre, hogy a bizonyítékot legenerálják! - -Erre az adatelérhetőségi problémára a DAS a megoldás. A könnyű csomópontok a teljes státuszadat kis véletlenszerű darabjait töltik le, és a minták segítségével ellenőrzik, hogy a teljes adatkészlet rendelkezésre áll-e. Kiszámítható annak tényleges valószínűsége, hogy N véletlenszerű darab letöltése után tévesen feltételezzük a teljes adatelérhetőséget ([100 darab esetén az esély 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), azaz hihetetlenül valószínűtlen). - -Még ebben a forgatókönyvben is előfordulhat, hogy a véletlenszerű adatkéréseket végző kliensek előtt észrevétlen marad az, ha csak néhány bájtot tartanak vissza a támadások során. A törléskódolás ezt úgy oldja meg, hogy rekonstruálja a hiányzó kis adatdarabokat, amelyek felhasználhatók a javasolt státuszváltozások ellenőrzésére. Ezután a rekonstruált adatok felhasználásával csalási bizonyítékot lehetne készíteni, amely megakadályozza, hogy a könnyű csomópontok rossz fejléceket fogadjanak el. - -**Megjegyzés:** A DAS és a csalási bizonyítékok még nem kerültek bevezetésre a proof-of-stake Ethereum könnyű kliensek számára, de szerepelnek az útitervben, valószínűleg ZK-SNARK alapú bizonyítékok formájában. A mai könnyű kliensek a DAC egy formájára támaszkodnak: ellenőrzik a szinkronizálási bizottság személyazonosságát, majd megbíznak a kapott aláírt blokkfejlécekben. - -## Adatelérhetőség és L2 összevont tranzakciók {#data-availability-and-layer-2-rollups} - -Az [L2 skálázási megoldások](/layer-2/), mint például az [összevont tranzakciók](/glossary/#rollups), csökkentik a tranzakciós költségeket és növelik az átvitelt az Ethereumon a tranzakciók láncon kívüli feldolgozásával. Az összevont tranzakciók tömörített formában és kötegekben kerülnek az Ethereumra. A kötegek több ezer egyedi, láncon kívüli tranzakciót jelentenek egyetlen tranzakcióban az Ethereumon. Ez csökkenti a torlódást az alaprétegen és a felhasználók díjait. - -Az Ethereumba küldött „összefoglaló” tranzakciókban azonban csak akkor lehet megbízni, ha a javasolt státuszváltozás független módon ellenőrizhető és megerősíthető, hogy az az összes láncon kívüli tranzakció alkalmazásának eredménye. Ha az összevonttranzakció-üzemeltetők nem teszik elérhetővé a tranzakciós adatokat ehhez az ellenőrzéshez, akkor hibás adatokat küldhetnek az Ethereumba. - -Az [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/) tömörített tranzakciós adatokat küldenek az Ethereumba, és várnak egy bizonyos ideig (általában 7 napig), hogy független ellenőrök ellenőrizhessék az adatokat. Ha valaki problémát észlel, létrehozhat egy csalási bizonyítékot, és azt felhasználhatja az összevont tranzakciók megkérdőjelzésére. Ez azt eredményezi, hogy a lánc visszafordul és elveti az érvénytelen blokkot. Ez csak akkor lehetséges, ha az adatok rendelkezésre állnak. Jelenleg az optimista rollupok kétféle módon vihetnek tranzakciós adatokat az L1-re. Néhány rollup az adatokat `CALLDATA` formában állandóan elérhetővé teszi, amelyek folyamatosan elérhetők a láncon belül. Az EIP-4844 bevezetése lehetővé teszi, hogy az összevont tranzakciók a tranzakciós adataikat az olcsóbb blobtárolóba tegyék. Ez nem állandó tárhely. A független ellenőröknek kb. 18 napon belül le kell kérdezniük a blobokat, és jelezniük kell az esetleges problémáikat, mielőtt az adatok törlődnek az Ethereum (L1) rétegről. Az adatok elérhetőségét az Ethereum-protokoll csak erre a rövid, rögzített időablakra garantálja. Ezután az időpont után az Ethereum ökoszisztémában más szereplők felelőssége lesz. Bármely csomópont ellenőrizheti az adatelérhetőséget a DAS segítségével, vagyis a blobadatok kis, véletlenszerű mintáinak letöltésével. - -A [zero-knowledge (ZK) összevont tranzakcióknak](/developers/docs/scaling/zk-rollups) nem kell tranzakciós adatokat közzétenniük, mivel a [zero-knowledge érvényességi igazolások](/glossary/#zk-proof) garantálják a státuszváltozások helyességét. Az adatok elérhetősége azonban még mindig probléma, mivel nem lehet garantálni a ZK összevont tranzakció működését (és nem is tudunk vele interakcióba lépni), ha nem ismerjük a releváns státuszadatokat. A felhasználók például nem ismerhetik meg egyenlegüket, ha az üzemeltető visszatartja az összevont tranzakciókból következő státusz részleteit. Emellett nem tudnak státuszfrissítéseket végrehajtani az újonnan hozzáadott blokk információival. - -## Az adatelérhetőség és az adatvisszakereshetőség összehasonlítása {#data-availability-vs-data-retrievability} - -Az adatelérhetőség különbözik az adatok visszakereshetőségétől. Az adatelérhetőség annak biztosítása, hogy a teljes csomópontok képesek hozzáférni és ellenőrizni az adott blokkhoz kapcsolódó tranzakciók teljes halmazát. Ebből nem feltétlenül következik, hogy az adatok örökre hozzáférhetők. - -Az adatok visszakereshetősége a csomópontok azon képessége, hogy _historikus információkat_ tudnak visszakeresni a blokkláncból. Ezekre a múltbeli adatokra nincs szükség az új blokkok ellenőrzéséhez, csak a teljes csomópontok szinkronizálásához a Genesis blokkból vagy bizonyos múltbeli kérések kiszolgálásához. - -Az Ethereum alapprotokollja elsősorban az adatelérhetőséggel foglalkozik, nem a visszakereshetőséggel. Az adatok visszakereshetőségét harmadik felek által üzemeltetett archiváló csomópontok kis halmaza is biztosíthatja, vagy a hálózaton belül decentralizált fájltárolás, mint például a [Portal Network](https://www.ethportal.net/). - -## További olvasnivaló {#further-reading} - -- [Mi az az adatelérhetőség?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) -- [Mit jelent az adatelérhetőség?](https://coinmarketcap.com/alexandria/article/what-is-data-availability) -- [Az Ethereum-láncon kívüli adatelérhetőségi helyzete](https://blog.celestia.org/ethereum-off-chain-data-availability-landscape/) -- [Az adatelérhetőség ellenőrzésére vonatkozó útmutató](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) -- [A sharding + DAS javaslat magyarázata](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) -- [Megjegyzés az adatelérhetőségről és a törlési kódolásról](https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding#can-an-attacker-not-circumvent-this-scheme-by-releasing-a-full-unavailable-block-but-then-only-releasing-individual-bits-of-data-as-clients-query-for-them) -- [Adatelérhetőségi bizottságok.](https://medium.com/starkware/data-availability-e5564c416424) -- [Proof-of-stake típusú adatelérhetőségi bizottságok.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) -- [Megoldások az adatvisszakereshetőségi problémára](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) -- [Adatelérhetőség vagy hogyan tanulták meg az összevont tranzakciók, hogy ne aggódjanak és szeressék az Ethereumot](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md deleted file mode 100644 index 26b5b1372f3..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/dex-design-best-practice/index.md +++ /dev/null @@ -1,220 +0,0 @@ ---- -title: Decentralizált tőzsde (DEX) tervezésének bevált gyakorlatai -description: Útmutató a tokenátváltás UX/UI döntéseihez. -lang: hu ---- - -Az Uniswap 2018-as bevezetése óta százával jöttek létre decentralizált tőzsdék tucatnyi különböző láncon. -Számos új elemeket vezetett be vagy beletette a maga kis csavarját, de az interfész általában ugyanolyan maradt. - -Ennek egyik oka [Jakob törvénye](https://lawsofux.com/jakobs-law/): - -> A felhasználók a legtöbb időt ezeken az oldalakon töltik. Tehát azt preferálják, hogy minden oldal ugyanúgy működjön, ahogy azt már megismerték. - -A korai bevezetőknek, mint a Uniswap, Pancakeswap és Sushiswap köszönhetően a DeFifelhasználóknak van egy közös elképzelésük, hogyan néz ki egy DEX. -Emiatt meg tudunk fogalmazni bevált gyakorlatokat. Egyre több tervezési döntést kezelnek sztenderd módon a különböző oldalakon. A DEX-ek fejlődését úgy nézhetjük végig, mint egy nagy tesztelés, ami élőben folyik. A működő dolgok maradnak, a nem működőket kivetik. Van hely az egyéni megoldásokra, de bizonyos szabványoknak meg kell felelni. - -Ez a cikk összefoglalja: - -- mit tartalmazzon -- hogyan legyen a leginkább használható -- a személyreszabás főbb módjai - -A példák modelljei ehhez a cikkhez készültek, bár valódi projekteken alapulnak. - -A Figma eszközkészlet megtalálható a cikk alján – használja Ön is szabadon, és alkossa meg saját modelljét! - -## A DEX alapvető anatómiája {#basic-anatomy-of-a-dex} - -Az UI általában három elemet tartalmaz: - -1. Fő űrlap -2. Gomb -3. Részletek panel - -![Általános DEX UI a három fő elemmel](./1.png) - -## Variációk {#variations} - -Ez a közös téma, de ezeket az elemeket különféle módokon lehet elrendezni. A részletek panel lehet: - -- A gomb felett -- A gomb alatt -- Rejtve egy kinyíló panelben -- És/vagy egy előnézeti ablakban - -Megjegyzés: Az előnézeti ablak opcionális, de ha kevés adat van a fő felületen, akkor szükség lesz rá. - -## A fő űrlap struktúrája {#structure-of-the-main-form} - -Ez az a doboz, ahol kiválasztjuk, melyik tokent akarjuk átváltani. Egy beviteli mezőből és egy kis gombból áll, melyek egymás mellett találhatók. - -A DEX-ek általában további információkat közölnek a felette vagy alatta lévő sorban, de ezt másképp is be lehet állítani. - -![Beviteli sor a részletekkel felette és alatta](./2.png) - -## Variációk {#variations2} - -Két UI-variációt láthatunk itt; az egyiknek nincsenek szegélyei, nyitott dijáznt adva, a másiknál pedig a beviteli sora keretezve van, így fókusz kerül erre az elemre. - -![A fő űrlap két UI-variációja](./3.png) - -Ez az alapvető struktúra **négy fő információt** mutat a dizájban: egyet-egyet minden sarokban. Ha csak egy felső/alsó sor van, akkor két dolgot lehet megmutatni. - -A DeFi fejlődése mentén sokféle dolgot foglaltak bele ide. - -## Kulcsinformációk megmutatása {#key-info-to-include} - -- Egyenleg a tárcában -- Maximum gomb -- Fiat egyenérték -- Árhatás a „kapott” összeg esetén - -A korai megoldásoknál a fiat egyenérték sokszor hiányzott. Ha bármilyen web3-projekt készül, ez a fiat egyenérték elengedhetetlen. A felhasználók még helyi valutákban gondolkodnak, ezért szükséges, hogy ezzel a mentális modellel össze lehessen kapcsolni az információkat. - -A második mezőnél (ahol kiválasztja a tokent, amire váltani szeretne) az árhatást is meg lehet mutatni a fiat valuta összege mellett, kiszámolva a beadott és becsült visszakapott összeg különbségét. Ez egy igen hasznos részlet. - -A százalékos gombok (pl. 25%, 50%, 75%) hasznos funkciók, de több helyet igényelnek, több műveletet kell végrehajtani és több mentális terhet jelentenek. Ugyanez a helyzet a százalékos csúszkával. Ezek az UI döntések az adott márkán és a felhasználóin múlnak. - -További részleteket lehet megmutatni a fő űrlap alatt. Mivel ezek a profi felhasználóknak szólnak, érdemes: - -- minimálisra csökkenteni ezek mennyiségét, vagy -- elrejteni egy kinyíló panelben - -![A fő űrlap sarkaiban látható részletek](./4.png) - -## További információk megmutatása {#extra-info-to-include} - -- A tokenek ára -- Csúszás -- Minimum kapott összeg -- Várható eredmény -- Árhatás -- Gázköltség becslése -- Egyéb díjak -- Rendelés útvonala - -Ezek a részletek természetesen opcionálisak is lehetnek. - -A rendelés útvonala érdekes, de a legtöbb felhasználónak egyáltalán nem számít. - -Néhány másik részlet ugyanazt mondja el, csak másképpen. Például a minimum kapott összeg és a csúszás ugyanannak két oldala. Ha a csúszás 1%-ra van állítva, akkor a minimum várható összeg = várt eredmény-1%. Néhány UI várható összeget, minimum összeget és csúszást mutat… Ami hasznos, de talán túl sok. - -A legtöbb felhasználó általában az alapértelmezett csúszást használja. - -Az árhatás gyakran látszik zárójelekben a fiat egyenérték mellett, a „valamire” mezőben. Ez egy kiváló UX részlet, de ha itt megmutatjuk, akkor kell-e még alatta is megmutatni? Majd újra az előnézetben? - -Számos felhasználó (főleg ha kis összegeket vált) nem foglalkozik ezekkel a részletekkel; csak beírják a számot és megnyomják az átváltást. - -![Néhány részlet ugyanazt mutatja](./5.png) - -A részletek azon múlnak, hogy milyenek a felhasználók és milyen érzetet ad az alkalmazás. - -Ha a részletek panelban megmutatjuk a csúszási toleranciát, akkor ott szerkeszhetővé is kell tenni. Ez egy jó példa a „gyorsításra”; egy elegáns UX trükk, amely anélkül gyorsítja meg a flowt a tapasztalt felhasználók számára, hogy az az alkalmazás általános használatát érintené. - -![A csúszást állítani lehet a részletek panelben](./6.png) - -Érdemes végiggondolni a részleteket, és nem csak egy oldalon, hanem a teljes menetben: -A fő űrlapon beírjuk a számokat → A részleteket megmutatjuk → Rákattintunk az előnézetre (ha van). -A részletek panel mindig látható, vagy rá kell kattintani ahhoz, hogy kinyíljon? -Az előnézettel megtörjük a használat folytonosságát? Ez ráveszi a felhasználót, hogy lassítson és átgondolja a szándékát, ami hasznos lehet. De szükséges-e nekik még egyszer minden részlet? Ezen a ponton mi a hasznos számukra? - -## Tervezési opciók {#design-options} - -Ahogy említettük, ennek nagy része a személyes stíluson múlik -Ki a felhasználó? -Mi a márka? -Profi interfészt akar minden részlettel, vagy inkább minimalista elrendezést? -Még ha a profi felhasználóknak is készül, és minden információ elérhető, érdemes megfontolni meg Alan Cooper szavait: - -> Mindegy, milyen szép és menő az interfész, a kevesebb néha több. - -### Struktúra {#structure} - -- tokenek a bal vagy a jobb oldalon -- 2 vagy 3 sor -- részletek a gomb felett vagy alatt -- a részletek kinyithatók, minimalizáltak vagy nem jelennek meg - -### Komponensstílus {#component-style} - -- üres -- körvonalas -- kitöltött - -Tisztán UX szempontból az UI stílusok kevesebbet számítanak, mint gondolnánk. A vizuális divatok jönnek-mennek, és a legtöbb preferencia szubjektív. - -Ahhoz, hogy erre ráérezzen, és átlássa a különféle beállításokat, nézzen meg néhány példát és kísérletezzen maga. - -Az alábbi Figma eszközkészlet tartalmaz üres, körvonalas és kitöltött komponenseket is. - -Tekintse meg az alábbi példákat, hogyan lehet ezeket összeilleszteni különféle módokon: - -![3 sor kitöltött stílussal](./7.png) - -![3 sor körvonalas sílussal](./8.png) - -![2 sor üres stílussal](./9.png) - -![3 sor körvonalasan egy részletek panellel együtt](./10.png) - -![3 sor az input sorral körvonalasan](./11.png) - -![2 sor kitöltött stílussal](./12.png) - -## De melyik oldalra kerüljön a token? {#but-which-side-should-the-token-go-on} - -A lényeg, hogy valószínűleg nem okoz nagy különbséget a használatban. Néhány dologra érdemes figyelni, ami miatt egyik vagy másik lesz a jó megoldás. - -Érdekes megfigyelni, ahogy a divat változik az idővel. Uniswap eredetileg balra tette a tokent, de aztán átkerült jobbra. Sushiswap is megváltoztatta ugyanígy egy frissítésnél. A legtöbb protokoll követte a példát. - -A pénzügyi konvenciók szerint a valuta szimbóluma a szám elé kerül, például $50, €50, £50, de _szóban_ 50 dollár, 50 euró, 50 font hangzik el. - -Az átlagos felhasználónak – főleg aki balról jobbra, fentről lefelé olvas – a token a jobb oldalon természetesebben hat. - -![UI, ahol a token a bal oldalon van](./13.png) - -Ha a token a bal oldalon és a számok a jobb oldalon vannak, akkor kellemesen szimmetrikus az elhelyezés, de van ennek hátránya is. - -A közelség törvénye azt mondja, hogy a közeli dolgok összefüggőbbnek tűnnek. Eszerint a kapcsolódó tételeket közel akarjuk tenni egymáshoz. A tokenegyenleg közvetlenül kapcsolódik a tokenhez, és megváltozik, amikor új tokent választunk. Ezért a tokenegyenleg kerülhetne a token kiválasztógombja mellé. Ha a token alá tennénk, akkor megtörné a szimmetriát. - -Végülis mindkét megoldásnak vannak előnyei és hátrányai, de a trend szerint a token a jobb oldalra kerül. - -# Gombműködés {#button-behavior} - -Ne legyen külön gomb a jóváhagyásra. Ne is kelljen ehhez külön kattintani. A felhasználó átváltást akar, ezért legyen a gombon átváltás felirat és az első lépés maga a jóváhagyás. Az ablak mutathatja a haladást lépésekkel, vagy egyszerűen egy „2-ből 1 tranzakció jóváhagyása” figyelmeztetéssel. - -![UI, ahol külön gomb van a jóváhagyásra és az átváltásra](./14.png) - -![UI, ahol egy jóváhagyás gomb van](./15.png) - -## Gomb mint helyi segítség {#button-as-contextual-help} - -A gomb figyelmeztetésként is működhet! - -Ezt nem használják annyira web3-on kívül, de itt elterjedtté vált. Így kevesebb helyet foglal, és fenntartja a figyelmet. - -Ha a fő tevékenység, azaz az átváltás nem érhető el egy hiba miatt, akkor annak okát ki lehet írni a gombra, például - -- hálózatváltás -- tárca csatlakoztatása -- különféle hibák - -A gombot **hozzá is lehet kapcsolni az elvégzendő cselekvéshez**. Például, ha a felhasználó rossz hálózaton van, a gombon megjelenik, hogy „váltás Ethereumra”, és ha rákattint, akkor átváltja a hálózatot. Ez jelentősen meggyorsítja a használatot. - -![A fő akciók a fő CTA-ról indulnak](./16.png) - -![Hibaüzenet a fő CTA-n](./17.png) - -## Építse meg sajátját ezzel a figma fájllal {#build-your-own-with-this-figma-file} - -Számos protokoll kemény munkájának köszönhető, hogy a DEX dizájnja sokat fejlődött. Tudjuk, hogy a felhasználónak milyen információra van szüksége, hogyan mutassuk azt meg, és hogyan legyen könnyed a használat menete. -Remélhetőleg ez a cikk segített áttekinteni az UX elveket. - -Ha kísérletezne, akkor használja hozzá a Figma eszközkészletet. Egyszerű, mégis rugalmas ahhoz, hogy kedve szerint építse meg az alapstruktúrát. - -[Figma eszközkészlet](https://www.figma.com/community/file/1393606680816807382/dex-wireframes-kit) - -A DeFi továbbfejlődik, és mindig van lehetőség az újításra. - -Sok szerencsét! diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md deleted file mode 100644 index a1f21c12236..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/heuristics-for-web3/index.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -title: 7 heurisztika a web3-interfész dizájnjához -description: A web3 felhasználhatóságának fejlesztési elvei -lang: hu ---- - -A használhatósági heurisztikák amolyan ökölszabályok, melyekkel felmérhető egy oldal használhatósága. -Az itt felsorolt 7 heurisztikát kifejezetten web3-ra alakították ki és érdemes együtt használni Jakob Nielsen [10 általános elv az interakciós dizájnhoz](https://www.nngroup.com/articles/ten-usability-heuristics/) iránymutatásával. - -## Hét használati heurisztika web3-ra {#seven-usability-heuristics-for-web3} - -1. A visszajelzés a cselekvést követi -2. Biztonság és megbízhatóság -3. A legfontosabb információ egyértelmű legyen -4. Érthető szóhasználat -5. A műveletek a lehető legrövidebbek legyenek -6. A hálózati kapcsolódás látható és rugalmas legyen -7. Az alkalmazásból legyen irányítható, nem a tárcából - -## Definíciók és példák {#definitions-and-examples} - -### 1. A visszajelzés a cselekvést követi {#feedback-follows-action} - -**Egyértelmű legyen, amikor történt vagy éppen történik valami.** - -A felhasználók a következő lépéseiket az előzők eredménye alapján teszik meg. Ezért lényeges, hogy mindig ismerjék a rendszer jelen állapotát. Ez még fontosabb a web3-ban, mert a tranzakcióknak sokszor kevés idő kell, hogy véglegesedjenek a blokkláncban. Ha nincs visszajelzés, akkor elbizonytalanodnak, hogy megtörtént-e. - -**Tippek:** - -- Tájékoztassa a felhasználót üzenetek és figyelmeztetések révén. -- Egyértelműen közölje a várakozási időt. -- Ha egy akció néhány másodpercnél hosszabb ideig tart, biztosítson a felhasználónak egy számlálót vagy animációt, hogy tudja, éppen folyamatban van a kérése. -- Ha több lépésből áll a folyamat, akkor mutassa az összeset. - -**Például:** -Ha megmutatja a folyamat összes lépését, akkor a felhasználó tudja, hogy hol tart. A megfelelő ikonok segítenek megérteni, hogy milyen állapotban vannak a műveleteik. - -![Tájékoztassa a felhasználót minden lépésről, amikor tokeneket vált](./Image1.png) - -### 2. A biztonság és a megbízhatóság legyen beégetve itt: {#security-and-trust-are-backed-in} - -A biztonság alapvető prioritás, és ezt a felhasználóval is tudatni kell. -Az emberek számára fontosak az adataik. A biztonság mindig a legfontosabb a felhasználónak, ezért a dizájn minden szintjén figyelembe kell venni. Mindig el kell nyerni a felhasználók bizalmát, ami különféle alkalmazásoknál mást jelenthet. Ne utólag gondoljon rá, hanem tervezze bele tudatosan. A teljes felhasználói élmény során bizalmat kell kiépíteni, beleértve a közösségi csatornákat, a dokumentációt és a végső felhasználói felületet is. A decentralizáció szintje, a pénzeszközök többaláírásos kezelése és az, hogy a csapatot lenyomozták-e a nyilvános fórumokon, mind befolyásolják a felhasználók bizalmát. - -**Tippek:** - -- Mutassa meg büszkén az auditokat -- Tegyen szert több auditra -- Reklámozza a biztonsági jellemzőket, melyeket kialakított -- Jelezze a felmerülő kockázatokat, beleértve a mögöttes integrációkat is -- Kommunikálja a stratégiák összetett voltát -- Vegye figyelembe a nem felhasználói felülettel kapcsolatos gondokat, melyek befolyásolják a felhasználók biztonságérzetét - -**Példa:** -Tüntesse fel az auditot a láblécben, feltűnő méretben. - -![A honlap láblécében feltüntetett auditok](./Image2.png) - -### 3. A legfontosabb információk legyenek egyértelműk {#the-most-important-info-is-obvious} - -A bonyolult rendszerek esetében csak a legfontosabb adatokat mutassa. Határozza meg, hogy mi a legfontosabb, és azt vegye előre a bemutatásban. -A túl sok információ túlterheli a felhasználókat, akik általában egy információdarabot vesznek figyelembe a döntésnél. A DeFi esetében ez az információ valószínűleg a THM a jövedelmet hozó alkalmazásoknál, illetve a hitelfedezet (LTV) a kölcsönadó alkalmazásoknál. - -**Tippek:** - -- A felhasználókat megvizsgálva kiderül, mi a legfontosabb mérőszám -- Legyen a kulcsinformáció nagy, a többi pedig kicsi és diszkrét -- Az emberek nem olvassák el, hanem átfutják a dolgokat, ezért legyen a dizájn jól átfutható - -**Példa:** A nagy tokeneket színesben könnyebb megtalálni az átfutás közben. A THM legyen nagy és hangsúlyos színű. - -![Könnyű megtalálni a tokent és a THM-et](./Image3.png) - -### 4. Érthető szóhasználat {#clear-terminology} - -A szóhasználat legyen érthető és helyénvaló. -A technikai zsargon nagy akadály lehet, mert egy teljesen új gondolkodási módot igényel. A felhasználók ekkor nem tudják hozzákapcsolni a dizájnt az általuk már ismert szavakhoz, mondatokhoz és koncepciókhoz. Minden zavaró és ismeretlen, és a tanulási görbe nagyon meredek, mire eljutnak addig, hogy használni próbálják. A felhasználó azért fordul a DeFi-hoz, hogy megtakarítson egy kis pénzt, és azt látja, hogy: bányászat, gazdálkodás, letétbe helyezés, kibocsátás, vesztegetés, megőrzés, széfek, veTokenek, megszerzés, korszakok, decentralizált algoritmusok, protokoll által birtokolt likviditás… -Használjon egyszerű kifejezéseket, amelyeket bárki megérthet. Ne találjon ki teljesen új szavakat az adott projekthez. - -**Tippek:** - -- Használjon egyszerű és konzisztens terminológiát -- Használjon ismert szavakat, amennyire lehetséges -- Ne találjon ki új kifejezéseket -- Kövesse a koncenciókat, ahogy megjelennek -- Tanítsa a felhasználókat, amennyire csak lehetséges - -**Példa:** -„Az Ön jutalma” egy széles körben érthető, semleges kifejezés; nem egy új szó az adott projekthez. Ha a jutalmat USD-ben mutatja, akkor az kapcsolódni tud a meglévő gondolkodási sémákhoz, még akkor is, ha a jutalom másik tokenben van. - -![Token jutalmak, amerikai dollárban megmutatva](./Image4.png) - -### 5. A műveleteknek a lehető legrövidebbnek kell lenniük {#actions-are-as-short-as-possible} - -Gyorsítsa fel a felhasználó interakcióját azzal, hogy csoportosítja az műveleteket. -Ezt az okosszerződés szintjén, vagy akár a felhasználói felület szintjén is meg lehet tenni. A felhasználónak ne kelljen a rendszer egyik részéről a másikra navigálnia – vagy akár elhagynia azt –, hogy teljesítsen egy átlagos műveletet. - -**Tippek:** - -- Kombinálja a jóváhagyást más műveletekkel, ha lehet -- Csoportosítsa az aláírásokat közel egymáshoz - -**Példa:** A likviditás hozzáadása és a letétbe helyezés két olyan művelet, melyet összevonva felgyorsul a használat és egyszerre spórol időt és gázt a felhasználónak. - -![Átváltás, ahol kombinálni lehet a letéti és staking művelet](./Image5.png) - -### 6. A hálózati kapcsolódás látható és rugalmas {#network-connections-are-visible-and-flexible} - -Tájékoztassa a felhasználót, hogy milyen hálózathoz kapcsolódik, és adjon egyértelmű lehetősége ennek módosítására. -Ez rendkívül fontos a több láncon működő alkalmazásoknál. Az alkalmazás főbb funkciói akkor is legyenek láthatók, ha a felhasználó nem kapcsolódik hálózathoz, vagy olyanhoz kapcsolódik, ami nem támogatott. - -**Tippek:** - -- Mutasson meg az alkalmazásból annyit, amennyit csak lehet, miközben a felhasználó nincs hálózathoz kapcsolódva -- Mutassa meg, hogy a felhasználó melyik hálózathoz kapcsolódik -- Ne hagyja, hogy a felhasználónak a tárcához kelljen navigálnia a hálózat átváltásához -- Ha az alkalmazáshoz hálózatot kell váltani, akkor az tegye az alkalmazásból -- Ha az alkalmazás több piacot vagy helyet tartalmaz számos hálózattal, akkor legyen egyértelmű a felhasználónak, hogy éppen mit lát - -**Példa:** Mutassa meg a felhasználónak, hogy melyik hálózathoz kapcsolódik, és hogy ezt módosítani tudja az alkalmazásban. - -![Legördülő gomb mutatja a hálózati kapcsolatot](./Image6.png) - -### 7. Az alkalmazásból irányítható, nem a tárcából {#control-from-the-app-not-the-wallet} - -A felhasználói felület olyan legyen, hogy a felhasználó mindent tudjon és mindent irányíthasson, amire szükség van. -Web3-ban vannak bizonyos műveletek, amelyek a felhasználói felülethez, mások a tárcához tartoznak. Általában a felhasználói felület az, ahol a műveletek elindul, és a tárcában erősítik meg azt. A felhasználó összezavarodik, ha ez a kettő nincs jól összehangolva. - -**Tippek:** - -- Közölje a rendszer státuszát a felhasználói felületen visszajelzés formájában -- Mentse az előzményeket -- Legyen összekapcsolva a blokkfelfedezőkkel a korábbi tranzakciók miatt -- Legyen egyszerű a hálózat átváltása. - -**Példa:** Egy konténer mutatja a felhasználónak, hogy milyen tokenek vannak a tárcájában, a fő CTA pedig lehetőséget ad a hálózat átváltására. - -![Fő CTA feldobja a hálózat átváltásának lehetőségét](./Image7.png) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/index.md deleted file mode 100644 index 737132fbe6f..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/design-and-ux/index.md +++ /dev/null @@ -1,92 +0,0 @@ ---- -title: Dizájn és UX (felhasználói élmény) a web3-ban -description: Bevezetés az UX-tervezésbe és kutatásba a web3-ban és az Ethereumon -lang: hu ---- - -Ön még csak most ismerkedik az Ethereumon való tervezéssel? Akkor a megfelelő helyen jár. Az Ethereum-közösség olyan forrásokkal rendelkezik, amelyek segítenek elindulni a web3-tervezésben és -kutatásban. Megismerheti az alapvető fogalmakat, amelyek eltérhetnek más, ismert alkalmazások tervezésétől. - -Először a web3 alaposabb megértésére van szüksége? Tekintse meg a [**Tanulási központ**](/learn/) oldalt. - -## Kezdje a felhasználói kutatással {#start-with-user-research} - -A hatékony tervezés túlmutat a vizuálisan vonzó felhasználói felületek létrehozásán. Magában foglalja a felhasználó igényeinek, céljainak és mozgatórugóinak mélyreható megértését. Ezért erősen ajánljuk, hogy minden tervező alkalmazzon egy tervezési folyamatot, mint például a [**dupla gyémánt folyamat**](https://en.wikipedia.org/wiki/Double_Diamond_(design_process_model)), hogy biztosítsa, munkája tudatos és szándékos. - -- [A web3-nak több UX kutatóra és tervezőre van szüksége](https://blog.akasha.org/akasha-conversations-9-web3-needs-more-ux-researchers-and-designers) – A jelenlegi tervezési érettség áttekintése -- [Egyszerű útmutató az UX kutatáshoz a web3-ban](https://uxplanet.org/a-complete-guide-to-ux-research-for-web-3-0-products-d6bead20ebb1) – Egyszerű útmutató a kutatáshoz -- [Hogyan közelítsük meg az UX-döntéseket a web3-ban](https://archive.devcon.org/archive/watch/6/data-empathy-how-to-approach-ux-decisions-in-web3/) – A kvantitatív és kvalitatív kutatás rövid áttekintése, és a kettő közötti különbségek (videó, 6 perc) -- [UX-kutatónak lenni a web3-ban](https://medium.com/@georgia.rakusen/what-its-like-being-a-user-researcher-in-web3-6a4bcc096849) – Személyes vélemény arról, milyen UX-kutatónak lenni a web3-ban - -## Kutatási tanulmányok a web3-ban {#research-in-web3} - -Ez a web3-ban végzett felhasználói kutatások válogatott listája, amely segíthet a tervezési és termékdöntésekben, vagy inspirációként szolgálhat saját tanulmányok készítéséhez. - -| Fókuszterület | Név | -|:----------------------------------------------------------------- |:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Bevezetés a kriptóba | [The WalletConnect Pulse 2024: Crypto fogyasztói hangulat & használat](https://walletconnect.com/pulse-2024-crypto-consumer-report) | -| Bevezetés a kriptóba | [CRADL: UX a kriptovaluták világában](https://docs.google.com/presentation/d/1s2OPSH5sMJzxRYaJSSRTe8W2iIoZx0PseIV-WeZWD1s/edit?usp=sharing) | -| Bevezetés a kriptóba | [CRADL: Bevezetés a kriptovaluták világába](https://docs.google.com/presentation/d/1R9nFuzA-R6SxaGCKhoMbE4Vxe0JxQSTiHXind3LVq_w/edit?usp=sharing) | -| Bevezetés a kriptóba | [Bitcoin UX riport](https://github.com/patestevao/BitcoinUX-report/blob/master/report.md) | -| Bevezetés a kriptóba | [ConSensys: A web3 helyzete világszerte 2023-ban](https://consensys.io/insight-report/web3-and-crypto-global-survey-2023) | -| Bevezetés a kriptóba | [NEAR: Az elfogadás felé vezető út felgyorsítása](https://drive.google.com/file/d/1VuaQP4QSaQxR5ddQKTMGI0b0rWdP7uGn/view) | -| Letétbe helyezés | [OpenUX: Rocket Pool csomópont-operátor UX](https://storage.googleapis.com/rocketpool/RocketPool-NodeOperator-UX-Report-Jan-2024.pdf) | -| Letétbe helyezés | [Staking: Főbb trendek, tanulságok és előrejelzések – Eth Staker](https://lookerstudio.google.com/u/0/reporting/cafcee00-e1af-4148-bae8-442a88ac75fa/page/p_ja2srdhh2c?s=hmbTWDh9hJo) | -| Letétbe helyezés | [Többalkalmazásos letétbe helyezés](https://github.com/threshold-network/UX-User-Research/blob/main/Multi-App%20Staking%20(MAS)/iterative-user-study/MAS%20Iterative%20User%20Study.pdf) | -| DAO | [2022-es DAO-kutatás frissítése: Mire van szüksége a DAO-építőknek?](https://blog.aragon.org/2022-dao-research-update/) | -| DeFi | [A DeFi helyzete 2024-ben](https://stateofdefi.org/) (folyamatos felmérés) | -| DeFi | [Fedezeti alapok](https://github.com/threshold-network/UX-User-Research/tree/main/Keep%20Coverage%20Pool) | -| DeFi | [ConSensys: DeFi felhasználói kutatási riport 2022-ben](https://cdn2.hubspot.net/hubfs/4795067/ConsenSys%20Codefi-Defi%20User%20ResearchReport.pdf) | -| Metaverzum | [Metaverse: Felhasználói kutatási riport](https://www.politico.com/f/?id=00000187-7685-d820-a7e7-7e85d1420000) | -| Metaverzum | [Szafarira megyünk: Felhasználók kutatása a Metaverzumban](https://archive.devcon.org/archive/watch/6/going-on-safari-researching-users-in-the-metaverse/?tab=YouTube) (videó, 27 perc) | -| Az Ethereum.org UX-statisztikái | [Használhatósági és felhasználói elégedettségi felmérés – Ethereum.org](https://lookerstudio.google.com/reporting/0a189a7c-a890-40db-a5c6-009db52c81c9) | - -## Web3-tervezés {#design-for-web3} - -- [Web3 UX tervezési kézikönyv](https://web3ux.design/) - Gyakorlati útmutató a web3 alkalmazások tervezéséhez -- [Web3-tervezési alapelvek](https://medium.com/@lyricalpolymath/web3-design-principles-f21db2f240c1) – UX-szabályok keretrendszere a blokkláncalapú dappok számára -- [Blokklánc dizájnelvek](https://medium.com/design-ibm/blockchain-design-principles-599c5c067b6e) – Az IBM-blokklánc tervezői csapatának tanulságai -- [Web3 tervezési minták](https://www.web3designpatterns.io/) – Valódi web3 termékekből származó tervezési minták gyűjteménye -- [W3design.io](https://w3design.io/) – Az ökoszisztéma különböző projektjeinek UI-folyamataiból összeállított könyvtár -- [Neueux.com](https://neueux.com/apps) – UI-könyvtár felhasználói folyamatok változatos szűrési lehetőségekkel -- [A web3 használhatóságának válsága: Amit tudnia kell!](https://www.youtube.com/watch?v=oBSXT_6YDzg) – Panelbeszélgetés a fejlesztőközpontú projektépítés buktatóiról (videó, 34 perc) - -## Első lépések {#getting-started} - -- [Heurisztika a web3-hoz](/developers/docs/design-and-ux/heuristics-for-web3/) - 7 heurisztika a web3-interfész dizájnjához -- [DEX dizájn bevált gyakorlatok](/developers/docs/design-and-ux/dex-design-best-practice/) - Útmutató a decentralizált tőzsdék tervezéséhez - -## Web3-tervezési esettanulmányok {#design-case-studies} - -- [Deep Work Studio](https://deepwork.studio/case-studies/) -- [A Crypto UX kézikönyve](https://www.cryptouxhandbook.com/) -- [NFT eladás az OpenSea platformon](https://builtformars.com/case-studies/opensea) -- [Wallet UX-kibontás a tárcák megváltoztatásáról](https://www.youtube.com/watch?v=oTpuxYj8JWI&ab_channel=ETHDenver) (videó, 20 perc) - -## Tervezési jutalmak {#bounties} - -- [Dework](https://app.dework.xyz/bounties) -- [Buildbox hackathons](https://app.buidlbox.io/) -- [ETHGlobal hackathonok](https://ethglobal.com/) - -## Tervezési DAO-k és közösségek {#design-daos-and-communities} - -Vegyen részt a szakmai közösség által irányított szervezetekben, vagy csatlakozzon tervezési csoportokhoz, hogy megvitassa a tervezéssel és kutatással kapcsolatos témákat és trendeket más tagokkal. - -- [Vectordao.com](https://vectordao.com/) -- [Deepwork.studio](https://www.deepwork.studio/) -- [Designer-dao.xyz](https://www.designer-dao.xyz/) -- [We3.co](https://we3.co/) -- [Openux.xyz](https://openux.xyz/) -- [Nyílt forráskódú Web3Design](https://www.web3designers.org/) - -## Tervezési rendszerek {#design-systems} - -- [Optimism Design](https://www.figma.com/@optimism) (Figma) -- [Ethereum.org tervezési rendszer](https://www.figma.com/@ethdotorg) (Figma) -- [Finity – a Polygon tervezési rendszere](https://www.figma.com/community/file/1073921725197233598/finity-design-system) (Figma) -- [Kleros tervezési rendszer](https://www.figma.com/community/file/999852250110186964/kleros-design-system) (Figma) -- [Safe Design System](https://www.figma.com/community/file/1337417127407098506/safe-design-system) (Figma) -- [ENS tervezési rendszer](https://thorin.ens.domains/) -- [Mirror tervezési rendszer](https://degen-xyz.vercel.app/) - -**Az oldalon szereplő cikkek és projektek nem minősülnek az Ethereum által minősített termékeknek**, az itt megjelenő adataik tájékoztatási célt szolgálnak. A hivatkozásokat a [listázási szabályzatunkban](/contributing/design/adding-design-resources) szereplő kritériumok alapján adjuk hozzá ehhez az oldalhoz. Ha szeretne egy új projektet/cikket hozzáadni, szerkessze ezt az oldalt a [GitHubon](https://github.com/ethereum/ethereum-org-website/blob/dev/public/content/developers/docs/design-and-ux/index.md). diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/mev/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/mev/index.md deleted file mode 100644 index 44c822f2089..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/mev/index.md +++ /dev/null @@ -1,221 +0,0 @@ ---- -title: Maximálisan kinyerhető érték (MEV) -description: Bevezetés a maximálisan kinyerhető érték (MEV) lényegébe -lang: hu ---- - -A maximális kinyerhető érték (MEV) arra utal, hogy a blokk létrehozásából kapható sztenderd blokkjutalmon és a gázdíjakon felül plusz értéket lehet szerezni a tranzakciók blokkba helyezésével, kizárásával és a sorrendek megváltoztatásával. - -## Maximálisan kinyerhető érték (MEV) {#maximal-extractable-value} - -A maximálisan kinyerhető értéket először a [proof-of-work (munkaigazolás)](/developers/docs/consensus-mechanisms/pow/) kontextusában alkalmazták, és ezért „bányászattal kivonható értékként” emlegették. Mivel a proof-of-work esetében a bányászok ellenőrzik a tranzakciók felvételét, kizárását és sorrendjét. [A Beolvadás](/roadmap/merge) során áttértek a proof-of-stake (letéti igazolás) mechanizmusára, és ezeket a szerepeket a validátorok látják el, a bányászat pedig nem része az Ethereum protokolljának. Értékkinyerési módszerek azonban továbbra is léteznek, ezért jelenleg a „maximálisan kinyerhető érték” kifejezést használjuk. - -## Előfeltételek {#prerequisites} - -A téma könnyebb megértése érdekében érdemes megismeri a [tranzakciókkal](/developers/docs/transactions/), [blokkokkal](/developers/docs/blocks/), [proof-of-stake-kel](/developers/docs/consensus-mechanisms/pos) és [gázzal](/developers/docs/gas/) foglalkozó témákat. Emellett a [dappok](/dapps/) és a [DeFi](/defi/) ismerete szintén hasznos. - -## MEV kivonása {#mev-extraction} - -Elméletileg a MEV teljes egészében a validátoroknál keletkezik, mivel ők tudják garantálni a profitábilis MEV-lehetőségek végrehajtását. A gyakorlatban a MEV nagy részét független hálózati résztvevők, úgynevezett „keresők” nyerik ki. A keresők komplex algoritmusokat futtatnak a blokkláncadatokon, hogy felismerjék a profitábilis MEV-lehetőségeket, és botok révén automatikusan beküldik ezeket a nyereséges tranzakciókat a hálózatba. - -A validátorok megkapják a MEV-összeg egy részét, mivel a keresők hajlandók magas gázdíjat fizetni (a validátornak) azért, hogy a nyereséges tranzakcióik bekerülhessenek egy adott blokkba. Feltételezve, hogy a keresők gazdaságilag racionálisak, a kereső által fizetett gázdíj a kereső MEV-jének legfeljebb 100%-a (mert ha a gázdíj magasabb lenne, pénzt veszítene vele). - -Viszont az erősen versenyképes MEV-lehetőségeknél, mint a [DEX arbitrázs](#mev-examples-dex-arbitrage), a keresőknek a teljes MEV-bevétel 90%-át vagy többet kell gázdíjként kifizetniük a validátornak, mivel sokan akarják ugyanazt az arbitrázst lefuttatni. Mivel az arbitrázsügyletük lefutását csak úgy tudják garantálni, ha a legmagasabb gázárral rendelkező tranzakciót adják be. - -### Gázgolfozás {#mev-extraction-gas-golfing} - -A MEV-vel kapcsolatos dinamika versenyelőnnyé tette a „gázgolfozást” – amikor a tranzakciókat úgy programozzák, hogy a lehető legkevesebb gázt használják –, mivel a keresők magasabb gázárat tudnak megadni, miközben a teljes gázdíjuk állandó (gázdíj = gázár * felhasznált gáz). - -Néhány jól ismert gázgolfozási technika: olyan címek használata, amelyek hosszú nullasorozattal kezdődnek (például [0x0000000000C521824EaFf97Eac7B73B084ef9306](https://etherscan.io/address/0x0000000000c521824eaff97eac7b73b084ef9306)), mivel ezek tárolása kevesebb helyet (így kevesebb gázt) igényel; kis [ERC-20](/developers/docs/standards/tokens/erc-20/) tokenegyenleg meghagyása a szerződésekben, mivel több gázba kerül egy tárolóhely inicializálása (ha az egyenleg 0), mint a frissítése. A gázfelhasználás csökkentésére irányuló technikák kutatása aktív témakörnek számít a keresők körében. - -### Általánosított frontrunnerök {#mev-extraction-generalized-frontrunners} - -Ahelyett, hogy komplex algoritmusokat programoznának a profitábilis MEV-lehetőségek felderítésére, egyes keresők általánosított frontrunneröket futtatnak. Ezek az általánosított frontrunnerök, amelyek figyelik a memóriakészletet, hogy felismerjék a profitábilis tranzakciókat. A frontrunner lemásolja a potenciálisan nyereséges tranzakció kódját, kicseréli a címeket a frontrunner címére, és helyben lefuttatja a tranzakciót, hogy ellenőrizze, a módosított tranzakció nyereséget eredményez-e. Ha a tranzakció valóban nyereséges, a frontrunner benyújtja a módosított tranzakciót a kicserélt címmel és magasabb gázárral, „megelőzve” az eredeti tranzakciót, és megkapja az eredeti kereső MEV-jét. - -### Flashbots {#mev-extraction-flashbots} - -A Flashbots egy független projekt, amely a végrehajtási klienseket egy olyan szolgáltatással bővíti, amely lehetővé teszi a keresők számára, hogy MEV-tranzakciókat nyújtsanak be a validátoroknak anélkül, hogy a nyilvános memóriakészlet számára felfednék azokat. Ez megakadályozza, hogy a tranzakciókat általánosított frontrunnerök futtassák. - -## Példák a MEV-re {#mev-examples} - -A MEV többféleképpen is megjelenik a blokkláncon. - -### DEX arbitrázs {#mev-examples-dex-arbitrage} - -[A decentralizált tőzsdei (DEX)](/glossary/#dex) arbitrázs a legegyszerűbb és legismertebb MEV-lehetőség. Ennek eredményeképpen a legnépszerűbb is. - -Ez a következőképpen működik: ha két DEX két különböző áron kínál egy tokent, valaki megveheti a tokent az alacsonyabb árú DEX-en, és eladhatja a magasabb árú DEX-en egyetlen, atomikus tranzakció keretében. A blokklánc mechanikájának köszönhetően ez valódi, kockázatmentes arbitrázs. - -[Íme egy példa](https://etherscan.io/tx/0x5e1657ef0e9be9bc72efefe59a2528d0d730d478cfc9e6cdd09af9f997bb3ef4) egy nyereséges arbitrázs tranzakcióra, ahol egy kereső 1000 ETH-t 1045 ETH-re váltott, kihasználva az ETH/DAI pár eltérő árazását az Uniswapon és a Sushiswapon. - -### Likvidációk {#mev-examples-liquidations} - -A kölcsönzési protokollok likvidációja egy másik jól ismert MEV-lehetőség. - -Az olyan kölcsönzési protokollok, mint a Maker és az Aave megkövetelik, hogy a felhasználók letétbe helyezzenek némi biztosítékot (például ETH-t). Ezt a letétbe helyezett biztosítékot aztán arra használják, hogy kölcsönadják más felhasználóknak. - -A felhasználók ezután kölcsönözhetnek eszközöket és tokeneket másoktól attól függően, hogy mire van szükségük (például MKR-t kölcsönözhet, ha szavazni szeretne egy MakerDAO javaslatban), a letétbe helyezett biztosíték bizonyos százalékáig. Például, ha a kölcsönzési összeg legfeljebb 30%, akkor egy felhasználó, aki 100 DAI-t fizet be a protokollba, legfeljebb 30 DAI értékű másik eszközt vehet kölcsön. A protokoll határozza meg a pontos kölcsönzési teljesítmény százalékos arányát. - -Ahogy a hitelfelvevő biztosítékának értéke ingadozik, úgy változik a hitelfelvételi képessége is. Ha a piaci ingadozások miatt a kölcsönvett eszközök értéke meghaladja a biztosíték értékének 30%-át (a pontos arányt a protokoll határozza meg), a protokoll általában lehetővé teszi, hogy bárki felszámolja a biztosítékot, azonnal kifizetve a hitelezőknek (hasonló a [pótlólagos fedezetbekéréshez (margin call)](https://www.investopedia.com/terms/m/margincall.asp) a hagyományos finanszírozásban). Likvidáció esetén a hitelfelvevőnek általában magas likvidációs díjat kell fizetnie, amelynek egy része a felszámolóhoz kerül – itt jön a képbe a MEV-lehetőség. - -A keresők versenyeznek a blokkláncadatok gyors elemzésében, hogy meghatározzák, mely hitelfelvevőket lehet likvidálni, elsőként nyújtsanak be likvidációs tranzakciót, és szedjék be maguknak a likvidációs díjat. - -### Szendvicskereskedelem {#mev-examples-sandwich-trading} - -A szendvicskereskedelem a MEV-kivonás másik gyakori módszere. - -A szendvicshez a kereső figyeli a memóriakészletet a nagy DEX-üzletekre. Például valaki 10 000 UNI-t akar vásárolni DAI-jal a Uniswapon. Egy ilyen nagyságrendű kereskedés jelentős hatással lesz az UNI/DAI párra, és jelentősen megemelheti az UNI árfolyamát a DAI-hoz képest. - -A kereső kiszámíthatja ennek az UNI/DAI párra gyakorolt megközelítő árhatását, és közvetlenül a kereskedés _előtt_ optimális vételi megbízást adhat, olcsón megvásárolva az UNI-t, majd közvetlenül a kereskedés _után_ eladási megbízást adhat, eladva azt a megbízás által okozott magasabb áron. - -A szendvicselés azonban kockázatosabb, mivel nem atomikus (ellentétben a fenti DEX-arbitrázzsal), és hajlamos a [szalmonella-támadásra](https://github.com/Defi-Cartel/salmonella). - -### NFT MEV {#mev-examples-nfts} - -A MEV az NFT-k esetében egy kialakulóban lévő jelenség, és nem feltétlenül nyereséges. - -Mivel azonban az NFT tranzakciók ugyanazon a blokkláncon történnek, amelyet az összes többi Ethereum tranzakció megoszt, a keresők az NFT piacon is hasonló technikákat használhatnak, mint a hagyományos MEV-lehetőségeknél. - -Például, ha van egy népszerű NFT-kiadás, és egy kereső egy bizonyos NFT-t vagy NFT-készletet szeretne, akkor beprogramozhat egy tranzakciót úgy, hogy ő legyen az első a sorban, vagy egyetlen tranzakcióban megvásárolhatja az egész készletet. Vagy ha egy NFT [tévesen alacsony áron szerepel](https://www.theblockcrypto.com/post/113546/mistake-sees-69000-cryptopunk-sold-for-less-than-a-cent), a kereső megelőzheti a többi vevőt, és olcsón megveheti. - -Az NFT MEV egyik kiemelkedő példája az volt, amikor egy kereső 7 millió dollárt költött arra, hogy [megvásárolja](https://etherscan.io/address/0x650dCdEB6ecF05aE3CAF30A70966E2F395d5E9E5) az összes Cryptopunkot a legalacsonyabb áron. Egy blokklánckutató [magyarázta a Twitteren](https://twitter.com/IvanBogatyy/status/1422232184493121538), hogy a vevő egy MEV-szolgáltatóval dolgozott, hogy titokban tartsa a vásárlást. - -### Hosszú távú lehetőségek (long tail) {#mev-examples-long-tail} - -A DEX arbitrázs, a likvidációk és a szendvicskereskedelem nagyon jól ismert MEV-lehetőségek, és nem valószínű, hogy nyereségesek lennének az új keresők számára. Létezik azonban a kevésbé ismert MEV-lehetőségek esetében egy hosszú távú lehetőség (az NFT MEV is ilyen). - -Akik most kezdik a keresést, több sikert érhetnek el, ha a long tail szekcióban (kevésbé ismert, kisebb hozammal járó, hosszabb távon használható lehetőségek között) keresnek MEV-et. A Flashbot [MEV-állásbörzéje](https://github.com/flashbots/mev-job-board) felsorol néhány új lehetőséget. - -## A MEV hatásai {#effects-of-mev} - -A MEV nem feltétlen rossz, pozitív és negatív következményei is vannak az Ethereumban. - -### A pozitív hatásai {#effects-of-mev-the-good} - -Számos DeFi-projekt gazdaságilag racionális szereplőkre támaszkodik, hogy biztosítsa protokolljaik hasznosságát és stabilitását. Például a DEX arbitrázs biztosítja, hogy a felhasználók a legjobb, legkorrektebb árakat kapják a tokenjeikért, a hitelezési protokollok pedig a gyors likvidációra támaszkodnak, amikor a hitelfelvevők a fedezeti arányok alá esnek, hogy a hitelezők visszakapják a pénzüket. - -Ha a racionális keresők nem keresik és javítják a gazdasági hatástalanságokat, és nem használják ki a protokollok gazdasági ösztönzőit, a DeFi protokollok és általában a dappok nem lehetnek olyan erősek, mint jelenleg. - -### A negatív hatásai {#effects-of-mev-the-bad} - -Az alkalmazási rétegen a MEV egyes formái, mint például a szendvicskereskedelem, egyértelműen rosszabb felhasználói élményt eredményeznek. A szendvicsbe szorított felhasználóknak nagyobb csúszással és rosszabb teljesítéssel kell számolniuk a kereskedéseik során. - -A hálózati szinten az általánosított frontrunnerök és az általuk gyakran folytatott gázár-árverések (két vagy több frontrunner versenyez, hogy tranzakciójuk bekerüljön a következő blokkba a gázár fokozatos emelésével) a hálózat túlterheltségét és magas gázárakat eredményeznek másoknak is, akik szabályos tranzakciókat próbál végrehajtani. - -A _blokkon belüli_ eseményeken túl a MEV káros hatással lehet _blokkok között_ is. Ha a blokkban elérhető MEV jelentősen meghaladja a sztenderd blokkjutalmat, a validátorokat arra ösztönözhetik, hogy blokkokat szervezzenek át, és a MEV-et maguknak szerezzék meg, ami a blokklánc átrendeződését és a konszenzus instabilitását okozza. - -A blokklánc átszervezésének ezt a lehetőségét [a Bitcoin blokkláncon](https://dl.acm.org/doi/10.1145/2976749.2978408) már korábban is vizsgálták. Ahogy a Bitcoin blokkjutalma a felére csökken, és a tranzakciós díjak egyre nagyobb részét teszik ki a blokkjutalomnak, kialakulhat, hogy a bányászoknak gazdaságilag racionális lehet, ha lemondanak a következő blokk jutalmáról, és helyette magasabb díjakkal újrabányásszák a korábbi blokkokat. A MEV növekedésével ugyanez a helyzet állhat elő az Ethereumban is, ami veszélyezteti a blokklánc integritását. - -## A MEV jelenlegi helyzete {#state-of-mev} - -A MEV-kivonás 2021 elején felpörgött, ami az év első hónapjaiban rendkívül magas gázárakat eredményezett. A Flashbots MEV relay (közvetítő) megjelenése csökkentette az általános frontrunnerök hatékonyságát, és láncon kívülre vitte a gázár-árveréseket, csökkentve a gázárakat a hétköznapi felhasználók számára. - -Bár sok kereső még mindig jól keres a MEV-vel, de ahogy a lehetőségek egyre ismertebbek és több kereső versenyez ugyanazért, a validátorok egyre több MEV-bevételt fognak szerezni (a Flashbots-ban is ugyanolyan gázárverések zajlanak, mint a fenti, bár magánjelleggel, és a validátorok az ebből származó gázbevételt kapják meg). A MEV nem csak az Ethereumra jellemző, és mivel egyre nagyobb a verseny, a keresők alternatív blokkláncok, például a Binance Smart Chain felé mozdulnak el, ahol hasonló MEV-lehetőségek léteznek kevesebb versennyel. - -Másrészt a proof-of-work-ről a proof-of-stake-re való áttérés és az Ethereum összevont tranzakciókkal történő skálázása olyan módon változtatják meg a MEV-térképet, amely még nem világos. Még nem ismert, hogy a némileg előre ismert blokkelőterjesztők hogyan változtatják meg a MEV-kivonás dinamikáját a proof-of-work valószínűségi modelljéhez képest, vagy hogyan változik, amikor [egyetlen, titkos vezetőválasztás](https://ethresear.ch/t/secret-non-single-leader-election/11789) és [elosztott validátortechnológia](/staking/dvt/) kerül bevezetésre. Még az sem egyértelmű, milyen MEV-lehetőségek lesznek, amikor a felhasználói tevékenységek az Ethereumról áthelyeződnek a második blokkláncrétegre (L2), az összevont tranzakciókra és a szilánkokra. - -## MEV az Ethereum proof-of-stake (PoS) mechanizmusában {#mev-in-ethereum-proof-of-stake} - -Amint azt kifejtettük, a MEV negatív hatással van az általános felhasználói élményre és a konszenzusszintű biztonságra. Az Ethereumnak a proof-of-stake konszenzusra való áttérése („a Beolvadás”) potenciálisan új, MEV-hez kapcsolódó kockázatokat hoz létre: - -### Validátorcentralizáció {#validator-centralization} - -A Beolvadás utáni Ethereumban a validátorok (miután 32 ETH értékű letétet helyeztek el) konszenzusra jutnak a Beacon lánchoz hozzáadott blokkok érvényességéről. A 32 ETH sokak számára elérhetetlen lehet, ezért megvalósíthatóbb[ egy letéti alaphoz való csatlakozás ](/staking/pools/). Mindazonáltal az [önálló letétbe helyezők](/staking/solo/) egészséges eloszlása ideális, mivel enyhíti a validátorok centralizációját és javítja az Ethereum biztonságát. - -A MEV-kivonás vélhetően képes felgyorsítani a validátorok centralizációját. Ez részben azért van így, mert a validátorok [kevesebbet kapnak a blokkelőterjesztésért](/roadmap/merge/issuance/#how-the-merge-impacts-ETH-supply), mint korábban a bányászatért, a MEV-kivonás jelentősen [befolyásolhatja a validátorok bevételeit](https://github.com/flashbots/eth2-research/blob/main/notebooks/mev-in-eth2/eth2-mev-calc.ipynb) a [Beolvadás](/roadmap/merge/) után. - -A nagyobb letéti alapok valószínűleg több erőforrással rendelkeznek ahhoz, hogy befektessenek a MEV-lehetőségek kihasználásához szükséges optimalizálásokba. Minél több MEV-t termelnek ki ezek a poolok, annál több erőforrásuk van ennek fejlesztésére (és a bevétel növelésére), ami [méretgazdaságosságot](https://www.investopedia.com/terms/e/economiesofscale.asp#) eredményez. - -Az önálló letétbe helyezők, akiknek kevesebb erőforrás áll a rendelkezésükre, nem feltétlen tudnak profitálni a MEV-lehetőségekből. Ez növelheti a független validátorokra nehezedő nyomást, hogy erős letéti alapokhoz csatlakozzanak, és így növeljék a bevételüket, ami csökkenti a decentralizációt az Ethereumban. - -### Engedélyhez kötött memóriakészletek {#permissioned-mempools} - -A szendvics és a frontrunning támadásokra válaszul a kereskedők a tranzakciók titkossága érdekében a láncon kívül is megegyezhetnek a validátorokkal. Ahelyett, hogy a kereskedő a nyilvános memóriakészletbe küldene egy potenciális MEV-tranzakciót, a kereskedő közvetlenül a validátornak küldi azt, aki beemeli egy blokkba, és osztozik a nyereségen a kereskedővel. - -Ennek az elrendezésnek egy nagyobb változatai a „sötét alapok”, melyek engedélyhez kötött, csak hozzáférést adó memóriakészletek, amelyek a fizetős felhasználók számára elérhetők. Ez a tendencia csökkentené az Ethereum engedélymentességét és a bizalomigény-mentességet, potenciálisan egy „pay-to-play” (fizetős játék) mechanizmussá alakítaná át, amely a legmagasabb ajánlattevőnek kedvez. - -Az engedélyhez kötött memóriakészletek az előző szakaszban leírt centralizációs kockázatokat is felgyorsítják. A több validátort működtető nagy alapok valószínűleg profitálni fognak abból, hogy a kereskedők és a felhasználók számára tranzakciós adatvédelmet kínálnak, növelve ezzel a MEV-bevételeiket. - -Ezeknek a MEV-hez kapcsolódó problémáknak a leküzdése a Beolvadás utáni Ethereumban a kutatás egyik fő területe. Két megoldás merült fel, hogy a MEV negatív hatását csökkentsék az Ethereum decentralizációja és biztonsága szempontjából a Beolvadás után: [**javaslattevő-építő szétválasztása (PBS)**](/roadmap/pbs/) és az [**építő API**](https://github.com/ethereum/builder-specs). - -### Javaslattevő-építő szétválasztása (PBS) {#proposer-builder-separation} - -Mind a proof-of-work, mind a proof-of-stake esetében egy csomópont építi a blokkot, majd javasolja azt a konszenzusban részt vevő többi csomópontnak a láncba való felvételre. Egy új blokk akkor válik a kanonikus lánc részévé, ha egy másik bányász ráépít (PoW esetén), vagy ha a validátorok többségétől tanúsítást kap (PoS esetén). - -A blokképítő és blokkajánló szerepek kombinációja az, ami a legtöbb MEV-hez kapcsolódó problémát okozza. A konszenzuscsomópontokat például arra ösztönzik, hogy a MEV-bevételek maximalizálása érdekében [időzített támadásokban](https://www.mev.wiki/attack-examples/time-bandit-attack) láncátrendezéseket indítsanak el. - -A [javaslattevő-építő szétválasztása (PBS)](https://ethresear.ch/t/proposer-block-builder-separation-friendly-fee-market-designs/9725) a MEV hatásának mérséklésére szolgál, különösen a konszenzusrétegben. A PBS fő jellemzője a blokképítő és a blokkelőterjesztő szabályainak szétválasztása. A validátorok továbbra is felelősek a blokkok előterjesztéséért és az azokra vonatkozó szavazásért, de a tranzakciók elrendezése és a blokkok építése egy új, specializált entitás, a **blokképítő** feladata. - -A PBS keretében egy blokképítő létrehoz egy tranzakciócsomagot, és ajánlatot tesz arra, hogy egy Beacon lánc blokkba bekerüljön, mint végrehajtási csomag (payload). A következő blokk előterjesztésére kiválasztott validátor ezután ellenőrzi az ajánlatokat, és kiválasztja a legmagasabb díjú csomagot. A PBS lényegében egy aukciós piacot hoz létre, ahol az építők tárgyalnak a blokkterületet értékesítő validátorokkal. - -A jelenlegi PBS-tervek egy [elköteleződés-feltárás sémát](https://gitcoin.co/blog/commit-reveal-scheme-on-ethereum/) használnak, amelyben az építők csak a blokk tartalmára vonatkozó kriptográfiai elköteleződést (blokkfejléc) teszik közzé az ajánlatukkal. A nyertes ajánlat elfogadása után az ajánlattevő egy aláírt blokkajánlatot készít, amely tartalmazza a blokkfejlécet. A blokképítőnek az aláírt blokkjavaslat megtekintése után közzé kell tennie a teljes blokkot, és a véglegesítés előtt elegendő [tanúsítást](/glossary/#attestation) kell kapnia a validátoroktól. - -#### Hogyan enyhíti a javaslattevő-építő szétválasztás a MEV hatását? {#how-does-pbs-curb-mev-impact} - -A protokollon belüli javaslattevő-építő szétválasztása csökkenti a MEV konszenzusra gyakorolt hatását azáltal, hogy a MEV-kivonás kikerül a validátorok hatásköréből. Ehelyett a speciális hardvert futtató blokképítők fogják megragadni a jövőben a MEV-lehetőségeket. - -Ez azonban nem zárja ki teljesen a validátorokat a MEV-hez kapcsolódó bevételekből, mivel az építőknek magas ajánlatot kell tenniük ahhoz, hogy blokkjaikat a validátorok elfogadják. Mindazonáltal, mivel a validátorok már nem összpontosítanak közvetlenül a MEV-bevételek optimalizálására, csökken az időzített támadások veszélye. - -A javaslattevő-építő szétválasztása csökkenti a MEV centralizációs kockázatait is. Például a elköteleződés-feltárás séma megszünteti azt a bizalomkényszert az építők részéről, hogy a validátorok nem lopják el a MEV-lehetőséget, vagy nem juttatják azt más építőnek. Ez csökkenti az akadályokat az önálló letétbe helyezők számára, hogy a MEV előnyeiből részesüljenek, máskülönben az építők inkább a nagy, a láncon kívüli hírnévvel rendelkező alapokat részesítenék előnyben, és láncon kívüli üzleteket kötnének velük. - -Hasonlóképpen, a validátoroknak nem kell attól tartani, hogy az építők visszatartanak blokkokat vagy érvényteleneket adnak, mivel a fizetés feltétel nélküli. A validátor díja akkor is feldolgozható, ha a javasolt blokk nem áll rendelkezésre, vagy egy másik validátor érvénytelennek nyilvánítja. Az utóbbi esetben a blokkot egyszerűen elvetik, így a blokképítő elveszíti a tranzakciós díjat és MEV-bevételt. - -### Építő API {#builder-api} - -Bár a javaslattevő-építő szétválasztás azt ígéri, hogy csökkenti a MEV-kivonás hatásait, a megvalósítása a konszenzusprotokoll módosítását igényli. Konkrétan a Beacon lánc [elágazásválasztási](/developers/docs/consensus-mechanisms/pos/#fork-choice) szabályát kell hozzá frissíteni. Az [építő API](https://github.com/ethereum/builder-specs) egy ideiglenes megoldás, amelynek célja a javaslattevő-építő szétválasztásának megvalósítása, bár magasabb bizalomigénnyel. - -Az építő API az [Engine API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) módosított változata, amelyet a konszenzusréteg kliensei használnak arra, hogy a végrehajtási réteg klienseitől végrehajtási csomagokat kérjenek. Az [őszintevalidátor-specifikáció](https://github.com/ethereum/consensus-specs/blob/dev/specs/bellatrix/validator.md) szerint a blokkelőterjesztési feladatokra kiválasztott validátorok tranzakciócsomagot kérnek egy kapcsolódó végrehajtási klienstől, amelyet a javasolt Beacon lánc blokkjába foglalnak. - -Az építő API szintén közvetítőként működik a validátorok és a végrehajtási réteg kliensei között; de ez más, mivel lehetővé teszi a Beacon láncon lévő validátoroknak, hogy külső entitásoktól szerezzenek blokkokat (nem helyben építik fel a végrehajtási klienssel). - -Az alábbiakban látható az építő API működése: - -1. Az építő API összekapcsolja a validátort a blokképítők hálózatával, amely végrehajtási réteg klienseket futtat. A PBS-hez hasonlóan az építők olyan specializált felek, akik erőforrásigényes blokképítésbe fektetnek be, és különböző stratégiákat alkalmaznak a MEV + elsőbbségi díjak maximalizálására. - -2. A validátor (amely egy konszenzusréteg-klienst futtat) az építőhálózattól ajánlatokkal együtt kéri a végrehajtási csomagot. Az építők ajánlatai tartalmazzák a végrehajtási csomag fejlécét – ami a csomag tartalmára vonatkozó kriptográfiai elköteleződés – és a validátornak fizetendő díjat. - -3. A validátor megvizsgálja a beérkező ajánlatokat, és kiválasztja a legmagasabb díjjal rendelkező végrehajtási csomagot. Az építő API használatával a validátor létrehoz egy „vak” Beacon-blokk javaslatot, amely csak az aláírását és a végrehajtási csomag fejlécét tartalmazza, majd elküldi azt az építőnek. - -4. Az építő API-t futtató építőtől elvárható, hogy a teljes végrehajtási csomaggal válaszoljon, amikor meglátja a vak blokkjavaslatot. Ez lehetővé teszi a validátorok számára, hogy „aláírt” Beacon-blokkot hozzanak létre, amelyet az egész hálózatban elterjesztenek. - -5. Az építő API-t használó validátortól továbbra is elvárják, hogy helyben építsen blokkot, ha a blokképítő nem válaszol azonnal, így nem marad le a blokkjavaslatok jutalmáról. A validátor azonban nem hozhat létre egy másik blokkot a felfedett tranzakciókkal vagy egy másik adaggal, mivel ez _kétértelműség_ lenne (két blokk aláírása egy sloton belül), ami szabálysértésnek minősül. - -Az építő API egyik példája a [MEV Boost](https://github.com/flashbots/mev-boost), a [Flashbots aukciós mechanizmus](https://docs.flashbots.net/Flashbots-auction/overview/) továbbfejlesztése, amelynek célja a MEV negatív hatásainak csökkentése az Ethereumban. A Flashbots aukció lehetővé teszi a proof-of-stake mechanizmusban a validátorok számára, hogy a nyereséges blokkok építését specializált **keresőknek** adják ki. ![Egy diagram, amely a MEV áramlását mutatja be részleteiben](./mev.png) - -A keresők jövedelmező MEV-lehetőségeket keresnek, és tranzakciós csomagokat küldenek a blokkelőterjesztőknek egy [lepecsételt árú ajánlattal](https://en.wikipedia.org/wiki/First-price_sealed-bid_auction) együtt a blokkba való felvételre. A mev-geth-et, a go-ethereum (Geth) kliens elágaztatott változatát futtató validátornak csak ki kell választania a legnagyobb nyereséget hozó köteget, és azt az új blokk részévé kell tennie. A blokkelőterjesztők (validátorok) spamektől és érvénytelen tranzakcióktól való védelme érdekében a tranzakciókötegeket **közvetítők (relayer)** ellenőrzik, mielőtt azok eljutnak az előterjesztőhöz. - -A MEV Boost megtartja az eredeti Flashbots aukció működését, bár az Ethereum proof-of-stake-re való átállásához tervezett új funkciókkal. A keresők továbbra is találnak jövedelmező MEV-tranzakciókat a blokkokba való felvételhez, de a tranzakciók és kötegek blokkokká történő összevonásáért új, specializált szereplők, az **építők** felelősek. Az építő elfogadja a keresők lepecsételt-árú ajánlatait, és optimalizálásokat futtat a legjövedelmezőbb sorrend megtalálása érdekében. - -A közvetítő továbbra is felelős a tranzakciókötegek validálásáért, mielőtt továbbítja azokat a javaslattevőnek. A MEV Boost ugyanakkor bevezeti a **letéteket**, amelyek a [adatelérhetőség](/developers/docs/data-availability/) biztosításáért felelősek az építők által küldött blokkok és a validátorok által küldött blokkfejlécek tárolásával. Itt a közvetítőhöz (relay) csatlakozó validátor kéri az elérhető végrehajtási csomagokat, és a MEV Boost rendezési algoritmusát használja arra, hogy a legmagasabb ajánlatot és a MEV-borravalókat tartalmazó csomag fejlécét kiválassza. - -#### Hogyan csökkenti az építő API a MEV hatását? {#how-does-builder-api-curb-mev-impact} - -Az építő API alapvető előnye, hogy demokratizálja a MEV-lehetőségekhez való hozzáférést. A elköteleződés-feltárás sémák használata kiküszöböli a bizalmi feltételezéseket, és csökkenti a belépési korlátokat a MEV előnyeit kihasználni kívánó validálók számára. Ez csökkentené az önálló letétbe helyezőkön lévő nyomást, hogy a MEV-nyereség növelése érdekében nagy letéti alapokba integrálódjanak. - -Az építő API széles körű bevezetése nagyobb versenyt ösztönöz a blokképítők között, ami növeli a cenzúrával szembeni ellenállást. Mivel a validátorok több építő ajánlatát vizsgálják, az egy vagy több tranzakciót cenzúrázó építőnek túl kell licitálnia a nem cenzúrázók ajánlatait ahhoz, hogy sikeres legyen. Ez rendkívül megnöveli a felhasználók cenzúrázásának költségeit, és így elrettenti őket ettől a gyakorlattól. - -Egyes projektek, mint például a MEV Boost, az építő API-t egy olyan átfogó struktúra részeként használják, amelynek célja, hogy bizonyos felek, például a frontrunning/szendvicstámadásokat elkerülni próbáló kereskedők számára adatvédelmet biztosítson. Ezt úgy érjük el, hogy privát kommunikációs csatornát biztosítunk a felhasználók és a blokképítők között. A fenti engedélyhez kötött memóriakészletekkel ellentétben ez a megközelítés a következők miatt előnyös: - -1. Mivel a piacon több építő is jelen van, a cenzúrázás gyakorlatilag lehetetlen, ami előnyös a felhasználók számára. Ezzel szemben a centralizált és bizalomigényű „sötét alapok” létezése néhány blokképítő kezében összpontosítaná a hatalmat, és növelné a cenzúra lehetőségét. - -2. Az építő API szoftver nyílt forráskódú, ami lehetővé teszi, hogy bárki blokképítő szolgáltatásokat kínáljon. Eszerint a felhasználók nem kényszerülnek arra, hogy egy adott blokképítőt használjanak, és javítja az Ethereum semlegességét és engedélymentességét. Ráadásul a MEV-et kereső kereskedők nem járulnak hozzá akaratlanul a centralizációhoz azzal, hogy privát tranzakciós csatornákat használnak. - -## Kapcsolódó források {#related-resources} - -- [Flashbots-dokumentáció](https://docs.flashbots.net/) -- [Flashbots GitHub](https://github.com/flashbots/pm) -- [MEV-Explore](https://explore.flashbots.net/) – _Dashboard és tranzakciófelfedező a MEV tranzakciókhoz_ -- [mevboost.org](https://www.mevboost.org/) – _Tracker valós idejű statisztikákkal a MEV-Boost közvetítőkhöz és blokképítőkhöz_ - -## További olvasnivaló {#further-reading} - -- [Mi az a bányászattal kivonható érték (MEV)?](https://blog.chain.link/what-is-miner-extractable-value-mev/) -- [A MEV és én](https://www.paradigm.xyz/2021/02/mev-and-me) -- [Az Ethereum egy sötét erdő](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest/) -- [Kijutni a sötét erdőből](https://samczsun.com/escaping-the-dark-forest/) -- [Flashbots: megelőzni (frontrunning) a MEV-krízist](https://medium.com/flashbots/frontrunning-the-mev-crisis-40629a613752) -- [@bertcmiller MEV írásai](https://twitter.com/bertcmiller/status/1402665992422047747) -- [MEV-Boost: A Beolvadásra kész Flashbots-architektúra](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177) -- [Mi az a MEV Boost](https://www.alchemy.com/overviews/mev-boost) -- [Miért futtassunk MEV Boost-ot?](https://writings.flashbots.net/writings/why-run-mevboost/) -- [Ethereum útikalauz stopposoknak](https://members.delphidigital.io/reports/the-hitchhikers-guide-to-ethereum) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/oracles/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/oracles/index.md deleted file mode 100644 index 4d5be1d51fb..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/oracles/index.md +++ /dev/null @@ -1,433 +0,0 @@ ---- -title: Orákulumok -description: Az orákulumok valós adatokhoz való hozzáférést biztosítanak az Ethereum okosszerződései számára, több felhasználási lehetőséget és nagyobb értéket teremtve a felhasználóknak. -lang: hu ---- - -Az orákulumok olyan alkalmazások, amelyek adatcsatornákat hoznak létre, hogy elérhetővé tegyék a láncon kívüli adatforrásokat a blokkláncon lévő okosszerződések számára. Erre azért van szükség, mert az Ethereum-alapú okosszerződések alapértelmezés szerint nem férhetnek hozzá a blokkláncon kívül tárolt információkhoz. - -Ha az okosszerződéseket a láncon kívüli adatok felhasználásával lehet végrehajtani, az kiterjeszti a decentralizált alkalmazások hasznosságát és értékét. A láncon belüli előrejelzési piacok például orákulumokra támaszkodnak, hogy információt szolgáltassanak az eredményekről, amelyet a felhasználók előrejelzéseinek validálására használnak. Tegyük fel, hogy Alice 20 ETH-t tesz fel arra, hogy ki lesz a következő amerikai elnök. Ebben az esetben az előrejelzési piac dappnak szüksége van egy orákulumra, amely megerősíti a választási eredményeket, és meghatározza, hogy Alice jogosult-e kifizetésre. - -## Előfeltételek {#prerequisites} - -Ezt az oldalt könnyebb megérteni, ha az olvasó ismeri az Ethereum alapjait, beleértve a [csomópontokat](/developers/docs/nodes-and-clients/), a [konszenzusmechanizmusokat](/developers/docs/consensus-mechanisms/) és az [EVM-et](/developers/docs/evm/). Érdemes ismerni a [okosszerződéseket](/developers/docs/smart-contracts/) és a [okosszerződések anatómiáját](/developers/docs/smart-contracts/anatomy/), különösen az [eseményeket](/glossary/#events). - -## Mi az a blokkláncorákulum? {#what-is-a-blockchain-oracle} - -Az orákulumok olyan alkalmazások, amelyek külső információkat (azaz a láncon kívül tárolt információkat) gyűjtenek, ellenőriznek és továbbítanak a blokkláncon futó okosszerződésekhez. Amellett, hogy az orákulumok a láncon kívüli adatokat hoznak be az Ethereumra és terjesztik szét azokat, a blokkláncról információkat is küldhetnek külső rendszerekbe, például feloldhatnak egy intelligens zárat, amint a felhasználó Ethereum-tranzakción keresztül elküldi a releváns díjat. - -Orákulum nélkül az okosszerződés kizárólag a láncon belüli adatokra korlátozódna. - -Az orákulumok eltérnek az adatforrás (egy vagy több forrás), a bizalomigény (centralizált vagy decentralizált) és a rendszer felépítése (azonnali olvasás, közzététel-feliratkozás és kérés-válasz) szerint. Az orákulumokat aszerint is megkülönböztethetjük, hogy külső adatokat kérnek le a láncon belüli szerződéseknek (bemeneti orákulumok), információt küldenek a blokkláncból a láncon kívüli alkalmazásoknak (kimeneti orákulumok), vagy számítási feladatokat végeznek a láncon kívül (számítási orákulumok). - -## Miért szükséges az okosszerződésekhez orákulum? {#why-do-smart-contracts-need-oracles} - -Sok fejlesztő úgy tekint az okosszerződésekre, mint a blokklánc adott címein futó kódokra. Az okosszerződések [általánosabb nézete](/smart-contracts/) azonban az, hogy ezek olyan önvégrehajtó szoftverprogramok, amelyek képesek a felek közötti megállapodások érvényesítésére, ha bizonyos feltételek teljesülnek – innen ered az okosszerződés kifejezés. - -De az okosszerződések használata az emberek közötti megállapodások érvényesítésére nem egyszerű, mivel az Ethereum determinisztikus. A [determinisztikus rendszer](https://en.wikipedia.org/wiki/Deterministic_algorithm) egy kezdeti állapot, amely egy adott bemenet mellett mindig ugyanazt az eredményt produkálja, vagyis nincs véletlenszerűség vagy variáció a bemenetekből származó kimenetek kiszámításának folyamatában. - -A determinisztikus végrehajtás elérése érdekében a blokkláncok a csomópontokat arra korlátozzák, hogy egyszerű bináris (igaz/hamis) kérdésekben konszenzusra jussanak _csak_ a blokkláncon tárolt adatok felhasználásával. Példák az ilyen kérdésekre: - -- „A (nyilvános kulccsal azonosított) számlatulajdonos aláírta ezt a tranzakciót a hozzá tartozó privát kulccsal?” -- „Van-e elegendő fedezet ezen a számlán a tranzakció fedezésére?” -- „Érvényes ez a tranzakció az adott okosszerződés keretében?” stb. - -Ha a blokkláncok külső forrásból (azaz a való világból) kapnának információt, a determinizmus megvalósítása lehetetlen lenne, ami megakadályozná, hogy a csomópontok megegyezzenek a blokklánc státuszában bekövetkezett változásokról. Vegyünk például egy olyan okosszerződést, amely egy tranzakciót hajt végre a hagyományos ár-API-ból kapott aktuális ETH-USD árfolyam alapján. Ez a szám valószínűleg gyakran változik (arról nem is beszélve, hogy az API-t elavulttá tehetik vagy feltörhetik), ami azt jelenti, hogy az azonos szerződéskódot végrehajtó csomópontok különböző eredményekre jutnának. - -Egy olyan nyilvános blokklánc esetében, mint az Ethereum, ahol világszerte több ezer csomópont dolgozza fel a tranzakciókat, a determinizmus kritikus fontosságú. Mivel nincs központi hatóság, amely az igazság forrásaként szolgálna, a csomópontoknak olyan mechanizmusokra van szükségük, amelyekkel ugyanazon tranzakciók feldolgozása után ugyanazt az státuszt érik el. Az az eset, amikor az A csomópont végrehajtja egy okosszerződés kódját, és 3-at kap eredményként, míg a B csomópont 7-et kap ugyanarra, a konszenzus felbomlásához vezetne, és megszüntetné az Ethereum mint decentralizált számítástechnikai platform értékét. - -Ez a forgatókönyv rávilágít arra a problémára is, hogy a blokkláncokat úgy tervezzük meg, hogy külső forrásokból nyerjenek információkat. Az orákulumok azonban úgy oldják meg ezt a problémát, hogy információkat vesznek a láncon kívüli forrásokból, és azt a blokkláncon tárolják, hogy az okosszerződések felhasználhassák azokat. Mivel a láncon belül tárolt információk megváltoztathatatlanok és nyilvánosan elérhetők, az Ethereum-csomópontok biztonságosan használhatják a láncon kívülről importált orákulum-adatokat a státuszváltozások kiszámításához anélkül, hogy a konszenzus megszakadna. - -Ehhez az orákulum egy láncon belüli okosszerződésből és néhány láncon kívüli komponensből áll. A láncon belüli szerződés más okosszerződésektől kap adatigényléseket, amelyeket a láncon kívüli komponensnek (az úgynevezett orákulum-csomópontnak) továbbít. Ez az orákulum-csomópont lekérdezhet adatforrásokat – például alkalmazás programozási felület (API) használatával –, illetve tranzakciókat küldhet arra, hogy a kért adatok az okosszerződés tárolójába kerüljenek. - -Lényegében egy blokklánc-orákulum áthidalja a blokklánc és a külső környezet közötti információs szakadékot, „hibrid okosszerződéseket” létrehozva. A hibrid okosszerződés a láncon belüli szerződéskód és a láncon kívüli infrastruktúra kombinációján alapul. A decentralizált előrejelzési piacok kiváló példái a hibrid okosszerződéseknek. További példák lehetnek a terménybiztosítási okosszerződések, amelyek akkor fizetnek, amikor az orákulumok egy csoportja megállapítja, hogy bizonyos időjárási jelenségek bekövetkeztek. - -## Mi az orákulumprobléma? {#the-oracle-problem} - -Az orákulumok fontos problémát oldanak meg, de némi bonyodalmat is okoznak, például: - -- Hogyan ellenőrizzük, hogy a bejuttatott információ a megfelelő forrásból származik-e, vagy nem manipulálták-e? - -- Hogyan biztosítsuk, hogy ezek az adatok mindig rendelkezésre álljanak és rendszeresen frissüljenek? - -Az úgynevezett „orákulumprobléma” azokat a nehézségeket mutatja be, amelyek abból adódnak, hogy a blokklánc orákulumai adatot szolgáltatnak az okosszerződéseknek. Az orákulumtól származó adatoknak helyesnek kell lenniük ahhoz, hogy egy okosszerződés helyesen teljesüljön. Továbbá az, hogy meg kell bízni az orákulumoperátorokban, hogy pontos információkat szolgáltassanak, aláássa az okosszerződések bizalomigény nélküli aspektusát. - -A különböző orákulumok különböző megoldásokat kínálnak az orákulumproblémára, amelyeket később vizsgálunk meg. Az orákulumokat általában aszerint értékelik, hogy mennyire képesek kezelni a következő kihívásokat: - -1. **Helyesség**: Egy orákulum nem okozhatja, hogy az okosszerződések állapotváltozásokat indítsanak el érvénytelen, láncon kívüli adatok alapján. Az orákulumnak garantálnia kell az adatok _hitelességét_ és _integritását_. A hitelesség azt jelenti, hogy az adatok a megfelelő forrásból származnak, az integritás pedig az, hogy az adatok sértetlenek maradtak (azaz nem változtatták meg őket), mielőtt továbbküldték a láncon belülre. - -2. **Elérhetőség**: Az orákulum nem késleltetheti vagy akadályozhatja meg az okosszerződések végrehajtását és a státuszváltozások kiváltását. Ez azt jelenti, hogy az orákulumtól származó adatoknak megszakítás nélkül kell _rendelkezésre állniuk kérés esetén_. - -3. **Ösztönzőkompatibilitás**: Az orákulumnak ösztönöznie kell a láncokon kívüli adatszolgáltatókat arra, hogy helyes információkat küldjenek az okosszerződéseknek. Az ösztönzőkompatibilitás magában foglalja a _hozzárendelhetőséget_ és az _elszámoltathatóságot_. A hozzárendelhetőség lehetővé teszi egy külső információ összekapcsolását a szolgáltatójával, míg az elszámoltathatóság az adatszolgáltatókat az általuk adott információhoz köti, így a szolgáltatott információ minősége alapján jutalmazhatók vagy büntethetők. - -## Hogyan működik a blokklánc orákulumszolgáltatás? {#how-does-a-blockchain-oracle-service-work} - -### Felhasználók {#users} - -A felhasználók olyan entitások (azaz okosszerződések), amelyeknek a blokkláncon kívüli információkra van szükségük bizonyos műveletekhez. Az orákulumszolgáltatás alapvető folyamata azzal kezdődik, hogy a felhasználó adatot kér az orákulumszerződéstől. Az adatkérések általában az alábbi kérdések némelyikére vagy mindegyikére választ adnak: - -1. Milyen forrásokból tájékozódhatnak a láncon kívüli csomópontok a kért információról? - -2. Hogyan dolgozzák fel a riportolók az adatforrásokból származó információkat, és hogyan vonják ki a hasznos adatpontokat? - -3. Hány orákulum-csomópont vehet részt az adatok lekérdezésében? - -4. Hogyan kell kezelni az orákulumjelentésekben szereplő eltéréseket? - -5. Milyen módszert kell alkalmazni a beérkezett kérések szűrésére és a jelentések egyetlen értékké történő összesítésére? - -### Orákulumszerződés {#oracle-contract} - -Az orákulumszerződés az orákulumszolgáltatás láncon belüli összetevője. Figyeli a más szerződésektől érkező adatkéréseket, továbbítja az adatkéréseket az orákulum-csomópontoknak, és a visszaküldött adatokat továbbítja az kliensszerződéseknek. Ez a szerződés végezhet számításokat is a visszaküldött adatpontokon, hogy egy összesített értéket állítson elő, amelyet elküldhet az adatot kérő szerződésnek. - -Az orákulumszerződés tartalmaz néhány függvényt, amelyeket a kliensszerződések hívnak meg adatigényléskor. Egy új lekérdezés fogadásakor az okosszerződés egy [naplóeseményt](/developers/docs/smart-contracts/anatomy/#events-and-logs) bocsát ki az adatkérés részleteivel. Ez értesíti a naplóra feliratkozott, láncon kívüli csomópontokat (általában a JSON-RPC `eth_subscribe` parancsot használva), amelyek lekérdezik a naplóeseményben meghatározott adatokat. - -Az alábbiakban egy [orákulumszerződéses példa](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) olvasható Pedro Costától. Ez egy egyszerű orákulumszolgáltatás, amely más okosszerződések kérésére lekérdezheti a láncon kívüli API-okat, és a kért információt a blokkláncon tárolja: - -```solidity -pragma solidity >=0.4.21 <0.6.0; - -contract Oracle { - Request[] requests; //list of requests made to the contract - uint currentId = 0; //increasing request id - uint minQuorum = 2; //minimum number of responses to receive before declaring final result - uint totalOracleCount = 3; // Hardcoded oracle count - - // defines a general api request - struct Request { - uint id; //request id - string urlToQuery; //API url - string attributeToFetch; //json attribute (key) to retrieve in the response - string agreedValue; //value from key - mapping(uint => string) answers; //answers provided by the oracles - mapping(address => uint) quorum; //oracles which will query the answer (1=oracle hasn't voted, 2=oracle has voted) - } - - //event that triggers oracle outside of the blockchain - event NewRequest ( - uint id, - string urlToQuery, - string attributeToFetch - ); - - //triggered when there's a consensus on the final result - event UpdatedRequest ( - uint id, - string urlToQuery, - string attributeToFetch, - string agreedValue - ); - - function createRequest ( - string memory _urlToQuery, - string memory _attributeToFetch - ) - public - { - uint length = requests.push(Request(currentId, _urlToQuery, _attributeToFetch, "")); - Request storage r = requests[length-1]; - - // Hardcoded oracles address - r.quorum[address(0x6c2339b46F41a06f09CA0051ddAD54D1e582bA77)] = 1; - r.quorum[address(0xb5346CF224c02186606e5f89EACC21eC25398077)] = 1; - r.quorum[address(0xa2997F1CA363D11a0a35bB1Ac0Ff7849bc13e914)] = 1; - - // launch an event to be detected by oracle outside of blockchain - emit NewRequest ( - currentId, - _urlToQuery, - _attributeToFetch - ); - - // increase request id - currentId++; - } - - //called by the oracle to record its answer - function updateRequest ( - uint _id, - string memory _valueRetrieved - ) public { - - Request storage currRequest = requests[_id]; - - //check if oracle is in the list of trusted oracles - //and if the oracle hasn't voted yet - if(currRequest.quorum[address(msg.sender)] == 1){ - - //marking that this address has voted - currRequest.quorum[msg.sender] = 2; - - //iterate through "array" of answers until a position if free and save the retrieved value - uint tmpI = 0; - bool found = false; - while(!found) { - //find first empty slot - if(bytes(currRequest.answers[tmpI]).length == 0){ - found = true; - currRequest.answers[tmpI] = _valueRetrieved; - } - tmpI++; - } - - uint currentQuorum = 0; - - //iterate through oracle list and check if enough oracles(minimum quorum) - //have voted the same answer as the current one - for(uint i = 0; i < totalOracleCount; i++){ - bytes memory a = bytes(currRequest.answers[i]); - bytes memory b = bytes(_valueRetrieved); - - if(keccak256(a) == keccak256(b)){ - currentQuorum++; - if(currentQuorum >= minQuorum){ - currRequest.agreedValue = _valueRetrieved; - emit UpdatedRequest ( - currRequest.id, - currRequest.urlToQuery, - currRequest.attributeToFetch, - currRequest.agreedValue - ); - } - } - } - } - } -} -``` - -### Orákulum-csomópontok {#oracle-nodes} - -Az orákulum-csomópont az orákulumszolgáltatás láncon kívüli összetevője. Információkat szerez külső forrásokból, például harmadik fél szerverein tárolt API-okból, és a láncon belülre helyezi, hogy az okosszerződések felhasználhassák azokat. Az orákulum-csomópontok figyelik a láncon belüli orákulumszerződés eseményeit, és folytatják a naplóban leírt feladat elvégzését. - -Az orákulum-csomópontok gyakori feladata, hogy [HTTP GET](https://www.w3schools.com/tags/ref_httpmethods.asp) kérést küldjenek egy API-szolgáltatáshoz, elemezzék a választ a releváns adatok kinyeréséhez, formázzák az adatokat a blokklánc által olvasható kimenetté, és elküldjék a láncon belül egy tranzakcióba foglalva az orákulumszerződéshez. Az orákulum-csomópontnak a benyújtott információk érvényességét és sértetlenségét „hitelességi bizonyítékok” segítségével is igazolnia kell, amelyeket később vizsgálunk meg. - -A számítási orákulumok a láncon kívüli csomópontokra is támaszkodnak olyan számítási feladatok elvégzésében, amelyeket a láncon belül nem lenne célszerű végrehajtani, tekintettel a gázköltségekre és a blokkméretkorlátokra. Az orákulum-csomópont feladata lehet például egy ellenőrizhetően véletlenszerű szám előállítása (például blokkláncalapú játékok esetében). - -## Orákulumtervezési minták {#oracle-design-patterns} - -Az orákulumoknak több különböző típusa létezik, beleértve az _azonnali olvasás_, _közzététel-feliratkozás_ és _kérés-válasz_ típusokat, amelyek közül az utóbbi kettő a legnépszerűbb az Ethereum-okosszerződések körében. Röviden ismertetjük a közzététel-feliratkozás és kérés-válasz modelleket. - -### A közzététel-feliratkozás orákulumok {#publish-subscribe-oracles} - -Az ilyen típusú orákulum egy „adatfolyamot” tesz közzé, amelyet a szerződések rendszeresen olvashatnak információkért. Ebben az esetben az adatok várhatóan gyakran változnak, ezért a kliensszerződéseknek figyelniük kell az orákulum tárolójában lévő adatok frissítésére. Például az az orákulum, mely a legfrissebb ETH-USD árinformációkat szolgáltatja a felhasználóknak. - -### Kérés-válasz orákulumok {#request-response-oracles} - -A kérés-válasz beállítás lehetővé teszi a kliensszerződés számára, hogy a közzététel-feliratkozás típusú orákulum által biztosított adatoktól eltérő, tetszőleges adatokat kérjen. A kérés-válasz orákulumok ideálisak, ha az adathalmaz túl nagy ahhoz, hogy az okosszerződés tárhelyén tárolják, és/vagy a felhasználóknak az adatoknak csak egy kis részére van szükségük egy adott időpontban. - -Bár a közzététel-feliratkozás típusú modelleknél összetettebbek, a kérés-válasz orákulumok alapvetően az előző szakaszban leírtaknak felelnek meg. Az orákulumnak van egy láncon belüli komponense, amely fogad egy adatkérést, és továbbítja azt egy láncon kívüli csomópontnak feldolgozásra. - -Az adatlekérdezést kezdeményező felhasználóknak kell fedezniük a láncon kívüli forrásból származó információk költségeit. A kliensszerződésnek biztosítania kell a fedezetet arra a gázköltségre, amikor az orákulumszerződés a választ visszakapja a callback függvényen keresztül. - -## A centralizált és a decentralizált orákulumok összehasonlítása {#types-of-oracles} - -### Centralizált orákulumok {#centralized-oracles} - -A centralizált orákulumot egyetlen szervezet irányítja, amely a láncon kívüli információk összesítéséért és az orákulumszerződés adatainak kérés szerinti frissítéséért is felelős. A centralizált orákulumok hatékonyak, mivel csak egyetlen igazságforrásra támaszkodnak. Jobban működhetnek azokban az esetekben, amikor a védett adatkészleteket közvetlenül a tulajdonos teszi közzé egy elfogadott aláírással. Ugyanakkor hátrányaik is vannak: - -#### Alacsony helyességi garanciák {#low-correctness-guarantees} - -A centralizált orákulumok esetében nem lehet megerősíteni, hogy a megadott információ helyes-e vagy sem. Még a „jó hírű” szolgáltatók is tévedhetnek vagy feltörhetik őket. Ha az orákulum hibássá válik, az okosszerződések rossz adatok alapján kerülnek végrehajtásra. - -#### Alacsony szintű elérhetőség {#poor-availability} - -A centralizált orákulumok nem garantálják, hogy mindig elérhetővé teszik a láncon kívüli adatokat az okosszerződések számára. Ha a szolgáltató úgy dönt, hogy kikapcsolja a szolgáltatást, vagy egy hacker eltéríti az orákulum láncon kívüli komponensét, akkor a rá támaszkodó okosszerződést a szolgáltatásmegtagadás (DoS-támadás) kockázata fenyegeti. - -#### Gyenge ösztöntzőkompatibilitás {#poor-incentive-compatibility} - -A centralizált orákulumok gyakran rosszul megtervezett ösztönzőket adnak az adatszolgáltatóknak vagy nem adnak semmit azért, hogy azok pontos/helyes információkat küldjenek. Ha egy orákulumnak fizetünk a helyességért, az még nem garantálja azt. Ez a probléma annál nagyobb lesz, minél nagyobb az okosszerződések által kezelt érték. - -### Decentralizált orákulumok {#decentralized-oracles} - -A decentralizált orákulumok célja a centralizáltak korlátainak kiküszöbölése azáltal, hogy kizárjuk az egyetlen meghibásodási pont lehetőségét. A decentralizált orákulumszolgáltatás egy egyenrangú hálózat több résztvevőjéből áll, akik konszenzust alakítanak ki a láncon kívüli adatokról, mielőtt elküldenék azokat egy okosszerződésnek. - -Egy decentralizált orákulum (ideális esetben) engedély nélküli, bizalomigénytől mentes és nem kezeli azt egy központi fél; a valóságban a decentralizáció egy spektrumon mozog. Vannak félig decentralizált orákulumhálózatok, amelyekben bárki részt vehet, de van egy „tulajdonos”, aki a korábbi teljesítmény alapján jóváhagyja és eltávolítja a csomópontokat. Léteznek teljesen decentralizált orákulumhálózatok is: ezek általában önálló blokkláncokként működnek, és meghatározott konszenzusmechanizmusokkal rendelkeznek a csomópontok koordinálására és a helytelen viselkedés szankcionálására. - -A decentralizált orákulumok használata a következő előnyökkel jár: - -### Magas szintű helyességi garanciák {#high-correctness-guarantees} - -A decentralizált orákulumok különböző megközelítésekkel próbálják elérni az adatok helyességét. Ez magában foglalja a visszaküldött információk hitelességét és integritását igazoló bizonyítékok használatát, valamint több szervezetnek együttesen meg kell állapodnia a láncon kívüli adatok érvényességéről. - -#### Hitelességi igazolások {#authenticity-proofs} - -A hitelességi bizonyítékok olyan kriptográfiai mechanizmusok, amelyek lehetővé teszik a külső forrásból származó információk független ellenőrzését. Ezek a bizonyítékok hitelesíthetik az információ forrását, és felismerhetik azt, hogy módosították-e az adatokat a lekérdezés után. - -Példák a hitelességi igazolásokra: - -**Transport Layer Security (TLS) bizonyítékok**: Az orákulum-csomópontok gyakran kérnek le adatokat külső forrásokból a Transport Layer Security (TLS) protokollon alapuló biztonságos HTTP-kapcsolat segítségével. Egyes decentralizált orákulumok hitelességi igazolásokat alkalmaznak a TLS-munkamenetek ellenőrzésére (azaz egy csomópont és egy adott kiszolgáló közötti információcsere megerősítésére), és arra, hogy a munkamenet tartalmát nem módosították. - -**Trusted Execution Environment (TEE) tanúsítványok**: A [megbízható végrehajtási környezet](https://en.wikipedia.org/wiki/Trusted_execution_environment) (TEE) egy olyan sandbox számítási környezet, amely elszigetelten működik a gazdarendszer folyamataitól. A TEE-k biztosítják, hogy a számítási környezetben tárolt/használt alkalmazáskód vagy adat megőrzi integritását, bizalmas jellegét és megváltoztathatatlanságát. A felhasználók tanúsítást is létrehozhatnak annak igazolására, hogy egy alkalmazáspéldány a megbízható végrehajtási környezetben fut. - -A decentralizált orákulumok bizonyos osztályai megkövetelik, hogy az orákulum-csomópontok üzemeltetői TEE-tanúsítványokat adjanak. Ez megerősíti a felhasználó felé, hogy a csomópont üzemeltetője egy megbízható végrehajtási környezetben futtatja az orákulumkliens egy példányát. A TEE-k megakadályozzák, hogy külső folyamatok megváltoztassák vagy elolvassák az alkalmazás kódját és adatait, ezért ezek az igazolások bizonyítják, hogy az orákulum-csomópont sértetlenül és bizalmasan őrzi az információkat. - -#### Az információk konszenzusalapú validálása {#consensus-based-validation-of-information} - -A centralizált orákulumok az igazság egyetlen forrására támaszkodnak, amikor adatokat szolgáltatnak az okosszerződéseknek, ami magában hordozza a pontatlan információk közzétételének lehetőségét. A decentralizált orákulumok úgy oldják meg ezt a problémát, hogy több orákulum-csomópontra támaszkodva kérdezik le a láncon kívüli információkat. A több forrásból származó adatok összehasonlításával a decentralizált orákulumok csökkentik azt a kockázatot, hogy az érvénytelen információkat adnak a láncon belüli szerződéseknek. - -A decentralizált orákulumoknak azonban kezelniük kell a több, láncon kívüli forrásból származó információk közötti eltéréseket. Az információkülönbségek minimalizálása és annak biztosítása érdekében, hogy az orákulumszerződéshez továbbított adatok az orákulum-csomópontok kollektív véleményét tükrözzék, a decentralizált orákulumok a következő mechanizmusokat használják: - -##### Szavazás/letétadás az adatok pontossága érdekében - -Egyes decentralizált orákulumhálózatok megkövetelik, hogy a résztvevők szavazzanak vagy letétet helyezzenek az adatkérdésekre adott válaszok pontosságára (például „Ki nyerte a 2020-as amerikai választásokat?”) a hálózat natív tokenjét használva. Ezután egy aggregációs protokoll összesíti a szavazatokat és letéteket, és a többség által támogatott választ tekinti érvényesnek. - -Azokat a csomópontokat, amelyek válaszai eltérnek a többségi választól, úgy büntetik, hogy a tokenjeiket szétosztják azok között, amelyek többször adnak helyes értéket. Ha a csomópontoknak az adatszolgáltatás előtt kötelezvényt kell adniuk, akkor ez őszinte válaszadásra ösztönzi őket, mivel feltételezzük, hogy a racionális gazdasági szereplők hozammaximalizálásra törekszenek. - -A letét adás/szavazás megvédi a decentralizált orákulumokat a [Sybil-támadásoktól](/glossary/#sybil-attack) is, amikor a rosszindulatú szereplők több személyazonosságot hoznak létre, hogy kijátsszák a konszenzusrendszert. A letétadás azonban nem tudja megakadályozni az „ingyenélést” (az orákulum-csomópontok másolnak információt másoktól) és a „lusta validálást” (a többséget követik anélkül, hogy maguk ellenőriznék az információt). - -##### Schelling-pont mechanizmusok - -A [Schelling-pont](https://en.wikipedia.org/wiki/Focal_point_(game_theory)) egy játékelméleti fogalom, amely feltételezi, hogy több entitás mindig egy közös problémamegoldásra jut, ha nincs kommunikáció. A Schelling-pont mechanizmusokat gyakran használják a decentralizált orákulumhálózatokban, hogy a csomópontok konszenzusra jussanak az adatkérésekre adott válaszokkal kapcsolatban. - -Ennek egyik korai ötlete volt a [SchellingCoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/), egy olyan adatfolyam, ahol a résztvevők „skaláris” kérdésekre (melyek nagyságrendekre vonatkoznak, például „mennyi az ETH ára?”) adnak válaszokat, egy letéttel együtt. Azok a felhasználók, akik a 25. és 75. [percentilis](https://en.wikipedia.org/wiki/Percentile) közötti értékeket adnak, jutalomban részesülnek, akiknek az értékei nagymértékben eltérnek a mediánértéktől, büntetést kapnak. - -Bár SchellingCoin ma még nem létezik, számos decentralizált orákulum – nevezetesen a [Maker Protocol's Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module) – használja a schelling-pont mechanizmust az orákulumadatok pontosságának javítására. Minden Maker Oracle csomópont két komponensből áll: a csomópontok („közvetítők” és „ellátók/betáplálók”) láncon kívüli peer-to-peer (P2P) hálózatból, amelyek a biztosítéki eszközök piaci árait megadják, valamint egy láncon belüli „Medianizer” szerződésből, amely kiszámítja a megadott értékek mediánját. A megadott késleltetési időszak lejártával ez a mediánérték lesz a kapcsolódó eszköz új referenciaára. - -További példák a Schelling-pont mechanizmusokat használó orákulumokra: [Chainlink Off-Chain Reporting](https://docs.chain.link/docs/off-chain-reporting/) és [Witnet](https://witnet.io/). Mindkét rendszerben a peer-to-peer hálózat orákulum-csomópontjaitól érkező válaszokat egyetlen összesített értékké, például átlagértékké vagy mediánná aggregálják. A csomópontokat aszerint jutalmazzák vagy büntetik, hogy válaszaik milyen mértékben igazodnak az összesített értékhez vagy térnek el attól. - -A Schelling-pont mechanizmusok azért vonzók, mert minimalizálják a láncon belüli lábnyomot (egy tranzakció kell hozzá), miközben garantálják a decentralizációt. Ez utóbbi azért lehetséges, mert a csomópontoknak alá kell írniuk a benyújtott válaszok listáját, mielőtt az bekerül az átlag/középértéket előállító algoritmusba. - -### Elérhetőség {#availability} - -A decentralizált orákulumszolgáltatások képesek biztosítani az okosszerződéseknek a láncon kívüli adatok magas szintű elérhetőségét. Ehhez decentralizálni kell mind a láncon kívüli információk forrását, mind az információk láncon belüli továbbításáért felelős csomópontokat. - -Ez biztosítja a hibatűrést, mivel az orákulumszerződés több csomópontra támaszkodhat (amelyek több adatforrásra támaszkodnak) a szerződések lekérdezéseinek végrehajtásában. A decentralizáció a forrás _és_ a csomópontüzemeltető szintjén döntő fontosságú – az orákulum-csomópontok hálózata, mely azonos forrásra támaszkodik, ugyanabba a problémába ütközik, mint egy centralizált orákulum. - -A letétalapú orákulumoknál lehetséges súlyos büntetést (slashing) adni a csomópont-üzemeltetőknek, ha nem reagálnak gyorsan az adatkérésekre. Ez jelentősen ösztönzi az orákulum-csomópontokat arra, hogy hibatűrő infrastruktúrába fektessenek, és időben szolgáltassanak adatokat. - -### Jó ösztöntzőkompatibilitás {#good-incentive-compatibility} - -A decentralizált orákulumok különböző ösztönzőket alkalmaznak, hogy megakadályozzák a [bizánci](https://en.wikipedia.org/wiki/Byzantine_fault) viselkedést a orákulum-csomópontok között. Az ösztönzőkompatibilitás magában foglalja a _hozzárendelhetőséget_ és az _elszámoltathatóságot_: - -1. A decentralizált orákulum-csomópontoknak gyakran alá kell írniuk az adatkérésekre adott adatokat. Ez az információ segít az orákulum-csomópontok teljesítményének értékelésében, így a felhasználók adatigényléskor kiszűrhetik a megbízhatatlan szereplőket. Ilyen például a Witnet [Algoritmikus reputációs rendszere (Algorithmic Reputation System)](https://docs.witnet.io/intro/about/architecture#algorithmic-reputation-system). - -2. A decentralizált orákulumok megkövetelhetik a csomópontoktól, hogy az általuk benyújtott adatok helyességét letéttel is alátámasszák. Ha az adatszolgáltatás helyes, ez a letét a szolgálatért járó jutalmakkal együtt visszatérül. De büntetésképpen slashelhető is, ha az információ téves, ami bizonyos fokú elszámoltathatóságot biztosít. - -## Orákulumok alkalmazása az okosszerződésekben {#applications-of-oracles-in-smart-contracts} - -Az Ethereumon használt orákulumok gyakori felhasználási esetei a következők: - -### Pénzügyi adatok lekérdezése {#retrieving-financial-data} - -A [decentralizált pénzügyi](/defi/) (DeFi) alkalmazások lehetővé teszik a peer-to-peer hitelezést, kölcsönzést és az eszközök kereskedelmét. Ehhez gyakran különböző pénzügyi információk beszerzésére van szükség, beleértve az árfolyamadatokat (a kriptovaluták fiat-értékének kiszámításához vagy a tokenárak összehasonlításához) és a tőkepiaci adatokat (a tokenizált eszközök, például az arany vagy az amerikai dollár értékének kiszámításához). - -Egy DeFi kölcsönzési protokollnak például le kell kérdeznie a biztosítékként letétbe helyezett eszközök (például az ETH) aktuális piaci árait. Ez lehetővé teszi, hogy a szerződés meghatározza a fedezeti eszközök értékét, és ezáltal a felvehető kölcsön értékét is. - -A DeFi népszerű „ár-orákulumjai” közé tartozik a Chainlink Price Feeds, a Compound Protocol [Open Price Feed](https://compound.finance/docs/prices), az Uniswap [Time-Weighted Average Prices (TWAPs)](https://docs.uniswap.org/contracts/v2/concepts/core-concepts/oracles) és a [Maker Oracles](https://docs.makerdao.com/smart-contract-modules/oracle-module). - -Az építőknek meg kell érteniük az ezekkel az ár-orákulumokkal járó fenntartásokat, mielőtt beépítenék őket a projektjükbe. Ez a [cikk](https://blog.openzeppelin.com/secure-smart-contract-guidelines-the-dangers-of-price-oracles/) részletes elemzést nyújt arról, hogy mit kell figyelembe venni, ha az említett ár-orákulumok bármelyikét használni szeretnénk. - -Következzen egy példa arra, hogyan lehet lekérdezni a legfrissebb ETH árat az okosszerződésben a Chainlink árakra vonatkozó adatfolyamával: - -```solidity -pragma solidity ^0.6.7; - -import "@chainlink/contracts/src/v0.6/interfaces/AggregatorV3Interface.sol"; - -contract PriceConsumerV3 { - - AggregatorV3Interface internal priceFeed; - - /** - * Network: Kovan - * Aggregator: ETH/USD - * Address: 0x9326BFA02ADD2366b30bacB125260Af641031331 - */ - constructor() public { - priceFeed = AggregatorV3Interface(0x9326BFA02ADD2366b30bacB125260Af641031331); - } - - /** - * Returns the latest price - */ - function getLatestPrice() public view returns (int) { - ( - uint80 roundID, - int price, - uint startedAt, - uint timeStamp, - uint80 answeredInRound - ) = priceFeed.latestRoundData(); - return price; - } -} -``` - -### Ellenőrizhető véletlenszerűség generálása {#generating-verifiable-randomness} - -Bizonyos blokklánc-alkalmazások, mint például a játékok vagy a lottórendszerek, nagyfokú kiszámíthatatlanságot és véletlenszerűséget igényelnek a hatékony működéshez. A blokkláncok determinisztikus végrehajtása azonban kiküszöböli a véletlenszerűséget. - -Az eredeti megközelítés az álvéletlenszerű kriptográfiai függvények használata volt, mint például a `blockhash`, de ezeket [manipulálhatták a bányászok](https://ethereum.stackexchange.com/questions/3140/risk-of-using-blockhash-other-miners-preventing-attack#:~:text=So%20while%20the%20miners%20can,to%20one%20of%20the%20players.) a proof-of-work algoritmust megoldva. Továbbá, az Ethereum [proof-of-stake mechanizmusra való átváltása](/roadmap/merge/) azt jelenti, hogy a fejlesztők többé nem támaszkodhatnak a `blockhash`-re a láncon belüli véletlenszerűség tekintetében. A Beacon-lánc [RANDAO mechanizmusa](https://eth2book.info/altair/part2/building_blocks/randomness) azonban alternatív véletlenszerűségi forrást biztosít. - -Lehetséges a véletlen értéket a láncon kívül generálni és a láncon belül elküldeni, de ez nagy bizalmi követelményeket támaszt a felhasználókkal szemben. Azt kell hinniük, hogy az érték valóban kiszámíthatatlan mechanizmusok révén jött létre, és nem változott meg az átadás során. - -A láncon kívüli számításhoz tervezett orákulumok úgy oldják meg ezt a problémát, hogy biztonságosan generálnak véletlenszerű eredményeket, amelyeket a folyamat kiszámíthatatlanságát igazoló kriptográfiai bizonyítékokkal együtt továbbítanak a láncon belülre. Ilyen például a [Chainlink VRF](https://docs.chain.link/docs/chainlink-vrf/) (Igazolható véletlenfüggvény/Verifiable Random Function), amely egy bizonyíthatóan igazságos és hamisításbiztos véletlenszám-generátor (RNG), hogy a kiszámíthatatlan eredményekre támaszkodó alkalmazásokhoz megbízható okosszerződéseket lehessen létrehozni. Egy másik példa az [API3 QRNG](https://docs.api3.org/explore/qrng/), amely a kvantum véletlenszám-generálást (QRNG) szolgálja ki, egy kvantumjelenségeken alapuló, Web3 RNG nyilvános módszert, amelyet az Ausztrál Nemzeti Egyetem (ANU) által elérhető. - -### Az események eredményeinek elérése {#getting-outcomes-for-events} - -Az orákulumok segítségével könnyű olyan okosszerződéseket létrehozni, amelyek valós eseményekre reagálnak. Az orákulumszolgáltatások ezt azáltal teszik lehetővé, hogy a szerződések külső API-okhoz kapcsolódhatnak a láncon kívüli komponenseken keresztül, és információkat vehetnek ezekből az adatforrásokból. Például a korábban említett előrejelző alkalmazás kérhet egy orákulumot, hogy küldje vissza a választási eredményeket egy megbízható, láncon kívüli forrásból (például az Associated Presstől). - -Az orákulumok valós adatok lekérdezésére való használata újszerű felhasználási területeket tesz lehetővé; például egy decentralizált biztosítási terméknek pontos információkra van szüksége az időjárásról, katasztrófákról stb. a hatékony működéshez. - -### Okosszerződések automatizálása {#automating-smart-contracts} - -Az okosszerződések nem futnak automatikusan, hanem egy externally owned account (EOA), azaz külső tulajdonú számlának vagy egy másik szerződéses számlának kell elindítania a funkciókat a szerződéskód végrehajtásához. A legtöbb esetben a szerződésfunkciók nagy része nyilvános, és az EOA-k és más szerződések által meghívhatók. - -De vannak olyan _privát funkciók_ is egy szerződésen belül, amelyek mások számára elérhetetlenek, de kritikusak a dapp általános funkcionalitása szempontjából. Ilyen lehet például egy `mintERC721Token()` függvény, amely rendszeresen új NFT-ket készít a felhasználók számára, egy függvény a kifizetések odaítélésére egy előrejelzési piacon, vagy egy függvény a feltett tokenek feloldására egy DEX-en. - -A fejlesztőknek időközönként ilyen funkciókat kell indítaniuk, hogy az alkalmazás zökkenőmentesen működjön. Ez azonban azt eredményezheti, hogy a fejlesztők több órát veszítenek a hétköznapi feladatokkal, ezért fontos az okosszerződések végrehajtásának automatizálása. - -Egyes decentralizált orákulumhálózatok automatizálási szolgáltatásokat kínálnak, amelyek lehetővé teszik a láncon kívüli orákulum-csomópontok számára, hogy a felhasználó által meghatározott paraméterek alapján okosszerződés-funkciókat indítsanak el. Ehhez általában „regisztrálni” kell a célszerződést az orákulumszolgáltatásnál, pénzeszközöket kell biztosítani az orákulumüzemeltető kifizetéséhez, és meg kell határozni a szerződést kiváltó feltételeket vagy időpontokat. - -A Chainlink [Keeper Network](https://chain.link/keepers) lehetőséget biztosít az okosszerződések számára a rendszeres karbantartási feladatok minimális bizalomigényű és decentralizált módon történő kiszervezésére. Tekintse meg a hivatalos [Keeper-dokumentációt](https://docs.chain.link/docs/chainlink-keepers/introduction/) a szerződés Keeper-kompatibilissé tételével és az Upkeep-szolgáltatással kapcsolatos információkért. - -## Hogyan használjuk a blokkláncorákulumokat {#use-blockchain-oracles} - -Többféle orákulumalkalmazást is integrálhat az Ethereum dappba: - -**[Chainlink](https://chain.link/)** – _A Chainlink decentralizált orákulumhálózatok hamisításbiztos bemeneteket, kimeneteket és számításokat biztosítanak a fejlett okosszerződések támogatásához bármely blokkláncon._ - -**[Chronicle](https://chroniclelabs.org/)** - _A Chronicle megoldja a láncon belüli adatátvitel jelenlegi korlátait azáltal, hogy valóban skálázható, költséghatékony, decentralizált és ellenőrizhető orákulumokat készít._ - -**[Witnet](https://witnet.io/)** – _A Witnet egy engedély nélküli, decentralizált és cenzúrának ellenálló orákulum, amely segíti az okosszerződéseket, hogy erős kriptogazdasági garanciákkal reagáljanak a valós világ eseményeire._ - -**[UMA Oracle](https://uma.xyz)** – _Az UMA optimista orákulum lehetővé teszi, hogy az okosszerződések gyorsan, mindenféle adatot megkapjanak különböző alkalmazásokhoz, beleértve a biztosítási, pénzügyi derivatívákat és előrejelzési piacokat._ - -**[Tellor](https://tellor.io/)** – _A Tellor egy átlátható és engedély nélküli orákulumprotokoll az okosszerződések számára, hogy könnyedén hozzájusson bármilyen adathoz, amikor csak szükség van rá._ - -**[Band Protocol](https://bandprotocol.com/)** – _A Band Protocol egy láncokon átívelő adatorákulum-platform, amely valós adatokat és API-okat aggregál és kapcsol össze okosszerződésekkel._ - -**[Paralink](https://paralink.network/)** – _A Paralink nyílt forráskódú és decentralizált orákulumplatformot biztosít az Ethereumon és más népszerű blokkláncokon futó okosszerződésekhez._ - -**[Pyth Network](https://pyth.network/)** – _A Pyth hálózat egy olyan pénzügyi orákulumhálózat, amely első kézből szerez információt, és folyamatosan valós adatokat tesz közzé a láncon belül egy hamisításnak ellenálló, decentralizált és önfenntartó környezetben._ - -**[API3 DAO](https://www.api3.org/)** – _Az API3 DAO olyan, első féltől származó orákulummegoldásokat kínál, amelyek nagyobb forrásátláthatóságot, biztonságot és skálázhatóságot biztosítanak egy decentralizált megoldásában az okosszerződések számára._ - -**[Supra](https://supra.com/)** - Egy vertikálisan integrált eszközrendszer a láncok közötti megoldások számára, amely összekapcsolja az összes blokkláncot, legyen az publikus (L1-ek és L2-k) vagy privát (vállalati), decentralizáltorákulum-árfolyamadatokat biztosítva, melyet láncon belüli és kívüli projektek is használhatnak. - -## További olvasnivaló {#further-reading} - -**Cikkek** - -- [Mi az a blokkláncorákulum?](https://chain.link/education/blockchain-oracles) – _Chainlink_ -- [Mi az a blokkláncorákulum?](https://betterprogramming.pub/what-is-a-blockchain-oracle-f5ccab8dbd72) – _Patrick Collins_ -- [Decentralizált orákulumok: részletes áttekintés](https://medium.com/fabric-ventures/decentralised-oracles-a-comprehensive-overview-d3168b9a8841) – _Julien Thevenard_ -- [Blokkláncorákulum bevezetése az Ethereumon](https://medium.com/@pedrodc/implementing-a-blockchain-oracle-on-ethereum-cedc7e26b49e) – _Pedro Costa_ -- [Az okosszerződések miért nem tudnak API-hívásokat kezdeményezni?](https://ethereum.stackexchange.com/questions/301/why-cant-contracts-make-api-calls) – _StackExchange_ -- [Miért van szükség decentralizált orákulumokra](https://newsletter.banklesshq.com/p/why-we-need-decentralized-oracles) – _Bankless_ -- [Tehát Ön egy ár-orákulumot szeretne használni](https://samczsun.com/so-you-want-to-use-a-price-oracle/) – _samczsun_ - -**Videók** - -- [Orákulumok és a blokklánc-használat kiterjesztése](https://youtu.be/BVUZpWa8vpw) – _Real Vision Finance_ -- [A különbség az orákulumok között az első kézből vagy harmadik féltől szerezett adatok tekintetében](https://blockchainoraclesummit.io/first-party-vs-third-party-oracles/) – _Blockchain Oracle Summit_ - -**Oktatóanyagok** - -- [Hogyan lehet lekérni az Ethereum aktuális árát a Solidityben?](https://blog.chain.link/fetch-current-crypto-price-data-solidity/) – _Chainlink_ -- [Orákulumadat felhasználása](https://docs.chroniclelabs.org/Developers/tutorials/Remix) — _Chronicle_ - -**Példaprojektek** - -- [Teljes Chainlink kezdőprojekt az Ethereumra Solidity nyelven](https://github.com/hackbg/chainlink-fullstack) – _HackBG_ diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/index.md deleted file mode 100644 index b98e7822867..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/index.md +++ /dev/null @@ -1,59 +0,0 @@ ---- -title: Ethereum fejlesztési szabványok -description: -lang: hu -incomplete: true ---- - -## Szabványok áttekintése {#standards-overview} - -Az Ethereum közösség sok szabványt vezetett be, hogy a projektek (mint az [Ethereum kliensek](/developers/docs/nodes-and-clients/) és tárcák) interoperábilisek maradjanak különböző megvalósításokban, és biztosítsák, hogy az okosszerződések és a dappok összeilleszthetőek maradnak. - -Általában a szabványok [Ethereum-fejlesztési javaslatokként](/eips/) (EIP) kerülnek bevezetésre, melyeket a közösség tagjai vitatnak meg egy [sztenderd folyamat](https://eips.ethereum.org/EIPS/eip-1) során. - -- [Bevezetés az EIP-kbe](/eips/) -- [EIP-k listája](https://eips.ethereum.org/) -- [EIP GitHub mappa](https://github.com/ethereum/EIPs) -- [EIP vitafórum](https://ethereum-magicians.org/c/eips) -- [Bevezetés az Ethereum irányításába](/governance/) -- [Az Ethereum irányításának áttekintése](https://web.archive.org/web/20201107234050/https://blog.bmannconsulting.com/ethereum-governance/) _2019. március 31., Boris Mann_ -- [Ethereum protokollfejlesztés-irányítás és hálózatfrissítés-koordináció](https://hudsonjameson.com/2020-03-23-ethereum-protocol-development-governance-and-network-upgrade-coordination/) _2020. március 23., Hudson Jameson_ -- [Lejátszási lista az Ethereum protokollfejlesztőinek megbeszéléseiről](https://www.youtube.com/@EthereumProtocol) _(YouTube lejátszási lista)_ - -## Szabványtípusok {#types-of-standards} - -Az EIP-k 3 típusa: - -- Szabványok listája: minden olyan változást leír, amely a legtöbb vagy az összes Ethereum-implementációt érinti -- [Meta lista](https://eips.ethereum.org/meta): egy Ethereumhoz kapcsolódó folyamat leírása, vagy javaslat egy folyamat megváltoztatására -- [Információs lista](https://eips.ethereum.org/informational): egy Ethereum-tervezési problémát ír le, vagy általános iránymutatásokat nyújt az Ethereum közössége számára - -A szabványok listáját 4 kategóriára lehet felosztani: - -- [Központi](https://eips.ethereum.org/core): konszenzuselágazást igénylő fejlesztések -- [Hálózat](https://eips.ethereum.org/networking): fejlesztések a devp2p és a Light Ethereum alprotokoll körül, valamint javasolt fejlesztések a whisper és a swarm hálózati protokollspecifikációkhoz. -- [Interfész](https://eips.ethereum.org/interface): fejlesztések az ügyfél API/RPC specifikációk és szabványok, valamint bizonyos nyelvi szintű szabványok, például a metódusnevek és a szerződés ABI-k körül. -- [ERC](https://eips.ethereum.org/erc): alkalmazási szintű szabványok és konvenciók - -A különböző típusokról és kategóriákról részletesebb információ az [EIP-1](https://eips.ethereum.org/EIPS/eip-1#eip-types) dokumentumban található - -### Token szabványok {#token-standards} - -- [ERC-20](/developers/docs/standards/tokens/erc-20/) – Egy sztenderd interfész a helyettesíthető (cserélhető) tokenekhez, például a szavazási és letéti tokenekhez vagy a virtuális valutákhoz. - - [ERC-223](/developers/docs/standards/tokens/erc-223/) - Egy helyettesíthető tokenszabvány, melynek révén a tokenek az etherrel azonosan működnek, és támogatja a tokenküldés kezelését a fogadó oldalán. - - [ERC-1363](https://eips.ethereum.org/EIPS/eip-1363) – Egy tokeninterfészt határoz meg az ERC-20 tokenek számára, amely támogatja a címzett kód végrehajtását a transfer vagy transferFrom után, illetve a feladó kódját a jóváhagyás után. -- [ERC-721](/developers/docs/standards/tokens/erc-721/) – Egy sztenderd interfész a nem helyettesíthető tokenekhez, például egy műalkotásról szóló okirathoz vagy egy dalhoz. - - [ERC-2309](https://eips.ethereum.org/EIPS/eip-2309) – Egy szabványosított esemény, amelyet egy vagy több, egymást követő tokenazonosítókat használó, nem helyettesítő token létrehozásakor/átadásakor bocsátanak ki. - - [ERC-4400](https://eips.ethereum.org/EIPS/eip-4400) – Az EIP-721 fogyasztói szerepkör interfészbővítése. - - [ERC-4907](https://eips.ethereum.org/EIPS/eip-4907) – Korlátozott jogosultságú, időben korlátozott szerepkör hozzáadása az ERC-721 tokenekhez. -- [ERC-777](/developers/docs/standards/tokens/erc-777/) – **(NEM AJÁNLOTT)** Az ERC-20-hoz képest továbbfejlesztett tokenszabvány. -- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) – Olyan tokenszabvány, amely egyaránt tartalmazhat helyettesíthető és nem helyettesíthető eszközöket. -- [ERC-4626](/developers/docs/standards/tokens/erc-4626/) – A tokenizált trezorok technikai paramétereinek optimalizálására és egységesítésére tervezett tokenizált trezorszabvány. - -Tudjon meg többet a [tokenszabványokról](/developers/docs/standards/tokens/). - -## További olvasnivaló {#further-reading} - -- [Ethereum Fejlesztési Javaslatok (EIP-k)](/eips/) - -_Ismersz olyan közösségi anyagot, amely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md deleted file mode 100644 index 68404126db9..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-1155/index.md +++ /dev/null @@ -1,146 +0,0 @@ ---- -title: ERC-1155 Multitoken szabvány -description: -lang: hu ---- - -## Bevezetés {#introduction} - -Egy sztenderd interfész olyan szerződésekhez, amelyek többféle tokentípust kezelnek. Egy telepített szerződés tartalmazhatja helyettesíthető és nem helyettesíthető tokenek vagy más konfigurációk (például félig helyettesíthető tokenek) bármilyen kombinációját. - -**Mit jelent a multitoken szabvány?** - -Az ötlet egyszerű, és egy olyan okosszerződéses interfész létrehozására irányul, amely bármilyen számú helyettesíthető és nem helyettesíthető tokentípust képes reprezentálni és irányítani. Ily módon az ERC-1155 token ugyanazokat a funkciókat tudja ellátni, mint egy [ERC-20](/developers/docs/standards/tokens/erc-20/) és [ERC-721](/developers/docs/standards/tokens/erc-721/) token, sőt mindkettő egyszerre. Javítja az ERC-20 és ERC-721 szabványok működését, hatékonyabbá teszi és kijavítja a nyilvánvaló végrehajtási hibákat. - -Az ERC-1155 token teljes körű leírását az [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155) tartalmazza. - -## Előfeltételek {#prerequisites} - -Az oldal jobb megértéséhez javasoljuk, hogy először olvassa el a [tokenszabványok](/developers/docs/standards/tokens/), [ERC-20](/developers/docs/standards/tokens/erc-20/) és [ERC-721](/developers/docs/standards/tokens/erc-721/) nevű dokumentumokat. - -## ERC-1155 funkciók és jellemzők: {#body} - -- [Csoportos transzfer](#batch_transfers): Több eszköz átvitele egyetlen hívással. -- [Csoportos egyenleglehívás](#batch_balance): Több eszköz egyenlegének lekérdezése egyetlen hívással. -- [Csoportos jóváhagyás](#batch_approval): Az összes token jóváhagyása egy címre. -- [Hook-ok](#receive_hook): Token-hook-ok fogadása. -- [NFT támogatás](#nft_support): Ha a kínálat csak 1, kezelje NFT-ként. -- [Biztonságos átviteli szabályok](#safe_transfer_rule): Szabályok a biztonságos átvitelre. - -### Csoportos transzferek {#batch-transfers} - -A csoportos transzfer nagyon hasonlóan működik, mint a hagyományos ERC-20-transzfer. Nézzük meg a normál ERC-20 `transferFrom` funkciót: - -```solidity -// ERC-20 -function transferFrom(address from, address to, uint256 value) external returns (bool); - -// ERC-1155 -function safeBatchTransferFrom( - address _from, - address _to, - uint256[] calldata _ids, - uint256[] calldata _values, - bytes calldata _data -) external; -``` - -Az egyetlen különbség az ERC-1155-ben az, hogy az értékeket tömbként adjuk át, és az azonosítók tömbjét is átadjuk. Például `ids=[3, 6, 13]` és `values=[100, 200, 5]` esetén a kapott átutalások a következők lesznek: - -1. 100 darab 3-as azonosítójú token átvitele `_from` helyről `_to` helyre. -2. 200 darab 6-os azonosítójú token átvitele `_from` helyről `_to` helyre. -3. 5 darab 13-as azonosítójú token átvitele `_from` helyről `_to` helyre. - -Az ERC-1155-ben csak `transferFrom` van, `transfer` nincs. Ha normál `transfer` módjára akarja használni, csak állítsa be a „from” címet a függvényt hívó címre. - -### Csoportos egyenleglehívás {#batch-balance} - -A megfelelő ERC-20 `balanceOf` hívás szintén rendelkezik csoportos támogatású partnerfunkcióval. Emlékeztetőül, ez az ERC-20-as verzió: - -```solidity -// ERC-20 -function balanceOf(address owner) external view returns (uint256); - -// ERC-1155 -function balanceOfBatch( - address[] calldata _owners, - uint256[] calldata _ids -) external view returns (uint256[] memory); -``` - -Még egyszerűbb az egyenleghívásnál, hogy egyetlen hívással több egyenleget is lekérdezhetünk. Átadjuk a tulajdonosok tömbjét, majd a tokenazonosítók tömbjét. - -Ha például `_ids=[3, 6, 13]` és `_owners=[0xbeef..., 0x1337..., 0x1111...]`, a visszatérési érték a következő lesz: - -```solidity -[ - balanceOf(0xbeef...), - balanceOf(0x1337...), - balanceOf(0x1111...) -] -``` - -### Csoportos jóváhagyás {#batch-approval} - -```solidity -// ERC-1155 -function setApprovalForAll( - address _operator, - bool _approved -) external; - -function isApprovedForAll( - address _owner, - address _operator -) external view returns (bool); -``` - -A jóváhagyások némileg eltérnek az ERC-20-tól. Konkrét összegek jóváhagyása helyett a `setApprovalForAll` segítségével állíthat be egy jóváhagyási vagy nem jóváhagyási műveletet. - -Az aktuális státusz leolvasása az `isApprovedForAll` segítségével történhet. Amint látja, ez egy mindent vagy semmit művelet. Nem határozhatja meg, hogy hány tokent hagyjon jóvá, és azt sem, hogy melyik tokenosztályt hagyja jóvá. - -Ezt szándékosan az egyszerűség jegyében tervezték. Egy címre vonatkozóan hagyhat jóvá mindent. - -### Hook fogadása {#receive-hook} - -```solidity -function onERC1155BatchReceived( - address _operator, - address _from, - uint256[] calldata _ids, - uint256[] calldata _values, - bytes calldata _data -) external returns(bytes4); -``` - -Tekintettel az [EIP-165](https://eips.ethereum.org/EIPS/eip-165) támogatásra, az ERC-1155 csak az okosszerződésekre vonatkozó hook-okat fogadja. A hook-függvénynek egy mágikus, előre definiált bytes4-értéket kell visszaadnia, amely a következő formában van megadva: - -```solidity -bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) -``` - -Ha a fogadó szerződés visszaküldi ezt az értéket, akkor feltételezzük, hogy a szerződés elfogadja az átutalást, és tudja, hogyan kell kezelni az ERC-1155 tokeneket. Remek, nincs többé szerződésbe ragadt token! - -### NFT-támogatás {#nft-support} - -Ha a kínálat csak egy darab, akkor a token lényegében egy nem helyettesíthető token (NFT). Az ERC-721 szabványának megfelelően meghatározhat egy metaadat URL-címet is. Az ügyfelek képesek az URL-t olvasni és módosítani, ennek módját [itt](https://eips.ethereum.org/EIPS/eip-1155#metadata) tekintheti meg. - -### Biztonságos átutalási szabály {#safe-transfer-rule} - -Az előző magyarázatokban már érintettünk néhány biztonságos átutalási szabályt. De nézzük a szabályok közül a legfontosabbat: - -1. A hívónak engedélyeznie kell a `_from` címre vonatkozó tokenek elköltését, vagy a hívónak meg kell egyeznie a `_from` címmel. -2. Az átutalási hívásnak vissza kell fordulnia, ha - 1. a `_to` címe 0. - 2. az `_ids` hossza nem azonos a `_values` hosszával. - 3. az `_ids` paraméterben szereplő token(ek) birtokosának bármelyik egyenlege alacsonyabb, mint a `_values` paraméterben szereplő, a címzettnek küldött megfelelő összeg(ek). - 4. bármilyen más hiba előfordul. - -_Megjegyzés_: Minden csoportos funkció, beleértve a hook-ot is, egyéni változatban is létezik. Ez a gázhatékonyság érdekében történik, tekintve, hogy valószínűleg csak egy eszköz átadása lesz a leggyakrabban használt módszer. Ezeket az egyszerűség kedvéért kihagytuk a magyarázatokból, beleértve a biztonságos átutalási szabályokat is. A nevek megegyeznek, csak a „Batch” szót kell eltávolítani. - -## További olvasnivaló {#further-reading} - -- [ERC-1155: Multitoken szabvány](https://eips.ethereum.org/EIPS/eip-1155) -- [ERC-1155: Openzeppelin-dokumentációk](https://docs.openzeppelin.com/contracts/3.x/erc1155) -- [ERC-1155: GitHub mappa](https://github.com/enjin/erc-1155) -- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md deleted file mode 100644 index 6f2bec84ebe..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-20/index.md +++ /dev/null @@ -1,172 +0,0 @@ ---- -title: ERC-20 Tokenszabvány -description: -lang: hu ---- - -## Bevezetés {#introduction} - -**Mi is az a token?** - -A tokenek gyakorlatilag bármit képviselhetnek az Ethereumon: - -- reputációs pontokat egy online platformon -- egy karakter képességeit egy játékban -- pénzügyi eszközöket, mint például részesedést egy cégben -- fiat valutát, mint az USD -- egy uncia aranyat -- és még sok mást... - -Egy ilyen erős Ethereum funkciót egy szintén erős szabványnak kell kezelnie, igaz? És pontosan itt jön képbe az ERC-20 szerepe! Ez a szabvány lehetővé teszi a fejlesztők számára, hogy olyan tokenalkalmazásokat fejlesszenek, amelyek együttműködnek más termékekkel és szolgáltatásokkal. Az ERC-20 szabványt arra is használják, hogy további funkciókat biztosítsanak az [ether](/glossary/#ether) számára. - -**Mi az az ERC-20?** - -Az ERC-20 bevezeti a helyettesíthető tokenekre vonatkozó szabványt, vagyis minden egyes token pontosan ugyanaz (típusban és értékben), mint egy másik. Például egy ERC-20 token úgy viselkedik, mint az ETH, vagyis 1 token egyenlő és egyenlő is marad az összes többi tokennel. - -## Előfeltételek {#prerequisites} - -- [Számlák](/developers/docs/accounts) -- [Okosszerződések](/developers/docs/smart-contracts/) -- [Token szabványok](/developers/docs/standards/tokens/) - -## Törzs {#body} - -Az ERC-20 (Ethereum Request for Comments 20), melyet Fabian Vogelsteller javasolt 2015. novemberében, egy tokenszabvány, mely egy API-t implementál a tokenek számára az okosszerződéseken belül. - -Az ERC-20 által biztosított funkciók például: - -- tokenek átutalása egyik számláról a másikra -- egy számla aktuális tokenegyenlegének lekérdezése -- a hálózaton rendelkezésre álló tokenek teljes készlete -- jóváhagyja, hogy egy számláról származó token összegét elköltheti-e egy másik számla - -Ha egy okosszerződés implementálja a következő metódusokat és eseményeket, akkor egy ERC-20 tokenszerződésnek lehet nevezni, és a telepítés után a létrejött tokenek számontartásáért lesz felelős az Ethereumon. - -Az [EIP-20-ból](https://eips.ethereum.org/EIPS/eip-20): - -### Metódusok {#methods} - -```solidity -function name() public view returns (string) -function symbol() public view returns (string) -function decimals() public view returns (uint8) -function totalSupply() public view returns (uint256) -function balanceOf(address _owner) public view returns (uint256 balance) -function transfer(address _to, uint256 _value) public returns (bool success) -function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) -function approve(address _spender, uint256 _value) public returns (bool success) -function allowance(address _owner, address _spender) public view returns (uint256 remaining) -``` - -### Események {#events} - -```solidity -event Transfer(address indexed _from, address indexed _to, uint256 _value) -event Approval(address indexed _owner, address indexed _spender, uint256 _value) -``` - -### Példák {#web3py-example} - -Nézzük meg, miért olyan fontos egy szabvány, hogy egyszerűbbé tegye számunkra azt, hogy bármely ERC-20 tokenszerződést megtekinthessük az Ethereumon. Csak a szerződés Alkalmazás bináris interfészére (ABI) lesz szükség, hogy egy felületet készítsünk bármely ERC-20 tokennek. Ahogy lentebb láthatja, egy egyszerűsített ABI-t használunk, hogy egyszerűbb példával éljünk. - -#### Web3.py példa {#web3py-example} - -Először győződjön meg arról, hogy a [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python könyvtár telepítve van: - -``` -pip install web3 -``` - -```python -from web3 import Web3 - - -w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) - -dai_token_addr = "0x6B175474E89094C44Da98b954EedeAC495271d0F" # DAI -weth_token_addr = "0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2" # Wrapped ether (WETH) - -acc_address = "0xA478c2975Ab1Ea89e8196811F51A7B7Ade33eB11" # Uniswap V2: DAI 2 - -# Ez egy ERC-20 token szerződés egyszerűsített Application Binary Interface-e (ABI). -# It will expose only the methods: balanceOf(address), decimals(), symbol() and totalSupply() -simplified_abi = [ - { - 'inputs': [{'internalType': 'address', 'name': 'account', 'type': 'address'}], - 'name': 'balanceOf', - 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], - 'stateMutability': 'view', 'type': 'function', 'constant': True - }, - { - 'inputs': [], - 'name': 'decimals', - 'outputs': [{'internalType': 'uint8', 'name': '', 'type': 'uint8'}], - 'stateMutability': 'view', 'type': 'function', 'constant': True - }, - { - 'inputs': [], - 'name': 'symbol', - 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], - 'stateMutability': 'view', 'type': 'function', 'constant': True - }, - { - 'inputs': [], - 'name': 'totalSupply', - 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], - 'stateMutability': 'view', 'type': 'function', 'constant': True - } -] - -dai_contract = w3.eth.contract(address=w3.to_checksum_address(dai_token_addr), abi=simplified_abi) -symbol = dai_contract.functions.symbol().call() -decimals = dai_contract.functions.decimals().call() -totalSupply = dai_contract.functions.totalSupply().call() / 10**decimals -addr_balance = dai_contract.functions.balanceOf(acc_address).call() / 10**decimals - -# DAI -print("===== %s =====" % symbol) -print("Total Supply:", totalSupply) -print("Addr Balance:", addr_balance) - -weth_contract = w3.eth.contract(address=w3.to_checksum_address(weth_token_addr), abi=simplified_abi) -symbol = weth_contract.functions.symbol().call() -decimals = weth_contract.functions.decimals().call() -totalSupply = weth_contract.functions.totalSupply().call() / 10**decimals -addr_balance = weth_contract.functions.balanceOf(acc_address).call() / 10**decimals - -# WETH -print("===== %s =====" % symbol) -print("Total Supply:", totalSupply) -print("Addr Balance:", addr_balance) -``` - -## Ismert problémák {#erc20-issues} - -### ERC-20-token-elfogadási problémák {#reception-issue} - -Amikor ERC-20 tokeneket küldenek olyan okosszerződésbe, amely nem tudja azokat kezelni, akkor ezek végleg elvesznek. Ennek az az oka, hogy a befogadó szerződésnek nincs olyan funkcionalitása, hogy felismerje vagy válaszoljon a bejövő tokenekre, és nincs olyan mechanizmus az ERC-20-szabványban, ami figyelmeztetné a szerződést az érkező tokenekről. Ez a probléma a következő módokon nyilvánul meg: - -1. Tokenátviteli mechanizmus - - Az ERC-20 tokeneket a transfer vagy a transferFrom függvényekkel lehet küldeni - - Amikor a felhasználó tokeneket küld egy szerződéscímre ezekkel a függvényekkel, a tokenek elmennek attól függetlenül, hogy a szerződés képes-e azokat fogadni -2. A figyelmeztetés hiánya - - A befogadó szerződés nem kap figyelmeztetést vagy visszahívást, hogy tokenek érkeztek hozzá - - Ha a befogadó szerződés nem tud tokeneket kezelni (például nincs egy fallback függvény vagy egy dedikált függvény, ami a tokent fogadná), akkor a tokenek beragadnak a szerződés címén -3. Nincs beépített kezelés - - Az ERC-20 szabvány nem köti ki a kötelező funkciót a befogadó szerződésnek, ezért számos szerződés képtelen a beérkező tokenek megfelelő kezelésére - -Néhány alternatív szabvány létezik ennek a problémának a kezelésére, mint az [ERC-223](/developers/docs/standards/tokens/erc-223) - -## További olvasnivaló {#further-reading} - -- [EIP-20: ERC-20 tokenszabvány](https://eips.ethereum.org/EIPS/eip-20) -- [OpenZeppelin – Tokenek](https://docs.openzeppelin.com/contracts/3.x/tokens#ERC20) -- [OpenZeppelin – ERC-20-implementáció](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol) -- [Alchemy – Útmutató a Solidity ERC-20 tokenekhez](https://www.alchemy.com/overviews/erc20-solidity) - - -## További helyettesíthető tokenekről szóló szabványok {#fungible-token-standards} - -- [ERC-223](/developers/docs/standards/tokens/erc-223) -- [ERC-777](/developers/docs/standards/tokens/erc-777) -- [ERC-4626 - Tokenizált értékmegőrzőre vonatkozó szabvány](/developers/docs/standards/tokens/erc-4626) \ No newline at end of file diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md deleted file mode 100644 index a779631bcb6..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-223/index.md +++ /dev/null @@ -1,197 +0,0 @@ ---- -title: ERC-223 tokenszabvány -description: Az ERC-223 helyettesíthető tokenszabvány áttekintése, működése és az ERC-20-szal való összevetése. -lang: hu ---- - -## Bevezetés {#introduction} - -### Mi az az ERC-223? {#what-is-erc223} - -ERC-223 a helyettesíthető tokenek szabványa, amely hasonlít az ERC-20-hoz. A fő különbség az, hogy az ERC-223 nemcsak a token API-t adja meg, hanem a küldési logikát is a küldő és a fogadó között. Egy kommunikációs modellt vezet be, amely alapján a fogadó képes kezelni a token fogadását. - -### Eltérések az ERC-20-hoz képest {#erc20-differences} - -Az ERC-223 kezeli az ERC-20 néhány korlátját, és egy új interakciós módszert vezet be a tokenszerződés és a tokent befogadó szerződés között. Néhány dolog lehetséges az ERC-223-mal, de az ERC-20-szal nem: - -- A tokenküldés kezelése a fogadó oldalán: a fogadó fél képes követni, hogy egy ERC-223-as token érkezett. -- A helytelenül küldött tokenek elutasítása: ha a felhasználó ERC-223-as tokent küld egy szerződésnek, amely nem fogad tokeneket, akkor el tudja utasítani azt, így nem veszik el. -- Metaadatok a küldés során: az ERC-223 token metaadatokat is tartalmaz, így bármilyen információt át lehet adni a tokenküldésnél. - -## Előfeltételek {#prerequisites} - -- [Számlák](/developers/docs/accounts) -- [Okosszerződések](/developers/docs/smart-contracts/) -- [Tokenszabványok](/developers/docs/standards/tokens/) -- [ERC-20](/developers/docs/standards/tokens/erc-20/) - -## Törzs {#body} - -Az ERC-223 egy tokenszabvány, ami API-t implementál a tokeneknek az okosszerződésekben. Emellett API-t határoz meg azoknak a szerződéseknek, melyek ERC-223 tokent fogadnak be. Azok a szerződések, amelyek nem támogatják az ERC-223-at befogadó API-t, nem fogadhatnak ilyen tokent, így megakadályozzák a hibát. - -Ha az okosszerződés implementálja a következő metódusokat és eseményeket, akkor egy ERC-223-kompatibilis tokenszerződésnek nevezhető. Amint telepítve van, trekkelnie kell a létrehozott tokeneket az Ethereumon. - -A szerződésnek nem kell csak ilyen funkciókkal bírnia, a fejlesztő más jellemzőket is használhat a többi tokenszabványból is. Például az „approve” és a „transferFrom” függvények nincsenek benne az ERC-223 szabványban, de implementálhatók. - -[EIP-223-ból](https://eips.ethereum.org/EIPS/eip-223): - -### Metódusok {#methods} - -Az ERC-223 tokennek a következő metódusokat kell implementálnia: - -```solidity -function name() public view returns (string) -function symbol() public view returns (string) -function decimals() public view returns (uint8) -function totalSupply() public view returns (uint256) -function balanceOf(address _owner) public view returns (uint256 balance) -function transfer(address _to, uint256 _value) public returns (bool success) -function transfer(address _to, uint256 _value, bytes calldata _data) public returns (bool success) -``` - -A szerződésnek, mely ERC-223 tokent fogad be, a következő metódusokat kell implementálnia: - -```solidity -function tokenReceived(address _from, uint _value, bytes calldata _data) -``` - -Ha ERC-223 tokent küldenek egy olyan szerződésnek, amely nem implementálja a „tokenReceived(..)” függvényt, akkor az átadás elbukik és a token nem hagyja el a küldőt. - -### Események {#events} - -```solidity -event Transfer(address indexed _from, address indexed _to, uint256 _value, bytes calldata _data) -``` - -### Példák {#examples} - -Az ERC-223 token API-ja hasonlít az ERC-20-ashoz, ezért felhasználóifelület-fejlesztés szempontból nincs különbség. Az egyetlen kivételaz, hogy az ERC-223 tokenek nem ismerik az „approve” + „transferFrom” függvényeket, mert ezek opcionálisak. - -#### Solidity-példák {#solidity-example} - -A következő példa bemutatja, hogyan működik egy alap ERC-223 tokenszerződés: - -```solidity -pragma solidity ^0.8.19; -abstract contract IERC223Recipient { - function tokenReceived(address _from, uint _value, bytes memory _data) public virtual; -} -contract VeryBasicERC223Token { - event Transfer(address indexed from, address indexed to, uint value, bytes data); - string private _name; - string private _symbol; - uint8 private _decimals; - uint256 private _totalSupply; - mapping(address => uint256) private balances; - function name() public view returns (string memory) { return _name; } - function symbol() public view returns (string memory) {return _symbol; } - function decimals() public view returns (uint8) { return _decimals; } - function totalSupply() public view returns (uint256) { return _totalSupply; } - function balanceOf(address _owner) public view returns (uint256) { return balances[_owner]; } - function isContract(address account) internal view returns (bool) { - uint256 size; - assembly { size := extcodesize(account) } - return size > 0; - } - function transfer(address _to, uint _value, bytes calldata _data) public returns (bool success){ - balances[msg.sender] = balances[msg.sender] - _value; - balances[_to] = balances[_to] + _value; - if(isContract(_to)) { - IERC223Recipient(_to).tokenReceived(msg.sender, _value, _data); - } - emit Transfer(msg.sender, _to, _value, _data); - return true; - } - function transfer(address _to, uint _value) public returns (bool success){ - bytes memory _empty = hex"00000000"; - balances[msg.sender] = balances[msg.sender] - _value; - balances[_to] = balances[_to] + _value; - if(isContract(_to)) { - IERC223Recipient(_to).tokenReceived(msg.sender, _value, _empty); - } - emit Transfer(msg.sender, _to, _value, _empty); - return true; - } -} -``` - -Szeretnénk, ha egy másik szerződés „tokenA” letétet fogadna el, feltéve, hogy tokenA egy ERC-223 token. A szerződés csak tokenA-t fogadhat el, a többit el kell utasítsa. Amikor a szerződés tokenA-t kap, akkor „Deposit()” eseményt kell kiadnia, és megnöveli a belső „deposits” változót az adott értékkel. - -Íme a kód: - -```solidity -contract RecipientContract is IERC223Recipient { - event Deposit(address whoSentTheTokens); - uint256 deposits = 0; - address tokenA; // The only token that we want to accept. - function tokenReceived(address _from, uint _value, bytes memory _data) public override - { - // It is important to understand that within this function - // msg.sender is the address of a token that is being received, - // msg.value is always 0 as the token contract does not own or send Ether in most cases, - // _from is the sender of the token transfer, - // _value is the amount of tokens that was deposited. - require(msg.sender == tokenA); - deposits += _value; - emit Deposit(_from); - } -} -``` - -## Gyakran ismételt kérdések {#faq} - -### Mi történik, ha tokenB-t küldünk a szerződésnek? {#sending-tokens} - -A tranzakció elbukik, a tokenátadás nem történik meg. A tokenek a küldő címére térnek vissza. - -### Hogyan lehet letétet elhelyezni ebbe a szerződésbe? {#contract-deposits} - -Meg kell hívni az ERC-223 token „transfer(address,uint256)” vagy „transfer(address,uint256,bytes)” függvényeit, megadva a „RecipientContract” címét. - -### Mi történik, ha ERC-20 tokent küldünk egy ilyen szerződésnek? {#erc-20-transfers} - -Ha ERC-20 tokent küldenek a „RecipientContract” szerződésnek, akkor az átadás megtörténik, de a szerződés nem ismeri fel (nem lesz „Deposit()” esemény, és az érték sem változik). A nem kívánt ERC-20 letéteket nem lehet kiszűrni vagy megakadályozni. - -### Mi van, ha szeretnénk függvényt végrehajtani, miután a token letét végbement? {#function-execution} - -Ennek többféle módja van. Ebben a példában megnézzük a metódust, amitől az ERC-223 átadás egyenértékű lesz az ether-küldéssel: - -```solidity -contract RecipientContract is IERC223Recipient { - event Foo(); - event Bar(uint256 someNumber); - address tokenA; // The only token that we want to accept. - function tokenReceived(address _from, uint _value, bytes memory _data) public override - { - require(msg.sender == tokenA); - address(this).call(_data); // Handle incoming transaction and perform a subsequent function call. - } - function foo() public - { - emit Foo(); - } - function bar(uint256 _someNumber) public - { - emit Bar(_someNumber); - } -} -``` - -Amikor a „RecipientContract” kap egy ERC-223 tokent, a szerződés a token tranzakció „_data” paramétereként kódolt függvényt hajt végre, ugyanúgy, ahogy az ether-tranzakciók kódolják a függvényhívásokat a tranzakció „data” paramétereként. Tekintse meg [az adatmezőt](https://ethereum.org/en/developers/docs/transactions/#the-data-field) további információért. - -A fenti példában az ERC-223 tokent a „RecipientContract” címre a „transfer(address,uin256,bytes calldata _data)” függvénnyel kell küldeni. Ha az adatparaméter „0xc2985578” (ami a „foo()” függvény jele), akkor a foo() függvény indul el a token letétbe helyezése után, és a Foo() eseményt adja. - -A paramétereket be lehet adni a token átadás „data” részébe is, például meghívhatjuk a bar() függvényt az 12345 értékkel „_someNumber” mezőben. Ekkor a „data” a következő „0x0423a13200000000000000000000000000000000000000000000000000000000000004d2”, ahol a „0x0423a132” a „bar(uint256)” függvény aláírása és „00000000000000000000000000000000000000000000000000000000000004d2” a 12345 érték uint256-ként. - -## Korlátok {#limitations} - -Miközben az ERC-223 megold néhány gondot az ERC-20 szabvány kapcsán, megvannak a maga korlátai: - -- Adaptáció és kompatibilitás: az ERC-223 még nincs széles körben adaptálva, ami miatt behatárolt a meglévő eszközökkel és platformokkal való kompatibilitása. -- Visszafelé ható kompatibilitás: az ERC-223 nem kompatibilis visszafelé az ERC-20-szal, tehát a meglévő ERC-20-as szerződések és eszközök nem fognak működni az ERC-223 tokenekkel változtatás nélkül. -- Gázköltségek: Az ERC-223 küldés extra ellenőrzései és funkciói nagyobb költségeket eredményezhetnek egy ERC-20 tranzakcióhoz képest. - -## További olvasnivaló {#further-reading} - -- [EIP-223: ERC-223 tokenszabvány](https://eips.ethereum.org/EIPS/eip-223) -- [Eredeti ERC-223 javaslat](https://github.com/ethereum/eips/issues/223) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md deleted file mode 100644 index 7c566a69bcb..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-4626/index.md +++ /dev/null @@ -1,211 +0,0 @@ ---- -title: ERC-4626 Tokenizált értékmegőrzőre vonatkozó szabvány -description: A hozamtartó értékmegőrzőkre vonatkozó szabvány. -lang: hu ---- - -## Bevezetés {#introduction} - -Az ERC-4626 szabvány a hozamtartó értékmegőrzők műszaki paramétereinek optimalizálására és egységesítésére szolgál. Egy szabványos API-t biztosít ezen tokenizált értékmegőrzőkhöz, amelyek egyetlen, alapul szolgáló ERC-20 token részvényeit képviselik. Az ERC-4626 egy opcionális kiterjesztést is körvonalaz az ERC-20-at használó tokenizált értékmegőrzők számára, amely alapvető funkciókat kínál a tokenek letétbe helyezéséhez, kivonásához és az egyenlegek leolvasásához. - -**Az ERC-4626 szerepe a hozamtartó értékmegőrzőkben** - -A hitelpiacok, az aggregátorok és a kamatozó tokenek segítenek a felhasználóknak különböző stratégiák végrehajtásával megtalálni a legjobb hozamot a kriptotokenjeikre. Ezek a stratégiák enyhe eltérésekkel kerülhetnek végrehajtásra, ami hibás lehet, vagy pazarolja a fejlesztési erőforrásokat. - -Az ERC-4626 a hozamtartó értékmegőrzőkben csökkenti az integrációs erőfeszítéseket, és a konzisztensebb és robusztusabb végrehajtási minták létrehozásával a fejlesztők kis mértékű speciális erőfeszítései mellett lehetővé teszi a hozamhoz való hozzáférést a különböző alkalmazásokban. - -Az ERC-4626 token teljes körű leírását az [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626) tartalmazza. - -## Előfeltételek {#prerequisites} - -Az oldal könnyebben megértéséhez javasoljuk, hogy tekintse át a [Tokenszabványok](/developers/docs/standards/tokens/) és az [ERC-20](/developers/docs/standards/tokens/erc-20/) című cikkeket. - -## ERC-4626 funkciók és jellemzők: {#body} - -### Metódusok {#methods} - -#### asset {#asset} - -```solidity -function asset() public view returns (address assetTokenAddress) -``` - -Ez a függvény visszaadja az értékmegőrzőben a könyveléshez, befizetéshez és kivonáshoz használt token címét. - -#### totalAssets {#totalassets} - -```solidity -function totalAssets() public view returns (uint256) -``` - -Ez a függvény az értékmegőrzőben lévő fedezeti eszközök teljes összegét adja vissza. - -#### convertToShares {#convertoshares} - -```solidity -function convertToShares(uint256 assets) public view returns (uint256 shares) -``` - -Ez a függvény visszaadja a részvények (`shares`) mennyiségét, amelyet az értékmegőrző a megadott eszközök (`assets`) mennyiségéért cserélne. - -#### convertToAssets {#convertoassets} - -```solidity -function convertToAssets(uint256 shares) public view returns (uint256 assets) -``` - -Ez a függvény visszaadja az eszközök (`assets`) mennyiségét, amelyet az értékmegőrző a megadott részvények (`shares`) mennyiségéért cserélne. - -#### maxDeposit {#maxdeposit} - -```solidity -function maxDeposit(address receiver) public view returns (uint256 maxAssets) -``` - -Ez a függvény a `receiver` által egyetlen [`deposit`](#deposit) hívással letétbe helyezhető fedezeti eszközök maximális összegét adja vissza. - -#### previewDeposit {#previewdeposit} - -```solidity -function previewDeposit(uint256 assets) public view returns (uint256 shares) -``` - -Ez a függvény lehetővé teszi a felhasználók számára, hogy szimulálják a betétük hatásait az aktuális blokkban. - -#### letét {#deposit} - -```solidity -function deposit(uint256 assets, address receiver) public returns (uint256 shares) -``` - -Ez a függvény a mögöttes tokenek eszközeit (`assets`) helyezi el az értékmegőrzőben, és a részvények (`shares`) tulajdonjogát a fogadónak (`receiver`) adja. - -#### maxMint {#maxmint} - -```solidity -function maxMint(address receiver) public view returns (uint256 maxShares) -``` - -Ez a függvény visszaadja a `receiver` által egyetlen [`mint`](#mint) hívással kiadható részvények maximális mennyiségét. - -#### previewMint {#previewmint} - -```solidity -function previewMint(uint256 shares) public view returns (uint256 assets) -``` - -Ez a függvény lehetővé teszi a felhasználók számára, hogy szimulálják a mintelés hatásait az aktuális blokkban. - -#### mint (kibocsátás) {#mint} - -```solidity -function mint(uint256 shares, address receiver) public returns (uint256 assets) -``` - -Ez a függvény pontosan `shares` értékmegőrzői részvényeket ad ki a fogadónak (`receiver`) az alapul szolgáló tokenek eszközeinek (`assets`) letétbe helyezésével. - -#### maxWithdraw {#maxwithdraw} - -```solidity -function maxWithdraw(address owner) public view returns (uint256 maxAssets) -``` - -Ez a függvény az `owner` egyenlegéből egyetlen [`withdraw`](#withdraw) hívással kivehető fedezeti eszközök maximális összegét adja vissza. - -#### previewWithdraw {#previewwithdraw} - -```solidity -function previewWithdraw(uint256 assets) public view returns (uint256 shares) -``` - -Ez a függvény lehetővé teszi a felhasználók számára, hogy szimulálják a kivonásuk hatásait az aktuális blokkban. - -#### withdraw {#withdraw} - -```solidity -function withdraw(uint256 assets, address receiver, address owner) public returns (uint256 shares) -``` - -Ez a függvény részvény (`shares`) elégetését végzi a tulajdonostól (`owner`), és pontosan ennyi `shares` tokent küld az értékmegőrzőből a fogadónak (`receiver`). - -#### maxRedeem {#maxredeem} - -```solidity -function maxRedeem(address owner) public view returns (uint256 maxShares) -``` - -Ez a függvény visszaadja az `owner` egyenlegéből [`redeem`](#redeem) hívással visszaváltható részvények maximális mennyiségét. - -#### previewRedeem {#previewredeem} - -```solidity -function previewRedeem(uint256 shares) public view returns (uint256 assets) -``` - -Ez a függvény lehetővé teszi a felhasználók számára, hogy szimulálják a beváltásuk hatásait az aktuális blokkban. - -#### redeem {#redeem} - -```solidity -function redeem(uint256 shares, address receiver, address owner) public returns (uint256 assets) -``` - -Ez a függvény meghatározott számú részvényt (`shares`) vált be a tulajdonostól (`owner`), és elküldi a mögöttes token eszközöket (`assets`) az értékmegőrzőből a fogadónak (`receiver`). - -#### totalSupply {#totalsupply} - -```solidity -function totalSupply() public view returns (uint256) -``` - -Visszaadja a forgalomban lévő, be nem váltott értékmegőrző-részvények teljes számát. - -#### balanceOf {#balanceof} - -```solidity -function balanceOf(address owner) public view returns (uint256) -``` - -Visszaadja az `owner` által jelenleg birtokolt értékmegőrző-részvények teljes mennyiségét. - -### Az interfész térképe {#mapOfTheInterface} - -![Az ERC-4626 interfész térképe](./map-of-erc-4626.png) - -### Események {#events} - -#### Letétbe helyezési esemény - -Akkor **KELL** kiadni, amikor tokeneket helyeznek el az értékmegőrzőben a [`mint`](#mint) és a [`deposit`](#deposit) metódusokon keresztül - -```solidity -event Deposit( - address indexed sender, - address indexed owner, - uint256 assets, - uint256 shares -) -``` - -Ahol a küldő (`sender`) az a felhasználó, aki eszközöket (`assets`) cserélt részvényre (`shares`), és átadta ezeket a részvényeket (`shares`) a tulajdonosnak (`owner`). - -#### Kivonási esemény - -Ki **KELL** adni, amikor a letétes a [`redeem`](#redeem) vagy [`withdraw`](#withdraw) módon részvényeket vesz ki az értékmegőrzőből. - -```solidity -event Withdraw( - address indexed sender, - address indexed receiver, - address indexed owner, - uint256 assets, - uint256 shares -) -``` - -Ahol a küldő (`sender`) az a felhasználó, aki a kivonást kezdeményezte és a tulajdonos (`owner`) tulajdonában lévő részvényeket (`shares`) eszközökre (`assets`) cserélte. A `receiver` az a felhasználó, aki a visszavont eszközöket (`assets`) megkapta. - -## További olvasnivaló {#further-reading} - -- [ERC-4626: Tokenizált értékmegőrzőre vonatkozó szabvány](https://eips.ethereum.org/EIPS/eip-4626) -- [ERC-4626: GitHub mappa](https://github.com/transmissions11/solmate/blob/main/src/tokens/ERC4626.sol) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md deleted file mode 100644 index 29f4349a989..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-721/index.md +++ /dev/null @@ -1,244 +0,0 @@ ---- -title: ERC-721 Nem helyettesíthető tokenekről szóló szabvány -description: -lang: hu ---- - -## Bevezetés {#introduction} - -**Mi az a nem helyettesíthető token?** - -Egy nem helyettesíthető tokent (NFT) valami vagy valaki egyedi beazonosítására lehet használni. Ezt a tokentípust tökéletesen lehet használni olyan platformokon, melyek gyűjthető tárgyakat, hozzáférési kulcsokat, lottószelvényeket, sorszámozott koncertjegyeket vagy sporteseményjegyeket stb. árulnak. Ez a speciális tokentípus csodás lehetőségeket rejt magában, így megérdemel egy megfelelő szabványt, így az ERC-721 szolgál megoldásul! - -**Mi az az ERC-721?** - -Az ERC-721 bevezeti az NFT-szabványt, vagyis ez a tokentípus egyedi és különböző értékekkel rendelkezhet, mint egy másik token ugyanabból az okosszerződésből, ami esetleg a korából, ritkaságából vagy a kinézetéből származik. Egy pillanat, kinézet? - -Igen! Minden NFT-nek van egy `uint256` változója `tokenId` néven, így minden ERC-721 szerződéshez tartozó `contract address, uint256 tokenId` globálisan egyedi. Tehát egy dappnak lehet egy „konvertere”, amely a `tokenId` változót használja bemenetre, kimenetként pedig valami menő dolog képét adja vissza, például zombikat, fegyvereket, képességeket vagy csodás kiscicákat! - -## Előfeltételek {#prerequisites} - -- [Számlák](/developers/docs/accounts/) -- [Okosszerződések](/developers/docs/smart-contracts/) -- [Token szabványok](/developers/docs/standards/tokens/) - -## Törzs {#body} - -Az ERC-721 (Ethereum Request for Comments 721), melyet William Entriken, Dieter Shirley, Jacob Evans és Nastassia Sachs javasolt 2018. januárjában, egy nem helyettesíthető tokenre vonatkozó szabványt vezet be, mely egy token API-t implementál az okosszerződéseken belül. - -Olyan funkcionalitásokat tartalmaz, mint a tokenátutalás egyik számláról a másikra, a token jelenlegi egyenlegének lekérdezése az adott számlán, az adott token jelenlegi tulajdonosa, valamint a teljes elérhető tokenmennyiség a hálózaton. Emellett vannak más funkciók is, mint például annak jóváhagyása, hogy egy harmadik fél számlája átmozgasson egy bizonyos mennyiségű tokent az adott számláról. - -Ha egy okosszerződés implementálja a következő metódusokat és eseményeket, akkor egy ERC-721 nem helyettesíthető tokenszerződésnek lehet nevezni, és a telepítés után a létrejött tokenek számontartásáért lesz felelős az Ethereumon. - -Az [EIP-721-ből](https://eips.ethereum.org/EIPS/eip-721): - -### Metódusok {#methods} - -```solidity - function balanceOf(address _owner) external view returns (uint256); - function ownerOf(uint256 _tokenId) external view returns (address); - function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable; - function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable; - function transferFrom(address _from, address _to, uint256 _tokenId) external payable; - function approve(address _approved, uint256 _tokenId) external payable; - function setApprovalForAll(address _operator, bool _approved) external; - function getApproved(uint256 _tokenId) external view returns (address); - function isApprovedForAll(address _owner, address _operator) external view returns (bool); -``` - -### Események {#events} - -```solidity - event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId); - event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId); - event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved); -``` - -### Példák {#web3py-example} - -Nézzük meg, miért olyan fontos egy szabvány, hogy egyszerűbbé tegye számunkra azt, hogy bármely ERC-721 tokenszerződést megtekinthessük az Ethereumon. Csak a szerződés Alkalmazás bináris interfészére (ABI) lesz szükség, hogy egy felületet készítsünk bármely ERC-721 tokennek. Ahogy lentebb látni fogod, egy egyszerűsített ABI-t használunk, hogy egy egyszerűbb példával éljünk. - -#### Web3.py példa {#web3py-example} - -Először győződj meg arról, hogy a [Web3.py](https://web3py.readthedocs.io/en/stable/quickstart.html#installation) Python könyvtár telepítve van: - -``` -pip install web3 -``` - -```python -from web3 import Web3 -from web3._utils.events import get_event_data - - -w3 = Web3(Web3.HTTPProvider("https://cloudflare-eth.com")) - -ck_token_addr = "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d" # CryptoKitties Contract - -acc_address = "0xb1690C08E213a35Ed9bAb7B318DE14420FB57d8C" # CryptoKitties Sales Auction - -# This is a simplified Contract Application Binary Interface (ABI) of an ERC-721 NFT Contract. -# It will expose only the methods: balanceOf(address), name(), ownerOf(tokenId), symbol(), totalSupply() -simplified_abi = [ - { - 'inputs': [{'internalType': 'address', 'name': 'owner', 'type': 'address'}], - 'name': 'balanceOf', - 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], - 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True - }, - { - 'inputs': [], - 'name': 'name', - 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], - 'stateMutability': 'view', 'type': 'function', 'constant': True - }, - { - 'inputs': [{'internalType': 'uint256', 'name': 'tokenId', 'type': 'uint256'}], - 'name': 'ownerOf', - 'outputs': [{'internalType': 'address', 'name': '', 'type': 'address'}], - 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True - }, - { - 'inputs': [], - 'name': 'symbol', - 'outputs': [{'internalType': 'string', 'name': '', 'type': 'string'}], - 'stateMutability': 'view', 'type': 'function', 'constant': True - }, - { - 'inputs': [], - 'name': 'totalSupply', - 'outputs': [{'internalType': 'uint256', 'name': '', 'type': 'uint256'}], - 'stateMutability': 'view', 'type': 'function', 'constant': True - }, -] - -ck_extra_abi = [ - { - 'inputs': [], - 'name': 'pregnantKitties', - 'outputs': [{'name': '', 'type': 'uint256'}], - 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True - }, - { - 'inputs': [{'name': '_kittyId', 'type': 'uint256'}], - 'name': 'isPregnant', - 'outputs': [{'name': '', 'type': 'bool'}], - 'payable': False, 'stateMutability': 'view', 'type': 'function', 'constant': True - } -] - -ck_contract = w3.eth.contract(address=w3.to_checksum_address(ck_token_addr), abi=simplified_abi+ck_extra_abi) -name = ck_contract.functions.name().call() -symbol = ck_contract.functions.symbol().call() -kitties_auctions = ck_contract.functions.balanceOf(acc_address).call() -print(f"{name} [{symbol}] NFTs in Auctions: {kitties_auctions}") - -pregnant_kitties = ck_contract.functions.pregnantKitties().call() -print(f"{name} [{symbol}] NFTs Pregnants: {pregnant_kitties}") - -# Using the Transfer Event ABI to get info about transferred Kitties. -tx_event_abi = { - 'anonymous': False, - 'inputs': [ - {'indexed': False, 'name': 'from', 'type': 'address'}, - {'indexed': False, 'name': 'to', 'type': 'address'}, - {'indexed': False, 'name': 'tokenId', 'type': 'uint256'}], - 'name': 'Transfer', - 'type': 'event' -} - -# We need the event's signature to filter the logs -event_signature = w3.keccak(text="Transfer(address,address,uint256)").hex() - -logs = w3.eth.get_logs({ - "fromBlock": w3.eth.block_number - 120, - "address": w3.to_checksum_address(ck_token_addr), - "topics": [event_signature] -}) - -# Notes: -# - Increase the number of blocks up from 120 if no Transfer event is returned. -# - If you didn't find any Transfer event you can also try to get a tokenId at: -# https://etherscan.io/address/0x06012c8cf97BEaD5deAe237070F9587f8E7A266d#events -# Click to expand the event's logs and copy its "tokenId" argument -recent_tx = [get_event_data(w3.codec, tx_event_abi, log)["args"] for log in logs] - -if recent_tx: - kitty_id = recent_tx[0]['tokenId'] # Paste the "tokenId" here from the link above - is_pregnant = ck_contract.functions.isPregnant(kitty_id).call() - print(f"{name} [{symbol}] NFTs {kitty_id} is pregnant: {is_pregnant}") -``` - -A CryptoKitties szerződésnek van egy pár érdekes eseménye, ami nem sztenderd. - -Nézzünk meg kettőt közülük: `Pregnant` és `Birth`. - -```python -# A Pregnant és a Birth esemény ABI-ok használata, hogy infókat kapjunk meg az új cicákról. -ck_extra_events_abi = [ - { - 'anonymous': False, - 'inputs': [ - {'indexed': False, 'name': 'owner', 'type': 'address'}, - {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, - {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, - {'indexed': False, 'name': 'cooldownEndBlock', 'type': 'uint256'}], - 'name': 'Pregnant', - 'type': 'event' - }, - { - 'anonymous': False, - 'inputs': [ - {'indexed': False, 'name': 'owner', 'type': 'address'}, - {'indexed': False, 'name': 'kittyId', 'type': 'uint256'}, - {'indexed': False, 'name': 'matronId', 'type': 'uint256'}, - {'indexed': False, 'name': 'sireId', 'type': 'uint256'}, - {'indexed': False, 'name': 'genes', 'type': 'uint256'}], - 'name': 'Birth', - 'type': 'event' - }] - -# We need the event's signature to filter the logs -ck_event_signatures = [ - w3.keccak(text="Pregnant(address,uint256,uint256,uint256)").hex(), - w3.keccak(text="Birth(address,uint256,uint256,uint256,uint256)").hex(), -] - -# Here is a Pregnant Event: -# - https://etherscan.io/tx/0xc97eb514a41004acc447ac9d0d6a27ea6da305ac8b877dff37e49db42e1f8cef#eventlog -pregnant_logs = w3.eth.get_logs({ - "fromBlock": w3.eth.block_number - 120, - "address": w3.to_checksum_address(ck_token_addr), - "topics": [ck_event_signatures[0]] -}) - -recent_pregnants = [get_event_data(w3.codec, ck_extra_events_abi[0], log)["args"] for log in pregnant_logs] - -# Here is a Birth Event: -# - https://etherscan.io/tx/0x3978028e08a25bb4c44f7877eb3573b9644309c044bf087e335397f16356340a -birth_logs = w3.eth.get_logs({ - "fromBlock": w3.eth.block_number - 120, - "address": w3.to_checksum_address(ck_token_addr), - "topics": [ck_event_signatures[1]] -}) - -recent_births = [get_event_data(w3.codec, ck_extra_events_abi[1], log)["args"] for log in birth_logs] -``` - -## Népszerű NFT-k {#popular-nfts} - -- [Etherscan NFT Tracker](https://etherscan.io/tokens-nft) legnagyobb forgalommal rendelkező NFT-k listája az Ethereumon. -- [CryptoKitties](https://www.cryptokitties.co/) egy játék, mely tenyészthető, gyűjthető és imádnivaló lényekről szól, melyeket CryptoKittiknek nevezünk. -- [Sorare](https://sorare.com/) egy globális fantáziafutball-játék, ahol korlátozott példányszámú gyűjthető dolgot lehet összeszedni, Ön irányíthatja a csapatait, és versenyezhet díjakért. -- [Az Ethereum Name Service (ENS)](https://ens.domains/) egy biztonságos & decentralizált módját kínálja az erőforrások kezelésére a blokkláncon vagy azon kívül egyszerű, emberek számára is olvasható nevek használatával. -- A [POAP](https://poap.xyz) ingyenes NFT-ket biztosít azoknak, akik részt vesznek eseményeken vagy meghatározott akciókat hajtanak végre. A POAP-ok létrehozása és terjesztése ingyenes. -- Az [Unstoppable Domains](https://unstoppabledomains.com/) egy San Francisco székhelyű vállalat, amely domainneveket fejleszt a blokkláncra. A blokklánc-domainek a kriptovalutacímeket ember által is olvasható nevekre cserélik, és cenzúraellenálló weboldalakhoz is használhatók. -- A [Gods Unchained Cards](https://godsunchained.com/) egy TCG (Trading Card Game) az Ethereum-blokkláncon, amely NFT-ket használ, hogy valódi tulajdonjogot biztosítson a játékon belüli eszközökre. -- A [Bored Ape Yacht Club](https://boredapeyachtclub.com) egy 10 000 egyedi NFT-ből álló gyűjtemény, amely amellett, hogy bizonyíthatóan ritka műalkotás, a klub tagsági zálogaként is szolgál, és a közösségi erőfeszítések eredményeként idővel növekvő tagsági kedvezményeket és előnyöket biztosít. - -## További olvasnivaló {#further-reading} - -- [ERC-721: Nem helyettesíthető tokenekről szóló szabvány](https://eips.ethereum.org/EIPS/eip-721) -- [OpenZeppelin - ERC-721 Dokumentáció](https://docs.openzeppelin.com/contracts/3.x/erc721) -- [OpenZeppelin - ERC-721 Implementáció](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol) -- [Alchemy NFT API](https://docs.alchemy.com/alchemy/enhanced-apis/nft-api) diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md deleted file mode 100644 index 69264f5cbbb..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/erc-777/index.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: ERC-777 tokenszabvány -description: -lang: hu ---- - -## {#introduction} - -**** - -**** - -A hook vagy horog az okosszerződés kódjában leírt funkciót jelent. Akkor kerülnek meghívásra, amikor a szerződésen keresztül tokeneket küldenek vagy fogadnak. Ez lehetővé teszi, hogy az okosszerződés reagáljon a bejövő vagy kimenő tokenekre. - -## {#prerequisites} - -- []() -- []() -- []() - -## {#body} - -A horgokat az [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820)-as szabvány segítségével regisztrálják és fedezik fel. - -A szabvány megoldja az ERC-20-ban a `decimals` körül kialakult zavart is. Ez az egyértelműség javítja a fejlesztői élményt. - -Az ERC-777-es szerződésekkel úgy lehet interakcióba lépni, mintha ERC-20-as szerződések lennének. - -### {#methods} - -```solidity - -``` - -### {#events} - -```solidity - -``` - -### {#web3py-example} - -#### {#web3py-example} - -``` - -``` - -```python - - - - -``` - -```python - - -``` - -## {#popular-nfts} - -- -- -- -- -- -- -- -- - -## További olvasnivaló {#further-reading} - -- []() -- []() -- []() -- []() diff --git a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/index.md b/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/index.md deleted file mode 100644 index 864ff6f8d6b..00000000000 --- a/public/content/translations/hu/23) Advanced Docs/developers/docs/standards/tokens/index.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Tokenszabványok -description: -lang: hu -incomplete: true ---- - -## Bevezetés {#introduction} - -Sok Ethereum fejlesztési szabvány a tokeninterfészekre összpontosít. Ezek a szabványok segítenek abban, hogy az okosszerződések továbbra is összeilleszthetőek maradnak, így például amikor egy új projekt egy tokent bocsát ki, az továbbra is kompatibilis marad a meglévő decentralizált tőzsdékkel. - -## Előfeltételek {#prerequisites} - -- [Ethereum fejlesztési szabványok](/developers/docs/standards/) -- [Okosszerződések](/developers/docs/smart-contracts/) - -## Token szabványok {#token-standards} - -Itt van néhány az Ethereum legnépszerűbb tokenszabványaiból: - -- [ERC-20](/developers/docs/standards/tokens/erc-20/) – Egy sztenderd interfész a helyettesíthető (cserélhető) tokenekhez, például a szavazási és letéti tokenekhez vagy a virtuális valutákhoz. - -### NFT szabványok {#nft-standards} - -- [ERC-721](/developers/docs/standards/tokens/erc-721/) – Egy sztenderd interfész a nem helyettesíthető tokenekhez, például egy műalkotásról szóló okirathoz vagy egy dalhoz. -- [ERC-1155](/developers/docs/standards/tokens/erc-1155/) – Az ERC-1155 hatékonyabb kereskedést és tranzakciókötést tesz lehetővé, ami költségmegtakarítást eredményez. Ez a tokenszabvány lehetővé teszi mind a közüzemi tokenek (például $BNB vagy $BAT), mind pedig a CryptoPunks-hoz hasonló, nem helyettesíthető tokenek létrehozását. - -Az [ERC](https://eips.ethereum.org/erc) javaslatok teljes listája. - -## További olvasnivaló {#further-reading} - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ - -## Kapcsolódó útmutatók {#related-tutorials} - -- [Tokenintegrációs ellenőrzési lista](/developers/tutorials/token-integration-checklist/) _– Egy ellenőrzési lista, melyet figyelembe kell venni tokenekkel történő interakcióknál_ -- [Az ERC-20 token okosszerződés megértése](/developers/tutorials/understand-the-erc-20-token-smart-contract/) _– Bevezetés az első okosszerződés telepítésébe egy Ethereum teszthálózaton._ -- [ERC-20 tokenek átvitele és jóváhagyása egy Solidity okosszerződésből](/developers/tutorials/transfers-and-approval-of-erc-20-tokens-from-a-solidity-smart-contract/) _– hogyan használjunk okosszerződést a Solidity nyelv használatával a tokenekkel való interakcióhoz._ -- [Útmutató az ERC-721 piacimplementációhoz](/developers/tutorials/how-to-implement-an-erc721-market/) _– Hogyan lehet tokenizált tárgyakat eladásra kínálni egy decentralizált és titkosított felületen._ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" deleted file mode 100644 index 0b8d716bf50..00000000000 --- "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/index.md" +++ /dev/null @@ -1,114 +0,0 @@ ---- -title: Méretezés -description: Bevezetés a különböző skálázási lehetőségekbe, melyet jelenleg az Ethereum közösség fejleszt. -lang: hu -sidebarDepth: 3 ---- - -## Skálázás áttekintése {#scaling-overview} - -Ahogy az Ethereumot használók száma nőtt, a blokklánc elért bizonyos kapacitáskorlátokat. Ez megemelte a hálózat használatának költségeit, és egyúttal igényt teremtett a „skálázási megoldásokra”. Többféle megoldást kutatnak, tesztelnek és vezetnek be, amelyek különböző megközelítésekkel érnek el hasonló célokat. - -A skálázhatóság fő célja a tranzakció sebességének növelése (gyorsabb véglegesség) és a nagyobb tranzakcióátvitel (több tranzakció másodpercenként) a decentralizáció vagy a biztonság feláldozása nélkül (bővebben az [Ethereum jövőképében](/roadmap/vision/)). Az Ethereum blokkláncon (L1) a nagy kereslet lassabb tranzakciókhoz és irracionális [gázárakhoz](/developers/docs/gas/) vezet. A hálózati kapacitás növelése a sebesség és a tranzakcióátvitel tekintetében alapvető fontosságú az Ethereum értelmes és tömeges használatához. - -Bár a sebesség és a tranzakcióátvitel fontos, mégis lényeges, hogy az ezeket lehetővé tevő skálázási megoldások decentralizáltak és biztonságosak maradjanak. A csomópontok üzemeltetői számára a belépési korlátok alacsonyan tartása kritikus, hogy ne mozduljon el a hálózat a centralizált és bizonytalan számítási teljesítmény felé. - -Koncepcionálisan a skálázást először a láncon belüli vagy kívüli kategóriájába sorolhatjuk. - -## Előfeltételek {#prerequisites} - -Jó alapokkal kell rendelkeznie az összes alapvető témakörről. A skálázási megoldások megvalósítása komoly feladat, a technológia még kevésbé kiforrott, folyamatosan kutatják és fejlesztik. - -## Láncon belüli skálázás {#on-chain-scaling} - -A láncon belüli skálázáshoz módosíttani kell az Ethereum protokollját (L1 [főhálózatot](/glossary/#mainnet)). Sokáig a blokklánc felosztásától (sharding) várták az Ethereum skálázását. Ehhez a blokkláncot különálló darabokra kellett volna osztani, amelyeket a validátorok részhalmazai ellenőriznek. A második blokkláncréteg (L2) összevont tranzakciókkal történő skálázása vált preferálttá. Ezt támogatja az Ethereum-blokkokhoz csatolt adatok egy új, olcsóbb formája, amelyet kifejezetten arra terveztek, hogy a felhasználók számára olcsóbbá tegye az összevont tranzakciókat. - -### Sharding {#sharding} - -A sharding egy adatbázis felosztásának folyamata. A validátorok részhalmazai az egyes shardokért lennének felelősek, ahelyett hogy az egész Ethereumot nyomon követnék. A sharding sokáig szerepelt az Ethereum [ütemtervében](/roadmap/), és egykor úgy tervezték, hogy még a proof-of-stake bevezetése (a Beolvadás) előtt leszállításra kerül. Az [L2 összevont tranzakciók](#layer-2-scaling) gyors fejlődése és a [Danksharding](/roadmap/danksharding) feltalálása (a validátorok által hatékonyan ellenőrizhető összevont tranzakciós adatblobok hozzáadása az Ethereum blokkokhoz) azonban arra késztette az Ethereum közösséget, hogy az összevonttranzakció-központú skálázást részesítse előnyben a sharding helyett. Ez segít abban is, hogy az Ethereum konszenzuslogikája egyszerűbb legyen. - -## Láncon kívüli skálázás {#off-chain-scaling} - -A láncon kívüli megoldásokat az L1 főhálózattól függetlenül valósítják meg, tehát nem igényelnek változtatásokat a meglévő Ethereum protokollban. Az L2 megoldások közvetlenül az Ethereum L1 konszenzusából származtatják biztonságukat, mint például a [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/), [a zero-knowledge összevont tranzakciók](/developers/docs/scaling/zk-rollups/) vagy [státuszcsatornák](/developers/docs/scaling/state-channels/). Más megoldások különböző formájú új láncok létrehozását foglalják magukban, amelyek a biztonságukat a főhálózattól elkülönítve kezelik, mint például [mellékláncok](#sidechains), [validiumok](#validium) vagy [plazmaláncok](#plasma). Ezek a megoldások kommunikálnak a főhálózattal, de más-más célok elérése érdekében másképp biztosítják a szükséges biztonságot. - -### L2 skálázás {#layer-2-scaling} - -A láncon kívüli megoldások ezen kategóriája az Ethereum főhálózatból meríti biztonságát. - -Az L2 azon megoldások gyűjtőfogalma, amelyek az alkalmazások skálázhatóságát úgy oldják meg, hogy a tranzakciókat a főhálózaton (L1) kívül végzik el, ugyanakkor felhasználják a főhálózat robusztus, decentralizált biztonsági modelljét. A hálózat leterheltségekor lassul a tranzakciók feldolgozása, ami rontja a felhasználói élményt bizonyos típusú dappoknál. Ahogy nő a hálózat forgalma, úgy nőnek a gázárak, mivel a tranzakció küldők próbálják egymást túllicitálni. Ez nagyon drágává teszi az Ethereum használatát. - -A legtöbb L2 megoldás egy szerver vagy egy szerverklaszter körül helyezkedik el, amelyek mindegyikét csomópontnak, validátornak, operátornak, szekvenszernek, blokkgyártónak vagy hasonlónak nevezhetjük. A megvalósítástól függően ezeket az L2 csomópontokat futtathatják egyének, felhasználóként működő vállalkozások vagy vállalatok, harmadik fél vagy egyének nagy csoportja (hasonlóan a főhálózathoz). Általánosságban elmondható, hogy a tranzakciókat ezekhez az L2 csomópontokhoz nyújtják be ahelyett, hogy közvetlenül az L1-be (főhálózat) adnák. Bizonyos megoldásoknál az L2 ezután csoportokba rendezi őket, mielőtt az L1 felé közvetítené azokat, majd az L1 rögzíti azokat, és nem módosíthatók. A részletek jelentősen eltérnek a különböző L2 technológiák és megvalósítások függvényében. - -Egy adott L2 lehet nyitott és több alkalmazás használja, vagy egy adott projekt üzemelteti a saját alkalmazásukhoz. - -#### Miért szükséges az L2? {#why-is-layer-2-needed} - -- A másodpercenkénti tranzakciók számának növekedése jelentősen javítja a felhasználói élményt, és csökkenti a hálózati torlódásokat az Ethereum főhálózaton. -- Sok tranzakciót vonnak össze, melyek egyetlen tranzakcióként jelennek meg az Ethereum főhálózaton, ezzel is csökkentve a felhasználók gázdíjait, így az Ethereum mindenhol befogadóbbá és elérhetőbbé válik. -- A skálázhatóság fejlesztése nem mehet a decentralizáció rovására – az L2 réteg az Ethereumra épül. -- Vannak alkalmazásspecifikus L2 hálózatok, amelyek hatékonysági előnyökkel járnak az eszközökkel való méretarányos munka során. - -[Bővebben az L2-ről](/layer-2/). - -#### Összevont tranzakciók {#rollups} - -Az összevont tranzakciók az L1-en kívül hajtják végre a tranzakciókat, majd az adatok az L1-be kerülnek, ahol konszenzusra jutnak. Mivel a tranzakciós adatok az L1 blokkokban szerepelnek, ez lehetővé teszi az összevont tranzakciók natív Ethereum-biztonsággal történő védelmét. - -Kétfajta összevont tranzakció létezik különböző biztonsági modellekkel: - -- **Optimista összevont tranzakció**: alapértelmezésben érvényes tranzakciókat feltételez, és csak kétely esetén végez számításokat egy [**csalási bizonyíték**](/glossary/#fraud-proof) révén. [Bővebben az optimista összevont tranzakciókról](/developers/docs/scaling/optimistic-rollups/). -- **Zero-knowledge összevont tranzakció**: számítást végez a láncon kívül, és [**érvényességi bizonyítékot**](/glossary/#validity-proof) ad a láncnak. [Bővebben a zero-knowledge összevont tranzakciókról](/developers/docs/scaling/zk-rollups/). - -#### Állapot csatornák {#channels} - -A státuszcsatornák többaláírásos szerződéseket használnak, hogy a résztvevők gyorsan és szabadon tudjanak tranzakciókat lebonyolítani a láncon kívül, majd a végleges elszámolást a főhálózattal végezzék. Ez minimalizálja a hálózati torlódásokat, díjakat és késedelmeket. Két típusa jelenleg a státuszcsatorna és a fizetési csatorna. - -Tudjon meg többet az [státuszcsatornákról](/developers/docs/scaling/state-channels/). - -### Mellékláncok {#sidechains} - -A melléklánc egy független, EVM-kompatibilis blokklánc, amely a főhálózattal párhuzamosan fut. Ezek kétirányú hidakon keresztül kompatibilisek az Ethereummal, és saját konszenzusszabályok és blokkparaméterek szerint működnek. - -Tudjon meg többet a [mellékláncokról](/developers/docs/scaling/sidechains/). - -### Plazma {#plasma} - -A plazmalánc egy külön blokklánc, amely a fő Ethereum-lánchoz van rögzítve, és csalásbizonylatokat (például [optimista rollup](/developers/docs/scaling/optimistic-rollups/)) használ a viták eldöntésére. - -Bővebben a [plazmáról](/developers/docs/scaling/plasma/). - -### Validium {#validium} - -A validiumlánc olyan érvényességi bizonyítékokat használ, mint a zero-knowledge összevont tranzakciók, de az adatokat nem az Ethereum L1-en tárolja. Ez másodpercenként 10 000 tranzakciót eredményezhet validiumlánconként, és több láncot lehet párhuzamosan futtatni. - -Bővebben a [validiumokról](/developers/docs/scaling/validium/). - -## Miért van szükség ennyi skálázási megoldásra? {#why-do-we-need-these} - -- A többféle megoldás segíthet csökkenteni a hálózat részeinek általános zsúfoltságát, és megakadályozza az egyetlen meghibásodási pont kialakulását is. -- Az egész több, mint a részek összege. Különböző megoldások létezhetnek és működhetnek együtt, ami exponenciális hatást gyakorolhat a jövőbeli tranzakciók sebességére és tranzakcióátvitelre. -- Nem minden megoldás igényli az Ethereum konszenzusalgoritmusának közvetlen használatát, és az alternatívák olyan előnyöket kínálhatnak, amelyeket egyébként nehéz lenne elérni. -- Egyetlen skálázási megoldás sem elegendő az [Ethereum víziójának](/roadmap/vision/) megvalósításához. - -## Ön inkább vizuális típus? {#visual-learner} - - - -_Vegye figyelembe, hogy a videóban szereplő magyarázat az L2 kifejezést használja az összes láncon kívüli skálázási megoldásra, míg mi olyan láncon kívüli megoldásként különböztetjük meg, amely biztonságát az L1 főhálózat konszenzusán keresztül nyeri._ - - - -## További olvasnivaló {#further-reading} - -- [Egy összevonttranzakció-központú Ethereum útiterv](https://ethereum-magicians.org/t/a-rollup-centric-ethereum-roadmap/4698) _Vitalik Buterin_ -- [Naprakész elemzések az L2 skálázási megoldásokról az Ethereum számára](https://www.l2beat.com/) -- [Ethereum L2 skálázási megoldások értékelése: összehasonlítási keretrendszer](https://medium.com/matter-labs/evaluating-ethereum-l2-scaling-solutions-a-comparison-framework-b6b2f410f955) -- [Egy nem teljeskörű útmutató az összevont tranzakciókhoz](https://vitalik.eth.limo/general/2021/01/05/rollup.html) -- [Ethereum-alapú ZK összevont tranzakciók: világverők](https://hackmd.io/@canti/rkUT0BD8K) -- [Az optimista összevont tranzakciók és a ZK összevont tranzakciók összehasonlítása](https://limechain.tech/blog/optimistic-rollups-vs-zk-rollups/) -- [Zero-knowledge blokklánc skálázhatósága](https://ethworks.io/assets/download/zero-knowledge-blockchain-scaling-ethworks.pdf) -- [Miért az összevont tranzakciók és az adatmegosztások (sharding) adják az egyetlen fenntartható megoldást a nagyfokú skálázhatósághoz](https://polynya.medium.com/why-rollups-data-shards-are-the-only-sustainable-solution-for-high-scalability-c9aabd6fbb48) -- [Milyen L3 megoldásoknak van értelme?](https://vitalik.eth.limo/general/2022/09/17/layer_3.html) -- [Adatelérhetőség vagy hogyan tanulták meg az összevont tranzakciók, hogy ne aggódjanak és szeressék az Ethereumot](https://ethereum2077.substack.com/p/data-availability-in-ethereum-rollups) - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" deleted file mode 100644 index 522182424e0..00000000000 --- "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/optimistic-rollups/index.md" +++ /dev/null @@ -1,269 +0,0 @@ ---- -title: Optimista összevont tranzakciók -description: Bevezetés az optimista összevont tranzakciókba – az Ethereum közösség által használt skálázási megoldásba. -lang: hu ---- - -Az optimista összevont tranzakciók olyan L2 protokollok, amelyeket az Ethereum alapréteg tranzakcióátvitelének növelésére terveztek. A tranzakciók láncon kívüli feldolgozásával csökkentik a számításokat a fő Ethereum-láncon, ami jelentősen javítja a feldolgozási sebességet. A [mellékláncokhoz](/developers/docs/scaling/sidechains/) képest az optimistaz összevont tranzakciók a főhálózat biztonságát a tranzakciós eredmények láncon belüli közzétételével nyerik, a [plazmaláncokkal összevetve](/developers/docs/scaling/plasma/) ugyanúgy az Ethereumon ellenőrzik a tranzakciókat csalási bizonyítékokkal, de azok a tranzakciós adatokat máshol tárolják. - -Mivel a számítás az Ethereum használatának lassú és drága része, az optimista összevont tranzakciók akár 10-100-szoros javulást is kínálnak a méretezhetőségben. Az optimista összevont tranzakciók a tranzakciókat is `calldata` mezőként vagy a [blobokba](/roadmap/danksharding/) írják az Ethereumba, csökkentve a felhasználók gázköltségeit. - -## Előfeltételek {#prerequisites} - -Érdemes áttekinteni az [Ethereum skálázásról](/developers/docs/scaling/) és [L2 megoldásokról](/layer-2/) szóló oldalakat. - -## Mi az az optimista összevont tranzakció? {#what-is-an-optimistic-rollup} - -Az optimista összevont tranzakció az Ethereum skálázásának olyan megközelítése, amely a számítást és a státusztárolást láncon kívül végzi. Az optimista összevont tranzakciók a tranzakciókat az Ethereumon kívül hajtják végre, de a tranzakciós adatokat `calldata` mezőként vagy [blobokban](/roadmap/danksharding/) a főhálózatra küldik. - -Az optimista összevont tranzakciók operátorai több láncon kívüli tranzakciót kötegelnek össze nagy tételekben, mielőtt elküldik az Ethereumnak. Ez a megközelítés lehetővé teszi a fix költségek elosztását a kötegek tranzakcióira, csökkentve ezzel a végfelhasználók díjait. Az optimista összevont tranzakciók tömörítési technikákat is alkalmaznak, hogy csökkentsék az Ethereumban közzétett adatok mennyiségét. - -Az optimista összevont tranzakciók azért számítanak optimistának, mert feltételezik, hogy a láncon kívüli tranzakciók érvényesek, és nem tesznek közzé érvényességi bizonyítékokat a láncon közzétett tranzakciókötegekről. Ez a különbség az optimista és a [zero-knowledge összevont tranzakciók](/developers/docs/scaling/zk-rollups) között, mivel utóbbiak kriptográfiai [érvényességi bizonyítékokat](/glossary/#validity-proof) tesznek közzé a láncokon kívüli tranzakciókról. - -Az optimista összevont tranzakciók ehelyett egy csalásbizonyító rendszerre támaszkodnak, hogy felderítsék azokat az eseteket, amikor a tranzakciókat nem megfelelően számítják ki. Miután egy összevonttranzakció-köteget benyújtottak az Ethereumra, egy adott „megkérdőjelezési” időszakon belül bárki megtámadhatja az összevont tranzakció eredményét egy [csalási bizonyíték](/glossary/#fraud-proof) kiszámításával. - -Ha a csalási bizonyíték sikeres, az összevonttranzakció-protokoll újra végrehajtja a tranzakció(ka)t, és ennek megfelelően frissíti az összevont tranzakció státuszát. A sikeres csalási bizonyíték másik hatása az, hogy a hibásan végrehajtott tranzakció blokkba való felvételéért felelős szekvencer büntetést kap. - -Ha az összevonttranzakció-köteg a megkérdőjelezési időszak letelte után is kifogástalan marad (minden tranzakciót helyesen hajtottak végre), akkor azt érvényesnek és elfogadottnak tekintik az Ethereumon. Lehetséges egy meg nem erősített összevonttranzakció-blokkra építeni, de fontos tudni: a tranzakció eredményei megfordulnak, ha egy korábban közzétett, hibásan végrehajtott tranzakción alapulnak. - -## Hogyan működnek együtt az optimista összevont tranzakciók az Ethereummal? {#optimistic-rollups-and-Ethereum} - -Az optimista összevont tranzakciók [láncon kívüli skálázási megoldások](/developers/docs/scaling/#off-chain-scaling), amelyek az Ethereumra épülve működnek. Minden egyes optimista összevont tranzakció-ot az Ethereum-hálózaton telepített okosszerződések egy csoportja kezel. Az optimista összevont tranzakciók a tranzakciókat a fő Ethereum-láncon kívül dolgozzák fel, majd ezeket kötegekben egy láncon belüli összevont tranzakciós szerződésbe írják. Az Ethereum blokkláncához hasonlóan ez a tranzakciós rekord is megváltoztathatatlan, és az „optimista összevont tranzakció láncát” alkotja. - -Az optimista összevont tranzakció architektúrája a következő részekből áll: - -**Láncon lévő szerződések**: Az optimista összevont tranzakciók működését az Ethereumon futó okosszerződések irányítják. Ide olyan szerződések tartoznak, melyek tárolják az összevonttranzakció-blokkokat, követik a státuszfrissítéseket és a felhasználói befizetéseket. Így az Ethereum az optimista összevont tranzakció alaprétegeként vagy L1-ként szolgál. - -**Láncon kívüli virtuális gép (VM)**: Bár az optimista összevont tranzakciós protokollt kezelő szerződések az Ethereumon futnak, az összevont tranzakciós protokoll a számításokat és a státusztárolást egy másik virtuális gépen végzi, amely elkülönül az [Ethereum virtuális géptől](/developers/docs/evm/). A láncon kívüli VM az, ahol az alkalmazások élnek és a státuszváltozások végrehajtásra kerülnek; ez az optimista összevont tranzakció felső vagy második rétege (L2). - -Mivel az optimista összevont tranzakcióokat az EVM számára írt vagy lefordított programok futtatására tervezték, a láncon kívüli VM számos EVM tervezési specifikációt tartalmaz. Ezenkívül a láncban kiszámított csalási bizonyítékok lehetővé teszik az Ethereum-hálózat számára, hogy érvényre juttassa a láncon kívüli VM-ben kiszámított státuszváltozások érvényességét. - -Az optimista összevont tranzakciókat hibrid skálázási megoldásoknak nevezik, mert bár különálló protokollként léteznek, biztonsági tulajdonságaik az Ethereumból származnak. Az Ethereum többek között garantálja az összevont tranzakció láncon kívüli számítás helyességét és a számítás mögötti adatok elérhetőségét. Ezáltal az optimista összevont tranzakciók biztonságosabbak, mint a tisztán láncon kívüli skálázási protokollok (pl. [mellékláncok](/developers/docs/scaling/sidechains/)), amelyek nem támaszkodnak az Ethereum biztonságára. - -Az optimista összevont tranzakciók az Ethereum fő protokolljára támaszkodnak a következőkben: - -### Adatelérhetőség {#data-availability} - -Az optimista összevont tranzakciók a tranzakciós adatokat `calldata` mezőként vagy [blobokban](/roadmap/danksharding/) küldik az Ethereumba. Mivel az összevont tranzakció-lánc végrehajtása a benyújtott tranzakciókon alapul, bárki felhasználhatja ezt az Ethereum alaprétegén tárolt információt az összevont tranzakció státuszának végrehajtásához és a státuszváltozások helyességének ellenőrzéséhez. - -[Az adatelérhetőség](/developers/docs/data-availability/) kritikus fontosságú, mivel a státuszadatokhoz való hozzáférés nélkül azok, akik megkérdőjelezik az eredményt, nem tudnak csalási bizonyítékokat konstruálni az érvénytelen összevont tranzakciós műveletek vitatására. Mivel az Ethereum biztosítja az adatelérhetőséget, csökken annak kockázata, hogy az összevont tranzakció operátorai rosszindulatú cselekményeket követnek el (pl. érvénytelen blokkok beküldése). - -### Cenzúraálló kialakítás {#censorship-resistance} - -Az optimista összevont tranzakciók szintén az Ethereumra támaszkodnak a cenzúrának való ellenállás tekintetében. Egy optimista összevont tranzakció esetében egy centralizált entitás (az operátor) felelős a tranzakciók feldolgozásáért és az összevonttranzakció-blokkok Ethereumba való beküldéséért. Ennek van néhány következménye: - -- az összevont tranzakció operátorai cenzúrázhatják a felhasználókat azáltal, hogy teljesen offline állapotba kerülnek, vagy megtagadják az olyan blokkok előállítását, amelyek bizonyos tranzakciókat tartalmaznak. - -- az összevont tranzakció-operátorai megakadályozhatják, hogy a felhasználók az összevont tranzakciós szerződésben elhelyezett pénzeszközöket kivegyék, azáltal, hogy visszatartják a tulajdonlás Merkle-bizonyítékához szükséges státuszadatokat. A státuszadatok visszatartása az összevont tranzakció státuszát is elrejtheti a felhasználók elől, és megakadályozhatja őket abban, hogy interakcióba lépjenek vele. - -Az optimista összevont tranzakciók úgy oldják meg ezt a problémát, hogy az operátorokat arra kényszerítik, hogy az státuszfrissítésekhez kapcsolódó adatokat közzétegyék az Ethereumon. az összevont tranzakciós adatok láncon történő közzététele a következő előnyökkel jár: - -- Ha egy optimista összevont tranzakció operátora nem elérhető vagy leállítja a tranzakciós kötegek előállítását, egy másik csomópont a rendelkezésre álló adatok segítségével reprodukálhatja az összevont tranzakció utolsó státuszát, és folytathatja a blokkok előállítását. - -- A felhasználók a tranzakciós adatok segítségével Merkle-bizonyítékokat hozhatnak létre, amelyek igazolják a pénzeszközök tulajdonjogát, és kivehetik eszközeiket az összevont tranzakcióból. - -- A felhasználók a szekvenszer helyett az L1-en is benyújthatják tranzakcióikat, ebben az esetben a szekvenszernek egy bizonyos időn belül be kell vonnia a tranzakciót, hogy továbbra is érvényes blokkokat tudjon előállítani. - -### Elszámolás {#settlement} - -Egy másik szerep, amelyet az Ethereum az optimista összevont tranzakciókkal összefüggésben játszik, az elszámolási réteg szerepe. Az elszámolási réteg lehorgonyozza az egész blokklánc-ökoszisztémát, biztonságot teremt, és objektív véglegességet biztosít, ha egy másik láncon (ebben az esetben optimista összevont tranzakción) olyan vita merül fel, amely egyeztetést igényel. - -Az Ethereum főhálózat egy középpontot biztosít az optimista összevont tranzakciók számára a csalási bizonyítékok ellenőrzéséhez és a viták rendezéséhez. Ráadásul az összevont tranzakción végrehajtott tranzakciók csak _azután_ lesznek véglegesek, hogy az összevonttranzakció-blokkot az Ethereum elfogadta. Ha egy összevont tranzakciót egyszer már elkötelezettnek vettek az Ethereum alaprétegén, azt nem lehet visszavonni (kivéve a lánc átszervezésének igen valószínűtlen esetét). - -## Hogyan működnek az optimista összevont tranzakciók? {#how-optimistic-rollups-work} - -### Tranzakcióvégrehajtás és aggregáció {#transaction-execution-and-aggregation} - -A felhasználók tranzakciókat nyújtanak be az operátoroknak, amelyek az optimista összevont tranzakció tranzakcióinak végrehajtását végző csomópontok (node). Az operátor, akit validátornak vagy aggregátornak is nevezhetünk, összesíti a tranzakciókat, tömöríti a mögöttes adatokat, és közzéteszi a blokkot az Ethereumon. - -Habár bárki lehet validátor, az optimista összevont tranzakció validátoroknak kötelezvényt kell adniuk, mielőtt blokkokat állítanak elő, hasonlóan a [letétbe helyezési (proof-of-stake) rendszerhez](/developers/docs/consensus-mechanisms/pos/). Ez a kötelezvény csökkenthető vagy elvehető, ha a validátor érvénytelen blokkot tesz közzé, vagy egy régi, de érvénytelen blokkra épít (még ha a blokkja érvényes is). Az optimista összevont tranzakciók kriptogazdasági ösztönzőket alkalmaznak annak biztosítására, hogy a validátorok becsületesen járjanak el. - -Az optimista összevonttranzakció-lánc többi validátorának a benyújtott tranzakciókat az összevont tranzakció státusza másolatának felhasználásával kell végrehajtaniuk. Ha a validátor végső státusza eltér az operátor által javasolt állapottól, akkor megkérdőjelezheti azt, és kikalkulálhatja a csalási bizonyítékot. - -Bizonyos optimista összevont tranzakciók egy szekvenszert használnak a lánc végrehajtásához, és nem egy engedélymentes validáló rendszert. A szekvenszer a validátorhoz hasonlóan feldolgozza a tranzakciókat, összevonttranzakció-blokkokat hoz létre, és az összevont tranzakciókat az L1 láncba (Ethereum) küldi. - -A szekvencer különbözik a hagyományos rollup-operátortól, mert nagyobb befolyása van a tranzakciók sorrendjére. Emellett a szekvenszer elsőbbségi hozzáféréssel rendelkezik az összevonttranzakció-lánchoz, és ő az egyetlen olyan entitás, amely jogosult tranzakciókat benyújtani a láncon belüli szerződéshez. A nem szekvenszer csomópontoktól vagy a felhasználóktól származó tranzakciók egy külön tárolóban várakoznak, amíg a szekvenszer be nem illeszti azokat egy új kötegbe. - -#### Összevonttranzakció-blokkok beküldése az Ethereumra {#submitting-blocks-to-ethereum} - -Az optimista összevont tranzakció operátora a láncon kívüli tranzakciókat egy kötegbe gyűjti, és elküldi az Ethereumnak hitelesítésre. Ez a folyamat magában foglalja a tranzakciókkal kapcsolatos adatok tömörítését és közzétételét az Ethereumban `calldata` mezőként vagy blobokban. - -A `calldata` az okosszerződésben egy nem módosítható, nem állandó terület, amely a [memóriához](/developers/docs/smart-contracts/anatomy/#memory) hasonlóan viselkedik. A `calldata` a blokklánc [historikus naplóinak](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) részeként fennmarad a láncban, de az Ethereum státusz részeként nem tárolódik. Mivel a `calldata` nem érinti az Ethereum státuszát, ezért olcsóbb, mintha az adatokat a láncban kellene tárolni. - -A `calldata` kulcsszót a Solidityben arra is használják, hogy végrehajtáskor argumentumokat adjanak át egy okosszerződés-függvénynek. A `calldata` azonosítja a tranzakció során meghívott függvényt, és a függvény bemeneteit egy tetszőleges bájtsorozat formájában tartalmazza. - -Az optimista összevont tranzakciók a `calldata`-t arra használják, hogy a tömörített tranzakciós adatokat a láncon belüli szerződéshez küldik. az összevont tranzakció operátora úgy ad be új köteget, hogy az összevont tranzakciós szerződésben szereplő függvényt meghívja és a tömörített adatokat függvényargumentumként átadja. A `calldata` használata csökkenti a felhasználói díjakat, mivel az összevont tranzakciók legtöbb költsége az adatok láncban történő tárolásából származik. - -Itt megtekinthet egy [példát](https://etherscan.io/tx/0x9102bfce17c58b5fc1c974c24b6bb7a924fb5fbd7c4cd2f675911c27422a5591) egy összevonttranzakció-köteg benyújtására, mely bemutatja a koncepció működését. A szekvenszer meghívta a `appendSequencerBatch()` metódust, és a tömörített tranzakciós adatokat a `calldata` segítségével adta át bemenetként. - -Néhány összevont tranzakció blobot használ, hogy a tranzakciókötegeket az Ethereumon letárolja. - -A blobok nem módosíthatók és nem állandóak (ahogy a `calldata` is), de kb. 18 nap múlva levágják azokat az előzményadatokról. A blobokkal kapcsolatos további információkért tekintse meg [Danksharding](/roadmap/danksharding) oldalt. - -### Státuszrögzítések {#state-commitments} - -Az optimista összevont tranzakció státusza (számlák, egyenlegek, szerződéskódok stb.) egy [Merkle-fa](/whitepaper/#merkle-trees) vagy státuszfa formájába szerveződik. Ennek a Merkle-fának a gyökerét (státuszgyökér), amely az összevont tranzakció legutóbbi státuszát mutatja, az összevont tranzakciós szerződés hash-eli és tárolja. A láncon minden státuszváltozás egy új összevonttranzakció-státuszt hoz létre, amelyet az operátor egy új státuszgyökér kiszámításával rögzít. - -Az operátornak a kötegek beküldésekor be kell nyújtania a régi és az új státuszgyökereket. Ha a régi státuszgyökér megegyezik a láncon lévő szerződésben lévő státuszgyökérrel, az utóbbit elvetik, és az új státuszgyökérrel helyettesítik. - -az összevont tranzakció operátorának a tranzakcióköteg Merkle-gyökerét is rögzítenie kell. Ez lehetővé teszi, hogy bárki bizonyítsa egy tranzakciónak a kötegbe való felvételét (L1-en) egy [Merkle-bizonyíték](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) bemutatásával. - -Egy optimista összevont tranzakcióban a státuszelköteleződések, különösen a státuszgyökerek szükségesek a státuszváltozások helyességének bizonyításához. az összevont tranzakciós szerződés azonnal elfogadja az új státuszgyökereket az operátoroktól, de később törölheti az érvényteleneket, hogy visszaállítsa az összevont tranzakció helyes állapotát. - -### Csalásbizonyítás {#fraud-proving} - -Az optimista összevont tranzakciók lehetővé teszik bárki számára, hogy blokkokat tegyen közzé az érvényesség igazolása nélkül. Annak érdekében azonban, hogy a lánc biztonságos maradjon, az optimista összevont tranzakciók meghatároznak egy időablakot, amely alatt bárki vitathatja a státuszváltozást. Ezért az összevonttranzakció-blokkokat „állításoknak” nevezik, mivel bárki vitathatja érvényességüket. - -Ha valaki vitatja az állítást, akkor az összevonttranzakció-protokoll elindítja a csalási bizonyíték kiszámítását. A csalási bizonyíték interaktív, valaki közzétesz egy állítást, majd egy másik személy megkérdőjelezi azt. A bizonyítéktípusok eltérhetnek abban, hogy hány körös interakcióra van szükség a csalási bizonyíték kiszámításához. - -Az egykörös interaktív bizonyítási rendszerek újra lejátsszák a vitatott tranzakciókat az L1-en az érvénytelen állítások felderítésére. az összevonttranzakció-protokoll a vitatott tranzakció újbóli végrehajtását versenyezteti az L1-en (Ethereum) egy hitelesítőszerződés segítségével, és a kiszámított státuszgyökér határozza meg, hogy ki nyeri a kihívást. Ha a kihívónak az összevont tranzakció helyes státuszára vonatkozó állítása helytálló, az operátort megbüntetik a kötelezvényének csökkentésével. - -A csalás felderítése érdekében a tranzakciók újbóli végrehajtása az L1-en megköveteli az egyes tranzakciók státuszelköteleződéseinek közzétételét, és növeli a láncban közzéteendő adatok számát. A tranzakciók újrajátszása jelentős gázköltségekkel is jár. Ezen okok miatt az optimista összevont tranzakciók áttérnek a többkörös interaktív bizonyításra, amely az érvénytelen összevonttranzakció-műveletek felderítését hatékonyabban éri el. - -#### Többkörös interaktív bizonyítás {#multi-round-interactive-proving} - -A többfordulós interaktív bizonyítás magában foglal egy oda-vissza kommunikáló protokollt az állító és a kihívó között, amelyet egy L1 hitelesítőszerződés felügyel, és amely végül eldönti, hogy kinek az állítása helytelen. Miután egy L2 csomópont megtámad egy állítást, az állítónak két egyenlő részre kell osztania a vitatott állítást. Ekkor minden állítás ugyanannyi számítási lépést tartalmaz, mint a többi. - -A kihívó ezután kiválasztja, hogy melyik állítást kívánja megtámadni. A felosztási folyamat, vagyis a kettéosztó protokoll addig folytatódik, amíg mindkét fél nem vitatja a végrehajtás _adott_ lépéséről szóló állítást. Ezen a ponton az L1 szerződés megoldja a vitát azzal, hogy kiértékeli az utasítást (és annak eredményét), hogy elkapja a vétkes felet. - -Az állítónak „egylépéses bizonyítékot” kell benyújtania, amely igazolja a vitatott lépés számításának érvényességét. Ha az állító nem tudja megadni az egylépéses bizonyítékot, vagy az L1-ellenőrző érvénytelennek ítéli azt, akkor elveszíti a kihívást. - -Néhány megjegyzés az ilyen típusú csalási bizonyítékról: - -1. A többfordulós interaktív csalási bizonyíték azért hatékony, mert minimálisra csökkenti az L1-lánc által a viták eldöntése során elvégzendő munkát. A teljes tranzakció újrajátszása helyett az L1-nek csak egy lépést kell elvégeznie az összevont tranzakció végrehajtásában. - -2. A kettéosztó protokollok csökkentik a láncban közzétett adatok mennyiségét (nem kell minden tranzakcióhoz státuszváltozást közzétenni). Az optimista összevont tranzakciókat nem korlátozza az Ethereum gázlimitje. Ehhez képest a tranzakciókat újra végrehajtó optimista összevont tranzakcióoknak meg kell győződniük arról, hogy egy L2 tranzakció alacsonyabb gázlimittel rendelkezik, hogy versenyeztetni tudják annak végrehajtását egy Ethereum tranzakción belül. - -3. A rosszhiszemű állító kötelezvényének egy részét a kihívó kapja, míg a másik részét elégetik. Az égetés megakadályozza a validátorok közötti összejátszást; ha két validátor összejátszik, hogy hamis kihívásokat kezdeményezzen, akkor is elveszítik a letét jelentős részét. - -4. A többfordulós interaktív bizonyítás megköveteli, hogy az állító és a kihívó a megadott időkereten belül lépéseket tegyen. Aki a határidő lejárta előtt nem cselekszik, az elveszíti a kihívást. - -#### Miért fontosak a csalási bizonyítékok az optimista összevont tranzakcióknál {#fraud-proof-benefits} - -A csalási bizonyítékok azért fontosak, mert megkönnyítik a _bizalomigény-mentes véglegességet_ az optimista összevont tranzakcióknál. A bizalomigény-mentes véglegesség az optimista összevont tranzakciók olyan tulajdonsága, amely garantálja, hogy egy tranzakció – amennyiben érvényes – végül visszaigazolásra kerül. - -A rosszhiszemű csomópontok hamis megkérdőjelezésekkel megpróbálhatják késleltetni egy érvényes rollup-blokk megerősítését. A csalási bizonyítékok azonban végül igazolni fogják az összevonttranzakció-blokk érvényességét, és megerősítik azt. - -Ez kapcsolódik az optimista összevont tranzakciók egy másik biztonsági tulajdonságához is: a lánc érvényessége azon múlik, hogy legyen (legalább) _egy_ jóhiszemű csomópont. A jóhiszemű csomópont a láncot megfelelően tovább tudja vinni azáltal, hogy érvényes állításokat tesz közzé, vagy vitatja az érvénytelen állításokat. Bárhogy is legyen, a jóhiszemű csomópontokkal vitába szálló rosszhiszemű csomópontok a csalási bizonyíték előállítása során elveszítik letétjeiket. - -### L1/L2 interoperabilitás {#l1-l2-interoperability} - -Az optimista összevont tranzakciókat az Ethereum főhálózattal való interoperabilitásra tervezték, és ezáltal a felhasználók üzeneteket és tetszőleges adatokat továbbíthatnak L1 és L2 között. Az EVM-mel is kompatibilisek, így a meglévő [alkalmazásokat](/developers/docs/dapps/) át lehet vinni az optimista összevont tranzakciókra, vagy új dappokat lehet létrehozni az Ethereum fejlesztői eszközeivel. - -#### 1. Eszközmozgás {#asset-movement} - -##### Belépés az összevont tranzakció-ba - -Egy optimista összevont tranzakció használatához a felhasználók ETH-t, ERC-20 tokeneket és más elfogadott eszközöket helyeznek el az összevont tranzakció [hídjának](/developers/docs/bridges/) szerződésében az L1-en. A hídszerződés továbbítja a tranzakciót az L2-hez, ahol a tranzakcióval megegyező mennyiségű eszközt bocsátanak ki és küldenek a felhasználó által az optimista összevont tranzakción kiválasztott címre. - -A felhasználó által generált tranzakciók (mint például egy L1 > L2 befizetés) bekerülnek a sorba, majd a szekvenszer elküldi azokat az összevont tranzakciós szerződésnek. A cenzúrával szembeni ellenállás megőrzése érdekében azonban az optimista összevont tranzakciók lehetővé teszik a felhasználók számára, hogy közvetlenül a láncon belüli összevont tranzakciós szerződéshez nyújtsanak be egy tranzakciót, ha az egy bizonyos ideig nem kerül feldolgozásra. - -Egyes optimista összevont tranzakciók egyszerűbb megközelítést alkalmaznak annak megakadályozására, hogy a szekvenszerek cenzúrázzák a felhasználókat. Ekkor egy blokkot az L1 szerződéshez az előző blokk óta benyújtott összes tranzakció (pl. befizetések) határoz meg, az összevonttranzakció-láncban feldolgozott tranzakciókon kívül. Ha egy szekvenszer figyelmen kívül hagy egy L1 tranzakciót, akkor (bizonyíthatóan) rossz státuszgyökeret fog közzétenni; ezért a szekvenszerek nem késleltethetik a felhasználó által generált üzeneteket, miután azokat az L1-en közzétették. - -##### Kilépés az összevont tranzakcióból - -Az optimista összevont tranzakcióból az Ethereumra való visszavétel a csalást bizonyító rendszer miatt nehezebb. Ha egy felhasználó L2 > L1 tranzakciót kezdeményez az L1-en letétbe helyezett pénzeszközök kivonására, akkor meg kell várnia, amíg a megkérdőjelezési időszak – amely nagyjából hét napig tart – letelik. Mindazonáltal maga a visszavonási folyamat egyszerű. - -Miután a kifizetési kérelmet az L2 összevont tranzakción kezdeményezték, a tranzakció bekerül a következő kötegbe, miközben a felhasználó összevont tranzakción lévő eszközei elégetésre kerülnek. Miután a köteget közzétették az Ethereumon, a felhasználó kiszámíthatja a Merkle-bizonyítékot, amely igazolja, hogy a kilépési tranzakciója bekerült a blokkba. Ezután csak ki kell várni a késleltetési időszakot, hogy véglegesedjen a tranzakció az L1-en, és kivehesse a pénzt a főhálózatra. - -Annak érdekében, hogy ne kelljen egy hetet várni az Ethereumba történő pénzkivonás előtt, az optimista összevont tranzakció felhasználói alkalmazhatnak egy **likviditási szolgáltatót** (LP). A likviditásszolgáltató átveszi a függőben lévő L2 kivonás tulajdonjogát, és fizet a felhasználónak az L1-en (díj ellenében). - -A likviditásszolgáltatók a pénzeszközök felszabadítása előtt ellenőrizhetik a felhasználó kifizetési kérelmének érvényességét (végrehajtják a láncot). Így biztosítékot kapnak arra, hogy a tranzakciót végül meg fogják erősíteni (a bizalomigény-mentes véglegesség miatt). - -#### 2. EVM-kompatibilitás {#evm-compatibility} - -A fejlesztők számára az optimista összevont tranzakciók előnye az, hogy kompatibilisek – vagy még jobb, hogyha egyenértékűek – a [Ethereum virtuális géppel (EVM)](/developers/docs/evm/). Az EVM-kompatibilis összevont tranzakciók megfelelnek az [Ethereum sárgakönyv](https://ethereum.github.io/yellowpaper/paper.pdf) specifikációinak, és bytecode szinten támogatják az EVM-et. - -Az EVM-kompatibilitás az optimista összevont tranzakcióknál a következő előnyökkel jár: - -i. A fejlesztők az Ethereumon meglévő okosszerződéseket optimista összevont tranzakció-láncokra migrálhatják anélkül, hogy a kódbázisokat nagy mértékben módosítaniuk kellene. Ez időt takaríthat meg a fejlesztőcsapatoknak az Ethereum okosszerződések L2-re történő telepítésekor. - -ii. Az optimista összevont tranzakciókat használó fejlesztők és projektcsapatok kihasználhatják az Ethereum infrastruktúrájának előnyeit. Ide tartoznak a programozási nyelvek, kódkönyvtárak, tesztelési eszközök, kliensszoftverek, telepítési infrastruktúra stb. - -A meglévő eszközök használata azért fontos, mert ezeket az évek során alaposan ellenőrizték és kijavították a hibáikat. Emellett az Ethereum fejlesztőknek nem kell megtanulniuk, hogyan kell egy teljesen új fejlesztői stackkel programot fejleszteni. - -#### 3. Láncok közötti szerződésmeghívások {#cross-chain-contract-calls} - -A felhasználók (külső tulajdonú számlák) úgy lépnek kapcsolatba az L2 szerződésekkel, hogy tranzakciót küldenek az összevont tranzakció-szerződésnek, vagy ugyanezt egy szekvenszerrel vagy validátorral végeztetik el. Az optimista összevont tranzakciók azt is lehetővé teszik, hogy az Ethereumon lévő szerződéses számlák interakcióba lépjenek az L2 szerződésekkel az L1 és L2 közötti üzenetek és adatok továbbítására szolgáló hídszerződések révén. Ez azt jelenti, hogy az Ethereum főhálózaton lévő (L1) szerződést úgy lehet programozni, hogy az L2 optimista összevont tranzakción lévő szerződésekhez tartozó funkciókat hívjon meg. - -A láncközi szerződéses hívások aszinkron módon történnek, vagyis a hívást először kezdeményezik, majd egy későbbi időpontban hajtják végre. Ez eltér az Ethereumon történő, két szerződés közötti hívásoktól, mivel annak azonnali eredménye van. - -A láncközi szerződéskötésre példa a korábban ismertetett token-letétbehelyezés. Az L1-en lévő szerződés letétbe helyezi a felhasználó tokenjeit, és üzenetet küld az L2 szerződésnek, hogy bocsásson ki ugyanannyi tokent az összevont tranzakción. - -Mivel a láncközi üzenethívások szerződésvégrehajtást eredményeznek, a feladónak fedeznie kell a számítás [gázköltségeit](/developers/docs/gas/). Ehhez célszerű magas gázhatárt beállítani, hogy elkerülje a tranzakció meghiúsulását a célláncon. A tokenek híddal való mozgatása jó példa erre, mert ha a tranzakció L1 oldala (a tokenek letétbe helyezése) működik, de az L2 oldal (új tokenek kibocsátása) az alacsony gázmennyiség miatt meghiúsul, a letét behajthatatlanná válik. - -Végül fontos tudni, hogy a szerződések közötti L2 > L1 üzenethívások néhány perc elteltével kerülnek végrehajtásra. Ennek az az oka, hogy az optimista összevont tranzakcióból a főhálózatra küldött üzeneteket nem lehet végrehajtani, amíg a megkérdőjelezési időszak le nem jár. - -## Hogyan működnek az optimista összevont tranzakciós díjak? {#how-do-optimistic-rollup-fees-work} - -Az optimista összevont tranzakciók az Ethereumhoz hasonlóan gázdíjrendszert használnak annak jelölésére, hogy a felhasználók mennyit fizetnek tranzakciónként. Az optimista összevont tranzakciók után felszámított díjak a következő összetevőktől függenek: - -1. **Státuszrögzítés**: Az optimista összevont tranzakciók a tranzakciós adatokat és a blokkfejléceket (amelyek az előző blokkfejléc hash-éből, a státuszgyökérből és a köteggyökérből állnak) `blobként` vagy egy „binárisan nagy objektumként” teszik közzé az Ethereumon. [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) bevezetett egy költséghatékony megoldást az adat láncon belüli tárolására. A `blob` egy új tranzakciós mező, mellyel az összevont tranzakciók képesek tömörített státuszváltozást rögzíteni az Ethereumon (L1). A `calldata` mezőhöz képest, mely állandóan elérhető a láncon, a blobok rövid életűek és levághatók a kliensekről [4096 korszak után](https://github.com/ethereum/consensus-specs/blob/81f3ea8322aff6b9fb15132d050f8f98b16bdba4/configs/mainnet.yaml#L147) (kb.18 nappal később). A blobok használatával, melyekbe a tömörített tranzakciós adatok kötegeit teszik, az optimista összevont tranzakciók jelentősen csökkentették annak költségét, hogy a tranzakciók bekerüljenek az L1-re. - -2. A **Blob gázhasználata**: a blobot igénylő tranzakciók egy dinamikus díjmechanizmust használnak, amely hasonlít az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) által bevezetetthez. A 3-as típusú tranzakciók gázdíja egy alap blobdíjjal számol, melyet a hálózat határoz meg a blobhelyre való kereslet és a küldött tranzakció blobhely használata alapján. - -3. **L2 operátordíjak**: Ezt az összevonttranzakció-csomópontnak fizetik a tranzakciók feldolgozása során felmerülő számítási költségek ellentételezéseként, hasonlóan az Ethereum gázdíjaihoz. az összevonttranzakció-csomópontok alacsonyabb tranzakciós díjakat számítanak fel, mivel az L2-k nagyobb feldolgozási kapacitással rendelkeznek, és nincsenek olyan hálózati torlódásaik, amelyek miatt az Ethereum validálói magasabb díjú tranzakciókat részesítenek előnyben. - -Az optimista összevont tranzakciók számos mechanizmust alkalmaznak a felhasználói díjak csökkentésére, beleértve a tranzakciók kötegelését és a `calldata` tömörítését az adatpublikálási költségek csökkentése érdekében. Az [L2 díjkövető](https://l2fees.info/) oldalon valós idejű áttekintést kaphat arról, hogy mennyibe kerül az Ethereum-alapú optimista összevont tranzakciók használata. - -## Hogyan skálázzák az optimista összevont tranzakciók az Ethereumot? {#scaling-ethereum-with-optimistic-rollups} - -Az optimista összevont tranzakciók az adatelérhetőség biztosítása érdekében tömörített tranzakciós adatokat tesznek közzé az Ethereumban. A láncban közzétett adatok tömörítésének képessége alapvető fontosságú ahhoz, hogy az Ethereumon skálázni lehessen a tranzakcióátvitelt az optimista összevont tranzakciókkal. - -Az Ethereum korlátozza, hogy mennyi adatot tartalmazhatnak a blokkok, gázegységekben kifejezve (az [átlagos blokkméret](/developers/docs/blocks/#block-size) 15 millió gáz). Bár ez korlátozza, hogy az egyes tranzakciók mennyi gázt használhatnak fel, azt is jelenti, hogy a tranzakciókhoz kapcsolódó adatok csökkentésével növelhetjük a blokkonként feldolgozott tranzakciók számát, ami közvetlenül javítja a skálázhatóságot. - -Az optimista összevont tranzakciók többféle technikát használnak a tranzakciós adatok tömörítésének elérésére és a másodpercenkénti tranzakciószám (TPS) javítására. Ez a [cikk](https://vitalik.eth.limo/general/2021/01/05/rollup.html) például összehasonlítja, hogy egy egyszerű felhasználói tranzakció (ether küldése) mennyi adatot generál a főhálózaton és az összevont tranzakció-on: - -| Paraméter | Ethereum (L1) | Összevont tranzakció (L2) | -| ------------ | ------------------------- | ------------------------- | -| Nonce | ~3 | 0 | -| Gázár | ~8 | 0–0,5 | -| Gáz | 3 | 0–0,5 | -| Címzett | 21 | 4 | -| Érték | 9 | ~3 | -| Aláírás | ~68 (2 + 33 + 33) | ~0,5 | -| Küldő | 0 (az aláírásból kinyeri) | 4 | -| **Összesen** | **~112 bájt** | **~12 bájt** | - -Néhány hozzávetőleges számítás ezekkel a számokkal segíthet megmutatni az optimista összevont tranzakció által biztosított skálázhatósági javulást: - -1. Az egyes blokkok célmérete 15 millió gáz, és egy bájt adat ellenőrzése 16 gázba kerül. Ha az átlagos blokkméretet elosztjuk 16 gázzal (15 000 000/16), akkor az átlagos blokkba **937 500 bájtnyi adat fér**. -2. Ha egy alap összevont tranzakció 12 bájtot használ, akkor egy átlagos Ethereum-blokk **78 125 összevont tranzakciót** (937 5000/12) vagy **39 összevonttranzakció-köteget** tud feldolgozni (ha minden egyes köteg átlagosan 2000 tranzakciót tartalmaz). -3. Ha az Ethereumon 15 másodpercenként keletkezik egy új blokk, akkor az összevont tranzakció feldolgozási sebessége nagyjából **5208 tranzakciót jelent másodpercenként**. Ez úgy történik, hogy az egy Ethereum-blokkban tárolható alap összevont tranzakciók számát (**78 125**) elosztjuk az átlagos blokkidővel (**15 másodperc**). - -Ez egy meglehetősen optimista becslés, tekintve, hogy az optimista összevont tranzakciók nem tudnak egy teljes blokkot alkotni az Ethereumon. Ugyanakkor nagyjából képet adhat arról, hogy az optimista összevont tranzakciók mekkora skálázhatósági nyereséget biztosíthatnak az Ethereum-felhasználóknak (a jelenlegi implementációk akár 2000 TPS-t is kínálnak). - -Az [adat sharding](/roadmap/danksharding/) bevezetése az Ethereumban várhatóan javítja a skálázhatóságot az optimista összevont tranzakciók esetén. Mivel az összevont tranzakcióknak más, nem összevont tranzakciókkal kell megosztaniuk a blokkteret, feldolgozási kapacitásukat az Ethereum adatátviteli kapacitása korlátozza. A Danksharding növeli az L2 láncok számára rendelkezésre álló helyet az adatok blokkonkénti közzétételéhez, a drága, állandó `CALLDATA` helyett olcsóbb, nem állandó „blob” tárhelyet használva. - -### Az optimista összevont tranzakciók előnyei és hátrányai {#optimistic-rollups-pros-and-cons} - -| Előnyök | Hátrányok | -| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Hatalmas javulást kínál a skálázhatóság terén a biztonság és a megbízhatóság csökkenése nélkül. | A tranzakció véglegesítésének késedelme a lehetséges csalási kihívások miatt. | -| A tranzakciós adatokat az L1-en tárolják, ami javítja az átláthatóságot, a biztonságot, a cenzúrával szembeni ellenállást és a decentralizációt. | A centralizált összevonttranzakció-operátorok (szekvenszerek) befolyásolhatják a tranzakciók sorrendjét. | -| A csalási bizonyíték garantálja a bizalomigény-mentes véglegességet, és lehetővé teszi, hogy kevés jóhiszemű résztvevő is biztosítani tudja a láncot. | Ha nincsenek jóhiszemű csomópontok, egy rosszhiszemű operátor ellophat pénzeszközöket érvénytelen blokkok és státuszelköteleződések közzétételével. | -| A csalási bizonyítékok kiszámítása a hagyományos L2 csomópontok számára is elérhető, ellentétben az érvényességi bizonyításokkal (amelyeket a ZK összevont tranzakciókat használnak), amelyekhez speciális hardverre van szükség. | A biztonsági modellhez szükséges legalább egy jóhiszemű csomópont, amely összevont tranzakciókat hajt végre és csalási bizonyítékokat nyújt be az érvénytelen státuszváltozások megtámadására. | -| az összevont tranzakciók a „bizalomigény-mentes elérhetőség” előnyeit élvezik (bárki működésre kényszerítheti a láncot a tranzakciók végrehajtásával és az állítások elküldésével). | A felhasználóknak meg kell várniuk az egyhetes kihívási időszak lejártát, mielőtt visszavennék a pénzüket az Ethereumba. | -| Az optimista összevont tranzakciók jól megtervezett kriptogazdasági ösztönzőkre támaszkodnak a lánc biztonságának növelése érdekében. | A összevont tranzakcióknak minden tranzakciós adatot a láncban kell közzétenniük, ami növelheti a költségeket. | -| Az EVM-mel és a Solidityvel való kompatibilitás lehetővé teszi a fejlesztők számára, hogy Ethereum-natív okosszerződéseket telepítsenek a összevont tranzakciókba, vagy a meglévő eszközöket használják új dappok létrehozásához. | | - -### Az optimista összevont tranzakciók vizuális bemutatása {#optimistic-video} - -Ön inkább vizuális típus? Nézze meg a videót, melyben a Finematics elmagyarázza az optimista összevont tranzakciók lényegét: - - - -### Optimista összevont tranzakciók használata {#use-optimistic-rollups} - -Az optimista összevont tranzakcióknak többféle megvalósítása létezik, amelyeket integrálhat a dappjaiba: - - - -## További információk az optimista összevont tranzakciókról - -- [Hogyan működnek az optimista összevont tranzakciók (teljes útmutató)](https://www.alchemy.com/overviews/optimistic-rollups) -- [Mi az a blokklánc összevont tranzakció? Technikai bevezetés](https://www.ethereum-ecosystem.com/blog/what-is-a-blockchain-rollup-a-technical-introduction) -- [Az alapvető útmutató az Arbitrumhoz](https://newsletter.banklesshq.com/p/the-essential-guide-to-arbitrum) -- [Hogyan működik valójában az optimista összevont tranzakció?](https://www.paradigm.xyz/2021/01/how-does-optimisms-rollup-really-work) -- [Az OVM részletes bemutatása](https://medium.com/ethereum-optimism/ovm-deep-dive-a300d1085f52) -- [Mi az az optimista virtuális gép?](https://www.alchemy.com/overviews/optimistic-virtual-machine) diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" deleted file mode 100644 index 5e53cd5d0bf..00000000000 --- "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/plasma/index.md" +++ /dev/null @@ -1,175 +0,0 @@ ---- -title: Plazmaláncok -description: Bevezetés a plazmaláncokba, az Ethereum közössége által használt skálázási megoldásba. -lang: hu -incomplete: true -sidebarDepth: 3 ---- - -A plazmalánc egy külön blokklánc, amely az Ethereum főhálózathoz van rögzítve, de a tranzakciókat a láncon kívül hajtja végre, saját blokkvalidálási mechanizmussal. A plazmaláncokat néha „gyerekláncoknak” is nevezik, mivel lényegében az Ethereum főhálózat kisebb másolatai. A plazmaláncok [csalási bizonyítékokat](/glossary/#fraud-proof) használnak (ahogy az [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/)), hogy így döntsék el a vitákat. - -A Merkle-fák lehetővé teszik ezen láncok végtelen halmazának létrehozását, amelyek képesek a szülői láncok (beleértve az Ethereum főhálózatot is) sávszélességének tehermentesítésére. Bár ezek a láncok az Ethereumból merítenek némi biztonságot (csalási bizonyítékokon keresztül), biztonságukat és hatékonyságukat számos tervezési korlát befolyásolja. - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértéséhez érdemes ismernie az alapvető témaköröket és az [Ethereum skálázását](/developers/docs/scaling/). - -## Mi az a plazma? - -A plazma egy keretrendszer a nyilvános blokkláncok, például az Ethereum skálázhatóságának javítására. Az eredeti [plazma fehérkönyv](http://plasma.io/plasma.pdf) leírása szerint a plazmaláncok egy másik blokkláncra (az úgynevezett „gyökérláncra”) épülnek. Minden „gyereklánc” a gyökérláncból indul ki, és általában a szülői láncra telepített okosszerződés kezeli. - -A plazmaszerződés többek között [hídként](/developers/docs/bridges/) működik, amely lehetővé teszi a felhasználók számára az eszközök mozgatását az Ethereum főhálózat és a plazmalánc között. Bár emiatt nagyon hasonlítanak a [mellékláncokhoz](/developers/docs/scaling/sidechains/), a plazmaláncok viszont – bizonyos mértékig – az Ethereum főhálózat biztonságából profitálnak. Ez ellentétben áll a mellékláncokkal, amelyek maguk felelnek a biztonságukért. - -## Hogyan működik a plazma? - -A plazmakeretrendszer alapvető összetevői a következők: - -### Láncon kívüli számítás {#off-chain-computation} - -Az Ethereum jelenlegi feldolgozási sebessége kb. 15–20 tranzakcióra korlátozódik másodpercenként, ami csökkenti annak lehetőségét, hogy rövid távon skálázásható legyen és több felhasználót tudjon kezelni. Ez a probléma elsősorban azért áll fenn, mert az Ethereum [konszenzusmechanizmusa](/developers/docs/consensus-mechanisms/) sok egyenrangú csomópontot igényel a blokklánc státuszváltozásainak ellenőrzéséhez. - -Bár az Ethereum konszenzusmechanizmusa szükséges a biztonsághoz, nem biztos, hogy minden felhasználási esetre alkalmazható. Például ha Alice naponta fizetett Bobnak egy csésze kávét, akkor ezeket az összegeket nem feltétlen kell az egész Ethereum-hálózatnak ellenőriznie, mivel a felek között fennáll némi bizalom. - -A plazma feltételezi, hogy az Ethereum főhálózatának nem kell minden tranzakciót ellenőriznie. Ehelyett a tranzakciókat a főhálózaton kívül is feldolgozhatjuk, így a csomópontoknak nem kell minden tranzakciót hitelesíteniük. - -Láncon kívüli számításra van szükség, hogy a plazmaláncok optimalizálhassák a sebességet és a költségeket. Például a plazmalánc alkalmazhat egy operátort a tranzakciók sorrendjének és végrehajtásának kezelésére – és a legtöbbször így is tesz. Mivel csak egy entitás ellenőrzi a tranzakciókat, a plazmalánc feldolgozási ideje gyorsabb, mint az Ethereum főhálózaté. - -### Státuszrögzítések {#state-commitments} - -Bár a plazma a tranzakciókat a láncon kívül hajtja végre, azok elszámolása az Ethereum fő végrehajtási rétegén történik – ellenkező esetben a plazmaláncok nem élvezhetik az Ethereum biztonsági garanciáit. De a láncon kívüli tranzakciók véglegesítése a plazmalánc státuszának ismerete nélkül megtörné a biztonsági modellt, és lehetővé tenné az érvénytelen tranzakciók elterjedését. Ezért az operátornak, aki a plazmalánc blokkjainak előállításáért felel, rendszeresen közzé kell tennie az Ethereumban a státuszelköteleződéseket. - -Az [elköteleződési séma](https://en.wikipedia.org/wiki/Commitment_scheme) egy olyan kriptográfiai technika, amellyel egy érték vagy állítás mellett elköteleződhetünk anélkül, hogy azt egy másik fél számára felfednénk. Az elköteleződések abban az értelemben köteleznek, hogy nem változtathatja meg az értéket vagy az állítást, ha már elkötelezte magát mellette. A státuszelköteleződések a plazmában Merkle-gyökerek formájában jelennek meg (egy [Merkle-fából](/whitepaper/#merkle-trees)), amelyeket az operátor időközönként elküld a plazmaszerződésnek az Ethereum-láncon. - -A Merkle-gyökerek olyan kriptográfiai primitívek, amelyek lehetővé teszik nagy mennyiségű információ tömörítését. Egy Merkle-gyökér (ebben az esetben „blokkgyökér”) egy blokkban lévő összes tranzakciót képviselhet. A Merkle-gyökerek megkönnyítik annak ellenőrzését is, hogy egy kis adatdarab része-e a nagyobb adathalmaznak. A felhasználó például előállíthat egy [Merkle-bizonyítékot](/developers/tutorials/merkle-proofs-for-offline-data-integrity/#main-content), hogy igazolja, egy tranzakció része egy adott blokknak. - -A Merkle-gyökerek fontosak, hogy az Ethereum számára információt adjanak a láncon kívüli státuszról. A Merkle-gyökerekre úgy is gondolhatunk, mint „mentési pontokra”: az operátor kijelenti, hogy „ez a plazmalánc státusza x időpontban, és ez a Merkle-gyökér a bizonyíték”. Az operátor a Merkle-gyökérrel elköteleződik a plazmalánc _aktuális státuszára_, ezért nevezik státuszelköteleződésnek. - -### Belépés és kilépés {#entries-and-exits} - -Ahhoz, hogy az Ethereum-felhasználók kihasználhassák a plazma előnyeit, szükség van egy olyan mechanizmusra, amely lehetővé teszi a pénzeszközök mozgatását a főhálózat és a plazmaláncok között. Nem küldhetünk tetszőlegesen ethert egy plazmaláncon lévő címre – ezek a láncok nem kompatibilisek, így a tranzakció vagy meghiúsulna, vagy elveszne a pénz. - -A plazma egy Ethereumon futó főszerződést használ a felhasználói belépések és kilépések feldolgozására. Ez a főszerződés felelős a státuszkötelezvények követéséért és a tisztességtelen viselkedés büntetéséért csalási bizonyítékok révén (erről később lesz még szó). - -#### Belépés a plazmaláncba {#entering-the-plasma-chain} - -A plazmaláncba való belépéshez Alice-nek (a felhasználónak) ETH-t vagy bármely ERC-20 tokent kell befizetnie a plazmaszerződésbe. A plazmaoperátor, aki figyeli a szerződésbefizetéseket, létrehoz egy összeget, mely megegyezik Alice kezdeti befizetésével, és felszabadítja azt a plazmaláncban lévő címére. Alice-nak tanúsítania kell, hogy a gyerekláncban megkapta a pénzeszközöket, majd ezeket tranzakciókra használhatja. - -#### Kilépés a plazmaláncból {#exiting-the-plasma-chain} - -A plazmaláncból való kilépés több okból is bonyolultabb, mint a belépés. A legnagyobb nehézség az, hogy bár az Ethereum rendelkezik információkkal a plazmalánc státuszáról, nem tudja ellenőrizni, hogy az információ igaz-e vagy sem. Egy rosszhiszemű felhasználó téves állításokat tehet (például: „van 1000 ETH-em”), és megúszhatja azzal, hogy hamis bizonyítékokkal támasztja alá az állítását. - -A hamis visszavonások megelőzése érdekében „megkérdőjelezési időszakot” vezetnek be. A megkérdőjelezési időszak alatt (általában egy hét) bárki megtámadhat egy kifizetési kérelmet csalási bizonyítékkal. Ha a megkérdőjelezés sikeres, akkor a visszavonási kérelmet elutasítják. - -Általában azonban az a helyzet, hogy a felhasználók őszinték, és helyes állításokat tesznek a tulajdonukban lévő pénzeszközökről. Ebben az esetben Alice kezdeményez egy kivételi kérelmet a gyökérláncon (Ethereum) egy tranzakció benyújtásával a plazmaszerződéshez. - -Emellett egy Merkle-bizonyítékot is be kell nyújtania, amely igazolja, hogy a plazmaláncban a pénzét létrehozó tranzakció bekerült egy blokkba. Erre a Plazma olyan iterációi esetében van szükség, mint például a [plazma MVP](https://www.learnplasma.org/en/learn/mvp.html), amelyek [el nem költött tranzakciós kimenet (UTXO/Unspent Transaction Output)](https://en.wikipedia.org/wiki/Unspent_transaction_output) modellt használnak. - -Mások, mint például a [plazma Cash](https://www.learnplasma.org/en/learn/cash.html), UTXO-k helyett [nem helyettesíthető tokenek (NFT)](/developers/docs/standards/tokens/erc-721/) formájában jelenítik meg a pénzalapokat. A pénzeszköz kivételéhez ebben az esetben a tokenek tulajdonjogának igazolása szükséges a plazmaláncon. Ez úgy történik, hogy a tokent érintő két legutóbbi tranzakciót benyújtja, és Merkle-bizonyítékkal igazolja, hogy ezek a tranzakciók bekerültek egy blokkba. - -A felhasználónak a tisztességes viselkedés garanciájaként a visszavonási kérelemhez biztosítékot is kell adnia. Ha a megkérdőjelező bebizonyítja, hogy Alice visszavonási kérelme érvénytelen, akkor a kötelezvényének értékét csökkentik, és annak egy része jutalomként a megkérdőjelezőhöz kerül. - -Ha a megkérdőjelezési időszak anélkül telik el, hogy valaki csalási bizonyítékot adna, Alice kifizetési kérelme érvényesnek minősül, és lehetővé teszi számára, hogy visszaszerezze a letéteket a plazmaszerződésből az Ethereumon. - -### Vitarendezés {#dispute-arbitration} - -Mint minden blokkláncnak, a plazmaláncoknak is szükségük van egy mechanizmusra a tranzakciók integritásának érvényesítésére, amennyiben a résztvevők rosszindulatúan cselekednek (pl. duplán költik el a pénzt). Ebből a célból a plazmaláncok csalási bizonyítékokat használnak a státuszváltozások érvényességével kapcsolatos viták eldöntésére és a rosszhiszemű viselkedés szankcionálására. A csalási bizonyítékok olyan mechanizmusként szolgálnak, amelyen keresztül egy plazma-gyereklánc panaszt nyújt be a szülői lánchoz vagy a gyökérlánchoz. - -A csalási bizonyíték egy olyan állítás, hogy egy adott státuszváltozás érvénytelen. Például ha egy felhasználó (Alice) kétszer próbálja elkölteni ugyanazt a pénzt. Talán elköltötte az UTXO-t egy tranzakcióban Bobbal, és ugyanazt az UTXO-t (ami most Bobé) egy másik tranzakcióban akarja elkölteni. - -A pénzkivétel megakadályozása érdekében Bob csalási bizonyítékot állít össze, hogy Alice az említett UTXO-t egy korábbi tranzakcióban elköltötte, és Merkle-bizonyítékkal bizonyítja, hogy a tranzakció bekerült egy blokkba. Ugyanez a folyamat működik a plazma Cash-ben is – Bobnak bizonyítania kell, hogy Alice korábban átutalta a tokeneket, amelyeket ki akar venni. - -Ha Bob megkérdőjelezése sikeres, akkor Alice visszavonási kérelmét elutasítják. Ez a megközelítés azonban Bob azon képességére támaszkodik, hogy figyelje a láncot a visszavonási kérelmek tekintetében. Ha Bob offline, akkor Alice feldolgozhatja a rosszhiszemű visszavonást, amint letelik a kihívási időszak. - -## A tömeges kilépési probléma a plazmánál {#the-mass-exit-problem-in-plasma} - -A tömeges kilépés problémája akkor jelentkezik, amikor nagyszámú felhasználó egyszerre próbál kilépni egy plazmaláncból. Hogy miért van ez a probléma, az a plazma egyik legnagyobb problémájával függ össze: az **adatok elérhetetlensége**. - -Az adatelérhetőség azt jelenti, hogy ellenőrizni lehet, hogy egy javasolt blokk információit valóban közzétették-e a blokklánc-hálózaton. Egy blokk „nem elérhető”, ha annak készítője magát a blokkot közzéteszi, de a blokk létrehozásához használt adatokat visszatartja. - -A blokkoknak elérhetőnek kell lenniük, hogy a csomópontok le tudják tölteni a blokkot, és ellenőrizni tudják a tranzakciók érvényességét. A blokkláncok biztosítják az adatok elérhetőségét azáltal, hogy a blokkkészítőket arra kényszerítik, hogy minden tranzakciós adatot a láncban tegyenek közzé. - -Az adatelérhetőség abban is segít, hogy az Ethereum alaprétegére épülő, láncon kívüli skálázási protokollok biztosítva legyenek. Azáltal, hogy az ilyen láncok üzemeltetőit arra kényszerítik, hogy tranzakciós adatokat tegyenek közzé az Ethereumban, bárki megtámadhatja az érvénytelen blokkokat a lánc helyes állapotára hivatkozó csalási bizonyítékokkal. - -A plazmaláncok elsősorban a tranzakciós adatokat tárolják az operátoroknál, és **nem tesznek közzé semmilyen adatot a főhálózaton** (csak időszakos státuszelköteleződéseket). Ez azt jelenti, hogy a felhasználóknak az operátorra kell hagyatkozniuk a blokkadatok biztosításában, ha csalási bizonyítékokat kell létrehozniuk, amelyek megkérdőjelezik az érvénytelen tranzakciókat. Ha ez a rendszer működik, akkor a felhasználók bármikor használhatják a csalási bizonyítékokat a pénzeszközök biztosítására. - -A probléma akkor kezdődik, amikor az operátor, nem pedig felhasználó az, aki rosszhiszeműen cselekszik. Mivel az operátor egyedül irányítja a blokkláncot, nagyobb motivációja lehet arra, hogy érvénytelen státuszváltozást hajtson végre, például ellopják a plazmalánc felhasználóihoz tartozó pénzeszközöket. - -Ebben az esetben a klasszikus csalási bizonyíték rendszere nem működik. Az operátor könnyen elvégezhet egy érvénytelen tranzakciót, amellyel Alice és Bob pénzét átutalja a saját tárcájába, és elrejtheti a csalási bizonyítékhoz szükséges adatokat. Ez azért lehetséges, mert az operátor nem köteles az adatokat a felhasználók vagy a főhálózat rendelkezésére bocsátani. - -Ekkor a legoptimistább megoldás az, ha megkíséreljük a felhasználók „tömeges kilépését” a plazmaláncból. A tömeges kilépés lelassítja a rosszhiszemű üzemeltető pénzlopási tervét, és bizonyos fokú védelmet nyújt a felhasználók számára. A kivételi kérelmek az egyes UTXO-k (vagy tokenek) létrehozásának időpontja alapján kerülnek sorrendbe, ami megakadályozza, hogy a rosszhiszemű operátorok a tisztességes felhasználókat megelőzzék. - -Ennek ellenére továbbra is szükségünk van egy olyan módszerre, amellyel a tömeges kilépés során ellenőrizhetjük a kilépési kérelmek érvényességét, hogy megakadályozzuk, hogy az opportunista egyének kihasználják az érvénytelen kilépéseket feldolgozó káoszt. A megoldás egyszerű: megköveteljük a felhasználóktól, hogy a pénzük kivételéhez **a lánc utolsó érvényes státuszát** tegyék közzé. - -Ennek a megközelítésnek azonban még mindig vannak problémái. Ha például egy plazmalánc összes felhasználójának ki kell lépnie (ami egy rosszhiszemű üzemeltető esetében lehetséges), akkor a plazmalánc teljes érvényes státuszát egyszerre kell kipublikálni az Ethereum alaprétegén. A plazmaláncok tetszőleges mérete (nagy tranzakcióátviel = több adat) és az Ethereum feldolgozási sebességének korlátai miatt ez nem ideális megoldás. - -Bár a kilépési játékok elméletben jól hangzanak, a valós életben a tömeges kilépések valószínűleg az egész hálózatra kiterjedő torlódást fognak okozni az Ethereumban. Amellett, hogy károsítja az Ethereum funkcionalitását, egy rosszul koordinált tömeges kilépés azt jelenti, hogy a felhasználók esetleg nem tudnak pénzt felvenni, mielőtt az operátor lemerít minden számlát a plazmaláncban. - -## A plazma előnyei és hátrányai {#pros-and-cons-of-plasma} - -| Előnyök | Hátrányok | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Nagy átvitelt és tranzakciónként alacsony költséget kínál. | Nem támogatja a számítást (nem tud okosszerződéseket futtatni). Csak alapvető token-átutalások, váltások és egy pár más tranzakciótípus támogatott az elsőrendű logika által. | -| Jól használható tetszőleges felhasználók közötti tranzakciókra (felhasználópárok között nincs költség, ha mindkettő a plazmán van). | A felhasználónak rendszeresen figyelni kell a hálózatot (elérhetőségi követelmény), vagy át kell ruházni ezt a felelősséget másra a pénzeszközök biztonsága érdekében. | -| A plazmaláncok a főlánctól független, speciális felhasználási esetekhez igazíthatók. Bárki, beleértve a vállalkozásokat is, testre szabhatja a plazma-okosszerződéseket, hogy skálázható infrastruktúrát biztosítson, amely különböző kontextusokban működik. | Egy vagy több operátorra támaszkodik az adatok tárolásában és kérésre történő kiszolgálásában. | -| Csökkenti az Ethereum főhálózat terhelését azáltal, hogy a számítást és a tárolást a láncon kívülre helyezi. | A kiutalások több napig is tarthatnak, hogy lehetővé tegyék a megkérdőjelezést vonást. A helyettesíthető eszközök esetében ezt a likviditásszolgáltatók enyhíthetik, de ez tőkeköltséggel jár. | -| | Ha túl sok felhasználó próbál egyszerre kilépni, az Ethereum főhálózat túlterheltté válhat. | - -## A plazma és az L2 skálázási protokollok összehasonlítása {#plasma-vs-layer-2} - -Míg a plazma egykor hasznos skálázási megoldásnak számított az Ethereum számára, azóta a [második blokkláncréteg (L2) skálázási protokollok](/layer-2/) javára elvetették. Az L2 skálázási megoldások a plazma számos problémáját orvosolják: - -### Hatékonyság {#efficiency} - -A [zero-knowledge összevont tranzakciók](/developers/docs/scaling/zk-rollups) kriptográfiai bizonyítékokat generálnak a láncon kívül feldolgozott tranzakciók minden tételének érvényességéről. Ez megakadályozza, hogy a felhasználók (és az operátorok) érvénytelen státuszváltozásokat kezdeményezzenek, így nem relevánsak a megkérdőjelezési időszakok és a kilépési játékok. Ez azt is jelenti, hogy a felhasználóknak nem kell rendszeresen figyelniük a láncot, hogy biztosítsák pénzeszközeiket. - -### Az okosszerződések támogatása {#support-for-smart-contracts} - -A plazma keretrendszer másik problémája az volt, hogy [nem tudta támogatni az Ethereum okosszerződések végrehajtását](https://ethresear.ch/t/why-smart-contracts-are-not-feasible-on-plasma/2598/4). Ennek eredményeképpen a plazma legtöbb implementációja többnyire egyszerű fizetésekre vagy ERC-20 tokenek cseréjére készült. - -Ezzel szemben az optimista összevont tranzakciók, kompatibilisek az [Ethereum virtuális géppel](/developers/docs/evm/) és képesek Ethereum-natív [okosszerződések](/developers/docs/smart-contracts/) futtatására, így hasznos és _biztonságos_ megoldást jelentenek a [decentralizált alkalmazások](/developers/docs/dapps/) skálázására. Hasonlóképpen, tervben van az [EVM zero-knowledge implementációjának (zkEVM)](https://ethresear.ch/t/a-zk-evm-specification/11549) létrehozása, amely lehetővé tenné a ZK összevont tranzakciók számára, hogy tetszőleges logikát dolgozzanak fel és okosszerződéseket hajtsanak végre. - -### Az adatok elérhetetlensége {#data-unavailability} - -Amint azt már korábban kifejtettük, a plazmánál az adatelérhetőség nem megoldott. Ha egy rosszhiszemű operátor egy érvénytelen státuszt továbbítana a plazmaláncban, a felhasználók nem tudnák azt megtámadni, mivel az operátor visszatarthatja a csalási bizonyítékhoz szükséges adatokat. Az összevont tranzakciók úgy oldják meg ezt a problémát, hogy az operátoroknak közzé kell tenni a tranzakciós adatokat az Ethereumon, így bárki ellenőrizheti a lánc státuszát, és szükség esetén csalási bizonyítékokat hozhat létre. - -### A tömeges kilépés problémája {#mass-exit-problem} - -A ZK és az optimista összevont tranzakciók a maguk módján oldják meg a plazma tömeges kilépési problémáját. A ZK összevont tranzakció például olyan kriptográfiai mechanizmusokra támaszkodik, amelyek biztosítják, hogy az operátorok semmilyen esetben sem tudják ellopni a felhasználók pénzeszközeit. - -Hasonlóképpen, az optimista összevont tranzakciók késleltetési időszakot írnak elő a pénzkivételre, amely alatt bárki megkérdőjelezheti azt, és megakadályozhatja a rosszhiszemű kivételi kérelmeket. Bár ez hasonló a plazmához, a különbség az, hogy a hitelesítők hozzáférnek a csalási bizonyítékokhoz szükséges adatokhoz. Így a rollup-felhasználóknak nincs szükségük arra, hogy őrült, „elsőként kilépő” migrációba kezdjenek az Ethereum főhálózatra. - -## Miben különbözik a plazma a melléklánctól és a sharding-tól? {#plasma-sidechains-sharding} - -A plazma, a mellékláncok és a sharding hasonlóak, mivel mindannyian valamilyen módon kapcsolódnak az Ethereum főhálózathoz. E kapcsolatok szintje és erőssége azonban eltérő, ami befolyásolja az egyes skálázási megoldások biztonsági tulajdonságait. - -### A plazma és a mellékláncok összehasonlítása {#plasma-vs-sidechains} - -A [melléklánc](/developers/docs/scaling/sidechains/) egy önállóan működtetett blokklánc, amely egy kétirányú hídon keresztül kapcsolódik az Ethereum főhálózathoz. A [hidak](/bridges/) lehetővé teszik a felhasználók számára, hogy tokeneket cseréljenek a két blokklánc között, hogy a mellékláncon tranzakciókat bonyolíthassanak, csökkentve az Ethereum főhálózat zsúfoltságát és javítva a skálázhatóságot. A mellékláncok külön konszenzusmechanizmust használnak, és jellemzően sokkal kisebbek, mint az Ethereum főhálózat. Ennek eredményeképpen az eszközök áthidalása ezekbe a láncokba fokozott kockázatot jelent; az Ethereum főhálózatból örökölt biztonsági garanciák hiánya miatt az melléklánc-modellben a felhasználók a pénzeszközök elvesztését kockáztatják a mellékláncot érő támadás során. - -Ezzel szemben a plazmaláncok a főhálózatból merítik biztonságukat. Ez mérhetően biztonságosabbá teszi őket, mint a mellékláncokat. Mind a mellékláncok, mind a plazmaláncok különböző konszenzusprotokollokkal rendelkezhetnek, de a különbség az, hogy a plazmaláncok minden egyes blokkhoz Merkle-gyökereket tesznek közzé az Ethereum főhálózaton. A blokkgyökerek olyan kis információdarabok, amelyek segítségével ellenőrizhetjük a plazmaláncban zajló tranzakciókkal kapcsolatos információkat. Ha egy plazmaláncot támadás ér, a felhasználók a megfelelő bizonyítékok segítségével biztonságosan kivehetik pénzüket a főhálózatra. - -### A plazma és a sharding összehasonlítása {#plasma-vs-sharding} - -Mind a plazmaláncok, mind a shard-láncok rendszeresen közzéteszik a kriptográfiai bizonyítékokat az Ethereum főhálózatra. Azonban eltérő biztonsági tulajdonságokkal rendelkeznek. - -A shard-láncok „összevont fejléceket” küldenek a főhálózatnak, amelyek részletes információkat tartalmaznak az egyes adat-shardról. A főhálózat csomópontjai ellenőrzik és érvényesítik az adat-shardok érvényességét, csökkentve ezzel az érvénytelen shard-változások lehetőségét és védve a hálózatot a rosszindulatú tevékenységektől. - -A plazma azért más, mert a főhálózat csak minimális információt kap a gyerekláncok státuszáról. Ez azt jelenti, hogy a főhálózat nem tudja hatékonyan ellenőrizni a gyerekláncokon végrehajtott tranzakciókat, így azok kevésbé biztonságosak. - -**Fontos megjegyezni**, hogy az Ethereum blokklánc ütemtervében már nem szerepel a sharding. Ezt felváltotta a rollupok-on keresztül történő skálázás és a [Danksharding](/roadmap/danksharding). - -### A plazma használata {#use-plasma} - -Több projekt is kínál olyan plazmaimplementációkat, amelyeket Ön is beépíthet a dappjaiba: - -- [Polygon](https://polygon.technology/) (korábban Matic Network) - -## További olvasnivaló {#further-reading} - -- [Ismerje meg a plazmát](https://www.learnplasma.org/en/) -- [Gyors emlékeztető arról, hogy mit jelent a „megosztott biztonság” és miért olyan fontos ez a fogalom](https://old.reddit.com/r/ethereum/comments/sgd3zt/a_quick_reminder_of_what_shared_security_means/) -- [A mellékláncok, a plazma és a sharding összehasonlítása](https://vitalik.eth.limo/general/2019/06/12/plasma_vs_sharding.html) -- [A plazma megértése, 1. rész: Az alapok](https://www.theblockcrypto.com/amp/post/10793/understanding-plasma-part-1-the-basics) -- [A plazma élete és halála](https://medium.com/dragonfly-research/the-life-and-death-of-plasma-b72c6a59c5ad#) - -_Van olyan közösségi erőforrása, amely segített Önnek? Szerkessze ezt az oldalt, és adja hozzá!_ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" deleted file mode 100644 index 1f92c6f05e6..00000000000 --- "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/sidechains/index.md" +++ /dev/null @@ -1,73 +0,0 @@ ---- -title: Mellékláncok -description: Bevezetés a mellékláncokba, az Ethereum közössége által használt skálázási megoldásba. -lang: hu -sidebarDepth: 3 ---- - -A melléklánc egy különálló blokklánc, amely az Ethereum hálózatától függetlenül működik, és az Ethereum főhálózatához egy kétirányú híddal csatlakozik. A mellékláncoknak eltérő blokkparaméterei és [konszenzusalgoritmusai](/developers/docs/consensus-mechanisms/) lehetnek, melyeket a tranzakciók hatékonyabb feldolgozására terveztek. A mellékláncok használata azonban kompromisszumokkal jár, mivel azok nem rendelkeznek az Ethereumra jellemző biztonsági tulajdonságokkal. A [második blokkláncréteg (L2) skálázási megoldásaival](/layer-2/) ellentétben a mellékláncok nem rögzítik állapotváltozásaikat és tranzakciós adataikat az Ethereum főhálózatán. - -A mellékláncok bizonyos mértékben feláldozzák decentralizáltságukat vagy biztonságukat, hogy nagyobb tranzakcióátvitelt érjenek el ([skálázhatósági trilemma](https://vitalik.eth.limo/general/2021/05/23/scaling.html)). Az Ethereum azonban elkötelezett a skálázási megoldások mellett, anélkül hogy kompromisszumot kötne a decentralizáció és biztonság terén, ahogy azt a [vízió megfogalmazása](/roadmap/vision/) is mutatja a fejlesztésekre vonatkozóan. - -## Hogyan működnek a mellékláncok? {#how-do-sidechains-work} - -A mellékláncok független blokkláncok, eltérő történetekkel, fejlesztési tervekkel és tervezési megoldásokkal. Bár egy mellékláncnak a felszínen lehet néhány hasonlósága az Ethereummal, számos sajátossággal rendelkezik. - -### Konszenzusalgoritmus {#consensus-algorithms} - -A mellékláncokat egyedivé (Ethereumtól eltérővé) tevő egyik tulajdonság az alkalmazott konszenzusalgoritmus. Konzenzus tekintetében a mellékláncok nem támaszkodnak az Ethereumra, hanem az igényeiknek megfelelő alternatív konzenzusprotokollt választhatnak. Néhány példa a mellékláncokon alkalmazott konszenzusalgoritmusokra: - -- [Proof-of-authority (jogosultsági igazolás)](/developers/docs/consensus-mechanisms/poa/) -- [Delegált proof-of-stake (letéti igazolás)](https://en.bitcoin.it/wiki/Delegated_proof_of_stake) -- [Bizánci hibatűrés](https://decrypt.co/resources/byzantine-fault-tolerance-what-is-it-explained). - -Az Ethereumhoz hasonlóan a mellékláncok is rendelkeznek validáló csomópontokkal, amelyek ellenőrzik és feldolgozzák a tranzakciókat, blokkokat állítanak elő, és tárolják a blokklánc állapotát. A validátorok felelősek a konszenzus fenntartásáért a hálózaton belül és a rosszindulatú támadások elleni védelemért is. - -#### Blokkparaméterek {#block-parameters} - -Az Ethereum korlátozza a [blokkidőt](/developers/docs/blocks/#block-time) (azaz az új blokkok létrehozásához szükséges időt) és a [blokkméretet](/developers/docs/blocks/#block-size) (azaz a blokkokban tárolt adat mennyiségét gázban kifejezve). A mellékláncok ezzel szemben más paramétereket alkalmaznak, mint a gyorsabb blokkidők vagy a magasabb gázkorlátozások, annak érdekében, hogy nagyobb teljesítményt, gyorsabb tranzakciókat és alacsonyabb díjakat érjenek el. - -Habár ez bizonyos előnyökkel jár, kritikus következményei lehetnek a hálózat decentralizáltságát és biztonságát illetően. Az olyan blokkparaméterek, mint az alacsony blokkidők és a nagy blokkméretek növelik egy teljes csomópont fenntartásának nehézségeit, ami miatt csak néhány „szupercsomópont” felelhet a lánc biztonságáért. Egy ilyen forgatókönyv esetén megnő a validátorok összejátszásának vagy a lánc rosszindulatú átvételének lehetősége. - -Ahhoz, hogy a blokkláncok a decentralizáció csökkenése nélkül skálázódhassanak, a csomópontok működtetésének mindenki számára elérhetőnek kell lennie, nem csak a speciális hardverrel rendelkezőknek. Ezért folynak erőfeszítések annak biztosítására, hogy mindenki [futtasson egy teljes csomópontot](/developers/docs/nodes-and-clients/#why-should-i-run-an-ethereum-node) az Ethereum hálózaton. - -### EVM-kompatibilitás {#evm-compatibility} - -Egyes mellékláncok EVM-kompatibilisek, és képesek az [Ethereum virtuális gépre (EVM)](/developers/docs/evm/) fejlesztett szerződések végrehajtására. Az EVM-kompatibilis mellékláncok támogatják azokat az okosszerződéseket, melyeket [Solidity](/developers/docs/smart-contracts/languages/) vagy más EVM okosszerződés nyelveken írtak, tehát az Ethereum főhálózatra írt okosszerződések az EVM-kompatibilis mellékláncokon is működnek. - -Ha Ön a [dappját](/developers/docs/dapps/) egy mellékláncban szeretné használni, akkor csak az [okosszerződést](/developers/docs/smart-contracts/) kell telepíteni erre a mellékláncra. Úgy néz ki, olyan érzés, és úgy is működik, mint a főhálózat – a szerződéseket Solidityben írja, és a melléklánc RPC-jén keresztül lép kapcsolatba a lánccal. - -Mivel a mellékláncok EVM-kompatibilisek, hasznos [skálázási megoldásnak](/developers/docs/scaling/) számítanak az Ethereum-natív dappok számára. Ha a dapp egy mellékláncon van, a felhasználók alacsonyabb gázdíjakat és gyorsabb tranzakciókat élvezhetnek, különösen akkor, ha a főhálózat túlterhelt. - -Ugyanakkor a melléklánc használata jelentős kompromisszumokkal jár. Minden melléklánc maga felel a biztonságáért, és nem örökli az Ethereum biztonsági tulajdonságait. Ez növeli a rosszindulatú viselkedés lehetőségét, ami hatással lehet a felhasználókra vagy veszélyeztetheti pénzeszközeiket. - -### Eszközmozgás {#asset-movement} - -Ahhoz, hogy egy különálló blokklánc az Ethereum főhálózat mellékláncává váljon, kezelnie kell az eszközök átutalását az Ethereum főhálózatról el és vissza. Az Ethereummal való átjárhatóságot egy blokklánchíd segítségével érik el. A [hidak](/bridges/) az Ethereum főhálózatra telepített okosszerződéseket és egy mellékláncot használnak az alapok közötti áthidalásokra. - -Bár a hidak segítségével a felhasználók pénzeszközöket mozgathatnak az Ethereum és a melléklánc között, az eszközök fizikailag nem mozognak a két lánc között. Ehelyett olyan mechanizmusokat használnak a láncok közötti értékátvitelre, amelyek jellemzően kibocsátással és égetéssel járnak. További információ a [hidakról](/developers/docs/bridges/#how-do-bridges-work). - -## A mellékláncok előnyei és hátrányai {#pros-and-cons-of-sidechains} - -| Előnyök | Hátrányok | -| ---------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| A mellékláncok alapjául szolgáló technológia jól megalapozott, és kiterjedt kutatás és tervezési fejlesztések eredménye. | A mellékláncok a decentralizáció és a bizalomigény-mentesség bizonyos mértékét a skálázhatóságra cserélik. | -| A mellékláncok támogatják az általános számításokat és EVM-kompatibilitást kínálnak (Ethereum-natív dappokat futtathatnak). | Egy melléklánc külön konszenzusmechanizmust használ, és nem részesül az Ethereum biztonsági garanciáiból. | -| A mellékláncok különböző konszenzusmodelleket használnak a tranzakciók hatékony feldolgozása és a felhasználók tranzakciós díjainak csökkentése érdekében. | A mellékláncok magasabb szintű bizalmi feltételezést igényelnek (például a rosszindulatú melléklánc-validátorok határozatképes csoportja csalást követhet el). | -| Az EVM-kompatibilis mellékláncok lehetővé teszik a dappok számára, hogy bővítsék az ökoszisztémájukat. | | - -### Mellékláncok használata {#use-sidechains} - -Több projekt is kínál olyan melléklánc-implementációkat, amelyeket Ön is beépíthet a dappjaiba: - -- [Polygon PoS](https://polygon.technology/solutions/polygon-pos) -- [Skale](https://skale.network/) -- [Gnosis Chain (korábban xDai)](https://www.gnosischain.com/) -- [Loom Network](https://loomx.io/) -- [Metis Andromeda](https://www.metis.io/) - -## További olvasnivaló {#further-reading} - -- [Ethereum dappok skálázása mellékláncokkal](https://medium.com/loom-network/dappchains-scaling-ethereum-dapps-through-sidechains-f99e51fff447) _2018. február 8. – Georgios Konstantopoulos_ - -_Ismersz olyan közösségi anyagot, mely segített neked? Módosítsd az oldalt és add hozzá!_ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" deleted file mode 100644 index 257a88b9257..00000000000 --- "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/state-channels/index.md" +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Státuszcsatornák -description: Bevezetés a státusz- és fizetési csatornákba, az Ethereum közössége által használt skálázási megoldásba. -lang: hu -sidebarDepth: 3 ---- - -A státuszcsatornák lehetővé teszik a résztvevők számára, hogy biztonságosan tranzakciókat bonyolítsanak le a láncon kívül, miközben minimálisra csökkentik az Ethereum főhálózattal való interakciót. A csatornát alkotó résztvevők tetszőleges számú, a láncon kívüli tranzakciót hajthatnak végre, melyhez csak két láncon belüli tranzakciót kell beküldeniük csatorna megnyitásához és lezárásához. Ez rendkívül nagy tranzakcióátvitelt tesz lehetővé, és alacsonyabb költségeket eredményez a felhasználók számára. - -## {#how-do-sidechains-work} - -A nyilvános blokkláncok, mint például az Ethereum, az elosztott architektúrájuk miatt skálázhatósági kihívásokkal küzdenek: a láncban végrehajtott tranzakciókat az összes csomópontnak végre kell hajtania. A csomópontoknak képesnek kell lenniük arra, hogy egy blokkban lévő tranzakciók mennyiségét szerény hardverrel kezeljék, hogy a hálózat decentralizált maradjon, de ez korlátozza a tranzakcióátviteli sebességet. - -### {#consensus-algorithms} - -A csatornák olyan egyszerű társközi (peer-to-peer) protokollok, amelyek lehetővé teszik, hogy két fél számos tranzakciót hajtson végre egymás között, és csak a végeredményt tegyék fel a blokkláncra. A csatorna kriptográfiát használ annak bizonyítására, hogy az általuk generált összesített adatok valóban érvényes köztes tranzakciók eredményei. Egy [több aláírásos](/developers/docs/smart-contracts/#multisig) okosszerződés biztosítja, hogy a tranzakciókat a megfelelő felek írják alá. - -- []() -- []() -- - -A csatornák segítségével a státuszváltozásokat az érdekelt felek hajtják végre és érvényesítik, minimalizálva az Ethereum végrehajtási rétegének számításait. Ez csökkenti a torlódásokat az Ethereumon, és növeli a tranzakciók feldolgozási sebességét a felhasználók számára. - -#### {#block-parameters} - -Minden csatornát egy [több aláírásos okosszerződés](/developers/docs/smart-contracts/#multisig) kezel, amely az Ethereumon fut. Egy csatorna megnyitásához a résztvevők telepítik a csatornaszerződést a láncban, és pénzt helyeznek el benne. - -A csatorna lezárásához a résztvevők elküldik a csatorna utolsó elfogadott státuszát a láncba. Ezt követően az okosszerződés a zárolt pénzeszközöket az egyes résztvevőknek a csatorna végső státuszában lévő egyenlege szerint osztja szét. - -A peer-to-peer csatornák különösen hasznosak olyan helyzetekben, amikor néhány előre meghatározott résztvevő nagy gyakorisággal kíván tranzakciókat lebonyolítani anélkül, hogy az többletterhekkel járna. A blokklánc-csatornák két kategóriába sorolhatók: **fizetési** és **státuszcsatornák**. - -### {#evm-compatibility} - -A fizetési csatornát leginkább úgy lehet leírni, mint két felhasználó által közösen vezetett „kétirányú főkönyvet”. A főkönyv kezdeti egyenlege a csatornanyitási fázisban a láncban lévő szerződésbe zárolt betétek összege. - -A főkönyv egyenlegének (azaz a fizetési csatorna státuszának) frissítéséhez a csatorna összes résztvevőjének jóváhagyása szükséges. A csatorna résztvevői által aláírt csatornaváltozás véglegesítettnek tekinthető, hasonlóan az Ethereumban végrehajtott tranzakciókhoz. - -A fizetési csatornák a legkorábbi skálázási megoldások közé tartoztak, amelyek célja az egyszerű felhasználói interakciók (pl. ETH átutalások, atomikus átváltások, mikrofizetések) költséges láncon belüli tevékenységének minimalizálása volt. A csatorna résztvevői korlátlan mennyiségű azonnali, illeték nélküli tranzakciót hajthatnak végre egymás között mindaddig, amíg az átutalások nettó összege nem haladja meg a letétbe helyezett tokeneket. - -A láncon kívüli fizetések támogatásán kívül a fizetési csatornák nem bizonyultak hasznosnak az általános státuszváltozási logika kezelésére. A státuszcsatornákat azért hozták létre, hogy megoldják ezt a problémát, és azok támogassák az általános célú számítások skálázását. - -### {#asset-movement} - -A státuszcsatornáknak sok közös vonásuk van a fizetési csatornákkal. A felhasználók például kriptográfiailag aláírt üzenetek (tranzakciók) cseréjével lépnek kapcsolatba egymással, amelyeket a csatorna többi résztvevőjének is alá kell írnia. Ha egy javasolt státuszváltozást nem ír alá minden résztvevő, az érvénytelennek minősül. - -## {#pros-and-cons-of-sidechains} - -| | | -| | | -| | | -| | | -| | | -| | | - -### {#use-sidechains} - -- []() -- []() -- []() -- []() -- []() - -## {#further-reading} - -- - -_ _ diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" deleted file mode 100644 index 696bd6c534c..00000000000 --- "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/validium/index.md" +++ /dev/null @@ -1,165 +0,0 @@ ---- -title: Validium -description: Bevezetés a validiumba, az Ethereum közössége által használt skálázási megoldásba. -lang: hu -sidebarDepth: 3 ---- - -A validium egy [skálázási megoldás](/developers/docs/scaling/), amely érvényességi bizonylatok, például [ZK összevont tranzakciók](/developers/docs/scaling/zk-rollups/) segítségével érvényesíti a tranzakciók integritását, de nem tárolja a tranzakciós adatokat az Ethereum főhálózaton. Bár a láncon kívüli adatok elérhetősége kompromisszumokat eredményez, a skálázhatóság terén hatalmas javulást jelent (a validiumok másodpercenként [kb. 9000 tranzakciót vagy annál többet is képesek feldolgozni](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263)). - -## Előfeltételek {#prerequisites} - -Érdemes áttekinteni az [Ethereum skálázásról](/developers/docs/scaling/) és [L2 megoldásokról](/layer-2) szóló oldalakat. - -## Mi az a validium? {#what-is-validium} - -A validiumok olyan skálázási megoldások, amelyek az Ethereum főhálózaton kívüli adatelérhetőséget és számítást használnak, és láncon kívül dolgozzák fel a tranzakciókat, így javítva a tranzakcióátvitelt. A zero-knowledge összevont tranzakciókhoz hasonlóan a validiumok is [zero-knowledge bizonyítékokat](/glossary/#zk-proof) tesznek közzé az Ethereumon kívüli tranzakciók ellenőrzésére. Ez megakadályozza az érvénytelen státuszváltozásokat, és növeli a validiumlánc biztonsági garanciáit. - -Ezek az érvényességi bizonyítékok ZK-SNARK (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, vagyis zero-knowledge tömörített nem interaktív érv ismeretre) vagy ZK-STARK (Zero-Knowledge Scalable Transparent Argument of Knowledge, vagyis zero-knowledge skálázható transzparens érv ismeretre) formájában érkezhetnek. Bővebben a [zero-knowledge bizonyítékokról](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/). - -A validium-felhasználók pénzeszközeit egy Ethereum-alapú okosszerződés ellenőrzi. A validiumok a ZK összevont tranzakciókhoz hasonlóan szinte azonnali kifizetéseket kínálnak; miután a főhálózat ellenőrizte a kifizetési kérelem érvényességi bizonyítékát, a felhasználók [Merkle-bizonyítékok](/developers/tutorials/merkle-proofs-for-offline-data-integrity/) benyújtásával tudnak pénzt felvenni. A Merkle-bizonyíték igazolja, hogy a felhasználó kifizetési tranzakciója bekerült egy ellenőrzött tranzakciókötegbe, így a láncon belüli szerződés feldolgozhatja a kifizetést. - -A validium felhasználók azonban befagyaszthatják pénzeszközeiket és korlátozhatják a pénzfelvételt. Ez akkor fordulhat elő, ha a validiumlánc adatelérhetőség-kezelői visszatartják a felhasználók elől a láncon kívüli állapotadatokat. A tranzakciós adatokhoz való hozzáférés nélkül a felhasználók nem tudják előállítani a pénzeszközök tulajdonjogának bizonyításához, illetve a kifizetések végrehajtásához szükséges Merkle-bizonyítékot. - -Ez a fő különbség a validiumok és a ZK összevont tranzakciók között, vagyis az adatelérhetőség spektrumán máshol helyezkednek el. Mindkét megoldás másképp közelíti meg az adattárolást, ami kihat a biztonságra, illetve a bizalomigény-mentességre. - -## Miként működnek együtt a validiumok az Ethereummal? {#how-do-validiums-interact-with-ethereum} - -A validiumok a meglévő Ethereum-láncra épülő skálázási protokollok. Bár a tranzakciókat a láncon kívül hajtja végre, a validium láncot a főhálózatra telepített okosszerződések gyűjteménye kezeli, beleértve a következőket is: - -1. **Hitelesítői szerződés**: A hitelesítői szerződés ellenőrzi a validium-üzemeltető által az státuszfrissítésekre benyújtott bizonylatok érvényességét. Ez két dolgot fed le a láncon kívül történő végrehajtással kapcsolatban: a tranzakciók helyességét igazoló érvényességi bizonyítékot és a tranzakciós adatok meglététről szóló adatelérhetőségi bizonyítékot. - -2. **Főszerződés**: A főszerződés tárolja a blokképítő által benyújtott státusz elköteleződést (Merkle-gyökerek), és frissíti a validium státuszát, amint egy érvényességi bizonyítékot a láncban ellenőriznek. Ez a szerződés kezeli a validiumláncba történő befizetéseket és az onnan történő kivonásokat is. - -A validiumok a fő Ethereum-láncra támaszkodnak a következő területeken is: - -### Elszámolás {#settlement} - -A validiumon végrehajtott tranzakciókat nem lehet teljes mértékben megerősíteni, amíg a szülőlánc nem ellenőrzi érvényességüket. Minden validiumon lebonyolított ügyletet végül a főhálózaton kell elszámolni. Az Ethereum-blokklánc „elszámolási garanciákat” is nyújt a validium-felhasználók számára, ami azt jelenti, hogy a láncot elhagyó tranzakciókat nem lehet visszafordítani vagy megváltoztatni, miután a láncba bevitték őket. - -### Biztonság {#security} - -Az Ethereum, mint elszámolási réteg, szintén garantálja az státuszváltozások érvényességét a validiumon. A validiumláncon végrehajtott, láncon kívüli tranzakciókat az Ethereum alaprétegén lévő okosszerződésen keresztül ellenőrzik. - -Ha a láncon belüli hitelesítő szerződés érvénytelennek ítéli a bizonyítékot, a tranzakciókat elutasítja. Ez azt jelenti, hogy az operátoroknak meg kell felelniük az Ethereum-protokoll által kikényszerített érvényességi feltételeknek, mielőtt frissítenék a validium státuszát. - -## Hogyan működik a validium? {#how-does-validium-work} - -### Tranzakciók {#transactions} - -A felhasználók tranzakciókat nyújtanak be az operátornak, amely egy csomópont, és ez felel a validiumlánc tranzakcióinak végrehajtásáért. Egyes validiumok egyetlen operátort használnak a lánc végrehajtására, vagy támaszkodhatnak egy [proof-of-stake (PoS)](/developers/docs/consensus-mechanisms/pos/) mechanizmusra is az operátorok rotációja érdekében. - -Az operátor a tranzakciókat egy kötegbe tömöríti, és a bizonyításhoz elküldi egy bizonyító programnak (circuit). A bizonyító program elfogadja a tranzakciós köteget (és más releváns adatokat) bemenetként, és kiad egy érvényességi bizonyítékot, amely igazolja a műveleteket helyes végrehajtását. - -### Státuszrögzítések {#state-commitments} - -A validium státuszát egy Merkle-fa formájában hash-elik, amelynek gyökere az Ethereum fő szerződésben van tárolva. A Merkle- vagy státuszgyökér a validiumon lévő számlák és egyenlegek aktuális státuszára vonatkozó kriptográfiai kötelezettségvállalás. - -A státuszfrissítéshez az operátornak ki kell számítania a tranzakciók végrehajtása utáni új státuszgyökeret, és el kell küldenie azt a láncon belüli szerződésnek. Ha az érvényesség igazolása rendben van, a javasolt státusz elfogadásra kerül, és a validium átvált az új gyökérstátuszra. - -### Letét elhelyezése és kivétele {#deposits-and-withdrawals} - -A felhasználók ETH-t (vagy bármely ERC-kompatibilis tokent) helyeznek letétbe a láncon belüli szerződésben, így tudnak pénzeszközt mozgatni az Ethereumról egy validiumba. A szerződés közvetíti a letéti eseményt a validiumnak a láncon kívülre, ahol a felhasználó címére jóváírják a letétnek megfelelő összeget. Az operátor ezt a befizetési tranzakciót is egy új kötegbe foglalja. - -A pénzeszközök főhálózatra történő visszautalásához a validium felhasználó kezdeményez egy kifizetési tranzakciót, és elküldi azt az operátornak, aki érvényesíti a kifizetési kérelmet, és felveszi azt egy kötegbe. A felhasználó validiumláncban lévő eszközei megsemmisülnek, mielőtt kiléphetnének a rendszerből. Miután a köteghez kapcsolódó érvényességi bizonyítékot ellenőrizték, a felhasználó meghívhatja a fő szerződést, hogy kivegye a befizetésének a fennmaradó részét. - -A validiumprotokoll cenzúraellenes mechanizmusként lehetővé teszi a felhasználók számára, hogy közvetlenül a validiumszerződésből lépjenek ki, anélkül hogy az operátoron keresztül mennének. Ebben az esetben a felhasználóknak Merkle-bizonyítékot kell szolgáltatniuk a hitelesítő szerződésnek, amely igazolja, hogy a fiók szerepel a státuszgyökérben. Ha a bizonyítékot elfogadják, a felhasználó meghívhatja a fő szerződés visszavonási funkcióját, hogy kivegye a pénzét a validiumból. - -### Kötegbenyújtás {#batch-submission} - -A tranzakcióköteg végrehajtása után az operátor benyújtja a kapcsolódó érvényességi bizonyítékot a hitelesítői szerződésnek, és új státuszgyökeret javasol a főszerződésnek. Ha a bizonylat érvényes, a főszerződés frissíti a validium státuszát, és véglegesíti a kötegben lévő tranzakciók eredményeit. - -A ZK összevont tranzakciókkal ellentétben a validium blokkgyártóinak nem kell közzétenniük a kötegek tranzakciós adatait (csak a blokkfejléceket). Ez teszi a validiumot egy tisztán láncon kívüli skálázási protokollá, szemben a „hibrid” megoldásokkal ([L2](/layer-2/)), amelyek a státuszadatokat `calldata` formájában közzéteszik a fő Ethereum-láncon. - -### Adatelérhetőség {#data-availability} - -A validiumok láncon kívüli adatelérhetőségi modellt használnak, ahol az operátorok az összes tranzakciós adatot az Ethereum főhálózaton kívül tárolják. A validium alacsony láncon belüli adatlábnyoma javítja a skálázhatóságot (a tranzakcióátvitelt nem korlátozza az Ethereum adatfeldolgozási kapacitása) és csökkenti a felhasználói díjakat (a `calldata` közzétételének költsége alacsonyabb). - -A láncon kívüli adatelérhetőség azonban problémát jelent: a Merkle-bizonyítékok létrehozásához vagy ellenőrzéséhez szükséges adatok nem állnak rendelkezésre. Ez azt jelenti, hogy a felhasználók nem tudnak pénzeszközt kivenni a láncon belüli szerződésből, ha az operátorok rosszhiszeműen cselekszenek. - -Számos validiummegoldás a státuszadatok tárolásának decentralizálásával próbálja megoldani ezt a problémát. Ez azt jelenti, hogy a blokkgyártókat arra kényszerítik, hogy a mögöttes adatokat elküldjék az „adatelérhetőség-kezelőknek”, akik felelősek a láncon kívüli adatok tárolásáért, és kérésre a felhasználók rendelkezésére bocsátják azokat. - -A validiumban az adatelérhetőség kezelői minden validiumköteg aláírásával tanúsítják az adatelérhetőséget a láncon kívüli tranzakciókhoz. Ezek az aláírások egyfajta „rendelkezésre állási bizonyítékot” jelentenek, amelyet a láncon lévő hitelesítői szerződés a státuszfrissítések jóváhagyása előtt ellenőriz. - -A validiumok eltérnek egymástól az adatelérhetőség kezelési módjában. Egyesek megbízható felekre támaszkodnak a státuszadatok tárolásában, míg mások véletlenszerűen kijelölt validátorokat használnak erre. - -#### Adatelérhetőségi bizottság (DAC) {#data-availability-committee} - -A láncon kívüli adatok elérhetőségének garantálása érdekében egyes validium-megoldások megbízható résztvevők egy csoportját, az úgynevezett adatelérhetőségi bizottságot (DAC) jelölik ki a státuszmásolat tárolására és az adatelérhetőség igazolására. A DAC-k könnyebben megvalósíthatók és kevesebb koordinációt igényelnek, mivel a taglétszám alacsony. - -A felhasználóknak azonban meg kell bízniuk a DAC-ben, hogy szükség esetén rendelkezésre bocsátja az adatokat (például a Merkle-bizonyítékok generálásához). Fennáll annak a lehetősége, hogy az adatelérhetőségi bizottságok [tagjait egy rosszindulatú szereplő megtámadja](https://notes.ethereum.org/DD7GyItYQ02d0ax_X-UbWg?view), aki aztán visszatartja a láncon kívüli adatokat. - -[Bővebben az adatelérhetőségi bizottságokról a validiumokban](https://medium.com/starkware/data-availability-e5564c416424). - -#### Kötelezvényalapú adatelérhetőség {#bonded-data-availability} - -Más validiumok megkövetelik azoktól a résztvevőktől, akik az offline adatok tárolásáért felelnek, hogy feladatuk megkezdése előtt letétbe tegyenek (zároljanak) bizonyos értékű tokent egy okosszerződésben. Ez a letét „kötelezvényként” szolgál, amely garantálja az adatelérhetőség kezelőinek tisztességes viselkedését, és csökkenti a bizalmi feltételezéseket. Ha ezek a résztvevők nem bizonyítják az adatelérhetőséget, a kötelezvényt lecsökkentik. - -A kötelezvényalapú adatelérhetőség esetén bárki kijelölhető a láncon kívüli adatok tárolására, amint biztosítja a szükséges letétet. Ezáltal bővül a jogosult adatelérhetőségi kezelők köre, és csökken az adatelérhetőségi bizottságokat (DAC) érintő centralizáció. Ennél is fontosabb, hogy ez a megközelítés kriptogazdasági ösztönzőkre támaszkodik a rosszindulatú tevékenységek megakadályozására, ami lényegesen biztonságosabb, mintha megbízható feleket jelölnénk ki az offline adatok biztosítására a validiumban. - -[Bővebben a kötelezvényalapú adatelérhetőségről a validiumokban](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf). - -## Volitionok és a validium {#volitions-and-validium} - -A validiumok számos előnyt kínálnak, de kompromisszumokkal is járnak (leginkább az adatelérhetőségben). De mint sok más skálázási megoldás, a validiumok is speciális felhasználási esetekre alkalmasak – ezért hozták létre a volitionokat. - -A volitionok kombinálják a ZK összevont tranzakciókat és a validiumláncot, és teszik lehetővé a felhasználók számára a két skálázási megoldás közötti váltást. A volitionokkal a felhasználók bizonyos tranzakciók esetében választhatják a validium láncon kívüli adatelérhetőségét, ugyanakkor válthatnak láncon belüli adatelérhetőségi megoldásra (ZK összevont tranzakciók) is, amikor arra van szükségük. Ez lényegében megadja a felhasználóknak a szabadságot, hogy olyan kompromisszumot válasszanak, amely megfelel egyedi igényüknek. - -Egy decentralizált tőzsde (DEX) előnyben részesítheti a validium skálázható és privát infrastruktúrájának használatát a nagy értékű kereskedésekhez. ZK összevont tranzakciót is használhat azon felhasználók számára, akik magasabb biztonsági garanciákat és bizalomigény-mentességet szeretnék. - -## A validiumok és az EVM kompatibilitás {#validiums-and-evm-compatibility} - -A ZK összevont tranzakciók hasonlóan a validiumok egyszerű alkalmazásokhoz, például tokencserékhez és fizetésekhez alkalmasak. Az általános számítás és az okosszerződések végrehajtásának támogatása a validiumok között nehezen megvalósítható, tekintettel az [EVM](/developers/docs/evm/) utasítások bizonyításának jelentős többletköltségére egy zero-knowledge bizonyítékot készítő folyamatban. - -Egyes validium projektek ezt a problémát úgy próbálják megkerülni, hogy EVM-kompatibilis nyelveket (például Solidity, Vyper) fordítanak le, hogy egyedi, hatékony bizonyításra optimalizált bájtkódot hozzanak létre. Ennek a megközelítésnek az a hátránya, hogy az új, new zero-knowledge bizonyítéknak kedvező virtuális gépek (VM) nem feltétlenül támogatják a fontos EVM-műveleti kódokat, és a fejlesztőknek közvetlenül a magas szintű nyelven kell írniuk az optimális élmény érdekében. Ez még több problémát okoz: arra kényszeríti a fejlesztőket, hogy a dappokat egy teljesen új fejlesztői stackkel építsék meg, és megszakítja a kompatibilitást a jelenlegi Ethereum infrastruktúrával. - -Néhány csapat azonban megpróbálja optimalizálni a meglévő EVM opkódokat a ZK-bizonyítási folyamatok számára. Ennek eredménye egy zero-knowledge Ethereum virtuális gép (zkEVM) kifejlesztése lesz, egy EVM-kompatibilis VM, amely bizonyítékokat állít elő a programfuttatás helyességének ellenőrzésére. A zkEVM segítségével a validiumláncok okosszerződéseket hajthatnak végre a láncon kívül, és érvényességi bizonyítékokat nyújthatnak be egy láncon kívüli számítás ellenőrzésére (anélkül, hogy azt újra végre kellene hajtaniuk) az Ethereumon. - -[Bővebben a zkEVM-ekről](https://www.alchemy.com/overviews/zkevm). - -## Hogyan skálázzák a validiumok az Ethereumot? {#scaling-ethereum-with-validiums} - -### 1. Láncon kívüli adattárolás {#off-chain-data-storage} - -Az L2 skálázási projektek, mint például az optimista és ZK összevont tranzakciók, a tisztán láncon kívüli skálázási protokollok (például [plazma](/developers/docs/scaling/plasma/)) a végtelen skálázhatóságát a biztonságra cserélik azáltal, hogy bizonyos tranzakciós adatokat közzétesznek az L1-en. Ez azonban azt jelenti, hogy a összevont tranzakciók skálázhatósági tulajdonságait korlátozza az Ethereum főhálózat adatsávszélessége (emaitt az [adatsharding](/roadmap/danksharding/) az Ethereum adattárolási kapacitásának javítását célozza). - -A validiumok úgy érik el a skálázhatóságot, hogy minden tranzakciós adatot a láncon kívül tartanak, és csak akkor tesznek közzé státuszelköteleződéseket (és érvényességi bizonyítékokat), amikor az státuszfrissítéseket továbbítják a fő Ethereum-láncnak. Az érvényességi bizonyítékok megléte azonban nagyobb biztonsági garanciákat biztosít a validiumoknak, mint más, tisztán láncon kívüli skálázási megoldások, például a plazma és a [mellékláncok](/developers/docs/scaling/sidechains/). Azáltal, hogy csökkenti az adatmennyiséget, amelyet az Ethereumnak fel kell dolgoznia a láncon kívüli tranzakciók validálása előtt, a validiumdizájnok jelentősen növelik a tranzakcióátviteli sebességet a főhálózaton. - -### 2. Rekurzív bizonyítékok {#recursive-proofs} - -A rekurzív bizonyíték olyan érvényességi bizonyíték, amely más bizonyítékok érvényességét ellenőrzi. Ez a „bizonyítékok bizonyítéka” több bizonyíték rekurzív összevonásával jön létre, amíg kialakul egy végső bizonyíték, amely az összes korábbit ellenőrzi. A rekurzív bizonyítékok úgy skálázzák a blokklánc feldolgozási sebességét, hogy egy adott érvényességi bizonyíték által lefedett tranzakciók számát növelik. - -Jellemzően minden érvényességi bizonyíték, amelyet a validium üzemeltetője benyújt az Ethereumnak ellenőrzésre, egyetlen blokk integritását validálja. Egyetlen rekurzív bizonyíték azonban egyszerre több validiumblokk érvényességét is tudja igazolni – ez azért lehetséges, mert a bizonyító folyamat több blokkbizonyítékot rekurzív módon egyetlen végső bizonyítékká képes összevonni. Ha a láncon belüli hitelesítői szerződés elfogadja a rekurzív bizonyítékot, az összes mögöttes blokk azonnal véglegesítésre kerül. - -## A validium előnyei és hátrányai {#pros-and-cons-of-validium} - -| Előnyök | Hátrányok | -| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Az érvényességi bizonyítékok biztosítják a láncon kívüli tranzakciók integritását, és megakadályozzák, hogy az üzemeltetők érvénytelen státuszfrissítéseket véglegesítsenek. | Az érvényességi bizonyítékok előállításához speciális hardverre van szükség, ami centralizációs kockázatot jelent. | -| Növeli a tőkehatékonyságot a felhasználók számára (nincs késedelem a pénzeszközök Ethereumba való visszavételében). | Korlátozottan támogatja az általános számítást/okosszerződéseket; speciális nyelveket igényel a fejlesztése. | -| Nem sérülékeny bizonyos gazdasági támadásokkal szemben, melyekkel a csalási bizonyíték alapú rendszerek szembesülnek a nagy értékű alkalmazásoknál. | Nagy számítási kapacitást igényel a ZK bizonyítékok generálása; nem költséghatékony az alacsony tranzakcióátvitelű alkalmazásoknál. | -| Csökkenti a felhasználók gázdíját azáltal, hogy a hívásadatokat (calldata) nem küldi el az Ethereum főhálózatára. | Lassabb szubjektív véglegességi idő (10–30 perc egy ZK bizonyíték generálása) de gyorsabb a teljes véglegesség, mivel nincs felelősségre vonási idő. | -| Alkalmas olyan speciális felhasználási esetekre, mint a kereskedés vagy a blokkláncjátékok, amelyeknél a legfontosabb a tranzakciókra vonatkozó adatvédelem és a skálázhatóság. | Előfordulhat, hogy a felhasználók nem tudnak hozzájutni a pénzeszközeikhez, mert a tulajdonlásuk Merkle-bizonyítékaihoz a láncon kívüli adatoknak rendelkezésre kell állniuk. | -| A láncon kívüli adatelérhetőség nagyobb tranzakcióátvitelt biztosít és növeli a skálázhatóságot. | A biztonsági modell bizalmi feltételezésekre és kriptogazdasági ösztönzőkre támaszkodik, ellentétben a ZK összevont tranzakciókkal, amelyek kriptográfiai biztonsági mechanizmusokra támaszkodnak. | - -### Validiumok/volitionok használata {#use-validium-and-volitions} - -Több projekt is kínál olyan validium- és volitionimplementációkat, amelyeket Ön is beépíthet a dappjaiba: - -**StarkWare StarkEx** – _A StarkEx egy Ethereum L2 skálázási megoldás, amely érvényességi bizonyítékokon alapul. ZK összevont tranzakció vagy validium adatelérhetőségi módban is működhet._ - -- [Dokumentáció](https://docs.starkware.co/starkex-v4/starkex-deep-dive/data-availability-modes#validium) -- [Honlap](https://starkware.co/starkex/) - -**Matter Labs zkPorter** – _A zkPorter egy L2 skálázási protokoll, amely a zkRollup és a sharding ötleteit ötvöző hibrid megközelítéssel kezeli az adatelérhetőséget. Tetszőlegesen sok shardot támogathat, mindegyik saját adatelérhetőségi szabályzattal._ - -- [Blog](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) -- [Dokumentáció](https://docs.zksync.io/zk-stack/concepts/data-availability) -- [Honlap](https://zksync.io/) - -## További információ {#further-reading} - -- [A validium és az L2 összevetése – 99. szám](https://www.buildblockchain.tech/newsletter/issues/no-99-validium-and-the-layer-2-two-by-two) -- [A ZK összevont tranzakciók és a validium összehasonlítása](https://blog.matter-labs.io/zkrollup-vs-validium-starkex-5614e38bc263) -- [A volition és a kialakulóban lévő adatelérhetőségi spektrum](https://medium.com/starkware/volition-and-the-emerging-data-availability-spectrum-87e8bfa09bb) -- [Összevont tranzakciók, validiumok és volitionok: ismerje meg az Ethereum legfrissebb skálázási megoldásait](https://www.defipulse.com/blog/rollups-validiums-and-volitions-learn-about-the-hottest-ethereum-scaling-solutions) diff --git "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" "b/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" deleted file mode 100644 index 4caff0bbfd0..00000000000 --- "a/public/content/translations/hu/24) Advanced Docs \342\200\223 Scaling/developers/docs/scaling/zk-rollups/index.md" +++ /dev/null @@ -1,259 +0,0 @@ ---- -title: Zero-knowledge összegzők -description: Bevezetés a zero-knowledge összevont tranzakciókba – az Ethereum közösség által használt skálázási megoldásba. -lang: hu ---- - -A zero-knowledge (ZK) összevont tranzakciók olyan második blokkláncrétegbeli (L2) [skálázási megoldások](/developers/docs/scaling/), amelyek növelik az Ethereum főhálózat tranzakcióátviteli képességét azáltal, hogy a számítást és státusztárolást a láncon kívülre helyezik. A ZK összevont tranzakciók több ezer tranzakciót képesek feldolgozni egy kötegben, majd minimális összefoglalóadatot küldenek a főhálózatra. Ez az összefoglaló adat megadja az Ethereum státuszváltozásait és a kriptográfiai bizonyítékot arra, hogy ezek a változtatások helyesek. - -## Előfeltételek {#prerequisites} - -Érdemes áttekinteni az [Ethereum skálázásról](/developers/docs/scaling/) és [L2 megoldásokról](/layer-2) szóló oldalakat. - -## Mik azok a zero-knowledge összevont tranzakciók? {#what-are-zk-rollups} - -**Zero-knowledge (ZK/nullaismeret-alapú) összevont tranzakciók** a tranzakciókat kötegekbe gyűjtik (göngyölítik), amelyeket a láncon kívül hajtanak végre. A láncon kívüli számítás csökkenti a blokkláncra küldendő adatok mennyiségét. A ZK összevont tranzakció operátorai a kötegben lévő tranzakciók által okozott változásokról összefoglalót küldenek ahelyett, hogy minden egyes tranzakciót külön-külön elküldenének. Emellett [érvényességi bizonyítékokat](/glossary/#validity-proof) is készítenek, hogy bizonyítsák a változtatásaik helyességét. - -A ZK összevont tranzakció státuszát az Ethereum hálózatra telepített okosszerződés tartja fenn. Ennek a státusznak a frissítéséhez a ZK összevont tranzakciós csomópontoknak érvényességi bizonyítékot kell benyújtaniuk ellenőrzésre. Az érvényességi bizonyíték egy kriptográfiai biztosíték arra, hogy az összevont tranzakció által javasolt státuszváltozás valóban az adott tranzakcióköteg végrehajtásának eredménye. Ez azt jelenti, hogy a ZK összevont tranzakcióknak csak érvényességi bizonyítékokat kell szolgáltatniuk ahhoz, hogy az Ethereumon a tranzakciók véglegesedjenek, ahelyett hogy az összes tranzakciós adatot a láncon tennék közzé, mint az [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/). - -A ZK összevont tranzakcióból az Ethereumba történő pénzmozgás nem jár késedelemmel, mivel a kilépési tranzakciók akkor kerülnek végrehajtásra, amikor a ZK összevont tranzakciós szerződés ellenőrzi az érvényességi bizonyítékot. Ezzel szemben az optimista összevont tranzakciókból történő pénzkivonás késleltetett, hogy szükség esetén bárki megtámadhassa a kilépési tranzakciót egy [csalási bizonyítékkal](/glossary/#fraud-proof). - -A ZK összevont tranzakciók a tranzakciókat `calldata` adatként írják az Ethereumba. A `calldata` az a hely, ahol az okosszerződés-függvények külső hívásaiban szereplő adatok tárolódnak. A `calldata` információit közzéteszik a blokkláncon, így bárki önállóan rekonstruálhatja az összevont tranzakció státuszát. A ZK összevont tranzakciók tömörítési technikákat használnak a tranzakciós adatok csökkentésére – például a számlákat cím helyett index-szel jelölik, ami 28 bájtnyi adatot takarít meg. Az adatok közzététele a láncon jelentős költséget jelent az összevont tranzakciók esetében, így az adattömörítés csökkentheti a felhasználók díjait. - -## Hogyan működnek együtt a ZK összevont tranzakciók az Ethereummal? {#zk-rollups-and-ethereum} - -A ZK összevont tranzakciós lánc egy olyan láncon kívüli protokoll, amely az Ethereum blokklánc tetején működik, és a láncon belüli Ethereum okosszerződések kezelik. A ZK összevont tranzakciók a tranzakciókat a főhálózaton kívül hajtják végre, de a láncon kívüli tranzakciós kötegeket átadják a láncon belüli összevonttranzakció-szerződésnek. Ez a tranzakciós rekord, akárcsak az Ethereum blokklánc, megváltoztathatatlan, és a ZK összevont tranzakciós láncot alkotja. - -A ZK összevont tranzakció alapvető felépítése a következő összetevőkből áll: - -1. **Láncon lévő szerződések**: A ZK összevont tranzakciós protokollt az Ethereumon futó okosszerződések irányítják. Ez magában foglalja a fő szerződést, amely tárolja az összevont tranzakciós blokkokat, nyomon követi a letéteket és figyeli a státuszfrissítéseket. Egy másik láncon belüli szerződés (a hitelesítői szerződés) ellenőrzi a blokk készítői által benyújtott zero-knowledge bizonyítékokat. Így az Ethereum a ZK összevont tranzakciók alaprétegeként vagy L1-ként szolgál. - -2. **Láncon kívüli virtuális gép (VM)**: Míg a ZK összevont tranzakciós protokoll az Ethereumon él, a tranzakciók végrehajtása és a státusztárolás az [EVM-től](/developers/docs/evm/) független, külön virtuális gépen történik. Ez a láncon kívüli VM a ZK összevont tranzakciós tranzakciók végrehajtási környezete, és a ZK összevont tranzakciós protokoll másodlagos vagy második rétegeként szolgál. Az Ethereum főhálózaton ellenőrzött érvényességi bizonyítékok garantálják a láncon kívüli VM-ben történő státuszváltozások helyességét. - -A ZK összevont tranzakciók hibrid skálázási megoldások, mivel láncon kívüli, függetlenül működő protokollok, de biztonságukat az Ethereumból merítik. Konkrétan az Ethereum-hálózat érvényesíti a státuszváltozások érvényességét a ZK összevont tranzakción, és garantálja az összevont tranzakció státuszváltozásához tartozó adatelérhetőséget. Emiatt a ZK összevont tranzakciók biztonságosabbak, mint a tisztán láncon kívüli skálázási megoldások, mint például a [mellékláncok](/developers/docs/scaling/sidechains/), amelyek maguk felelnek a biztonsági tulajdonságaikért, vagy a [validiumok](/developers/docs/scaling/validium/), amelyek bár érvényességi bizonyítékokkal ellenőrzik a tranzakciókat az Ethereumon, de a tranzakciós adatokat máshol tárolják. - -A ZK összevont tranzakciók az Ethereum fő protokolljára támaszkodnak a következőkben: - -### Adatelérhetőség {#data-availability} - -A ZK összevont tranzakciók minden egyes, a láncon kívül feldolgozott tranzakció státuszadatait közzéteszik az Ethereumon. Ezekkel az adatokkal lehetővé válik, hogy magánszemélyek vagy vállalkozások reprodukálják az összevont tranzakció státuszát, és maguk hitelesítsék a láncot. Az Ethereum ezeket az adatokat `calldata` formájában a hálózat minden résztvevője számára elérhetővé teszi. - -A ZK összevont tranzakcióknak nem kell sok tranzakciós adatot közzétenniük a láncban, mivel az érvényességi bizonyítékok már most is ellenőrzik az státuszváltozások hitelességét. Mindazonáltal az adatok láncon belüli tárolása továbbra is fontos, mivel lehetővé teszi az L2-lánc státuszának engedély nélküli, független ellenőrzését, így bárki tranzakciókötegeket küldhet be, és ezzel elejét veszi annak, hogy rosszhiszemű szereplők cenzúrázzák vagy befagyasszák a láncot. - -A felhasználóknak szükségük van a láncon lévő dolgokra ahhoz, hogy az összevont tranzakcióval interakcióban legyenek. A státuszadatokhoz elérése nélkül a felhasználók nem tudják lekérdezni a számlaegyenlegüket, illetve nem tudnak státuszinformációkra támaszkodó tranzakciókat (pl. pénzfelvételt) kezdeményezni. - -### Tranzakcióvéglegesség {#transaction-finality} - -Az Ethereum a ZK összevont tranzakciók elszámolási rétegeként működik: az L2 tranzakciók csak akkor kerülnek véglegesítésre, ha az L1 szerződés elfogadja az érvényességi bizonyítékot. Ez kiküszöböli annak kockázatát, hogy a rosszindulatú szereplők megrongálják a láncot (pl. ellopják a pénzeszközöket), mivel minden tranzakciót jóvá kell hagyni a főhálózaton. Az Ethereum azt is garantálja, hogy a felhasználói műveleteket nem lehet visszafordítani, miután véglegesítették azokat az L1-en. - -### Cenzúraálló kialakítás {#censorship-resistance} - -A legtöbb ZK összevont tranzakció egy „szupercsomópontot” (az operátort) használ a tranzakciók végrehajtására, a kötegek előállítására és a blokkok L1-re küldésére. Ez biztosítja ugyan a hatékonyságot, de növeli a cenzúra kockázatát: a rosszindulatú ZK összevonttranzakció-üzemeltetők cenzúrázhatják a felhasználókat azáltal, hogy megtagadják a tranzakciók kötegekbe való felvételét. - -Biztonsági intézkedésként a ZK összevont tranzakciók lehetővé teszik a felhasználók számára, hogy tranzakciókat nyújtsanak be közvetlenül a főhálózat összevont tranzakciós szerződéshez, ha úgy gondolják, hogy az üzemeltető cenzúrázza őket. Ezzel a felhasználók átléphetnek a ZK összevont tranzakcióból az Ethereumra az üzemeltető engedélye nélkül. - -## Hogyan működnek a ZK összevont tranzakciók? {#how-do-zk-rollups-work} - -### Tranzakciók {#transactions} - -A ZK összevont tranzakció felhasználói aláírják a tranzakciókat, és elküldik az L2 operátoroknak feldolgozásra és a következő kötegbe való felvételre. Bizonyos esetekben az operátor egy centralizált résztvevő, az úgynevezett szekvenszer, amely végrehajtja a tranzakciókat, kötegekbe gyűjti azokat, és továbbítja az L1-nek. Ebben a rendszerben a szekvenszer az egyetlen olyan entitás, amely L2 blokkokat állíthat elő és összevont tranzakciókat adhat hozzá a ZK összevont tranzakciós szerződéshez. - -Más ZK összevont tranzakciók egy [proof-of-stake (letétigazolás)](/developers/docs/consensus-mechanisms/pos/) alapú validátorcsoport használatával rotálják az operátori szerepet. A leendő üzemeltetők pénzt helyeznek el az összevont tranzakciós szerződésben, és az egyes letétek nagysága befolyásolja a letétbe helyező esélyeit arra, hogy kiválasztják a következő köteg előállítására. Az operátort meg lehet büntetni a letétje mértékéig, ha rosszindulatúan cselekszik, ami arra ösztönzi, hogy érvényes blokkokat tegyen közzé. - -#### Hogyan teszik közzé a ZK összevont tranzakciók a tranzakciós adatokat az Ethereumon {#how-zk-rollups-publish-transaction-data-on-ethereum} - -A tranzakciós adatokat az Ethereumon `calldata` adatként publikálják. A `calldata` egy adatterület az okosszerződésben, amelyet arra használnak, hogy argumentumokat adjanak át egy függvénynek, és a [memóriához](/developers/docs/smart-contracts/anatomy/#memory) hasonlóan viselkedik. Bár a `calldata` nem az Ethereum státuszának részeként tárolódik, az Ethereum [historikus naplózásában](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html?highlight=memory#logs) fennmarad a láncban. A `calldata` nem befolyásolja az Ethereum státuszát, így olcsó adattárolást tesz lehetővé a láncban. - -A `calldata` kulcsszó gyakran azonosítja a tranzakció által meghívott okosszerződés-metódust, és annak bemeneteit egy tetszőleges bájtsorozat formájában tartalmazza. A ZK összevont tranzakciók a `calldata` mezőt használják a tömörített tranzakciós adatok láncon belüli közzétételére; az összevonttranzakció-operátor új köteget ad hozzá az összevont tranzakciós szerződésben szereplő függvény meghívásával, és az adatokat a függvény argumentumaként adja át. Ez segít csökkenteni a felhasználók költségeit, mivel az összevont tranzakciós díjak nagy részét a tranzakciós adatok láncban történő tárolására fordítják. - -### Státuszrögzítések {#state-commitments} - -A ZK összevont tranzakció státusza, amely az L2 számlákat és egyenlegeket tartalmazza, egy [Merkle-fa](/whitepaper/#merkle-trees) formájában jelenik meg. A Merkle-fa gyökerének (Merkle-gyökér) kriptográfiai hash-e a láncon belüli szerződésben van tárolva, így az összevonttranzakció-protokoll nyomon követheti a ZK összevont tranzakció státuszában bekövetkező változásokat. - -Az összevont tranzakció egy új tranzakcióhalmaz végrehajtása után új státuszba lép. A státuszváltozást kezdeményező operátornak ki kell számolnia egy új státuszgyökeret, és be kell nyújtania azt a láncon belüli szerződésnek. Ha a köteghez tartozó érvényességi bizonyítékot a hitelesítő szerződés igazolja, az új Merkle-gyökér lesz a ZK összevont tranzakció kanonikus státuszgyökere. - -A státuszgyökerek kiszámítása mellett a ZK összevont tranzakciós operátor létrehoz egy köteggyökeret is, ami a kötegben lévő tranzakciókat tartalmazó Merkle-fa gyökere. Egy új köteg benyújtásakor az összevont tranzakciós szerződés tárolja a köteggyökeret, így a felhasználók bizonyítani tudják, hogy egy tranzakció (például egy kifizetési kérelem) szerepel a kötegben. A felhasználóknak meg kell adniuk a tranzakció adatait, a köteggyökeret és egy [Merkle bizonyítékot](/developers/tutorials/merkle-proofs-for-offline-data-integrity/), amely megmutatja a belefoglalás útvonalát. - -### Érvényességi bizonyítékok {#validity-proofs} - -Az új státuszgyökér, amelyet a ZK összevont tranzakció operátora az L1 szerződésnek benyújt, az összevont tranzakció státuszának frissítéséből származik. Tegyük fel, hogy Alice 10 tokent küld Bobnak, az operátor egyszerűen csökkenti Alice egyenlegét 10-zel, és növeli Bob egyenlegét 10-zel. Az operátor ezután a frissített számlaadatokat hash-eli, újjáépíti az összevont tranzakció Merkle-fáját, és az új Merkle-gyökeret elküldi a láncban lévő szerződésnek. - -Az összevont tranzakciós szerződés azonban nem fogadja el automatikusan a javasolt státuszelköteleződést, amíg az operátor nem bizonyítja, hogy az új Merkle-gyökér az összevont tranzakció státuszának helyes frissítéséből származik. A ZK összevont tranzakció operátora ezt úgy éri el, hogy érvényességi bizonyítékot állít elő, amely egy tömör kriptográfiai elköteleződés, amely a kötegelt tranzakciók helyességét igazolja. - -Az érvényességi bizonyítékok lehetővé teszik a felek számára, hogy igazolják egy állítás helyességét anélkül, hogy felfednék az állítást – ezért nevezik őket felfedés nélküli (zero-knowledge) bizonyításnak is. A ZK összevont tranzakciók érvényességi bizonyítékokat használnak a láncon kívüli státuszváltozások helyességének megerősítésére, és a tranzakciókat nem kell újra végrehajtani az Ethereumon. Ezek az érvényességi bizonyítékok [ZK-SNARK](https://arxiv.org/abs/2202.06877) (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge, vagyis zero-knowledge tömörített nem interaktív érv ismeretre) vagy [ZK-STARK](https://eprint.iacr.org/2018/046) (Zero-Knowledge Scalable Transparent Argument of Knowledge, vagyis zero-knowledge skálázható transzparens érv ismeretre) formájában érkezhetnek. - -A SNARK-ok és a STARK-ok egyaránt segítenek igazolni a ZK összevont tranzakciókban a láncon kívüli számítás integritását, bár mindegyik típusnak vannak sajátos jellemzői. - -**ZK-SNARK-ok** - -A ZK-SNARK protokoll működéséhez szükség van a nyilvános paraméterek (közös hivatkozási karakterlánc/CRS) létrehozására: a CRS nyilvános paramétereket biztosít az érvényességi bizonyítékok igazolásához és ellenőrzéséhez. A bizonyítási rendszer biztonsága a CRS beállításától függ; ha a nyilvános paraméterek létrehozásához használt információk rosszindulatú szereplők birtokába jutnak, akkor képesek lehetnek hamis érvényességi bizonyítékokat generálni. - -Egyes ZK összevont tranzakciók úgy próbálják megoldani ezt a problémát, hogy egy [többszereplős számítási ceremóniát (MPC)](https://zkproof.org/2021/06/30/setup-ceremonies/amp/) használnak, melynek során megbízható személyekkel nyilvános paramétereket generálnak a ZK-SNARK folyamat számára. Mindegyik fél ad némi véletlenszerűséget (úgynevezett „mérgező hulladékot”) a CRS konstrukciójához, amelyet azonnal meg kell semmisíteniük. - -Ezt a bizalmat igénylő felállást azért használják, mert ez növeli a CRS-beállítás biztonságát. Amíg legalább egy becsületes résztvevő megsemmisíti a bemenetét, a ZK-SNARK rendszer biztonsága garantált. Ez a megközelítés azonban megköveteli, hogy az érintettek bízzanak abban, hogy törlik a mintavételezett véletlenszerűséget, és nem ássák alá a rendszer biztonsági garanciáit. - -A bizalmi feltételezésektől eltekintve a ZK-SNARK-ok népszerűek a kis bizonyítékméret és az állandó ellenőrzési idő miatt. Mivel a bizonyítékok L1-en történő ellenőrzése jelenti a ZK összevont tranzakció működtetésének nagyobb költségét, az L2-k ZK-SNARK-okat használnak a főhálózaton gyorsan és olcsón ellenőrizhető bizonyítékok létrehozására. - -**ZK-STARK-ok** - -A ZK-SNARK-okhoz hasonlóan a ZK-STARK-ok is a bemenetek felfedése nélkül bizonyítják a láncon kívüli számítás érvényességét. A ZK-STARK-ok azonban skálázhatóságuk és átláthatóságuk miatt a ZK-SNARK-okhoz képest előrelépésnek számítanak. - -A ZK-STARK-ok átláthatók, mivel a közös referenciasorozat (CRS) megbízható beállítása nélkül is működnek. Ehelyett a ZK-STARK-ok nyilvánosan ellenőrizhető véletlenszerűségre támaszkodnak a bizonyítások generálásához és ellenőrzéséhez szükséges paraméterek beállításához. - -A ZK-STARK-ok nagyobb skálázhatóságot is biztosítanak, mivel az érvényességi bizonyítékok igazolásához és ellenőrzéséhez szükséges idő _kvázilineárisan_ növekszik a mögöttes számítás bonyolultságához képest. A ZK-SNARK-okkal a bizonyítási és ellenőrzési idők _lineárisan_ skálázódnak a mögöttes számítás méretéhez képest. Ez azt jelenti, hogy a ZK-STARK-oknak kevesebb időre van szükségük a bizonyításhoz és ellenőrzéshez, mint a ZK-SNARK-oknak, amikor nagy adathalmazokról van szó, ami nagy volumenű alkalmazásokhoz teszi őket hasznossá. - -A ZK-STARK-ok a kvantumszámítógépek ellen is biztonságosak, míg a ZK-SNARK-okban használt elliptikus görbe kriptográfia (ECC) széles körben úgy vélik, hogy sebezhető a kvantumszámítógépekkel szemben. A ZK-STARK-ok hátránya, hogy nagyobb méretű bizonyítékokat készítenek, amelyeket drágább ellenőrizni az Ethereumon. - -#### Hogyan működnek az érvényességi bizonyítékok a ZK összevont tranzakciókban? {#validity-proofs-in-zk-rollups} - -##### Bizonyíték készítése - -A tranzakciók elfogadása előtt az operátor elvégzi a szokásos ellenőrzéseket. Ez magában foglalja annak ellenőrzését, hogy: - -- A küldő és a fogadó számlák a státuszfa részét képezik. -- A küldőnek elegendő fedezete van a tranzakció lebonyolításához. -- A tranzakció helyes, és egyezik a küldő összevont tranzakcióbeli nyilvános kulcsával. -- A küldő nonce-ja helyes stb. - -Amint a ZK összevont tranzakciós csomópont elegendő tranzakcióval rendelkezik, összegyűjti azokat egy kötegbe, és összeszedi a bemeneteket a bizonyító folyamat számára, hogy egy tömör ZK-bizonyítékká állítsa össze. Ezek a következők: - -- A kötegben lévő tranzakciókat tartalmazó Merkle-fa gyökere. -- Merkle-bizonyítékok a tranzakciókhoz a kötegbe való felvétel bizonyítására. -- Merkle-bizonyítékok a tranzakciókban szereplő minden küldő-fogadó párra annak bizonyítására, hogy ezek a számlák az összevont tranzakció státuszfájának részét képezik. -- Közbenső státuszgyökerek halmaza, amely a státuszgyökér frissítéséből származik, miután az egyes tranzakciókhoz státuszfrissítéseket alkalmaztak (azaz csökkentették a küldőszámlákat és növelték a fogadószámlákat). - -A bizonyító folyamat úgy számítja ki az érvényességi bizonyítékot, hogy minden tranzakción végigmegy, és elvégzi ugyanazokat az ellenőrzéseket, amelyeket az operátor a tranzakció feldolgozása előtt elvégzett. Először is a megadott Merkle-bizonyíték segítségével ellenőrzi, hogy a küldő számlája része a meglévő státuszgyökérnek. Ezután csökkenti a küldő egyenlegét, megnöveli a nonce-ját, a frissített számlaadatokat hash-eli, és a Merkle-bizonyítékkal kombinálva létrehoz egy új Merkle-gyökeret. - -Ez a Merkle-gyökér tükrözi a ZK összevont tranzakció státuszának egyetlen változását: a küldő egyenlegének és a nonce-nak a változását. Ez azért lehetséges, mert a számla létezésének bizonyítására használt Merkle-bizonyítékot használják az új státuszgyökér létrehozására. - -A bizonyító folyamat ugyanezt végzi a fogadó számláján. Ellenőrzi, hogy a fogadó számlája létezik-e a köztes státuszgyökér alatt (a Merkle-bizonyítékkal), növeli az egyenlegét, újra-hash-eli a számlaadatokat, és a Merkle-bizonyítékkal kombinálva létrehoz egy új státuszgyökeret. - -A folyamat minden tranzakciónál megismétlődik; minden ciklus új státuszgyökeret hoz létre a küldő számlájának frissítéséből, és egy következő új gyökeret a fogadó számlájának frissítéséből. A státuszgyökér frissítése azt mutatja, hogy az összevont tranzakció státuszfájának egy része megváltozik. - -A ZK bizonyító folyamat a teljes tranzakciós köteg felett iterál, és ellenőrzi a frissítések azon sorozatát, amely az utolsó tranzakció végrehajtása után egy végső státuszgyökeret eredményez. Az utolsó kiszámított Merkle-gyökér lesz a ZK-rollup legújabb kanonikus státuszgyökere. - -##### Bizonyíték-ellenőrzés - -Miután a bizonyító folyamat igazolja a státuszfrissítések helyességét, az L2 operátor benyújtja a kiszámított érvényességi bizonyítékot az L1-en lévő hitelesítő szerződésnek. A szerződés ellenőrző folyamata igazolja a bizonyíték érvényességét, és ellenőrzi a bizonyítás részét képező nyilvános bemeneteket is: - -- **Korábbi státuszgyökér**: A ZK összevont tranzakció régi státuszgyökere (a kötegelt tranzakciók végrehajtása előtt), amely az L2-lánc utolsó ismert érvényes státuszát tükrözi. - -- **Új státuszgyökér**: A ZK összevont tranzakció új státuszgyökere (a kötegelt tranzakciók végrehajtása után), amely az L2-lánc legújabb státuszát tükrözi. Az új státuszgyökér az a végső gyökér, amely a bizonyító folyamatban a státuszfrissítések után keletkezik. - -- **Köteggyökér**: A köteg Merkle-gyökere, amelyet a kötegben lévő tranzakciók _merkle-izálásával_ és a fa gyökerének hash-elésével kapunk. - -- **Tranzakciós bemenetek**: A benyújtott köteg részeként végrehajtott tranzakciókhoz kapcsolódó adatok. - -Ha a bizonyíték kielégíti a folyamatot (azaz érvényes), akkor létezik azon érvényes tranzakciók halmaza, amelyek az összevont tranzakciót az előző státuszából (a korábbi státuszgyökér által kriptográfiai ujjlenyomatokkal ellátva) egy új státuszba (az újstátuszgyökér által kriptográfiai ujjlenyomatokkal ellátva) vezetik át. Ha a korábbi státuszgyökér megegyezik az összevont tranzakciós szerződésben tárolt gyökérrel, és a bizonyíték érvényes, az összevont tranzakciós szerződés átveszi az új státuszgyökeret a bizonyítékból, és frissíti a státuszfáját, hogy tükrözze az összevont tranzakció megváltozott státuszát. - -### Belépés és kilépés {#entries-and-exits} - -A felhasználók úgy lépnek be a ZK összevont tranzakcióba, hogy tokeneket helyeznek el az összevont tranzakció L1-en lévő szerződésében. Ez a tranzakció bekerül a sorba, mivel csak az operátorok nyújthatnak be tranzakciókat az összevont tranzakciós szerződéshez. - -Ha a függőben lévő befizetési sor kezd megtelni, a ZK összevont tranzakció operátora átveszi a befizetési tranzakciókat, és benyújtja azokat az összevont tranzakciós szerződéshez. Amint a felhasználó pénzeszközei az összevont tranzakcióban vannak, elkezdheti használni azáltal, hogy tranzakciókat küld az operátornak feldolgozásra. A felhasználók ellenőrizhetik az egyenlegeket az összevont tranzakción a számlaadataik hash-elésével, a hash elküldésével az összevont tranzakció-szerződésnek, és egy Merkle-bizonyítékkal, amelyet az aktuális státuszgyökérrel szemben ellenőriznek. - -A ZK összevont tranzakcióból az L1-re való visszalépés egyszerű. A felhasználó kezdeményezi a kilépési tranzakciót azzal, hogy az összevont tranzakcióban lévő eszközeit egy megadott számlára küldi elégetés céljából. Ha az üzemeltető felveszi a tranzakciót a következő kötegbe, a felhasználó kivételi kérelmet nyújthat be a láncon belüli szerződéshez. Ez a kivételi kérelem a következőket tartalmazza: - -- Merkle bizonyíték, amely bizonyítja, hogy a felhasználó tranzakciója egy tranzakciókötegben szerepel az elégetési számlán - -- Tranzakciós adatok - -- Köteggyökér - -- L1 cím a befizetett pénzeszközök fogadására - -az összevont tranzakciós szerződés hash-eli a tranzakció adatait, ellenőrzi, hogy létezik-e a köteggyökér, és a Merkle-bizonyíték segítségével ellenőrzi, hogy a tranzakció hash része-e a köteggyökérnek. Ezt követően a szerződés végrehajtja a kilépési tranzakciót, és elküldi a pénzt a felhasználó által az L1-en kiválasztott címre. - -## A ZK összevont tranzakciók és az EVM kompatibilitása {#zk-rollups-and-evm-compatibility} - -Az optimista összevont tranzakciókkal ellentétben a ZK összevont tranzakciók nem kompatibilisek az [Ethereum virtuális géppel (EVM)](/developers/docs/evm/). Az általános célú EVM-számítás bizonyítási folyamata nehezebb és erőforrás-igényesebb, mint az egyszerű számítások bizonyítása (mint például a tokenátvitel). - -A [zero-knowledge technológia fejlődése](https://hackmd.io/@yezhang/S1_KMMbGt#Why-possible-now) azonban újból felkeltette az érdeklődést az EVM-számítás zero-knowledge bizonyítékokba csomagolása iránt. Ezek az erőfeszítések egy olyan zero-knowledge EVM (zkEVM) implementáció létrehozására irányulnak, amely hatékonyan képes ellenőrizni a programvégrehajtás helyességét. A zkEVM újrateremti a meglévő EVM opkódokat a bizonyítási/ellenőrzési folyamathoz, lehetővé téve az okosszerződések végrehajtását. - -Az EVM-hez hasonlóan a zkEVM is státuszváltozást okoz, miután bizonyos bemeneteken számításokat végeztek. A különbség az, hogy a zkEVM zero-knowledge bizonyítékokat is készít, hogy ellenőrizze a programvégrehajtás lépéseinek helyességét. Az érvényességi bizonyítékok ellenőrizhetik a VM státuszát érintő műveletek helyességét (memória, stack, tárhely) és magát a számítást (a művelet a megfelelő opkódokat hívta meg és helyesen hajtotta végre). - -Az EVM-kompatibilis ZK összevont tranzakciók bevezetése várhatóan segít a fejlesztőknek kihasználni a zero-knowledge bizonyítékok skálázhatóságát és biztonsági garanciáit. Ami még fontosabb, a natív Ethereum infrastruktúrával való kompatibilitás azt jelenti, hogy a fejlesztők ZK-barát dappokat építhetnek ismerős (és kipróbált) eszközökkel és nyelvekkel. - -## Hogyan működnek a ZK összevont tranzakciós díjak? {#how-do-zk-rollup-fees-work} - -Az, hogy a felhasználók mennyit fizetnek a tranzakciókért a ZK összevont tranzakciókon, az Ethereum főhálózathoz hasonlóan a gázdíjtól függ. A gázdíjak azonban az L2 esetében másképp alakulnak, és a következő költségek befolyásolják: - -1. **Státuszfrissítés**: Az Ethereum státuszába való írás (azaz egy tranzakció benyújtása az Ethereum blokkláncán) fix költséggel jár. A ZK összevont tranzakciók a tranzakciók kötegelésével és a fix költségek több felhasználóra történő elosztásával csökkentik ezt a költséget. - -2. **Adatközzététel**: A ZK összevont tranzakciók minden tranzakció státuszadatait `calldata` mezőként teszik közzé az Ethereumban. A `calldata` költségeit jelenleg az [EIP-1559](https://eips.ethereum.org/EIPS/eip-1559) szabályozza, amely a `calldata` nem nulla bájtjaira 16, nulla bájtjaira 4 gázköltséget ír elő. A tranzakció költségét az befolyásolja, hogy mennyi `calldata`-t kell a láncban közzétenni. - -3. **L2 operátordíjak**: Ezt az összevont tranzakció operátorának fizetik a tranzakciók feldolgozása során felmerülő számítási költségek ellentételezéseként, hasonlóan az Ethereum főhálózat [tranzakciós prioritási díjaihoz (borravaló)](/developers/docs/gas/#how-are-gas-fees-calculated). - -4. **Bizonyítéklétrehozás és ellenőrzés**: A ZK összevont tranzakció operátorainak érvényességi bizonyítékokat kell előállítaniuk a tranzakciókötegekhez, ami erőforrás-igényes. A zero-knowledge bizonyítékok ellenőrzése a főhálózaton szintén gázba kerül (kb. 500 000 gáz). - -A tranzakciók kötegelése mellett a ZK összevont tranzakciók a tranzakciós adatok tömörítésével csökkentik a felhasználók díjait. [Megtekinthet egy valós idejű kalkulációt](https://l2fees.info/) arról, hogy mennyibe kerül az Ethereum ZK összevont tranzakciók használata. - -## Hogyan skálázzák a ZK összevont tranzakciók az Ethereumot? {#scaling-ethereum-with-zk-rollups} - -### Tranzakciós adatok tömörítése {#transaction-data-compression} - -A ZK összevont tranzakciók növelik az Ethereum alaprétegének tranzakcióátvitelét azáltal, hogy a számításokat a láncon kívülre viszik, de a skálázás valódi lendületét a tranzakciós adatok tömörítése adja. Az Ethereum [blokkmérete](/developers/docs/blocks/#block-size) korlátozza az egyes blokkokban tárolható adatokat, és ezáltal a blokkonként feldolgozott tranzakciók számát. A tranzakciókkal kapcsolatos adatok tömörítésével a ZK összevont tranzakciók jelentősen növelik a blokkonként feldolgozott tranzakciókat. - -A ZK összevont tranzakciók jobban tudják tömöríteni a tranzakciós adatokat, mint az optimista összevont tranzakciók, mivel nem kell a tranzakciók érvényesítéséhez szükséges összes adatot elküldeniük. Minimális adatot kell elküldeniük, amellyel újra lehet építeni az összevont tranzakción lévő számlák és egyenlegek legfrissebb státuszát. - -### Rekurzív bizonyítékok {#recursive-proofs} - -A zero-knowledge bizonyítékok előnye, hogy azok más bizonyítékokat is ellenőrizhetnek. Például egy ZK-SNARK ellenőrizhet más ZK-SNARK-okat. Ezek a rekurzív bizonyítékok drámaian megnövelik a ZK összevont tranzakciók teljesítményét. - -Jelenleg az érvényességi bizonyítékokat blokkonként generálják, és az L1-szerződéshez nyújtják be ellenőrzésre. Az egy blokkra vonatkozó bizonyítékok ellenőrzése korlátozza a ZK összevont tranzakciók tranzakcióátvitelét, mivel csak egy blokk véglegesíthető, amikor az operátor benyújtja a bizonyítékot. - -A rekurzív bizonyítékok révén ugyanakkor egyetlen érvényességi bizonyítékkal több blokkot is véglegesíthetünk. Ennek az az oka, hogy a bizonyító folyamat rekurzív módon több blokkbizonyítékot aggregál, amíg egy végső bizonyíték létre nem jön. Az L2 operátor benyújtja ezt a rekurzív bizonyítékot, és ha a szerződés elfogadja azt, akkor az összes vonatkozó blokk azonnal véglegesítésre kerül. A rekurzív bizonyítékokkal nő az Ethereumon az adott időperiódusban véglegesíthető ZK összevont tranzakciók száma. - -### A ZK összevont tranzakciók előnyei és hátrányai {#zk-rollups-pros-and-cons} - -| Előnyök | Hátrányok | -| ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Az érvényességi bizonyítékok biztosítják a láncon kívüli tranzakciók helyességét, és megakadályozzák, hogy az operátorok érvénytelen státuszváltozásokat hajtsanak végre. | Az érvényességi bizonyítékok kiszámításával és ellenőrzésével járó költségek jelentősek, és növelhetik az összevont tranzakciók felhasználóinak díjait. | -| Gyorsabb tranzakciós véglegesítést kínál, mivel a státuszfrissítések jóváhagyása az érvényességi bizonyítékok L1-en történő ellenőrzése után történik. | Az EVM-kompatibilis ZK összevont tranzakciók építése a zero-knowledge technológia összetettsége miatt nehéz. | -| Bizalomigény nélküli kriptográfiai mechanizmusokra támaszkodik a biztonság érdekében, nem pedig az ösztönzött szereplők őszinteségére, mint az [optimista összevont tranzakciók](/developers/docs/scaling/optimistic-rollups/#optimistic-pros-and-cons) esetében. | Az érvényességi bizonyítékok előállításához speciális hardverre van szükség, ami ösztönözheti a lánc néhány fél általi centralizált ellenőrzését. | -| A láncon kívüli státusz megállapításához szükséges adatokat az L1-en tárolja, ami garantálja a biztonságot, a cenzúraellenességet és a decentralizációt. | A centralizált operátorok (szekvencerek) befolyásolhatják a tranzakciók sorrendjét. | -| A felhasználók nagyobb tőkehatékonyságot élveznek, és késedelem nélkül vehetnek fel pénzt az L2-ről. | A hardver-követelmények csökkenthetik azon résztvevők számát, akik a láncot működésre kényszeríthetik, növelve annak kockázatát, hogy a rosszindulatú operátorok befagyasztják az összevont tranzakció státuszát és cenzúrázzák a felhasználókat. | -| Nem függ az elérhetőségi feltételezésektől, és a felhasználóknak nem kell validálniuk a láncot, hogy megvédjék pénzeszközeiket. | Egyes bizonyítási rendszerek (pl. a ZK-SNARK) megbízható beállításokat igényelnek, amelyek rossz kezelés esetén potenciálisan veszélyeztethetik az összevont tranzakció biztonsági modelljét. | -| A jobb adattömörítés segíthet csökkenteni a `calldata` közzétételének költségeit az Ethereumban, és minimalizálhatja a felhasználók összevonttranzakció-díjait. | | - -### A ZK összevont tranzakciók vizuális bemutatása {#zk-video} - -Nézze meg a videót, melyben a Finematics elmagyarázza a ZK összevont tranzakciók lényegét: - - - -### ZK összevont tranzakciók használata {#use-zk-rollups} - -A ZK összevont tranzakcióknak többféle megvalósítása létezik, amelyeket integrálhat a dappjaiba: - - - -## Kik dolgoznak zkEVM-en? {#zkevm-projects} - -Többek között az alábbi projektek dolgoznak zkEVM-en: - -- **[zkEVM](https://github.com/privacy-scaling-explorations/zkevm-specs)** - _A zkEVM az Ethereum Alapítvány által finanszírozott projekt, amelynek célja egy EVM-kompatibilis ZK összevont tranzakció létrehozása és egy mechanizmus kifejlesztése az Ethereum blokkok érvényességi bizonyítékainak generálására._ - -- **[Polygon zkEVM](https://polygon.technology/solutions/polygon-zkevm)** - _Egy decentralizált ZK összevont tranzakció az Ethereum főhálózaton, amely egy zero-knowledge Ethereum virtuális gépen (zkEVM) dolgozik, amely Ethereum tranzakciókat hajt végre átlátható módon, beleértve a zero-knowledge-bizonyíték igazolásásra alkalmas okosszerződéseket is._ - -- **[Scroll](https://scroll.io/blog/zkEVM)** - _Scroll egy tech-központú vállalat, amely egy natív zkEVM L2 megoldás létrehozásán dolgozik az Ethereum számára._ - -- **[Taiko](https://taiko.xyz)** - _A Taiko egy decentralizált, Ethereum-egyenértékű ZK összevont tranzakció ([1-es típusú ZK-EVM](https://vitalik.eth.limo/general/2022/08/04/zkevm.html))._ - -- **[ZKsync](https://docs.zksync.io/)** - _A ZKsync Era egy EVM-kompatibilis ZK összevont tranzakció, amelyet a Matter Labs készített a saját zkEVM-jével alátámasztva._ - -- **[Starknet](https://starkware.co/starknet/)** - _A StarkNet egy EVM-kompatibilis L2 skálázási megoldás, amelyet a StarkWare készített._ - -- **[Morph](https://www.morphl2.io/)** - _Morph egy olyan hibrid összevont tranzakció skálázási megoldás, mely zk-bizonyítékot használ, hogy kezelje az L2-höz kapcsolódó státuszmegkérdőjelezés problémáját._ - -## További olvasnivaló a ZK összevont tranzakciókról {#further-reading-on-zk-rollups} - -- [Mik azok a zero-knowledge összevont tranzakciók?](https://coinmarketcap.com/alexandria/glossary/zero-knowledge-rollups) -- [Mik azok a zero-knowledge összevont tranzakciók?](https://alchemy.com/blog/zero-knowledge-rollups) -- [A STARK-ok és a SNARK-ok összehasonlítása](https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/) -- [Mi az a zkEVM?](https://www.alchemy.com/overviews/zkevm) -- [ZK-EVM típusok: Ethereum-egyenértékű, EVM-egyenértékű, 1. típus, 4. típus és egyéb rejtélyes kifejezések](https://taiko.mirror.xyz/j6KgY8zbGTlTnHRFGW6ZLVPuT0IV0_KmgowgStpA0K4) -- [Bevezetés a zkEVM-be](https://hackmd.io/@yezhang/S1_KMMbGt) -- [Awesome-zkEVM dokumentációk](https://github.com/LuozhuZhang/awesome-zkevm) -- [A ZK-SNARK-ok működése](https://vitalik.eth.limo/general/2017/02/01/zk_snarks.html) -- [Hogyan lehetséges a SNARK?](https://vitalik.eth.limo/general/2021/01/26/snarks.html) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md deleted file mode 100644 index c982c906241..00000000000 --- a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Adatszerkezetek és kódolás -description: Az alapvető Ethereum adatstruktúrák áttekintése. -lang: hu -sidebarDepth: 2 ---- - -Az Ethereum nagy adatkötegeket hoz létre, tárol és mozgat. Az adatot standard és memóriahatékony módon kell formázni, hogy bárki tudjon [csomópontot futtatni](/run-a-node/) viszonylag szerény, fogyasztói szintű hardveren. Ehhez az Ethereum stackben számos speciális adatstruktúra található. - -## Előfeltételek {#prerequisites} - -Ehhez érdemes áttekinteni az Ethereum és a [kliensszoftver](/developers/docs/nodes-and-clients/) alapjait. Emellett javasoljuk, hogy a hálózati réteggel és az [Ethereum fehérkönyvvel](/whitepaper/) is ismerkedjen meg. - -## Adatstruktúrák {#data-structures} - -### Patricia Merkle-fák {#patricia-merkle-tries} - -A Patricia Merkle-fák olyan struktúrák, melyek kulcs-érték párokat kódolnak egy determinisztikus és kriptográfiailag hitelesített fastruktúrává. Ezeket kiterjedten használják az Ethereum végrehajtási rétegén. - -[Bővebben a Patricia Merkle-fákról](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) - -### Rekurzív hosszúságú prefixum (RLP) {#recursive-length-prefix} - -A rekurzív hosszúságú prefixum (RLP) egy sorozatosítási módszer, melyet kiterjedten használnak az Ethereum végrehajtási rétegén. - -[További tudnivalók az RLP-ről](/developers/docs/data-structures-and-encoding/rlp) - -### Egyszerű sorosítás (SSZ) {#simple-serialize} - -Az egyszerű sorosítás (SSZ) a domináns sorosítási formátum az Ethereum konszenzus rétegén, mivel kompatibilis a merklelizációval. - -[További tudnivalók az SSZ-ről](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md deleted file mode 100644 index 255ceabf37f..00000000000 --- a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md +++ /dev/null @@ -1,263 +0,0 @@ ---- -title: Merkle Patricia-fa -description: Bevezetés a Merkle Patricia-fa témájába. -lang: hu -sidebarDepth: 2 ---- - -Az Ethereum státusza (az összes számla, egyenleg és okosszerződés) bele van kódolva az informatikában Merkle-fa néven ismert adatszerkezet egy speciális változatába. Ez a struktúra számos kriptográfiai alkalmazásban hasznos, mert ellenőrizhető kapcsolatot hoz létre a fában összefonódott összes egyedi adat között, és egyetlen **gyökérértéket** eredményez, amely felhasználható az adatok bizonyítására. - -Az Ethereum adatszerkezete egy „módosított Merkle-Patricia-fa (trie)”, amely azért kapta ezt a nevet, mert a PATRICIA (Practical Algorithm To Retrieve Information Coded in Alphanumeric/gyakorlati algoritmus az alfanumerikusan kódolt információk visszakeresésére) néhány jellemzőjét kölcsönzi, továbbá az Ethereum státuszát alkotó elemek hatékony lekérdezésére (re**trie**val) tervezték. - -A Merkle-Patricia-fa determinisztikus és kriptográfiailag ellenőrizhető: a státusz gyökerét csak úgy lehet előállítani, ha azt a státusz minden egyes darabjából kiszámítjuk, és két azonos státusz könnyen bizonyítható a gyökér-hash és az ahhoz vezető hash-ek az összehasonlításával (_Merkle-bizonyíték_). Ezzel szemben nem lehet két különböző státuszt létrehozni ugyanazzal a gyökér-hash-értékkel, és minden olyan kísérlet, hogy a státuszt különböző értékekkel módosítsák, más státusz gyökér-hash-t eredményez. Elméletileg ez a struktúra biztosítja a `O(log(n))` hatékonyság „szent grálját” a beleírások, keresések és törlések esetében. - -A közeljövőben az Ethereum tervezi, hogy áttér a [Verkle-fastruktúrára](https://ethereum.org/en/roadmap/verkle-trees), amely új lehetőségeket nyit a jövőbeli protokollfejlesztések előtt. - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértése érdekben tekintse meg a [hashek](https://en.wikipedia.org/wiki/Hash_function), [Merkle-fák](https://en.wikipedia.org/wiki/Merkle_tree), [fák](https://en.wikipedia.org/wiki/Trie) és [sorosítás](https://en.wikipedia.org/wiki/Serialization) témákat. Ez a cikk egy alapvető [radix-fa](https://en.wikipedia.org/wiki/Radix_tree) leírásával kezdődik, majd lépésenként bemutatja az Ethereum optimalizáltabb adatszerkezetéhez szükséges módosításokat. - -## Alapvető radix-fák {#basic-radix-tries} - -Egy alapvető radix-fában minden csomópont a következőképpen néz ki: - -``` - [i_0, i_1 ... i_n, value] -``` - -Ahol `i_0 ... i_n` az ábécé (gyakran bináris vagy hexadecimális) szimbólumait jelöli, `value` a csomópontban lévő végérték, és az `i_0, i_1 ... i_n` a slotokban lévő értékek, melyek értéke `NULL` vagy más csomópontokra (itt hashekre) mutató mutatók. Ez egy alapvető `(key, value)` (kulcs, érték) tárolót alkot. - -Tegyük fel, hogy egy radixfa adatstruktúráját szeretnénk használni a kulcs-érték párosok halmaza feletti sorrend tárolására. Ahhoz, hogy megtaláljuk a `dog` kulcshoz jelenleg hozzárendelt értéket a fában, először a `dog` szót alakítjuk át az ábécé betűivé (amely `64 6f 67`), majd haladunk lefelé a fában, amíg meg nem találjuk az értéket. Ez azt jelenti, hogy a gyökérhash keresésével kezdjük egy kulcs/érték adatbázisban (DB), hogy megtaláljuk a fa gyökérpontját. Ez más (csomó)pontokra mutató kulcsok tömbjeként jelenik meg. Ehhez a `6`-os indexnél lévő értéket kulcsként használjuk, és ezt a kulcs-érték adatbázisban megkeressük, hogy megkapjuk az egy szinttel lejjebbi csomópontot. Ezután a `4`-es indexet választjuk a következő érték megkereséséhez, majd a `6`-os indexet, és így tovább, amíg egyszer végig nem követtük az utat: `gyökér -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, ekkor megnézzük a csomópont értékét, és visszaadjuk az eredményt. - -Különbség van aközött, hogy valamit a fában vagy az alapjául szolgáló kulcs-érték adatbázisban keresünk. Mindkettő kulcs-érték elrendezést definiál, de a mögöttes adatbázis képes a kulcsok hagyományos, egylépéses keresésére. Egy kulcs keresése a fában többszöri adatbáziskeresést igényel a végső érték eléréséhez. Az adatbáziskeresést nevezzük `path` néven, hogy kiküszöböljük a félreérthetőséget. - -A radix-fák frissítési és törlési műveletei a következőképpen definiálhatók: - -``` - def update(node,path,value): - curnode = db.get(node) if node else [ NULL ] * 17 - newnode = curnode.copy() - if path == '': - newnode[-1] = value - else: - newindex = update(curnode[path[0]],path[1:],value) - newnode[path[0]] = newindex - db.put(hash(newnode),newnode) - return hash(newnode) - - def delete(node,path): - if node is NULL: - return NULL - else: - curnode = db.get(node) - newnode = curnode.copy() - if path == '': - newnode[-1] = NULL - else: - newindex = delete(curnode[path[0]],path[1:]) - newnode[path[0]] = newindex - - if all(x is NULL for x in newnode): - return NULL - else: - db.put(hash(newnode),newnode) - return hash(newnode) -``` - -A „Merkle” radix-fa a csomópontok összekapcsolásával épül fel, determinisztikusan generált kriptográfiai hash digest-ek segítségével. Ez a tartalomcímzés (a kulcs-érték adatbázisban `key == keccak256(rlp(value))`) biztosítja a tárolt adatok kriptográfiai integritását. Ha egy adott fa gyökérhashe nyilvánosan ismert, akkor aki hozzáférhet a mögöttes levél szintű adatokhoz, bizonyítékot állíthat össze arra, hogy a fa egy adott értéket tartalmaz egy adott útvonalon, azáltal hogy megadja az egyes csomópontok hashét, amelyek egy adott értéket a fa gyökeréhez kapcsolnak. - -Egy támadó számára lehetetlen egy nem létező `(path, value)` pár bizonyítása, mivel a gyökérhash az összes alatta lévő hashre épül. A mögöttes adatok módosítása megváltoztatná a gyökérhasht. A hashre úgy is gondolhat, mint az adatok szerkezeti információinak tömörített reprezentációjára, amelyet a hashfüggvény előképvédelme (pre-image) biztosít. - -A radix-fa egy atomnyi egységére (például egyetlen hexadecimális karakter vagy 4 bites bináris szám) „nibble”-ként hivatkozunk. Miközben az útvonalat bejárjuk egy-egy nibble mentén, a csomópontnak legfeljebb 16 gyermeke lehet addig, amíg egy `value` értéket tartalmaz. Ezért ezeket 17 hosszúságú tömbként ábrázoljuk. Ezeket a 17 elemű tömböket „elágazási csomópontoknak” nevezzük. - -## Merkle Patricia-fa {#merkle-patricia-trees} - -A radix-fáknak egy fő korlátja van: nem hatékonyak. Ha egy `(path, value)` kötést szeretnénk tárolni, ahol az útvonal, mint az Ethereumban, 64 karakter hosszú (a `bytes32` nibble száma), akkor több mint egy kilobájtnyi extra helyre lesz szükségünk, hogy karakterenként egy szintet tároljunk, és minden keresés vagy törlés mind a 64 lépést megteszi. A bevezetett Patricia-fa megoldotta ezt a gondot. - -### Optimalizálás {#optimization} - -A Merkle Patricia-fa egy csomópontja az egyik a következőkből: - -1. `NULL` (egy üres string) -2. `branch` Egy 17 elemű csomópont `[ v0 ... v15, vt ]` -3. `leaf` Egy 2 elemű csomópont `[ encodedPath, value ]` -4. `extension` Egy 2 elemű csomópont `[ encodedPath, key ]` - -A 64 karakteres útvonalak esetén elkerülhetetlen, hogy a fa első néhány rétegének bejárása után olyan csomóponthoz érjünk, ahol legalább az út egy részén nem létezik elágazás. Annak elkerülése érdekében, hogy az útvonal mentén akár 15 ritka `NULL` csomópontot kelljen létrehozni, a lefelé haladást egy `extension` csomópont létrehozásával levágjuk, amely a `[ encodedPath, key ]` formájú, ahol `encodedPath` tartalmazza a „részleges útvonalat”, amelyet át kell ugrani (az alább ismertetett kompakt kódolással), és a `key` a következő DB-keresésre szolgál. - -Egy `level` (levél) csomópont esetében, amelyet a `encodedPath` első nibble-jében lévő jelölővel (flag) jelölhetünk, az útvonal kódolja az összes korábbi csomópont útvonalrészletét, és közvetlenül megnézhetjük a `value` mezőt. - -Ez az optimalizálás azonban kétértelműséget eredményez. - -A nibble-ekben történő útvonalak bejárásakor előfordulhat, hogy páratlan számú nibble-t kell bejárnunk, de minden adat `bytes` formátumban van tárolva. Nem lehet különbséget tenni például az `1` és a `01` nibble között (mindkettőt `<01>`-ként kell tárolni). A páratlan hosszúság megadásához a részleges útvonal elé egy jelölőt (flag) kell illeszteni. - -### Specifikáció: Hexadecimális szekvencia kompakt kódolása opcionális befejezővel {#specification} - -Mind a _páratlan és páros fennmaradó részleges útvonalhossz_, mind a _levél és bővítmény csomópont_ jelölése a fent leírtak szerint bármely 2 elemű csomópont részleges útvonalának első nibble-jében megtalálható. Az eredmény így néz ki: - - hex char bits | node type partial path length - ---------------------------------------------------------- - 0 0000 | extension even - 1 0001 | extension odd - 2 0010 | terminating (leaf) even - 3 0011 | terminating (leaf) odd - -A páros fennmaradó útvonalhossz (`0` vagy `2`) esetén mindig egy `0` „kitöltő” nibble következik. - -``` - def compact_encode(hexarray): - term = 1 if hexarray[-1] == 16 else 0 - if term: hexarray = hexarray[:-1] - oddlen = len(hexarray) % 2 - flags = 2 * term + oddlen - if oddlen: - hexarray = [flags] + hexarray - else: - hexarray = [flags] + [0] + hexarray - // hexarray now has an even length whose first nibble is the flags. - o = '' - for i in range(0,len(hexarray),2): - o += chr(16 * hexarray[i] + hexarray[i+1]) - return o -``` - -Példák: - -``` - > [ 1, 2, 3, 4, 5, ...] - '11 23 45' - > [ 0, 1, 2, 3, 4, 5, ...] - '00 01 23 45' - > [ 0, f, 1, c, b, 8, 10] - '20 0f 1c b8' - > [ f, 1, c, b, 8, 10] - '3f 1c b8' -``` - -Ez a Merkle Patricia-fa egy csomópontjának megadásához szükséges bővített kód: - -``` - def get_helper(node,path): - if path == []: return node - if node = '': return '' - curnode = rlp.decode(node if len(node) < 32 else db.get(node)) - if len(curnode) == 2: - (k2, v2) = curnode - k2 = compact_decode(k2) - if k2 == path[:len(k2)]: - return get(v2, path[len(k2):]) - else: - return '' - elif len(curnode) == 17: - return get_helper(curnode[path[0]],path[1:]) - - def get(node,path): - path2 = [] - for i in range(len(path)): - path2.push(int(ord(path[i]) / 16)) - path2.push(ord(path[i]) % 16) - path2.push(16) - return get_helper(node,path2) -``` - -### Példa fa {#example-trie} - -Tegyük fel, hogy egy olyan fát szeretnénk, amely négy út-érték párt tartalmaz `('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')`. - -Először az elérési utakat és az értékeket `bytes` formába alakítjuk át. Az alábbiakban a _útvonalak_ tényleges bájt ábrázolását `<>` jelöli, bár a _values_ a könnyebb érthetőség érdekében továbbra is sztringként jelennek meg, `''` jelöléssel (ezek is `bytes` formában lennének): - -``` - <64 6f> : 'verb' - <64 6f 67> : 'puppy' - <64 6f 67 65> : 'coins' - <68 6f 72 73 65> : 'stallion' -``` - -Most létrehozunk egy ilyen fát a következő kulcs-érték párokkal a mögöttes adatbázisban: - -``` - rootHash: [ <16>, hashA ] - hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ] - hashB: [ <00 6f>, hashC ] - hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ] - hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] -``` - -Amikor egy csomópontra egy másik csomóponton belül hivatkozunk, akkor a `H(rlp.encode(node))` szerepel, ahol `H(x) = keccak256(x) if len(x) >= 32 else x` és `rlp.encode` az [RLP](/developers/docs/data-structures-and-encoding/rlp) kódolási függvény. - -Vegyük észre, hogy egy fa frissítésekor a kulcs-érték párt `(keccak256(x), x)` egy állandó keresőtáblában kell tárolni, _ha_ az újonnan létrehozott csomópont hossza >= 32. Ha a csomópont ennél rövidebb, nem kell tárolni, mivel az f(x) = x függvény megfordítható. - -## Fák az Ethereumban {#tries-in-ethereum} - -Az Ethereum végrehajtási rétegén minden Merkle-fa Merkle Patricia-fát használ. - -Egy blokk fejlécében 3 gyökér 3 fából származik. - -1. stateRoot (státuszgyökér) -2. transactionsRoot (tranzakciógyökér) -3. receiptsRoot (visszaigazolásgyökér) - -### Státuszfa {#state-trie} - -Egy globális státuszfa van, amely minden alkalommal frissül, amikor egy kliens feldolgoz egy blokkot. Ebben a `path` (útvonal) mindig `keccak256(ethereumAddress)` és a `value` (érték) mindig:`rlp(ethereumAccount)`. Tehát egy Ethereum `account` (számla) az egy 4 elemű tömb a következőkkel: `[nonce,balance,storageRoot,codeHash]`. Ezen a ponton érdemes megjegyezni, hogy ez a `storageRoot` (tárolási fa) egy másik Patricia-fa gyökere: - -### Tárolási fa {#storage-trie} - -A tárolási fa az, ahol _minden_ szerződésadat tárolódik. Minden számlához külön tárolási fa tartozik. Egy adott címen adott tárolási pozíción lévő értékek lekérdezéséhez szükség van a tárolási címre, a tárolt adat egész számú pozíciójára a tárolóban és a blokk azonosítójára. Ezek azután átadhatók a JSON-RPC API-ban definiált `eth_getStorageAt` paraméterként, például a 0 tárolóhelyén lévő adatok lekérdezéséhez erre a címre `0x295a70b2de5e3953354a6a8344e616ed314d7251`: - -``` -curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x0", "latest"], "id": 1}' localhost:8545 - -{"jsonrpc":"2.0","id":1,"result":"0x00000000000000000000000000000000000000000000000000000000000004d2"} - -``` - -A tároló egyéb elemeinek visszakeresése bonyolultabb, mivel először ki kell számítani a tárolási fában elfoglalt pozíciót. A pozíciót a cím és a tárolási pozíció `keccak256` hasheként kell kiszámítani, mindkettőt balra nullákkal kitöltve 32 bájt hosszúságúra. Például az adatok pozíciója az 1-es tárolóhelyen erre a címre `0x391694e7e0b0cce554cb130d723a9d27458f9298`: - -``` -keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) -``` - -A Geth konzolban ez a következőképpen kalkulálható: - -``` -> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" -undefined -> web3.sha3(key, {"encoding": "hex"}) -"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" -``` - -A `path` (útvonal) ezért `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. Ez már használható az adatok lekérdezésére a tároló fából: - -``` -curl -X POST --data '{"jsonrpc":"2.0", "method": "eth_getStorageAt", "params": ["0x295a70b2de5e3953354a6a8344e616ed314d7251", "0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9", "latest"], "id": 1}' localhost:8545 - -{"jsonrpc":"2.0","id":1,"result":"0x000000000000000000000000000000000000000000000000000000000000162e"} -``` - -Megjegyzés: A `storageRoot` az Ethereum számlára alapvetően üres, ha az nem egy szerződéses számla. - -### Tranzakciófa {#transaction-trie} - -Minden blokkhoz külön tranzakciós fa tartozik, amely ismét `(key, value)` (kulcs, érték) párokat tárol. Az út `rlp(transactionIndex)`, amely azt a kulcsot jelöli, amely megfelel egy értéknek, amelyet a következők határoznak meg: - -``` -if legacyTx: - value = rlp(tx) -else: - value = TxType | encode(tx) -``` - -Bővebb információt az [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) dokumentációban talál. - -### Visszaigazolásfa {#receipts-trie} - -Minden blokknak saját visszaigazolásfája van. A `path` (útvonal): `rlp(transactionIndex)`. A `transactionIndex` az indexe a blokkban, melybe bekerült. A visszaigazolásfát sosem frissítik. A tranzakciófához hasonlóan vannak jelenlegi és régi visszaigazolások. Egy adott visszaigazolás lekérdezéséhez visszaigazolásfából szükség van a blokkban lévő tranzakció indexére, a visszaigazoláscsomagra (payload) és a tranzakciótípusra. A visszaigazolás lehet `Receipt` típusú, amely a `TransactionType` és a `ReceiptPayload` összeadása, vagy lehet `LegacyReceipt` típusú, amely `rlp([status, cumulativeGasUsed, logsBloom, logs])` kódként van meghatározva. - -Bővebb információt az [EIP-2718](https://eips.ethereum.org/EIPS/eip-2718) dokumentációban talál. - -## További olvasnivaló {#further-reading} - -- [Módosított Merkle Patricia-fa — Hogyan menti az Ethereum a státuszt](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) -- [Merkle-használat az Ethereumban](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) -- [Az Ethereum-fa megértése](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md deleted file mode 100644 index cbbebaeb807..00000000000 --- a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/rlp/index.md +++ /dev/null @@ -1,163 +0,0 @@ ---- -title: Rekurzív hosszúságú prefix (RLP) sorosítás -description: Az RLP-kódolás bemutatása az Ethereum végrehajtási rétegen. -lang: hu -sidebarDepth: 2 ---- - -A rekurzív hosszúságú prefixum (RLP) egy sorosítási módszer, melyet kiterjedten használnak az Ethereum végrehajtási rétegén. Az RLP a csomópontok közötti adatátvitelt szabványosítja helytakarékos formátumban. Az RLP célja a bináris adatok tetszőlegesen egymásba ágyazott tömbjeinek kódolása, és ez az elsődleges kódolási módszer, amelyet az Ethereum végrehajtási rétegén az objektumok sorosítására használnak. Az RLP fő célja a struktúra kódolása; a pozitív egész számok kivételével az RLP az egyes adattípusok (pl. karakterláncok, lebegőszámok) kódolását magasabb rendű protokollokra bízza. A pozitív egész számokat nagy endián bináris formában kell ábrázolni, vezető nullák nélkül (így az egész szám értéke nulla, ami üres bájttömbnek felel meg). A vezető nullákat tartalmazó, sorosított, pozitív egész számokat az RLP-t használó magasabb rendű protokolloknak érvénytelennek kell tekinteniük. - -További információkat talál [az Ethereum Sárgakönyvben (B függelék)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19). - -Ahhoz, hogy az RLP-vel kódoljunk egy szótárt, a két javasolt kanonikus forma a következő: - -- a `[[k1,v1],[k2,v2]...]` kódot használjuk olyan kulcsokkal, melyek lexikográfiai sorrendben vannak -- a magasabb szintű Patricia-fa kódolást használjuk, mint az Ethereum - -## Definíció {#definition} - -Az RLP-kódolási funkció egy elemet vesz fel. Az elem a következő lehet： - -- egy sztring vagy karaktersorozat (bájttömb) az egy elem -- az elemek listája is egy elem -- egy pozitív egész szám egy tétel - -Például a következők mindegyike elem: - -- egy üres sztring; -- egy sztring, amely a „cat” (macska) szót tartalmazza; -- egy lista, melyben bármennyi sztring található; -- és az ennél bonyolultabb adatstruktúrák, mint `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`. -- a szám `100` - -Érdemes megjegyezni, hogy az oldal további részében a sztring kifejezés a „bináris adat bizonyos számú bájtját” jelenti; nem használunk speciális kódolást, és a sztringek tartalmát nem ismerjük (kivéve a nem minimális pozitív egész számok elleni eseteknél). - -Az RPL kódolást a következő módon definiáljuk: - -- Pozitív egész szám esetén a legrövidebb bájttömbre konvertáljuk, amelynek nagy endián értelmezése az egész szám, majd az alábbi szabályok szerint sztringként kódoljuk. -- Egy bájt, amelynek értéke a `[0x00, 0x7f]` (decimális `[0, 127]`) tartományban van, annak RLP-kódolása önmaga. -- Máskülönben, ha a sztring 0–55 bájt hosszú, az RLP-kódolás egyetlen **0x80** (decimál 128) értékű bájtból és a sztring hosszából áll, amelyet a sztring követ. Az első bájt tartománya tehát `[0x80, 0xb7]` (dec. `[128, 183]`). -- Ha a sztring több mint 55 bájt hosszú, az RLP-kódolás egyetlen bájtból áll, amelynek értéke **0xb7** (dec. 183), valamint a sztring hossza bájtokban kifejezve bináris formában, ezt követi a sztring hossza, majd a sztring. Például egy 1024 bájt hosszú sztring kódolása `\xb9\x04\x00` (dec. `185, 4, 0`), amelyet a sztring követ. Itt `0xb9` (183 + 2 = 185) az első bájt, majd az a 2 bájt `0x0400` (dec. 1024) jön, amely az aktuális sztring hosszát jelöli. Az első bájt tartománya tehát `[0xb8, 0xbf]` (dec. `[184, 191]`). -- Ha egy sztring 2^64 bájt vagy hosszabb, akkor nem kódolható. -- Ha egy lista teljes payload-ja (azaz az összes RLP-kódolt elemének együttes hossza) 0–55 bájt hosszú, az RLP-kódolás egyetlen **0xc0** értékű bájtból és a payload hosszából áll, amelyet az elemek RLP-kódolásainak összekapcsolása követ. Az első bájt tartománya tehát `[0xc0, 0xf7]` (dec. `[192, 247]`). -- Ha egy lista teljes payload-ja több mint 55 bájt hosszú, az RLP-kódolás egyetlen **0xf7** értékű bájtból, valamint a payload hosszának bájtban kifejezett hosszából áll bináris formában, amelyet a payload hossza követ, majd az elemek RLP-kódolásainak összekapcsolása. Az első bájt tartománya tehát `[0xf8, 0xff]` (dec. `[248, 255]`). - -Ez kódban a következőképpen néz ki: - -```python -def rlp_encode(input): - if isinstance(input,str): - if len(input) == 1 and ord(input) < 0x80: - return input - return encode_length(len(input), 0x80) + input - elif isinstance(input, list): - output = '' - for item in input: - output += rlp_encode(item) - return encode_length(len(output), 0xc0) + output - -def encode_length(L, offset): - if L < 56: - return chr(L + offset) - elif L < 256**8: - BL = to_binary(L) - return chr(len(BL) + offset + 55) + BL - raise Exception("input too long") - -def to_binary(x): - if x == 0: - return '' - return to_binary(int(x / 256)) + chr(x % 256) -``` - -## Példák {#examples} - -- a „dog” sztring = [ 0x83, 'd', 'o', 'g' ] -- a [ "cat", "dog" ] lista = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` -- az üres sztring ('null') = `[ 0x80 ]` -- az üres lista = `[ 0xc0 ]` -- az integer 0 = `[ 0x80 ]` -- a '\\x00' bájt = `[ 0x00 ]` -- a '\\x0f' bájt = `[ 0x0f ]` -- a '\\x04\\x00' bájt = `[ 0x82, 0x04, 0x00 ]` -- a háromnak a [halmazelméleti ábrázolása](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers) `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` -- a „Lorem ipsum dolor sit amet, consectetur adipisicing elit” sztring = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ... , 'e', 'l', 'i', 't' ]` - -## RLP-dekódolás {#rlp-decoding} - -Az RLP-kódolás szabályai és folyamata szerint az RLP-dekódolás bemenete bináris adatok tömbjének tekinthető. Az RLP-dekódolási folyamat a következő: - -1. a bemeneti adatok első bájtja (azaz előtagja) alapján dekódolja az adattípust, a tényleges adat hosszát és az eltolást; - -2. az adatok típusának és eltolásának megfelelően dekódolja az adatokat, tiszteletben tartva a pozitív egész számokra vonatkozó minimális kódolási szabályt; - -3. folytatja a bemenet többi részének dekódolását; - -Ezek közül az adattípusok és az eltolás dekódolásának szabályai a következők: - -1. az adat egy sztring, ha az első bájt tartománya (az előtag) [0x00, 0x7f], és a sztring pontosan maga az első bájt; - -2. az adat egy sztring, ha az első bájt tartománya [0x80, 0xb7], és az első bájtot az a sztring követi, amelynek hossza egyenlő az első bájt mínusz 0x80; - -3. az adat egy sztring, ha az első bájt tartománya [0xb8, 0xbf], és a sztring hossza, amelynek hossza bájtokban egyenlő az első bájt mínusz 0xb7, követi az első bájtot, és a sztring követi a sztring hosszát; - -4. az adat egy lista, ha az első bájt tartománya [0xc0, 0xf7], és a lista minden olyan eleme RLP-kódolásának összekapcsolása, amelynek teljes payload-ja megegyezik az első bájttal mínusz 0xc0, az első bájtot követi; - -5. az adat egy lista, ha az első bájt tartománya [0xf8, 0xff], és a lista teljes payload-ja, amelynek hossza megegyezik az első bájttal mínusz 0xf7, követi az első bájtot, és a lista összes elemének RLP-kódolásának konkatenációja követi a lista teljes payload-ját; - -Ez kódban a következőképpen néz ki: - -```python -def rlp_decode(input): - if len(input) == 0: - return - output = '' - (offset, dataLen, type) = decode_length(input) - if type is str: - output = instantiate_str(substr(input, offset, dataLen)) - elif type is list: - output = instantiate_list(substr(input, offset, dataLen)) - output += rlp_decode(substr(input, offset + dataLen)) - return output - -def decode_length(input): - length = len(input) - if length == 0: - raise Exception("input is null") - prefix = ord(input[0]) - if prefix <= 0x7f: - return (0, 1, str) - elif prefix <= 0xb7 and length > prefix - 0x80: - strLen = prefix - 0x80 - return (1, strLen, str) - elif prefix <= 0xbf and length > prefix - 0xb7 and length > prefix - 0xb7 + to_integer(substr(input, 1, prefix - 0xb7)): - lenOfStrLen = prefix - 0xb7 - strLen = to_integer(substr(input, 1, lenOfStrLen)) - return (1 + lenOfStrLen, strLen, str) - elif prefix <= 0xf7 and length > prefix - 0xc0: - listLen = prefix - 0xc0; - return (1, listLen, list) - elif prefix <= 0xff and length > prefix - 0xf7 and length > prefix - 0xf7 + to_integer(substr(input, 1, prefix - 0xf7)): - lenOfListLen = prefix - 0xf7 - listLen = to_integer(substr(input, 1, lenOfListLen)) - return (1 + lenOfListLen, listLen, list) - raise Exception("input does not conform to RLP encoding form") - -def to_integer(b): - length = len(b) - if length == 0: - raise Exception("input is null") - elif length == 1: - return ord(b[0]) - return ord(substr(b, -1)) + to_integer(substr(b, 0, -1)) * 256 -``` - -## További olvasnivaló {#further-reading} - -- [RLP az Ethereumon](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) -- [Ethereum háttérműködése: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) -- [Coglio, A. (2020). Ethereum Rekurzív hosszúságú prefix (RLP) az ACL2-ben. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) - -## Kapcsolódó témák {#related-topics} - -- [Patricia Merkle-fa](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md deleted file mode 100644 index e66f02ea6eb..00000000000 --- a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/ssz/index.md +++ /dev/null @@ -1,149 +0,0 @@ ---- -title: Egyszerű sorosítás (SSZ) -description: Az Ethereum egyszerű sorosítási (SSZ) formátumának magyarázata. -lang: hu -sidebarDepth: 2 ---- - -Az **egyszerű sorosítás (SSZ)** a Beacon láncon használt sorosítási módszer. Ezt használják a konszenzusrétegben, a végrehajtási rétegben használt RLP sorosítás helyett, kivéve a társak megkeresésének protokolljánál. Az SSZ determinisztikus és hatékonyan Merkle-szerűsít. Az SSZ két komponensből áll: egy sorosítási sémából és egy Merkle-szerűsítő sémából, amelyet úgy terveztek, hogy hatékonyan dolgozzon a sorosított adatstruktúrával. - -## Hogyan működik az SSZ? {#how-does-ssz-work} - -### Sorosítás {#serialization} - -Az SSZ egy olyan sorosítási séma, amely nem önleíró – inkább egy sémára támaszkodik, amelyet előre ismerni kell. Az SSZ sorosítás célja, hogy tetszőleges összetettségű objektumokat bájtsorozatként ábrázoljon. Ez egy egyszerű folyamat az alaptípusokra. Az elemet egyszerűen hexadecimális bájtokká alakítja. Az alaptípusok a következők: - -- nem aláírt egész számok -- Boolean-ek - -Az „összetett” típusok esetében a sorosítás bonyolultabb, mivel az összetett típus több elemet tartalmaz, amelyek különböző típusúak vagy különböző méretűek lehetnek, vagy mindkettő. Ha ezek az objektumok mind fix hosszúságúak (azaz az elemek mérete mindig állandó lesz, függetlenül a tényleges értékeiktől), akkor a sorosítás az összetett típus minden egyes elemének kis-endian bájtsztringekké történő átalakítása. Ezeket a bájtsztringeket összekapcsolják. A sorosított objektum a fix hosszúságú elemek bájtlista reprezentációját tartalmazza ugyanabban a sorrendben, ahogyan azok a deszerializált objektumban szerepelnek. - -A változó hosszúságú típusok esetében a tényleges adatok helyébe egy „eltolási” (offszet) érték lép az adott elem pozíciójában a sorosított objektumban. A tényleges adatok egy halomba kerülnek a sorosított objektum végén. Az eltolási érték a halomban lévő tényleges adatok kezdetének indexe, amely a megfelelő bájtokra mutató mutatóként szolgál. - -Az alábbi példa azt szemlélteti, hogyan működik az eltolás fix és változó hosszúságú elemeket tartalmazó konténer esetében: - -```Rust - - struct Dummy { - - number1: u64, - number2: u64, - vector: Vec, - number3: u64 - } - - dummy = Dummy{ - - number1: 37, - number2: 55, - vector: vec![1,2,3,4], - number3: 22, - } - - serialized = ssz.serialize(dummy) - -``` - -A `serialized` a következő szerkezetű lenne (itt 4 bitre van kitöltve, a valóságban 32 bitre van, és az áttekinthetőség kedvéért `int` ábrázolást használunk): - -``` -[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] ------------- ----------- ----------- ----------- ---------- - | | | | | - number1 number2 offset for number 3 value for - vector vector - -``` - -az áttekinthetőség érdekében sorokra osztva: - -``` -[ - 37, 0, 0, 0, # little-endian encoding of `number1`. - 55, 0, 0, 0, # little-endian encoding of `number2`. - 16, 0, 0, 0, # The "offset" that indicates where the value of `vector` starts (little-endian 16). - 22, 0, 0, 0, # little-endian encoding of `number3`. - 1, 2, 3, 4, # The actual values in `vector`. -] -``` - -Ez még mindig egyszerűsítés – a fenti ábrákon szereplő egész számok és nullák valójában bájtlistákként lennének tárolva, például így: - -``` -[ - 10100101000000000000000000000000 # little-endian encoding of `number1` - 10110111000000000000000000000000 # little-endian encoding of `number2`. - 10010000000000000000000000000000 # The "offset" that indicates where the value of `vector` starts (little-endian 16). - 10010110000000000000000000000000 # little-endian encoding of `number3`. - 10000001100000101000001110000100 # The actual value of the `bytes` field. -] -``` - -Így a változó hosszúságú típusok tényleges értékei egy halomban tárolódnak a sorosított objektum végén, a mezők rendezett listájában a megfelelő pozíciókban tárolt eltolási értékeikkel együtt. - -A speciális esetek különleges kezelést igényelnek, mint például a `BitList` típus, amelyhez a sorosítás során hosszkorlátot kell hozzáadni, majd a deszerializáció során eltávolítani azt. További részletek az [SSZ specifikációban](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) találhatók. - -### Deszerializáció {#deserialization} - -Az objektum deszerializációjához szükség van a sémára. A séma meghatározza a sorosított adatok pontos elrendezését, hogy minden egyes elemet egy bájtblob-ból valamilyen értelmes objektummá lehessen deszerializálni, amelynek elemei a megfelelő típusúak, értékűek, méretűek és pozíciójúak. A séma az, amely megmondja a deszerializátornak, hogy mely értékek ténylegesek, és melyek az eltolási értékek. Az objektum sorosításakor minden mezőnév eltűnik, de a séma szerinti deszerializáláskor újra létrejön. - -Tekintse meg az [ssz.dev](https://www.ssz.dev/overview) oldalt egy interaktív magyarázatért. - -## Merkle-szerűsítés {#merkleization} - -Ez az SSZ sorosított objektum ezután Merkle-szerűsíthető, azaz átalakítható ugyanazon adatok Merkle-fa reprezentációjává. Először meg kell határozni a 32 bájtos darabok számát a sorosított objektumban. Ezek a fa levelei. A levelek teljes számának 2 hatványának kell lennie, hogy a levelek összevonása végül egyetlen hashfagyökeret eredményezzen. Ha ez magától nem így van, akkor további 32 bájtnyi nullát tartalmazó levelek kerülnek hozzáadásra. Ezt így ábrázolhatjuk: - -``` - hash tree root - / \ - / \ - / \ - / \ - hash of leaves hash of leaves - 1 and 2 3 and 4 - / \ / \ - / \ / \ - / \ / \ - leaf1 leaf2 leaf3 leaf4 -``` - -Vannak olyan esetek is, amikor a fa levelei nem egyenletesen oszlanak el, ahogy azt a fenti példa mutatja. A 4. levél például egy több elemet tartalmazó konténer lehet, amely további „mélységet” igényel a Merkle-fához, ami egy egyenetlen fát hoz létre. - -Ahelyett, hogy ezeket a faelemeket X. levélnek, X. csomópontnak stb. neveznénk, általános indexeket adhatunk nekik, kezdve a gyökérrel = 1 és balról jobbra számozva minden szinten. Ez a fentebb ismertetett általánosított index. A sorosított lista minden egyes elemének általános indexe `2**depth + idx`, ahol idx a nullával indexelt pozíciója a sorosított objektumban, a mélység (depth) pedig a Merkle-fa szintjeinek száma, amely az elemek (levelek) számának kettes bázisú logaritmusaként határozható meg. - -## Általánosított indexek {#generalized-indices} - -Az általánosított index egy egész szám, amely egy csomópontot jelöl egy bináris Merkle-fában, ahol minden csomópontnak van egy általánosított indexe `2 ** depth + index in row`. - -``` - 1 --depth = 0 2**0 + 0 = 1 - 2 3 --depth = 1 2**1 + 0 = 2, 2**1+1 = 3 - 4 5 6 7 --depth = 2 2**2 + 0 = 4, 2**2 + 1 = 5... - -``` - -Ez az ábrázolás a Merkle-fa minden egyes adatához egy csomópontindexet ad. - -## Többszörös bizonyítékok {#multiproofs} - -Az általánosított indexek listájának megadása, mely egy adott elemet reprezentál, lehetővé teszi, hogy ellenőrizzük azt a hashfa gyökerével szemben. Ez a gyökér az általunk elfogadott valóság. Bármelyik adatot ellenőrizhetjük ezzel a valósággal szemben, ha beillesztjük a Merkle-fa megfelelő helyére (amelyet az általánosított indexe határoz meg), és megfigyeljük, hogy a gyökér állandó marad-e. A [specifikációban](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) vannak olyan függvények, amelyek megmutatják, hogyan lehet kiszámítani a csomópontok minimális halmazát, amely egy adott általános indexkészlet tartalmának ellenőrzéséhez kell. - -Például az alábbi fa 9-es indexében lévő adatok ellenőrzéséhez szükségünk van a 8, 9, 5, 3, 1 indexben lévő adatok hashére. A (8,9) hashnek meg kell egyeznie a (4) hashsel, amely az 5-tel hashelve a 2-t adja, amely a 3-mal hashelve az 1-es fa gyökerét adja. Ha a 9-hez helytelen adatokat adnánk meg, a gyökér megváltozna – ezt észlelnénk, és nem tudnánk ellenőrizni az ágat. - -``` -* = data required to generate proof - - 1* - 2 3* - 4 5* 6 7 -8* 9* 10 11 12 13 14 15 - -``` - -## További olvasnivaló {#further-reading} - -- [Az Ethereum frissítése: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) -- [Az Ethereum frissítése: Merkle-szerűsítés](https://eth2book.info/altair/part2/building_blocks/merkleization) -- [SSZ implementációk](https://github.com/ethereum/consensus-specs/issues/2138) -- [SSZ kalkulátor](https://simpleserialize.com/) -- [SSZ.dev](https://www.ssz.dev/) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md deleted file mode 100644 index 0c5dca6215b..00000000000 --- a/public/content/translations/hu/25) Research Documentation/developers/docs/data-structures-and-encoding/web3-secret-storage-definition/index.md +++ /dev/null @@ -1,189 +0,0 @@ ---- -title: Web3 titkos tárhely meghatározása -description: A web3 titkos tárolás hivatalos definíciója -lang: hu -sidebarDepth: 2 ---- - -Ahhoz, hogy az Ön alkalmazása az Ethereumon működjön, használhatja a web3 objektumot, amit a web3.js könyvtár biztosít. A háttérben RPC híváson keresztül egy helyi csomóponttal kommunikál. A [web3](https://github.com/ethereum/web3.js/) bármelyik Ethereum csomóponttal működőképes, mely nyilvánossá tesz egy RPC réteget. - -A `web3` az `eth` objektumot tartalmazza: web3.eth. - -```js -var fs = require("fs") -var recognizer = require("ethereum-keyfile-recognizer") - -fs.readFile("keyfile.json", (err, data) => { - var json = JSON.parse(data) - var result = recognizer(json) -}) - -/** result - * [ 'web3', 3 ] web3 (v3) keyfile - * [ 'ethersale', undefined ] Ethersale keyfile - * null invalid keyfile - */ -``` - -Ez a dokumentum a web3 titkos tárolási definíciójának **3. verzióját** dokumentálja. - -## Definíció {#definition} - -A fájl tényleges kódolása és dekódolása nagyrészt változatlan marad az 1. verzióhoz képest, kivéve, hogy a titkosítási algoritmus már nem AES-128-CBC-hez van kötve (az AES-128-CTR a minimális követelmény). A legtöbb jelentés és algoritmus hasonló az 1. verzióhoz, kivéve a `mac`, amely a származtatott kulcs bal szélső második 16 bájtjának és a teljes `ciphertextnek` a SHA3 (keccak-256) kombinációjaként van megadva. - -A titkos kulcsfájlok közvetlenül a `~/.web3/keystore` (Unix-szerű rendszerekre) és a `~/AppData/Web3/keystore` (Windows esetén) mappákban vannak tárolva. A nevük bármi lehet, de egy jó elnevezési logika a `.json`, ahol `` a titkos kulcshoz adott 128 bites UUID (a titkos kulcs címének adatvédelmet biztosító proxy). - -Minden ilyen fájlhoz tartozik egy jelszó. Egy adott `.json` fájl titkos kulcsának létrehozásához először a fájl titkosítási kulcsát kell létrehozni; ez úgy történik, hogy a fájl jelszavát fogjuk és átadjuk a `kdf` kulcs által megadott kulcskészítő függvénynek. A KDF-től függő statikus és dinamikus paraméterek a `kdfparams` kulcsban vannak leírva. - -A PBKDF2-t minden minimálisan megfelelő implementációnak támogatnia kell az alábbi módon: - -- `kdf`: `pbkdf2` - -A PBKDF2-höz a kdfparams tartalmazza: - -- `prf`: `hmac-sha256` kell legyen (talán a jövőben ki lesz terjesztve); -- `c`: iterációk száma; -- `salt`: a PBKDF-nek átadott salt; -- `dklen`: a létrehozott kulcs hossza. Muszáj, hogy >= 32 legyen. - -Miután a fájl kulcsát létrehoztuk, azt a MAC származtatásával kell ellenőrizni. A MAC-et a származtatott kulcs bal szélső második 16 bájtjának és a `ciphertext` kulcs tartalmának összekapcsolásából képzett bájttömb SHA3 (keccak-256) hasheként kell kiszámítani: - -```js -KECCAK(DK[16..31] ++ ) -``` - -(ahol a `++` az összeadási művelet) - -Ezt az értéket össze kell hasonlítani a `mac` kulcs tartalmával; ha eltérnek, alternatív jelszót kell kérni (vagy a műveletet törölni). - -A fájl kulcsának ellenőrzése után a titkosított szöveg (a fájlban szereplő `ciphertext` kulcs) visszafejthető a `cipher` kulcs által meghatározott és a `cipherparams` kulcson keresztül paraméterezett szimmetrikus titkosítási algoritmus segítségével. Ha a származtatott kulcs mérete és az algoritmus kulcsmérete nem egyezik, akkor a származtatott kulcs nullával kitöltött, jobb szélső bájtjait kell használni az algoritmus kulcsaként. - -Minden minimálisan megfelelő implementációnak támogatnia kell az AES-128-CTR algoritmust, amelyet a következőkkel jelölnek: - -- `cipher: aes-128-ctr` - -Ez a titkosító a következő paramétereket veszi fel, amelyeket a cipherparams kulcshoz adott kulcsként kell megadni: - -- `iv`: 128 bites inicializálási vektor a titkosításhoz. - -A titkosítás kulcsa a származtatott kulcs bal szélső 16 bájtja, azaz `DK[0..15]` - -A titkos kulcs létrehozása vagy titkosítása lényegében ezen utasítások fordítottja. Győződjön meg arról, hogy a `uuid`, `salt` és `iv` valóban véletlenszerű. - -A `version` mezőn kívül, amelynek a verzió „kemény” azonosítójaként kell működnie, a megvalósítások használhatják a `minorversion` mezőt is a formátum kisebb, nem megszakított változásainak követésére. - -## Tesztvektorok {#test-vectors} - -Részletek: - -- `Address`: `008aeeda4d805471df9b2a5b0f38a0c3bcba786b` -- `ICAP`: `XE542A5PZHH8PYIZUBEJEO0MFWRAPPIL67` -- `UUID`: `3198bc9c-6672-5ab3-d9954942343ae5b6` -- `Password`: `testpassword` -- `Secret`: `7a28b5ba57c53603b0b07b56bba752f7784bf506fa95edc395f5cf6c7514fe9d` - -### PBKDF2-SHA-256 {#PBKDF2-SHA-256} - -A tesztvektor `AES-128-CTR` és `PBKDF2-SHA-256` kódot használ: - -A `~/.web3/keystore/3198bc9c-6672-5ab3-d9954942343ae5b6.json` fájltartalma: - -```json -{ - "crypto": { - "cipher": "aes-128-ctr", - "cipherparams": { - "iv": "6087dab2f9fdbbfaddc31a909735c1e6" - }, - "ciphertext": "5318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46", - "kdf": "pbkdf2", - "kdfparams": { - "c": 262144, - "dklen": 32, - "prf": "hmac-sha256", - "salt": "ae3cd4e7013836a3df6bd7241b12db061dbe2c6785853cce422d148a624ce0bd" - }, - "mac": "517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2" - }, - "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", - "version": 3 -} -``` - -**Köztes értékek**: - -`Derived key`: `f06d69cdc7da0faffb1008270bca38f5e31891a3a773950e6d0fea48a7188551` `MAC Body`: `e31891a3a773950e6d0fea48a71885515318b4d5bcd28de64ee5559e671353e16f075ecae9f99c7a79a38af5f869aa46` `MAC`: `517ead924a9d0dc3124507e3393d175ce3ff7c1e96529c6c555ce9e51205e9b2` `Cipher key`: `f06d69cdc7da0faffb1008270bca38f5` - -### Scrypt {#scrypt} - -A tesztvektor AES-128-CTR és Scrypt-et használ: - -```json -{ - "crypto": { - "cipher": "aes-128-ctr", - "cipherparams": { - "iv": "740770fce12ce862af21264dab25f1da" - }, - "ciphertext": "dd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2", - "kdf": "scrypt", - "kdfparams": { - "dklen": 32, - "n": 262144, - "p": 1, - "r": 8, - "salt": "25710c2ccd7c610b24d068af83b959b7a0e5f40641f0c82daeb1345766191034" - }, - "mac": "337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c" - }, - "id": "3198bc9c-6672-5ab3-d995-4942343ae5b6", - "version": 3 -} -``` - -**Köztes értékek**: - -`Derived key`: `7446f59ecc301d2d79bc3302650d8a5cedc185ccbb4bf3ca1ebd2c163eaa6c2d` `MAC Body`: `edc185ccbb4bf3ca1ebd2c163eaa6c2ddd8a1132cf57db67c038c6763afe2cbe6ea1949a86abc5843f8ca656ebbb1ea2` `MAC`: `337aeb86505d2d0bb620effe57f18381377d67d76dac1090626aa5cd20886a7c` `Cipher key`: `7446f59ecc301d2d79bc3302650d8a5c` - -## Módosítások az 1. változathoz képest {#alterations-from-v2} - -Ez a verzió számos inkonzisztenciát javított ki az [itt](https://github.com/ethereum/homestead-guide/blob/master/old-docs-for-reference/go-ethereum-wiki.rst/Passphrase-protected-key-store-spec.rst) publikált 1. verzióhoz képest. Ezek röviden: - -- A nagybetűs írásmód indokolatlan és következetlen (scrypt kisbetűs, Kdf vegyes, MAC nagybetűs). -- A cím felesleges és veszélyezteti az adatvédelmet. -- `Salt` eredendően a kulcslétrehozási függvény paramétere, és ahhoz kell hozzárendelni, nem pedig általában a kriptográfiához. -- _SaltLen_ fölösleges (a Salt-ból le lehet vezetni). -- A kulcslétrehozási függvény adott, de a titkosítási algoritmus nehezen meghatározott. -- `Version` eredendően numerikus, mégis egy sztring (a strukturált verziókezelés lehetséges lenne egy sztringgel, de egy ritkán változó konfigurációs fájlformátum esetében ez nem releváns). -- `KDF` és `cipher` fogalmilag testvérek, mégis másképp szerveződnek. -- `MAC` egy szóköz agnosztikus adatdarabon keresztül kerül kiszámításra(!) - -A formátumot úgy változtattuk meg, hogy a következő fájlt kapjuk, amely funkcionálisan megegyezik a korábban hivatkozott oldal példájával: - -```json -{ - "crypto": { - "cipher": "aes-128-cbc", - "ciphertext": "07533e172414bfa50e99dba4a0ce603f654ebfa1ff46277c3e0c577fdc87f6bb4e4fe16c5a94ce6ce14cfa069821ef9b", - "cipherparams": { - "iv": "16d67ba0ce5a339ff2f07951253e6ba8" - }, - "kdf": "scrypt", - "kdfparams": { - "dklen": 32, - "n": 262144, - "p": 1, - "r": 8, - "salt": "06870e5e6a24e183a5c807bd1c43afd86d573f7db303ff4853d135cd0fd3fe91" - }, - "mac": "8ccded24da2e99a11d48cda146f9cc8213eb423e2ea0d8427f41c3be414424dd", - "version": 1 - }, - "id": "0498f19a-59db-4d54-ac95-33901b4f1870", - "version": 2 -} -``` - -## Módosítások az 2. változathoz képest {#alterations-from-v2} - -A 2. verzió egy korai C++ implementáció volt számos hibával. Minden lényeges dolog változatlan maradt. diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/index.md deleted file mode 100644 index 25cdf44a6cc..00000000000 --- a/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/index.md +++ /dev/null @@ -1,155 +0,0 @@ ---- -title: Hálózati réteg -description: Bevezetés az Ethereum hálózati rétegébe. -lang: hu -sidebarDepth: 2 ---- - -Az Ethereum egy peer-to-peer hálózat több ezer csomóponttal, amelyeknek szabványosított protokollokkal kommunikálnak egymással. A hálózati réteg azon protokollok halmaza, amelyek lehetővé teszik, hogy ezek a csomópontok megtalálják egymást és információt cseréljenek. Ez magában foglalja az információk pletykálását (egy a sokhoz kommunikáció) a hálózaton keresztül, valamint a kérések és válaszok cseréjét bizonyos csomópontok között (egy az egyhez kommunikáció). Minden csomópontnak be kell tartania bizonyos hálózati szabályokat, hogy biztosítsa a megfelelő információk küldését és fogadását. - -A kliensszoftver két részből áll (végrehajtási és konszenzusos kliensek), mindegyiknek különálló hálózati stackje van. A többi Ethereum-csomóponttal való kommunikáció mellett a végrehajtási és konszenzusos klienseknek egymással is kommunikálniuk kell. Ez az oldal magyarázatot ad a kommunikációs protokollokról. - -A végrehajtási kliensek tranzakciókat pletykálnak a végrehajtási réteg peer-to-peer hálózatán. Ehhez titkosított kommunikáció szükséges a hitelesített társak között. Amikor egy validátort kiválasztanak blokkelőterjesztésre, a csomópont helyi tranzakciógyűjtőjéből tranzakciókat ad át a konszenzusos kliensnek egy helyi RPC kapcsolaton, melyeket Beacon blokkokba csomagol. A konszenzusos kliensek ezután pletykálnak a Beacon blokkokról a saját p2p hálózatukon. Ehhez két elkülönített p2p hálózat kell: az egyik összeköti a végrehajtási klienseket a tranzakciópletykával, a másik a konszenzusos klienseket a blokkpletykával. - -## Előfeltételek {#prerequisites} - -E téma könnyebb megértéséhez tekintse meg az Ethereum [csomópontok és kliensek](/developers/docs/nodes-and-clients/) témáját. - -## A végrehajtási réteg {#execution-layer} - -A végrehajtási réteg hálózati protokolljai két részre oszlanak: - -- a felfedező stack: az UDP portra épül, és lehetővé teszi, hogy egy új csomópont megtalálja a társait, amelyekhez csatlakozhat - -- a DevP2P stack: a TCP port tetején helyezkedik el, és lehetővé teszi a csomópontok számára az információcserét - -A stackek párhuzamosan működnek. A felfedező stack új résztvevőket hoz a hálózatba, a DevP2P pedig lehetővé teszi ezek interakcióit. - -### Felfedezés {#discovery} - -A felfedezés a hálózatban lévő más csomópontok megtalálásának folyamata. Ez egy kis számú beöltő csomópont (bootnode) segítségével történik (amelyek címe [be van kódolva](https://github.com/ethereum/go-ethereum/blob/master/params/bootnodes.go) a kliensbe, hogy azonnal megtalálhatók legyenek, és összekapcsolják a klienst a társaival). Ezek a betöltő csomópontok azért léteznek, hogy egy új csomópontot bemutassanak a társaiknak – nincs más céljuk, nem vesznek részt a normál kliensfeladatokban, például a lánc szinkronizálásában, és csak a kliens legelső indításakor használják őket. - -A betöltőcsomópont-csomópont interakció protokollja a [Kademlia](https://medium.com/coinmonks/a-brief-overview-of-kademlia-and-its-use-in-various-decentralized-platforms-da08a7f72b8f) egy módosított formája, amely egy [elosztott hash táblát](https://en.wikipedia.org/wiki/Distributed_hash_table) használ a csomópontlista megosztására. Minden csomópont rendelkezik ezzel a táblával, hogy a szükséges információk birtokában legyen, amikor a legközelebbi társaihoz csatlakozik. A közelség nem földrajzi, hanem a csomópont azonosítójának hasonlósága határozza meg. A csomópontoknál lévő táblázat biztonsági okokból rendszeresen frissül. Például a [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) felfedezőprotokoll csomópontjai képesek „hirdetéseket” is küldeni, amelyek megjelenítik a kliens által támogatott alprotokollokat, lehetővé téve a társak számára, hogy tárgyaljanak a protokollokról, amelyeken keresztül mindketten kommunikálni tudnak. - -A felfedezés egy ping-pong-játékkal kezdődik. A sikeres ping-pong egy betöltő csomóponthoz „köti” az új csomópontot. A kezdeti üzenet, amely a betöltő csomópontot figyelmezteti a hálózatba belépő új csomópont létezésére, egy `PING`. Ez a `PING` hashelt információkat tartalmaz az új csomópontra, a betöltő csomópontra és a lejárati időre vonatkozóan. A betöltő csomópont fogadja a `PING`-et, és visszaküld egy `PONG`-ot, amely tartalmazza a `PING` hasht. Ha a `PING` és `PONG` hashek egyeznek, akkor az új csomópont és a betöltő csomópont közötti kapcsolat le van ellenőrizve, és „összekapcsolódtak”. - -Miután összekapcsolódott, az új csomópont küldhet egy `FIND-NEIGHBOURS` kérést a betöltő csomópontnak. A betöltő csomópont által visszaküldött adatok tartalmazzák azoknak a partnereknek a listáját, amelyekhez az új csomópont csatlakozhat. Ha a csomópontok nincsenek összekötve, a `FIND-NEIGHBOURS` kérés sikertelen lesz, így az új csomópont nem tud belépni a hálózatba. - -Amint az új csomópont megkapja a betöltő csomóponttól a szomszédok listáját, mindegyikükkel PING-PONG cserét kezd. A sikeres PING-PONG-ok összekötik az új csomópontot a szomszédjaival, lehetővé téve az üzenetváltást. - -``` -start client --> connect to bootnode --> bond to bootnode --> find neighbours --> bond to neighbours -``` - -A végrehajtási kliensek jelenleg a [Discv4](https://github.com/ethereum/devp2p/blob/master/discv4.md) felfedezőprotokollt használják, és aktív erőfeszítéseket tesznek a [Discv5](https://github.com/ethereum/devp2p/tree/master/discv5) protokollra való áttérésre. - -#### ENR: Ethereum csomópontfeljegyzés {#enr} - -A [Ethereum csomópontrekord (ENR)](/developers/docs/networking-layer/network-addresses/) egy objektum, amely három alapvető elemet tartalmaz: egy aláírást (a rekord tartalmának egy elfogadott azonosítási séma szerinti hashe), egy sorszámot, amely a rekord változását követi, és kulcs-érték párok tetszőleges listáját. Ez egy jövőbiztos formátum, amellyel az azonosító adatok könnyebben cserélhetők az új társak között, valamint ez az Ethereum-csomópontok preferált [hálózati cím](/developers/docs/networking-layer/network-addresses) formátuma. - -#### Miért épül a felfedezés az UDP-re? {#why-udp} - -Az UDP nem támogatja a hibaellenőrzést, a sikertelen csomagok újraküldését vagy a kapcsolatok dinamikus megnyitását és lezárását – ehelyett egy folyamatos információáramlást küld a célpontnak, függetlenül attól, hogy sikeresen fogadja-e azt. Ez a minimális funkcionalitás minimális költséget is jelent, így ez a kapcsolat nagyon gyors. A felfedezéshez, amikor egy csomópont egyszerűen csak jelezni akarja jelenlétét, hogy aztán hivatalos kapcsolatot létesítsen egy társsal, elegendő az UDP. A hálózati stack többi része számára azonban az UDP nem felel meg a célnak. A csomópontok közötti információcsere meglehetősen összetett, ezért egy teljesebb funkciójú protokollra van szükség, amely támogatja az újraküldést, a hibaellenőrzést stb. A TCP-hez kapcsolódó többletköltség megéri a többletfunkciókat. Ezért a P2P stack nagy része TCP-n keresztül működik. - -### DevP2P {#devp2p} - -A DevP2P a protokollok egész halmaza, amelyet az Ethereum a peer-to-peer hálózat létrehozásához és fenntartásához implementál. Miután az új csomópontok belépnek a hálózatba, interakcióikat a [DevP2P](https://github.com/ethereum/devp2p) stack protokolljai szabályozzák. Ezek mind a TCP-re épülnek, és magukban foglalják az RLPx transzport protokollt, a vezetékes protokollt és számos alprotokollt. [RLPx](https://github.com/ethereum/devp2p/blob/master/rlpx.md) a csomópontok közötti munkamenetek kezdeményezését, hitelesítését és fenntartását szabályozó protokoll. Az RLPx az RLP (Rekurzív hosszúságú prefixum) segítségével kódolja az üzeneteket, ami egy helytakarékos módszer az adatok minimális struktúrába történő kódolására, hogy azokat a csomópontok közötti küldhessék. - -A két csomópont közötti RLPx kapcsolódás egy kezdeti kriptográfiai kézfogással kezdődik. Ennek során a csomópont hitelesítő üzenetet küld, amelyet a társ ellenőriz. Sikeres ellenőrzés esetén a társ egy hitelesítést igazoló üzenetet generál, amelyet visszaküld a kezdeményezőnek. Ez egy kulcscserélési folyamat, amely lehetővé teszi a csomópontok számára a privát és biztonságos kommunikációt. A sikeres kriptográfiai kézfogás után mindkét csomópont „hello” üzenetet küld egymásnak „a vezetéken”. A vezetékes protokollt a hello üzenetek sikeres cseréje indítja el. - -A helló üzenetek a következőt tartalmazzák: - -- protokoll verziója -- kliensazonosító -- port -- csomópont-azonosító -- a támogatott alprotokollok listája - -Ez a sikeres interakcióhoz szükséges információ, mivel meghatározza, hogy a két csomópont milyen képességeket oszt meg egymással, és konfigurálja a kommunikációt. Létezik egy alprotokoll-tárgyalási folyamat, amelynek során az egyes csomópontok által támogatott alprotokollok listáját összehasonlítják, és a két csomópont számára közös alprotokollok használhatók a kapcsolódásban. - -A hello üzenetek mellett a vezetékes protokoll „szétkapcsolási” üzenetet is küldhet, amely figyelmeztetést ad a társnak, hogy a kapcsolat lezárul. A vezetékes protokoll PING és PONG üzeneteket is tartalmaz, amelyeket időszakosan küld a munkamenet nyitva tartása érdekében. Az RLPx és a vezetékes protokollok cseréje tehát megteremti a csomópontok közötti kommunikáció alapjait, és biztosítja a hasznos információk cseréjének keretét egy adott alprotokoll szerint. - -### Alprotokollok {#sub-protocols} - -#### Vezetékes protokoll {#wire-protocol} - -Miután a partnerek csatlakoztak, és az RLPx kapcsolódás elindult, a vezetékes protokoll határozza meg, hogy a partnerek hogyan kommunikálnak egymással. Kezdetben a vezetékes protokoll három fő feladatot határozott meg: a láncszinkronizációt, a blokkelőterjesztést és a tranzakciók cseréjét. Miután azonban az Ethereum átállt a proof-of-stake-re, a blokkelőterjesztés és a láncszinkronizáció a konszenzusréteg részévé vált. A tranzakciók cseréje továbbra is a végrehajtási kliensek hatáskörébe tartozik. A tranzakciók cseréje a függőben lévő tranzakciók csomópontok közötti cseréjére utal, hogy a blokképítők kiválaszthassanak közülük néhányat a következő blokkba. Bővebb információk [itt](https://github.com/ethereum/devp2p/blob/master/caps/eth.md) érhetők el ezekről a feladatokról. Az ezeket az alprotokollokat támogató kliensek a [JSON-RPC](/developers/docs/apis/json-rpc/) segítségével teszik közzé azokat. - -#### Les (könnyű Ethereum alprotokoll) {#les} - -Ez egy minimális protokoll a könnyű kliensek szinkronizálásához. Ezt a protokollt ritkán használják, mivel a teljes csomópontoknak ösztönzés nélkül kell adatokat szolgáltatniuk a könnyű klienseknek. A végrehajtási kliensek alapértelmezett viselkedése az, hogy nem szolgálják ki a könnyű klienseket a Les-en keresztül. Bővebb információ található a Les [specifikációban](https://github.com/ethereum/devp2p/blob/master/caps/les.md). - -#### Snap {#snap} - -A [snap protokoll](https://github.com/ethereum/devp2p/blob/master/caps/snap.md#ethereum-snapshot-protocol-snap) egy opcionális kiterjesztés, amely lehetővé teszi, hogy a társak pillanatfelvételeket cseréljenek a legutóbbi státuszokról, így anélkül ellenőrizhetik a számla- és tárolási adatokat, hogy közbenső Merkle-fa csomópontokat kellene letölteniük. - -#### Wit (tanúprotokoll) {#wit} - -A [tanúprotokoll](https://github.com/ethereum/devp2p/blob/master/caps/wit.md#ethereum-witness-protocol-wit) egy opcionális kiterjesztés, amely lehetővé teszi a státusztanúk cseréjét a társak között, hogy a kliensek szinkronizálva legyenek a lánc elejéhez. - -#### Whisper {#whisper} - -A Whisper egy olyan protokoll, amelynek célja a biztonságos üzenetváltás biztosítsa a társak között anélkül, hogy bármilyen információt írna a blokkláncra. A DevP2P vezetékes protokoll része volt, de már elavult. Más [kapcsolódó projektek](https://wakunetwork.com/) is léteznek hasonló célokkal. - -## A konszenzusréteg {#consensus-layer} - -A konszenzusos kliensek egy különálló, eltérő specifikációjú peer-to-peer hálózatban vesznek részt. A konszenzusos kliensek részt kell venniük a blokkpletykában, hogy új blokkokat kaphassanak a társaiktól, és továbbíthassák azokat, amikor rájuk kerül a sor, hogy blokkot javasoljanak. A végrehajtási réteghez hasonlóan ehhez is először egy felfedező protokollra van szükség, hogy a csomópont megtalálja a társait, és biztonságos kapcsolódásokat hozzon létre a blokkok, igazolások stb. cseréjéhez. - -### Felfedezés {#consensus-discovery} - -A végrehajtási kliensekhez hasonlóan a konszenzusos kliensek is [discv5](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-discovery-domain-discv5)-öt használnak UDP-n keresztül a társak megkereséséhez. A discv5 konszenzusréteg implementációja csak annyiban különbözik a végrehajtási kliensekétől, hogy tartalmaz egy illesztőt, amely a discv5-öt egy [libP2P](https://libp2p.io/) stackbe kapcsolja, elavulttá téve ezzel a DevP2P-t. A végrehajtási réteg RLPx kapcsolódásait elhagyták a libP2P zajmentes csatornáján való kézfogásért. - -### ENR-ek {#consensus-enr} - -A konszenzus csomópontok ENR-je tartalmazza a csomópont nyilvános kulcsát, IP-címét, UDP- és TCP-portjait, valamint két konszenzusspecifikus mezőt: a tanúsítást végző alhálózat bitmezőjét és az `eth2` kulcsot. Az előbbi megkönnyíti a csomópontok számára, hogy megtalálják az adott tanúsítási pletyka alhálózatokban részt vevő társaikat. Az `eth2` kulcs információt tartalmaz arról, hogy a csomópont melyik Ethereum elágazási (fork) verziót használja, így biztosítva, hogy a társak a megfelelő Ethereumhoz kapcsolódjanak. - -### libP2P {#libp2p} - -A libP2P stack a felfedezés után minden kommunikációt támogat. A kliensek tárcsázhatnak és hallgathatják az IPv4 és/vagy IPv6 protokollt az ENR-ben meghatározottak szerint. A libP2P réteg protokolljai feloszthatók a pletyka és a kérés/válasz (req/resp) domainekre. - -### Pletyka {#gossip} - -A pletyka domainbe tartozik minden információ, amelynek gyorsan kell terjednie a hálózaton. Ezek a Beacon-blokkok, bizonyítékok, tanúsítások, kilépések és kizárások. Ezt a libP2P gossipsub v1 segítségével továbbítják, ami a csomópontokon helyileg tárolt metaadatokra támaszkodik, beleértve a fogadható és továbbítandó pletykacsomagok maximális méretét. A pletyka domain további információt megtalálja [itt](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#the-gossip-domain-gossipsub). - -### Kérés-válasz {#request-response} - -A kérés-válasz domain olyan protokollokat tartalmaz, amelyekkel a kliensek konkrét információkat kérhetnek a társaiktól. Például bizonyos Beacon blokkok lekérése, melyek bizonyos gyökérhasheknek megfelelnek vagy egy slottartományba esnek. A válaszok mindig snappy-tömörített SSZ-kódolt bájtként érkeznek vissza. - -## Miért részesíti előnyben a konszenzusos kliens az SSZ-t az RLP-vel szemben? {#ssz-vs-rlp} - -Az SSZ jelentése egyszerű sorosítás. Fix offszeteket használ, amelyek megkönnyítik a kódolt üzenet egyes részeinek dekódolását anélkül, hogy a teljes struktúrát dekódolni kellene, ami hasznos a konszenzusos kliens számára, mivel hatékonyan ki tudja venni a kódolt üzenetekből az információrészeket. Kifejezetten a Merkle protokollokkal való integrációra is tervezték, ami a Merkle-szerűsítés hatékonyságának növelésével jár. Mivel a konszenzusrétegben minden hash Merkle-gyök, ez jelentős javulást jelent. Az SSZ garantálja az értékek egyedi ábrázolását is. - -## A végrehajtási és konszenzusos kliensek kapcsolódása {#connecting-clients} - -A konszenzusos és végrehajtási kliensek párhuzamosan futnak. Össze kell kapcsolódniuk, hogy a konszenzusos kliens utasításokat adhasson a végrehajtási kliensnek, a végrehajtási kliens pedig tranzakciókötegeket adhasson át a konszenzusos kliensnek, hogy azok bekerülhessenek a Beacon blokkokba. A két kliens közötti kommunikáció helyi RPC-kapcsolat segítségével valósítható meg. Egy [Engine-API](https://github.com/ethereum/execution-apis/blob/main/src/engine/common.md) néven ismert API határozza meg a két kliens között küldött utasításokat. Mivel mindkét kliens egyetlen hálózati identitás mögött helyezkedik el, megosztanak egy ENR-t (Ethereum csomópontfeljegyzés), amely mindkét kliens számára külön kulcsot tartalmaz (eth1 és eth2 kulcs). - -A kontrollfolyamat összefoglalása az alábbiakban látható, zárójelben a vonatkozó hálózati stackkel. - -### Amikor a konszenzusos kliens nem terjeszt elő blokkot: {#when-consensus-client-is-not-block-producer} - -- A konszenzusos kliens blokkot kap a blokkpletyka-protokollon keresztül (konszenzus p2p) -- A konszenzusos kliens előzetesen validálja a blokkot, azaz biztosítja, hogy az érvényes feladótól érkezett, helyes metaadatokkal -- A blokkban lévő tranzakciókat a végrehajtási rétegnek küldik el végrehajtási csomagként (helyi RPC-kapcsolat) -- A végrehajtási réteg végrehajtja a tranzakciókat és ellenőrzi a blokkfejlécben lévő státuszt (azaz a hashek egyezését) -- A végrehajtási réteg visszaadja a validációs adatokat a konszenzus rétegnek, a blokk validáltnak tekinthető (helyi RPC kapcsolat) -- A konszenzus réteg hozzáadja a blokkot a saját blokkláncának fejéhez és tanúsítja azt, a tanúsítást a hálózaton keresztül küldi szét (konszenzus p2p) - -### Amikor a konszenzusos kliens blokkot terjeszt elő: {#when-consensus-client-is-block-producer} - -- A konszenzusos kliens értesítést kap arról, hogy ő a következő blokkelőterjesztő (konszenzus p2p) -- A konszenzusréteg meghívja a `blokk létrehozása` metódust a végrehajtási kliensben (helyi RPC) -- A végrehajtási réteg hozzáfér a tranzakciós memóriakészlethez, amelyet a tranzakciós pletykaprotokoll töltött fel (végrehajtási p2p) -- A végrehajtási kliens a tranzakciókat egy blokkba foglalja, végrehajtja a tranzakciókat és létrehoz egy blokk hasht -- A konszenzusos kliens átveszi a tranzakciókat és a blokk hasht a végrehajtási klienstől, és hozzáadja azokat a Beacon-blokkhoz (helyi RPC) -- A konszenzusos kliens a blokkot a blokkpletyka-protokollon keresztül továbbítja (konszenzus p2p) -- A többi kliens megkapja a javasolt blokkot a blokkpletyka-protokollon keresztül, és a fent leírtak szerint validálja (konszenzus p2p) - -Amint a blokkot elegendő validátor tanúsította, a lánc fejéhez adják, igazolják és végül véglegesítik. - -![](cons_client_net_layer.png) ![](exe_client_net_layer.png) - -A hálózati réteg sémája a konszenzus- és végrehajtási kliensek számára, az [ethresear.ch](https://ethresear.ch/t/eth1-eth2-client-relationship/7248) honlapról - -## További olvasnivaló {#further-reading} - -[DevP2P](https://github.com/ethereum/devp2p) [LibP2p](https://github.com/libp2p/specs) [Konszenzusréteg hálózati specifikáció](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) [Kademlia to discv5](https://vac.dev/kademlia-to-discv5) [Kademlia leírás](https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf) [Bevezetés az Ethereum p2p-be](https://p2p.paris/en/talks/intro-ethereum-networking/) [Eth1 és eth2 kapcsolata](http://ethresear.ch/t/eth1-eth2-client-relationship/7248) [A Beolvadásról és eth2 kliensrészletekről szóló videó](https://www.youtube.com/watch?v=zNIrIninMgg) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md deleted file mode 100644 index 79417cf574c..00000000000 --- a/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/network-addresses/index.md +++ /dev/null @@ -1,38 +0,0 @@ ---- -title: Hálózati címek -description: Bevezetés a hálózati címekbe. -lang: hu -sidebarDepth: 2 ---- - -Az Ethereum csomópontoknak azonosítaniuk kell magukat néhány alapvető információval, hogy a társaikhoz tudjanak kapcsolódni. Annak érdekében, hogy a lehetséges társak értelmezni tudják ezeket az információkat, három szabványosított formátumban továbbítják, amelyeket bármely Ethereum-csomópont megérthet: multiaddr, enode vagy Ethereum Node Records (ENRs). Az ENRs az Ethereum hálózati címek jelenlegi szabványa. - -## Előfeltételek {#prerequisites} - -A jelen téma könnyebb megértéséhez érdemes megtekinteni az Ethereum [hálózati rétegéről](/developers/docs/networking-layer/) szóló oldalt. - -## Multiaddr {#multiaddr} - -Az eredeti Ethereum csomópontcím formátuma a multiaddr (a multi-addresses rövidítése) volt. A multiaddr egy egyetemes formátum a peer-to-peer hálózatokhoz. A címek kulcs-érték párokként jelennek meg, a kulcsok és az értékek perjellel vannak elválasztva. Például a multiaddr értéke a `192.168.22.27` IPv4-címmel rendelkező csomópontnak, ami a `33000` TCP-portot figyeli: - -`/ip4/192.168.22.27/tcp/33000` - -Az Ethereum csomópont esetében a multiaddr tartalmazza a csomópont-azonosítót (a nyilvános kulcs hashe): - -`/ip4/192.168.22.27/tcp/33000/p2p/5t7Nv7dG2d6ffbvAiewVsEwWweU3LdebSqX2y1bPrW8br` - -## Enode {#enode} - -Az enode az Ethereum-csomópontok azonosítására szolgál egy URL-címformátum segítségével. A hexadecimális csomópont-ID az URL felhasználónevet tartalmazó részében van kódolva, a hoszttól @ jellel elválasztva. A hosztnév csak IP-címként adható meg; DNS nevek nem engedélyezettek. A hosztnév szakaszban szereplő port a TCP figyelő port. Ha a TCP és UDP (felfedező) portok különböznek, az UDP portot a „discport” lekérdezési paraméterként kell megadni - -A következő példában a csomópont URL-címe egy olyan csomópontot ír le, amelynek IP-címe `10.3.58.6`, TCP-portja `30303` és UDP felfedezőportja `30301`. - -`enode://6f8a80d14311c39f35f516fa664deaaaa13e85b2f7493f37f6144d86991ec012937307647bd3b9a82abe2974e1407241d54947bbb39763a4cac9f77166ad92a0@10.3.58.6:30303?discport=30301` - -## Ethereum Node Records (ENRs) {#enr} - -Az Ethereum Node Records (ENR) a hálózati címek szabványosított formátuma az Ethereumon. Ez váltotta fel a multiaddr és az enode használatát. Ezek különösen hasznosak, mert nagyobb információcserét tesznek lehetővé a csomópontok között. Az ENR tartalmaz egy aláírást, egy sorszámot és olyan mezőket, melyek az aláírások létrehozására és érvényesítésére használt azonosítási rendszert részletezik. Az ENR tetszőleges, kulcs-érték párokba rendezett adatokkal is feltölthető. Ezek a kulcs-érték párok tartalmazzák a csomópont IP-címét és a csomópont által használható alprotokollokra vonatkozó információkat. A konszenzus kliensek egy [specifikus ENR struktúrát](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/p2p-interface.md#enr-structure) használnak a betöltőcsomópontok (bootnode) azonosítására, és tartalmaznak egy `eth2` mezőt is, amely az aktuális Ethereum elágazásról és a tanúsításpletyka alhálózatról tartalmaz információt (ez köti a csomópontot a társak egy adott csoportjához, akiknek tanúsításait aggregálják). - -## További olvasnivaló {#further-reading} - -[EIP-778: Ethereum Node Records (ENR)](https://eips.ethereum.org/EIPS/eip-778) [Hálózati címek az Ethereumban](https://dean.eigenmann.me/blog/2020/01/21/network-addresses-in-ethereum/) [LibP2P: Multiaddr-Enode-ENR?!](https://consensys.net/diligence/blog/2020/09/libp2p-multiaddr-enode-enr/) diff --git a/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md b/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md deleted file mode 100644 index ef98d696462..00000000000 --- a/public/content/translations/hu/25) Research Documentation/developers/docs/networking-layer/portal-network/index.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Portal Network -description: Áttekintés a Portal Network-ről, egy fejlesztés alatt álló hálózatról, mely a kevés forrással bíró klienseket támogatja. -lang: hu ---- - -Az Ethereum egy számítógépekből álló hálózat, melyek az Ethereum kliensszoftvert futtatják. Minden ilyen számítógépet csomópontnak neveznek. A kliensszoftver lehetővé teszi, hogy a csomópont adatot tudjon küldeni és fogadni az Ethereum hálózaton, és hozzá tudja ellenőrizni az adatokat az Ethereum protokollszabályokhoz. A csomópontok rengeteg historikus adatot tárolnak a merevlemezen, és az új információs csomagokat, vagyis blokkokat hozzáadják ezekhez, melyeket a hálózat többi csomópontjától kapnak. Ez azért szükséges, hogy ellenőrizhető legyen, egy csomópont a hálózat többi részével konzisztens információkat tartalmaz. Tehát a csomópontok üzemeltetéséhez sok tárhelyre van szükség. Néhány csomópont működés sok RAM-ot is igényel emellett. - -A tárhely probléma megoldására fejlesztettek könnyű csomópontokat, amelyek nem maguk tárolják az információt, hanem lekérik azt a teljes csomópontoktól. Ez ugyanakkor azt is jelenti, hogy a könnyű csomópont nem független módon ellenőrzi az információt, hanem egy másik csomópontban bízik. Emellett a teljes csomópontoknak egy extra feladatot kell ellátni, amikor kiszolgálják ezeket a könnyű csomópontokat. - -A Portal Network egy új hálózati dizájn az Ethereumon, amely az adatelérhetőségi problémákat hivatott megoldani a könnyű csomópontok esetében anélkül, hogy bízniuk kellene másban vagy a teljes csomópontot terhelnénk vele, és ehhez a szükséges információt kis darabokban osztják meg a hálózaton. - -Bővebben a [csomópontokról és kliensekről](/developers/docs/nodes-and-clients/) - -## Miért van szükség Portal Networkre? {#why-do-we-need-portal-network} - -Az Ethereum csomópontok a saját teljes vagy részleges másolatukat tárolják az Ethereum blokkláncról. Ezt a helyi másolatot használják a tranzakciók validálására, és arra, hogy a csomópont a megfelelő láncot kövesse. Ez a helybeli másolat lehetővé teszi, hogy a csomópontok független módon ellenőrizzék a bejövő adatok érvényességét és helyességét, anélkül hogy egy másik entitásban kellene megbízniuk. - -A blokklánc, a kapcsolódó státusz és a visszaigazolási adatok a csomópont merevlemezén rengeteg helyet foglalnak. Például egy 2 TB merevlemez kell egy olyan csomópont futtatásához, mely [Geth-et](https://geth.ethereum.org) használ egy konszenzusos klienssel párban. A snap-szinkronizálás használatával, amely csak a viszonylag friss blokkok láncadatait tárolja, a Geth kb. 650 GB lemezterületet foglal el, de kb. 14 GB/hét sebességgel növekszik (a csomópontot időszakosan vissza lehet vágni 650 GB-ra). - -Tehát a csomópont futtatása költséges lehet, mert nagy tárhelyet kell dedikálni az Ethereumnak. Az Ethereum ütemterve számos megoldást kínál erre a problémára, beleértve az [előzményadatok lejáratát](/roadmap/statelessness/#history-expiry), [státuszlejáratot](/roadmap/statelessness/#state-expiry) és [státuszmentességet](/roadmap/statelessness/). Ugyanakkor ezek bevezetésére még kell várni néhány évet. Emellett működnek [könnyű csomópontok](/developers/docs/nodes-and-clients/light-clients/), amelyek nem mentenek saját adatot a láncról, hanem a teljes csomópontoktól kérdezik le a szükséges információkat. Ekkor azonban a könnyű csomópontnak meg kell bíznia a teljes csomópontban, hogy korrekt adatot szolgáltat, és még terhet is jelent a teljes csomópontnak. - -A Portal Network célja, hogy alternatív módot biztosítson a könnyű csomópontoknak, hogy hozzájussanak az adatokhoz bizalomigény nélkül, és nem növeli jelentősen a teljes csomópontok által elvégzendő munkát. Ennek módja az Ethereum csomópontok számára, hogy az adatot másképpen kell megosztani a hálózaton. - -## Hogyan működik a Portal Network? {#how-does-portal-network-work} - -Az Ethereum csomópontok szigorú protokollt követnek abban, hogyan kommunikálnak egymással. A végrehajtási kliensek a kommunikációhoz néhány alprotokollt használnak, mint a [DevP2P](/developers/docs/networking-layer/#devp2p), miközben a konszenzusos kliensek egy másik adagot, amit [libP2P](/developers/docs/networking-layer/#libp2p) néven neveznek. Ezek határozzák meg a csomópontok között átadható adattípusokat. - -![devP2P és libP2P](portal-network-devp2p-libp2p.png) - -A csomópontok emellett specifikus adatokat is tudnak adni a [JSON-RPC API](/developers/docs/apis/json-rpc/) révén, amely az a mód, ahogy az alkalmazások és tárcák cserélnek információt az Ethereum csomópontokkal. Ugyanakkor ezek egyike sem az ideális megoldás a könnyű kliensek kiszolgálására. - -A könnyű kliensek nem tudnak adatot szerezni a láncról a DevP2P vagy libP2p protokollok révén, mert ezeket szinkronizálásra és a blokkokról és tranzakciókról szóló pletykákhoz tervezték. A könnyű kliens nem akarja letölteni ezeket az információkat, mert akkor nem lenne könnyű súlyú. - -A JSON-RPC API azért nem jó, mert egy specifikus teljes csomóponton vagy egy közpinti RPC szolgáltatón múlik, hogy adatot adjon. Ekkor a könnyű kliensnek meg kellene bíznia a csomópontban vagy a szolgáltatóban, hogy az jóhiszemű, továbbá a teljes csomópontot is leterheli és nagyobb sávszélesség kell neki, ha egyszerre több könnyű kliens több kéréssel fordul hozzá. - -A Portal Network lényege, hogy újragondolja az egész dizájnt, kifejezetten a könnyedségre építve, a meglévő Ethereum-kliensek tervezési korlátain kívül. - -A Portal Network lényege, hogy a jelenlegi hálózati stack legjobb részeit használja ki azáltal, hogy lehetővé teszi, hogy a könnyű kliensek számára szükséges információkat, például az előzményadatokat és a lánc fejének beazonosítását egy könnyű, DevP2P stílusú peer-to-peer decentralizált hálózaton keresztül szolgáltassák ki, amely egy [DHT-t](https://en.wikipedia.org/wiki/Distributed_hash_table) használ (hasonlóan a Bittorrenthez). - -Az ötlet lényege, hogy minden egyes csomóponthoz hozzáadnák a teljes Ethereum előzményadatainak kis részét és néhány konkrét csomóponti feladatot. Ezután a kéréseket úgy szolgálnák ki, hogy megkeresik az adatokat tároló csomópontot és azoktól lekérdezik azt. - -Ez megfordítja azt a szokásos modellt, amelyben a könnyű csomópontok egyetlen csomópontot találnak, és felkérik őket nagy mennyiségű adat szűrésére és kiszolgálására; ehelyett gyorsan megszűrik a csomópontok nagy hálózatát, amelyek mindegyike kis mennyiségű adatot kezel. - -A cél az, hogy a könnyű súlyú Portal kliensek decentralizált hálózata a következőket tegye: - -- a lánc elejét, vagyis legfrissebb állapotát kövesse -- szinkronizálja a jelenlegi és a historikus láncadatokat -- státuszadatokat szerezzen -- tranzakciókat terjesszen el -- tranzakciókat hajtson végre az [EVM](/developers/docs/evm/) révén - -Ennek a hálózati dizájnnak az előnyei: - -- csökkenti a központi szolgáltatóktól való függést -- csökkenti az internet sávszélességi igényt -- minimális vagy nulla szinkronizálásra van szükség -- A kevés erőforrással bíró eszközök esetében is működőképes (<1 GB RAM, <100 MB merevlemez, 1 CPU) - -Az alábbi ábra a meglévő kliensek azon funkcióit mutatja be, amelyeket a Portal Network biztosíthat, lehetővé téve a felhasználók számára, hogy ezeket a funkciókat nagyon alacsony erőforrásigényű eszközökön is elérjék. - -### A Portal Network hálózatok - -| Beacon könnyű kliens | Státuszhálózat | Tranzakciópletyka | Előzményadatok hálózata | -| -------------------- | -------------------------- | --------------------- | ----------------------- | -| Beacon lánc könnyű | Számla- és szerződéstároló | Könnyű memóriakészlet | Fejlécek | -| Protokolladatok | | | Blokktestek | -| | | | Visszaigazolások | - -## Alapértelmezett kliensdiverzitás {#client-diversity-as-default} - -A Portal Network fejlesztői már eleve három elkülönült klienst építenek az első naptól fogva. - -A Portal Network kliensei a következők: - -- [Trin](https://github.com/ethereum/trin): Rust nyelven írva -- [Fluffy](https://nimbus.team/docs/fluffy.html): Nim nyelven írva -- [Ultralight](https://github.com/ethereumjs/ultralight): Typescript nyelven írva -- [Shisui](https://github.com/optimism-java/shisui): Go nyelven írva - -A több független kliensimplementáció növeli az Ethereum-hálózat rugalmasságát és decentralizációját. - -Ha az egyik kliensnél problémák vagy sebezhetőségek merülnek fel, a többi kliens zavartalanul működhet tovább, megelőzve az egyetlen hibapont kialakulását. Emellett az eltérő klienshasználat elősegíti az innovációt és a versenyt, ösztönzi a fejlesztéseket és csökkenti a monokultúra kockázatát az ökoszisztémán belül. - -## További olvasnivaló {#futher-reading} - -- [A Portal Network (Piper Merriam előadása a Devconon, Bogotában)](https://www.youtube.com/watch?v=0stc9jnQLXA). -- [A Portal Network Discord csatornája](https://discord.gg/CFFnmE7Hbs) -- [A Portal Network honlapja](https://www.ethportal.net/) diff --git a/public/content/translations/hu/26) Miscellaneous/about/index.md b/public/content/translations/hu/26) Miscellaneous/about/index.md deleted file mode 100644 index e4e973e3646..00000000000 --- a/public/content/translations/hu/26) Miscellaneous/about/index.md +++ /dev/null @@ -1,129 +0,0 @@ ---- -title: Rólunk -description: A csapatról, közösségről és az ethereum.org küldetéséről -lang: hu ---- - -# Az ethereum.org-ról {#about-ethereumorg} - -Az ethereum.org egy nyilvános, nyílt forráskódú információs forrás az Ethereum közösségnek, amelyhez bárki hozzájárulhat. Egy kicsi központi csapat elhivatottan dolgozik az oldal fenntartásán és fejlesztésén, és ebben több ezer közösségi tag segíti őket a világ minden tájáról. - -**Az ethereum.org-tól senki sem lép Önnel kapcsolatba. Ne válaszoljon ilyesmire!** - -## Megjegyzés a nevekkel kapcsolatban {#a-note-on-names} - -Általános dolog, hogy az emberek összekeverik az Ethereum világába tartozó neveket, így nem tudnak az Ethereum működéséről valós képet kapni. Az alábbiakban gyorsan összefoglalnánk, hogy mi micsoda: - -### Ethereum {#ethereum} - -Az Ethereum egy nyilvános hálózat, egy blokklánc és egy nyílt forráskódú protokoll, melyet egy globális közösség sok tízezernyi tagja működtet, irányít, kezel és birtokol, és amely közösség fejlesztőkből, csomópont-üzemeltetőkből, ETH-szel rendelkezőkből és felhasználókból áll. - -[Bővebben az Ethereumról](/what-is-ethereum/) - -[Bővebben az Ethereum irányításáról](/governance/) - -### Ether (ETH) {#ether-or-eth} - -Az Ether (melyet ETH-ként is láthat) a natív valuta, mellyel az Ethereumon tranzakciókat hajtanak végre. Az Ethereum hálózat használatáért ETH-ben kell fizetni (tranzakciós díjak formájában). Az ETH-t arra is használják, hogy a letétbe helyezés révén biztosítsa a hálózatot. Amikor arról van szó, hogy mi az Ethereum ára, akkor az ETH-re gondolnak. - -[Bővebben az ETH-ről](/eth/) - -[Bővebben az ETH letétbe helyezéséről](/staking/) - -### Ethereum Alapítvány {#ethereum-foundation} - -Egy non-profit szervezet, melyet eredetileg az ETH tömeges eladásával alapítottak meg, és az Ethereum hálózat és ökoszisztéma dedikált támogatója. - -[Bővebben az Ethereum Alapítványról](/foundation/) - -### ethereum.org {#ethereum-org} - -Egy nyilvános, nyílt forráskódú weboldal és tudásbázis az Ethereum közössége számára. Az ethereum.org oldalt egy kicsi központi csapat vezeti, melyet az Ethereum Alapítvány hozott létre, és több ezer közösségi tag közreműködik benne a világ minden tájáról. - -Ez a cikk további információkat tartalmaz az ethereum.org-ról. - -## Küldetésünk {#our-mission} - -**Az ethereum.org küldetése, hogy a legjobb portál legyen az Ethereum egyre növekvő közössége számára** - -Arra törekszünk, hogy egy könnyen érthető tudástárat építsünk minden Ethereumhoz kapcsolódó témáról, hogy az új felhasználók megismerhessék az Ethereumot és fontos koncepcióit. Szeretnénk: - -- elmagyarázni az Ethereumot bárkinek, akinek új ez a technológia -- segíteni az új felhasználónak belekezdeni az ETH és az Ethereum használatába -- segíteni az új fejlesztőknek, hogy építésbe fogjanak -- bemutatni az Ethereum világának változásait, híreit -- bemutatni a közösség által készített anyagokat -- lehetővé tenni az Ethereum oktatást annyi nyelven, amennyin csak lehetséges - -E küldetést elérni, ezért a csapatunk a következő két elsődleges célra koncentrál az ethereum.org-on: - -### 1. Az ethereum.org látogatók felhasználó élményének javítása {#visitors} - -- A tartalom kiterjesztése új témákra, fejlesztése és frissítése -- A használhatóság és az elérhetőség fejlesztése a lokalizáció és a webfejlesztés bevált gyakorlatai által -- A felhasználói elköteleződés növelése olyan funkciókkal, mint a kérdőívek, kvízek és web3 integrációk -- A honlapot megőrizzék könnyűsúlyú és hatékonyan működő állapotában - -### 2. A közreműködők közössége növekedjen, erősödjön és alkalmas legyen {#community} - -- A honlaphoz hozzájárulók számának növelése -- A közreműködők megtartásának javítása a bevonás, elismerés és díjak révén -- A közösség tagjait alkalmassá tenni arra, hogy egyre növekvő, jelentős hozzájárulásokat tegyenek -- A közreműködés sokszínűségének elősegítése: kód, tartalom, dizájn, fordítás, moderálás -- A kódbázis modern, tiszta és jól dokumentált legyen - -## Alapelveink {#core-principles} - -A következő fő elvek segítenek nekünk teljesíteni a küldetést. - -### 1. Az ethereum.org egy portál az Ethereumra {#core-principles-1} - -Szeretnénk felkelteni a felhasználók érdeklődését és megválaszolni a kérdéseiket. Tehát portálunk egyszerre szolgáltat információkat, „varázslatos pillanatokat” és hozzáférést a közösség által létrehozott kiváló anyagokhoz. A honlap tartalma nem helyettesíti a már meglévő, kiterjedt forrásokat, hanem bevezeti a felhasználókat a témákba és elérhetővé teszi ezeket az anyagokat. Szeretnénk támogatni és integrálni a közösség által felépített tudásbázist, hogy azok láthatóbbak és felfedezhetőbbek legyenek. [Az Ethereum közösség](/community/) ennek a középpontjában áll: nemcsak a közösséget szolgáljuk, hanem együttműködünk a tagjaival és felhasználjuk a visszajelzéseiket. A weboldal nem csak a mostani közösségnek szól, hanem annak is, amelyhez reményeink szerint felfejlődhetünk. Emlékeznünk kell arra, hogy közösségünk globális, és sok nyelvből, régióból és kultúrából származó embereket tartalmaz. - -### 2. Az ethereum.org folyamatosan fejlődik {#core-principles-2} - -Az Ethereum és a közösség folyamatosan fejlődik, így az ethereum.org is fejlődni fog. Emiatt van az oldalnak egyszerű dizájnrendszere és moduláris struktúrája. Iteratív változtatásokat hajtunk végre az alapján, hogy az emberek hogyan használják a webhelyet, és mit akar tőle a közösség. Nyílt forráskóddal működünk, és a közreműködők közösségével dolgozunk, így Ön is tehet javaslatot változtatásokra vagy segíthet is nekünk a különféle feladatokban. [Bővebben a közreműködésről](/contributing/) - -### 3. Az ethereum.org nem egy tipikus termékről szóló weboldal {#core-principles-3} - -Az Ethereum egy nagy dolog: magában foglal egy közösséget, egy technológiát, egy sor elképzelést és ideológiát, és még sok mást. Ez azt jelenti, hogy a weboldalnak sok különböző felhasználói utat le kell fednie a „fejlesztőtől, aki egy bizonyos eszközt szeretne kifejleszteni” egészen az „újoncig, aki vett valamennyi ETH-et és még nem tudja, mi az a tárca”. „Melyik a legjobb blokklánc platform weboldal?” marad az örökérvényű kérdés – mi úttörők vagyunk. Egy ilyen felépítéséhez kísérletezés szükséges. - -## Az ethereum.org ütemterve {#roadmap} - -Az ethereum.org csapat negyedéves ütemtervet publikál az aktuális célokról, hogy a tevékenységét elérhetőbbé tegye és elősegítse a közösségi közreműködéseket. - -[Tekintse meg a 2024. 3. negyedévére vonatkozó ütemtervünket](https://github.com/ethereum/ethereum-org-website/issues/13399) - -**Hogy hangzik?** Nagyra értékeljük, ha visszajelzést ad az ütemtervükkel kapcsolatban! Ha bármivel kapcsolatban úgy véli, hogy foglalkoznunk kellene vele, tudassa velünk! Szívesen fogadjuk a közösség bármelyik tagjától az ötleteket és a beadott kérvényeket (PR, mint pull request). - -**Szeretne Ön is részt venni?** [Tudjon meg többet a közreműködésről](/contributing/), [kövessen minket Twitteren](https://twitter.com/ethdotorg), vagy csatlakozzon a közösségi megbeszélésekhez a [Discord szerveren](https://discord.gg/ethereum-org). - -## Tervezési elvek {#design-principles} - -A honlappal kapcsolatos tartalmi és dizájn jellegű megbeszéléseket a [dizájnelvek](/contributing/design-principles/) vezérlik. - -## Dizájnrendszer {#design-system} - -Egy [dizájnrendszert](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System?node-id=0%3A1&t=QBt9RkhpPqzE3Aa6-1) hoztunk létre és tettünk közzé, hogy az új jellemzőket gyorsabban be tudjuk vezetni, illetve a közösség tagjai is részt tudjanak venni az ethereum.org nyilvános dizájnjában. - -Szeretne Ön is részt venni?[Kövesse a témát a Figmában](https://www.figma.com/file/NrNxGjBL0Yl1PrNrOT8G2B/ethereum.org-Design-System), a [GitHub issue-knál](https://github.com/ethereum/ethereum-org-website/issues/6284) és csatlakozzon a [#design Discord csatornán](https://discord.gg/ethereum-org) folyó beszélgetésekhez. - -## Stílusútmutató {#style-guide} - -Elérhető egy [stílusútmutató](/contributing/style-guide/), hogy a tartalomírás bizonyos aspektusait összehangolja, és így a hozzájárulás folyamata is egyszerűbb lesz. - -Kérjük, hogy tekintse át az [elveinket](/contributing/design-principles/) és a [stílusútmutatót](/contributing/style-guide/), ha szeretne [hozzájárulni a honlaphoz](/contributing/). - -Ha bármi észrevétele van a dizájnelvekkel, dizájnrendszerrel és a stílusútmutatóval kapcsolatban, azt jelezze felénk. Ne feledje, az ethereum.org a közösségért van a közösség által. - -## Licenc {#license} - -Az ethereum.org honlap nyílt forráskódú és az [MIT License](https://github.com/ethereum/ethereum-org-website/blob/dev/LICENSE) vonatkozik rá, hacsak másképp nincs megadva. Bővebben az ethereum.org [felhasználási feltételeiről](/terms-of-use/). - -## Álláslehetőségek {#open-jobs} - -Habár ez a honlap nyílt forráskódú és bárki dolgozhat rajta, egy dedikált csapat dolgozik az ethereum.org és más Ethereum Alapítványi webprojektek jobbá tételén. - -Itt megtalálhatja az aktuális álláslehetőségeket. Ha nem lát Önhöz illeszkedő pozíciót, akkor nézzen át a [Discord szerverünkre](https://discord.gg/ethereum-org) és mondja el nekünk, hogyan szeretne velünk dolgozni! - -Az ethereum.org csapaton túli lehetőségek is érdeklik? [Nézze meg az Ethereumhoz kapcsolódó további álláslehetőségeket](/community/get-involved/#ethereum-jobs/). diff --git a/public/content/translations/hu/26) Miscellaneous/enterprise/index.md b/public/content/translations/hu/26) Miscellaneous/enterprise/index.md deleted file mode 100644 index 41f49c4ccac..00000000000 --- a/public/content/translations/hu/26) Miscellaneous/enterprise/index.md +++ /dev/null @@ -1,161 +0,0 @@ ---- -title: Vállalatok az Ethereum főhálózaton -description: Útmutatók, cikkek és eszközök a nyilvános Ethereum blokkláncon lévő vállalati alkalmazásokról -lang: hu ---- - -# Az Ethereum vállalatok számára {#ethereum-for-enterprise} - -Az Ethereum sokféle vállalkozásnak segíthet, beleértve a nagyvállalatokat is: - -- Növelni a bizalmat és csökkenteni az üzleti partnerek közötti koordináció költségét -- Javítani a felelősségre vonhatóságot és a működtetési hatékonyságot az üzleti hálózatokban -- Új üzleti modelleket és értékteremtő lehetőségeket kifejleszteni -- Versenyképesen jövőbiztossá tenni a szervezeteiket - -A korai években számos vállalati blokklánc-alkalmazást építettek privát, engedélyköteles, Ethereum-kompatibilis blokkláncokra vagy konzorciumláncokra. Manapság a technológiai fejlődésnek köszönhetően, mely nagyobb tranzakcióátvitelt, alacsonyabb tranzakciós költségeket és adatvédelmet tesz lehetővé, a legtöbb vállalati alkalmazás, mely Ethereum-technológiát használ, a publikus Ethereum főhálózatra vagy [L2](/layer-2) láncokra épül. - - -## Források {#enterprise-resources} - -### További olvasnivaló {#further-reading} - -Nem technikai információs anyagok annak megértéséhez, hogy a vállalkozások hogyan profitálhatnak az Ethereumból - -- [Miért hasznosak a blokkláncok az üzletben?](https://entethalliance.org/why-are-blockchains-useful-for-business/) - _A blokkláncok értékének megvitatása a kiszámíthatóság lencséjén keresztül_ -- [Enterprise Ethereum Alliance 2023 Business Readiness Report](https://entethalliance.org/eea-ethereum-business-readiness-report-2023/) - _felméri a nyilvános Ethereumban és a szélesebb Ethereum ökoszisztémában rejlő lehetőségeket és képességeket a vállalkozások számára_ -- [_Ethereum for Business_, írta Paul Brody](https://www.uapress.com/product/ethereum-for-business/) - _Egy közérthető útmutató azokról a felhasználási esetekről, amelyek a vagyonkezeléstől a fizetésen át az ellátási láncokig megtérülést hoznak_ - -### Szervezetek {#organizations} - -Különféle szervezetek számtalan együttműködésen alapuló erőfeszítést tettek azért, hogy az Ethereumot vállalkozásbarátabbá tegyék - -- [Enterprise Ethereum Alliance](https://entethalliance.org/) - Az EEA segíti a szervezeteket, hogy bevezessék és használják az Ethereum technológiáit mindennapi üzleti tevékenységükben. Célja az üzleti Ethereum felgyorsítása azáltal, hogy a szakmai és kereskedelmi támogatást, érdekérvényesítést és kutatást, szabványfejlesztést és ökoszisztéma-alapú bizalmi szolgáltatást nyújt. -- [Global Blockchain Business Council](https://www.gbbc.io/) - A GBBC a blokklánc-technológiai ökoszisztéma iparági szövetsége. A GBBC a politikai döntéshozók és a szabályozók bevonásával, rendezvények és mélyreható viták szervezésével, valamint a kutatás ösztönzésével elkötelezett a blokklánc további elfogadása mellett, hogy biztonságosabb, igazságosabb és működőképesebb társadalmakat hozzon létre. - - -## Vállati fejlesztői anyagok {#enterprise-developer-resources} - -### Termékek és szolgáltatások {#products-and-services} - -- [4EVERLAND](https://www.4everland.org/) - _ API-okat, RPC szolgáltatásokat és eszközöket kínál decentralizált alkalmazások működtetésére és az Ethereumon való decentralizált tároláshoz_ -- [Alchemy](https://www.alchemy.com/) - _API-szolgáltatásokat és -eszközöket szolgáltat az Ethereum alkalmazások fejlesztéséhez és monitorozásához_ -- [Blast](https://blastapi.io/) - _egy API-platform, amely RPC/WSS API-okat biztosít az Ethereum archív főhálózathoz és a teszthálózatokhoz._ -- [Blockapps](https://blockapps.net/) - _a vállalati Ethereum-protokoll, az eszközkészlet és az API-ok implementációja, melyek a STRATO platformot alkotják_ -- [Chainstack](https://chainstack.com/) - _az Ethereum főhálózatára és teszthálózataira biztosít infrastruktúrát, amelyet nyilvános és elkülönített vevői felhőkben hosztol_ -- [ConsenSys](https://consensys.io/) - _számos terméket és eszközt kínál az Ethereum fejlesztésére, valamint tanácsadási és egyedi fejlesztési szolgáltatásokat nyújt_ -- [Crossmint](http://crossmint.com/) – _Vállalati szintű web3-fejlesztési platform okosszerződések telepítéséhez, hitelkártyás és láncok közötti fizetések lehetővé tételéhez, valamint API-ok használatára NFT-k létrehozása, terjesztése, értékesítése, tárolása és szerkesztése érdekében._ -- [Envision Blockchain](https://envisionblockchain.com/) - _az Ethereum főhálózatra szakosodott, vállalati fókuszú, tanácsadási és fejlesztési szolgáltatásokat nyújt_ -- [EY OpsChain](https://blockchain.ey.com/products/contract-manager) - _beszerzési munkafolyamatot biztosít, melynek során ajánlatbekéréseket (RFQ), szerződéseket, rendeléseket és számlákat bocsát ki az Ön megbízható üzleti partnereiből álló hálózatán keresztül_ -- [Hyperledger Besu](https://www.hyperledger.org/use/besu) - _egy vállalati fókuszú, nyílt forráskódú Ethereum-kliens Apache 2.0 licensszel fejlesztve és Java nyelven írva_ -- [Infura](https://infura.io/) - _skálázható API-hozzáférés az Ethereumhoz és az IPFS hálózatokhoz_ -- [Kaleido](https://kaleido.io/) - _egy vállalati fókuszú fejlesztési platform, amely egyszerűsített blokklánc- és digitáliseszköz-alkalmazásokat kínál_ -- [NodeReal](https://nodereal.io/) - _skálázható blokklánc-infrastruktúrát és API-szolgáltatókat biztosít a web3 ökoszisztémának_ -- [Moralis](http://moralis.io/) - _vállalati szintű API-ok és csomópontok egy SOC2 2-es típusú tanúsítással_ -- [Provide](https://provide.services/) - _vállalati zero-knowledge middleware_ -- [QuickNode](https://www.quicknode.com/) - _megbízható és gyors csomópontokat biztosít magas szintű API-okkal, mint amilyen az NFT API, Token API stb., miközben egy egységes termékcsomagot és vállalati szintű megoldásokat szállít_ -- [Tenderly](https://tenderly.co) - _egy web3-fejlesztői platform, amely okosszerződés-fejlesztéshez, -teszteléshez, -monitorozáshoz és -működtetéshez biztosít hibakeresési, megfigyelhetőségi és infrastruktúrához kapcsolódó építőelemeket_ -- [Unibright](https://unibright.io/) - _egy blokklánc-specialistákból, tervezőkből, fejlesztőkőből és szaktanácsadókból álló csapat, több mint 20 év tapasztalattal az üzleti folyamatok és az integráció területén_ -- [Zeeve](https://www.zeeve.io/) - _az Ethereumra való építéshez nyújt termékeket és eszközöket, valamint infrastruktúrát és API-okat biztosít vállalati web3 alkalmazásoknak._ - -### Eszközök és könyvtárak {#tooling-and-libraries} - -- [Baseline Project](https://www.baseline-protocol.org/) - _A Baseline Protocol egy olyan eszköz- és könyvtárkészlet, amely segít a vállalatoknak az összetett, többszereplős üzleti folyamatok és munkafolyamatok adatvédelmi szempontból történő koordinálásában, miközben az adatok a megfelelő nyilvántartási rendszerekben maradnak. A szabvány lehetővé teszi, hogy két vagy több állapotgép elérje és fenntartsa az adatok konzisztenciáját és a munkafolyamatok folytonosságát a hálózat közös referenciakeretként való használatával._ -- [Chainlens](https://www.chainlens.com/) - _SaaS és on-prem blokklánc adat- és elemzési platform a Web3 Labs-től_ -- [Ernst & Young 'Nightfall'](https://github.com/EYBlockchain/nightfall_3) - _egy alkalmazás az ERC-20, ERC-721 és ERC-1155 alkalmazások átvitelére zero-knowledge módon, optimista összesítés használatával_ - -### Skálázási megoldások {#scalability-solutions} - -A legtöbb új blokklánc-alkalmazás az [L2](/layer-2) láncokra épül. A második blokkláncréteget (L2) olyan technológiák vagy rendszerek alkotják, melyek az Ethereumon (L1) futnak, öröklik a biztonsági tulajdonságait az L1-től és nagyobb tranzakciófeldolgozási kapacitást (átvitelt) biztosítanak, alacsonyabb tranzakciós illetékkel (működési költség) és gyorsabb tranzakciómegerősítéssel, mint az L1 esetében. A 2. rétegű skálázási megoldások biztonságát az 1. réteg szolgáltatja, de a blokklánc alkalmazások számára elérhetővé teszik, hogy több felhasználót, tevékenységet vagy adatot kezeljenek, mint amire az 1. réteg képes lenne. A legtöbbjük a kriptográfiában és a zéró-tudású (ZK) bizonyíték kapcsán elért fejlődési eredményeket használja, hogy növelje a teljesítményt és a biztonságot, és néhányuk az adatvédelem újabb szintjét kínálja. - -## Vállalati alkalmazások a főhálózaton {#enterprise-live-on-mainnet} - -Íme néhány olyan vállalati alkalmazás, amelyet hagyományos, nem blokklánc alapú vállalatok építettek a nyilvános Ethereum főhálózatra és L2-re. - -### Fizetések {#payments} - -- A [Brave Browser](https://basicattentiontoken.org/) - _a felhasználóknak fizet, hogy hirdetéseket nézzenek, a felhasználók pedig fizetéssel támogathatják a kiadókat a Basic Attention Token segítségével._ -- [Lugano városa Svájcban](https://bitcoinsuisse.com/news/city-of-lugano-accepts-crypto-payments) - _adófizetés és egyéb önkormányzati szolgáltatások_ -- Az [EthereumAds](https://ethereumads.com/) - _lehetővé teszi a weboldal működtetőinek, hogy reklámhelyeket értékesítsenek és az Ethereumon keresztül kapjanak érte pénzt_ -- [hCaptcha](https://www.hcaptcha.com/) - _Botkizáró CAPTCHA rendszer, amely fizet a weboldal működtetőinek a felhasználók által végzett munkáért, akik a gépi tanulás számára jelölik az adatokat. Már telepítve van a Cloudflare-en is._ -- [Opera MiniPay](https://www.opera.com/products/minipay) - _megkönnyíti és biztonságosabbá teszi a mobilfizetést az Afrikában élők számára, akiknek egy saját felügyeletű tárcával és telefonszámokkal egyszerűbbé teszi a tranzakciókat_ -- [Roxpay](https://www.roxpay.ch/) - _automatizálja a használat alapú eszközszámlázást és fizetést_ -- [SAP Digital Currency Hub](https://community.sap.com/t5/technology-blogs-by-sap/cross-border-payments-made-easy-with-digital-money-experience-the-future/ba-p/13560384) - _határokon átnyúló fizetések stabil érmékkel_ -- [Toku](https://www.toku.com/) - _bérszámfejtés, tokenalapú ösztöndíjak adminisztrációja, adózás, helyi alkalmazás, jövedelmezés és elosztott HR-megoldások_ -- [Xerof](https://www.xerof.com/) - _gyors és alacsony költségű nemzetközi (határokon átívelő) vállalatok közötti (B2B) fizetések intézése_ - -### Pénzügy {#finance} - -- [ABN AMRO](https://tokeny.com/tokeny-fuels-abn-amro-bank-in-tokenizing-green-bonds-on-polygon/) - _a Tokeny révén tokenizált, zöld kötvények_ -- [Crowdz](https://crowdz.io/) - _platform számlák/követelések pénzügyi kezelésére és faktoringjára_ -- [Mata Capital](https://consensys.io/blockchain-use-cases/finance/mata-capital) - _ingatlanbefektetések tokenizálása_ -- [Obligate](https://www.obligate.com/) - _szabályozott és ellenőrzött (KYC) láncon belüli kötvények és kereskedelmi papírok_ -- [Siemens](https://press.siemens.com/global/en/pressrelease/siemens-issues-first-digital-bond-blockchain) - _kötvénykibocsátás_ -- [Sila](https://silamoney.com/) - _bankolásra és ACH-fizetésre szolgáló infrastruktúra mint szolgáltatás egy stabil érmét használva_ -- [Societe Generale FORGE](https://www.sgforge.com/product/bonds/) - _kötvénykibocsátás_ -- [Taurus](https://www.taurushq.com/) - _tokenizált részvények kibocsátása_ - -### Eszköztokenizálás {#tokenization} - -- Az [AgroToken](https://agrotoken.io/en/) - _mezőgazdasági anyagokat tokenizál és kereskedik velük_ -- [Bitbond](https://www.bitbond.com/) - _tokenizálással javítja a pénzügyi eszközök kibocsátását, rendezését és őrzését_ -- [Blocksquare](https://blocksquare.io/) - _tokenizálási infrastruktúra ingatlanokhoz_ -- [Centrifuge](https://centrifuge.io/) - _tokenizált követelések finanszírozása, tartozások és eszközök kezelése_ -- [Clearmatics](https://www.clearmatics.com) - _decentralizált hálózati platformok építése a tokenizált értékek társközi (peer-to-peer) átváltásához_ -- [dClimate](https://www.dclimate.net/) - _decentralizált klímainformációs ökoszisztéma_ -- [Fabrica](https://www.fabrica.land/) - _platform az ingatlanok digitalizálására, beleértve a DeFi kölcsönzést és az ingatlanokkal való kereskedelmet_ -- A [Fasset](https://www.fasset.com/) - _egy platform a fenntartható infrastruktúráért_ -- [Nori](https://nori.com/) - _nyílt forráskódú piaci infrastruktúra a karboncsökkentési projektek számára, hogy mérhessék és monetizálhassák tevékenységüket_ -- [Propy](https://propy.com/) - _platform a lakossági ingatlanügyletek automatizálására okosszerződésekkel_ -- A [RealT](https://realt.co/) - _révén a befektetők a világ minden részéről vásárolhatnak az amerikai ingatlanpiacon a szabályozásnak megfelelő, tokenizált résztulajdont_ -- [Rubey](https://www.rubey.be/) - _platform a felsőfokú művészet tokenizálásához, hogy azok elérhetők legyenek a kiskereskedelmi befektetőknek_ -- [Swarm](https://swarm.com/) - _platform a fizikai eszközök digitalizálására és a szabályozásnak megfelelő kereskedelmére _ -- [Thallo](https://www.thallo.io/) - _platform a digitális karbon kreditek üzleti tranzakciókba való integrálására_ -- [Tokenchampions](https://tokenchampions.com/) - _tokenizálja az európai focijátékosok képeinek jogait_ - -### Adatok notarizációja {#notarization-of-data} - -- [ANSA](https://www.ansa.it/english/news/science_tecnology/2020/04/06/ansa-using-blockchain-to-help-readers_af820b4f-0947-439b-843e-52e114f53318.html) - _Olasz hírügynökség, mely az álhírek ellen küzd, és lehetővé teszi az olvasók számára, hogy a hírek eredetét a főhálózaton történő rögzítéssel ellenőrizzék_ -- [Breitling](https://www.coindesk.com/breitling-arianee-all-new-watches-ethereum) - _az órák származását és javítási történetét rögzíti az Ethereumon_ -- [BRØK](https://www.xn--brk-1na.no/) - _platform a tőzsdén nem jegyzett társaságoknak, melyet a norvég kormány biztosít_ -- [Certifaction](https://certifaction.com/) - _legálisan érvényes elektronikus aláírások, melynek eleve része az adatvédelem_ -- [EthSign](https://ethsign.xyz/) - _feljegyezi az Ethereum-blokkláncra az aláírt elektronikus dokumentumokat_ -- [Stacktical](https://stacktical.com/) - _szoftverfejlesztés, szolgáltatásiszint-megegyezés (SLA) digitális biztosítása és aláírása natív letétbe helyezési képességekkel_ -- [Verizon](https://decrypt.co/46745/verizon-news-press-releases-ethereum-full-transparency) - _Naplózza a sajtóközleményeket az Ethereumon a vállalati elszámoltathatóság és bizalom biztosítása érdekében_ -- [WolfTown](https://www.mef.net/edge-view-blog/automated-secure-timely-sla-reporting-is-finally-a-reality/) - _MEF és Sage Management által automatizált szolgáltatásiszint-megegyezés (SLA) riportálása a távközlési szolgáltatók között_ - -### Ellátási lánc {#supply-chain} - -- [Birra Peroni](https://www.ey.com/en_gl/news/2021/05/birra-peroni-is-the-first-industrial-organization-to-mint-unique-non-fungible-tokens-using-ey-opschain-traceability) _NFT-ket készít minden egyes új tétel sörhöz, ami nagyobb átláthatóságot és hatékonyságot tesz lehetővé az ellátási láncban_ -- [CargoX](https://cargox.io/) - _Elektronikus fuvarlevél- és okmánytovábbítási szolgáltató szállításhoz_ -- [Circularize](https://www.circularise.com/) - _elejétől a végéig lekövethető megoldás arra, ahogy a nyersanyagokból késztermékek lesznek_ -- [EY OpsChain Network Procurement](https://blockchain.ey.com/products/contract-manager) - _egy beszerzési munkafolyamatot biztosít a cégek számára, melynek során ajánlatbekéréseket (RFQ), szerződéseket, rendeléseket és számlákat bocsát ki az üzleti partnereiből álló hálózatán keresztül_ -- [Minespider](https://www.minespider.com/) - _ellátási lánc, eredet és Co2 kibocsátás nyomon követése_ -- [Morpheus.network](https://morpheus.network/) - _platform az ellátási lánc automatizálására_ -- [StaTwig](https://statwig.com/) - _ellátási lánc működtetése_ -- [TradeTrust](https://www.tradetrust.io/) - _az elektronikus fuvarleveleket (eBLs) ellenőrzi a nemzetközi szállításban_ -- [Transmute](https://transmute.industries/) - _adatcsereplatform a globális kereskedelem számára, amely támogatja az Ethereumon a decentralizált identitással való tranzakciókat_ - -### Biztosítás {#insurance} - -- [Arbol](https://www.arbolmarket.com/) - _egy parametrikus biztosítás az időjárásból eredő kockázatok fedezésére_ -- [Etherisc](https://etherisc.com/) - _decentralizált biztosítás különféle kockázatokra_ -- [Nayms](https://www.nayms.com/) - _az AON-nal együtt épített digitális tér arra, hogy biztosítási programokat hozzanak létre, tőkét gyűjtsenek és helyezzenek ki, kockázatot írjanak le, valamint díj- és kárigény-tranzakciók fizetését intézzék_ - -### Identitás, hitelesítőadatok és tanúsítványok {#credentials} - -- [BCdiploma](https://www.bcdiploma.com/) - _digitalizálja és ellenőrzi az okiratokat, tanúsítványokat és a mikro hitelesítési adatokat_ -- [Hyland Credentials](https://www.hylandcredentials.com) - _digitális diplomákat és más oktatási igazolványokat, engedélyeket és bizonyítványokat bocsát ki_ -- [Palau Digital Residency Program](https://rns.id/) - _a világpolgárok részére lehetővé teszi egy legális, a Palau kormány által kiadott igazolvány megszerzését_ -- [Spherity](https://www.spherity.com/) - _digitális identitáskezelési megoldásokat kínál, hogy az ökoszisztémában megalapozza a digitális bizalmat, fókuszálva a decentralizált identitásra és az ellenőrizhető hitelesítő adatokra_ -- [Zug Digital ID](https://ezug.ch/en/) - _egy blokkláncalapú identitásrendszer Svájcban, amely digitális hozzáférést biztosít a kormány által nyújtott szolgáltatásokhoz, és olyan a funkciókat is támogat, mint az online biciklikölcsönzés és a helyhatósági szavazás_ - -### Szórakozás, NFT-k és hűségprogramok - -- [Adidas Virtual Gear](https://www.adidas.com/metaverse) - _virtuális felszerelések NFT-gyűjteménye_ -- [The British Museum's Sandbox](https://decrypt.co/150405/british-museum-enter-metaverse-via-sandbox) - _egy NFT-gyűjtemény_ -- [Fruitlab](https://fruitlab.com/) - _platform a játékosoknak, hogy az online játékok megtekintése, megosztása és használata során jövedelemhez jussanak_ -- [Nike Swoosh](https://www.swoosh.nike/) - _egy NFT-platform_ -- [Sothbebys Metaverse](https://metaverse.sothebys.com/) - _egy digitális művészeti NFT-piactér a Sothebys által_ - -Ha szeretne valamit hozzáadni a listához, akkor tekintse át a [közreműködésre vonatkozó instrukciókat](/contributing/). diff --git a/public/content/translations/hu/26) Miscellaneous/foundation/index.md b/public/content/translations/hu/26) Miscellaneous/foundation/index.md deleted file mode 100644 index 6ccb3fa997a..00000000000 --- a/public/content/translations/hu/26) Miscellaneous/foundation/index.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Ethereum Alapítvány -description: Ismerje meg az Ethereum Alapítványt (EF), amely egy non-profit szervezet, s célja az Ethereum és a hozzá kapcsolódó technológiák támogatása. -hideEditButton: true -lang: hu ---- - -# Az Ethereum Alapítványról {#about-the-ethereum-foundation} - - - -Az [Ethereum Alapítvány (EF)](http://ethereum.foundation/) egy non-profit szervezet, melynek célja az [Ethereum](/what-is-ethereum/) és a kapcsolódó technológiák támogatása. - -Az Ethereum Alapítvány (EF) nem egy cég, még csak nem is hagyományos non-profit. Feladatuk nem az Ethereum irányítása vagy vezetése, és nem is az egyetlen szervezetté válás, amely finanszírozza az Ethereumhoz kapcsolódó, fontos technológiák fejlesztését. Az EF egy sokkal nagyobb [ökoszisztémának](/community/) a része. - -## Ethereum Alapítvány Kezdeményezések {#ethereum-foundation-initiatives} - -### Ecosystem Támogatási Program {#ecosystem-support-program} - -Az [Ökoszisztéma Támogatási Program](https://esp.ethereum.foundation/) célja, hogy pénzügyi és nem pénzügyi támogatást nyújtson projekteknek és egyéneknek a tágabb Ethereum közösségen belül, hogy felgyorsítsa az ökoszisztéma növekedését. Az Ökoszisztéma Támogatási Program az eredeti Ethereum támogatási/ösztöndíj program kibővítése, amely főként a pénzügyi támogatásra összpontosított. - -Tudjon meg többet az Ökoszisztéma Támogatási Programról, korábbi ösztöndíjasokról és az ösztöndíj jelentkezési folyamatáról az [esp.ethereum.foundation](https://esp.ethereum.foundation/) oldalon. Ezenkívül megnézheti az [Ökoszisztéma Támogatási Program Blogját](https://blog.ethereum.org/category/ecosystem-support-program/) vagy követheti az [@EF_ESP](https://twitter.com/EF_ESP) oldalt a legfrissebb hírekért és bejelentésekért. - -### Devcon {#devcon} - -Az Ethereum Alapítvány 2014 óta szervezi a Devcont, az Ethereum éves konferenciáját, mely egy helyre gyűjti a fejlesztőket, kutatókat, gondolkodókat és alkotókat. - -Hozzáférhet az összes konferencián elhangzó előadás videójához a kezdetektől az [archive.devcon.org](https://archive.devcon.org/) oldalon. - -Tudjon meg többet a [devcon.org](https://devcon.org/) oldalon, tekintse meg a [Devcon blogot](https://devcon.org/en/blogs/), vagy kövesse a [@efdevcon](https://twitter.com/EFDevcon) csatornát a legfrissebb információkért. - -### Ösztöndíjas program {#fellowship-program} - -Az [Ethereum Alapítvány Ösztöndíjas Programja](https://fellowship.ethereum.foundation/) egy olyan kezdeményezés, mely a kulturális, nemzeti és gazdasági csoportok egyenlő arányú jelenlétét akarja elősegíteni. A program úgy akarja áthidalni a szakadékokat, hogy kivételes és tehetséges egyéneket keres és támogat, hogy felkeltsék e csoportok Ethereum iránti érdeklődését, elhárítsák azokat az akadályokat, amelyek miatt a távolmaradó emberek és közösségek nem tudnak csatlakozni az Ethereum világához, pedig ők jelentik a web3 jövőjét. - -[Tudjon meg többet a fellowship.ethereum.foundation oldalon](https://fellowship.ethereum.foundation/). - -
- -További információkért az Alapítványról látogasson el az [ethereum.foundation](http://ethereum.foundation/) weboldalra, vagy nézze meg az [Ethereum Alapítvány Blogot](https://blog.ethereum.org/) a legfrissebb hírekért és bejelentésekért. diff --git a/public/content/translations/hu/27) Contributing/contributing/design-principles/index.md b/public/content/translations/hu/27) Contributing/contributing/design-principles/index.md deleted file mode 100644 index 8a179086b72..00000000000 --- a/public/content/translations/hu/27) Contributing/contributing/design-principles/index.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -title: Dizájnelvek -lang: hu -description: Az ethereum.org dizájnhoz és tartalmi döntésekhez kapcsolódó elvei ---- - -# Dizájnelveink {#contributing-to-ethereumorg-} - - Üdvözlöm az ethereum.org dizánelvei oldalon. Ez szerves része annak a folyamatnak, amely során az ethereum.org-ot fejlesztjük. - -Az elveink adják a honlapnak és tartalmának kinézetét és érzetét. - -Kérjük, hogy tekintse át ezeket, mielőtt [közreműködik az ethereum.org-on](/contributing/). - -## Mik azok a dizájnelvek? {#ways-to-contribute} - -Ne aggódjon, nagyon egyszerűek! A **dizájnelvek** olyan útmutatások, melyekhez igazodunk a tervezésnél (amikor létrehozunk, fenntartunk vagy frissítünk valamit). - -Az ethereum.org-nál ezek az elvek adják meg, hogy mit képviseljen a honlap és mit mutasson a világnak. Egyaránt ösztönzők **és** gyakorlatiasak. Nemcsak az, ahogyan a honlap _kinéz_, hanem ahogy _működik_ és ahogy azt valaki _megtapasztalja_. Minden egyes dolog, a színektől kezdve az elrendezésig és hogyan beszélünk az Ethereumról, mind ezen elvek mentén történik. - -## Az elvek a gyakorlatban {#how-decisions-about-the-site-are-made} - -Vegyünk egy példát. Az egyik elv a „hiteles”, ami azt jelenti, hogy a látogatók _érezzék_ és _tudják_, hogy a honlap megbízható - ahogy a kiterjedt Ethereum ökoszisztéma is. Ezen belül található három gyakorlati „alelv”, amelyeket követve elérhetjük, hogy a honlap hiteles legyen: - -- _„Friss”_ vagyis a tartalom legyen frissítve. -- _„Közösségi bizonyíték”_ vagyis mutassuk meg az ökoszisztéma méretét, diverzitását és tevékenységeit (mint az Ethereum-frissítések, DeFi, játékok, hackathon-ok stb.) -- _„Konzisztens”_ vagyis egységes dizájn az oldalakon, valamint tónus és pontosság a tartalomban. - -Tehát amikor döntést akarunk hozni, akkor a hitelesség elve mentén feltehetjük a kérdést: - -- _„Tükrözi a honlap az aktuális információkat?”_ -- _„Hogyan és hol mutatjuk meg az ökoszisztéma méretét és tevékenységét?”_ -- _„A közösségi tag által javasolt hozzájárulás, amelyet átnézek, konzisztens a jelenlegi dizájnnal és írással?”_ - -## Az ethereum.org dizájnelvei {#contributors} - -### 1. Inspiráló {#1-inspirational} - -Ez a honlap arra inspirálja a felhasználókat, hogy elképzeljék, az Ethereum hogyan változtatja meg a világot. Arra ösztönözze az embereket, hogy az Ethereum ökoszisztémát felfedezzék, játszanak és bütyköljenek az eszközökkel és alkalmazásokkal. - -- **Radikális:** A honlap kifejezze az Ethereum ambíciózus célját, hogy értelmes módon megváltoztassa a világot. Legyen egyértelmű, hogy az Ethereum nem csak egy új technológiai stack - ez egy transzformációs technológia. -- **Az oktatás általi felhatalmazás:** Ez a honlap olyan tudást adjon az embereknek, hogy megértsék az Ethereumban rejlő potenciált, megtalálják a maguk helyét az ökoszisztémában, és azt érezzék, hogy képesek közreműködni benne. - -Vizuzális irány • Tartalom - -### 2. Univerzális {#2-universal} - -Az Ethereum egy globális, decentralizált projekt, és ez meghatározza a közönséget is. A honlap ezért legyen elérhető mindenkinek, és fogékony a világ számtalan kultúrájára. - -- **Elérhető:** A honlap kövesse az elérhetőségi iránymutatást - beleértve azt, hogy a kis sávszélességgel bíró emberek is kapcsolódhassanak hozzá. -- **Egyértelmű:** Legyen egyszerű és ellentmondásoktól mentes. Ne használjon olyan kifejezéseket, amelyeket félre lehet magyarázni vagy az értelme elveszik a fordításban. -- **Az Ethereum sokrétű:** Az Ethereum egy projekt, egy kódbázis, egy közösség, egy vízió. Különböző embereknek másféle okból értékes, és sokféle módon részt lehet venni benne. - -Írásrendszerek • Színhasználat • Vizuális irány • Tartalom - -### 3. Egy jó történet {#3-a-good-story} - -Az honlap legyen olyan, mint egy jó történet. A látogatók egy utazáson vesznek részt, és az a tartalom, melyhez Ön is hozzájárul, része ennek az útnak. A közreműködése egy egyértelmű történet része: melynek eleje van (bevezetés/belépési pont), közepe (tanulságok és rálátások) és vége (források vagy következő lépések). - -- **Hierarchikus**: Az egyértelmű, hierarchikusan rendezett információs architektúra segíti a látogatót, hogy az ethereum.org-on egy történetként haladjanak, ahogy a céljaik felé tartanak. -- **Egy lépcsőfok:** Ez egy lépcsőfok bárkinek, aki választ keres. Nem akarjuk helyettesíteni vagy lecserélni a már létező forrásokat. Választ adunk és megbízható következő lépéseket. - -Felhasználói utak • Tartalom - -### 4. Hiteles {#4-credible} - -Az emberek az Ethereum ökoszisztémába való bevezetést keresik, vagy szkeptikusok. Ezt a felelősséget el kell ismerni a kommunikáció módját illetően. Biztosítanunk kell, hogy mindannyian nagyobb magabiztossággal távoznak a honlapról. - -- **Friss:** Mindig aktuális. -- **Közösségi bizonyíték:** Mutassuk meg az ökoszisztéma méretét, diverzitását és tevékenységét. -- **Konzisztens:** A konzisztens dizájn és tartalom hitelességet sugall. - -Vizuzális irány • Tartalom - -### 5. Együttműködő fejlesztés {#5-collaborative-improvement} - -A honlap számtalan közreműködő terméke, ahogy az ökoszisztéma egésze is. - -- **Nyitott:** Értékeljük a forráskód, a folyamatok és projektek átláthatóságát az ökoszisztéma egészében. -- **Kiterjeszthető:** A modularitás az egyik fő fókuszunk, ezért a részvétel is legyen moduláris. A honlap fő dizájnja, komponenskódja és implementációja tegye lehetővé, hogy a jövőben könnyen kiterjeszthető legyen. -- **Kísérleti:** Állandóan kísérletezünk, tesztelünk és ismétlünk. -- **Együttműködő:** Ez a projekt mindannyiunkat összehoz. -- **Fenntartható:** Hosszú távú fenntartásra rendezkedünk be, melyet a közösség végez - -Láthatja a dizájnelveket a gyakorlatban [a honlap egészében](/). - -## Adjon visszajelzést {#give-feedback} - -**Ossza meg véleményét erről a dokumentumról!** Az egyik javasolt elvünk az **Együttműködő fejlesztés**, amely szerint ez a honlap számtalan résztvevő közös terméke legyen. Ennek szellemében osztjuk meg a dizájnelveket az Ethereum közösségével. - -Miközben ezek az elvek az ethereum.org honlapra fókuszálnak, reméljük, hogy számos elv az Ethereum ökoszisztéma értékeit képviseli (például észrevehető az [az Ethereum fehékönyv elveinek](https://github.com/ethereum/wiki/wiki/White-Paper#philosophy) hatása). Talán Ön is szívesen követné ezeket a saját projektjében! - -Tudassa velünk gondolatait a [Discord szerveren](https://discord.gg/ethereum-org) vagy azáltal, hogy [létrehoz egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=). diff --git a/public/content/translations/hu/27) Contributing/contributing/design/index.md b/public/content/translations/hu/27) Contributing/contributing/design/index.md deleted file mode 100644 index 0c136e5aa77..00000000000 --- a/public/content/translations/hu/27) Contributing/contributing/design/index.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: Közreműködés a dizájnban -description: Közreműködés a dizájnban az ethereum.org-on -lang: hu ---- - -# Közreműködés a dizájnban az ethereum.org-on {#design-contributions} - -Minden projekt kritikus eleme a dizájn, amennyiben az idejét és a dizájnképességeit az ethereum.org oldalon kamatoztatja, akkor segíti a látogatók felhasználói élményét. A nyílt forráskódú projektben való közreműködés lehetőséget ad arra, hogy releváns tapasztalatot szerezzen és készségeit együttműködő környezetben fejlessze. Együtt dolgozhat más tervezőkkel, fejlesztőkkel és közösségi tagokkal, akik mind saját perspektívával és rálátással rendelkeznek. - -Ez egy remek módja annak is, hogy egy sokszínű és hatásos portfóliót hozzon létre, mely bemutatja a dizájnképességeit. - -## Hogyan vehet részt? - -###  Adjon visszajelzést a korai dizájn prototípusairól {#design-critique} - -Néha szükséges a nyers ötleteket letesztelni. Ez egy remek lehetőség arra, hogy technikai tudás nélkül is részt vehessen. - -1. A dizájncsapat megoszt egy tervet a [Discord-on](https://discord.com/invite/ethereum-org) és a [GitHub-on](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). -2. Végigvezetik a dizájnon, hogy utána visszajelzést adjon a komment részben. -3. Ennek eredményét megosztják a GitHub issue-ban, majd lezárják azt. - -###  Vegyen részt kutatásban {#answer-surveys} - -Adjon visszajelzést a honlapról: - -1. Tekintse meg az ethereum.org-ot és olvasson el néhány oldalt. -2. Kattintson a visszajelzés funkcióra a jobb alsó sarokban, és válaszoljon a dizájnnal és tartalommal kapcsolatos kérdésekre. -3. Fókuszáljon a szabadon megválaszolható kérdésekre. - -###  Találjon dizájnnal kapcsolatos problémákat a honlapon és jelezze azokat {#report-design-issues} - -Az ethereum.org egy gyorsan fejlődő honlap, amely számtalan jellemzővel és tartalommal bír. A felhasználói felület bizonyos része már kivezethető lenne vagy fejleszteni kellene. Ha ilyet talál, akkor jelezze, hogy felkerüljön a radarunkra. - -1. Tekintse meg a honlapot és figyeljen oda a dizájnra. -2. Készítsen képernyőképeket és jegyzeteket, ha vizuális vagy UX problémát lát. -3. Jelezze a problémákat egy [hibariportban](https://github.com/ethereum/ethereum-org-website/issues/new/choose). - -###  Javasoljon dizájnváltozásokat {#propose-design-changes} - -Ha szereti a dizájnkihívásokat, akkor nézze meg a GitHub issue-kat, és szűrjön rá a [dizájnnal kapcsolatos tételekre](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). - -1. Tekintse meg a honlapot és figyelje meg a dizájnt, vagy keressen rá a GitHub könyvtárban azokra a jelzett hibákra, ahol [dizájnra van szükség (Design required)](https://github.com/ethereum/ethereum-org-website/labels/design%20required%20%F0%9F%8E%A8). -2. Ötleteljen a megoldáson és tervezze meg. (ideális esetben ezt a [dizájnrendszert](https://www.figma.com/community/file/1134414495420383395) használva). -3. Javasoljon megoldást a kapcsolódó GitHub issue-ban, vagy [hozzon létre újat](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A&template=feature_request.yaml&title=Feature+request). -4. Várja meg, amíg a dizájncsapat átnézi. - -###  Építsünk dizájnrendszert együtt {#Contribute-to-design-system} - -A dizájnrendszerünk révén ethereum.org tervezése szórakoztató és könnyű. Ha Ön tapasztalt dizájner, akkor segíthet nekünk a honlap komponenseinek létrehozásában. - -1. Válasszon egy meglévő issue-t a GitHub-on a [dizájnrendszer tábláról](https://github.com/ethereum/ethereum-org-website/labels/design%20system) vagy hozzon létre újat. -2. Kérje meg, hogy az adott tételt Önnek adják. -3. Készítsen dizájnt Figmában a kért komponensről. -4. Ossza meg azt a dizájncsapattal a GitHub-on, amikor átnézésre vagy útmutatásra van szüksége. -5. A dizájncsapat átnézi azt. -6. A csapat átvezeti rajta a változásokat és megosztja azt a közösséggel. - -###  Írjon dizájnnal kapcsolatos tartalmat a honlapra {#write-design-articles} - -Az Ethereum fejlesztői közössége kellően erős, de a dizájnközösségnek még van hova fejlődnie. Ha Ön web3-tudással rendelkező dizájner, akkor ossza meg tapasztalatát a nagyobb közösséggel, hogy együtt fejlődhessünk; van egy [oldalunk az Ethereumra vonatkozó dizájnról](/developers/docs/design-and-ux/), amelyhez Ön is hozzájárulhat. Megtekintheti a [listázási szabályokat](/contributing/design/adding-design-resources) is. - -1. Ötleteljen a dizájntémákon az ethereum.org kapcsán, melyek a többi dizájnernek is hasznosak lehetnek. -2. A GitHub könyvtárban [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new), és javasoljon egy témát benne (még ne írja meg a tartalmat). -3. Várja meg, amíg a dizájncsapat jóváhagyja. -4. Amint jóváhagyták, írja meg a tartalmat. -5. Adja be a kapcsolódó GitHub issue-ban. - -###  Készítsen új illusztrációkat {#prepare-illustrations} - -A vizualizáció az egyik legerősebb eszköz az elvont témák elmagyarázásához. Nagy potenciál van a diagrammokban és infografikákban. Egy kép képes ezernyi dolgot elmondani. - -1. Tekintse meg a honlapot és azokat az oldalakat, amelyeken jól jönne néhány infografika. -2. Biztosítsa, hogy az illusztráció stílusa kapcsolódik a meglévő [eszközökhöz](/assets/). -3. A GitHub könyvtárban [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new), melyben felveti az adott illusztrációt. -4. A dizájcsapat átnézi. -5. Létrehozunk egy új issue-t, és felkérünk egy fejlesztőt, hogy létrehozza az adott képet. diff --git a/public/content/translations/hu/27) Contributing/contributing/index.md b/public/content/translations/hu/27) Contributing/contributing/index.md deleted file mode 100644 index e8d145dbd9b..00000000000 --- a/public/content/translations/hu/27) Contributing/contributing/index.md +++ /dev/null @@ -1,117 +0,0 @@ ---- -title: Közreműködők -description: Ismerje meg, hogyan tud különféle módokon közreműködni az ethereum.org kapcsán -lang: hu ---- - -# Hozzájárulás az ethereum.org-hoz 🦄 {#contributing-to-ethereumorg} - -Az ethereum.org egy nyílt forráskódú projekt **több mint 12 000** közreműködővel, akik segítenek fordítani, írni, tervezni és fenntartani a honlapot. - -Ez egy befogadó közösség, mely segít fejlődni és megismerni az Ethereum ökoszisztémát, miközben értelmes hozzájárulást tehet és gyakorlati tapasztalatot szerezhet! - -## Közreműködési módok {#ways-to-contribute} - -**Fordítás** -- [Csatlakozzon a fordítási programhoz](/contributing/translation-program/) – Segítsen abban, hogy az ethereum.org új nyelveken legyen elérhető - -**Fejlesztés** -- [Dolgozzon egy meglévő problémán](https://github.com/ethereum/ethereum-org-website/issues) – Olyan feladatot találhat, melyet szükségesnek látunk megoldani - -**Dizájn** -- [Segítsen a honlap dizájnjában](/contributing/design/) Bármilyen szinten is ért hozzá, be tud segíteni a honlap dizájnjába - -**Tartalom** -- [Hozzon létre vagy szerkessze a tartalmat](/contributing/#how-to-update-content) – Javasoljon új oldalakat vagy fejlessze a meglévőket -- [Javasoljon közösségi forrásokat](/contributing/content-resources/) – Adjon hasznos cikket vagy forrást egy adott oldalhoz -- [Javasoljon dizájnforrást](/contributing/design/adding-design-resources/) – Adjon hozzá, frissítsen és töröljön a dizájnforrások közül -- [Javasoljon kifejezést a szószedethet](/contributing/adding-glossary-terms/) – Segítsen kiterjeszteni az Ethereum [szószedetet](/glossary/) -- [Kvízek](/contributing/quizzes/) – Adjon hozzá, frissítse és töröljön a kvízkérdésekből, melyek egy adott oldalhoz tartoznak - -**Új jellemzőkre vonatkozó ötletek** -- [Javasoljon új jellemzőt](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) – Ossza meg ötletét új jellemzőre vagy dizájnra vonatkozóan - -**Termékmegjelenítések** -- [Javasoljon tőzsdét](/contributing/adding-exchanges/) – Adjon egy új tőzsdét a [tőzsdekeresőhöz](/get-eth/#country-picker) -- [Javasoljon egy terméket](/contributing/adding-products/) – Adjon egy dappot vagy tárcát az adott oldalhoz -- [Javasoljon fejlesztői eszközt](/contributing/adding-developer-tools/) – Javasoljon fejlesztői eszközt a megfelelő oldalhoz -- [Javasoljon második blokkláncréteget (L2)](/contributing/adding-layer-2s/) – Adjon L2-t a megfelelő oldalhoz -- [Javasoljon letétbe helyezési terméket vagy szolgáltatást](/contributing/adding-staking-products/) – Adjon hozzá olyan projektet, ami elősegíti az önálló letétbe helyezést, a letéti alap vagy letéti szolgáltatás igénybevételét -- [Javasoljon tárcát](/contributing/adding-wallets/) – Adjon egy tárcát a [tárcakereső oldalra](/wallets/find-wallet/) -- [Javasoljon egy projektet a DeSci oldalra](/contributing/adding-desci-projects/) – Adjon hozzá egy Ethereumra épített projektet, mely hozzájárul a decentralizált tudományhoz - -Kérdése van? 🤔 Csatlakozzon a [Discord szerverünkhöz](https://discord.gg/ethereum-org) - -## Megfelelő első feladatok a hozzájárulás megkezdéséhez - -Ezek olyan jelenlegi feladatok, melyekbe besegíthet és felvállalhatja őket. Ehhez egy GitHub profilra lesz szükség, mert a változások nagy része azon keresztül zajlik. - - - -Tekintse meg az összes feladatot - -## Hogyan lehet az ethereum.org-on dolgozni {#how-to-update-content} - -Ha szeretne részt venni a [fordítási programban](/contributing/translation-program/), akkor hozzon létre egy [Crowdin](https://crowdin.com/project/ethereum-org) profilt. Minden máshoz, mint amilyen az új tartalom vagy vizualizáció, vagy a meglévő fejlesztése, hibajavítás, a meglévő feladatokon való munka, egy [GitHub](https://github.com/) profilra lesz szükség. - -Minden frissítés a GitHub PR folyamaton keresztül zajlik. Ez azt jelenti, hogy Ön készít a honlapról egy saját másolatot, végrehajtja a változtatásokat és megkéri, hogy azokat olvasszák be. Ha még nem csinált ilyet, akkor kövesse a [GitHub könvytár](https://github.com/ethereum/ethereum-org-website) alján lévő instrukciókat. - -Ehhez nincs szükség engedélyre, de mindenesetre tudassa velünk, hogy mit tervez. Ehhez: - -- Kommentáljon egy problémán vagy PR-on a [GitHub-ban](https://github.com/ethereum/ethereum-org-website) -- Küldjön üzenetet a [Discord szerveren](https://discord.gg/ethereum-org) - -Mielőtt nekilát, ismerkedjen meg: - -- az [ethereum.org fejlődő víziójával](/about/) -- a [tervezési elvekkel](/contributing/design-principles/) -- a [stílusútmutatóval](/contributing/style-guide/) -- a [viselkedési szabályzattal](/community/code-of-conduct) - - - -## Hogyan történik a döntéshozás a honlapról {#how-decisions-about-the-site-are-made} - -A PR-okról, dizájnfejlesztésről, főbb frissítésekről a döntéseket egy olyan csapat hozza, mely az Ethereum ökoszisztémához tartozik. Ebben a csapatban projekt menedzserek, fejlesztők, tervezők, marketingesek, kommunikációs szakemberek és szakértők vannak. Minden döntés alapja a közösségi input, ezért tegye fel a kérdését, adjon be PR-t vagy keresse meg a csapatot: - -- [website@ethereum.org](mailto:website@ethereum.org) -- [@ethdotorg](https://twitter.com/ethdotorg) -- [Discord szerver](https://discord.gg/ethereum-org) - -### Megjegyzés a plágiumról {#plagiarism} - -Amikor az ethereum.org tartalmához vagy alkotásaihoz hozzájárul, akkor csak a saját munkáját használja vagy azt, amire engedélye van. Az Ethereum ökoszisztéma számos projektje nyílt forráskódú licenccel működik, ami lehetővé teszi az információ ingyenes megosztását. Ugyanakkor, ha ezt az információt nem ismeri, akkor ne adja hozzá a honlaphoz az adott tartalmat. A plagizálásnak minősülő PR-okat elutasítjuk. - -## Most ismerkedik a nyílt forráskóddal? {#new-to-open-source} - -A GitHub könyvtárban megtalálja azokat a könnyen érthető feladatokat, melyeket az új fejlesztőknek szántunk, és elláttuk a [megfelelő első feladatok](https://github.com/ethereum/ethereum-org-website/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) címkével. - -## Kérje a láncon belüli eredménytokenjét (OAT) {#oat} - -Ha a munkáját beolvasztják az ethereum.org-ba, akkor kérhet egy különleges oklevelet a [Galxe-n](https://app.galxe.com/quest/ethereumorg) keresztül. A láncon belüli eredménytoken (OAT) egy tanúsítvány, hogy jobbá tette az ökoszisztémát. - -[Bővebben az OAT-okról](https://help.galxe.com/en/articles/7067290-galxe-oats-reward-and-celebrate-achievements) - -### Hogyan kell kérni -1. Csatlakozzon a [Discord szerverhez](https://discord.gg/ethereum-org). -2. Másolja be a közreműködését a ` #🥇 | proof-of-contribution` csatornába -3. Ezután csapatunk elküldi az OAT-hoz tartozó linket. -4. Szerezze meg az OAT-ot! - -Az OAT igényléséhez saját felügyeletű tárcát használjon. Ne használjon tőzsdei számlát vagy olyat, amelyhez nem rendelkezik privát kulccsal, mivel ezekkel nem lehet OAT-ot kezelni. - -## Igényeljen GitPOAP-ot {#claim-gitpoap} - -A GitPOAP automatikusan felismeri a beolvasztott hozzájárulást, és lehetővé teszi, hogy egy egyedi POAP-ot szerezzen a platformon! - - -### Hogyan kell kérni {#how-to-claim} - -1. Keresse fel a [GitPOAP](https://www.gitpoap.io) oldalt. -2. Kapcsolódjon a tárcájával vagy akár az e-mail-címével. -3. Használja GitHub felhasználói nevét, ETH-címét, ENS-nevét vagy bármilyen GitPOAP-ot, hogy a jogosultságát ellenőrizze. -4. Ha a GitHub-profilja jogosult, akkor készíthet magának egy GitPOAP-ot. - -## Hozzájárulók {#contributors} - - diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/faq/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/faq/index.md deleted file mode 100644 index 726ef1860ab..00000000000 --- a/public/content/translations/hu/27) Contributing/contributing/translation-program/faq/index.md +++ /dev/null @@ -1,119 +0,0 @@ ---- -title: Fordítási program – gyakran ismételt kérdések (GYIK) -lang: hu -description: Gyakran ismételt kérdések az ethereum.org fordítási programról ---- - -# Útmutató az ethereum.org fordításához {#translating-ethereum-guide} - -Ha Önnek új a fordítási program és még kérdései vannak, akkor az alábbi gyakran ismételt kérdések segíthetnek a kezdésben. Ez az útmutató segít választ kapni a legjellemzőbb kérdésekre. - -## Kaphatok jutalmat az ethereum.org fordításáért? {#compensation} - -Az ethereum.org egy nyílt forráskódú honlap, ezért bárki részt vehet és hozzájárulhat. - -Az ethereum.org fordítási program ennek kiterjesztése és ugyanilyen elveken működik. - -A fordítási program célja, hogy az Ethereumhoz kapcsolódó tartalom mindenki számára elérhető legyen, függetlenül az általa beszélt nyelvektől. Azt is lehetővé teszi, hogy a több nyelvet beszélők részt vehessenek az Ethereum ökoszisztémájában és hozzájáruljanak ahhoz. - -Ezért a fordítási program nyitott és önkéntes, nem jár érte külön jutalom. Ha a lefordított szavak után fizetni kellene a fordítóknak, akkor a fordítási programba csak profi fordítók vehetnének részt. Emiatt a program kizárólagos lenne, és nem érné el a célját, azt, hogy bárki bevonódhasson és részt vehessen az ökoszisztémában. - -Mindent megteszünk, hogy a hozzájárulók sikeresek legyenek az Ethereum ökoszisztémában; számos nem pénzügyi ösztönző létezik, mint a [POAP-ok](/contributing/translation-program/acknowledgements/#poap) és a [fordítói igazolás](/contributing/translation-program/acknowledgements/#certificate), továbbá a [Fordítói ranglista](/contributing/translation-program/acknowledgements/) és [a fordítók megjelenítése a honlapon](/contributing/translation-program/contributors/). - -## Hogyan kell lefordítani a sztringeket, melyekben `` található? {#tags} - -Nem minden sztring jelenik meg egyszerű szövegként. Bizonyos sztringek tartalmaznak HTML tagokat (`<0>`, ``).Ezek lényege a hiperlinkek beillesztése, illetve a formázás. - -- A tagek közötti szöveget fordítsa le, de a tagekat ne. A `<` és `>` zárójelek között ne fordítson és ne változtasson semmit. -- A sztring egységessége érdekében használja az eredeti másolása (Copy Source) gombot balra lent. Ez átmásolja az eredeti sztringet és beilleszti a szövegdobozba. Ezzel a tagek egyértelműen a helyükön lesznek, és így nem fog semmi hiányozni. - -![Crowdin interfész, ahol az eredeti másolása gomb ki van emelve](./html-tag-strings.png) - -A sztingen belül mozgathatja a tagek helyét, hogy a fordításnak megfelelő helyen álljanak - csak egyszerre mozgassa minden részét. - -A tagek és kódrészletek kezeléséről többet megtudhat az [ethereum.org Fordítási stílusútmutatóból](/contributing/translation-program/translators-guide/#dealing-with-tags). - -## Hol élnek a sztringek? {#strings} - -Az eredeti sztring néha nem elég ahhoz, hogy pontos fordítást tudjon adni. - -- Nézze meg a „képernyőképeket” és a „kontextust” a további információkért. Az eredeti sztring szekciójában látható a képernyőkép, mely megmutatja, hogy milyen szövegkörnyezetben helyezkedik el a sztring. -- Ha mégis bizonytalan lenne, jelezze azt a „komment szekcióban”. [Nem tudja, hogyan írjon kommentet?](#comment) - -![Megmutatja, hogyan látszik a kontextus egy sztringnél a képernyőkép segítségével](./source-string.png) - -![Egy példa képernyőkép a kontextusban](./source-string-2.png) - -## Hogyan írjak kommentet vagy kérdezzek? Szeretnék jelezni valami gondot vagy elírást... {#comment} - -Ha egy adott sztring kapcsán jelezni szeretne valamit, írjon kommentet. - -- Kattintson a második gombra a jobb fenti menüsorban. Jobb oldalon megjelenik egy rejtett lap. Írja meg kommentjét vagy kattintson a „probléma” (issue) dobozra alul a bejelöléséhez. Kiválaszthatja a probléma típusát a legördülő menüből. -- Amint elküldi, az megjelenik a csapatunknál. Kijavítjuk a problémát, válaszolunk Önnek a kommentjére és lezárjuk azt. -- Ha egy helytelen fordítást jelez, akkor az adott fordítás és az új javaslat a következő átnézés során egy olyan személyhez kerül, aki beszéli az adott nyelvet. - -![Hogyan lehet kommenteket és kéréseket létrehozni](./comment-issue.png) - -## Mi az a fordítói memória (TM)? {#translation-memory} - -A fordítói memória (TM) egy Crowdin funkció, mely eltárolja a korábban fordított [ethereum.org](http://ethereum.org/) sztringeket. A sztring fordításkor automatikusan bekerül a projekt TM-jébe. Ez egy hasznos eszköz lehet, mellyel időt spórolhat! - -- Tekintse meg a „TM- és MT-javaslatokat”, és láthatja, hogy mások hogyan fordították az adott vagy hasonló kifejezést. Ha talál egy nagy mértékben illeszkedő megoldást, akkor úgy használhatja fel azt, hogy rákattint. -- Ha a lista üres, akkor kereshet a TM-ben korábbi fordításokat, hogy konzisztensen legyenek adott kifejezések használva. - -![A fordítói memóriáról készült képernyőkép](./translation-memory.png) - -## Hogyan használjam a Crowdin szószedetet? {#glossary} - -Az Ethereum terminológia egy másik fontos része a fordító tevékenységnek, mivel a legtöbb új technikai kifejezés még nem rendelkezik helyi megfelelővel. Emellett bizonyos kifejezések mást jelentenek a különböző kontextusokban. [Bővebben az Ethereum terminológiafordításáról](#terminology) - -A Crowdin szószedet jó hely arra, hogy a kifejezéseket és definíciókat tisztázzuk. Kétféleképpen lehet a szószedetet használni. - -- Először is, ha alá van húzva egy kifejezés az eredeti sztringben, akkor vigye oda az egeret és láthatja a rövid meghatározását. - -![Egy példa a szószedetben lévő definícióra](./glossary-definition.png) - -- Másodszor, ha lát egy ismeretlen kifejezést, de az nincs aláhúzva, akkor kereshet a szószedetben (harmadik gomb a jobb oszlopban). Itt megtalálja bizonyos kifejezések magyarázatát, melyek gyakran szerepelnek a projektben. - -![Képernyőkép, hogy hol található a Crowdin-ban a szószedet](./glossary-tab.png) - -- Ha nem találja, akkor adja hozzá! Keresse meg azt egy keresőben, és adja hozzá a meghatározást a szószedethez. Ezzel segítheti a többi fordítót is, hogy jobban megértsék a kifejezést. - -![Képernyőkép, hogyan lehet a Crowdin-ben új elemet felvinni a szószedetbe](./add-glossary-term.png) - -### Terminológiafordítási szabályzat {#terminology} - -_A nevek (márkák, cégek, emberek) és az új technológiai kifejezések (Beacon-lánc, shard láncok stb.) kapcsán_ - -Az Ethereum számtalan új kifejezést használ, melyeket nemrég találtak ki. Néhány kifejezés másképp fog megjelenni minden fordítónál, mert nincsen rá egy megoldás az adott nyelven. Az ilyen inkonzisztenciák félreértést okozhatnak és rontják az olvashatóságot. - -A nyelvi sokszínűség és a különféle sztenderdizációk miatt szinte lehetetlen egységesen hozzáállni a terminológia fordításához, mely mindenre használható lenne. - -Ezért a leggyakrabban használt kifejezéseket a fordítókra bízzuk. - -A következőket javasoljuk, ha ismeretlen kifejezéssel találkozik: - -- Tekintse meg a [szószedetet](#glossary), hogy más fordítók hogyan kezelték azt. Ha úgy véli, hogy a korábbi megoldások nem megfelelők, akkor adja hozzá a saját verzióját a szószedethez. -- Ha a szószedetben nincs semmi, nézze meg egy keresőben vagy a cikkekben, hogy a saját közössége hogyan használja azt. -- Ha nem talál ilyen előfordulást, akkor bízzon az intuíciójában és javasoljon egy megoldást! -- Ha bizonytalan lenne, akkor hagyja fordítás nélkül az adott kifejezést. Néha az angol kifejezések kellőképpen hordozzák a kifejezés értelmét. - -A márkák, cégek és emberek neveit hagyja meg, mert zavarhoz és SEO-nehézségekhez vezethet. - -## Hogyan működik az átnézés? {#review-process} - -A fordítások minőségének és konzisztenciájának érdekében az [Acolad](https://www.acolad.com/) végzi az átnézést, ami világ szinten az egyik legnagyobb nyelvi szolgáltató. Az Acolad 20 000 profi nyelvésszel dolgozik, akik szakmai átnézést biztosítanak minden nyelvre és tartalomra. - -Az átnézés folyamata egyértelmű; amint egy adott [tartalommappa](/contributing/translation-program/content-buckets) 100%-ban le van fordítva, akkor arra az adagra megrendeljük az átnézést. Az átnézés a Crowdin platformon történik. Amint az átnézéssel végeztek, a lefordított tartalom megjelenik a honlapon. - -## Hogyan adhatok hozzá tartalmat a saját nyelvemen? {#adding-foreign-language-content} - -Jelenleg a nem angol nyelvű tartalom közvetlenül angolból van fordítva, ezért olyan szöveg nem adható hozzá egy adott nyelvhez, amely nem létezik angolul. - -Ha szeretne az ethereum.org-ra új tartalmat javasolni, akkor [nyisson egy kérést](https://github.com/ethereum/ethereum-org-website/issues) a GitHub-on. Ha ezzel egyetértenek, az új tartalom angolul készül el, és a Crowdin platformon lesz lefordítva minden más nyelvre. - -A jövőben a tervek szerint nem angol nyelvű tartalom is bekerülhet majd. - -## Kapcsolatfevétel {#contact} - -Köszönjük, hogy áttekintette a fentieket. Reméljük, hogy ez segít bekapcsolódni a programba. Csatlakozzon a [Discord fordítási csatornához](https://discord.gg/ethereum-org), hogy választ kapjon a kérdéseire, egyeztessen a többi fordítóval, vagy írjon nekünk a translations@ethereum.org címre! diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/how-to-translate/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/how-to-translate/index.md deleted file mode 100644 index 483e6474dfe..00000000000 --- a/public/content/translations/hu/27) Contributing/contributing/translation-program/how-to-translate/index.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Fordítási útmutató -lang: hu -description: Útmutató a Crowdin használatáról az ethereum.org fordítása kapcsán ---- - -# Fordítási útmutató {#how-to-translate} - -## Vizuális útmutató {#visual-guide} - -A vizuális tanulók tekintsék meg, ahogy Luka bemutatja a Crowdin használatát. Ugyanezeket a lépéseket találja meg írott formában alább. - - - -## Írott útmutató {#written-guide} - -### Csatlakozzon a projektünkhöz a Crowdin-ben {#join-project} - -Jelentkezzen be Crowdin-profiljába vagy készítsen egyet, ha még nem rendelkezik vele. A létrehozáshoz csak egy e-mail-címre és jelszóra lesz szüksége. - - - Csatlakozzon a projekthez - - -### Válassza ki a nyelvet {#open-language} - -Miután bejelentkezett a Crowdin-be, elolvashatja a projekt leírását és láthatja az elérhető nyelvek listáját. Minden nyelv információkat mutat arról, hogy mennyi lefordítandó szó van benne, mekkora tartalom van már lefordítva és jóváhagyva belőle. - -Nyissa meg a nyelvet, amelyre fordítani szeretne, így láthatja a fájlok listáját, melyek elérhetőek. - -![A nyelvek listája a Crowdin-ben](./list-of-languages.png) - -### Válasszon ki egy dokumentumot, amelyen dolgozni kíván {#find-document} - -A honlap tartalma fel van osztva dokumentumokra és tartalommappákra. A dokumentumok státuszát láthatja a jobb oldalon - ha a fordítási eredmény kisebb mint 100%, akkor segítsen be! - -Nem találja a nyelvet? [Nyisson egy kérést](https://github.com/ethereum/ethereum-org-website/issues/new/choose) vagy kérdezze meg a [Discord](/discord/) csatornán - -![A lefordított és még nem fordított fájlok a Crowdin-ban](./crowdin-files.png) - -Megjegyzés a tartalommappákról: ezekre azért van szükség Crowdin-ben, hogy a legfontosabb tartalom legyen kész a leghamarabb. Amikor megnyit egy nyelvet, például a [filipinót](https://crowdin.com/project/ethereum-org/fil#) , akkor tartalommappákat lát (1. Kezdőoldal, 2. Alapvető dolgok, 3. Felfedezés stb.). - -Kérjük, hogy fordítását ebben a sorrendben végezze (1 → 2 → 3 → ⋯), hogy a legfontosabb oldalak készüljenek el először. - -[Tudjon meg többet az ethereum.org tartalommappáiról](/contributing/translation-program/content-buckets/) - -### Fordítsás {#translate} - -Miután kiválasztotta a fordítani kívánt fájlt, az megnyílik az online szerkesztőben. Ha még nem használta a Crowdin-t korábban, ez az útmutató bemutatja az alapvető dolgokat. - -![A Crowdin online szerkesztője](./online-editor.png) - -**_1 – Bal oldali menü_** - -- Nincs lefordítva (piros) – olyan szöveg, amelyet még nem fordítottak le. Ezekkel a sztringekkel kell foglalkoznia. -- Le van fordítva (zöld) – ezeket a szövegeket már lefordították, de még nem lettek átnézve. Ezekhez javasolhat alternatív megoldásokat, vagy szavazhat a meglévőkre a szerkesztő + és - gombjaival. -- Jóváhagyott (pipa) – olyan szöveg, melyet átnéztek és már élőben látható a honlapon. - -A tetején található keresőben specifikus sztringeket is kereshet, illetve tud státusz alapján szűrni vagy átállítani a nézetet. - -**_2 – Szerkesztői terület_** - -A fő fordítási terület – a forrásszöveg felül jelenik meg, a releváns szövegkörnyezettel és képernyőképekkel, ha azok rendelkezésre állnak. A fordítás beviteléhez írja a szöveget az „Ide írja a fordítást” (Enter translation here) mezőbe és mentsen. - -A sztring meglévő fordításait és más nyelvekre való átültetését is itt láthatja, továbbá a fordítási memória találatai és a gépi fordítás javaslatai is itt jelennek meg. - -**_3 – Jobb oldali menü_** - -Itt találhatók a kommentek, a fordítási memória találatai és a szószedet tételei. Az alapnézet a kommenteket mutatja, ahol a fordítók kommunikálhatnak, jelezhetik a problémákat vagy a helytelen fordításokat. - -A tetején lévő gombokkal átválthat a fordítási memóriára, ahol a meglévő fordításokat találja, vagy megnézheti a szószedetet, mely a kulcsfogalmak definícióit és sztenderd fordításait mutatja. - -Szeretne többet megtudni? Tekintse meg a [dokumentációt a Crowdin online szerkesztőről](https://support.crowdin.com/online-editor/) - -### A fordítás átnézése {#review-process} - -Miután befejezte a fordítást (a tartalommappa összes fájlja 100%-ot mutat), a professzionális fordítási szolgáltatás ellenőrzi (és javítja) a tartalmat. Az átnézés után (vagyis az átnézés is 100%-ot mutat), bekerül a fordítás a honlapra. - - - Ne használjon gépi fordítást, az nem elfogadott. Minden fordítást átnézünk, mielőtt felkerülne a honlapra. Ha a javasolt fordításról kiderül, hogy gép végezte, akkor azokat elvetjük, és a gépi fordítást használó közreműködőket eltávolítjuk a projektből. - - -### Kapcsolatfevétel {#get-in-touch} - -Kérdése van? Vagy szeretne együttműködni a csapatunkkal és más fordítókkal? Írjon nekünk a #translations csatornán az [ethereum.org Discord szerveren](/discord/) - -Elérhet minket a translations@ethereum.org címen is - -Köszönjük, hogy részt vesz az ethereum.org fordítási programban! diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/index.md deleted file mode 100644 index f96ca43b5ca..00000000000 --- a/public/content/translations/hu/27) Contributing/contributing/translation-program/index.md +++ /dev/null @@ -1,90 +0,0 @@ ---- -title: Fordítási Program -lang: hu -description: Információk az ethereum.org fordítási programról ---- - -# Fordítási Program {#translation-program} - -A fordítási program egy közös erőfeszítés, hogy az ethereum.org mindenféle nyelvre le legyen fordítva, hogy a világon sok milliárdnyi nem angol anyanyelvű ember számára elérhetővé váljon. - -![](./enterprise-eth.png) - -## Segítsen a fordításban {#help-us-translate} - -Az ethereum.org fordítási program nyitott és bárki közreműködhet! - -1. Jelentkezzen be a Crowdin profiljába vagy regisztráljon. -2. Válassza ki a nyelvet, amelyre fordítani szeretne. -3. Mielőtt belekezd, tekintse meg a [fordítási útmutatót](/contributing/translation-program/how-to-translate/) a Crowdin használatának elsajátításához, valamint a [fordítási stílusútmutatót](/contributing/translation-program/translators-guide/) a tippek és bevált gyakorlatok érdekében. -4. A gépi fordítás nem elfogadható. -5. Minden fordítást átnéznek, mielőtt a honlapra felkerül, így a lefordított anyag bizonyos késéssel válik elérhetővé. - -_Csatlakozzon az [ethereum.org Discord](/discord/)-csatornájához, hogy megvitassa a fordítással kapcsolatos dolgokat, kérdezzen, visszajelzést adjon, megossza az ötleteit vagy csatlakozzon a fordítói csoporthoz._ - - - Kezdjen bele a fordításba - - -## A fordítási programról {#about-us} - -Az Ethereum-közösség célja, hogy globális és befogadó legyen, a tartalom nagy része ugyanakkor az angolul beszélőknek szól, ezzel kizárva a világ mintegy 6 milliárd nem angolul beszélő emberét. Ahhoz, hogy az ethereum.org legyen az Ethereumba vezető kapu egy világméretű közösség számára, a nem angolul beszélőknek a tartalmat anyanyelvükön szeretnénk átadni. - -Az ethereum.org fordítási program célja, hogy az Ethereum mindenkinek elérhető legyen, ezért az ethereum.org-ot és más Ethereum tartalmat a lehető legtöbb nyelvre le szeretnénk fordítani. - -Tudjon meg többet az ethereum.org fordítási program [missziójáról és víziójáról](/contributing/translation-program/mission-and-vision). - -### Eddigi eredményeink {#our-progress} - -- [**Több mint 6000** fordító](/contributing/translation-program/contributors/) -- **62** nyelv elérhető a honlapon -- [**3 millió** szó került lefordításra 2023-ban](/contributing/translation-program/acknowledgements/) - - - -### Köszönetnyilvánítások {#acknowledgements} - -Az ethereum.org-ot sok ezer közösségi tag fordítja, akik a fodítási program magját alkotják. Szeretnénk elismerni a fordítókat, és támogatni őket karrierjükben. Íme néhány elismerés a fordítóknak: - -#### Tanúsítvány {#certificate} - -Ha Ön közreműködött a fordítási programban és legalább 5000 szónyi fordítását jóváhagyták, akkor kérhet tanúsítványt. [Bővebben a tanúsítványokról](/contributing/translation-program/acknowledgements/#certificate) - -#### OAT-ok {#oats} - -A fodítási program résztvevői különféle OAT-okat (láncon belüli eredménytoken) kaphatnak a lefordított szavak száma alapján 2024-ben. Az OAT-ok olyan NFT-k, melyek igazolják a résztvételüket az ethereum.org fodítási programban. [Bővebben az OAT-okról](/contributing/translation-program/acknowledgements/#oats) - -#### Fordítói elismerések {#translator-acknowledgements} - -A legaktívabb fordítókat megjelenítjük a [ranglistákon](/contributing/translation-program/acknowledgements/), valamint az [összes közreműködőt is listázzuk](/contributing/translation-program/contributors/). - -#### Jutalmak {#rewards} - -Korábban visszamenőleg Ethereum-konferenciákra szóló jegyekkel jutalmaztuk a legaktívabb közreműködőket, mint amilyen a [Devcon](https://devcon.org/en/) és a [Devconnect](https://devconnect.org/), továbbá exkluzív ethereum.org ajándékokat kaptak. - -Folyamatosan törekszünk új és innovatív módon elismerni a résztvevőket, ezért mindenképpen maradjon velünk! - -### Útmutatók és anyagok {#guides-and-resources} - -Ha Ön is részt vesz a fodítási programban, vagy gondolkodik rajta, érdemes megnéznie az alábbi útmutatókat: - -- [Fordítási stílusútmutató](/contributing/translation-program/translators-guide/) _– instrukciók és tippek az ethereum.org fordítóinak_ -- [Fordítási GYIK](/contributing/translation-program/faq/) _– gyakran ismételt kérdések és válaszok az ethereum.org fordítási programjáról_ -- [Crowdin online szerkesztői útmutató](https://support.crowdin.com/online-editor/) _– részletes útmutató a Crowdin online szerkesztő és néhány haladóbb funkció használatáról_ -- [Tartalommappák](/contributing/translation-program/content-buckets/) _– az ethereum.org tartalommappáiba melyik oldalak tartoznak_ - -További hasznos fordítási eszközökért, fordítói közösségekért, illetve fordítási program blogbejegyzéseiért keresse fel az [Erőforrások oldalt](/contributing/translation-program/resources/). - -## Kapcsolatfevétel {#get-in-touch} - -Kérdése van? Vagy szeretne együttműködni a csapatunkkal és más fordítókkal? Írjon nekünk a #translations csatornán az [ethereum.org Discord szerveren](https://discord.gg/ethereum-org) - -Elérhet minket a translations@ethereum.org címen is - -## Kezdjen saját fordítási programba {#starting-a-translation-program} - -Arra törekszünk, hogy az Ethereum tartalom minél több nyelven olvasható legyen, és így az oktatási anyagok mindenki számára elérhetővé váljanak. Ezzel összhangban szeretnénk segíteni más Ethereum-projekteknek a saját fordításuk megszervezésében, kezelésében és fejlesztésében. - -Ezért létrehoztunk a [Fordítási program munkafüzetet](/contributing/translation-program/playbook/), amely tartalmazza azokat a tippeket és bevált gyakorlatot, amelyeket az ethereum.org fordítása során gyűjtöttünk. - -Szeretne közreműködni vagy használná a fordítási forrásokat? Van visszajelzése a munkafüzet kapcsán? Szívesen hallanánk róla a translations@ethereum.org címen. diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/mission-and-vision/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/mission-and-vision/index.md deleted file mode 100644 index 670ed406c52..00000000000 --- a/public/content/translations/hu/27) Contributing/contributing/translation-program/mission-and-vision/index.md +++ /dev/null @@ -1,25 +0,0 @@ ---- -title: Küldetés és vízió -lang: hu -description: Az ethereum.org fordítási program missziója és víziója ---- - -# Küldetés és vízió {#mission-and-vision} - -Az Ethereum-közösség célja, hogy globális és befogadó legyen, a tartalom nagy része ugyanakkor az angolul beszélőknek szól, ezzel kizárva a világ mintegy 6 milliárd nem angolul beszélő emberét. Ahhoz, hogy az ethereum.org legyen az Ethereumba vezető kapu egy világméretű közösség számára, a nem angolul beszélőknek a tartalmat anyanyelvükön szeretnénk átadni. - -Az ethereum.org fordítási program célja, hogy az Ethereum mindenkinek elérhető legyen, ezért az ethereum.org-ot és más Ethereum tartalmat a lehető legtöbb nyelvre le szeretnénk fordítani. - -## Küldetésünk {#our-mission} - -- Biztosítjuk a honlap lefordítását, hogy a világ bármely részéről érkező látogatók a saját nyelvükön ismerhessék meg az Ethereumot -- Segítjük, hogy bárki csatlakozhasson a globális Ethereum közösség tagjaihoz -- Elősegítjük az Ethereumról szóló információk és tudás könnyebb elérését és mindenkit felölelő megosztását -- Támogatjuk a közösség tagjait, hogy részt vegyenek az Ethereum lefordításában, és nyomot hagyjanak az ökoszisztémában -- Beazonosítjuk, kapcsolódunk és útmutatást adunk azoknak a lelkes közreműködőknek, akik részt szeretnének venni az ökoszisztémában - -## A jövőképünk {#our-vision} - -- Lefordítjuk a lényeges tartalmakat az Ethereum közösség tagjai számára, akik a világ lehető legtöbb országából és részéből származnak -- Támogatjuk a tudásmegosztást minden nyelven, hogy egy jól informált és tanult Ethereum közösség legyen -- Növeljük az Ethereumba való bevonást és annak elérhetőségét azzal, hogy a nyelvi akadályokat elhárítjuk, ami miatt az angolul nem beszélők esetleg ne tudjanak csatlakozni az ökoszisztémához diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/resources/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/resources/index.md deleted file mode 100644 index 8f448dde469..00000000000 --- a/public/content/translations/hu/27) Contributing/contributing/translation-program/resources/index.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Források a fordítóknak -lang: hu -description: Hasznos források az ethereum.org fordítóinak ---- - -# Források {#resources} - -Alább láthatja a hasznos útmutatókat és eszközöket az ethereum.org fordításához, továbbá fordítói közösségeket és híreket is találhat. - -## Útmutatók {#guides} - -- [Fordítási stílusútmutató](/contributing/translation-program/translators-guide/) _– instrukciók és tippek az ethereum.org fordítóinak_ -- [Fordítási GYIK](/contributing/translation-program/faq/) _– gyakran ismételt kérdések és válaszok az ethereum.org fordítási programjáról_ -- [Crowdin online szerkesztői útmutató](https://support.crowdin.com/online-editor/) _– részletes útmutató a Crowdin online szerkesztő és néhány haladóbb funkció használatáról_ -- [Tartalommappák](/contributing/translation-program/content-buckets/) _– az ethereum.org tartalommappáiba melyik oldalak tartoznak_ - -## Eszközök {#tools} - -- [Microsoft Language Portal](https://www.microsoft.com/en-us/language) _– megtalálhatja a technikai kifejezésekhez tartozó sztenderd fordításokat_ -- [Linguee](https://www.linguee.com/) _– fordításokhoz keresőmotor és szótár, mely szavak vagy kifejezések alapján is használható_ -- [Proz term search](https://www.proz.com/search/) _– adatbázis, melyben fordítói szótárak és speciális kifejezések szószedetei találhatók_ -- [Eurotermbank](https://www.eurotermbank.com/) _– európai kifejezések gyűjteménye 42 nyelven_ - -## Közösségek {#communities} - -- [Nyelvspecifikus Discord fordítói csoportok](/discord/) _– az ethereum.org fordítók összekapcsolása fordítói csoportokban_ -- [Kínai fordítói csoport](https://www.notion.so/Ethereum-org-05375fe0a94c4214acaf90f42ba40171) _– Notion oldal a kínai fordítók közötti koordinációhoz_ - -## Legfrissebb hírek {#latest-updates} - -A fordítási program legfrissebb híreihez tekintse meg az [Ethereum Alapítvány blogját](https://blog.ethereum.org/): - -- [2021. október – mérföldkövek frissítése](https://blog.ethereum.org/2021/10/04/translation-program-update/) -- [2020. december – mérföldkövek frissítése](https://blog.ethereum.org/2020/12/21/translation-program-milestones-updates-20/) -- [2020. július – mérföldkövek frissítése](https://blog.ethereum.org/2020/07/29/ethdotorg-translation-milestone/) -- [2019. augusztus – a fordítási program bevezetése](https://blog.ethereum.org/2019/08/20/translating-ethereum-for-our-global-community/) - -## Fogadóóra a fordítóknak {#office-hours} - -Minden hónap második szerdáján tartunk fogadóórát a fordítóknak. Az #office-hours voice channel az [ethereum.org Discord](/discord/) csatornáján található, ahol pontos időpontokat és további részleteket is talál. - -A fogadóórák során a fordítók kérdezhetnek, visszajelzést adhatnak, megoszthatják elképzeléseiket, és beszélgethetnek az ethereum.org csapatával. Ezeket a megbeszéléseket arra is használjuk, hogy a legújabb dolgokat megosszuk a fordítási program kapcsán, illetve a fontos tippeket és útmutatásokat átadjuk a közreműködőknek. - -Csatlakozzon, amennyiben Ön is az ethereum.org fordítója vagy szeretne az lenni. diff --git a/public/content/translations/hu/27) Contributing/contributing/translation-program/translators-guide/index.md b/public/content/translations/hu/27) Contributing/contributing/translation-program/translators-guide/index.md deleted file mode 100644 index 6682ee378d9..00000000000 --- a/public/content/translations/hu/27) Contributing/contributing/translation-program/translators-guide/index.md +++ /dev/null @@ -1,293 +0,0 @@ ---- -title: Fordítási útmutató -lang: hu -description: Instrukciók és tippek az ethereum.org fordítóinak ---- - -# Ethereum.org fordítási stílusútmutató {#style-guide} - -Az ethereum.org fordítási stílusútmutató a legfontosabb iránymutatásokat, instrukciókat és tippeket tartalmazza a fordítók számára, hogy a honlapot helyi nyelveken tudjuk megjeleníteni. - -Ez egy általános útmutató, nem nyelvspecifikus. - -Ha bármilyen kérdése, javaslata vagy visszajelzése van, írjon nekünk a translations@ethereum.org-ra, üzenjen a @ethdotorg-ra a Crowdin-ban, vagy [csatlakozzon a Discord](https://discord.gg/ethereum-org) csatornához, ahol üzenhet a #translations beszélgetésben. - -## A Crowdin használata {#using-crowdin} - -A [fordítási program oldalon](/contributing/translation-program/#how-to-translate) találhat alapvető instrukciókat arról, hogyan csatlakozzon a Crowdin-ban a projekthez és hogyan kell az online szerkesztőt használni. - -Ha többet szeretne megtudni a Crowdin-ről és a haladóbb funkcióiról, akkor a [Crowdin tudástárban](https://support.crowdin.com/online-editor/) minden funkcióról részletes útmutatókat és áttekintéseket találhat. - -## Az üzenet lényegének megragadása {#capturing-the-essence} - -Amikor az ethereum.org tartalmát fordítja, ne ragaszkodjon a szó szerinti átültetéshez. - -Az üzenet lényegét ragadja meg. Ehhez talán át kell fogalmazni bizonyos mondatokat, vagy leírást kell alkalmazni a szavankénti fordítás helyett. - -A különféle nyelvek eltérő nyelvtani szabályokkal, konvenciókkal és szórenddel bírnak. A fordításnál vegye figyelembe a célnyelv logikáját, és ne ragaszkodjon az angol stuktúrájához, mert ennek gyenge megfogalmazás és olvashatóság lesz a következménye. - -Olvassa el az egész mondatot, és alakítsa úgy, hogy az a célnyelvnek megfeleljen. - -## Magázás vagy tegezés {#formal-vs-informal} - -Magázást használunk, mert az mindig udvarias és minden látogatónak megfelel. - -Ilyen megfogalmazással elkerülhetők a nem hivatalosnak vagy támadónak hangzó kifejezések, és a látogatók korától és nemétől függetlenül mindig alkalmas. - -A legtöbb indoeurópiai és afro-ázsiai nyelv nemspecifikus második személyű személyes névmásokat használ, amelyek megkülönböztetik a férfiakat és a nőket. A felhasználó megszólításakor vagy a birtokos névmások használatakor elkerülhetjük a látogató nemének feltételezését, mivel a formális megszólítási forma általánosan alkalmazható és következetes, függetlenül attól, hogy a látogató hogyan azonosítja magát. - -## Egyszerű és tiszta szóhasználat és jelentés {#simple-vocabulary} - -Az a célunk, hogy a honlapon lévő tartalom mindenki számára érthető legyen. - -Ez könnyen elérhető rövid és egyszerű szavak használatával. Ha több szó is rendelkezésre áll az adott nyelven, akkor a legjobb a legrövidebb kifejezés, amely visszaadja a jelentést. - -## Írásrendszerek {#writing-system} - -Az ethereum.org számos nyelven elérhető a latinhoz képest eltérő írásrendszerek (vagy írásjelek) használatával. - -A tartalom az adott nyelvnek megfelelő írásrendszeren kell megjelenjen, és ne tartalmazzon latin írásjeleket. - -A tartalom átültetésénél biztosítani kell, hogy a fordítás konzisztens legyen és nem tartalmazzon latin írásjeleket. - -Általános félreértés, hogy az Ethereum kifejezéseinek latin írásjelekkel kell megjelennie. Ez nem helyes, inkább a kiejtését használjuk minden helyi nyelven (például 以太坊 kínaiul, إيثيريوم arabul stb.). - -**Ez természetesen nem alkalmazható azokra a nyelvekre, ahol a tulajdonneveket nem fordítják le.** - -## Az oldal metaadatának fordítása {#translating-metadata} - -Néhány oldal tartalmaz metaadatokat, mint „title”, „lang”, „description”, „sidebar” stb. - -A Crowdin-ban el van rejtve az a szöveg, melyet nem kell lefordítani, tehát a látható metaadatokhoz is megfelelő fordításra van szükség. - -Legyen körültekintő, amikor a forrásszöveg „en” jelöléssel szerepel. Ez mutatja, hogy az oldal milyen nyelven elérhető, és a [helyi nyelv ISO-nyelvikódjára](https://www.andiamo.co.uk/resources/iso-language-codes/) kell fordítani. Ezeket a sztringeket latin írásjelekkel kell írni, nem más írásrendszerrel. - -A nyelvi kódokhoz nézze meg a Crowdin fordítási memóriáját, vagy az online szerkesztőben is láthatja az oldal URL-jében. - -Néhány példa a nyelvi kódokra: - -- Arab - ar -- Egyszerűsített kínai - zh -- Francia - fr -- Hindi - hi -- Spanyol - es - -## Külsős cikkek címei {#external-articles} - -Néhány sztring külsős cikkek címeit is tartalmazza. A legtöbb fejlesztői dokumentáció ajánl további olvasmányokat külsős cikkek formájában. Ezeket a címeket le kell fordítani a helyi nyelvre, hogy a látogató konzisztens módon tudja elolvasni a szöveget. - -Alább talál néhány példát arra, hogyan néznek ki ezek a sztringek, hogyan lehet ezeket azonosítani (a cikkekre mutató hivatkozások az oldalak alján, a További olvasnivalók részben találhatók): - -![Cikkcímek az oldalsó menüben](./article-titles-in-sidebar.png) ![Cikkcímek a szerkesztőben](./article-titles-in-editor.png) - -## Crowdin figyelmeztetések {#crowdin-warnings} - -A Crowdin beépített funkciója, hogy hibák esetén jelez a fordítónak. Automatikus figyelmeztet mentés előtt, ha lemaradt egy tag a forrás szerint, ha olyan elemet fordított le, melyet nem szabad, ha több szóköz van valahol, hiányzik a mondat végén az írásjel stb. Amikor ilyen figyelmeztetést lát, kérjük, hogy nézze meg még egyszer a fordítását. - -**Ezek mindig azt jelzik, hogy valami eltérés van vagy fontos rész hiányzik.** - -Így néz ki egy Crowdin figyelmeztetés, ha lemarad egy tag: ![Példák a Crowdin figyelmeztetéseire](./crowdin-warning-example.png) - -## Tagek és kódrészletek kezelése {#dealing-with-tags} - -Számos szöveg tartalmaz tageket és variánsokat, amelyeket a szerkesztőben sárgával láthatunk. Ezeknek funkciójuk van, ezért megfelelően kell kezelni őket. - -**Crowdin-beállítások** - -A tagek kezeléséhez és másolásához azt javasoljuk, hogy változtassa meg a beállítását. - -1. Beállítások megnyitása ![Hogyan kell a beállításokat megnyitni a szerkesztőben](./editor-settings.png) - -2. Gördítsen le a HTML-tagek megjelenítése pontig - -3. „Elrejtés” kiválasztása![Válassza ki az „Elrejtés” lehetőséget](./hide-tags.png) - -4. Kattintson a „Mentés” lehetőségre - -Ebben az eseten nem a teljes tag látszik, hanem egy szám lesz a helyén. A fordításnál ezekre a tagekre kattintva a teljes hivatkozást átmásolja a fordítói mezőbe. - -**Hivatkozások** - -Teljes hivatkozásokat is találhat az ethereum.org vagy más honlapokra vonatkozóan. - -Ezek maradjanak azonosak a forrással, ne változtassa meg őket. Ha bármit változtat a hivatkozásokon, akár egy perjelet is kivesz, akkor azok használhatatlanná válnak. - -A hivatkozásokat másolja át egyenesen a forrásból, kattintson rájuk vagy használja a „forrás másolása” (copy source) gombot (Ctrl+Shift+C). - -![Example of link.png](./example-of-link.png) - -A hivatkozások tagekkel formázva is megjelennek a forrásszövegben (vagyis <0> ). Ha a tagek fölé mozgatja a kurzort, akkor megnézheti a tartalmát - ezek sokszor hivatkozásokat tartalmaznak. - -A hivatkozásokat mindig másolja át a forrásból, ne változtassa meg a sorrendjüket. - -Ha a tagek megváltoznak, akkor az általuk képviselt hivatkozások használhatatlanok lesznek. - -![Example of links inside tags.png](./example-of-links-inside-tags.png) - -**Tagek és variánsok** - -A forrás sokféle taget tartalmaz, melyeket mindig másoljon át a forrásból. A sorrendjük is maradjon a forrásnak megfelelő. - -A tageknél mindig van nyitó és zárótag. Az ezek közé eső szöveget általában le kell fordítani. - -Például: ``Decentralizált`` - -`` - _Ez egy nyitótag, melytől félkövér lesz a szöveg_ - -Decentralizált - _Fordítandó szöveg_ - -`` - _Zárótag_ - -![Example of 'strong' tags.png](./example-of-strong-tags.png) - -A kódrészleteket másképp kell megközelíteni, mert ezek kódot tartalmaznak és nem szabad lefordítani. - -Például: ``nonce`` - -`` - _Nyitótag, melyben egy kódrészlet van_ - -nonce - _Nem fordítható szöveg_ - -`` - _Zárótag_ - -![Example of code snippets.png](./example-of-code-snippets.png) - -A forrás tartalmaz rövidített tagokat is, melyek csak számként jelennek meg, a tartalmuk nem egyértelmű ránézésre. Ha a kurzort fölé mozgatjuk, akkor látszik, hogy mit tartalmaznak. - -Az alábbi példában látszik, hogy a kurzort odamozgatva <0> azt mutatja, hogy `` és egy kódrészletet tartalmaz, így azt nem kell lefordítani. - -![Example of ambiguous tags.png](./example-of-ambiguous-tags.png) - -## Rövid és hosszú alakok/rövidítések {#short-vs-full-forms} - -Számos rövidítést használunk a honlapon, például dapp-ok, NFT, DAO, DeFi stb. Ezek elfogadott rövidítések az angolban és a legtöbb felhasználó számára ismerősek. - -Mivel ezeknek nem létezik más nyelvre való átültetése, ezért a legjobb módszer egy leíró fordítás használata, mely mellé bekerül zárójelbe az eredeti rövidítés. - -Ne fordítsa le a rövidítést, mert nem fogják felismerni a felhasználók és a helyi megoldás nem lesz számukra ismerős. - -Például a dapp-ok fordítása: - -- Decentralizált alkalmazások (dapp-ok) → _Teljes formában lefordítva (angol rövidítés zárójelben)_ - -## Kifejezések, melyekre nincs bevett fordítás {#terms-without-established-translations} - -Bizonyos kifejezéseknek nincs bevett fordítása az adott nyelven, és inkább angolul ismeri mindenki. Az ilyen kifejezések sokszor új koncepciókat fednek le, mint a proof-of-work, proof-of-stake, Beacon-lánc, staking stb. - -Bár a fordítás furcsán hathat, mégis érdemes lenne átültetni ezeket a helyi nyelvre. - -A fordításnál legyen kreatív, írja körül vagy egyszerűen írja át a saját nyelvére. - -**Azért érdemes lefordítani a helyi nyelvre és nem angolul használni, mert a jövőben ez az új terminológia sokkal elterjedtebb lesz, ahogy sokan kezdik el használni az Ethereumot és a kapcsolódó technológiákat. Az új emberek bevonásához érthető terminológiára van szükség minden nyelven, még ha azt nekünk is kell kitalálni.** - -## Gombok és CTA-k {#buttons-and-ctas} - -A honlapon számos gomb található, melyet másképpen kell lefordítani. - -A gomb szövegét úgy lehet beazonosítani, hogy a kontextusban található képernyőképen látható, vagy a szerkesztőben a „button” kifejezéssel szerepel. - -A fordítás legyen a lehető legrövidebb, hogy ne okozzon gondot a formázásnál. Emellett legyen felszólító módban, vagyis egy utasítást vagy kérést tükrözzön. - -![Hogyan lehet felismerni a gombot](./how-to-find-a-button.png) - -## Fordítás a befogadás szellemében {#translating-for-inclusivity} - -Az ethereum.org látogatói a világ minden tájáról jönnek és különféle háttérrel rendelkeznek. Ezért a honlap nyelve legyen semleges, mindenkit befogadó, nem kizáró jellegű. - -Ennek fontos szempontja a nemi semlegesség. Ehhez a formális megszólításokat érdemes használni, és elkerülni a nemre utaló kifejezéseket a fordításban. - -A bevonás másik szempontja a globális közönség figyelembe vétele, amely nem szűkül le semelyik országra, fajra vagy régióra. - -Végül a nyelve legyen megfelelő mindenféle közönségnek és korosztálynak. - -## Nyelvspecifikus fordítások {#language-specific-translations} - -A fordítás közben ügyeljen arra, hogy az adott nyelv nyelvtani szabályait, konvencióit és formázását kövesse, ne a forrást vegye figyelembe. A forrásszöveg az angol szabályokat követi, melyek nem feltétlen alkalmazhatók más nyelveknél. - -Ismerje és használja a saját nyelvének szabályait megfelelő módon. Ha segítségre van szüksége, akkor jelezze, és megpróbálunk információkat találni az adott nyelv szabályairól. - -Néhány példa, hogy mire kell különösen odafigyelni: - -### Írásjelek, formázás {#punctuation-and-formatting} - -**Nagybetüs írásmód** - -- A nagybetüs írásmód jelentősen eltér a különféle nyelvekben. -- Az angolban minden címet és nevet, a hónapokat és napokat, a nyelvek neveit, az ünnepeket stb. mind nagybetűvel írják. Más nyelvekben ez hibásnak minősül, mert más szabályokat követnek. -- Máshol jellemző a személyes névmások, főnevek és bizonyos melléknevek nagybetűvel való írása, ami az angolban másképp van. - -**Szóközhasználat** - -- A helyesírási szabályok megadják az adott nyelv szóközhasználatát. Mivel szóközt mindenhol használunk, ezért ezek a szabályok a legkülönfélébbek és könnyű elrontani a fordításban. -- Néhány jellemző különbség az angol és más nyelvek között: - - Szóköz a mértékegységek és valuták előtt (pl. USD, EUR, kB, MB) - - Szóköz a hőfokot jelző jel előtt (pl. °C, ℉) - - Szóköz néhány írásjel előtt, mint a szókihagyás (…) - - Szóköz a perjel (/) előtt és után - -**Listák** - -- Minden nyelvben eltérő szabályok vonatkoznak a listák írására. Melyek jelentősen eltérhetnek az angoltól. -- Néhány nyelvben az első szót nagybetűvel kell írni, máshol kisbetűvel kezdik. Számos nyelvben más szabály van a nagybetűvel való írásra attól függően, hogy milyen hosszúak a sorok. -- Ez igaz a mondatvégi írásjelekre is. A lista végén lehet pont (**.**), vessző (**,**) vagy pontosvessző (**;**) a nyelvtől függően. - -**Idézőjelek** - -- A nyelvek másféle idézőjeleket használnak. Az angol átmásolása általában nem helyes. -- A leggyakoribb példák: - - „példaszöveg“ - - ‚példaszöveg’ - - »példaszöveg« - - “példaszöveg” - - ‘példaszöveg’ - - «példaszöveg» - -**Kötőjelek és gondolatjelek** - -- Az angolban a kötőjelet (-) arra használják, hogy szavakat vagy szórészeket kapcsoljanak össze, miközben a gondolatjel (–) inkább tartományt vagy megállást jelöl. -- Sok nyelvben eltérő a használata a kötőjelnek és a gondolatjelnek, melyet figyelembe kell venni. - -### Formátumok {#formats} - -**Számok** - -- A számok írásában a legnagyobb eltérés a decimális és az ezres elválasztás jelölése. Az ezres elválasztás lehet pont, vessző vagy szóköz. Ehhez hasonlóan néhány nyelv pontot használ a decimálisnál, mások vesszőt. - - Néhány példa: - - Angol – **1,000.50** - - Spanyol – **1.000,50** - - Francia – **1 000,50** -- Másik fontos megfontolás lehet a százalékjel használata. Különféle módokon lehet írni: **100%**, **100 %** vagy **%100**. -- Végül a negatív számok írásmódja is eltérhet a nyelvtől függően: -100, 100-, (100) vagy [100]. - -**Dátumok** - -- A dátumok írásánál számos dolgot figyelembe kell venni a nyelvi eltérések miatt. A dátum formátuma, elválaszás, nagybetű használata és kezdő nullák használata. Különbség van a teljes hosszúságú és a számokkal írt dátum között is. - - Néhány példa a dátumformátumokra: - - Angol UK (dd/mm/yyyy) – 1st January, 2022 - - Angol US (mm/dd/yyyy) – January 1st, 2022 - - Kínai (yyyy-mm-dd) – 2022 年 1 月 1 日 - - Francia (dd/mm/yyyy) – 1er janvier 2022 - - Olasz (dd/mm/yyyy) – 1º gennaio 2022 - - Német (dd/mm/yyyy) – 1. Januar 2022 - -**Pénznemek** - -- A pénznemek fordítása nehézsége okozhat a különféle formátumok, konvenciók és átváltások miatt. Általános szabályként hagyjuk meg az eredeti szövegben lévő pénznemet. Az olvasó kedvéért hozzátehetjük zárójelben a helyi pénznemet és átváltást. -- Az írásbeli eltérés a szimbólumok elhelyezésében, a decimális jelölőkben, a szóközben, rövidítésekben vagy szimbólumok használatában áll. - - Szimbólum elhelyezése: $100 vagy 100$ - - Decimális vessző vagy pont: 100,50$ vagy 100.50$ - - Szóközhasználat: 100$ vagy 100 $ - - Rövidítések vagy szimbólumok: 100 $ vagy 100 USD - -**Mértékegységek** - -- Általános szabályként hagyjuk meg az eredeti szövegben lévő mértékegységeket. Ha más rendszert használ egy adott ország, akkor zárójelben meg lehet mutatni azt is. -- A helyi használat mellett vannak más eltérések is a nyelveknél. A fő különbség a szóközhasználat a szám és a mértékegység között van, mely eltérhet nyelvenként. Például 100kB vagy 100 kB, 50ºF vagy 50 ºF. - -## Következtetés {#conclusion} - -Az ethereum.org fordítása remek lehetőség arra, hogy az Ethereum különféle aspektusait megismerjük. - -A fordítás során próbáljon meg nem sietni. Élvezze a folyamatot, leljen benne örömet! - -Köszönjük, hogy részt vesz a fordítási programban, s lehetővé teszi, hogy a honlap mások számára is elérhető legyen. Az Ethereum közössége globális, örülünk, hogy Ön is a tagja! diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-desci-projects/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-desci-projects/index.md deleted file mode 100644 index 8906c876f09..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/adding-desci-projects/index.md +++ /dev/null @@ -1,44 +0,0 @@ ---- -title: DeSci projektek hozzáadása -description: Az az irányelv, amelyet követünk, amikor hivatkozást adunk hozzá a projektekhez a DeSci oldalon az ethereum.org webhelyen -lang: hu ---- - -# Projektek hozzáadása {#adding-projects} - -Szeretnénk biztosítani, hogy különböző projekteket mutassunk be, és jó áttekintést nyújtsunk a DeSci tájékozódásáról. - -Bárki szabadon javasolhat egy projektet, amelyet felsorolhatnak a DeSci oldalon az ethereum.org webhelyen. Ugyanúgy, bárki, aki észrevesz egy olyan projektet, amely már nem releváns, vagy nem felel meg a jogosultsági feltételeinknek, szabadon javasolhatja annak eltávolítását. - -## A döntési keretrendszer {#the-decision-framework} - -### A feltüntetés kritériumai: kötelezők {#the-must-haves} - -- **Nyílt forráskód/adat** - A kód és az adatok nyitottsága alapvető DeSci-elv, így a DeSci-projektek nem lehetnek zárt forráskódúak. A kódbázisnak hozzáférhetőnek kell lennie, és ideális esetben nyitottnak a pull requestek számára PR. -- **A DeSci projekteknek láthatóan decentralizáltnak kell lenniük** - Ehhez tartozhat egy DAO általi irányítás, vagy egy decentralizált technológiai rendszer felhasználása, ideértve a nem tároló pénztárcákat is. Valószínűleg az Ethereumon auditálható okosszerződéseket foglal magában. -- **Őszinte és pontos listázási információk** - A projektek által javasolt tételek őszinte és pontos információkkal érkezzenek. Azokat a termékeket eltávolítjuk, melyek hamis információkat adnak meg a listázáshoz, például a nyílt forráskódú megjelölés, amikor a kód nem érhető el. -- **Megmutatható elkötelezettség a tudományhoz való szélesebb hozzáférés mellett** - A DeSci-projekteknek képesnek kell lenniük megfogalmazni, hogyan bővíti ki a részvételt a tudományban a nagyközönség számára, nem csak a token-/NFT-tulajdonosoknak. -- **Világszerte elérhető** - A projektnek ne legyen földrajzi korlátozása vagy olyan „ismerd meg ügyfeled” (KYC) követelménye, amely kizár bizonyos embereket a szolgáltatás eléréséből. -- **Informatív weboldal és dokumentáció** - Fontos, hogy a projekt weboldalát látogatók megértsék, hogy a projekt valójában mit csinál, hogyan járul hozzá a tudomány infrastruktúrájának decentralizációjához, és hogyan lehet részt venni benne. -- **A projektnek az Ethereum ökoszisztémája részének kell lennie** - Az ethereum.org-nál úgy véljük, hogy az Ethereum (és annak Layer 2 megoldásai) megfelelő alapréteget jelentenek a DeSci-mozgalom számára. -- **A projekt elég jól kialakult** - A projektnek valós felhasználói vannak, akik hosszú hónapok óta hozzáférhetnek a projekt szolgáltatásaihoz. - -### Jó, ha van - -- **Több nyelven elérhető** - A projekt le van fordítva több nyelvre, lehetővé téve a világ minden tájáról származó felhasználók számára az elérését. -- **Oktatási források** - A terméknek jól kidolgozott bevezető élménnyel kell rendelkeznie, hogy segítse és oktassa a felhasználókat. Vagy legyenek elérhető cikkek vagy videók arról, hogyan kell azt használni. -- **Harmadik fél által végzett auditok** - A termékét egy megbízható harmadik fél szakemberei vizsgálták sebezhetőségek szempontjából. -- **Kapcsolattartási pont** - Egy kapcsolattartási pont a projekt számára (ez lehet egy DAO vagy közösség képviselője) nagyban segíti a pontos információk beszerzését a változások esetén. Ezzel az ethereum.org frissítése könnyebb, amikor a jövőben információt kell szerezni. - -## Karbantartás {#maintenance} - -Mivel az Ethereum természete gyorsan alakul, a csapatok és a termékek jönnek-mennek, és naponta történnek innovációk, ezért rutinszerűen ellenőrizzük a tartalmakat: - -- Győződjön meg arról, hogy az összes felsorolt projekt továbbra is teljesíti a kritériumainkat -- Ellenőrizze, hogy nincsenek-e olyan termékek, amelyek a jelenlegiekhez képest jobban megfelelnek a kritériumoknak - -Az ethereum.org-ot a nyílt forráskódú közösség tartja fenn, és így a közösségre támaszkodik ahhoz, hogy aktuális információkat mutasson. Ha észrevételeket tesz bármely felsorolt projekt információjával kapcsolatban, ami frissítésre szorul, kérjük, nyisson egy issuel-t vagy pull requestet a GitHub tárolónkban. - -## Felhasználási feltételek {#terms-of-use} - -Tekintse meg [használati feltételeinket](/terms-of-use/). Az ethereum.org-on található információk általános tájékoztatásul szolgálnak. diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-developer-tools/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-developer-tools/index.md deleted file mode 100644 index 7de5321e7b7..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/adding-developer-tools/index.md +++ /dev/null @@ -1,61 +0,0 @@ ---- -title: Fejlesztőeszközök hozzáadása -lang: hu -description: A fejlesztőeszközök felsorolásának kritériumai az ethereum.org weboldalon ---- - -# Fejlesztőeszközök hozzáadása {#contributing-to-ethereumorg-} - -Szeretnénk biztosítani, hogy a lehető legjobb fejlesztői erőforrásokat soroljuk fel, hogy az emberek magabiztosan építhessenek és rendelkezzenek a szükséges támogatással. - -Ha van olyan hasznos fejlesztői eszköz, amit elmulasztottunk, nyugodtan javasolja egy megfelelő helyen. - -Jelenleg a fejlesztőeszközöket a [fejlesztői portálunkon](/developers/) keresztül soroljuk fel. - -**Nyugodtan javasoljon új hozzáadásokat a megfelelő oldalakhoz.** - -## Hogyan döntünk {#ways-to-contribute} - -A fejlesztőeszköz-beküldéseket az alábbi kritériumok alapján értékeljük ki: - -**Jelentős mértékben különbözik-e a már felsorolt eszközöktől?** - -- Új kategóriák vagy típusú eszközök -- Új funkciók azonos típusú meglévő eszközökhöz képest -- Egy olyan felhasználási esetet célzott meg, amit a meglévő hasonló eszközök nem fednek le - -**Jól dokumentált-e az eszköz?** - -- Létezik dokumentáció? -- Elegendő-e az eszköz használatához? -- Frissítették-e az utóbbi időben? - -**Széles körben használták-e az eszközt?** - -- Fontolóra vesszünk olyan mutatókat, mint a GitHub csillagok, letöltési statisztikák, és azt, hogy ismert vállalatok vagy projektek használják-e - -**Megfelelő minőségű az eszköz?** - -- Vannak visszatérő hibák? -- Megbízható az eszköz? -- Aktívan karbantartják az eszközt? - -**Az eszköz nyílt forráskódú?** - -Az Ethereum térben sok projekt nyílt forráskódú. Valószínűbb, hogy olyan nyílt forráskódú projekteket sorolunk fel, amelyek lehetővé teszik a közösségi fejlesztők számára, hogy megvizsgálják a kódot, és hozzájáruljanak ahhoz. - ---- - -## Termékrendelés {#product-ordering} - -Hacsak a termékeket kifejezetten másként nem rendelték meg, például ábécé sorrendben, a termékek a lekorábbitól a legújabbig jelennek meg az oldalon. Más szóval, a legújabb termékek a lista aljára kerülnek. - ---- - -## Adjon hozzá fejlesztői eszközt {#how-decisions-about-the-site-are-made} - -Ha egy fejlesztői eszközt szeretne hozzáadni az ethereum.org-hoz, és az megfelel a feltételeknek, hozzon létre egy issue-t a GitHubon. - - - Issue létrehozása - diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-exchanges/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-exchanges/index.md deleted file mode 100644 index ea9ca0f12c2..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/adding-exchanges/index.md +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: Cserék hozzáadása -description: Az az irányelv, amelyet akkor használunk, amikor cseréket adunk hozzá az ethereum.org webhelyhez -lang: hu ---- - -# Ethereum cserék hozzáadása {#adding-ethereum-exchanges} - -Bárki szabadon javasolhat új cseréket az ethereum.org oldalon. - -Jelenleg ezeket soroljuk fel: - -- [ethereum.org/get-eth anyagai](/get-eth/) - -Ezen az oldalon a felhasználó megadhatja, hol él, és megnézheti, milyen cseréket használhat. Ez segít a földrajzi korlátozások korai feltárásában. - -Emiatt a kontextus miatt szükségünk van néhány konkrét információra, amikor cserét javasol. - -**MEGJEGYZÉS:** Ha decentralizált tőzsdét szeretne listázni, tekintse meg a [pénztárcák és dapps listára vonatkozó irányelveinket ](/contributing/adding-products/). - -## Amire szükségünk van {#what-we-need} - -- A cserére vonatkozó földrajzi korlátozások. A tőzsdéhez kapcsolódó földrajzi korlátozásokat részletezni kell a tőzsde webhelyének erre a célra szolgáló oldalán vagy szakaszában. -- Azok a pénznemek, amelyekkel a felhasználók ETH-t vásárolhatnak -- Annak bizonyítéka, hogy a tőzsde törvényes kereskedelmi társaság -- Bármilyen további információ, amivel rendelkezhet – ezek lehetnek a céggel kapcsolatos információk, például a működési évek, a pénzügyi háttér stb. - -Erre az információra azért van szükségünk, hogy pontosan [segíthessünk a felhasználóknak olyan tőzsdét találni, amelyet használhatnak](/get-eth/#country-picker). - -És azért, hogy az ethereum.org még biztosabb legyen abban, hogy a csere legitim és biztonságos szolgáltatás. - ---- - -## Adjon hozzá cserét {#add-exchange} - -Ha cserét szeretne hozzáadni az ethereum.org webhelyhez, hozzon létre egy issue-t a GitHubon. - - - Issue létrehozása - diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-glossary-terms/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-glossary-terms/index.md deleted file mode 100644 index 5d304d76bfc..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/adding-glossary-terms/index.md +++ /dev/null @@ -1,26 +0,0 @@ ---- -title: Kifejezések hozzáadása a szószedethez -lang: hu -description: Kritériumaink új kifejezések hozzáadásához az ethereum.org szószedethez ---- - -# Kifejezések hozzáadása a szószedethez {#contributing-to-ethereumorg-} - -Ez a tér minden nap változik. Folyamatosan új kifejezések kerülnek be az Ethereum-felhasználók lexikonjába, és szükségünk van a segítségére, hogy pontos, naprakész referenciát biztosíthassunk minden Ethereum-hoz. Nézze meg az aktuális [szószedetet](/glossary/), és tekintse meg az alábbiakat, ha segíteni szeretne! - -## Kritériumok {#criteria} - -A szószedetbe felvett új kifejezéseket a következő kritériumok alapján értékeljük: - -- Naprakész és aktuális a kifejezés/definíció? -- Van már hasonló kifejezés a szótárban? (Ha igen, fontolja meg az új kifejezés előnyeit a meglévő kifejezés frissítésével szemben) -- A kifejezés/definíció nem vonatkozik termékreklámra vagy egyéb promóciós tartalomra? -- A kifejezés/definíció közvetlenül vonatkozik az Ethereumra? -- A meghatározás objektív, pontos, és nem tartalmaz szubjektív ítéletet vagy véleményt? -- A forrás hiteles? Hivatkoznak a forrásaikra? - ---- - -## Adjon hozzá kifejezést {#how-decisions-about-the-site-are-made} - -Ha egy szószedetet szeretne hozzáadni az ethereum.org webhelyhez, és az megfelel a feltételeknek, [probléma létrehozása a GitHubon](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+ %3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml). diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-layer-2s/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-layer-2s/index.md deleted file mode 100644 index a5d9176362d..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/adding-layer-2s/index.md +++ /dev/null @@ -1,97 +0,0 @@ ---- -title: Második blokkláncréteg (L2) hozzáadása -description: Szabályzat ahhoz, hogy második blokkláncréteget (L2) adjunk az ethereum.org webhelyhez -lang: hu ---- - -# Második blokkláncréteg (L2) hozzáadása {#adding-layer-2} - -Biztosítani szeretnénk, hogy a lehető legjobb erőforrásokat soroljuk fel, hogy a felhasználók biztonságosan és magabiztosan navigálhassanak az L2-k világában. - -Bárki szabadon javasolhatja egy L2 hozzáadását az ethereum.org webhelyen. Ha van olyan L2, amelyet kihagytunk, **[kérjük, javasolja](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_layer2.yaml)!** - -Jelenleg ezeket az L2-ket soroljuk fel: - -- [Optimista összegzők](/developers/docs/scaling/optimistic-rollups/) -- [Zero-knowledge összegzők](/developers/docs/scaling/zk-rollups/) -- [2. réteg](/layer-2/) - -Az L2 egy viszonylag új és érdekes paradigma az Ethereumban. Az ethereum.org kapcsán próbáltunk kialakítani egy helyes keretrendszert, de a listázási kritériumok fejlődni fognak idővel. - -## A döntési keretrendszer {#decision-framework} - -### A feltüntetés kritériumai: kötelezők {#criteria-for-inclusion-the-must-haves} - -**Az L2BEAT oldalán listázott** - -- Ahhoz, hogy figyelembe tudjuk venni az adott projektet, annak listázva kell lennie az [L2BEAT](https://l2beat.com) oldalán. Az L2BEAT egy robosztus kockázati elemzést végez az L2-es projektekre, amelyre mi is támaszkodunk az adott L2 megítélésekor. **Ha a projekt nem szerepel az L2BEAT oldalán, akkor nem listázhatjuk az ethereum.org-on.** -- [Tudjon meg többet arról, hogy a projekt hogyan kerülhet fel az L2BEAT oldalra](https://github.com/l2beat/l2beat/blob/master/CONTRIBUTING.md). - -**Nyílt forráskódú** - -- A kódnak elérhetőnek kell lennie, s a széles közönségtől fogadhat be PR-okat. - -**L2 kategóriák** - -Jelenleg a következő L2 kategóriákat használjuk: - -- Optimista típusú összevont tranzakciók -- Nulla tudás alapú (ZK) összevont tranzakció - -_Más skálázási megoldásokat nem tekintünk L2-nek, melyek nem használják az Ethereumot adatelérhetőségi és biztonsági szempontból._ - -**Ethereum használata adatelérhetőségre** - -- Az adatelérhetőség fontos megkülönböztető faktor az L2-k és más skálázási megoldások között. A projektnek az Ethereum-főhálózatot **kell** használnia az adatelérhetőségre, hogy listázni lehessen. - -**Hidak** - -- Hogyan tudnak a felhasználók belépni az L2-be? - -**A projekt létrejöttének időpontja** - -- Az L2-nek élőnek kell lennie a főhálózaton legalább 6 hónapja - -- Ennél újabb projekteket, melyek még nincsenek igazán kitesztelve a felhasználók által, nem valószínű, hogy listázunk. - -**Külső biztonsági audit** - -- A termék biztonságát megbízható módon le kell tesztelni, akár audit, akár belső biztonsági csapat vagy más módszer révén. Ez csökkenti a felhasználók kockázatát, és megmutatja, hogy a projekt komolyan veszi a biztonságot. - -**Stabil felhasználói bázis** - -- Figyelembe vesszük a TVL-előzményeket, a tranzakciós statisztikákat, és azt, hogy használják-e ismert cégek vagy projektek - -**Aktív fejlesztői csapat** - -- Nem vesszük be a listába az olyan L2-t, melynek nincs aktív csapata, mely a projekten dolgozik. - -**Blokkfelfedező** - -- A listázott projektekhez működőképes blokkfelfedező szükséges, hogy a felhasználók könnyedén navigálhassanak a láncon. - -### Más kritériumok: jó, ha van kategória {#nice-to-haves} - -**Tőzsdei támogatás a projektre** - -- Tudnak a felhasználók letétet tenni vagy kivenni közvetlenül egy tőzsdéről? - -**Dapp-hivatkozások az L2 ökoszisztémában** - -- Szeretnénk információt adni a felhasználóknak, hogy ezen az L2-n mit tudnak csinálni. (pl. https://portal.arbitrum.io/, https://www.optimism.io/apps) - -**Tokenszerződések listái** - -- Mivel az eszközöknek új címük lesz az L2-n, ezért kérjük, hogy osszák meg a tokenlistát, ha elérhető. - -**Natív tárcatámogatás** - -- Van bármilyen beépített tárcatámogatás? - -## Adjon hozzá L2-t {#add-exchange} - -Ha egy L2-t szeretne hozzáadni az ethereum.org webhelyhez, hozzon létre egy problémát a GitHubon. - - - Issue létrehozása - diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-products/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-products/index.md deleted file mode 100644 index 81ca0e5a093..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/adding-products/index.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -title: Termékek hozzáadása -description: Szabályzat az új dappok hozzáadásáról az ethereum.org webhelyhez -lang: hu ---- - -# Ethereum-termékek hozzáadása {#adding-products} - -Bárki szabadon javasolhat új dappokat az ethereum.org oldalra, ahol ez releváns. **Nem, nem fogjuk a dappot a főoldalra helyezni** 😜 - -A dappok jelenleg a következő helyeken vannak listázva: - -- ethereum.org/dapps -- ethereum.org/get-eth anyagai - -**Kérjük, hogy ezekhez a listákhoz javasoljon új tételt.** - -Bár nyitottan fogadunk minden javaslatot, a jelenlegi dappokat az alapján választottuk, hogy milyen élményt adnak a felhasználóknak. Ez a dizájnelveken alapszik: - -- _Inspiráló_: az ethereum.org-on megjelenő minden tétel valami újat adjon a felhasználóknak -- _Egy jó történet_: a feltüntetett tételek adjanak új felismerést vagy aha-élményt a felhasználóknak -- _Hiteles_: minden itt megjelenő törvényes üzlet/projekt, hogy minimalizálja a felhasználók kockázatát - -Összességében az **ethereum.org szeretné, ha a felhasználók problémamentesen tudnák használni ezeket a termékeket**. Ezért a dappokat a következők alapján választjuk ki: - -- egyszerű használat -- interoperábilis más termékekkel -- biztonság -- hosszú élettartam - -Íme a döntési keretrendszerünk részletesebben. Kérjük, ossza meg visszajelzését vagy javaslatait. - -## A döntési keretrendszer {#decision-framework} - -### A feltüntetés kritériumai: kötelezők {#criteria-for-inclusion-the-must-haves} - -- **Biztonsági szempontból tesztelt termék** – a termék biztonságát megbízható módon le kell tesztelni, akár audit, belső biztonsági csapat vagy más módszer révén. Ez csökkenti a felhasználók kockázatát, és megmutatja, hogy a projekt komolyan veszi a biztonságot. -- **A termék legalább 6 hónapja élesben működik** – ez is megmutatja a termék biztonságát. 6 hónap alatt a kritikus hibák és sebezhetőségek általában kiderülnek. -- **Egy aktív csapat dolgozik rajta** – ez biztosítja a minőséget és a felhasználók támogatását is. -- **Őszinte és pontos listázási információk** - a projekt által javasolt termék őszinte és pontos információkkal érkezik. Azokat a termékeket eltávolítjuk, melyek hamis információkat adnak meg a listázáshoz, például a nyílt forráskódú megjelölés, amikor a kód nem érhető el. - -### A rangsor kritériumai: jó, ha van kategória {#criteria-for-ranking-the-nice-to-haves} - -A javasolt dapp talán nem lesz olyan prominens módon megjelenítve az ethereum.org-on, mint mások, mely a következőkből fakad. - -**Dappok** - -- **Elérhető a listázott tárcák többségéből** – a dappoknak működniük kell a tárcák többségéből, melyeket az ethereum.org-on feltüntetünk. -- **A felhasználók kipróbálhatják** – a felhasználóknak tudniuk kell azt használni, és valami kézzelfoghatót elérni vele. -- **Belépési folyamat** – a termék használatához egy jól megtervezett belépési élmény kapcsolódik, mely segíti és tanítja a felhasználókat. Vagy legyenek elérhető cikkek vagy videók arról, hogyan kell azt használni. -- **Saját felügyeletű** – a felhasználók kezelik a saját pénzeszközeiket. Ha a termék eltűnik, a felhasználók akkor is elérik és használhatják az eszközeiket. -- **Világszerte elérhető** - A terméknek ne legyen földrajzi korlátozása vagy olyan ismerd meg ügyfeled (KYC) követelménye, amely kizár bizonyos embereket a szolgáltatás eléréséből. -- **Nyílt forráskódú** –a kódnak elérhetőnek kell lennie, és a széles közönségtől fogadhat be PR-okat. -- **Közösség** – dedikált közösséggel rendelkezik a termék, talán a Discord-on, ahol a felhasználók kapcsolódni tudnak a csapattal segítségért vagy javasolhatnak új funkciókat. - -## Kritériumok a gyakorlatban {#criteria-in-practice} - -Minél több kritériumnak felel meg, annál valószínűbb, hogy meglesz a helye az ethereum.org-on. - -Egy listázott termék, mely csak a kötelező kritériumoknak felel meg, talán lecserélésre kerül, amint jön egy olyan termék, mely több feltételt teljesít. - -Egyéb dolgok, melyek befolyásolják a döntést: - -- Ha újat adunk hozzá ahelyett, hogy lecserélnénk, megtöri az oldal UX-jét? - - az oldal elsősorban tájékoztatásul szolgál, elmagyarázza az Ethereumot és kapcsolódó koncepcióit. Ha túl sok opciót lát a felhasználó, akkor kevésbé olvasható az oldal, így kevésbé hasznos. -- Az oldalon túl sok a választási lehetőség, ami megbénítja a felhasználót? - - mint amikor valaki órákig böngészi a Netflixet, mert nem tudja milyen filmet nézzen. Az új felhasználók túl sok választási lehetőséggel való elárasztása kockázatot jelent. - -Ezt a dizájndöntést az ethereum.org hozza meg. - -De az biztos, hogy **megtalálhatók olyan oldalak hivatkozásai, amelyek több dappot sorolnak fel** - -### Termékrendelés {#product-ordering} - -Hacsak a termékeket kifejezetten másként nem rendelték, például ábécé sorrendben, az oldalon a legutóbb hozzáadottól láthatók a legrégebben bekerülőig. Más szóval, a legújabb termékek a lista aljára kerülnek. - -### Felhasználási feltételek {#terms-of-use} - -Tekintse meg [használati feltételeinket](/terms-of-use/). Az ethereum.org-on található információk általános tájékoztatásul szolgálnak. - -## Karbantartás {#maintenance} - -Mivel az Ethereum természete gyorsan alakul, a csapatok és a termékek jönnek-mennek, és naponta történnek innovációk, ezért rutinszerűen ellenőrizzük a tartalmakat: - -- biztosítjuk, hogy az összes felsorolt projekt továbbra is teljesíti a kritériumainkat -- ellenőrizzük, hogy nincsenek-e olyan termékek, amelyek a jelenlegiekhez képest jobban megfelelnek a kritériumoknak - -Segítségünkre lehet ebben, ha megnézi és értesít minket. [Nyisson egy hibajegyet](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=Type%3A+Feature&template=feature_request.yaml&title=) vagy küldjön e-mailt a [website@ethereum.org](mailto:website@ethereum.org) címre - -_Megvizsgáljuk a szavazási lehetőségeket is, hogy a közösség jelezhesse preferenciáit, és kiemelhesse a legjobb termékeket, amelyeket a honlapon ajánlhatunk._ - ---- - -## Adjon hozzá terméket {#add-your-product} - -Ha egy dappot szeretne hozzáadni az ethereum.org-hoz, és az megfelel a feltételeknek, hozzon létre egy issue-t a GitHubon. - - - Issue létrehozása - diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-staking-products/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-staking-products/index.md deleted file mode 100644 index f6e8e3aacba..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/adding-staking-products/index.md +++ /dev/null @@ -1,176 +0,0 @@ ---- -title: Letétbe helyezési termékek vagy szolgáltatások hozzáadása -description: Szabályzat az új letétbe helyezési termékek vagy szolgáltatások hozzáadásáról az ethereum.org webhelyhez -lang: hu ---- - -# Letétbe helyezési termékek vagy szolgáltatások hozzáadása {#adding-staking-products-or-services} - -Biztosítani szeretnénk, hogy a lehető legjobb forrásokat soroljuk fel, és a felhasználók biztonságosan és magabiztosan használhassák azokat. - -Bárki szabadon javasolhatja egy letétbe helyezési termék vagy szolgáltatás hozzáadását az ethereum.org webhelyen. Ha valamit kihagytunk, **[kérjük, javasolja](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_staking_product.yaml)!** - -Jelenleg a következő oldalakon listázunk letétbe helyezési termékeket vagy szolgáltatásokat: - -- [Egyéni staking](/staking/solo/) -- [Staking, mint szolgáltatás](/staking/saas/) -- [Letéti alapok](/staking/pools/) - -A letéti igazolásos (proof-of-stake) mechanizmus a Beacon-láncon 2020. december 1-én kezdődött el. Bár a letétbe helyezés még új, próbáltunk kialakítani egy helyes keretrendszert az ethereum.org-on való megjelenítésre, de a listázási kritérimok fejlődni fognak az idővel, és végső soron ez ethereum.org csapat megítélésétől fog függeni. - -## A döntési keretrendszer {#the-decision-framework} - -A termék megjelenítése az ethereum.org oldalon nem egy adott tényezőtől függ. Több kritériumot veszünk figyelembe egyszerre, hogy a döntést meghozzuk. Minél több kritériumnak felel meg valami, annál valószínűbb, hogy helye van a honlapon. - -**Először is, milyen jellegű termék vagy szolgáltatás ez?** - -- Csomópont vagy kliens eszközök -- Kulcskezelés -- Letétbe helyezés mint szolgáltatás (SaaS) -- Letéti alap - -Jelenleg ezek a kategóriák érhetők el. - -### A feltüntetés kritériumai {#criteria-for-inclusion} - -A letétbe helyezési termékek vagy szolgáltatások megjelenítését a következők alapján ítéljük meg: - -**Mikor került a projekt vagy szolgáltatás bevezetésre?** - -- Van rá bizonyíték, hogy a termék vagy szolgáltatás mikor vált nyilvánosan elérhetővé? -- Ez meghatározza a termék harcedzettségét. - -**A projektet aktívan karbantartják?** - -- Van olyan csapat, mely aktívan dolgozik rajta? Ki vesz részt ebben? -- Csak az aktívan karbantartott termékeket tudjuk figyelembe venni. - -**A termék vagy szolgáltatás megbízott/emberi közvetítők nélkül működik?** - -- A felhasználás közben mikor van szükség emberi beavatkozásra, akár a kulcsok felügyeletét vagy a jutalmak elosztását illetően? -- Ez meghatározza a termék vagy szolgáltatás bizalomigénymentességét. - -**A projekt pontos és megbízható információkat ad?** - -- Alapvető fontosságú, hogy a termék honlapja naprakész, pontos és nem félrevezető információkat tartalmazzon, különösen az Ethereum-protokollra vagy kapcsolódó technológiákra vonatkozóan. -- Azokat a termékeket elvetjük vagy eltávolítjuk, melyek félrevezető, elavult információkat és állításokat tartalmaznak az Ethereumról vagy kapcsolódó témákról. - -**Milyen platformokat támogat?** - -- azaz Linux, macOS, Windows, iOS, Android - -#### Szoftverek és okosszerződések {#software-and-smart-contracts} - -Ha valamilyen egyéni szoftver vagy okosszerződés van benne: - -**Minden nyílt forráskódú?** - -- A nyílt forráskódú projekteknek nyilvánosan elérhető könyvtárban kell tárolniuk a forráskódot -- Ez meghatározza a termék nyílt forráskódú mivoltát. - -**A termék túl van-e a _béta_ fejlesztésen?** - -- Hol tart a termék fejlesztési ciklusa? -- A béta fejlesztésnél tartó termékeket nem listázzuk az ethereum.org-on - -**A szoftver átment külső biztonsági auditon?** - -- Ha még nem, akkor vannak erre tervek? -- Ez meghatározza a termék auditáltságát. - -**Van a projektnek hibavadász programja?** - -- Ha még nincs, akkor vannak erre tervek? -- Ez meghatározza a termék hibavadász pontszámát. - -#### Csomópont vagy kliens eszközök {#node-or-client-tooling} - -Azokkal a szoftverekkel kapcsolatban, melyek csomópont- vagy kliensfelállítással, -kezeléssel vagy -migrációval kapcsolatosak: - -**Mely konszenzusréteg-kliensek (vagyis A Lighthouse, Teku, Nimbus, Prysm, Grandine) támogatott?** - -- Milyen klienseket támogat? Választhat a felhasználó? -- Ez meghatározza a termék több klienssel való használhatóságát. - -#### Staking, mint szolgáltatás {#staking-as-a-service} - -A [letétbe helyezés mint szolgáltatás (SaaS)](/staking/saas/) (vagyis delegált csomópontkezelés) kapcsán: - -**Milyen díjak kapcsolódnak a szolgáltatáshoz?** - -- Mi a díjstruktúra, például havi fizetés van? -- Van bármilyen további letétbe helyezési feltétel? - -**A felhasználóknak létre kell hozni egy számlát?** - -- Lehet használni a szolgáltatást engedély vagy ellenőrzés (KYC) nélkül? -- Ez meghatározza a termék engedélymentességét. - -**Kinél vannak az aláíró és visszavonó kulcsok?** - -- Milyen kulcsokat kell a felhasználónak tartania? Milyen kulcsokhoz fér hozzá a szolgáltatás? -- Ez meghatározza a termék bizalomigénymentességét. - -**Mi a csomópontok kliensdiverzitása?** - -- A validátorkulcsok mekkora aránya fut többségi konszenzus réteg (CL) klienssel? -- A legutóbbi állapot szerint a Prysm az a konszenzus réteg kliens, melyet a legtöbb csomópont-operátor használ, ezért veszélyes a hálózatra nézve. Ha bármelyik konszenzusréteg klienst a hálózat több mint 33%-a használja, akkor annak használatáról adatokat kell kérjünk. -- Ez meghatározza a termék kliensdiverzitását. - -#### Letéti alap {#staking-pool} - -A [letétialap-szolgáltatások](/staking/pools/) kapcsán: - -**Mi a minimális letétbe helyezés ETH-ben?** - -- például 0,01 ETH - -**Milyen díjak vagy letétbe helyezési feltételek vannak?** - -- A jutalom mekkora részét tartják meg díj formájában? -- Van bármilyen további letétbe helyezési feltétel? - -**Van likviditási token?** - -- Milyen tokenek szerepelnek? Hogyan működnek? Mik a szerződéscímek? -- Ez meghatározza a terméklikviditási token pontszámát. - -**A felhasználó részt vehet csomópont-operátorként?** - -- Mi szükséges egy validátorkliens futtatásához az összegyűjtött alapok használatával? -- Szükséges ehhez engedély egy egyéntől, cégtől vagy DAO-tól? -- Ez meghatározza a termék engedélymentes csomópont jellegét. - -**Mi a letéti alap csomópont-operátorainak kliensdiverzitása?** - -- A csomópont-operátorok mekkora aránya fut többségi konszenzus réteg (CL) klienssel? -- A legutóbbi állapot szerint a Prysm az a konszenzus réteg kliens, melyet a legtöbb csomópont-operátor használ, ezért veszélyes a hálózatra nézve. Ha bármelyik konszenzusréteg klienst a hálózat több mint 33%-a használja, akkor annak használatáról adatokat kell kérjünk. -- Ez meghatározza a termék kliensdiverzitását. - -### Más kritériumok: jó, ha van kategória {#other-criteria} - -**Milyen felhasználói felületeket támogat?** - -- azaz Böngészőalkalmazás, asztali alkalmazás, mobilalkalmazás, CLI - -**A csomóponti eszközökhöz ad a szoftver lehetőséget arra, hogy kliensek között lehessen váltani?** - -- A felhasználó könnyen és biztonsággal tud klienst váltani az eszközzel? - -**Az SaaS esetében a szolgáltatás mennyi validátort üzemeltet jelenleg?** - -- Ez segít megérteni a szolgáltatás kiterjedtségét. - -## Hogyan jelenítjük meg az eredményeket {#product-ordering} - -A fenti [felvételi kritériumok](#criteria-for-inclusion) alapján minden termékre vagy szolgáltatásra kumulatív pontszámot számítunk. Ezt az objektív kritériumoknak megfelelő termékek kiválogatására és bemutatására használjuk. Minél több kritériumra van bizonyíték, annál magasabbra soroljuk a terméket, a döntetlenek a használat alapján kerülnek sorrendbe. - -A kód logikája és a kritériumok súlyozása jelenleg ebben [a JavaScript komponensben](https://github.com/ethereum/ethereum-org-website/blob/dev/src/components/Staking/StakingProductsCardGrid.js#L350) található a könyvtárunkban. - -## Adja hozzá a termékét vagy szolgáltatását {#add-product} - -Ha egy letétbe helyezési terméket vagy szolgáltatást szeretne hozzáadni az ethereum.org webhelyhez, hozzon létre egy problémát a GitHubon. - - - Issue létrehozása - diff --git a/public/content/translations/hu/28) Contributing 2/contributing/adding-wallets/index.md b/public/content/translations/hu/28) Contributing 2/contributing/adding-wallets/index.md deleted file mode 100644 index a855259dc16..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/adding-wallets/index.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Tárcák hozzáadása -description: Szabályzat a tárcák hozzáadásáról az ethereum.org webhelyhez -lang: hu ---- - -# Tárcák hozzáadása {#adding-wallets} - -Biztosítani szeretnénk, hogy sokféle tárcát megmutatunk, lefedve azok funkciógazdagságát, hogy a felhasználók magabiztosan navigálhassanak az Ethereumban. - -Bárki szabadon javasolhatja egy tárca hozzáadását az ethereum.org webhelyen. Ha van olyan tárca, amelyet kihagytunk, kérjük, javasolja! - -A tárcák jelenleg a következő helyen vannak listázva: - -- [ethereum.org/wallets/find-wallet/](/wallets/find-wallet/) - -A tárcák gyorsan változnak az Ethereumban. Az ethereum.org kapcsán próbáltunk kialakítani egy helyes keretrendszert, de a listázási kritériumok fejlődni fognak idővel. - -## A döntési keretrendszer {#the-decision-framework} - -### A feltüntetés kritériumai: kötelezők {#the-must-haves} - -- **Bizonsági szempontból tesztelt termék** – a tárca biztonságát megbízható módon le kell tesztelni, akár audit, belső biztonsági csapat vagy más módszer révén. Ez csökkenti a felhasználók kockázatát, és megmutatja, hogy a projekt komolyan veszi a biztonságot. -- **A tárca legalább 6 hónapja élesben működik VAGY olyan csoport adta ki, melynek megbízható reputációja van** – ez is megmutatja a termék biztonságát. Hat hónap alatt a kritikus hibák és sebezhetőségek általában kiderülnek. Azért is kérünk hat hónapot, mert így ki lehet szűrni azokat az elágazásokat, melyeket gyorsan magukra hagynak. -- **Egy aktív csapat dolgozik rajta** – ez biztosítja a minőséget és a felhasználók támogatását is. -- **Őszinte és pontos listázási információk** - a projekt által javasolt termék őszinte és pontos információkkal érkezik. Azokat a termékeket eltávolítjuk, melyek hamis információkat adnak meg a listázáshoz, például a nyílt forráskódú megjelölés, amikor a kód nem érhető el. -- **Kapcsolattartási pont** - Egy kapcsolattartási pont a tárca kapcsán nagyban segíti a pontos információk beszerzését változások esetén. Ezzel az ethereum.org frissítése könnyebb, amikor a jövőben információt kell szerezni. -- **EIP-1559 (2-es típusú) tranzakciók** - a tárcának támogatnia kell az EIP-1559 (2-es típusú) tranzakciókat az Ethereum főhálózatán. -- **Jó felhasználói élmény** - Bár a felhasználói élmény szubjektív, de ha a központi csapat tagjai tesztelik a terméket, és nehezen használhatónak találják, akkor elutasíthatjuk azt, és inkább javaslatokat teszünk a javításra. Ezzel szeretnénk védeni a felhasználókat, akik sokszor kezdők ezen a területen. - -### Termékeltávolítások {#product-removals} - -- **Frissített információk** - A tárcaszolgáltatók felelősek azért, hogy 6 havonta újra benyújtsák a tárcára vonatkozó információkat, hogy biztosítsák azok érvényességét és relevanciáját (akkor is, ha nem történt változás). Ha ezt nem teszi meg a termék csapata, akkor az ethereum.org eltávolíthatja azt a honlapról. - -### Más kritériumok: jó, ha van kategória {#the-nice-to-haves} - -- **Világszerte elérhető** - a tárcának ne legyen földrajzi korlátozása vagy olyan ismerd meg ügyfeled (KYC) követelménye, amely kizár bizonyos embereket a szolgáltatásból. -- **Több nyelven elérhető** - a tárca le van fordítva több nyelvre, így a világ minden tájáról származó felhasználók számára elérhető. -- **Nyílt forráskódú** –a teljes kódbázisnak (nem csak moduloknak) elérhetőnek kell lennie, és a széles közönségtől fogadhat be PR-okat. -- **Saját felügyeletű** – a felhasználók kezelik a saját pénzeszközeiket. Ha a termék eltűnik, a felhasználók akkor is elérik és használhatják az eszközeiket. -- **Hardveres tárca támogatása** - a felhasználók hozzákapcsolhatják a hardveres tárcájukat, hogy tranzakciókat írjanak alá. -- **WalletConnect** - a felhasználók kapcsolódhatnak olyan dappokhoz, melyek WalletConnect-et használnak. -- **Ethereum RPC végpontok importálása** - a felhasználók importálhatják a csomópontok RPC-adatait, így csatlakozhatnak egy kiválasztott csomóponthoz vagy más EVM-kompatibilis hálózatokhoz. -- **NFT-k** - a felhasználók láthatják és használhatják az NFT-iket a tárcában. -- **Kapcsolódás az Ethereum alkalmazásaihoz** - a felhasználók képesek kapcsolódni az Ethereum alkalmazásaihoz és használni azokat. -- **Letétbe helyezés** - a felhasználók képeseket letétbe helyezni pénzeszközeiket közvetlenül a tárcából. -- **Átváltások** - a felhasználók képesek tokeneket átváltani a tárcán keresztül. -- **Több blokklánchálózat** - a tárca támogatja több blokklánchálózat elérését. -- **L2 hálózatok** - a tárca támogatja, hogy a felhasználók L2 hálózatokat érjenek el. -- **Gázdíjak személyre szabása** - a tárca lehetővé teszi a felhasználóknak, hogy személyre szabják a tranzakciós díjaikat (alapdíj, prioritási díj, maximális díj). -- **ENS támogatása** - a tárca lehetővé teszi, hogy a felhasználó ENS nevekre küldjön tranzakciókat. -- **ERC-20 támogatása** - a tárca lehetővé teszi, hogy ERC-20 tokenszerződéseket importáljon a felhasználó, vagy automatikusan lekérdezi és megmutatja az ERC-20-tokeneket. -- **Kriptovásárlás** - a tárca támogatja, hogy a felhasználó közvetlenül vásárolhasson kriptót vagy kapcsolódjon azzal. -- **Fiatért eladás** - a tárca támogatja, hogy a felhasználók közvetlenül kártyára vagy bankszámlára adjanak el és vegyenek ki fiatot. -- **Több aláírás** - támogatja több aláíró meglétét a tranzakciók kezelésénél. -- **Hagyományos visszaállítás** - támogatja az őrzők meglétét, így a felhasználó akkor is vissza tudja állítani a tárcát, ha nincs meg a kulcsmondata. -- **Dedikált támogatócsapat** - a tárcának dedikált támogatócsapata van, amely segít a felhasználók problémáit megoldani. -- **Oktatási források/dokumentáció** - a terméknek jól kidolgozott bevezető élménnyel kell rendelkeznie, hogy segítse és oktassa a felhasználókat. Vagy legyenek elérhető cikkek vagy videók arról, hogyan kell azt használni. - -## Tárca hozzáadása {#adding-a-wallet} - -Ha egy tárcát szeretne hozzáadni az ethereum.org webhelyhez, hozzon létre egy problémát a GitHubon. - - - Issue létrehozása - - -## Karbantartás {#maintenance} - -Mivel az Ethereum természete gyorsan alakul, a csapatok és a termékek jönnek-mennek, és naponta történnek innovációk, ezért rutinszerűen ellenőrizzük a tartalmakat: - -- biztosítjuk, hogy az összes felsorolt tárca és dapp továbbra is teljesíti a kritériumainkat -- ellenőrizzük, hogy nincsenek-e olyan termékek, amelyek a jelenlegiekhez képest jobban megfelelnek a kritériumoknak - -az ethereum.org-ot a nyílt forráskódú közösség tartja fenn, és így a közösségre támaszkodik ahhoz, hogy aktuális információkat mutasson. Ha a listázott tárcáknál frissítésre van szükség, akkor [nyisson egy hibajegyet](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=wallet+%3Apurse%3A&template=suggest_wallet.yaml) vagy [PR-t](https://github.com/ethereum/ethereum-org-website/pulls)! - - -## Felhasználási feltételek {#terms-of-use} - -Tekintse meg [használati feltételeinket](/terms-of-use/). Az ethereum.org-on található információk általános tájékoztatásul szolgálnak. diff --git a/public/content/translations/hu/28) Contributing 2/contributing/content-resources/index.md b/public/content/translations/hu/28) Contributing 2/contributing/content-resources/index.md deleted file mode 100644 index eef66c3d199..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/content-resources/index.md +++ /dev/null @@ -1,32 +0,0 @@ ---- -title: Tartalmi források hozzáadása -lang: hu -description: A tartalmi források listázásának kritériumai az ethereum.org-on ---- - -# Tartalmi források hozzáadása {#adding-content-resources} - -Nem remélhetjük, hogy mindent le tudunk fedni az Ethereum kapcsán, ezért megpróbálunk bemutatni néhányat a közösség által létrehozott remek cikkekből, útmutatókból, hírlevelekből, álláshirdetésekből és különböző tartalmi forrásokból. Ezek részletes információkat adnak olyan témákról, melyek érdeklik a felhasználókat. - -Ha van olyan tartalmi forrás, melyet megjeleníthetnénk, javasolja a megfelelő helyen. - -## Hogyan döntünk {#how-we-decide} - -A tanulási forrásokat a következőképpen ítéljük meg: - -- A tartalom friss? -- A tartalom fizetős? -- Az információ pontos? Tényszerű vagy véleményalapú? -- A szerző hiteles? Hivatkoznak a forrásaikra? -- Ez a tartalom olyan értéket ad, melyet a meglévő források/hivatkozások nem fednek le? -- Ez a tartalom valamelyik [közösségi típust](https://www.notion.so/efdn/Ethereum-org-User-Persona-Memo-b44dc1e89152457a87ba872b0dfa366c) szolgálja? - ---- - -## Adjon hozzá tartalmi forrást {#add-your-content-resource} - -Ha egy tartalmi forrást szeretne hozzáadni az ethereum.org-hoz, és az megfelel a feltételeknek, hozzon létre egy issue-t a GitHubon. - - - Issue létrehozása - diff --git a/public/content/translations/hu/28) Contributing 2/contributing/design/adding-design-resources/index.md b/public/content/translations/hu/28) Contributing 2/contributing/design/adding-design-resources/index.md deleted file mode 100644 index 0f7035b5490..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/design/adding-design-resources/index.md +++ /dev/null @@ -1,69 +0,0 @@ ---- -title: Dizájnforrások hozzáadása -description: Útmutató és feltételek a minőségi dizájnanyagok megjelenítéséhez az ethereum.org-on -lang: hu ---- - -# Dizájnforrások hozzáadása {#adding-design-resources} - -Bárki javasolhat új dizájnanyagokat a [Dizájn és UX a web3-ban oldalra](/developers/docs/design-and-ux/). - -Ennek az oldalnak a lényege, hogy olyan értéket adjon, mely inspirálja a web3-dizájnereket. Nem arra szolgál, hogy reklámozzon bizonyos szolgáltatásokat, termékeket vagy platformokat. - -Annak érdekében, hogy biztosítsuk az információk magas színvonalát és az értékes meglátások népszerűsítését, a következő listázási szabályt használjuk: - -## Kutatási tanulmányok és irányítópultok {#Research-studies} - -1. Megbízható módszertan - -a. A módszertan egyértelműen határozza meg, hogyan gyűjtötték az adatokat. - -b. Adják, meg a kutatásban résztvevők számát. - -c. Adják meg a kutatási módszereket. - -2. A web3-dizájnerek számára mennyire releváns és általános használati esetek - -a. A kutatás témája legyen releváns a web3-dizájnereknek és célozzon meg általános használati eseteket. - -3. Fókuszáljon az információk nyújtására - -a. A szöveg adjon betekintéseket, ne promótáljon projekteket vagy cégeket. - -## Cikkek {#Articles} - -1. A web3-dizájnerek/-kutatók számára mennyire releváns és általános web3-használati esetek - -a. A cikk témája legyen releváns a web3-dizájnerek és -kutatók számára, és célozzon meg általános web3-használati eseteket. - -2. Alapvető írásminőség - -a. A cikk legyen nyelvtanilag rendben és helyesírási hibáktól mentes. - -b. A lényeg a kulcsfontosságú meglátások és tanulságok átadása legyen. - -c. Az írás legyen tömör és lényegre törő. - -3. A szöveg célja - -a. A szöveg adjon betekintéseket, ne promótáljon projekteket vagy cégeket. - -## Közösségek/DAO-k {#Communities-and-DAOs} - -1. A honlap egyértelműen adja meg, hogyan lehet csatlakozni a DAO-hoz/közösséghez - -2. A tagság előnyei legyenek egyértelműek - -a. A tagság előnyeit emeljék ki határozottan. - -**Például**: visszajelzést kaphat a munkájáról, hozzáférhet munkalehetőségekhez vagy jutalmakhoz, megoszthatja tervezési és kutatási meglátásait. - -3. A Discordon legyen aktív és élénk beszélgetés - -a. A Discord-közösség mutasson élő és elkötelezett kommunikációt. - -b. A moderátorok aktívan vegyenek részt a közösség fenntartásában és a beszélgetések irányításában. - -c. A közösség mutassa meg, hogy az elmúlt két hétben értékes és eredményes beszélgetéseket folytatott. - -Ezen kritériumok alapján szeretnénk egy virágzó és tudásmegosztó környezetet adni a közösségünknek. A listázási szabály mentén a felhasználók megbízható, releváns és betekintést engedő forrásokhoz férhetnek hozzá. Köszönjük a megértését és együttműködését abban, hogy a minőségi tartalom legyen a platformon. diff --git a/public/content/translations/hu/28) Contributing 2/contributing/quizzes/index.md b/public/content/translations/hu/28) Contributing 2/contributing/quizzes/index.md deleted file mode 100644 index 52fdbd02b18..00000000000 --- a/public/content/translations/hu/28) Contributing 2/contributing/quizzes/index.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Kvízkérdés hozzáadása -description: Szabályzat az új kvízkérdések hozzáadásáról az ethereum.org webhelyhez -lang: hu ---- - -# Kvízek {#quizzes} - -A kvíz remek lehetőség a felhasználónak, hogy tesztelje, mennyire érti az adott oldal tartalmát. A kvíz az adott oldal tartalmára támaszkodik, és csak olyanra hivatkozik, ami ott szerepel. - -A kérdések struktúrája a következő. Kérdésfeltevés, 1 helyes válasz és magyarázata, hogy miért helyes, 3 helytelen válasz és magyarázata, hogy miért helytelen. - -A jelenlegi kvízekből néhány példát itt láthat: - -- [Második blokkláncréteg (L2)](/layer-2) -- [NFT](/nft/) -- [Mi az Ethereum?](/what-is-ethereum/) -- [Mi az az ETH?](/eth/) - -## Kvíz hozzáadása - -Ha van olyan oldal, mely még nem tartalmaz kvízt, akkor [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml). - -Adja meg a következő információkat: - -- Az oldal, ahova a kvíz kerülne -- 5 kérdés a következő részletekkel: - - Az oldal szekciója, melyhez a kérdés kapcsolódik - - A kérdésfeltevés - - 1 helyes válasz és a magyarázata, hogy miért helyes - - 3 helytelen válasz és a magyarázata, hogy miért helytelen - -## Kvízkérdés hozzáadása - -Ha szeretne egy kérdést hozzáadni egy kvízhez, akkor [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml), és adja meg a következőket: - -- Az oldal, ahova a kvízkérdés kerülne -- A kérdéshez adja meg a következő információkat: - - Az oldal szekciója, melyhez a kérdés kapcsolódik - - A kérdésfeltevés - - 1 helyes válasz és a magyarázata, hogy miért helyes - - 3 helytelen válasz és a magyarázata, hogy miért helytelen - -## Kvízkérdés frissítése - -Ha szeretne egy kérdést frissíteni egy kvíznél, akkor [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml), és adja meg a következőket: - -- Az oldal, ahol a kvízkérdést frissítené -- A kérdéshez adja meg a következő információkat: - - Az oldal szekciója, melyhez a kérdés kapcsolódik - - A kérdésfeltevés, ahol a frissítést szeretné - - A frissített kérdésfeltevés - - 1 helyes válasz és a magyarázata, hogy miért helyes - - 3 helytelen válasz és a magyarázata, hogy miért helytelen - -## Kvízkérdés eltávolítása - -Ha a kvízkérdéshez tartozó tartalom már nem szerepel az oldalon és ezért el kell távolítani, [nyisson egy issue-t](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=&template=suggest_quiz.yaml) a törlésre, és adja meg a következőket: - -- Az oldal, ahol a kvízkérdést törölné -- A kérdés, melyet törölni szeretne -- Annak magyarázata, hogy miért nincs szükség a kérdésre From 20fbd4101e66cc870fd9741141be35c16a3491e5 Mon Sep 17 00:00:00 2001 From: Corwin Smith Date: Mon, 6 Jan 2025 13:04:36 -0700 Subject: [PATCH 3/3] fix regressions --- .../hu/contributing/adding-exchanges/index.md | 2 +- .../adding-glossary-terms/index.md | 2 +- .../pos/attack-and-defense/index.md | 172 +++++++++++++----- .../docs/scaling/optimistic-rollups/index.md | 6 - .../docs/scaling/state-channels/index.md | 67 ------- .../docs/scaling/zk-rollups/index.md | 6 - .../docs/standards/tokens/erc-777/index.md | 77 -------- .../translations/hu/staking/solo/index.md | 2 +- 8 files changed, 126 insertions(+), 208 deletions(-) delete mode 100644 public/content/translations/hu/developers/docs/scaling/state-channels/index.md delete mode 100644 public/content/translations/hu/developers/docs/standards/tokens/erc-777/index.md diff --git a/public/content/translations/hu/contributing/adding-exchanges/index.md b/public/content/translations/hu/contributing/adding-exchanges/index.md index ea9ca0f12c2..b2499ec6b95 100644 --- a/public/content/translations/hu/contributing/adding-exchanges/index.md +++ b/public/content/translations/hu/contributing/adding-exchanges/index.md @@ -16,7 +16,7 @@ Ezen az oldalon a felhasználó megadhatja, hol él, és megnézheti, milyen cse Emiatt a kontextus miatt szükségünk van néhány konkrét információra, amikor cserét javasol. -**MEGJEGYZÉS:** Ha decentralizált tőzsdét szeretne listázni, tekintse meg a [pénztárcák és dapps listára vonatkozó irányelveinket ](/contributing/adding-products/). +**MEGJEGYZÉS:** Ha decentralizált tőzsdét szeretne listázni, tekintse meg a [pénztárcák és dapps listára vonatkozó irányelveinket](/contributing/adding-products/). ## Amire szükségünk van {#what-we-need} diff --git a/public/content/translations/hu/contributing/adding-glossary-terms/index.md b/public/content/translations/hu/contributing/adding-glossary-terms/index.md index 5d304d76bfc..a07a43d9f82 100644 --- a/public/content/translations/hu/contributing/adding-glossary-terms/index.md +++ b/public/content/translations/hu/contributing/adding-glossary-terms/index.md @@ -23,4 +23,4 @@ A szószedetbe felvett új kifejezéseket a következő kritériumok alapján é ## Adjon hozzá kifejezést {#how-decisions-about-the-site-are-made} -Ha egy szószedetet szeretne hozzáadni az ethereum.org webhelyhez, és az megfelel a feltételeknek, [probléma létrehozása a GitHubon](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+ %3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml). +Ha egy szószedetet szeretne hozzáadni az ethereum.org webhelyhez, és az megfelel a feltételeknek, [probléma létrehozása a GitHubon](https://github.com/ethereum/ethereum-org-website/issues/new?assignees=&labels=feature+%3Asparkles%3A%2Ccontent+%3Afountain_pen%3A&template=suggest_glossary_term.yaml). diff --git a/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md b/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md index fe0fed8b75a..c686a96a185 100644 --- a/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md +++ b/public/content/translations/hu/developers/docs/consensus-mechanisms/pos/attack-and-defense/index.md @@ -4,86 +4,160 @@ description: Ismerje meg a proof-of-stake Ethereum elleni ismert támadási vekt lang: hu --- -A tolvajok és szabotőrök folyamatosan keresik a lehetőséget, hogy megtámadják az Ethereum kliensszoftverét. Ez az oldal ismerteti az Ethereum konszenzusrétegét érő ismert támadási vektorokat, és felvázolja, hogyan lehet ezeket a támadásokat kivédeni. +A tolvajok és szabotőrök folyamatosan keresik a lehetőséget, hogy megtámadják az Ethereum kliensszoftverét. Ez az oldal ismerteti az Ethereum konszenzusrétegét érő ismert támadási vektorokat, és felvázolja, hogyan lehet ezeket a támadásokat kivédeni. Az ezen az oldalon található információk egy [hosszabb változatból](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) származnak. ## Előfeltételek {#prerequisites} -## {#what-is-pos} +A [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) alapszintű ismerete szükséges. Hasznos lesz továbbá, ha alapszintű ismeretekkel rendelkezik az Ethereum [ösztönzési réteg](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) és az elágazásválasztási algoritmus, az [LMD-GHOST](/developers/docs/consensus-mechanisms/pos/gasper) működéséről. -Gyakori tévhit, hogy egy sikeres támadó képes új ethert generálni, vagy tetszőleges számlákról ethert lehívni. Egyik sem lehetséges, mivel minden tranzakciót a hálózat összes végrehajtási kliense hajtja végre. A tranzakcióknak meg kell felelniük az érvényesség alapvető feltételeinek (például a tranzakciókat a feladó privát kulcsa írja alá, a feladónak elegendő egyenleggel kell rendelkeznie stb. Az eredménynek három osztálya van, amelyet egy támadó reálisan megcélozhat: átszervezés, dupla véglegesség vagy a véglegesség késleltetése. +## Mit akarnak a támadók? {#what-do-attackers-want} -## {#validators} +Gyakori tévhit, hogy egy sikeres támadó képes új ethert generálni, vagy tetszőleges számlákról ethert lehívni. Egyik sem lehetséges, mivel minden tranzakciót a hálózat összes végrehajtási kliense hajtja végre. A tranzakcióknak meg kell felelniük az érvényesség alapvető feltételeinek (például a tranzakciókat a feladó privát kulcsa írja alá, a feladónak elegendő egyenleggel kell rendelkeznie stb. Az eredménynek három osztálya van, amelyet egy támadó reálisan megcélozhat: átszervezés, dupla véglegesség vagy a véglegesség késleltetése. Az **átszervezés** a blokkok új sorrendbe rendezése, esetleg a kanonikus láncban lévő blokkok hozzáadásával vagy kivonásával. Egy rosszindulatú átszervezés biztosíthatja, hogy bizonyos blokkok bekerüljenek vagy kikerüljenek, lehetővé téve a dupla költést vagy az értékkivonást előre és hátra futó tranzakciókkal (MEV). Az átszervezés arra is felhasználható, hogy bizonyos tranzakciókat ne lehessen felvenni a kanonikus láncba, ami a cenzúra egy formája. Az átszervezés legszélsőségesebb formája a „véglegesítés visszaállítása”, amely eltávolítja vagy helyettesíti a korábban véglegesített blokkokat. Ez csak akkor lehetséges, ha a támadó a teljes feltett ether több mint ⅓-át megsemmisíti – ez a garancia az úgynevezett „gazdasági véglegesség” (erről később még lesz szó). **Kettős véglegesség** az a valószínűtlen, de súlyos állapot, amikor két elágazás képes egyszerre véglegesedni, ami tartós szakadást okoz a láncban. Ez elméletileg lehetséges egy olyan támadó számára, aki hajlandó a teljes feltett ether 34%-át kockáztatni. A közösség kénytelen lenne a láncon kívül koordinálni és megegyezni arról, hogy melyik láncot kövesse, amihez a társadalmi réteg erejére lenne szükség. -## {#transaction-execution-ethereum-pos} - -1. -2. -3. -4. -5. -6. +A **véglegesség késleltetése** megakadályozza, hogy a hálózat elérje a szükséges feltételeket a lánc szakaszainak véglegesítéséhez. Véglegesség nélkül nehéz megbízni az Ethereumra épülő pénzügyi alkalmazásokban. A véglegességkésleltetéses támadás célja valószínűleg egyszerűen az Ethereum megzavarása, nem pedig a közvetlen haszonszerzés, kivéve, ha a támadónak stratégiai short pozíciói vannak. A szociális réteg elleni támadás célja lehet az Ethereumba vetett közbizalom aláásása, az ether leértékelése, az elfogadás csökkentése vagy az Ethereum-közösség gyengítése, hogy megnehezítse a sávon kívüli koordinációt. -## {#finality} +Miután megállapítottuk került, hogy egy ellenség miért támadhatja meg az Ethereumot, a következő szakaszok azt vizsgálják meg, hogy _hogyan_ lehet ezt megtenni. + +## Támadási módszerek {#methods-of-attack} + +### 0. rétegbeli támadások {#layer-0} Először is, azok a személyek, akik nem vesznek részt aktívan az Ethereumban (a kliensszoftver futtatásával), a társadalmi réteget (0. réteg) célozva támadhatnak. A 0. réteg az alap, amelyre az Ethereum épül, és mint ilyen, potenciális támadási felületet jelent, amelynek következményei a stack többi részére is kihatnak. Néhány példa: -## {#crypto-economic-security} +- Egy félretájékoztató kampány alááshatja a közösség bizalmát az Ethereum ütemtervét, fejlesztőcsapatokat, alkalmazásokba stb. illetően. Ez pedig csökkentheti a hálózat biztosításában résztvevők számát, ami rontja a decentralizációt és a kriptogazdasági biztonságot. +- Célzott támadások és/vagy fenyegetés a fejlesztői közösség ellen. Ez a fejlesztők önkéntes kilépéséhez vezethet, és lelassíthatja az Ethereum fejlődését. + +- A túlbuzgó szabályozás a 0. réteg elleni támadásnak is tekinthető, mivel gyorsan visszavetheti a részvételt és az elfogadást. +- Hozzáértő, de rosszindulatú szereplők beszivárgása a fejlesztői közösségbe, akiknek célja a fejlődés lelassítása a megbeszélések megzavarásával, a fontos döntések késleltetésével, szemeteléssel (spam) stb. +- Az Ethereum ökoszisztéma kulcsszereplőinek adott kenőpénzek, hogy ezzel befolyásolják a döntéshozatalt. Ezeket a támadásokat az teszi különösen veszélyessé, hogy sok esetben nagyon kevés tőkére vagy technikai tudásra van szükség. Egy 0. rétegbeli támadás egy kriptogazdasági támadás multiplikátora lehet. Ha például a cenzúrát vagy a véglegesség visszaállítását egy rosszindulatú többségi érdekelt fél érné el, a szociális réteg aláásása megnehezíthetné a sávon kívüli közösségi válaszlépések koordinálását. A 0. rétegbeli támadások elleni védekezés valószínűleg nem egyszerű, de néhány alapelvet fel lehet állítani. Az egyik az Ethereummal kapcsolatos nyilvános információk magas jel-zaj arányának fenntartása, amelyeket a közösség becsületes tagjai hoznak létre és terjesztenek blogokon, Discord szervereken, kommentált specifikációkon, könyveken, podcastokon és Youtube-on keresztül. Itt az ethereum.org-on is igyekszünk pontos információkat fenntartani és a lehető legtöbb nyelvre lefordítani. A tér minőségi információkkal és mémekkel való elárasztása hatékony védekezés a félretájékoztatás ellen. -## {#fork-choice} - Egy másik fontos megerősítés a társadalmi réteg támadásaival szemben az egyértelmű küldetésnyilatkozat és az irányítási protokoll. Az Ethereum a decentralizáció és a biztonság bajnokaként pozicionálta magát az L1-es okosszerződések között, miközben nagyra értékeli a skálázhatóságot és a fenntarthatóságot is. Bármilyen nézeteltérések merülnek fel az Ethereum közösségben, ezek az alapelvek minimálisan sérülnek. A narratíva értékelése ezen alapelvek alapján és a felülvizsgálat egymást követő fordulóin keresztül az EIP (Ethereum Fejlesztési Javaslatok) folyamatában segíthet a közösségnek megkülönböztetni a jó és a rossz szereplőket, illetve korlátozhatja a rosszindulatú szereplők lehetőségét az Ethereum jövőbeli irányának befolyásolására. -## {#pos-and-security} - Végezetül fontos, hogy az Ethereum-közösség nyitott és befogadó maradjon minden résztvevő számára. A zártkörű közösségek különösen sebezhetők a társadalmi támadásokkal szemben, mivel könnyű „mi és ők” narratívákat építeni. A törzsiség és a mérgező maximalizmus árt a közösségnek és aláássa a 0. réteg biztonságát. A hálózat biztonságában érdekelt Ethereum-tagoknak úgy kell tekinteni az online és személyes találkozásokra, mint ami közvetlenül hozzájárul az Ethereum 0. rétegének biztonságához. -- -- -- -- Hozzáértő, de rosszindulatú szereplők beszivárgása a fejlesztői közösségbe, akiknek célja a fejlődés lelassítása a megbeszélések megzavarásával, a fontos döntések késleltetésével, szemeteléssel (spam) stb. +### A protokoll megtámadása {#attacking-the-protocol} + +Bárki, aki az Ethereum kliensszoftverét futtatja. Ahhoz, hogy egy validátor hozzáadjon egy klienshez, a felhasználónak 32 ethert kell betennie a letéti szerződésbe. A validátor lehetővé teszi a felhasználó számára, hogy aktívan részt vegyen az Ethereum hálózatának biztonságában azáltal, hogy új blokkokat javasol és tanúsít. A validátornak mostantól befolyásolhatja a blokklánc jövőbeli tartalmát is – teheti ezt becsületesen, és a jutalmak révén növelheti ether-egyenlegét, vagy megpróbálhatja a folyamatot a saját előnyére manipulálni, kockáztatva a letétjét. A támadás egyik módja az, hogy a teljes letét nagyobb hányadát halmozzák fel, majd ezt arra használják, hogy a becsületes validátorokat túlszavazzák. Minél nagyobb a támadó által ellenőrzött letét aránya, annál nagyobb a szavazóereje, különösen bizonyos gazdasági mérföldköveknél, amelyeket később megvizsgálunk. A legtöbb támadó azonban nem lesz képes elegendő ethert felhalmozni ahhoz, hogy ilyen módon támadjon, így ehelyett finom technikákat kell alkalmazniuk, hogy manipulálják a becsületes többséget, hogy egy bizonyos módon cselekedjen. + +Alapvetően minden kis letétes támadás a validátor kétféle hibás viselkedésének variációja: az aktivitáshiány (nem vagy későn tesznek javaslatot) vagy a túlaktivitás (túl sokszor tesznek javaslatot egy sloton belül). Legegyszerűbb formájukban ezeket a műveleteket az elágazásválasztó algoritmus és az ösztönző réteg könnyen kezeli, de vannak okos módszerek arra, hogy a támadók előnyére játszhassák ki a rendszert. + +### Kis mennyiségű ETH-t használó támadások {#attacks-by-small-stakeholders} + +#### Átszervezések (reorg) {#reorgs} + +Több cikk is ismertette az Ethereum elleni olyan támadásokat, amelyek a teljes feltett ether csak kis hányadával érnek el reorgokat vagy végleges késleltetést. Ezek a támadások általában arra épülnek, hogy a támadó visszatart valamilyen információt a többi validátor elől, majd valamilyen árnyalt módon és/vagy egy alkalmas pillanatban kiadja azt. Céljuk általában az, hogy kiszorítsanak egy vagy több becsületes blokkot a kanonikus láncból. Egy tanulmány, [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf), megmutatta, hogy egy támadó validátor hogyan hozhat létre és tanúsíthat egy blokkot (`B`) egy adott `n+1` slothoz, de tartózkodhat attól, hogy azt a hálózat más csomópontjainak továbbítsa. Ehelyett a következő `n+2` slotig megtartják az igazolt blokkot. Egy becsületes validátor egy blokkot (`C`) javasol az `n+2` slotba. Ezzel szinte egyidejűleg a támadó kiadhatja a visszatartott blokkját (`B`) és az arra vonatkozó visszatartott tanúsítványait, és az `n+2` slotra leadott szavazataival azt is tanúsíthatja, hogy `B` a lánc feje, ezzel gyakorlatilag tagadva a becsületes `C` blokk létezését. Amikor a becsületes `D` blokk felszabadul, az elágazásválasztó algoritmus úgy látja, hogy a `B` tetejére épülő `D` nehezebb, mint a `C`-re épülő `D`. A támadónak tehát sikerült eltávolítania az `n+2` slotban lévő becsületes `C` blokkot a kanonikus láncból egy 1 blokkos ex ante reorg segítségével. [Egy támadónak a tét 34%-ával](https://www.youtube.com/watch?v=6vzXwwk12ZE) nagyon jó esélye van arra, hogy sikerrel járjon ebben a támadásban, amint azt [ebben a jegyzetben](https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair) kifejtettük. Elméletileg azonban ezt a támadást kisebb letétekkel is meg lehetne kísérelni. [Neuder et al 2020](https://arxiv.org/pdf/2102.02247.pdf) leírta, hogy ez a támadás 30%-os letét mellett is működik, de később kimutatták, hogy [2%-os letét mellett is életképes](https://arxiv.org/pdf/2009.04987.pdf), majd [egyetlen validátor](https://arxiv.org/abs/2110.10086#) esetén is, a következő fejezetben vizsgált kiegyensúlyozási technikák segítségével. + +![ex-ante reorg](reorg-schematic.png) + +A fent leírt egyblokkos átszervezési támadás koncepcionális ábrája (a https://notes.ethereum.org/plgVdz-ORe-fGjK06BZ_3A#Fork-choice-by-block-slot-pair oldalról átvéve) + +Egy kifinomultabb támadás a becsületes validátorok halmazát különálló csoportokra oszthatja, amelyeknek különböző nézeteik vannak a lánc fejéről. Ezt nevezik **kiegyenlítő támadásnak**. A támadó megvárja az esélyt, hogy egy blokkot javasoljon, és amikor az megérkezik, kétértelműsíti, és kettőt javasol. Az egyik blokkot a becsületes validátorok felének, a másik blokkot pedig a másik felének. Az elágazásválasztó algoritmus észlelné a kétértelműséget, és a blokkot javaslót megbüntetné és kidobná a hálózatból, de a két blokk továbbra is létezne, és a validátorok körülbelül fele tanúsítaná mindkét elágazást. Eközben a fennmaradó rosszindulatú validátorok visszatartják tanúsításaikat. Ezután az egyik vagy másik elágazást előnyben részesítő tanúsítások szelektív felszabadításával éppen elég validátornak adják át a tanúsítások felhalmozott súlyát az egyik vagy másik elágazás javára, amint az elágazásválasztó algoritmus lefut, így a tanúsítások felhalmozott súlyát az egyik vagy másik elágazás javára billentik. Ez a végtelenségig folytatódhat, a támadó validátorok pedig fenntartják a validátorok egyenletes elosztását a két elágazás között. Mivel egyik elágazás sem tud 2/3-os szupertöbbséget szerezni, a hálózat nem kerülne véglegesítésre. + +**A pattogó (bouncing) támadások** hasonlóak. A szavazatokat a támadó validátorok ismét visszatartják. Ahelyett, hogy a szavazatokat úgy adnák le, hogy a két elágazás között egyenletes legyen a felosztás, a megfelelő pillanatokban arra használják a szavazataikat, hogy olyan ellenőrzőpontokat igazoljanak, amelyek felváltva váltakoznak az A és a B elágazás között. A tanúsításnak ez a két elágazás közötti felcserélése megakadályozza, hogy olyan igazolt forrás- és célellenőrzési pontok párjai legyenek, amelyek bármelyik láncban véglegesíthetők, ami megállítja a véglegesítést. + + + +A pattogó (bouncing) és a kiegyenlítő (balancing) támadás is arra épül, hogy a támadó kifinomult irányítással rendelkezik az üzenetek időzítése felett a hálózaton keresztül, ami nem valószínű. Mindazonáltal a protokollba védelmet építettek be a gyors üzeneteknek a lassú üzenetekkel szemben adott többletsúlyozás formájában. Ez az úgynevezett [javaslattevő-súlynövelés (proposer-weight boosting)](https://github.com/ethereum/consensus-specs/pull/2730). A pattogó támadások elleni védekezés érdekében az elágazásválasztó algoritmust úgy frissítették, hogy a legutóbbi igazolt ellenőrzőpont csak [az adott korszak slotjainak első 1/3-ában](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) válthat át egy alternatív láncra. Ez a feltétel megakadályozza, hogy a támadó szavazatokat gyűjtsön a későbbi használatra – az elágazásválasztó algoritmus egyszerűen hű marad ahhoz az ellenőrzőponthoz, amelyet a korszak első 1/3-ában választott, amely idő alatt a legtöbb becsületes validátor szavazott volna. + +Együttesen ezek az intézkedések olyan forgatókönyvet hoznak létre, amelyben egy becsületes blokkajánló nagyon gyorsan kibocsátja blokkját a slot kezdete után, majd egy kb. 1/3 slotnyi (4 másodperc) időszak következik, amikor az új blokk miatt az elágazásválasztó algoritmus egy másik láncra válthat. Ugyanezen határidő után a lassú validátoroktól érkező tanúsításokat a korábban érkezett tanúsításokhoz képest lefelé súlyozzák. Ez nagymértékben kedvez a gyors ajánlattevőknek és a validátoroknak a lánc fejének meghatározásakor, és jelentősen csökkenti a sikeres kiegyenlítő (balancing) vagy pattogó (bouncing) támadás valószínűségét. + +Érdemes megjegyezni, hogy a javaslattevő erősítése önmagában csak az „olcsó reorgok” ellen véd, vagyis kis letétellel rendelkező támadó esetén. Valójában az előterjesztő-erősítés önmagában is kijátszható a nagyobb érdekeltek által. E [bejegyzés](https://ethresear.ch/t/change-fork-choice-rule-to-mitigate-balancing-and-reorging-attacks/11127) szerzői leírják, hogy egy támadó, aki a letét 7%-ával rendelkezik, hogyan vetheti be a szavazatait stratégiailag, hogy becsületes validátorok becsapásával a saját elágazására építsen, és egy becsületes blokkot átszervezzen. Ezt a támadást ideális késleltetési feltételeket feltételezve dolgozták ki, ami nagyon valószínűtlen. A támadónak kedveznek az esélyek, de a nagyobb letét nagyobb tőkekockázatot és erősebb gazdasági visszatartó erőt is jelent. + +Javasoltak egy [kiegyenlítő támadást is, amely kifejezetten az LMD-szabályt célozza](https://ethresear.ch/t/balancing-attack-lmd-edition/11853), és amely a előterjesztő-erősítés ellenére is életképesnek bizonyult. Egy támadó két versengő láncot hoz létre úgy, hogy a blokkjavaslatát egyenlővé teszi, és minden egyes blokkot a hálózat egy-egy felére terjeszti el, így megközelítőleg egyensúlyt hoz létre az elágazások között. Ezután az összejátszó validátorok kiegyenlítik a szavazataikat, úgy időzítve, hogy a hálózat fele az `A` elágazásra kapja meg először a szavazatát, a másik fele pedig a `B` elágazásra. Mivel az LMD-szabály elveti a második tanúsítást, és csak az elsőt tartja meg minden egyes validátor számára, a hálózat egyik fele csak az `A`-ra adott szavazatokat látja, a `B`-re adottakat nem; a másik fele csak a `B`-re adott szavazatokat látja, az `A`-ra adottakat nem. A szerzők leírják, hogy az LMD-szabály „figyelemre méltó hatalmat” ad az ellenségnek a kiegyenlítő támadáshoz. + +Ezt az LMD támadási vektort a [az elágazásválasztó algoritmus frissítésével](https://github.com/ethereum/consensus-specs/pull/2845) zárták le úgy, hogy az elágazásválasztásnál az egyenlőtlen validátorokat teljesen kizárja a megfontolásból. Az egyenlőtlen validátorok jövőbeli befolyását az elágazásválasztó algoritmus kihagyja a számításból. Ez megakadályozza a fent vázolt kiegyenlítő támadást, miközben a lavinatámadásokkal szembeni ellenállóképességet is fenntartja. + +A támadások egy másik osztályát, az úgynevezett [**lavinatámadásokat**](https://ethresear.ch/t/avalanche-attack-on-proof-of-stake-ghost/11854/3) egy [2022 márciusában megjelent tanulmányban](https://arxiv.org/pdf/2203.01315.pdf) írták le. A lavinatámadáshoz a támadónak több egymást követő blokkajánlót kell irányítania. A támadó minden egyes blokkjavaslati slotban visszatartja a blokkját, és addig gyűjti azokat, amíg az őszinte lánc el nem éri a visszatartott blokkokkal azonos részfa súlyát. Ezután a visszatartott blokkok felszabadulnak úgy, hogy maximálisan kiegyenlítődnek. A szerzők szerint a előterjesztő-erősítés – az elsődleges védelem a kiegyenlítő és pattogó támadások ellen – nem véd a lavinatámadás egyes változatai ellen. A szerzők azonban a támadást csak az Ethereum elágazásválasztó algoritmusának egy erősen idealizált változatán mutatták be (a GHOST-ot használták LMD nélkül). + +A lavinatámadást az LMD-GHOST elágazásválasztó algoritmus LMD része enyhíti. Az LMD jelentése a „legutolsó üzenet által vezérelt” (latest-message-driven), és az egyes validátorok által vezetett táblázatra utal, amely a többi validátortól kapott legfrissebb üzenetet tartalmazza. Ez a mező csak akkor frissül, ha az új üzenet későbbi időpontból származik, mint a táblázatban egy adott validátort illetően már szereplő üzenet. A gyakorlatban ez azt jelenti, hogy minden egyes slotban az első fogadott üzenet az, amelyet a rendszer elfogadott, és minden további üzenet kétértelműség, amelyet figyelmen kívül kell hagyni. Másképpen fogalmazva, a konszenzuskliensek nem veszik figyelembe a kétértelműséget – a validátoroktól elsőként érkező üzenetet használják, a kétértelműséget elvetik, megelőzve ezzel a lavinatámadásokat. + +Az elágazásválasztási szabály számos más lehetséges jövőbeli frissítése is létezik, amelyek növelhetik a előterjesztő-erősítés által nyújtott biztonságot. Az egyik a [nézetösszevonás](https://ethresear.ch/t/view-merge-as-a-replacement-for-proposer-boost/13739), ahol a tanúsítók `n` másodperccel egy slot kezdete előtt befagyasztják az elágazásválasztásról alkotott nézetüket, és a javaslattevő ezután segít szinkronizálni a lánc nézetét a hálózaton. Egy másik lehetséges fejlesztés az [ egy sloton belüli véglegesség (single-slot finality)](https://notes.ethereum.org/@vbuterin/single_slot_finality), amely az üzenet időzítésén alapuló támadások ellen véd azáltal, hogy a láncot egyetlen slot után véglegesíti. + +#### Véglegesség késleltetése {#finality-delay} + +[Az a cikk](https://econcs.pku.edu.cn/wine2020/wine2020/Workshop/GTiB20_paper_8.pdf), amely először írta le az alacsony költségű, egyetlen blokkot érintő reorg támadást, leírt egy végső késleltetés (liveness failure) nevű támadást is, amely arra támaszkodik, hogy a támadó egy korszakkal határos blokk javaslattevője. Ez azért kritikus, mert ezek a korszakhatárblokkok lesznek az ellenőrzőpontok, amelyeket a Casper FFG a lánc egyes részeinek véglegesítéséhez használ. A támadó egyszerűen visszatartja a blokkját, amíg elegendő becsületes validátor nem használja FFG-szavazatát az előző korszakhatárblokk javára, mint az aktuális véglegesítési cél. Ezután kiadja a visszatartott blokkot. Tanúsítja a blokkját, és a fennmaradó becsületes validátorok is ezt teszik, különböző célellenőrzési pontokkal rendelkező elágazásokat létrehozva. Ha jól időzített, akkor megakadályozza a véglegességet, mert nem lesz 2/3-os szupertöbbség, amely bármelyik elágazást tanúsítaná. Minél kisebb a letét, annál pontosabb időzítésre van szükség, mivel a támadó kevesebb tanúsítást ellenőriz közvetlenül, és annál kisebb az esélye annak, hogy a támadó ellenőrzi a validátort, amely a korszakhatárblokkot javasolja. + +#### Nagy hatótávolságú támadások {#long-range-attacks} + +Létezik egy, a proof-of-stake blokkláncokra jellemző támadási osztály is, amelynek lényege, hogy a genezisblokkban részt vevő validátor fenntartja a blokklánc egy különálló elágazását a helyes blokklánc mellett, és végül meggyőzi az őszinte validátorhalmazt, hogy később egy alkalmas időpontban váltson át rá. Ez a fajta támadás nem lehetséges az Ethereumon, mivel a véglegességi eszköz (finality gadget) biztosítja, hogy az összes validátor rendszeres időközönként (ellenőrzőpontok) megegyezzen a becsületes lánc állapotáról. Ez az egyszerű mechanizmus semlegesíti a nagy hatótávolságú támadókat, mivel az Ethereum kliensei egyszerűen nem fogják a véglegesített blokkokat újraszervezni. A hálózathoz csatlakozó új csomópontok úgy teszik ezt, hogy keresnek egy megbízható legutóbbi állapot hasht (egy [gyenge szubjektivitás](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) ellenőrzőpontot), és azt használják pszeudo-genezis blokk-ként, amelyre építkeznek. Ez egy „bizalmi bejáratot” hoz létre a hálózatba belépő új csomópont számára, mielőtt az elkezdené ellenőrizni az információkat saját maga számára. + +#### Szolgáltatásmegtagadás (DoS) {#denial-of-service} + +Az Ethereum proof-of-stake mechanizmusa minden egyes slotban egyetlen validátort választ ki a teljes validátorkészletből, aki blokkajánló lesz. Ezt egy nyilvánosan ismert függvény segítségével lehet kiszámítani, és egy támadó számára lehetséges, hogy a következő blokkelőterjesztőt beazonosítsa. Ezután a támadó eláraszthatja szeméttel (spam) a blokkelőterjesztőt, hogy megakadályozza, hogy információt cseréljen a társaival. A hálózat többi része számára úgy tűnne, hogy a blokkelőterjesztő offline, és a slot egyszerűen üresen marad. Ez egyfajta cenzúra lehet bizonyos validátorokkal szemben, megakadályozva őket abban, hogy információt adjanak hozzá a blokklánchoz. Az egyetlen, titkos vezetőválasztás (SSLE) vagy az egynél több titkos vezetőválasztás megvalósítása csökkenti a szolgáltatásmegtagadás (DoS) kockázatát, mivel mindig csak a blokkelőterjesztő tudja, hogy kiválasztották, és nem deríthető ki előre. Ez még nem valósult meg, de a [kutatás-fejlesztési](https://ethresear.ch/t/secret-non-single-leader-election/11789) terület aktívan foglalkozik vele. + +Mindezek alapján elmondható, hogy kis letétekkel nehéz sikeresen megtámadni az Ethereumot. Az itt leírt életképes támadásokhoz idealizált elágasztásválasztó algoritmusra, valószínűtlen hálózati körülményekre van szükség, vagy a támadási vektorokat már lezárták az kliensszoftver-javításokkal. Ez nem zárja ki a lehetőséget, de a kisebbségi letéttel rendelkező támadó hatékonyságát meghatározza az, hogy milyen szintű technikai képességekkel bír, a konszenzusréteg ismerete és a szerencse. A támadó szempontjából az lehet a legjobb megoldás, ha minél több ethert halmoz fel, és a teljes letét többségi hányadával próbál elérni valamit. + +### A támadók a teljes letét >=33%-át használják {#attackers-with-33-stake} + +Az eddig említett összes támadás sikerének valószínűsége megnő, ha a támadónak több letétbe helyezett ether áll rendelkezésére, amivel szavazhat, és több validátort választhat, akik blokkokat javasolhatnak az egyes slotokban. Egy rosszindulatú validátor ezért arra törekedhet, hogy minél több letétbe helyezett ethert irányítson. + +A feltett ether 33%-a egy támadó számára viszonyítási alap, mivel egy ennél nagyobb összeggel képesek megakadályozni a lánc véglegesítését anélkül, hogy a többi validátor tevékenységét irányítaniuk kellene. Egyszerűen mindannyian együtt eltűnhetnek. Ha a letétbe helyezett ether legalább 1/3-a rosszindulatúan vagy nem tanúsít, akkor a 2/3-os szupertöbbség nem állhat fenn, és a lánc nem véglegesíthető. Ez ellen az inaktivitás elszivárgással védekeznek. Az inaktivitás elszivárgás azonosítja azokat a validátorokat, akik nem vagy a többséggel ellentétesen tanúsítanak. A nem tanúsító validátorok által birtokolt letétbe helyezett ether fokozatosan elvezetésre kerül, míg végül együttesen a teljes mennyiség kevesebb mint 1/3-át képviselik, így a lánc újra véglegesedhet. + +Az inaktivitási elszivárgás célja, hogy a lánc ismét véglegesedjen. A támadó azonban a letétbe helyezett ether egy részét is elveszíti. A teljes letétbe helyezett ether 33%-át kitevő validátorok tartós inaktivitása nagyon drága, még akkor is, ha nem is kapnak súlyos és kizárással járó büntetést. + +Feltételezve, hogy az Ethereum-hálózat aszinkron (az üzenetek küldése és fogadása között késések vannak), egy támadó, aki a teljes letét 34%-át ellenőrzi, kétszeres véglegesítést okozhat. Ez azért van, mert a támadó kétértelművé teheti, ha őt választják blokkelőterjesztőnek, majd duplán szavazhat az összes validátorával. Ez olyan helyzetet teremt, amelyben a blokkláncnak egy olyan elágazása létezik, amely mellett a letétbe helyezett ether 34%-a szavazott. Mindkét elágazásra csak a fennmaradó validátorok 50%-ának kell szavaznia, hogy mindkét elágazást szupertöbbség támogassa, és így mindkét lánc véglegesíthető (mivel a támadó validátorok 34%-a + a fennmaradó 66% fele = 67% mindkét elágazásnál). Az egymással versengő blokkokat a becsületes validátorok kb. 50%-ának kellene megkapnia, így ez a támadás csak akkor életképes, ha a támadónak bizonyos fokú ellenőrzése van a hálózaton terjedő üzenetek időzítése felett, így a becsületes validátorok felét rá tudja kényszeríteni az egyes láncokra. A támadónak szükségszerűen el kellene pusztítania a teljes letétjét (kb. 10 millió ether 34%-a a mai validátorhalmazt figyelembe véve), hogy elérje ezt a kettős véglegességet, mivel a validátorok 34%-a egyszerre kétszer szavazna – ez egy súlyos és kizárással járó büntetés maximális korrelációval. Ezzel a támadással szemben az a magas költség áll, hogy a teljes letétbe helyezett ether 34%-át el kell pusztítani. A támadásból való kilábaláshoz az Ethereum közösségnek „sávon kívül” kell koordinálnia, és meg kellene állapodnia abban, hogy az egyik elágazást követi, a másikat pedig figyelmen kívül hagyja. + +### A támadók a teljes letét kb. 50%-át használják {#attackers-with-50-stake} + +A letétbe helyezett ether 50%-ánál a validátorok egy rosszindulatú csoportja elméletileg két egyforma méretű elágazásra oszthatná a láncot, majd egyszerűen felhasználhatná a teljes 50%-os letétjét arra, hogy a becsületes validátorok csoportjával ellentétesen szavazzon, így fenntartva a két elágazást és megakadályozva a véglegesítést. A két elágazáson az inaktivitási elszivárgás végül mindkét lánc véglegesítéséhez vezet. Ezen a ponton az egyetlen lehetőség a közösségi helyreállítás. + +Nagyon valószínűtlen, hogy a validátorok egy ellenséges csoportja következetesen ellenőrizni tudná a teljes letét pontosan 50%-át, mivel a becsületes validátorok száma, a hálózati késleltetés stb. változó mértékű – egy racionális támadó számára a támadás hatalmas költsége és a siker alacsony valószínűsége erős visszatartó erőnek tűnik, különösen ha a _több mint_ 50% megszerzése nagyobb hatalmat szabadít fel. + +A teljes letét >50%-ánál a támadó uralni tudta az elágazásválasztó algoritmust. Ebben az esetben a támadó képes lenne a többségi szavazattal tanúsítani, ami elegendő kontrollt adna neki ahhoz, hogy rövid átrendeződéseket hajtson végre anélkül, hogy becsületes klienseket kellene becsapnia. A becsületes validátorok követnék ezt a példát, mivel az ő elágazásválasztó algoritmusuk is a támadó által preferált láncot látná a legnehezebbnek, így a lánc véglegesedhetne. Ez lehetővé teszi a támadó számára, hogy bizonyos tranzakciókat cenzúrázzon, rövidtávú átszervezéseket végezzen, és a blokkok önérdekű átrendezésével maximális profitot (MEV) szerezzen. Ez ellen a többségi részesedés hatalmas költsége (az írás idején ez kb. 19 milliárd dollár) ad védelmet, amelyet egy támadó kockáztat, mivel a társadalmi réteg közbeléphet, és elfogadhat egy becsületes kisebbségi elágazást, ami drámaian leértékeli a támadó részesedését. + +### A támadók a teljes letét >=66%-át használják {#attackers-with-66-stake} + +Egy támadó, aki az összes letétbe helyezett ether 66%-ával vagy többel rendelkezik, véglegesítheti a preferált láncot anélkül, hogy a becsületes validátorokat kényszerítenie kellene. A támadók egyszerűen megszavazhatják a preferált elágazást, majd véglegesíthetik azt, mert tisztességtelen szupertöbbséggel szavazhatnak. A szupertöbbség birtokosaként a támadó irányítaná a véglegesített blokkok tartalmát, hatalmában állna költeni, visszatekerni és újrakölteni, cenzúrázni bizonyos tranzakciókat és tetszés szerint átszervezni a láncot. Azzal, hogy a támadó további ethert vásárol, hogy 51% helyett 66%-ot ellenőrizzen, megszerzi a képességet, hogy utólagos reorgokat és végleges visszafordításokat hajtson végre (azaz megváltoztassa a múltat és ellenőrizze a jövőt is). Az egyetlen igazi védekezés a hatalmas költség, a teljes letétbe helyezett ether 66%-a, és a közösségi rétegre támaszkodva egy alternatív elágazás elfogadásának koordinálása. Ezt a következő részben részletesebben is megvizsgáljuk. + +## Emberek: az utolsó védelmi vonal {#people-the-last-line-of-defense} + +Ha a tisztességtelen validátoroknak sikerül véglegesíteniük a lánc általuk preferált verzióját, az Ethereum-közösség nehéz helyzetbe kerül. A kanonikus lánc tartalmaz egy tisztességtelen szakaszt az előzményeibe égetve, míg a becsületes validátorok büntetést kaphatnak, ha egy alternatív (becsületes) láncot tanúsítanak. Vegye figyelembe, hogy egy véglegesített, de hibás lánc a többségi kliens hibájából is adódhat. Végül a végső megoldás az, hogy a közösségi (0.) rétegre hagyatkozunk. + +Az Ethereum proof-of-stake konszenzusának egyik erőssége, hogy a közösség számos [védekező stratégiát](https://youtu.be/1m12zgJ42dI?t=1712) alkalmazhat egy támadás esetén. A minimális válasz lehet a támadók validátorainak a hálózatból való kizárása további szankció nélkül. A hálózatba való újbóli belépéshez a támadó egy aktiválási sorba kerül, amely biztosítja, hogy a validátorok halmaza fokozatosan növekedjen. Például elegendő validátor hozzáadása ahhoz, hogy megduplázza a letétbe helyezett ether mennyiségét, körülbelül 200 napot vesz igénybe, így a becsületes validátorok 200 napot nyerhetnek, mielőtt a támadó újabb 51%-os támadást kísérelhet meg. A közösség azonban dönthet úgy is, hogy szigorúbban bünteti a támadót, visszavonva a korábbi jutalmakat, vagy elégetve a letéti tőke egy részét (vagy akár 100%-át). + +A támadóra kiszabott büntetéstől függetlenül a közösségnek közösen kell döntenie arról is, hogy a tisztességtelen lánc – annak ellenére, hogy az Ethereum-kliensekbe kódolt elágazásválasztó algoritmus előnyben részesíti – valójában érvénytelen, és a közösségnek inkább a tisztességes láncra kellene építenie. A becsületes validátorok megállapodhatnak, hogy az Ethereum blokklánc közösség által elfogadott elágazására építenek, amely például a támadás megkezdése előtt elágazhatott a kanonikus láncról, vagy a támadók validátorait eltávolíthatják. A becsületes validátorok ösztönzést kapnának arra, hogy erre a láncra építsenek, mert elkerülhetnék a büntetést, amit azért kapnának, ha (jogosan) nem tanúsítanák a támadó láncát. Az Ethereumra épülő tőzsdék, on-rampok és alkalmazások inkább a helyes láncon szeretnének lenni, és követnék a becsületes validátorokat a helyes blokkláncra. + +Ez azonban jelentős vezetési kihívást jelentene. Néhány felhasználó és validátor kétségtelenül veszítene a helyes láncra való visszaváltás következtében, a támadás után validált blokkokban lévő tranzakciókat potenciálisan visszavonnák, megzavarva az alkalmazási réteget, és ez aláássa egyes felhasználók etikai elképzeléseit, akik hajlamosak azt hinni, hogy „a kód a törvény”. A tőzsdék és az alkalmazások valószínűleg összekapcsolták a láncon kívüli műveleteket a láncon belüli tranzakciókkal, amelyeket most vissza lehet göngyölíteni, elindítva a visszavonások és felülvizsgálatok tömkelegét, amelyet nehéz lenne tisztességesen kibogozni, különösen, ha a jogtalanul szerzett nyereségeket összekeverték, DeFi-ba vagy más származékos termékekbe helyezték, amelyek másodlagos hatásokkal járnak a tisztességes felhasználók számára. Kétségtelen, hogy néhány felhasználó, talán még az intézményiek is, hasznot húztak volna a tisztességtelen láncból, ravaszságból vagy szerencsés véletlenből, és elleneznék az elágazást, hogy megvédjék a hasznukat. Elpróbálták a >51%-os támadásokra adott közösségi válaszlépéseket, hogy egy észszerű, összehangolt választ gyorsan végre lehessen hajtani. A témáról tekintse meg Vitalik hasznos eszmecseréit az ethresear.ch oldalon [itt](https://ethresear.ch/t/timeliness-detectors-and-51-attack-recovery-in-blockchains/6925) és [itt](https://ethresear.ch/t/responding-to-51-attacks-in-casper-ffg/6363), valamint a Twitteren [itt](https://twitter.com/skylar_eth/status/1551798684727508992?s=20&t=oHZ1xv8QZdOgAXhxZKtHEw). Az összehangolt társadalmi reakció célja a támadó megbüntetése és a többi felhasználóra gyakorolt hatások minimalizálása kell, hogy legyen. + +A vezetés már önmagában is bonyolult téma. Egy tisztességtelen véglegesítő láncra adott 0. rétegbeli vészreakció kezelése kihívást jelentene az Ethereum közösség számára, de ez már [megtörtént](/history/#dao-fork-summary) – [kétszer](/history/#tangerine-whistle) – az Ethereum történetében. + +Mindazonáltal van valami kielégítő abban, hogy a végső megoldás a való világban található. Végső soron, még e fenomenális technológiai rendszer ellenére is, ha a legrosszabb valaha is bekövetkezne, a valódi embereknek kellene koordinálniuk a kiutat. + +## Összegzés {#summary} + +Ez az oldal azt vizsgálta, hogy a támadók milyen módon próbálhatják meg kihasználni az Ethereum proof-of-stake konszenzus protokollját. A reorgokat és a véglegesítés késleltetését a teljes letétbe helyezett ether növekvő arányú támadók esetében vizsgáltuk. Összességében a gazdagabb támadóknak nagyobb esélyük van a sikerre, mivel a letétjük szavazati joggal jár, amellyel befolyásolni tudják a jövőbeli blokkok tartalmát. Bizonyos küszöbértékeknél a támadó ereje növekszik: -## {#pros-and-cons} +33%: késleltetett véglegesség -| | | -| | | -| | | -| | | -| | | -| | | +34%: késleltetett véglegesség, kettős véglegesség -### {#comparison-to-proof-of-work} +51%: késleltetett véglegesség, kettős véglegesség, cenzúra, a blokklánc jövőjének ellenőrzése -Több cikk is ismertette az Ethereum elleni olyan támadásokat, amelyek a teljes feltett ether csak kis hányadával érnek el reorgokat vagy végleges késleltetést. Ezek a támadások általában arra épülnek, hogy a támadó visszatart valamilyen információt a többi validátor elől, majd valamilyen árnyalt módon és/vagy egy alkalmas pillanatban kiadja azt. +66%: késleltetett véglegesség, kettős véglegesség, cenzúra, a blokklánc jövőjének és múltjának ellenőrzése -- -- -- -- -- -- +Létezik egy sor kifinomultabb támadás is, amelyekhez kis mennyiségű letétbe helyezett ether is elég, de egy kifinomult támadó kell hozzá, aki az üzenet időzítése felett kontrollt gyakorol, hogy a saját javára befolyásolja a becsületes validátorok halmazát. -## {#further-reading} +Összességében, ezen potenciális támadási vektorok ellenére a sikeres támadás kockázata alacsony, minden bizonnyal alacsonyabb, mint a proof-of-worknél. Mivel a támadó, aki a becsületes validátorok szavazati erejével elnyomja a becsületes validátorokat, a letétbe helyezett ether költségét kockáztatja. A beépített „jutalmazás-büntetés” ösztönző réteg megvéd a legtöbb visszaéléstől, különösen az alacsony letéttel rendelkező támadóktól. A kifinomultabb pattogó és kiegyenlítő támadások szintén nem valószínű, hogy sikerrel járnak, mivel a valós hálózati feltételek miatt nehéz elérni az üzenetek kézbesítésének szabályozását a validátorok meghatározott részhalmazaihoz, és a klienscsapatok egyszerű javításokkal lezárták az ismert pattogó, kiegyenlítő és lavinatámadási vektorokat. -- -- -- -- -- -- []() -- -- []() +A 34%-os, 51%-os vagy 66%-os támadások sávon kívüli társadalmi koordinációt igényelnek a megoldásához. Bár ez valószínűleg fájdalmas lenne a közösség számára, a sávon kívüli válaszadás képessége erős visszatartó erőt jelent a támadóknak. Az Ethereum közösségi rétege a végső biztosíték – egy technikailag sikeres támadást még mindig ki lehet iktatni azzal, hogy a közösség elfogad egy becsületes elágazást. A támadó és az Ethereum közösség versenyt futna – a 66%-os támadásra költött dollármilliárdokat egy sikeres közösségi koordináció eltörölné, ha elég gyorsan végzik, így a támadó rengeteg nem likvid etherrel maradna egy tisztességtelen láncon, amelyet az Ethereum közösség figyelmen kívül hagy. Alacsony a valószínűsége, hogy ez a támadónak végül nyereséget hoz, ezért hatékony visszatartóerőt jelent. Ezért olyan fontos a szorosan összehangolt értékekkel rendelkező, összetartó közösségi réteg fenntartása. -## {#related-topics} +## További olvasnivaló {#further-reading} -- []() -- []() +- [A jelen írás részletesebb változata](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [Vitalik az elszámolási véglegességről](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) +- [Az LMD GHOST leírása](https://arxiv.org/abs/2003.03052) +- [A Casper-FFG leírása](https://arxiv.org/abs/1710.09437) +- [A Gasper leírása](https://arxiv.org/pdf/2003.03052.pdf) +- [A javaslattevő-erősítéses konszenzus specifikációi](https://github.com/ethereum/consensus-specs/pull/2730) +- [Pattogó támadások az ethresear.ch oldalon](https://ethresear.ch/t/prevention-of-bouncing-attack-on-ffg/6114) +- [SSLE-kutatás](https://ethresear.ch/t/secret-non-single-leader-election/11789) diff --git a/public/content/translations/hu/developers/docs/scaling/optimistic-rollups/index.md b/public/content/translations/hu/developers/docs/scaling/optimistic-rollups/index.md index 522182424e0..441912d26df 100644 --- a/public/content/translations/hu/developers/docs/scaling/optimistic-rollups/index.md +++ b/public/content/translations/hu/developers/docs/scaling/optimistic-rollups/index.md @@ -253,12 +253,6 @@ Az [adat sharding](/roadmap/danksharding/) bevezetése az Ethereumban várhatóa -### Optimista összevont tranzakciók használata {#use-optimistic-rollups} - -Az optimista összevont tranzakcióknak többféle megvalósítása létezik, amelyeket integrálhat a dappjaiba: - - - ## További információk az optimista összevont tranzakciókról - [Hogyan működnek az optimista összevont tranzakciók (teljes útmutató)](https://www.alchemy.com/overviews/optimistic-rollups) diff --git a/public/content/translations/hu/developers/docs/scaling/state-channels/index.md b/public/content/translations/hu/developers/docs/scaling/state-channels/index.md deleted file mode 100644 index 257a88b9257..00000000000 --- a/public/content/translations/hu/developers/docs/scaling/state-channels/index.md +++ /dev/null @@ -1,67 +0,0 @@ ---- -title: Státuszcsatornák -description: Bevezetés a státusz- és fizetési csatornákba, az Ethereum közössége által használt skálázási megoldásba. -lang: hu -sidebarDepth: 3 ---- - -A státuszcsatornák lehetővé teszik a résztvevők számára, hogy biztonságosan tranzakciókat bonyolítsanak le a láncon kívül, miközben minimálisra csökkentik az Ethereum főhálózattal való interakciót. A csatornát alkotó résztvevők tetszőleges számú, a láncon kívüli tranzakciót hajthatnak végre, melyhez csak két láncon belüli tranzakciót kell beküldeniük csatorna megnyitásához és lezárásához. Ez rendkívül nagy tranzakcióátvitelt tesz lehetővé, és alacsonyabb költségeket eredményez a felhasználók számára. - -## {#how-do-sidechains-work} - -A nyilvános blokkláncok, mint például az Ethereum, az elosztott architektúrájuk miatt skálázhatósági kihívásokkal küzdenek: a láncban végrehajtott tranzakciókat az összes csomópontnak végre kell hajtania. A csomópontoknak képesnek kell lenniük arra, hogy egy blokkban lévő tranzakciók mennyiségét szerény hardverrel kezeljék, hogy a hálózat decentralizált maradjon, de ez korlátozza a tranzakcióátviteli sebességet. - -### {#consensus-algorithms} - -A csatornák olyan egyszerű társközi (peer-to-peer) protokollok, amelyek lehetővé teszik, hogy két fél számos tranzakciót hajtson végre egymás között, és csak a végeredményt tegyék fel a blokkláncra. A csatorna kriptográfiát használ annak bizonyítására, hogy az általuk generált összesített adatok valóban érvényes köztes tranzakciók eredményei. Egy [több aláírásos](/developers/docs/smart-contracts/#multisig) okosszerződés biztosítja, hogy a tranzakciókat a megfelelő felek írják alá. - -- []() -- []() -- - -A csatornák segítségével a státuszváltozásokat az érdekelt felek hajtják végre és érvényesítik, minimalizálva az Ethereum végrehajtási rétegének számításait. Ez csökkenti a torlódásokat az Ethereumon, és növeli a tranzakciók feldolgozási sebességét a felhasználók számára. - -#### {#block-parameters} - -Minden csatornát egy [több aláírásos okosszerződés](/developers/docs/smart-contracts/#multisig) kezel, amely az Ethereumon fut. Egy csatorna megnyitásához a résztvevők telepítik a csatornaszerződést a láncban, és pénzt helyeznek el benne. - -A csatorna lezárásához a résztvevők elküldik a csatorna utolsó elfogadott státuszát a láncba. Ezt követően az okosszerződés a zárolt pénzeszközöket az egyes résztvevőknek a csatorna végső státuszában lévő egyenlege szerint osztja szét. - -A peer-to-peer csatornák különösen hasznosak olyan helyzetekben, amikor néhány előre meghatározott résztvevő nagy gyakorisággal kíván tranzakciókat lebonyolítani anélkül, hogy az többletterhekkel járna. A blokklánc-csatornák két kategóriába sorolhatók: **fizetési** és **státuszcsatornák**. - -### {#evm-compatibility} - -A fizetési csatornát leginkább úgy lehet leírni, mint két felhasználó által közösen vezetett „kétirányú főkönyvet”. A főkönyv kezdeti egyenlege a csatornanyitási fázisban a láncban lévő szerződésbe zárolt betétek összege. - -A főkönyv egyenlegének (azaz a fizetési csatorna státuszának) frissítéséhez a csatorna összes résztvevőjének jóváhagyása szükséges. A csatorna résztvevői által aláírt csatornaváltozás véglegesítettnek tekinthető, hasonlóan az Ethereumban végrehajtott tranzakciókhoz. - -A fizetési csatornák a legkorábbi skálázási megoldások közé tartoztak, amelyek célja az egyszerű felhasználói interakciók (pl. ETH átutalások, atomikus átváltások, mikrofizetések) költséges láncon belüli tevékenységének minimalizálása volt. A csatorna résztvevői korlátlan mennyiségű azonnali, illeték nélküli tranzakciót hajthatnak végre egymás között mindaddig, amíg az átutalások nettó összege nem haladja meg a letétbe helyezett tokeneket. - -A láncon kívüli fizetések támogatásán kívül a fizetési csatornák nem bizonyultak hasznosnak az általános státuszváltozási logika kezelésére. A státuszcsatornákat azért hozták létre, hogy megoldják ezt a problémát, és azok támogassák az általános célú számítások skálázását. - -### {#asset-movement} - -A státuszcsatornáknak sok közös vonásuk van a fizetési csatornákkal. A felhasználók például kriptográfiailag aláírt üzenetek (tranzakciók) cseréjével lépnek kapcsolatba egymással, amelyeket a csatorna többi résztvevőjének is alá kell írnia. Ha egy javasolt státuszváltozást nem ír alá minden résztvevő, az érvénytelennek minősül. - -## {#pros-and-cons-of-sidechains} - -| | | -| | | -| | | -| | | -| | | -| | | - -### {#use-sidechains} - -- []() -- []() -- []() -- []() -- []() - -## {#further-reading} - -- - -_ _ diff --git a/public/content/translations/hu/developers/docs/scaling/zk-rollups/index.md b/public/content/translations/hu/developers/docs/scaling/zk-rollups/index.md index 4caff0bbfd0..9e95a34dc42 100644 --- a/public/content/translations/hu/developers/docs/scaling/zk-rollups/index.md +++ b/public/content/translations/hu/developers/docs/scaling/zk-rollups/index.md @@ -222,12 +222,6 @@ Nézze meg a videót, melyben a Finematics elmagyarázza a ZK összevont tranzak -### ZK összevont tranzakciók használata {#use-zk-rollups} - -A ZK összevont tranzakcióknak többféle megvalósítása létezik, amelyeket integrálhat a dappjaiba: - - - ## Kik dolgoznak zkEVM-en? {#zkevm-projects} Többek között az alábbi projektek dolgoznak zkEVM-en: diff --git a/public/content/translations/hu/developers/docs/standards/tokens/erc-777/index.md b/public/content/translations/hu/developers/docs/standards/tokens/erc-777/index.md deleted file mode 100644 index 69264f5cbbb..00000000000 --- a/public/content/translations/hu/developers/docs/standards/tokens/erc-777/index.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -title: ERC-777 tokenszabvány -description: -lang: hu ---- - -## {#introduction} - -**** - -**** - -A hook vagy horog az okosszerződés kódjában leírt funkciót jelent. Akkor kerülnek meghívásra, amikor a szerződésen keresztül tokeneket küldenek vagy fogadnak. Ez lehetővé teszi, hogy az okosszerződés reagáljon a bejövő vagy kimenő tokenekre. - -## {#prerequisites} - -- []() -- []() -- []() - -## {#body} - -A horgokat az [ERC-1820](https://eips.ethereum.org/EIPS/eip-1820)-as szabvány segítségével regisztrálják és fedezik fel. - -A szabvány megoldja az ERC-20-ban a `decimals` körül kialakult zavart is. Ez az egyértelműség javítja a fejlesztői élményt. - -Az ERC-777-es szerződésekkel úgy lehet interakcióba lépni, mintha ERC-20-as szerződések lennének. - -### {#methods} - -```solidity - -``` - -### {#events} - -```solidity - -``` - -### {#web3py-example} - -#### {#web3py-example} - -``` - -``` - -```python - - - - -``` - -```python - - -``` - -## {#popular-nfts} - -- -- -- -- -- -- -- -- - -## További olvasnivaló {#further-reading} - -- []() -- []() -- []() -- []() diff --git a/public/content/translations/hu/staking/solo/index.md b/public/content/translations/hu/staking/solo/index.md index d011301a23b..84cd4df4c08 100644 --- a/public/content/translations/hu/staking/solo/index.md +++ b/public/content/translations/hu/staking/solo/index.md @@ -203,4 +203,4 @@ A teljes egyenleg visszavonásához végig kell menni a validátorkiléptetési - [Lépésről lépésre: hogyan kell csatlakozni az Ethereum 2.0 teszthálózathoz](https://kb.beaconcha.in/guides/tutorial-eth2-multiclient) – _Butta_ - [Eth2 Slashing elkerülési tippek](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) – _Raul Jordan 2020._ - +