From a7f2ed2d524dfdff26a3bd4387bae4aacaba0a78 Mon Sep 17 00:00:00 2001 From: Joshua <62268199+minimalsm@users.noreply.github.com> Date: Sat, 14 Feb 2026 00:11:17 +0000 Subject: [PATCH] i18n(ta): translation import part 03 of 13 (24 files) --- .../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 | 102 ++ .../pos/pos-vs-pow/index.md | 69 ++ .../pos/rewards-and-penalties/index.md | 91 ++ .../pos/weak-subjectivity/index.md | 39 + .../pos/withdrawal-credentials/index.md | 64 ++ .../docs/consensus-mechanisms/pow/index.md | 114 ++ .../consensus-mechanisms/pow/mining/index.md | 86 ++ .../dagger-hashimoto/index.md | 331 ++++++ .../mining/mining-algorithms/ethash/index.md | 1023 +++++++++++++++++ .../pow/mining/mining-algorithms/index.md | 42 + .../ta/developers/docs/dapps/index.md | 96 ++ .../block-explorers/index.md | 254 ++++ .../docs/data-and-analytics/index.md | 72 ++ .../index.md | 118 ++ .../docs/data-availability/index.md | 84 ++ .../data-structures-and-encoding/index.md | 32 + .../patricia-merkle-trie/index.md | 280 +++++ .../data-structures-and-encoding/rlp/index.md | 165 +++ .../data-structures-and-encoding/ssz/index.md | 153 +++ 24 files changed, 3699 insertions(+) create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/attestations/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/block-proposal/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/faqs/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/gasper/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/keys/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pow/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md create mode 100644 public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md create mode 100644 public/content/translations/ta/developers/docs/dapps/index.md create mode 100644 public/content/translations/ta/developers/docs/data-and-analytics/block-explorers/index.md create mode 100644 public/content/translations/ta/developers/docs/data-and-analytics/index.md create mode 100644 public/content/translations/ta/developers/docs/data-availability/blockchain-data-storage-strategies/index.md create mode 100644 public/content/translations/ta/developers/docs/data-availability/index.md create mode 100644 public/content/translations/ta/developers/docs/data-structures-and-encoding/index.md create mode 100644 public/content/translations/ta/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md create mode 100644 public/content/translations/ta/developers/docs/data-structures-and-encoding/rlp/index.md create mode 100644 public/content/translations/ta/developers/docs/data-structures-and-encoding/ssz/index.md diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/attestations/index.md new file mode 100644 index 00000000000..5329f69d008 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -0,0 +1,92 @@ +--- +title: "சான்றளிப்புகள்" +description: "பங்குச் சான்று எத்தேரியத்தில் உள்ள சான்றளிப்புகள் பற்றிய விளக்கம்." +lang: ta +--- + +ஒரு வரையாளர் ஒவ்வொரு யுகத்தில் (6.4 நிமிடங்கள்) ஒரு அங்கீகாரம் உருவாக்க, கையொப்பமிட மற்றும் ஒளிபரப்ப வேண்டியதாகும். இந்த பக்கம் இந்த அங்கீகாரங்கள் எப்படி தெரிகின்றன மற்றும் எவ்வாறு செயலாக்கப்படுகிறதையும், அணிவகுப்புக் கிளையிடங்களுக்கிடையில் எவ்வாறு தகவல்களைப் பரிமாறுகிறதையும் விளக்குகிறது. + +## அங்கீகாரம் என்பது என்ன? {#what-is-an-attestation} + +ஒவ்வொரு [யுகத்திலும்](/glossary/#epoch) (6.4 நிமிடங்கள்) ஒரு சரிபார்ப்பவர் நெட்வொர்க்கிற்கு ஒரு சான்றளிப்பை முன்மொழிகிறார். அந்த அங்கீகாரம் குறிப்பிட்ட ஒரு ஸ்லாட் ஆகும். சான்றளிப்பின் நோக்கம், சங்கிலி குறித்த சரிபார்ப்பவரின் பார்வைக்கு ஆதரவாக வாக்களிப்பதாகும், குறிப்பாக மிகச் சமீபத்திய நியாயப்படுத்தப்பட்ட தொகுதி மற்றும் தற்போதைய யுகத்தில் முதல் தொகுதி (`மூல` மற்றும் `இலக்கு` சரிபார்ப்புப் புள்ளிகள் என அழைக்கப்படுபவை). இந்தத் தகவல்களை அனைத்து பங்கேற்பாளர் வரையலர்களும் சேர்த்துப், நெட்வொர்க் ன் பிளாக்கின் நிலைமையைப் பற்றிய சம்மேளனம் அடைய உதவுகிறது. + +அங்கீகாரம் பின்வருமாறு கூறப்படும் கூறுகளைக் கொண்டுள்ளது: + +- `aggregation_bits`: சரிபார்ப்பவர்களின் ஒரு பிட்லிஸ்ட், இதில் நிலை (position) அவர்களின் கமிட்டியில் உள்ள சரிபார்ப்பவர் குறியீட்டைக் குறிக்கிறது; மதிப்பு (0/1) சரிபார்ப்பவர் `data`-வில் கையொப்பமிட்டாரா என்பதைக் குறிக்கிறது (அதாவது, அவர்கள் செயலில் உள்ளார்களா மற்றும் தொகுதி முன்மொழிபவருடன் உடன்படுகிறார்களா என்பது). +- `data`: சான்றளிப்பு தொடர்பான விவரங்கள், கீழே வரையறுக்கப்பட்டுள்ளபடி +- `signature`: தனிப்பட்ட சரிபார்ப்பவர்களின் கையொப்பங்களைத் திரட்டும் ஒரு BLS கையொப்பம் + +ஒரு சான்றளிக்கும் சரிபார்ப்பவருக்கான முதல் பணி `data`-ஐ உருவாக்குவதாகும். `data` பின்வரும் தகவல்களைக் கொண்டுள்ளது: + +- `slot`: சான்றளிப்பு குறிப்பிடும் ஸ்லாட் எண் +- `index`: கொடுக்கப்பட்ட ஸ்லாட்டில் சரிபார்ப்பவர் எந்தக் கமிட்டியைச் சேர்ந்தவர் என்பதைக் குறிப்பிடும் எண் +- `beacon_block_root`: சங்கிலியின் தொடக்கத்தில் சரிபார்ப்பவர் காணும் தொகுதியின் ரூட் ஹாஷ் (fork-choice நெறிமுறையைப் பயன்படுத்துவதன் விளைவு) +- `source`: சரிபார்ப்பவர்கள் மிகச் சமீபத்திய நியாயப்படுத்தப்பட்ட தொகுதியாகக் காண்பதைக் குறிக்கும் இறுதித்தன்மை வாக்கெடுப்பின் ஒரு பகுதி +- `target`: சரிபார்ப்பவர்கள் தற்போதைய யுகத்தின் முதல் தொகுதியாகக் காண்பதைக் குறிக்கும் இறுதித்தன்மை வாக்கெடுப்பின் ஒரு பகுதி + +`data` உருவாக்கப்பட்டவுடன், சரிபார்ப்பவர் `aggregation_bits` இல் தங்களது சொந்த சரிபார்ப்பவர் குறியீட்டிற்குரிய பிட்டை 0 இலிருந்து 1 ஆக மாற்றி, தாங்கள் பங்கேற்றதைக் காட்டலாம். + +இறுதியில், வரையலர் அங்கீகாரத்திற்கான கையொப்பத்தைச் செய்து, அதை நெட்வொர்க்குக்கு ஒளிபரப்புகிறார். + +### திரட்டப்பட்ட சான்றளிப்பு {#aggregated-attestation} + +ஒவ்வொரு வரையலருக்கும் தரவை நெட்வொர்க்கில் ஒளிபரப்புவதற்கு ஏற்பப் பெரும்பாலான மேலாண்மையைக் கொண்டுள்ளது. எனவே, தனித்துவமான வரையலர்களின் அங்கீகாரங்கள் ஒளிபரப்பதற்கு முன் சப் நெட்வொர்க்களில் சேர்க்கப்படுகின்றன. ஒரே `data`-வுடன் உடன்படும் அனைத்து சரிபார்ப்பவர்களின் கையொப்பங்களையும் ஒன்றாகத் திரட்டுவது இதில் அடங்கும். இதன் மூலம், ஒளிபரப்பப்படும் சான்றளிப்பில் ஒருமித்த `data`-வும், அந்த `data`-வை ஏற்கும் அனைத்து சரிபார்ப்பவர்களின் கையொப்பங்களையும் இணைத்து உருவாக்கப்பட்ட ஒரு ஒற்றைக் கையொப்பமும் அடங்கியிருக்கும். `aggregation_bits`-ஐப் பயன்படுத்தி இதைச் சரிபார்க்கலாம். ஏனெனில் இது ஒவ்வொரு சரிபார்ப்பவரின் கமிட்டியிலுள்ள குறியீட்டை வழங்குகிறது (`data`-வில் அதன் ID கொடுக்கப்பட்டுள்ளது). இதைப் பயன்படுத்தி தனிப்பட்ட கையொப்பங்களைக் கண்டறியலாம். + +ஒவ்வொரு யுகத்திலும் ஒவ்வொரு சப்நெட்டிலும் 16 சரிபார்ப்பவர்கள் `aggregators` (திரட்டிகளாக) தேர்ந்தெடுக்கப்படுகிறார்கள். திரட்டிகள் (aggregators) தங்கள் சொந்த `data`-விற்கு சமமான `data`-வைக் கொண்ட, gossip நெட்வொர்க்கில் அவர்கள் கேட்கும் அனைத்து சான்றளிப்புகளையும் சேகரிக்கின்றன. பொருந்தும் ஒவ்வொரு சான்றளிப்பின் அனுப்புநரும் `aggregation_bits`-இல் பதிவு செய்யப்படுகிறார். பின்னர், தொகுப்பாளர்கள் அங்கீகாரத்தை பரவலாக நெட்வொர்க்கில் ஒளிபரப்புகிறார்கள். + +ஒரு வரையலர் பிளாக் முன்மொழியவராகத் தேர்விக்கப்பட்டபோது, அவர்கள் புதிய பிளாக்கில் உள்ள. latest slot வரை சப் நெட்வொர்க்களிலிருந்து மொத்த அங்கீகாரங்களை ஒழுங்கமைக்கிறார்கள். + +### சான்றளிப்பு உள்ளடக்கத்தின் வாழ்க்கைச் சுழற்சி {#attestation-inclusion-lifecycle} + +1. உருவாக்கம் +2. பரப்புதல் +3. சேர்க்கை +4. பரப்புதல் +5. சேர்ப்பு + +அங்கீகாரத்தின் வாழ்க்கைச் சுழற்சி கீழே உள்ள வடிவத்தில் விளக்கப்படுகிறது: + +![சான்றளிப்பு வாழ்க்கைச் சுழற்சி](./attestation_schematic.png) + +## பரிசுகள் {#rewards} + +வரையலர்கள் அங்கீகாரங்களை சமர்ப்பிப்பதற்கான இலாபங்களைப் பெறுகிறார்கள். அங்கீகார இலாபம் பங்கேற்பு புள்ளிகள் (source, target, மற்றும் head), அடிப்படை இலாபம் மற்றும் பங்கேற்பு அளவுகோலின் அடிப்படையில் மாறுபடுகிறது. + +ஒவ்வொரு பங்கேற்பு புள்ளியும் உண்மையானது அல்லது பொய்யானதாக இருக்கலாம், சமர்ப்பிக்கப்பட்ட அங்கீகாரம் மற்றும் அதன் சேர்க்கை தாமதத்தின் அடிப்படையில். + +மூன்று புள்ளிகளும் உண்மையானது என்ற சிறந்த நிலைமை நிகழும்போது, வரையலர் (ஒவ்வொரு சரியான புள்ளிக்கு): + +`reward += base reward * flag weight * flag attesting rate / 64` + +புள்ளி அங்கீகார அளவுகோல், குறிப்பிட்ட புள்ளிக்கு அனைத்து அங்கீகாரமான வரையலர்களின் செயல்திறன் இருப்புகளைச் சேர்த்து, மொத்த செயல்திறன் இருப்பின் ஒத்திக்கையுடன் அளவிடப்படுகிறது. + +### அடிப்படை வெகுமதி {#base-reward} + +அடிப்படை இலாபம், அங்கீகாரமான வரையலர்களின் எண்ணிக்கை மற்றும் அவர்களது செயல்திறன் நாட்டத்தை அடிப்படையாகக் கொண்டு கணக்கிடப்படுகிறது: + +`அடிப்படை வெகுமதி = சரிபார்ப்பவர் செயலிலுள்ள இருப்பு x 2^6 / SQRT(அனைத்து செயலிலுள்ள சரிபார்ப்பாளர்களின் செயலிலுள்ள இருப்பு)` + +#### உள்ளடக்க தாமதம் {#inclusion-delay} + +சரிபார்ப்பவர்கள் சங்கிலியின் தலைப்பில் (`தொகுதி n`) வாக்களித்த நேரத்தில், `தொகுதி n+1` இன்னும் முன்மொழியப்படவில்லை. எனவே, சான்றளிப்புகள் இயல்பாகவே **ஒரு தொகுதிக்குப் பிறகு** சேர்க்கப்படுகின்றன. அதனால் `தொகுதி n`-ஐ சங்கிலியின் தலைமையாகக் கொண்டு வாக்களித்த அனைத்து சான்றளிப்புகளும் `தொகுதி n+1`-இல் சேர்க்கப்பட்டன, மற்றும், **உள்ளடக்க தாமதம்** 1 ஆகும். சேர்க்கை தாமதம் இரண்டு ஸ்லாட்களாக இரட்டிப்பானால், அங்கீகார இலாபம் அரை ஆகும், ஏனெனில் அங்கீகார இலாபத்தைக் கணக்கிட, அடிப்படை இலாபம் சேர்க்கை தாமதத்தின் எதிர்மறை வீதத்துடன் பெருக்கப்படுகிறது. + +### சான்றளிப்பு காட்சிகள் {#attestation-scenarios} + +#### காணாமல்போன வாக்களிக்கும் சரிபார்ப்பவர் {#missing-voting-validator} + +வரையலர்கள் தங்கள் அங்கீகாரத்தை சமர்ப்பிக்க அதிகபட்சமாக 1 யுகம் நேரம் கொண்டிருக்கிறார்கள். அங்கீகாரம் யுகம் 0 இல் தவறானால், அவர்கள் யுகம் 1 இல் சேர்க்கை தாமதத்துடன் அதைச் சமர்ப்பிக்க முடியும். + +#### காணாமல்போன திரட்டி {#missing-aggregator} + +ஒவ்வொரு யுகத்திலும் மொத்தமாக 16 தொகுப்பாளர்கள் உள்ளனர். கூடுதலாக, தோராயமாகத் தேர்ந்தெடுக்கப்பட்ட சரிபார்ப்பவர்கள் **256 யுகங்களுக்கு இரண்டு சப்நெட்களுக்கு** சந்தா செலுத்தி, திரட்டிகள் (aggregators) இல்லாத பட்சத்தில் காப்புப்பிரதியாகச் செயல்படுகின்றனர். + +#### காணாமல்போன தொகுதி முன்மொழிபவர் {#missing-block-proposer} + +சில சந்தர்ப்பங்களில், ஒரு அதிர்ஷ்டசாலி தொகுப்பாளர் பிளாக் முன்மொழியவராகவும் மாறலாம் என்பதை நினைவில் கொள்ளுங்கள். பிளாக் முன்மொழியவர் காணாமல் போனதால் அங்கீகாரம் சேர்க்கப்படாவிட்டால், அடுத்த பிளாக் முன்மொழியவர் மொத்த அங்கீகாரத்தை எடுத்து, அடுத்த பிளாக்கில் சேர்க்குவார். இருப்பினும், **உள்ளடக்க தாமதம்** ஒன்றால் அதிகரிக்கும். + +## மேலும் வாசிக்க {#further-reading} + +- [விட்டலிக்கின் சிறுகுறிப்பு ஒருமித்த விவரக்குறிப்பில் சான்றளிப்புகள்](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#attestationdata) +- [eth2book.info-வில் சான்றளிப்புகள்](https://eth2book.info/capella/part3/containers/dependencies/#attestationdata) + +_உங்களுக்கு உதவிய ஒரு சமூக வளம் பற்றி தெரியுமா?_ இந்தப் பக்கத்தைத் திருத்தி அதைச் சேர்க்கவும்!_ diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/block-proposal/index.md new file mode 100644 index 00000000000..fa18d9826e8 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -0,0 +1,69 @@ +--- +title: "தொகுதி முன்மொழிவு" +description: "பங்குச் சான்று எத்தேரியத்தில் தொகுதிகள் எவ்வாறு முன்மொழியப்படுகின்றன என்பதற்கான விளக்கம்." +lang: ta +--- + +பிளாக்குகள் பிளாக்க்செயினின் அடிப்படை அலகுகள் ஆகும். பிளாக்குகள் ஒவ்வொரு நொட்டை மத்தியில் ஒழுங்கமைக்கப்பட்ட, ஒப்புக்கொள்ளப்பட்ட மற்றும் ஒவ்வொரு நொட்டின் தரவுத்தளத்தில் சேர்க்கப்பட்ட தகவல்களின் தனியான அலகுகள் ஆகும். இத்தொகுப்பு எவ்வாறு உருவாக்கப்படுவதாகும் என்பதை விளக்குகிறது. + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +பிளாக் முன்மொழிதல், proof-of-stake ஒரு பகுதியாகும். இந்தப் பக்கத்தைப் புரிந்துகொள்ள, [பங்குச் சான்று](/developers/docs/consensus-mechanisms/pos/) மற்றும் [தொகுதி கட்டமைப்பு](/developers/docs/blocks/) பற்றிப் படிக்குமாறு நாங்கள் பரிந்துரைக்கிறோம். + +## யார் பிளாக்குகளை உருவாக்குகிறார்? தொகுதிகளை உருவாக்குவது யார்? {#who-produces-blocks} + +வரையலர் கணக்குகள் பிளாக்குகளை முன்மொழிக்கிறார்கள். வரையலர் கணக்குகள், அவர்களது செயலாக்க மற்றும் ஒப்புதலாளர் கிளையிடங்களின் ஒரு பகுதியாக வரையலர் மென்பொருளை இயக்கும் நொட் இயக்குனர்களால் நிர்வகிக்கப்படுகிறார்கள் மற்றும் காப்பீட்டு ஒப்பந்தத்தில் குறைந்தது 32 ETH வைச் சேர்க்கிறார்கள். எனினும், ஒவ்வொரு வரையலரும் சற்றும் குறைவாகப் பிளாக்கை முன்மொழிக்கும் பொறுப்பில் இருக்கும். எத்தீரியம் நேரத்தை ஸ்லாடுகள் மற்றும் யுகங்களில் அளவிடுகிறது. ஒவ்வொரு ஸ்லாடும் பதினைந்து வினாடிகள், மேலும் 32 ஸ்லாடுகள் (6.4 நிமிடங்கள்) ஒரு யுகத்தை உருவாக்குகின்றன. ஒவ்வொரு ஸ்லாடும் எத்தீரியத்தில் புதிய பிளாக்கை சேர்க்கும் ஒரு வாய்ப்பு ஆகும். + +### சீரற்ற தேர்வு {#random-selection} + +ஒவ்வொரு ஸ்லாடிலும் ஒரு ஒற்றை வரையலர் பிளாக்கை முன்மொழிக்க சுயாதீனமாகத் தேர்வு செய்யப்படுகிறது. ஒரு பிளாக்க்செயினில் உண்மையான சீரற்ற தன்மை இல்லை, ஏனெனில் ஒவ்வொரு நொடும் உண்மையான சீரற்ற எண்களை உருவாக்கினால், அவர்கள் ஒப்புக்கொள்வதில் எடுக்க முடியாது. அதற்குப் பதிலாக, வரையலர் தேர்வுப் பணி அசாதாரணமாக இருக்க வேண்டும். எத்தீரியத்தில், பிளாக்கு முன்மொழியரின் ஹாஷ் மற்றும் ஒவ்வொரு பிளாக்கும் புதுப்பிக்கப்படும் ஒரு விதை (seed) கலக்கும் RANDAO என்ற அல்கரிதம் மூலம் சீரற்ற தன்மை பெறப்படுகிறது. இந்த மதிப்பு மொத்த வரையலர் தொகுப்பிலிருந்து குறிப்பிட்ட வரையலரை தேர்வு செய்யப் பயன்படுத்தப்படுகிறது. சில விதை முறையைத் தவிர்க்க, வரையலர் தேர்வு இரண்டு யுகங்கள் முன்னதாக நிலைநாட்டப்படுகிறது. + +எனினும், வரையலர்கள் ஒவ்வொரு ஸ்லாடிலும் RANDAO யில் சேர்த்தாலும், உலகளாவிய RANDAO மதிப்பு ஒவ்வொரு யுகத்திலும் ஒரு முறை மட்டுமே புதுப்பிக்கப்படுகிறது. அடுத்த பிளாக் முன்மொழியரின் அடையாளத்தைக் கணக்கிட, RANDAO மதிப்பு ஸ்லாட் எண்ணுடன் கலக்கப்படுகிறது, இதன் மூலம் ஒவ்வொரு ஸ்லாடிலும் தனித்துவமான மதிப்பு கிடைக்கிறது. ஒரு தனிப்பட்ட சரிபார்ப்பாளர் தேர்ந்தெடுக்கப்படுவதற்கான நிகழ்தகவு வெறுமனே `1/N` அல்ல (இங்கு `N` = மொத்த செயலில் உள்ள சரிபார்ப்பாளர்களின் எண்ணிக்கை). அதற்குப் பதிலாக, ஒவ்வொரு வரையலரின் செயல்திறன் ETH இருப்பின் அடிப்படையில் அதிகரிக்கப்படுகிறது. அதிகபட்ச பயனுள்ள இருப்பு 32 ETH ஆகும் (இதன் பொருள் `இருப்பு < 32 ETH` என்பது `இருப்பு == 32 ETH` ஐ விட குறைந்த எடையிடலுக்கு வழிவகுக்கிறது, ஆனால் `இருப்பு > 32 ETH` என்பது `இருப்பு == 32 ETH` ஐ விட அதிக எடையிடலுக்கு வழிவகுக்காது). + +ஒவ்வொரு ஸ்லாடிலும் ஒரு மட்டுமே பிளாக் முன்மொழியர் தேர்வு செய்யப்படுகிறது. சாதாரண நிலைமைகளில், ஒரே பிளாக் தயாரிப்பாளர் தனது குறிப்பிட்ட ஸ்லாட்டில் ஒரு மட்டும் பிளாக்கை உருவாக்கி வெளியிடுகிறான். ஒரே ஸ்லாட்டிற்கான இரண்டு பிளாக்குகளை உருவாக்குவது ஒரு தண்டனைத் தண்டனை ஆகும், இது பொதுவாக "இருமைப்பாடாக" அறியப்படுகிறது. + +## பிளாக்கு எவ்வாறு உருவாக்கப்படுகிறது? {#how-is-a-block-created} + +பிளாக் முன்மொழியவர், அவர்கள் சொந்தமாக இயக்கப்படும் fork choice algorithm இன் பார்வையைப் பொறுத்து, சங்கத்தின் சமீபத்திய தலைப்பின் மேல் கட்டப்படும் கையொப்பமிடப்பட்ட beacon பிளாக்கைப் பரப்ப வேண்டும். Fork choice algorithm, முந்தைய ஸ்லாடிலிருந்து மீதமுள்ள எந்தவொரு அங்கீகாரங்களையும் அணிவகுக்கிறது, பின்னர் தனது வரலாற்றில் அதிகபட்சமான அங்கீகாரங்களின் சேர்க்கை எடையைக் கொண்ட பிளாக்கை கண்டுபிடிக்கிறது. அந்தப் பிளாக்கே, முன்மொழியவரால் உருவாக்கப்பட்ட புதிய பிளாக்கின் பெற்றோராகும். + +பிளாக் முன்மொழியர், தங்கள் சொந்த உள்ளூர் தரவுத்தளத்திலிருந்து மற்றும் சங்கத்தின் பார்வையிலிருந்து தரவுகளைப் சேகரித்து ஒரு பிளாக்கை உருவாக்குகிறான். பிளாக்கின் உள்ளடக்கம் கீழே உள்ள குறிப்பு வடிவில் காட்டப்பட்டுள்ளது: + +```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 +``` + +`randao_reveal` புலமானது, தொகுதி முன்மொழிவாளர் தற்போதைய யுகத்தின் எண்ணில் கையொப்பமிடுவதன் மூலம் உருவாக்கும், சரிபார்க்கக்கூடிய ஒரு சீரற்ற மதிப்பை எடுத்துக்கொள்கிறது. `eth1_data` என்பது வைப்பு ஒப்பந்தம் குறித்த தொகுதி முன்மொழிவாளரின் பார்வைக்கான ஒரு வாக்கெடுப்பாகும், இதில் வைப்பு Merkle trie இன் ரூட் மற்றும் புதிய வைப்புகளைச் சரிபார்க்க உதவும் வைப்புகளின் மொத்த எண்ணிக்கை ஆகியவை அடங்கும். `graffiti` என்பது ஒரு விருப்பப் புலமாகும், இதைப் பயன்படுத்தி ஒரு செய்தியைத் தொகுதியில் சேர்க்கலாம். `proposer_slashings` மற்றும் `attester_slashings` என்பவை, முன்மொழிவாளரின் சங்கிலிப் பார்வையின்படி, சில சரிபார்ப்பாளர்கள் தண்டனைக்குரிய குற்றங்களைச் செய்துள்ளனர் என்பதற்கான சான்றுகளைக் கொண்ட புலங்களாகும். `deposits` என்பது தொகுதி முன்மொழிவாளருக்குத் தெரிந்த புதிய சரிபார்ப்பாளர் வைப்புகளின் பட்டியல் ஆகும், மற்றும் `voluntary_exits` என்பது ஒருமித்த அடுக்கு அரட்டை நெட்வொர்க்கில் தொகுதி முன்மொழிவாளர் கேள்விப்பட்ட, வெளியேற விரும்பும் சரிபார்ப்பாளர்களின் பட்டியலாகும். `sync_aggregate` என்பது, முன்பு ஒத்திசைவுக் குழுவிற்கு (இலகு கிளையன்ட் தரவை வழங்கும் சரிபார்ப்பாளர்களின் துணைக்குழு) ஒதுக்கப்பட்ட சரிபார்ப்பாளர்கள் யார் மற்றும் தரவில் கையொப்பமிடுவதில் பங்கேற்றவர்கள் யார் என்பதைக் காட்டும் ஒரு திசையன் ஆகும். + +`execution_payload` என்பது செயலாக்க மற்றும் ஒருமித்த கிளையன்ட்களுக்கு இடையில் பரிவர்த்தனைகள் பற்றிய தகவல்களைப் பரிமாறிக்கொள்ள உதவுகிறது. `execution_payload` என்பது ஒரு பெக்கான் தொகுதிக்குள் உள்ளமைக்கப்படும் செயலாக்கத் தரவுகளின் தொகுதியாகும். `execution_payload` இன் உள்ளே உள்ள புலங்கள் எத்தேரியம் மஞ்சள் தாளில் கோடிட்டுக் காட்டப்பட்டுள்ள தொகுதி கட்டமைப்பைப் பிரதிபலிக்கின்றன, ஆனால் அதில் ஓம்மர்கள் (ommers) இல்லை மற்றும் `difficulty` க்கு பதிலாக `prev_randao` உள்ளது. Execution client தன் சொந்த gossip நெட்வொர்க்கில் கேட்டுத் தெரிந்த உள்ளூர் பரிமாற்றங்களின் தொலைபேசி அணுகுமுறை அளிக்கிறது. இந்தப் பரிமாற்றங்கள் உள்ளகமாகச் செயல்படுத்தப்படுகின்றன மற்றும் post-state எனப் அழைக்கப்படும் புதுப்பிக்கப்பட்ட நிலை trie ஐ உருவாக்குகின்றன. பரிவர்த்தனைகள் `transactions` எனப்படும் பட்டியலாக `execution_payload` இல் சேர்க்கப்பட்டுள்ளன, மேலும் பரிவர்த்தனைக்குப் பிந்தைய நிலை (post-state) `state-root` புலத்தில் வழங்கப்படுகிறது. + +இந்த அனைத்து தரவுகளும் ஒரு beacon பிளாக்கில் சேகரிக்கப்படுகிறார்கள், கையொப்பமிடப்படுகிறார்கள், மற்றும் பிளாக் முன்மொழியவரின் சகோதரர்களுக்குப் பரப்பப்படுகிறது, அவர்கள் இதைத் தங்களது சகோதரர்களுக்குப் பரப்புகிறார்கள், மற்றும் இதற்கும் இதுபோன்றது. + +[தொகுதிகளின் உடற்கூறியல்](/developers/docs/blocks) பற்றி மேலும் படிக்கவும். + +## பிளாக்கின் நிகழ்வுகள்? {#what-happens-to-blocks} + +பிளாக்கு பிளாக் முன்மொழியவரின் உள்ளூர் தரவுத்தளத்தில் சேர்க்கப்படுகிறது மற்றும் ஒப்புதலாளர் அடுக்கு நெட்வொர்க்கில் சகோதரர்களுக்குப் பரப்பப்படுகிறது. ஒரு வரையலர் பிளாக்கைப் பெறும்போது, அதில் உள்ள தரவுகளைச் சோதிக்கிறான், இதில் பிளாக்கின் சரியான பெற்றோரைக் கொண்டிருக்கிறதா, சரியான ஸ்லாட்டிற்கு ஒத்திருக்கிறதா, முன்மொழியரின் அடையாளம் எதிர்பார்க்கப்படும் தானா, RANDAO reveal சரியாக இருக்கிறதா மற்றும் முன்மொழியர் தண்டிக்கப்படாதவர் எனச் சோதிக்கிறான். `execution_payload` பிரிக்கப்பட்டு, சரிபார்ப்பாளரின் செயலாக்க கிளையன்ட், முன்மொழியப்பட்ட நிலை மாற்றத்தைச் சரிபார்க்க, பட்டியலில் உள்ள பரிவர்த்தனைகளை மீண்டும் செயல்படுத்துகிறது. பிளாக்கு அனைத்து இந்தச் சோதனைகளை வெற்றிகரமாகத் தாண்டின்போது, ஒவ்வொரு வரையலரும் அந்தப் பிளாக்கை தனது சொந்த உத்திசெய்த சங்கத்தில் சேர்க்கிறான். பிறகு, அடுத்த ஸ்லாட்டில் செயல்முறை மீண்டும் துவங்கும். + +## தொகுதி வெகுமதிகள் {#block-rewards} + +பிளாக் முன்மொழியவர் தனது வேலைக்குப் பணம் பெறுகிறான். செயலில் உள்ள சரிபார்ப்பாளர்களின் எண்ணிக்கை மற்றும் அவற்றின் பயனுள்ள இருப்புகளின் செயல்பாடாக ஒரு `base_reward` கணக்கிடப்படுகிறது. தொகுதி முன்மொழிவாளர், தொகுதியில் சேர்க்கப்பட்ட ஒவ்வொரு செல்லுபடியாகும் சான்றளிப்புக்கும் `base_reward` இன் ஒரு பகுதியைப் பெறுகிறார்; எவ்வளவு அதிகமான சரிபார்ப்பாளர்கள் தொகுதிக்குச் சான்றளிக்கிறார்களோ, அவ்வளவு அதிகமாக தொகுதி முன்மொழிவாளரின் வெகுமதி இருக்கும். தண்டனைக் குறைப்புக்குள்ளாக்கப்பட வேண்டிய சரிபார்ப்பாளர்களைப் புகாரளிப்பதற்கும் ஒரு வெகுமதி உள்ளது, இது தண்டனைக் குறைப்புக்குள்ளான ஒவ்வொரு சரிபார்ப்பாளருக்கும் `1/512 * பயனுள்ள இருப்பு` க்கு சமமாகும். + +[வெகுமதிகள் மற்றும் அபராதங்கள் பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties) + +## மேலும் வாசிக்க {#further-reading} + +- [தொகுதிகளுக்கான அறிமுகம்](/developers/docs/blocks/) +- [பங்குச் சான்றுக்கான அறிமுகம்](/developers/docs/consensus-mechanisms/pos/) +- [எத்தேரியம் ஒருமித்த விவரக்குறிப்புகள்](https://github.com/ethereum/consensus-specs) +- [Gasper-க்கான அறிமுகம்](/developers/docs/consensus-mechanisms/pos/gasper/) +- [எத்தேரியத்தை மேம்படுத்துதல்](https://eth2book.info/) diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/faqs/index.md new file mode 100644 index 00000000000..daaa8e2d308 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -0,0 +1,172 @@ +--- +title: "அடிக்கடி கேட்கப்படும் கேள்விகள்" +description: "ப்ரூஃப்-ஆஃப்-ஸ்டேக் எத்தேரியம் குறித்த அடிக்கடி கேட்கப்படும் கேள்விகள்." +lang: ta +--- + +## ப்ரூஃப்-ஆஃப்-ஸ்டேக் என்றால் என்ன {#what-is-proof-of-stake} + +Proof-of-stake என்பது blockchains-க்கு security வழங்கக்கூடிய algorithm வகையைச் சார்ந்தது, இது attackers தவறாகச் செயற்பட்டால் assets இழக்கப்படும் என்பதன் மூலம். Proof-of-stake முறைமைகள் validators-ஐ ஒரு asset-ஐ available செய்யத் தேவையாகக் கொண்டு, அந்த asset-ஐ validator சில dishonest behavior-ல் ஈடுபட்டால் அழிக்கக்கூடிய வகையில் இருக்க வேண்டும். Ethereum தனது blockchain-ஐ proof-of-stake முறைமையைப் பயன்படுத்தி பாதுகாக்கிறது. + +## Proof-of-stake எப்படி proof-of-work-க்கு ஒப்பிடப்படுகிறது? {#comparison-to-proof-of-work} + +Proof-of-work மற்றும் proof-of-stake இரண்டும் malicious actors-ஐ network-ஐ spam செய்யவோ அல்லது fraud செய்யவோ economically disincentivize செய்யும் முறைமைகள் ஆகும். இரு முறைகளிலும், nodes (consensus-ல் செயல்திறன் காட்டும்) சில assets-ஐ network-க்கு into வைக்கிறார்கள், மேலும் அவர்கள் தவறாகச் செயற்படுவதைப் போல் misbehave செய்யும்போது அந்த assets இழக்கப்படுகின்றன. + +Proof-of-work-ல், இந்த asset என்பது energy ஆகும். Node, miner என்ற பெயரால் அழைக்கப்படும், ஒரு algorithm-ஐ இயங்கச் செய்கிறார், இது மற்ற nodes-களைவிட விரைவில் ஒரு மதிப்பைக் கணக்கிடும் நோக்கத்துடன் இருக்கின்றது. மிக வேகமாகச் செயல்படும் node-க்கு block-ஐ chain-க்கு முன்மொழிய உரிமை கிடைக்கும். சங்கத்தின் வரலாறு மாற அல்லது பிளாக் முன்மொழிவில் உயர்வெடுக்க, ஒரு மெய்னர் பலவும் கணக்கீட்டு சக்தி தேவைப்படும், இது எப்போதும் போட்டியில் வெற்றி பெறுவதற்கு. இது முற்றிலும் செலவான மற்றும் கஷ்டமானது, சங்கத்தைத் தாக்குதல்களிலிருந்து பாதுகாக்கிறது. ப்ரூஃப்-ஆஃப்-வர்க் மூலம் "மெய்ன்" செய்யத் தேவையான சக்தி ஒரு யதார்த்த உலக பொருளாகும், மெய்னர்கள் இதற்காகப் பணம் செலவிடுகிறார்கள். + +ப்ரூஃப்-ஆஃப்-ஸ்டேக் தேவையான மையங்கள், "வாலிடேட்டர்ஸ்" என அழைக்கப்படும், நேரடியாக ஒரு கிரிப்டோ சொத்தை ஸ்மார்ட் ஒப்பந்தத்திற்கு சமர்ப்பிக்க வேண்டும். ஒரு வாலிடேட்டர் தவறாக நடத்துமானால், இந்தக் கிரிப்டோ அழிக்கப்படலாம், ஏனெனில் அவர்கள் நேரடியாகச் சங்கத்தில் தங்கள் சொத்துகளை "ஸ்டேக்" செய்கின்றனர், சக்தி செலவிடுவதற்கு மாறாக. + +ப்ரூஃப்-ஆஃப்-வர்க் மிகவும் அதிக சக்தி தேவைப்படுகிறது, ஏனெனில் மெய்னிங் செயல்முறையில் மின்சாரம் நாசமாகிறது. ப்ரூஃப்-ஆஃப்-ஸ்டேக், மற்றபடி, மிகவும் சிறிய அளவிலான சக்தி தேவையுள்ளது - எதீரியமின் வாலிடேட்டர்கள் ராஸ்பெர்ரிபைப்போன்றற குறைந்த சக்தி கொண்ட சாதனங்களில் கூட இயங்க முடியும். எதீரியமின் ப்ரூஃப்-ஆஃப்-ஸ்டேக் முறையை ப்ரூஃப்-ஆஃப்-வர்க்-க்கு விட அதிக பாதுகாப்பானது எனக் கருதப்படுகிறது, ஏனெனில் தாக்குதல் செலவு அதிகமாக இருக்கும் மற்றும் தாக்குதலாளிக்கு விளைவுகள் கடுமையாக இருக்கும். + +ப்ரூஃப்-ஆஃப்-வொர்க் மற்றும் ப்ரூஃப்-ஆஃப்-ஸ்டேக் என்பது ஒரு சர்ச்சைக்குரிய தலைப்பு. [விட்டலிக் புட்டேரின் வலைப்பதிவு](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) மற்றும் ஜஸ்டின் டிரேக் மற்றும் லின் ஆல்டன் இடையேயான விவாதம் வாதங்களின் நல்ல சுருக்கத்தை அளிக்கிறது. + + + +## ப்ரூஃப்-ஆஃப்-ஸ்டேக் சக்தி திறமையானது என்பதா? {#is-pos-energy-efficient} + +ஆம். ஆம். ப்ரூஃப்-ஆஃப்-ஸ்டேக் நெட்வொர்க்-ல் உள்ள மையங்கள் மிகச் சில அளவிலான சக்தி மட்டுமே பயன்படுத்துகின்றன. ஒரு மூன்றாம் பக்கம் ஆய்வு, முழு ப்ரூஃப்-ஆஃப்-ஸ்டேக் எதீரியமின் நெட்வொர்க் ஆண்டுதோறும் சுமார் 0.0026 TWh நுகர்கிறது - அமெரிக்காவில் விளையாட்டில் நுகரிக்கும் சக்தியின் சுமார் 13,000 மடங்கு. + +[எத்தேரியத்தின் ஆற்றல் நுகர்வு பற்றி மேலும்](/energy-consumption/). + +## ப்ரூஃப்-ஆஃப்-ஸ்டேக் பாதுகாப்பானதா? {#is-pos-secure} + +எதீரியமின் ப்ரூஃப்-ஆஃப்-ஸ்டேக் மிகவும் பாதுகாப்பானது. இந்த பொறிமுறையானது நேரலைக்கு வருவதற்கு முன்பு எட்டு ஆண்டுகளுக்கும் மேலாக கடுமையாக ஆய்வு செய்யப்பட்டு, உருவாக்கப்பட்டு, சோதிக்கப்பட்டது. பாதுகாப்பு உத்தரவாதங்கள் ப்ரூஃப்-ஆஃப்-வொர்க் பிளாக்செயின்களிலிருந்து வேறுபட்டவை. ப்ரூஃப்-ஆஃப்-ஸ்டேக்கில், தீங்கிழைக்கும் சரிபார்ப்பாளர்களை தீவிரமாக தண்டிக்கலாம் ("ஸ்லாஷ்" செய்யலாம்) மற்றும் சரிபார்ப்பாளர் தொகுப்பிலிருந்து வெளியேற்றலாம், இதற்கு கணிசமான அளவு ETH செலவாகும். ப்ரூஃப்-ஆஃப்-வொர்க்கின் கீழ், ஒரு தாக்குதலாளர் போதுமான ஹாஷ் சக்தியைக் கொண்டிருக்கும் வரை தங்கள் தாக்குதலை மீண்டும் மீண்டும் செய்யலாம். ப்ரூஃப்-ஆஃப்-வொர்க்கின் கீழ் இருப்பதை விட ப்ரூஃப்-ஆஃப்-ஸ்டேக் எத்தேரியத்தில் சமமான தாக்குதல்களை மேற்கொள்வது அதிக செலவு மிக்கது. சங்கிலியின் லைவ்நெஸ்ஸை பாதிக்க, நெட்வொர்க்கில் உள்ள மொத்த ஸ்டேக் செய்யப்பட்ட ஈதரில் குறைந்தது 33% தேவைப்படுகிறது (வெற்றியின் மிகக் குறைந்த நிகழ்தகவுடன் மிகவும் அதிநவீன தாக்குதல்கள் தவிர). எதிர்கால பிளாக்குகளின் உள்ளடக்கங்களைக் கட்டுப்படுத்த, மொத்த ஸ்டேக் செய்யப்பட்ட ETH-இல் குறைந்தது 51% தேவைப்படுகிறது, மேலும் வரலாற்றை மீண்டும் எழுத, மொத்த ஸ்டேக்கில் 66%-க்கும் மேல் தேவைப்படுகிறது. எத்தேரியம் நெறிமுறை இந்த சொத்துக்களை 33% அல்லது 51% தாக்குதல் சூழ்நிலைகளிலும், 66% தாக்குதல் சூழ்நிலையில் சமூக ஒருமித்த கருத்தின் மூலமும் அழித்துவிடும். + +- [தாக்குபவர்களிடமிருந்து எத்தேரியம் ப்ரூஃப்-ஆஃப்-ஸ்டேக்கைப் பாதுகாப்பது பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [ப்ரூஃப்-ஆஃப்-ஸ்டேக் வடிவமைப்பு பற்றி மேலும்](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## ப்ரூஃப்-ஆஃப்-ஸ்டேக் எத்தேரியத்தை மலிவானதாக ஆக்குகிறதா? {#does-pos-make-ethereum-cheaper} + +இல்லை. ஒரு பரிவர்த்தனையை அனுப்புவதற்கான செலவு (கேஸ் கட்டணம்) நெட்வொர்க் தேவை அதிகரிக்கும்போது அதிகரிக்கும் ஒரு டைனமிக் கட்டண சந்தையால் தீர்மானிக்கப்படுகிறது. ஒருமித்த பொறிமுறை இதை நேரடியாகப் பாதிக்காது. + +[கேஸ் பற்றி மேலும்](/developers/docs/gas). + +## நோட்கள், கிளையண்ட்கள் மற்றும் சரிபார்ப்பாளர்கள் என்றால் என்ன? {#what-are-nodes-clients-and-validators} + +நோட்கள் என்பவை எத்தேரியம் நெட்வொர்க்குடன் இணைக்கப்பட்ட கணினிகள். கிளையண்ட்கள் என்பவை கணினியை ஒரு நோடாக மாற்றும் மென்பொருளாகும். இரண்டு வகையான கிளையண்ட்கள் உள்ளன: எக்ஸிகியூஷன் கிளையண்ட்கள் மற்றும் கன்சென்சஸ் கிளையண்ட்கள். ஒரு நோடை உருவாக்க இரண்டும் தேவை. ஒரு சரிபார்ப்பாளர் என்பது ஒரு கன்சென்சஸ் கிளையண்டிற்கான ஒரு விருப்பத் தேர்வான துணை நிரலாகும், இது நோடை ப்ரூஃப்-ஆஃப்-ஸ்டேக் ஒருமித்த கருத்தில் பங்கேற்க உதவுகிறது. இதன் பொருள், தேர்ந்தெடுக்கப்பட்டால் பிளாக்குகளை உருவாக்குவது மற்றும் முன்மொழிவது மற்றும் நெட்வொர்க்கில் அவர்கள் கேட்கும் பிளாக்குகளுக்கு சான்றளிப்பது. ஒரு சரிபார்ப்பாளரை இயக்க, நோட் ஆபரேட்டர் டெபாசிட் ஒப்பந்தத்தில் 32 ETH டெபாசிட் செய்ய வேண்டும். + +- [நோட்கள் மற்றும் கிளையண்ட்கள் பற்றி மேலும்](/developers/docs/nodes-and-clients) +- [ஸ்டேக்கிங் பற்றி மேலும்](/staking) + +## ப்ரூஃப்-ஆஃப்-ஸ்டேக் ஒரு புதிய யோசனையா? {#is-pos-new} + +இல்லை. BitcoinTalk-இல் ஒரு பயனர் 2011-இல் பிட்காயினுக்கு ஒரு மேம்படுத்தலாக [ப்ரூஃப்-ஆஃப்-ஸ்டேக்கின் அடிப்படை யோசனையை முன்மொழிந்தார்](https://bitcointalk.org/index.php?topic=27787.0). எத்தேரியம் மெயின்நெட்டில் செயல்படுத்தத் தயாராவதற்கு பதினொரு ஆண்டுகள் ஆனது. வேறு சில சங்கிலிகள் எத்தேரியத்திற்கு முன்பே ப்ரூஃப்-ஆஃப்-ஸ்டேக்கை செயல்படுத்தின, ஆனால் எத்தேரியத்தின் குறிப்பிட்ட பொறிமுறை (கேஸ்பர் என அழைக்கப்படுகிறது) அல்ல. + +## எத்தேரியத்தின் ப்ரூஃப்-ஆஃப்-ஸ்டேக்கில் என்ன சிறப்பு? {#why-is-ethereum-pos-special} + +எத்தேரியத்தின் ப்ரூஃப்-ஆஃப்-ஸ்டேக் பொறிமுறை அதன் வடிவமைப்பில் தனித்துவமானது. இது வடிவமைக்கப்பட்டு செயல்படுத்தப்பட்ட முதல் ப்ரூஃப்-ஆஃப்-ஸ்டேக் பொறிமுறை அல்ல, ஆனால் இது மிகவும் வலிமையானது. இந்த ப்ரூஃப்-ஆஃப்-ஸ்டேக் பொறிமுறை "கேஸ்பர்" என்று அழைக்கப்படுகிறது. பிளாக்குகளை முன்மொழிவதற்காக சரிபார்ப்பாளர்கள் எவ்வாறு தேர்ந்தெடுக்கப்படுகிறார்கள், சான்றளிப்புகள் எவ்வாறு மற்றும் எப்போது செய்யப்படுகின்றன, சான்றளிப்புகள் எவ்வாறு கணக்கிடப்படுகின்றன, சரிபார்ப்பாளர்களுக்கு வழங்கப்படும் வெகுமதிகள் மற்றும் அபராதங்கள், ஸ்லாஷிங் நிபந்தனைகள், செயலற்ற கசிவு போன்ற ஃபெயில்சேஃப் பொறிமுறைகள் மற்றும் "இறுதித்தன்மை"க்கான நிபந்தனைகளை கேஸ்பர் வரையறுக்கிறது. இறுதித்தன்மை என்பது ஒரு பிளாக் நியமன சங்கிலியின் நிரந்தரப் பகுதியாகக் கருதப்படுவதற்கு, நெட்வொர்க்கில் உள்ள மொத்த ஸ்டேக் செய்யப்பட்ட ETH-இல் குறைந்தது 66% வாக்களித்திருக்க வேண்டும் என்ற நிபந்தனையாகும். ஆராய்ச்சியாளர்கள் கேஸ்பரை குறிப்பாக எத்தேரியத்திற்காக உருவாக்கினர், மேலும் எத்தேரியம் அதைச் செயல்படுத்திய முதல் மற்றும் ஒரே பிளாக்செயின் ஆகும். + +கேஸ்பரைத் தவிர, எத்தேரியத்தின் ப்ரூஃப்-ஆஃப்-ஸ்டேக் LMD-GHOST எனப்படும் ஃபோர்க் தேர்வு அல்காரிதத்தைப் பயன்படுத்துகிறது. ஒரே ஸ்லாட்டிற்கு இரண்டு பிளாக்குகள் இருக்கும் நிலை ஏற்பட்டால் இது தேவைப்படுகிறது. இது பிளாக்செயினின் இரண்டு ஃபோர்க்குகளை உருவாக்குகிறது. LMD-GHOST சான்றளிப்புகளின் மிகப் பெரிய "எடை" உள்ள ஒன்றைத் தேர்ந்தெடுக்கிறது. எடை என்பது சரிபார்ப்பாளர்களின் செயல்திறமிக்க இருப்பால் எடையிடப்பட்ட சான்றளிப்புகளின் எண்ணிக்கையாகும். LMD-GHOST எத்தேரியத்திற்கு தனித்துவமானது. + +கேஸ்பர் மற்றும் LMD_GHOST ஆகியவற்றின் கலவையானது கேஸ்பர் என்று அழைக்கப்படுகிறது. + +[கேஸ்பர் பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/gasper/) + +## ஸ்லாஷிங் என்றால் என்ன? {#what-is-slashing} + +ஸ்லாஷிங் என்பது ஒரு சரிபார்ப்பாளரின் ஸ்டேக்கில் சிலவற்றை அழிப்பதற்கும், நெட்வொர்க்கிலிருந்து சரிபார்ப்பாளரை வெளியேற்றுவதற்கும் வழங்கப்படும் சொல். ஒரு ஸ்லாஷிங்கில் இழந்த ETH-இன் அளவு, ஸ்லாஷ் செய்யப்படும் சரிபார்ப்பாளர்களின் எண்ணிக்கையுடன் அளவிடப்படுகிறது - அதாவது தனிநபர்களை விட கூட்டுச்சதி செய்யும் சரிபார்ப்பாளர்கள் கடுமையாக தண்டிக்கப்படுகிறார்கள். + +[ஸ்லாஷிங் பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/rewards-and-penalties#slashing) + +## சரிபார்ப்பாளர்களுக்கு 32 ETH ஏன் தேவை? {#why-32-eth} + +சரிபார்ப்பாளர்கள் ETH-ஐ ஸ்டேக் செய்ய வேண்டும், அதனால் அவர்கள் தவறாக நடந்து கொண்டால் இழப்பதற்கு ஏதாவது இருக்கும். குறிப்பாக 32 ETH ஸ்டேக் செய்ய வேண்டியதற்குக் காரணம், மிதமான வன்பொருளில் நோட்கள் இயங்குவதை இயக்குவதற்கே. ஒரு சரிபார்ப்பாளருக்கான குறைந்தபட்ச ETH குறைவாக இருந்தால், சரிபார்ப்பாளர்களின் எண்ணிக்கையும், எனவே ஒவ்வொரு ஸ்லாட்டிலும் செயலாக்கப்பட வேண்டிய செய்திகளின் எண்ணிக்கையும் அதிகரிக்கும், அதாவது ஒரு நோடை இயக்க அதிக சக்திவாய்ந்த வன்பொருள் தேவைப்படும். + +## சரிபார்ப்பாளர்கள் எவ்வாறு தேர்ந்தெடுக்கப்படுகிறார்கள்? {#how-are-validators-selected} + +RANDAO எனப்படும் அல்காரிதத்தைப் பயன்படுத்தி ஒவ்வொரு ஸ்லாட்டிலும் ஒரு பிளாக்கை முன்மொழிய ஒரு சரிபார்ப்பாளர் போலி-சீரற்ற முறையில் தேர்ந்தெடுக்கப்படுகிறார், இது பிளாக் முன்மொழிபவரிடமிருந்து ஒரு ஹாஷை ஒவ்வொரு பிளாக்கிலும் புதுப்பிக்கப்படும் ஒரு சீடுடன் கலக்கிறது. இந்த மதிப்பு மொத்த வரையலர் தொகுப்பிலிருந்து குறிப்பிட்ட வரையலரை தேர்வு செய்யப் பயன்படுத்தப்படுகிறது. சரிபார்ப்பாளர் தேர்வு இரண்டு எப்போக்களுக்கு முன்பே சரி செய்யப்படுகிறது. + +[சரிபார்ப்பாளர் தேர்வு பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/block-proposal) + +## ஸ்டேக் கிரைண்டிங் என்றால் என்ன? {#what-is-stake-grinding} + +ஸ்டேக் கிரைண்டிங் என்பது ப்ரூஃப்-ஆஃப்-ஸ்டேக் நெட்வொர்க்குகள் மீதான ஒரு வகை தாக்குதலாகும், அங்கு தாக்குபவர் சரிபார்ப்பாளர் தேர்வு அல்காரிதத்தை தங்கள் சொந்த சரிபார்ப்பாளர்களுக்கு சாதகமாக ஒருதலைப்பட்சமாக்க முயற்சிக்கிறார். RANDAO மீதான ஸ்டேக் கிரைண்டிங் தாக்குதல்களுக்கு மொத்த ஸ்டேக் செய்யப்பட்ட ETH-இல் பாதி தேவைப்படுகிறது. + +[ஸ்டேக் கிரைண்டிங் பற்றி மேலும்](https://eth2book.info/altair/part2/building_blocks/randomness/#randao-biasability) + +## சமூக ஸ்லாஷிங் என்றால் என்ன? {#what-is-social-slashing} + +சமூக ஸ்லாஷிங் என்பது ஒரு தாக்குதலுக்கு பதிலளிக்கும் விதமாக பிளாக்செயினின் ஒரு ஃபோர்க்கை ஒருங்கிணைக்கும் சமூகத்தின் திறன் ஆகும். ஒரு நேர்மையற்ற சங்கிலியை இறுதி செய்யும் ஒரு தாக்குபவரிடமிருந்து மீள சமூகத்தை இது செயல்படுத்துகிறது. தணிக்கைத் தாக்குதல்களுக்கு எதிராகவும் சமூக ஸ்லாஷிங் பயன்படுத்தப்படலாம். + +- [சமூக ஸ்லாஷிங் பற்றி மேலும்](https://ercwl.medium.com/the-case-for-social-slashing-59277ff4d9c7) +- [சமூக ஸ்லாஷிங் குறித்து விட்டலிக் புட்டேரின்](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) + +## நான் ஸ்லாஷ் செய்யப்படுவேனா? {#will-i-get-slashed} + +ஒரு சரிபார்ப்பாளராக, நீங்கள் வேண்டுமென்றே தீங்கிழைக்கும் நடத்தையில் ஈடுபடாவிட்டால் ஸ்லாஷ் செய்யப்படுவது மிகவும் கடினம். சரிபார்ப்பாளர்கள் ஒரே ஸ்லாட்டிற்கு பல பிளாக்குகளை முன்மொழியும் போது அல்லது அவர்களின் சான்றளிப்புகளுடன் தங்களுக்குள் முரண்படும்போது போன்ற மிகவும் குறிப்பிட்ட சூழ்நிலைகளில் மட்டுமே ஸ்லாஷிங் செயல்படுத்தப்படுகிறது - இவை தற்செயலாக எழ வாய்ப்பில்லை. + +[ஸ்லாஷிங் நிபந்தனைகள் பற்றி மேலும்](https://eth2book.info/altair/part2/incentives/slashing) + +## நத்திங்-அட்-ஸ்டேக் சிக்கல் என்றால் என்ன? {#what-is-nothing-at-stake-problem} + +நத்திங்-அட்-ஸ்டேக் சிக்கல் என்பது சில ப்ரூஃப்-ஆஃப்-ஸ்டேக் பொறிமுறைகளில் உள்ள ஒரு கருத்தியல் சிக்கலாகும், அங்கு வெகுமதிகள் மட்டுமே உள்ளன மற்றும் அபராதங்கள் இல்லை. ஸ்டேக்கில் எதுவும் இல்லை என்றால், ஒரு நடைமுறைச் சரிபார்ப்பாளர் பிளாக்செயினின் எந்த, அல்லது பல, ஃபோர்க்குகளுக்கும் சான்றளிப்பதில் சமமாக மகிழ்ச்சியாக இருக்கிறார், ஏனெனில் இது அவர்களின் வெகுமதிகளை அதிகரிக்கிறது. எத்தேரியம் ஒரு நியமன சங்கிலியை உறுதிசெய்ய இறுதித்தன்மை நிபந்தனைகள் மற்றும் ஸ்லாஷிங்கைப் பயன்படுத்தி இதைச் சமாளிக்கிறது. + +[நத்திங்-அட்-ஸ்டேக் சிக்கல் பற்றி மேலும்](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-the-nothing-at-stake-problem-and-how-can-it-be-fixed) + +## ஃபோர்க் தேர்வு அல்காரிதம் என்றால் என்ன? {#what-is-a-fork-choice-algorithm} + +ஒரு ஃபோர்க் தேர்வு அல்காரிதம் எந்தச் சங்கிலி நியமனமானது என்பதைத் தீர்மானிக்கும் விதிகளைச் செயல்படுத்துகிறது. உகந்த சூழ்நிலையில், ஃபோர்க் தேர்வு விதி தேவையில்லை, ஏனெனில் ஒரு ஸ்லாட்டிற்கு ஒரு பிளாக் முன்மொழிபவர் மட்டுமே உள்ளார் மற்றும் தேர்வு செய்ய ஒரு பிளாக் மட்டுமே உள்ளது. எப்போதாவது, ஒரே ஸ்லாட்டிற்கான பல பிளாக்குகள் அல்லது தாமதமாக வரும் தகவல்கள் சங்கிலியின் தலைக்கு அருகிலுள்ள பிளாக்குகள் எவ்வாறு ஒழுங்கமைக்கப்படுகின்றன என்பதற்கு பல விருப்பங்களுக்கு வழிவகுக்கிறது. இந்தச் சந்தர்ப்பங்களில், எல்லா கிளையண்ட்களும் ஒரே மாதிரியான சில விதிகளைச் செயல்படுத்த வேண்டும், அவை அனைத்தும் சரியான பிளாக்குகளின் வரிசையைத் தேர்ந்தெடுப்பதை உறுதிசெய்ய. ஃபோர்க்-தேர்வு அல்காரிதம் இந்த விதிகளை குறியாக்கம் செய்கிறது. + +எத்தேரியத்தின் ஃபோர்க்-தேர்வு அல்காரிதம் LMD-GHOST என்று அழைக்கப்படுகிறது. இது சான்றளிப்புகளின் மிகப்பெரிய எடையுடன் ஃபோர்க்கைத் தேர்ந்தெடுக்கிறது, அதாவது பெரும்பாலான ஸ்டேக் செய்யப்பட்ட ETH வாக்களித்த ஒன்று. + +[LMD-GHOST பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## ப்ரூஃப்-ஆஃப்-ஸ்டேக்கில் இறுதித்தன்மை என்றால் என்ன? {#what-is-finality} + +ப்ரூஃப்-ஆஃப்-ஸ்டேக்கில் இறுதித்தன்மை என்பது, கொடுக்கப்பட்ட பிளாக் நியமன சங்கிலியின் நிரந்தரப் பகுதியாகும் என்பதற்கான உத்தரவாதமாகும், மேலும் ஒரு தாக்குபவர் மொத்த ஸ்டேக் செய்யப்பட்ட ஈதரில் 33%-ஐ எரிக்கும் ஒருமித்த தோல்வி ஏற்பட்டாலன்றி அதை மாற்றியமைக்க முடியாது. இது "கிரிப்டோ-பொருளாதார" இறுதித்தன்மை, இது ப்ரூஃப்-ஆஃப்-வொர்க் பிளாக்செயின்களுக்குப் பொருத்தமான "சாத்தியக்கூறு இறுதித்தன்மைக்கு" எதிரானது. சாத்தியக்கூறு இறுதித்தன்மையில், பிளாக்குகளுக்கு வெளிப்படையான இறுதிசெய்யப்பட்ட/இறுதிசெய்யப்படாத நிலைகள் இல்லை - ஒரு பிளாக் பழையதாகும்போது சங்கிலியிலிருந்து அகற்றப்படுவதற்கான வாய்ப்பு குறைவாகவும் குறைவாகவும் ஆகிறது, மேலும் ஒரு பிளாக் "பாதுப்பானது" என்று அவர்கள் போதுமான நம்பிக்கையுடன் இருக்கும்போது பயனர்கள் தாங்களாகவே தீர்மானிக்கிறார்கள். கிரிப்டோ-பொருளாதார இறுதித்தன்மையுடன், சோதனைப்புள்ளி பிளாக்குகளின் ஜோடிகளுக்கு ஸ்டேக் செய்யப்பட்ட ஈதரில் 66% வாக்களிக்க வேண்டும். இந்த நிபந்தனை பூர்த்தி செய்யப்பட்டால், அந்த சோதனைப்புள்ளிகளுக்கு இடையேயான பிளாக்குகள் வெளிப்படையாக "இறுதிசெய்யப்படுகின்றன". + +[இறுதித்தன்மை பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/#finality) + +## "வீக் சப்ஜெக்டிவிட்டி" என்றால் என்ன? {#what-is-weak-subjectivity} + +வீக் சப்ஜெக்டிவிட்டி என்பது ப்ரூஃப்-ஆஃப்-ஸ்டேக் நெட்வொர்க்குகளின் ஒரு அம்சமாகும், அங்கு பிளாக்செயினின் தற்போதைய நிலையை உறுதிப்படுத்த சமூகத் தகவல்கள் பயன்படுத்தப்படுகின்றன. புதிய நோட்கள் அல்லது நீண்ட காலமாக ஆஃப்லைனில் இருந்த பிறகு நெட்வொர்க்கில் மீண்டும் இணையும் நோட்களுக்கு சமீபத்திய நிலை கொடுக்கப்படலாம், இதன்மூலம் அவை சரியான சங்கிலியில் உள்ளதா என்பதை நோட் உடனடியாகப் பார்க்க முடியும். இந்த நிலைகள் "வீக் சப்ஜெக்டிவிட்டி சோதனைப்புள்ளிகள்" என்று அழைக்கப்படுகின்றன, மேலும் அவை மற்ற நோட் ஆபரேட்டர்களிடமிருந்து அவுட்-ஆஃப்-பேண்ட் மூலமாகவோ, பிளாக் எக்ஸ்ப்ளோரர்களிடமிருந்தோ அல்லது பல பொது எண்ட்பாயிண்ட்களிலிருந்தோ பெறலாம். + +[வீக் சப்ஜெக்டிவிட்டி பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## ப்ரூஃப்-ஆஃப்-ஸ்டேக் தணிக்கையை எதிர்க்கிறதா? {#is-pos-censorship-resistant} + +தணிக்கை எதிர்ப்பை தற்போது நிரூபிப்பது கடினம். இருப்பினும், ப்ரூஃப்-ஆஃப்-வொர்க்கைப் போலன்றி, ப்ரூஃப்-ஆஃப்-ஸ்டேக் தணிக்கை செய்யும் சரிபார்ப்பாளர்களைத் தண்டிக்க ஸ்லாஷிங்கை ஒருங்கிணைக்கும் விருப்பத்தை வழங்குகிறது. நெறிமுறையில் வரவிருக்கும் மாற்றங்கள் உள்ளன, அவை பிளாக் பில்டர்களை பிளாக் முன்மொழிபவர்களிடமிருந்து பிரிக்கின்றன மற்றும் ஒவ்வொரு பிளாக்கிலும் பில்டர்கள் சேர்க்க வேண்டிய பரிவர்த்தனைகளின் பட்டியல்களை செயல்படுத்துகின்றன. இந்த முன்மொழிவு புரோபோசர்-பில்டர் பிரிப்பு என்று அழைக்கப்படுகிறது, மேலும் இது சரிபார்ப்பாளர்கள் பரிவர்த்தனைகளைத் தணிக்கை செய்வதைத் தடுக்க உதவுகிறது. + +[புரோபோசர்-பில்டர் பிரிப்பு பற்றி மேலும்](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## எத்தேரியத்தின் ப்ரூஃப்-ஆஃப்-ஸ்டேக் அமைப்பை 51% தாக்குதலுக்கு உள்ளாக்க முடியுமா? {#pos-51-attack} + +ஆம். ப்ரூஃப்-ஆஃப்-ஸ்டேக், ப்ரூஃப்-ஆஃப்-வொர்க்கைப் போலவே 51% தாக்குதல்களுக்கு ஆளாகக்கூடியது. தாக்குபவருக்கு நெட்வொர்க்கின் ஹாஷ் சக்தியில் 51% தேவைப்படுவதற்குப் பதிலாக, தாக்குபவருக்கு மொத்த ஸ்டேக் செய்யப்பட்ட ETH-இல் 51% தேவைப்படுகிறது. மொத்த ஸ்டேக்கில் 51%-ஐக் குவிக்கும் ஒரு தாக்குபவர் ஃபோர்க்-தேர்வு அல்காரிதத்தைக் கட்டுப்படுத்த முடியும். இது தாக்குபவரை சில பரிவர்த்தனைகளைத் தணிக்கை செய்யவும், குறுகிய தூர ரீஆர்க்குகளைச் செய்யவும் மற்றும் தங்களுக்குச் சாதகமாக பிளாக்குகளை மறுவரிசைப்படுத்துவதன் மூலம் MEV-ஐப் பிரித்தெடுக்கவும் உதவுகிறது. + +[ப்ரூஃப்-ஆஃப்-ஸ்டேக் மீதான தாக்குதல்கள் பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## சமூக ஒருங்கிணைப்பு என்றால் என்ன, அது ஏன் தேவை? {#what-is-social-coordination} + +சமூக ஒருங்கிணைப்பு என்பது எத்தேரியத்திற்கான ஒரு கடைசிப் பாதுகாப்புக் கோடாகும், இது நேர்மையற்ற பிளாக்குகளை இறுதி செய்த தாக்குதலிலிருந்து ஒரு நேர்மையான சங்கிலியை மீட்டெடுக்க அனுமதிக்கும். இந்தச் சந்தர்ப்பத்தில், எத்தேரியம் சமூகம் "அவுட்-ஆஃப்-பேண்ட்" ஆக ஒருங்கிணைத்து, ஒரு நேர்மையான சிறுபான்மை ஃபோர்க்கைப் பயன்படுத்த ஒப்புக்கொள்ள வேண்டும், இந்த செயல்பாட்டில் தாக்குபவரின் சரிபார்ப்பாளர்களை ஸ்லாஷ் செய்ய வேண்டும். இதற்கு ஆப்ஸ்கள் மற்றும் எக்ஸ்சேஞ்சுகளும் நேர்மையான ஃபோர்க்கை அங்கீகரிக்க வேண்டும். + +[சமூக ஒருங்கிணைப்பு பற்றி மேலும் படிக்கவும்](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## ப்ரூஃப்-ஆஃப்-ஸ்டேக்கில் பணக்காரர்கள் மேலும் பணக்காரர்களாகிறார்களா? {#do-rich-get-richer} + +ஒருவர் எவ்வளவு அதிகமாக ETH ஸ்டேக் செய்ய வேண்டுமோ, அவ்வளவு அதிகமாக சரிபார்ப்பாளர்களை இயக்கலாம், மேலும் அதிக வெகுமதிகளை அவர்கள் பெறலாம். வெகுமதிகள் ஸ்டேக் செய்யப்பட்ட ETH-இன் அளவுடன் நேர்கோட்டில் அளவிடப்படுகின்றன, மேலும் அனைவரும் ஒரே சதவீத வருவாயைப் பெறுகிறார்கள். ப்ரூஃப்-ஆஃப்-வொர்க் ஆனது ப்ரூஃப்-ஆஃப்-ஸ்டேக்கை விட பணக்காரர்களை மேலும் வளப்படுத்துகிறது, ஏனெனில் பெரிய அளவில் வன்பொருளை வாங்கும் பணக்கார மைனர்கள் அளவுசார் பொருளாதாரங்களிலிருந்து பயனடைகிறார்கள், அதாவது செல்வம் மற்றும் வெகுமதிக்கு இடையிலான உறவு நேரியல் அல்ல. + +## ப்ரூஃப்-ஆஃப்-ஸ்டேக் ப்ரூஃப்-ஆஃப்-வொர்க்கை விட அதிக மையப்படுத்தப்பட்டதா? {#is-pos-decentralized} + +இல்லை, ப்ரூஃப்-ஆஃப்-வொர்க் மையப்படுத்தலை நோக்கிச் செல்கிறது, ஏனெனில் மைனிங் செலவுகள் அதிகரித்து தனிநபர்களை விலைக்கு வெளியேற்றுகின்றன, பின்னர் சிறு நிறுவனங்களை விலைக்கு வெளியேற்றுகின்றன, மற்றும் பல. ப்ரூஃப்-ஆஃப்-ஸ்டேக்கில் தற்போதைய சிக்கல் லிக்விட் ஸ்டேக்கிங் டெரிவேட்டிவ்களின் (LSDs) செல்வாக்கு ஆகும். இவை சில வழங்குநரால் ஸ்டேக் செய்யப்பட்ட ETH-ஐக் குறிக்கும் டோக்கன்களாகும், உண்மையான ETH அன்ஸ்டேக் செய்யப்படாமல் யாரேனும் இரண்டாம் நிலை சந்தைகளில் மாற்றிக்கொள்ளலாம். LSD-க்கள் பயனர்களை 32 ETH-க்கும் குறைவாக ஸ்டேக் செய்ய அனுமதிக்கின்றன, ஆனால் அவை ஒரு சில பெரிய நிறுவனங்கள் பெரும்பாலான ஸ்டேக்கைக் கட்டுப்படுத்தக்கூடிய ஒரு மையப்படுத்தல் அபாயத்தையும் உருவாக்குகின்றன. இதனால்தான் எத்தேரியத்திற்கு [சோலோ ஸ்டேக்கிங்](/staking/solo) சிறந்த விருப்பமாகும். + +[LSD-க்களில் ஸ்டேக் மையப்படுத்தல் பற்றி மேலும்](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## நான் ஏன் ETH-ஐ மட்டுமே ஸ்டேக் செய்ய முடியும்? {#why-can-i-only-stake-eth} + +ETH என்பது Ethereum இன் சொந்த நாணயம். வாக்குகளையும் பாதுகாப்பையும் மதிப்பிடுவதற்கான செயல்திறமிக்க இருப்புகளைக் கணக்கிடுவதற்கு, அனைத்து ஸ்டேக்குகளும் ஒரே நாணயத்தில் குறிப்பிடப்படுவது அவசியம். ETH என்பது ஒரு ஸ்மார்ட் ஒப்பந்தத்தை விட எத்தேரியத்தின் ஒரு அடிப்படைக் கூறு ஆகும். பிற நாணயங்களை இணைப்பது சிக்கலான தன்மையை கணிசமாக அதிகரித்து, ஸ்டேக்கிங்கின் பாதுகாப்பைக் குறைக்கும். + +## எத்தேரியம் மட்டும்தான் ப்ரூஃப்-ஆஃப்-ஸ்டேக் பிளாக்செயினா? {#is-ethereum-the-only-pos-blockchain} + +இல்லை, பல ப்ரூஃப்-ஆஃப்-ஸ்டேக் பிளாக்செயின்கள் உள்ளன. எதுவும் எத்தேரியத்தைப் போல இல்லை; எத்தேரியத்தின் ப்ரூஃப்-ஆஃப்-ஸ்டேக் பொறிமுறை தனித்துவமானது. + +## தி மெர்ஜ் என்றால் என்ன? {#what-is-the-merge} + +தி மெர்ஜ் என்பது எத்தேரியம் அதன் ப்ரூஃப்-ஆஃப்-வொர்க் அடிப்படையிலான ஒருமித்த பொறிமுறையை அணைத்துவிட்டு அதன் ப்ரூஃப்-ஆஃப்-ஸ்டேக் அடிப்படையிலான ஒருமித்த பொறிமுறையை இயக்கிய தருணம். தி மெர்ஜ் செப்டம்பர் 15, 2022 அன்று நடந்தது. + +[தி மெர்ஜ் பற்றி மேலும்](/roadmap/merge) + +## லைவ்நெஸ் மற்றும் சேஃப்டி என்றால் என்ன? {#what-are-liveness-and-safety} + +லைவ்நெஸ் மற்றும் சேஃப்டி ஆகியவை ஒரு பிளாக்செயினுக்கான இரண்டு அடிப்பட பாதுகாப்பு கவலைகளாகும். லைவ்நெஸ் என்பது இறுதி செய்யும் சங்கிலியின் கிடைக்கும் தன்மையாகும். சங்கிலி இறுதி செய்வதை நிறுத்தினால் அல்லது பயனர்களால் அதை எளிதாக அணுக முடியாவிட்டால், அவை லைவ்நெஸ் தோல்விகளாகும். அதிகப்படியான அணுகல் செலவும் ஒரு லைவ்நெஸ் தோல்வியாகக் கருதப்படலாம். சேஃப்டி என்பது சங்கிலியைத் தாக்குவது எவ்வளவு கடினம் என்பதைக் குறிக்கிறது - அதாவது, முரண்பட்ட சோதனைப்புள்ளிகளை இறுதி செய்வது. + +[கேஸ்பர் பேப்பரில் மேலும் படிக்கவும்](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/gasper/index.md new file mode 100644 index 00000000000..793fde15ded --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -0,0 +1,52 @@ +--- +title: Gasper +description: "Gasper பங்கிற்கான சான்று இயங்குமுறை பற்றிய ஒரு விளக்கம்." +lang: ta +--- + +Gasper என்பது Casper the Friendly Finality Gadget (Casper-FFG) மற்றும் LMD-GHOST fork choice algorithm இன் கலவையாகும். இவை இணைந்து proof-of-stake எத்தீரியத்தை பாதுகாக்கும் ஒப்புதலுக்கான முறையை உருவாக்குகின்றன. Casper என்பது குறிப்பிட்ட பிளாக்குகளை "இறுதியான" என மேம்படுத்தும் முறையாகும், இதன் மூலம் புதிய நுழைவாளர்கள் அவர்கள் canonical சங்கத்தை ஒத்திசைத்து இருப்பதில் நம்பிக்கையுடன் இருக்கலாம். Fork choice algorithm சேர்க்கப்பட்ட வாக்களிப்புகளைப் பயன்படுத்தி, பிளாக்கில் பிரிவுகள்உருவாகும்போதுு சரியான ஒன்றைப்எளிதாகத் தேர்வுு செய்ய முடியும் என்பதை உறுதிப்படுத்துகிறது. + +**கவனத்திற்கு** Gasper-இல் சேர்ப்பதற்காக Casper-FFG-இன் அசல் வரையறை சற்றே புதுப்பிக்கப்பட்டது. இந்தப் பக்கம், புதுப்பிக்கப்பட்ட பதிப்பை நாங்கள் பரிசீலிக்கிறோம். + +## முன்நிபந்தனைகள் + +இந்த உள்ளடக்கத்தைப் புரிந்துகொள்ள, [பங்கிற்கான சான்று](/developers/docs/consensus-mechanisms/pos/) பற்றிய அறிமுகப் பக்கத்தைப் படிப்பது அவசியமாகும். + +## Gasper-இன் பங்கு {#role-of-gasper} + +Gasper என்பது proof-of-stake பிளாக்கை மேல் அமையப் பெறுகிறது, இதில் நொடுகள் எதியை ஒரு பாதுகாப்பு வைபாகமாக வழங்குகின்றன, இது அவர்கள் மந்தமாகவோ அல்லது போலியானதாகவோ செயல்பட்டால் அழிக்கப்படும். Gasper என்பது வரையலர்களுக்குக் கெடுதல் மற்றும் பணி வழங்கல், எ cuales பிளாக்குகளை ஏற்க மற்றும் மறுக்க, மற்றும் பிளாக்கின் எந்தfork இல் கட்டமைக்க வேண்டுமென்ற அனைத்தும் நிர்ணயிக்கும் முறையாகும். + +## இறுதியானது என்ன? {#what-is-finality} + +இறுதியானது என்பது சில பிளாக்குகளின் தன்மையாகும், இது அவை மாறவில்லையெனக் கூறுவதற்கு, முக்கிய ஒப்புதலின் தோல்வி ஏற்பட்டது மற்றும் ஒரு கொள்ளையாளர் மொத்தமாகப் பந்தயமாக வைக்கப்பட்ட எதியில் 1/3 ஐ அழித்துவிட்டால் மட்டுமே மாறக்கூடியது. இறுதியான பிளாக்குகள் பிளாக்கின் குறித்த தகவலாகக் கருதப்படலாம். ஒரு பிளாக் இறுதியானதாக இருக்க, அது இரண்டு கட்டமைப்புப் படிகள் வழியாகச் செல்கிறது: + +1. மொத்தமாகப் பந்தயமாக வைக்கப்பட்ட எதியின் இரண்டு-மூன்றாம் பங்கு அந்தப் பிளாக்கின் canonical சங்கத்தில் சேர்க்கப்படும் வகையில் வாக்களிக்க வேண்டும். இந்த நிபந்தனை "justified" என மேம்படுத்துகிறது. Justified பிளாக்குகள் மாற முடியாதவை என்பதே இல்லை, ஆனால் குறிப்பிட்ட நிபந்தனைகளில் மாறக்கூடியது. +2. Justified பிளாக்கின் மேலே மற்றொரு பிளாக் justified என்ற நிலையை அடைந்தால், அது "finalized" ஆக மேம்படுத்தப்படுகிறது. ஒரு பிளாக்கைப் இறுதியாகச் செய்யுவது அந்தப் பிளாக்கைப் canonical சங்கத்தில் சேர்க்கக்கூடிய உறுதி ஆகும். இதை மாற்ற முடியாது, வேறுஎந்தத் தாக்குதலாளரும்் மில்லியன் எதிகளை (மில்லியன் $USD) அழிக்க வேண்டியதாகும். + +இந்தப் பிளாக்கின் மேம்பாடுகள் ஒவ்வொரு ஸ்லாட்டிலும் நடக்கவில்லை. பதிலாக, எட்டாவது எல்லைகளில் உள்ள பிளாக்குகள் மட்டுமே justified மற்றும் finalized ஆக இருக்க முடியும். இந்தப் பிளாக்குகள் "checkpoints" என அழைக்கப்படுகின்றன. மேம்பாடு checkpoints இன் தம்பதிகளைப் பரிசீலிக்கிறது. சமீபத்தியதல்லாத சோதனைச் சாவடியை இறுதிசெய்யப்பட்டதாகவும், மிகச் சமீபத்திய தொகுதியை நியாயப்படுத்தப்பட்டதாகவும் மேம்படுத்துவதற்கு, இரண்டு அடுத்தடுத்த சோதனைச் சாவடிகளுக்கு இடையில் ஒரு \"பெரும்பான்மை இணைப்பு\" இருக்க வேண்டும் (அதாவது, சோதனைச்சாவடி B என்பது சோதனைச்சாவடி A-இன் சரியான வழித்தோன்றல் என்று மொத்தமாகப் பணையம் வைக்கப்பட்ட ஈதரில் மூன்றில் இரண்டு பங்கு வாக்களிக்க வேண்டும்). + +இறுதியானது என்பது ஒரு பிளாக்கு canonical என்பதற்கு இரண்டு-மூன்றாம் பகுதியின் ஒப்புதலுக்கு தேவைப்படுவதைப் பார்க்கும்போது, ஒரு தாக்குதலாளி மாற்று இறுதியாகச் செய்யப்பட்டது என்று சங்கத்தை உருவாக்க முடியாது: + +1. மொத்த பந்தயமாக வைக்கப்பட்ட எதியின் இரண்டு-மூன்றாம் பங்கு மொத்தமாகக் காண்பிக்க வேண்டும். +2. மொத்த பந்தயமாக வைக்கப்பட்ட எதியின் குறைந்தது ஒரு-மூன்றாம் பங்கு அழிக்கப்பட வேண்டும். + +முதலாவது நிபந்தனை, ஒரு சங்கத்தை இறுதியானதாகச் செய்ய இரண்டு-மூன்றாம் பங்கு தேவைப்படுகிறது என்பதால் தோன்றுகிறது. இரண்டாவது நிபந்தனை, இரண்டு-மூன்றாம் பங்கு மொத்தமாக வாக்களிக்கின்றனர் எனில், ஒரு-மூன்றாம் பங்கு இரண்டிலும் வாக்களிக்க வேண்டியிருக்கும் என்பதால் தோன்றுகிறது. Double-voting என்பது ஒரு slashing நிலைமை ஆகும், இது அதிகபட்சமாகத் தண்டிக்கப்படும், மேலும் மொத்த பந்தயமாக வைக்கப்பட்ட எதியின் ஒரு-மூன்றாம் பங்கு அழிக்கப்படும். மே 2022ன் நிலவரப்படி, இது ஒரு தாக்குதலாளி சுமார் $10 பில்லியன் மதிப்புள்ள எதிகளை எரிக்க வேண்டும் என்று குறிக்கிறது. Gasper-இல் தொகுதிகளை நியாயப்படுத்தி இறுதிசெய்யும் நெறிமுறையானது [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf)-இன் சற்றே மாற்றியமைக்கப்பட்ட வடிவமாகும். + +### ஊக்கத்தொகைகள் மற்றும் குறைத்தல் {#incentives-and-slashing} + +Validators எஞ்சியவுடன் நியாயமாகப் பிளாக்குகளை முன்மொழிந்து சரிபார்ப்பதற்காக rewarded ஆகின்றனர். Ether rewarded செய்யப்படுகிறது மற்றும் அவர்களின் பந்தயத்தில் சேர்க்கப்படுகிறது. மறுபுறம், validators க்கு அழைப்பு வந்தபோது செயல் செய்யத் தவறினால், இந்த rewards இல் இருந்து தவறுவார்கள், மேலும் சில சமயங்களில் அவர்களின் தற்போதைய பந்தயத்தின் ஒரு சிறிய பகுதியை இழக்கிறார்கள். எனினும், இணையதளத்தில் இல்லாததற்கான தண்டனைகள் சிறியவையாக உள்ளன மற்றும் பெரும்பாலான சந்தர்ப்பங்களில் rewards இழப்பதற்கான வாய்ப்பு செலவுகளைக் குறிக்கின்றன. இருப்பினும், சில validator நடவடிக்கைகளைத் தவறுதலாகச் செய்வது மிகவும் கடினமாகும், மேலும் சில தீய நோக்கத்தைக் குறிக்கின்றன, உதாரணமாக ஒரே slot க்காகப் பல பிளாக்குகளை முன்மொழிதல், ஒரே slot க்காகப் பல பிளாக்குகளுக்கு attesting செய்தல் அல்லது முந்தைய checkpoint votes க்கான முரண்பாடுகள். இவை" slashable" behaviors ஆகும், அவற்றுக்குக் கடுமையான தண்டனைகள் வழங்கப்படுகின்றன—slashing என்பது validator இன் பங்கியின் ஒரு பகுதி அழிக்கப்படுவதையும் validator ஐ validators குழுவிலிருந்து நீக்கப்படுவதையும் குறிக்கிறது. இந்த செயல்முறை 36 நாட்கள் ஆகும். முதல் நாளில், அதிகபட்சமாக 1 ETH வரை தொடக்க தண்டனை உண்டு. பின்னர் slashed validator இன் ether மெல்ல மெல்ல வெளியேறும் காலகட்டத்திற்குள் உடைந்து போகிறது, ஆனால் 18 ஆம் நாளில், அவர்கள் ஒரு" correlation penalty" ஐப் பெறுகிறார்கள், இது அதே நேரத்தில் மேலும் பல validators slashed செய்யப்படும்போது அதிகமாக இருக்கும். அதிகபட்ச தண்டனை முழு பங்கியாகும். இந்த rewards மற்றும் தண்டனைகள் நேர்மையான validators ஐ ஊக்குவிக்கவும், மற்றும் நெட்வொர்க்கிற்கான தாக்குதல்களைக் குறைக்கவும் உருவாக்கப்பட்டுள்ளன. + +### செயலற்ற தன்மை கசிவு {#inactivity-leak} + +Gasper பாதுகாப்புடன் மட்டுமல்லாமல் "அதிக சாத்தியமான நேர்மையை" வழங்குகிறது. இது இரண்டு-மூன்றாம் பங்கின் மொத்தம் staked ether உண்மையாக வாக்களிக்கும் மற்றும் protocol ஐப் பின்பற்றும் வரை, நெட்வொர்க் எந்த மற்ற செயல்பாடுகளுக்கும் (எடுத்துக்காட்டாகத் தாக்குதல்கள், நிலைமையில்லாத பிரச்சினைகள் அல்லது slashing) பின்பற்றாமல் finalize செய்ய முடியும் என்று கூறுகிறது. வேறு சொற்களில், மொத்தம் staked ether இன் ஒரு மூன்றாம் பகுதி எவ்விதமாகவும் அசல் செய்யப்படாத பட்சத்தில், நெட்வொர்க் finalize செய்ய முடியாது. Gasper இல், "அணைகலா விகிதம்" என்ற மேலதிக பாதுகாப்பு சுவர் உள்ளது. இந்த முறைமை நெட்வொர்க் நான்கு எபொக் கள் விடுவித்துவிட்டுவிட்டால் செயல்படுகிறது. பெரும்பான்மையான நெட்வொர்க் செய்யாத validators இன் பங்கு மெல்ல மெல்ல அழிக்கப்படுகிறது, ஆனால் பெரும்பான்மையான validators இரண்டு-மூன்றாம் பங்கு மீண்டும் பெறும் வரை, liveness failures மிகுந்த காலம் தாங்காது என்பதை உறுதி செய்யும். + +### ஃபோர்க் தேர்வு {#fork-choice} + +Casper-FFG-இன் அசல் வரையறையில் ஒரு பிரிதல் தேர்வு நெறிமுறை சேர்க்கப்பட்டுள்ளது, அது இந்த விதியை விதித்தது: `தொடக்கத் தொகுதியிலிருந்து மிகப்பெரிய தூரம் என உயரம் வரையறுக்கப்பட்டுள்ள நிலையில், மிக உயரமான, நியாயப்படுத்தப்பட்ட சோதனைச் சாவடியைக் கொண்ட சங்கிலியைப் பின்தொடரவும்`. Gasper இல், முதன்மை முற்போக்கு விதி புதிய மற்றும் மேம்பட்ட LMD-GHOST என்ற முற்போக்கு தேர்வு அலகுமூலம் அகற்றப்பட்டுள்ளது. வழக்கமான நிலைமைகளில், முற்போக்கு தேர்வு விதி தேவையில்லை - ஒவ்வொரு slot க்கும் ஒரு ஒரே block proposer உள்ளார், மற்றும் நேர்மையான validators அதை ஆதரிக்கின்றனர். ஆனால், பெரிய நெட்வொர்க் அசங்கநிலை அல்லது ஒரு மோசமான block proposer பல்வேறு கண்ணோட்டங்களை வழங்கும்போது, முற்போக்கு தேர்வு அலகு தேவையானது. அப்படி நிலைகள் உருவாகும்போது, முற்போக்கு தேர்வு அலகு சரியான சங்கரத்தை பாதுகாக்க முக்கியமான பாதுகாப்பாக இருக்கும். + +LMD-GHOST என்ற பெயர் "சமீபத்திய செய்திகள் அடிப்படையிலான greedy heaviest observed sub-tree" என்பதை குறிக்கிறது. இது attestations இன் மிகுந்த சேர்க்கை மசிவு கொண்ட சங்கரத்தை canonical என்று தேர்வு செய்யும் அலகு (greedy heaviest subtree) மற்றும் ஒரே validator இல் இருந்து பல செய்திகள் பெறப்பட்டால, சீராகச் சமீபத்தியய செய்தியை மட்டும் கருத்தில் கொள்ளும் (latest-message driven) என வரையறுக்கப்படுகிறது. மிகுந்த பாகத்தை canonical chain இல் சேர்க்கும் முன், ஒவ்வொரு validator இலும் இந்த விதியைப் பயன்படுத்தி ஒவ்வொரு பாகத்தையும் மதிப்பீடு செய்கின்றனர். + +## மேலும் வாசிக்க {#further-reading} + +- [Gasper: GHOST மற்றும் Casper-ஐ இணைத்தல்](https://arxiv.org/pdf/2003.03052.pdf) +- [Casper the Friendly Finality Gadget](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/index.md new file mode 100644 index 00000000000..247a16f7926 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/index.md @@ -0,0 +1,99 @@ +--- +title: "பங்குச் சான்று (PoS)" +description: "பங்குச் சான்று ஒருமித்த நெறிமுறை மற்றும் எத்தேரியத்தில் அதன் பங்கின் விளக்கம்." +lang: ta +--- + +பங்குச் சான்று (PoS) எத்தேரியத்தின் [ஒருமித்த பொறிமுறைக்கு](/developers/docs/consensus-mechanisms/) அடிப்படையாக உள்ளது. எத்தேரியம் 2022-இல் அதன் பங்குச் சான்று பொறிமுறையை செயல்படுத்தியது, ஏனெனில் முந்தைய [உழைப்புச் சான்று](/developers/docs/consensus-mechanisms/pow) கட்டமைப்புடன் ஒப்பிடும்போது இது அதிக பாதுகாப்பானது, குறைந்த ஆற்றல் தேவை கொண்டது, மற்றும் புதிய அளவிடுதல் தீர்வுகளை செயல்படுத்துவதற்கு சிறந்தது. + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +இந்தப் பக்கத்தை நன்கு புரிந்துகொள்ள, நீங்கள் முதலில் [ஒருமித்த பொறிமுறைகள்](/developers/docs/consensus-mechanisms/) பற்றிப் படிக்கப் பரிந்துரைக்கிறோம். + +## பங்குச் சான்று (PoS) என்றால் என்ன? {#what-is-pos} + +பங்குச் சான்று என்பது, சரிபார்ப்பாளர்கள் நேர்மையற்ற முறையில் செயல்பட்டால் அழிக்கப்படக்கூடிய மதிப்புள்ள ஒன்றை நெட்வொர்க்கில் வைத்துள்ளார்கள் என்பதை நிரூபிப்பதற்கான ஒரு வழியாகும். எத்தேரியத்தின் பங்குச் சான்றில், சரிபார்ப்பாளர்கள் எத்தேரியத்தில் உள்ள ஒரு ஸ்மார்ட் ஒப்பந்தத்தில் ETH வடிவில் மூலதனத்தை வெளிப்படையாகப் பங்கீடு செய்கிறார்கள். நெட்வொர்க்கில் பரப்பப்படும் புதிய பிளாக்குகள் செல்லுபடியாகும் என்பதைச் சரிபார்ப்பதற்கும், எப்போதாவது அவர்களே புதிய பிளாக்குகளை உருவாக்கிப் பரப்புவதற்கும் சரிபார்ப்பாளர் பொறுப்பாகிறார். அவர்கள் நெட்வொர்க்கை ஏமாற்ற முயன்றால் (உதாரணமாக, அவர்கள் ஒன்று அனுப்ப வேண்டிய இடத்தில் பல பிளாக்குகளை முன்மொழிவதன் மூலமோ அல்லது முரண்பாடான சான்றளிப்புகளை அனுப்புவதன் மூலமோ), அவர்களின் பங்கீடு செய்யப்பட்ட ETH-இல் சில அல்லது அனைத்தும் அழிக்கப்படலாம். + +## சரிபார்ப்பவர்கள் {#validators} + +ஒரு சரிபார்ப்பாளராகப் பங்கேற்க, ஒரு பயனர் 32 ETH ஐ டெபாசிட் ஒப்பந்தத்தில் டெபாசிட் செய்து, மூன்று தனித்தனி மென்பொருட்களை இயக்க வேண்டும்: ஒரு செயலாக்க கிளையன்ட், ஒரு ஒருமித்த கிளையன்ட், மற்றும் ஒரு சரிபார்ப்பாளர் கிளையன்ட். தங்கள் ETH-ஐ டெபாசிட் செய்தவுடன், பயனர் ஒரு செயல்படுத்தல் வரிசையில் சேர்கிறார், இது நெட்வொர்க்கில் சேரும் புதிய சரிபார்ப்பாளர்களின் விகிதத்தைக் கட்டுப்படுத்துகிறது. செயல்படுத்தப்பட்டவுடன், சரிபார்ப்பாளர்கள் எத்தேரியம் நெட்வொர்க்கில் உள்ள சக பயனர்களிடமிருந்து புதிய பிளாக்குகளைப் பெறுகிறார்கள். எத்தேரியத்தின் நிலைக்கு முன்மொழியப்பட்ட மாற்றங்கள் செல்லுபடியாகும் என்பதை சரிபார்க்க, பிளாக்கில் வழங்கப்படும் பரிவர்த்தனைகள் மீண்டும் செயல்படுத்தப்படுகின்றன, மற்றும் பிளாக் கையொப்பம் சரிபார்க்கப்படுகிறது. சரிபார்ப்பாளர் பின்னர் அந்த பிளாக்கிற்கு ஆதரவாக ஒரு வாக்கை (சான்றளிப்பு என அழைக்கப்படுகிறது) நெட்வொர்க் முழுவதும் அனுப்புகிறார். + +உழைப்புச் சான்றின் கீழ், பிளாக்குகளின் நேரம் மைனிங் கடினத்தன்மையால் தீர்மானிக்கப்படுகிறது, ஆனால் பங்குச் சான்றில், வேகம் நிர்ணயிக்கப்பட்டுள்ளது. பங்குச் சான்று எத்தேரியத்தில் நேரம் ஸ்லாட்டுகள் (12 வினாடிகள்) மற்றும் எப்போக்குகள் (32 ஸ்லாட்டுகள்) என பிரிக்கப்பட்டுள்ளது. ஒவ்வொரு ஸ்லாட்டிலும் ஒரு சரிபார்ப்பாளர் தோராயமாக ஒரு பிளாக் முன்மொழிபவராக தேர்ந்தெடுக்கப்படுகிறார். இந்த சரிபார்ப்பாளர் ஒரு புதிய பிளாக்கை உருவாக்கி அதை நெட்வொர்க்கில் உள்ள மற்ற முனைகளுக்கு அனுப்புவதற்குப் பொறுப்பாகிறார். மேலும் ஒவ்வொரு ஸ்லாட்டிலும், சரிபார்ப்பாளர்களின் ஒரு குழு தோராயமாக தேர்ந்தெடுக்கப்படுகிறது, அதன் வாக்குகள் முன்மொழியப்படும் பிளாக்கின் செல்லுபடியாகும் தன்மையை தீர்மானிக்கப் பயன்படுத்தப்படுகின்றன. நெட்வொர்க் சுமையை நிர்வகிக்கக்கூடியதாக வைத்திருக்க, சரிபார்ப்பாளர் தொகுப்பை குழுக்களாகப் பிரிப்பது முக்கியமானது. குழுக்கள் சரிபார்ப்பாளர் தொகுப்பைப் பிரிக்கின்றன, அதனால் ஒவ்வொரு செயலில் உள்ள சரிபார்ப்பாளரும் ஒவ்வொரு எப்போக்கிலும் சான்றளிக்கிறார், ஆனால் ஒவ்வொரு ஸ்லாட்டிலும் அல்ல. + +## எத்தேரியம் PoS-இல் ஒரு பரிவர்த்தனை எவ்வாறு செயல்படுத்தப்படுகிறது {#transaction-execution-ethereum-pos} + +எத்தேரியம் பங்குச் சான்றில் ஒரு பரிவர்த்தனை எவ்வாறு செயல்படுத்தப்படுகிறது என்பதற்கான முழுமையான விளக்கத்தை பின்வருபவை வழங்குகின்றன. + +1. ஒரு பயனர் தனது தனிப்பட்ட விசையுடன் ஒரு [பரிவர்த்தனையை](/developers/docs/transactions/) உருவாக்கி கையொப்பமிடுகிறார். இது பொதுவாக ஒரு பணப்பை அல்லது [ethers.js](https://docs.ethers.org/v6/), [web3js](https://docs.web3js.org/), [web3py](https://web3py.readthedocs.io/en/v5/) போன்ற நூலகத்தால் கையாளப்படுகிறது, ஆனால் பின்னணியில் பயனர் எத்தேரியம் [JSON-RPC API](/developers/docs/apis/json-rpc/) ஐப் பயன்படுத்தி ஒரு முனைக்கு கோரிக்கையை விடுக்கிறார். பரிவர்த்தனையை ஒரு பிளாக்கில் சேர்க்க ஒரு சரிபார்ப்பாளரை ஊக்குவிப்பதற்காக, பயனர் ஒரு டிப்ஸாக செலுத்தத் தயாராக இருக்கும் எரிவாயுவின் அளவை வரையறுக்கிறார். [டிப்ஸ்](/developers/docs/gas/#priority-fee) சரிபார்ப்பாளருக்கு செலுத்தப்படும் அதே வேளையில், [அடிப்படை கட்டணம்](/developers/docs/gas/#base-fee) எரிக்கப்படுகிறது. +2. பரிவர்த்தனை ஒரு எத்தேரியம் [செயலாக்க கிளையன்டிற்கு](/developers/docs/nodes-and-clients/#execution-client) சமர்ப்பிக்கப்படுகிறது, இது அதன் செல்லுபடியாகும் தன்மையை சரிபார்க்கிறது. இதன் பொருள், அனுப்புநரிடம் பரிவர்த்தனையை நிறைவேற்ற போதுமான ETH இருப்பதையும், அவர்கள் அதை சரியான விசையுடன் கையொப்பமிட்டுள்ளனர் என்பதையும் உறுதி செய்வதாகும். +3. பரிவர்த்தனை செல்லுபடியாகும் என்றால், செயலாக்க கிளையன்ட் அதை அதன் உள்ளூர் மெம்பூலில் (நிலுவையில் உள்ள பரிவர்த்தனைகளின் பட்டியல்) சேர்க்கிறது மற்றும் செயலாக்க அடுக்கு வதந்தி நெட்வொர்க் மூலம் மற்ற முனைகளுக்கும் ஒளிபரப்புகிறது. மற்ற முனைகள் பரிவர்த்தனையைப் பற்றி அறியும்போது, அவைகளும் அதைத் தங்கள் உள்ளூர் மெம்பூலில் சேர்க்கின்றன. மேம்பட்ட பயனர்கள் தங்கள் பரிவர்த்தனையை ஒளிபரப்புவதைத் தவிர்த்து, அதற்குப் பதிலாக [Flashbots Auction](https://docs.flashbots.net/flashbots-auction/overview) போன்ற சிறப்பு பிளாக் உருவாக்குபவர்களுக்கு அதை அனுப்பலாம். இது அவர்களை வரவிருக்கும் பிளாக்குகளில் அதிகபட்ச லாபத்திற்காக ([MEV](/developers/docs/mev/#mev-extraction)) பரிவர்த்தனைகளை ஒழுங்கமைக்க அனுமதிக்கிறது. +4. நெட்வொர்க்கில் உள்ள சரிபார்ப்பு முனைகளில் ஒன்று தற்போதைய ஸ்லாட்டிற்கான பிளாக் முன்மொழிபவர் ஆகும், இது முன்னர் RANDAO ஐப் பயன்படுத்தி போலி-தோராயமாக தேர்ந்தெடுக்கப்பட்டது. எத்தேரியம் பிளாக்செயினில் சேர்க்கப்பட வேண்டிய அடுத்த பிளாக்கை உருவாக்கி ஒளிபரப்புவதற்கும், உலகளாவிய நிலையைப் புதுப்பிப்பதற்கும் இந்த முனை பொறுப்பாகும். முனை மூன்று பகுதிகளால் ஆனது: ஒரு செயலாக்க கிளையன்ட், ஒரு ஒருமித்த கிளையன்ட் மற்றும் ஒரு சரிபார்ப்பாளர் கிளையன்ட். செயலாக்க கிளையன்ட் உள்ளூர் மெம்பூலில் இருந்து பரிவர்த்தனைகளை ஒரு "செயலாக்க பேலோடாக" தொகுத்து, ஒரு நிலை மாற்றத்தை உருவாக்க அவற்றை உள்ளூரில் செயல்படுத்துகிறது. இந்தத் தகவல் ஒருமித்த கிளையன்டிற்கு அனுப்பப்படுகிறது, அங்கு செயலாக்க பேலோட் ஒரு "பீக்கன் பிளாக்" இன் ஒரு பகுதியாக மூடப்பட்டுள்ளது, இது வெகுமதிகள், அபராதங்கள், ஸ்லாஷிங்குகள், சான்றளிப்புகள் போன்ற தகவல்களையும் கொண்டுள்ளது, இது சங்கிலியின் தலையில் உள்ள பிளாக்குகளின் வரிசையில் நெட்வொர்க் உடன்பட உதவுகிறது. செயலாக்க மற்றும் ஒருமித்த கிளையன்ட்களுக்கு இடையேயான தொடர்பு [ஒருமித்த மற்றும் செயலாக்க கிளையன்ட்களை இணைத்தல்](/developers/docs/networking-layer/#connecting-clients) இல் மேலும் விரிவாக விவரிக்கப்பட்டுள்ளது. +5. மற்ற முனைகள் ஒருமித்த அடுக்கு வதந்தி நெட்வொர்க்கில் புதிய பீக்கன் பிளாக்கைப் பெறுகின்றன. முன்மொழியப்பட்ட நிலை மாற்றம் செல்லுபடியாகும் என்பதை உறுதிப்படுத்த, அவர்கள் அதை தங்கள் செயலாக்க கிளையன்டிற்கு அனுப்புகிறார்கள், அங்கு பரிவர்த்தனைகள் உள்ளூரில் மீண்டும் செயல்படுத்தப்படுகின்றன. சரிபார்ப்பாளர் கிளையன்ட் பின்னர் பிளாக் செல்லுபடியானது என்றும், அது சங்கிலியின் பார்வையில் தர்க்கரீதியான அடுத்த பிளாக் என்றும் சான்றளிக்கிறது (அதாவது, [ஃபோர்க் தேர்வு விதிகளில்](/developers/docs/consensus-mechanisms/pos/#fork-choice) வரையறுக்கப்பட்டுள்ளபடி, இது அதிக எடை கொண்ட சான்றளிப்புகளைக் கொண்ட சங்கிலியில் கட்டமைக்கப்படுகிறது). அதற்கு சான்றளிக்கும் ஒவ்வொரு முனையிலும் பிளாக் உள்ளூர் தரவுத்தளத்தில் சேர்க்கப்படுகிறது. +6. ஒரு பரிவர்த்தனை இரண்டு சோதனைச் சாவடிகளுக்கு இடையில் "பெரும்பான்மை இணைப்பு" கொண்ட சங்கிலியின் ஒரு பகுதியாக மாறியிருந்தால் அதை "இறுதி செய்யப்பட்டது" என்று கருதலாம். ஒவ்வொரு எப்போக்கின் தொடக்கத்திலும் சோதனைச் சாவடிகள் நிகழ்கின்றன, மேலும் ஒவ்வொரு ஸ்லாட்டிலும் செயலில் உள்ள சரிபார்ப்பாளர்களின் ஒரு துணைக்குழு மட்டுமே சான்றளிக்கிறது, ஆனால் அனைத்து செயலில் உள்ள சரிபார்ப்பாளர்களும் ஒவ்வொரு எப்போக்கிலும் சான்றளிக்கிறார்கள் என்ற உண்மையைக் கணக்கில் கொள்ள அவை உள்ளன. எனவே, எப்போக்குகளுக்கு இடையில் மட்டுமே ஒரு 'பெரும்பான்மை இணைப்பை' நிரூபிக்க முடியும் (நெட்வொர்க்கில் மொத்தமாகப் பங்கீடு செய்யப்பட்ட ETH இல் 66% இரண்டு சோதனைச் சாவடிகளில் உடன்படும் இடம் இதுவாகும்). + +இறுதியாக்கம் பற்றிய கூடுதல் விவரங்களை கீழே காணலாம். + +## இறுதிநிலை {#finality} + +பரவலாக்கப்பட்ட நெட்வொர்க்குகளில் ஒரு பரிவர்த்தனைக்கு "இறுதியாக்கம்" என்பது, அது அதிக அளவு ETH எரிக்கப்படாமல் மாற்ற முடியாத ஒரு பிளாக்கின் பகுதியாக இருக்கும்போது ஏற்படுகிறது. பங்குச் சான்று எத்தேரியத்தில், இது "சோதனைச் சாவடி" பிளாக்குகளைப் பயன்படுத்தி நிர்வகிக்கப்படுகிறது. ஒவ்வொரு எப்போக்கிலும் முதல் பிளாக் ஒரு சோதனைச் சாவடி ஆகும். சரிபார்ப்பாளர்கள் தாங்கள் செல்லுபடியாகும் எனக் கருதும் சோதனைச் சாவடி ஜோடிகளுக்கு வாக்களிக்கின்றனர். ஒரு ஜோடி சோதனைச் சாவடிகள் மொத்தமாகப் பங்கீடு செய்யப்பட்ட ETH-இல் குறைந்தது மூன்றில் இரண்டு பங்கைக் குறிக்கும் வாக்குகளைப் பெற்றால், அந்தச் சோதனைச் சாவடிகள் மேம்படுத்தப்படுகின்றன. இரண்டில் மிகச் சமீபத்தியது (இலக்கு) "நியாயப்படுத்தப்பட்டது" ஆகிறது. இரண்டில் முந்தையது ஏற்கனவே நியாயப்படுத்தப்பட்டுள்ளது, ஏனெனில் அது முந்தைய எப்போக்கில் "இலக்காக" இருந்தது. இப்போது அது "இறுதி செய்யப்பட்டது" என மேம்படுத்தப்பட்டுள்ளது. சோதனைச் சாவடிகளை மேம்படுத்தும் இந்த செயல்முறை **[Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437)** ஆல் கையாளப்படுகிறது. Casper-FFG என்பது ஒருமித்த கருத்திற்கான ஒரு பிளாக் இறுதியாக்கக் கருவியாகும். ஒரு பிளாக் இறுதி செய்யப்பட்டவுடன், பெரும்பான்மையான பங்கீட்டாளர்களின் ஸ்லாஷிங் இல்லாமல் அதை மாற்றவோ அல்லது திரும்பப் பெறவோ முடியாது, இது பொருளாதார ரீதியாக சாத்தியமற்றதாக ஆக்குகிறது. + +இறுதி செய்யப்பட்ட பிளாக்கைத் திருப்புவதற்கு, ஒரு தாக்குபவர் மொத்தமாகப் பங்கீடு செய்யப்பட்ட ETH விநியோகத்தில் குறைந்தது மூன்றில் ஒரு பங்கை இழக்க ஒப்புக்கொள்வார். இதற்கான சரியான காரணம் இந்த [எத்தேரியம் ஃபவுண்டேஷன் வலைப்பதிவு இடுகையில்](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) விளக்கப்பட்டுள்ளது. இறுதியாக்கத்திற்கு மூன்றில் இரண்டு பங்கு பெரும்பான்மை தேவைப்படுவதால், ஒரு தாக்குபவர் மொத்தப் பங்கில் மூன்றில் ஒரு பங்குடன் வாக்களிப்பதன் மூலம் நெட்வொர்க் இறுதியாக்கத்தை அடைவதைத் தடுக்க முடியும். இதற்கு எதிராகப் பாதுகாக்க ஒரு பொறிமுறை உள்ளது: [செயல்படாத கசிவு](https://eth2book.info/bellatrix/part2/incentives/inactivity). சங்கிலி நான்கு எப்போக்குகளுக்கு மேல் இறுதி செய்யத் தவறும்போது இது செயல்படுத்தப்படுகிறது. செயல்படாத கசிவு, பெரும்பான்மைக்கு எதிராக வாக்களிக்கும் சரிபார்ப்பாளர்களிடமிருந்து பங்கீடு செய்யப்பட்ட ETH-ஐ வெளியேற்றுகிறது, இதனால் பெரும்பான்மை மூன்றில் இரண்டு பங்கு பெரும்பான்மையை மீண்டும் பெற்று சங்கிலியை இறுதி செய்ய அனுமதிக்கிறது. + +## கிரிப்டோ-பொருளாதார பாதுகாப்பு {#crypto-economic-security} + +ஒரு சரிபார்ப்பாளரை இயக்குவது ஒரு அர்ப்பணிப்பாகும். சரிபார்ப்பாளர் பிளாக் சரிபார்ப்பு மற்றும் முன்மொழிவில் பங்கேற்க போதுமான வன்பொருள் மற்றும் இணைப்பைப் பராமரிப்பார் என்று எதிர்பார்க்கப்படுகிறது. பதிலுக்கு, சரிபார்ப்பாளருக்கு ETH-இல் பணம் செலுத்தப்படுகிறது (அவர்களின் பங்கீடு செய்யப்பட்ட இருப்பு அதிகரிக்கிறது). மறுபுறம், ஒரு சரிபார்ப்பாளராகப் பங்கேற்பது, தனிப்பட்ட லாபம் அல்லது நாசவேலைக்காக நெட்வொர்க்கைத் தாக்க பயனர்களுக்கு புதிய வழிகளையும் திறக்கிறது. இதைத் தடுக்க, அழைக்கப்படும்போது பங்கேற்கத் தவறினால் சரிபார்ப்பாளர்கள் ETH வெகுமதிகளை இழக்கிறார்கள், மேலும் அவர்கள் நேர்மையற்ற முறையில் நடந்து கொண்டால் அவர்களின் இருக்கும் பங்கு அழிக்கப்படலாம். இரண்டு முதன்மை நடத்தைகள் நேர்மையற்றதாகக் கருதப்படலாம்: ஒரே ஸ்லாட்டில் பல பிளாக்குகளை முன்மொழிதல் (சமன்படுத்துதல்) மற்றும் முரண்பாடான சான்றளிப்புகளைச் சமர்ப்பித்தல். + +ஸ்லாஷ் செய்யப்பட்ட ETH-இன் அளவு, அதே நேரத்தில் எத்தனை சரிபார்ப்பாளர்கள் ஸ்லாஷ் செய்யப்படுகிறார்கள் என்பதைப் பொறுத்தது. இது ["தொடர்பு அபராதம்"](https://eth2book.info/bellatrix/part2/incentives/slashing#the-correlation-penalty) என்று அழைக்கப்படுகிறது, மேலும் இது சிறியதாக இருக்கலாம் (தனியாக ஸ்லாஷ் செய்யப்பட்ட ஒரு சரிபார்ப்பாளருக்கு ~1% பங்கு) அல்லது சரிபார்ப்பாளரின் 100% பங்கு அழிக்கப்படலாம் (வெகுஜன ஸ்லாஷிங் நிகழ்வு). இது ஒரு கட்டாய வெளியேற்ற காலத்தின் பாதியிலேயே விதிக்கப்படுகிறது, இது நாள் 1-இல் உடனடி அபராதத்துடன் (1 ETH வரை) தொடங்குகிறது, நாள் 18-இல் தொடர்பு அபராதம், மற்றும் இறுதியாக, நாள் 36-இல் நெட்வொர்க்கிலிருந்து வெளியேற்றப்படுகிறது. அவர்கள் நெட்வொர்க்கில் இருந்தாலும் வாக்குகளைச் சமர்ப்பிக்காததால் ஒவ்வொரு நாளும் சிறிய சான்றளிப்பு அபராதங்களைப் பெறுகிறார்கள். இதன் பொருள், ஒரு ஒருங்கிணைந்த தாக்குதல் தாக்குபவருக்கு மிகவும் விலை உயர்ந்ததாக இருக்கும். + +## ஃபோர்க் தேர்வு {#fork-choice} + +நெட்வொர்க் உகந்ததாகவும் நேர்மையாகவும் செயல்படும்போது, சங்கிலியின் தலையில் ஒரே ஒரு புதிய பிளாக் மட்டுமே இருக்கும், மேலும் அனைத்து சரிபார்ப்பாளர்களும் அதற்கு சான்றளிக்கின்றனர். இருப்பினும், நெட்வொர்க் தாமதம் காரணமாகவோ அல்லது ஒரு பிளாக் முன்மொழிபவர் சமன்படுத்தியதாலோ, சரிபார்ப்பாளர்கள் சங்கிலியின் தலையைப் பற்றி வெவ்வேறு பார்வைகளைக் கொண்டிருக்க முடியும். எனவே, ஒருமித்த கிளையன்ட்களுக்கு எதற்கு ஆதரவளிக்க வேண்டும் என்பதைத் தீர்மானிக்க ஒரு நெறிமுறை தேவைப்படுகிறது. பங்குச் சான்று எத்தேரியத்தில் பயன்படுத்தப்படும் நெறிமுறை [LMD-GHOST](https://arxiv.org/pdf/2003.03052.pdf) என்று அழைக்கப்படுகிறது, மேலும் இது அதன் வரலாற்றில் அதிக எடை கொண்ட சான்றளிப்புகளைக் கொண்ட ஃபோர்க்கை அடையாளம் காண்பதன் மூலம் செயல்படுகிறது. + +## பங்குச் சான்று மற்றும் பாதுகாப்பு {#pos-and-security} + +உழைப்புச் சான்றில் இருப்பது போலவே பங்குச் சான்றிலும் [51% தாக்குதல்](https://www.investopedia.com/terms/1/51-attack.asp) அச்சுறுத்தல் இன்னும் உள்ளது, ஆனால் இது தாக்குபவர்களுக்கு இன்னும் ஆபத்தானது. ஒரு தாக்குபவருக்கு பங்கீடு செய்யப்பட்ட ETH-இல் 51% தேவைப்படும். அவர்கள் தங்களுக்கு விருப்பமான ஃபோர்க் அதிக திரட்டப்பட்ட சான்றளிப்புகளைக் கொண்டது என்பதை உறுதிப்படுத்த தங்கள் சொந்த சான்றளிப்புகளைப் பயன்படுத்தலாம். திரட்டப்பட்ட சான்றளிப்புகளின் 'எடை' தான் ஒருமித்த கிளையன்ட்கள் சரியான சங்கிலியைத் தீர்மானிக்கப் பயன்படுத்துகின்றன, எனவே இந்தத் தாக்குபவர் தங்கள் ஃபோர்க்கை நியமனமானதாக மாற்ற முடியும். இருப்பினும், உழைப்புச் சான்றை விட பங்குச் சான்றின் ஒரு பலம் என்னவென்றால், சமூகம் ஒரு எதிர்-தாக்குதலை மேற்கொள்வதில் நெகிழ்வுத்தன்மையைக் கொண்டுள்ளது. உதாரணமாக, நேர்மையான சரிபார்ப்பாளர்கள் சிறுபான்மை சங்கிலியில் தொடர்ந்து கட்டமைக்கவும், தாக்குபவரின் ஃபோர்க்கைப் புறக்கணிக்கவும் முடிவு செய்யலாம், அதே நேரத்தில் பயன்பாடுகள், பரிமாற்றங்கள் மற்றும் பூல்களை அவ்வாறு செய்ய ஊக்குவிக்கலாம். அவர்கள் தாக்குபவரை நெட்வொர்க்கிலிருந்து வலுக்கட்டாயமாக அகற்றி, அவர்களின் பங்கீடு செய்யப்பட்ட ETH-ஐ அழிக்கவும் முடிவு செய்யலாம். இவை 51% தாக்குதலுக்கு எதிரான வலுவான பொருளாதாரப் பாதுகாப்புகளாகும். + +51% தாக்குதல்களுக்கு அப்பால், தீய நடிகர்கள் போன்ற பிற வகையான தீங்கிழைக்கும் செயல்களையும் முயற்சி செய்யலாம்: + +- நீண்ட தூரத் தாக்குதல்கள் (இறுதியாக்க கேஜெட் இந்தத் தாக்குதல் திசையனை நடுநிலையாக்குகிறது என்றாலும்) +- குறுகிய தூர 'மறுசீரமைப்புகள்' (முன்மொழிபவர் ஊக்கம் மற்றும் சான்றளிப்பு காலக்கெடு இதைத் தணிக்கிறது என்றாலும்) +- துள்ளல் மற்றும் சமநிலைப்படுத்தும் தாக்குதல்கள் (முன்மொழிபவர் ஊக்கத்தால் தணிக்கப்படுகிறது, மேலும் இந்தத் தாக்குதல்கள் எப்படியும் இலட்சியப்படுத்தப்பட்ட நெட்வொர்க் நிலைமைகளின் கீழ் மட்டுமே நிரூபிக்கப்பட்டுள்ளன) +- பனிச்சரிவுத் தாக்குதல்கள் (சமீபத்திய செய்தியை மட்டுமே கருத்தில் கொள்ளும் ஃபோர்க் தேர்வு நெறிமுறைகளின் விதியால் நடுநிலையாக்கப்பட்டது) + +ஒட்டுமொத்தமாக, எத்தேரியத்தில் செயல்படுத்தப்பட்டுள்ள பங்குச் சான்று, உழைப்புச் சான்றை விட பொருளாதார ரீதியாக அதிக பாதுகாப்பானது என்று நிரூபிக்கப்பட்டுள்ளது. + +## நன்மைகள் மற்றும் பாதகங்கள் {#pros-and-cons} + +| நிறைகள் | குறைகள் | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | +| பங்கீடு செய்தல், தனிநபர்கள் நெட்வொர்க்கைப் பாதுகாப்பதில் பங்கேற்பதை எளிதாக்குகிறது, பரவலாக்கலை ஊக்குவிக்கிறது. சரிபார்ப்பாளர் முனையை ஒரு சாதாரண மடிக்கணினியில் இயக்கலாம். பங்கீடு பூல்கள் 32 ETH இல்லாமல் பயனர்களைப் பங்கீடு செய்ய அனுமதிக்கின்றன. | உழைப்புச் சான்றுடன் ஒப்பிடும்போது பங்குச் சான்று இளமையானது மற்றும் குறைவான போர்க்களத்தில் சோதிக்கப்பட்டது | +| பங்கீடு செய்வது மிகவும் பரவலாக்கப்பட்டுள்ளது. PoW மைனிங்கில் பொருந்தும் அதே வழியில் அளவின் பொருளாதாரங்கள் பொருந்தாது. | உழைப்புச் சான்றை விட பங்குச் சான்று செயல்படுத்துவது மிகவும் சிக்கலானது | +| பங்குச் சான்று உழைப்புச் சான்றை விட அதிக கிரிப்டோ-பொருளாதாரப் பாதுகாப்பை வழங்குகிறது | எத்தேரியத்தின் பங்குச் சான்றில் பங்கேற்க பயனர்கள் மூன்று மென்பொருட்களை இயக்க வேண்டும். | +| நெட்வொர்க் பங்கேற்பாளர்களை ஊக்குவிக்க புதிய ETH-இன் குறைவான வெளியீடு தேவைப்படுகிறது | | + +### உழைப்புச் சான்றுடன் ஒப்பீடு {#comparison-to-proof-of-work} + +எத்தேரியம் முதலில் உழைப்புச் சான்றைப் பயன்படுத்தியது, ஆனால் செப்டம்பர் 2022-இல் பங்குச் சான்றுக்கு மாறியது. PoS ஆனது PoW ஐ விட பல நன்மைகளை வழங்குகிறது, அவை: + +- சிறந்த ஆற்றல் திறன் - உழைப்புச் சான்று கணக்கீடுகளில் அதிக ஆற்றலைப் பயன்படுத்தத் தேவையில்லை +- குறைந்த நுழைவுத் தடைகள், குறைக்கப்பட்ட வன்பொருள் தேவைகள் - புதிய பிளாக்குகளை உருவாக்கும் வாய்ப்பைப் பெற உயர் ரக வன்பொருள் தேவையில்லை +- குறைக்கப்பட்ட மையப்படுத்தல் ஆபத்து - பங்குச் சான்று நெட்வொர்க்கைப் பாதுகாக்கும் அதிக முனைகளுக்கு வழிவகுக்கும் +- குறைந்த ஆற்றல் தேவை காரணமாக, பங்கேற்பை ஊக்குவிக்க குறைவான ETH வெளியீடு தேவைப்படுகிறது +- தவறான நடத்தைக்கான பொருளாதார அபராதங்கள் உழைப்புச் சான்றுடன் ஒப்பிடும்போது 51% பாணித் தாக்குதல்களைத் தாக்குபவருக்கு அதிக செலவுள்ளதாக ஆக்குகின்றன +- ஒரு 51% தாக்குதல் கிரிப்டோ-பொருளாதாரப் பாதுகாப்புகளைத் தாண்டினால், சமூகம் ஒரு நேர்மையான சங்கிலியின் சமூக மீட்புக்கு தஞ்சம் அடையலாம். + +## மேலும் வாசிக்க {#further-reading} + +- [பங்குச் சான்று அடிக்கடி கேட்கப்படும் கேள்விகள்](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html) _Vitalik Buterin_ +- [பங்குச் சான்று என்றால் என்ன](https://consensys.net/blog/blockchain-explained/what-is-proof-of-stake/) _ConsenSys_ +- [பங்குச் சான்று என்பது என்ன, அது ஏன் முக்கியமானது](https://bitcoinmagazine.com/culture/what-proof-of-stake-is-and-why-it-matters-1377531463) _Vitalik Buterin_ +- [ஏன் பங்குச் சான்று (நவம்பர் 2020)](https://vitalik.eth.limo/general/2020/11/06/pos2020.html) _Vitalik Buterin_ +- [பங்குச் சான்று: பலவீனமான அகநிலைத்தன்மையை நான் எப்படி நேசிக்கக் கற்றுக்கொண்டேன்](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) _Vitalik Buterin_ +- [பங்குச் சான்று எத்தேரியம் தாக்குதல் மற்றும் பாதுகாப்பு](https://mirror.xyz/jmcook.eth/YqHargbVWVNRQqQpVpzrqEQ8IqwNUJDIpwRP7SS5FXs) +- [ஒரு பங்குச் சான்று வடிவமைப்பு தத்துவம்](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) _Vitalik Buterin_ +- [காணொளி: விட்டாலிக் புட்டரின் லெக்ஸ் ஃப்ரிட்மனுக்கு பங்குச் சான்றை விளக்குகிறார்](https://www.youtube.com/watch?v=3yrqBG-7EVE) + +## தொடர்புடைய தலைப்புகள் {#related-topics} + +- [வேலைக்கான சான்று](/developers/docs/consensus-mechanisms/pow/) +- [அதிகாரத்திற்கான சான்று](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/keys/index.md new file mode 100644 index 00000000000..cdee11a5d4b --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -0,0 +1,102 @@ +--- +title: "ப்ரூஃப்-ஆஃப்-ஸ்டேக் எத்தேரியத்தில் உள்ள விசைகள்" +description: "எத்தேரியத்தின் ப்ரூஃப்-ஆஃப்-ஸ்டேக் கருத்தொற்றுமைப் பொறிமுறையில் பயன்படுத்தப்படும் விசைகள் பற்றிய விளக்கம்" +lang: ta +--- + +Ethereum பயனர் சொத்துகளை public-private key cryptography மூலம் பாதுகாக்கிறது. Public key யின் அடிப்படையாக ஒரு Ethereum address உருவாக்கப்படுகிறது - அதாவது, இது பொது மக்கள் அனைவருக்கும் தெரியும் மற்றும் ஒரு தனிப்பட்ட அடையாளமாகப் பயன்படுகிறது. Private (அல்லது 'secret') key என்பது கணக்கு உரிமையாளரால் மட்டுமே அணுகக்கூடியதாக இருக்க வேண்டும். Private key ஐ பயன்படுத்தி பரிவர்த்தனைகள் மற்றும் தரவுகளை 'sign' செய்யப்படுகிறது, இதனால் cryptography மூலம் ஒரு குறிப்பிட்ட private key உடையவர் ஏதேனும் செயல்பாட்டை ஒப்புக்கொள்வதை நிரூபிக்க முடியும். + +எத்தேரியத்தின் விசைகள் [நீள்வட்ட வளைவு குறியாக்கவியல்](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) ஐப் பயன்படுத்தி உருவாக்கப்படுகின்றன. + +இருப்பினும், எத்தேரியம் [ப்ரூஃப்-ஆஃப்-ஒர்க்](/developers/docs/consensus-mechanisms/pow)-இலிருந்து [ப்ரூஃப்-ஆஃப்-ஸ்டேக்](/developers/docs/consensus-mechanisms/pos)-இற்கு மாறியபோது ஒரு புதிய வகை விசை எத்தேரியத்தில் சேர்க்கப்பட்டது. இயல்பாக இருந்த keys எவ்வித மாற்றமும் இல்லாமல் பழையவாறு இயங்கின, கணக்குகளைப் பாதுகாக்கும் elliptic-curve-based keys க்கான எந்த மாற்றமும் இல்லை. எனினும், proof-of-stake முறையில் பங்கேற்கவும் ETH ஐ staking மூலம் validators ஐ இயக்கவும் பயனர்களுக்குப் புதிய வகை key தேவைப்பட்டது. இது, ஒரு பெரிய எண்ணிக்கையிலான validators இடையே பல செய்திகள் பரிமாற்றம் செய்யும்போது ஏற்படும் scalability சவால்களைச் சமாளிக்க, நெட்வொர்க்கில் consensus பெறுவதற்கு தேவையான தகவல். + +இந்த புதிய வகை விசை [**போனே-லின்-ஷச்சாம் (BLS)** கையொப்பத் திட்டத்தை](https://wikipedia.org/wiki/BLS_digital_signature) பயன்படுத்துகிறது. இது ஒருங்கிணைந்த தனிப்பட்ட validator கீகளை மறுசீரமைக்கவும் சாத்தியமாக்குகிறது, மேலும் validators இடையே செயல்பாடுகளைநிர்வகிக்கச் சிறந்ததுு. + +## இரு வகையான சரிபார்ப்பவர் விசைகள் {#two-types-of-keys} + +Proof-of-stake மாறுவதற்கு முன்பு, Ethereum பயனர்களுக்குத் தங்களது நிதிகளை அணுக ஒரே elliptic-curve-based private key மட்டும் இருந்தது. ப்ரூஃப்-ஆஃப்-ஸ்டேக் அறிமுகப்படுத்தப்பட்டதன் மூலம், தனி ஸ்டேக்கர்களாக இருக்க விரும்பிய பயனர்களுக்கு **சரிபார்ப்பவர் விசை** மற்றும் **திரும்பப் பெறும் விசை** ஆகியவையும் தேவைப்பட்டன. + +### சரிபார்ப்பவர் விசை {#validator-key} + +Validator signing key இரண்டு கூறுகளைக் கொண்டது: + +- சரிபார்ப்பவரின் **தனிப்பட்ட** விசை +- சரிபார்ப்பவரின் **பொது** விசை + +சரிபார்ப்பவரின் தனிப்பட்ட விசையின் நோக்கம், தொகுதி முன்மொழிவுகள் மற்றும் சான்றளிப்புகள் போன்ற ஆன்செயின் செயல்பாடுகளில் கையொப்பமிடுவதாகும். இதனால், இந்தக் கீகள் hot wallet இல் வைத்திருக்க வேண்டும். + +சரிபார்ப்பவர் கையொப்பமிடும் விசைகளை ஒரு சாதனத்திலிருந்து மற்றொரு சாதனத்திற்கு மிக விரைவாக நகர்த்துவதற்கான நன்மையை இந்த நெகிழ்வுத்தன்மை கொண்டுள்ளது, இருப்பினும், அவை தொலைந்துவிட்டாலோ அல்லது திருடப்பட்டாலோ, ஒரு திருடன் சில வழிகளில் **தீங்கிழைக்கும் வகையில் செயல்படலாம்**: + +- Validator ஐ slashed செய்யவும்: + - ஒரே slot க்கு இரண்டு மாறுபட்ட beacon blocks கையொப்பமிடுவது + - மற்றொரு attestation ஐ "ஒட்டிய" attestation கையொப்பமிடுவது + - ஒரே target உடன் இரண்டு மாறுபட்ட attestations கையொப்பமிடுவது +- Voluntary exit ஐ கட்டாயமாக்குவது, இது validator ஐ staking செய்ய முடியாமல் ஆக்கிவிடும் மற்றும் withdrawal key உரிமையாளருக்கு ETH சமர்ப்பிக்கப்படும் + +ஒரு பயனர் ஸ்டேக்கிங் டெபாசிட் ஒப்பந்தத்தில் ETH ஐ டெபாசிட் செய்யும்போது **சரிபார்ப்பவரின் பொது விசை** பரிவர்த்தனைத் தரவில் சேர்க்கப்படும். இது _டெபாசிட் தரவு_ என்று அழைக்கப்படுகிறது, மேலும் இது சரிபார்ப்பவரை அடையாளம் காண எத்தேரியத்தை அனுமதிக்கிறது. + +### திரும்பப் பெறும் சான்றுகள் {#withdrawal-credentials} + +ஒவ்வொரு சரிபார்ப்பவருக்கும் _திரும்பப் பெறும் சான்றுகள்_ என அறியப்படும் ஒரு பண்பு உள்ளது. இந்த 32-பைட் புலத்தின் முதல் பைட் கணக்கு வகையை அடையாளம் காட்டுகிறது: `0x00` அசல் BLS (ஷபெல்லாவுக்கு முந்தைய, திரும்பப் பெற முடியாத) சான்றுகளைக் குறிக்கிறது, `0x01` ஒரு செயலாக்க முகவரியைக் குறிக்கும் மரபுவழிச் சான்றுகளைக் குறிக்கிறது, மற்றும் `0x02` நவீன கூட்டுச் சான்றுகள் வகையைக் குறிக்கிறது. + +`0x00` BLS விசைகளைக் கொண்ட சரிபார்ப்பவர்கள், உபரி இருப்பு கொடுப்பனவுகள் அல்லது ஸ்டேக்கிங்கிலிருந்து முழுமையாகத் திரும்பப் பெறுதல் ஆகியவற்றைச் செயல்படுத்த, இந்தச் சான்றுகளை ஒரு செயலாக்க முகவரியைக் குறிக்கும் வகையில் புதுப்பிக்க வேண்டும். ஆரம்ப விசை உருவாக்கத்தின் போது டெபாசிட் தரவில் ஒரு செயலாக்க முகவரியை வழங்குவதன் மூலம் இதைச் செய்யலாம், _அல்லது_ பின்னர் திரும்பப் பெறும் விசையைப் பயன்படுத்தி ஒரு `BLSToExecutionChange` செய்தியில் கையொப்பமிட்டு அதை ஒளிபரப்புவதன் மூலம் செய்யலாம். + +[சரிபார்ப்பவர் திரும்பப் பெறும் சான்றுகள் பற்றி மேலும்](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/) + +### திரும்பப் பெறும் விசை {#withdrawal-key} + +Withdrawal key இல் withdrawal credentials ஐ execution address க்கு pointing செய்ய, initial deposit க்கு முறையாக அமைக்கப்படாதால் தேவையாக இருக்கும். இது excess balance payments ஐ செயல்படுத்தத் தொடங்கும் மற்றும் பயனாளர்களுக்கு அவர்களின் staked ETH ஐ முழுமையாக எடுத்துக்கொள்ள உதவுகிறது. + +Validator keys போலவே, withdrawal keys க்கு இரண்டு கூறுகள் உள்ளன: + +- திரும்பப் பெறும் **தனிப்பட்ட** விசை +- திரும்பப் பெறும் **பொது** விசை + +திரும்பப் பெறும் சான்றுகளை `0x01` வகைக்குப் புதுப்பிப்பதற்கு முன்பு இந்த விசையை இழந்தால், சரிபார்ப்பவரின் இருப்புக்கான அணுகலை இழக்க நேரிடும். Validator இன்னும் attestations மற்றும் blocks களை கையொப்பமிட முடியும், ஏனெனில் இந்தச் செயல்கள் validator's private key ஐத் தேவைப்படுத்தும், ஆனால் withdrawal keys இழந்தால் அந்நிகரமாகக் குறைவாகவே தூண்டுதல் இருக்கும். + +Validator keys ஐ Ethereum account keys இல் இருந்து தனிப்படியாகக் கிளைத்தல், ஒரே பயனாளரால் பல validators ஐ இயக்க அனுமதிக்கிறது. + +![சரிபார்ப்பவர் விசை திட்ட வரைபடம்](validator-key-schematic.png) + +**குறிப்பு**: ஸ்டேக்கிங் கடமைகளிலிருந்து வெளியேறுவதற்கும், சரிபார்ப்பவரின் இருப்பைத் திரும்பப் பெறுவதற்கும் தற்போது சரிபார்ப்பவர் விசையுடன் [தன்னார்வ வெளியேற்றச் செய்தியில் (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) கையொப்பமிட வேண்டும். இருப்பினும், [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) என்பது ஒரு முன்மொழிவாகும், இது எதிர்காலத்தில் திரும்பப் பெறும் விசையுடன் வெளியேற்றச் செய்திகளில் கையொப்பமிடுவதன் மூலம் ஒரு சரிபார்ப்பவரின் வெளியேற்றத்தைத் தூண்டவும் அதன் இருப்பைத் திரும்பப் பெறவும் ஒரு பயனரை அனுமதிக்கும். [சேவை வழங்குநர்களாக ஸ்டேக்கிங்](/staking/saas/#what-is-staking-as-a-service)-இடம் ETH-ஐ ஒப்படைக்கும் ஸ்டேக்கர்கள் தங்கள் நிதிகளின் கட்டுப்பாட்டில் இருக்க இது உதவுவதன் மூலம் நம்பிக்கை அனுமானங்களைக் குறைக்கும். + +## ஒரு விதை சொற்றொடரிலிருந்து விசைகளைத் தருவித்தல் {#deriving-keys-from-seed} + +ஒவ்வொரு 32 ETH stakedக்கு புதிய 2 முற்றிலும் சுயாதீனமான விசைகளுக்குத் தேவையெனில், விசை மேலாண்மை விரைவில் கடுமையாகி விடும், குறிப்பாகப் பல validators ஐ இயக்கும் பயனாளர்களுக்கு. அதன் விளைவாக, ஒரே பொதுவான secret ஐப் பயன்படுத்தி பல validator keys ஐ உருவாக்க முடியும், மற்றும் அந்த ஒரே secret ஐ சேமிக்கல் மூலம் பல validator keys க்கு அணுகல் கிடைக்கும். + +[நினைவூட்டிகளும்](https://en.bitcoinwiki.org/wiki/Mnemonic_phrase) பாதைகளும் பயனர்கள் தங்கள் பணப்பைகளை [அணுகும்போது](https://ethereum.stackexchange.com/questions/19055/what-is-the-difference-between-m-44-60-0-0-and-m-44-60-0) அடிக்கடி சந்திக்கும் முக்கிய அம்சங்களாகும். Mnemonic என்பது தனிப்பட்ட விசைக்கு ஆரம்ப மூலமாகச் செயல்படும் சொற்கள் எனும் வரிசை ஆகும். கூடுதல் தரவுடன் இணைக்கப்பட்டபோதுு, mnemonic ஒரு hash ஐ உருவாக்குகிறது, இது 'master key' என அழைக்கப்படுகிறது. இதனை root என நினைத்துக் கொள்ளலாம். இந்த root இன் கிளைகள் பின்னர் ஒரு hierarchical path ஐப் பயன்படுத்தி உருவாக்கப்படும், இது child nodes களை parent node's hash மற்றும் மரத்தில் அவற்றின் index இன் கலவையாக க்கு உருவாக்கலாம். நினைவூட்டி அடிப்படையிலான விசை உருவாக்கத்திற்கான [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) மற்றும் [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) தரநிலைகளைப் பற்றிப் படிக்கவும். + +இந்த paths இன் கீழ்காணும் அமைப்பு உள்ளன, இது hardware wallets களுடன் தொடர்புடைய பயனாளர்களுக்குத் தெரிந்திருக்கும்: + +``` +m/44'/60'/0'/0` +``` + +இந்தப் பாதையில் உள்ள குறுக்குவிழிகள் (slashes) தனிப்பட்ட விசைகளின் கூறுகளைப் பிரிக்க உதவுகின்றன: + +``` +முதன்மை_விசை / நோக்கம் / நாணய_வகை / கணக்கு / மாற்றம் / முகவரி_குறியீட்டெண் +``` + +இந்தத் தர்க்கம், பயனர்கள் தங்களால் இயன்ற பல சரிபார்ப்பவர்களை ஒற்றை **நினைவூட்டிச் சொற்றொடருடன்** இணைக்க உதவுகிறது, ஏனெனில் மரத்தின் வேர் பொதுவானதாக இருக்கலாம், மேலும் கிளைகளில் வேறுபாடு நிகழலாம். பயனர் நினைவூட்டி சொற்றொடரிலிருந்து **எந்த எண்ணிக்கையிலான விசைகளையும் தருவிக்க** முடியும். + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +ஒவ்வொரு கிளையும் `/` ஆல் பிரிக்கப்பட்டுள்ளது, எனவே `m/2` என்பது முதன்மை விசையுடன் தொடங்கி கிளை 2-ஐப் பின்தொடர்வதைக் குறிக்கிறது. கீழே உள்ள படத்தில், ஒரு mnemonic phrase மூன்று withdrawal keys களைச் சேமிக்க பயன்படுகிறது, ஒவ்வொன்றுக்கும் இரண்டு validators இணைக்கப்பட்டுள்ளது. + +![சரிபார்ப்பவர் விசை தர்க்கம்](multiple-keys.png) + +## மேலும் வாசிக்க {#further-reading} + +- [கார்ல் பீக்குசென் எழுதிய எத்தேரியம் அறக்கட்டளை வலைப்பதிவு இடுகை](https://blog.ethereum.org/2020/05/21/keys/) +- [EIP-2333 BLS12-381 விசை உருவாக்கம்](https://eips.ethereum.org/EIPS/eip-2333) +- [EIP-7002: செயலாக்க அடுக்கு தூண்டப்பட்ட வெளியேற்றங்கள்](https://web.archive.org/web/20250125035123/https://research.2077.xyz/eip-7002-unpacking-improvements-to-staking-ux-post-merge) +- [பெரிய அளவில் விசை மேலாண்மை](https://docs.ethstaker.cc/ethstaker-knowledge-base/scaled-node-operators/key-management-at-scale) diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md new file mode 100644 index 00000000000..c7b90c09203 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md @@ -0,0 +1,69 @@ +--- +title: "Proof-of-stake மற்றும் proof-of-work" +description: "Ethereum-இன் proof-of-stake மற்றும் proof-of-work அடிப்படையிலான கருத்தொற்றுமை வழிமுறைகளின் ஒப்பீடு" +lang: ta +--- + +எதைத் தெரிவிக்கிறது என்றால் Ethereum தொடங்கியபோது, proof-of-stake இன்னும் அதிகமாக ஆராய்ச்சி மற்றும் மேம்பாடு செய்ய வேண்டியது இருந்தது, இது Ethereum ஐப் பாதுகாப்பாகச் செய்ய நம்பகமாக இருப்பதற்கு முன். Proof-of-work என்பது எளிமையான செயல்முறை ஆகும், இது ஏற்கனவே Bitcoin மூலம் நிரூபிக்கப்பட்டதால், மைய வளர்பவர்கள் அதை உடனடியாக நடைமுறைப்படுத்த Ethereum ஐத் தொடங்க அனுமதிக்க முடிந்தது. Proof-of-stake இனை நடைமுறைப்படுத்த 8 ஆண்டுகள் எடுத்தது. + +இந்தப் பக்கம் proof-of-work இருந்து proof-of-stake க்கு Ethereum நகர்த்தப்படுவதற்கான காரணங்களை மற்றும் அதில் உள்ள பரஸ்பர ஒப்பீடுகளை விளக்குகிறது. + +## பாதுகாப்பு {#security} + +Ethereum ஆராய்ச்சியாளர்கள் proof-of-stake ஐ proof-of-work விடப் பாதுகாப்பானது எனக் கருதுகின்றனர். இருப்பினும், இது சமீபத்திய காலத்தில் மட்டுமே Ethereum Mainnet இல் நடைமுறைப்படுத்தப்பட்டுள்ளது மற்றும் proof-of-work ஐவிட குறைவாக நேரத்தை நிரூபித்துள்ளது. Proof-of-stake க்கு இருக்கும் பாதுகாப்பு மாதிரியை proof-of-work உடன் ஒப்பிட்டுப் பார்த்து இதன் நன்மைகள் மற்றும் கேடுகள்பற்றிப் பின்வரும் பகுதிகள் விவாதிக்கின்றன. + +### தாக்குதலுக்கான செலவு {#cost-to-attack} + +Proof-of-stake முறையில், validators குறைந்தபட்சம் 32 ETH ஐ ஒரு smart contract இல் stake செய்ய வேண்டிய கட்டாயம் உள்ளது. தவறாக நடக்கும் validators க்களை தண்டிப்பதற்காக Ethereum அவர்கள் stake செய்த ether ஐ அழிக்க முடியும். Consensus அடைவதற்காக, மொத்த staked ether இல் குறைந்தபட்சம் 66% ஒரு குறிப்பிட்ட blocks குழுவின் ஆதரவுக்கு வாக்களிக்க வேண்டும். >=66% ஸ்டேக் வாக்களித்த தொகுதிகள் "இறுதிசெய்யப்பட்டவை" ஆகின்றன, அதாவது அவற்றை அகற்றவோ அல்லது மறுசீரமைக்கவோ முடியாது. + +நெட்வொர்க்கைத் தாக்குவதில் chain ஐ finalize செய்வதைத் தடுக்கவோ அல்லது canonical chain இல் ஒரு குறிப்பிட்ட blocks அமைப்பை நிச்சயமாக்கவோ, இத somehow ஒரு தாக்குபவர் பயனுள்ளதாக இருக்கும். இது, நியாயமான consensus க்கு path ஐ மாற்றி வைப்பதற்கு தாக்குபவர் பெரும்பாலான ether ஐ சேகரித்து அதனால் நேரடியாக வாக்களிப்பதன் மூலமாகவோ அல்லது நியாயமான validators களை ஒரு குறிப்பிட்ட விதமாக வாக்களிக்கத் தூண்டுவதன் மூலமாகவோ ஏற்படும். நுண்ணிய, குறைந்த probability கொண்ட தாக்குதல்கள் தவிர, Ethereum ஐத் தாக்குவதற்கான செலவு, consensus ஐ அவர்களது நன்மைக்காக மாற்றும் வகையில் தாக்குபவர் சேகரிக்க வேண்டிய stake இன் செலவாகும். + +தாக்குதலுக்கான மிகக் குறைந்த செலவானது மொத்த ஸ்டேக்கில் >33% ஆகும். மொத்த ஸ்டேக்கில் >33%-ஐ வைத்திருக்கும் ஒரு தாக்குதல்தாரி, வெறுமனே ஆஃப்லைனில் செல்வதன் மூலம் இறுதிப்படுத்தல் தாமதத்தை (finality delay) ஏற்படுத்த முடியும். இது நெட்வொர்க்கிற்கு மிகச் சிறிய பிரச்சனை, ஏனெனில் inactivity leak எனப்படும் ஒரு முறை offline validators களின் stake ஐ இழப்பதற்கான நடவடிக்கை எடுக்கும், இதனால் online majority மொத்த stake இன் 66% ஐ பிரதிநிதித்துவப்படுத்தி chain ஐ மீண்டும் finalize செய்ய முடியும். குறைந்தது 33% stake வைத்திருக்கும் ஒரு தாக்குபவர், block producer ஆகத் தேர்ந்தெடுக்கப்பட்டபோது ஒரே நேரத்தில் இரண்டு blocks உருவாக்கி, அனைத்து validators களுடன் இரட்டிப்பு வாக்கு அளிப்பதன் மூலம் இரட்டை finality ஏற்படுத்தலாம். ஒவ்வொரு fork க்கும் மீதமுள்ள நியாயமான validators க்களில் 50% பெறுவது போதுமானது, எனவே அவர்கள் தங்கள் messages ஐ சரியான நேரத்தில் அனுப்ப முடிந்தால், இரட்டை forks ஐ finalize செய்ய முடியலாம். இது வெற்றியடைய அதிக வாய்ப்பில்லை, ஆனால் ஒரு தாக்குபவர் இரட்டை finality ஏற்படுத்த முடியுமாயின், Ethereum சமூகத்தை ஒரு fork ஐ தேர்ந்தெடுக்கும்நிலைக்குக் கொண்டுவரர வேண்டும், அந்த நேரத்தில் தாக்குபவரின் validators மற்ற fork இல் slashed ஆகி விடும். + +மொத்த ஸ்டேக்கில் >33%-ஐக் கொண்டு, ஒரு தாக்குதல்தாரி Ethereum நெட்வொர்க்கில் ஒரு சிறிய (இறுதிப்படுத்தல் தாமதம்) அல்லது மிகவும் கடுமையான (இரட்டை இறுதிப்படுத்தல்) விளைவை ஏற்படுத்தும் வாய்ப்புள்ளது. நெட்வொர்க்கில் 14,000,000-க்கும் அதிகமான ETH ஸ்டேக் செய்யப்பட்டிருப்பதாலும், ஒரு ETH-க்கு $1000 என்ற பிரதிநிதித்துவ விலையினாலும், இந்தத் தாக்குதல்களை நடத்துவதற்கான குறைந்தபட்ச செலவு `1000 x 14,000,000 x 0.33 = $4,620,000,000` ஆகும். Slashing மூலம் தாக்குபவர் இந்தப் பணத்தை இழந்து, நெட்வொர்க்கிலிருந்து வெளியேற்றப்படுவர். மீண்டும் தாக்குதல் நடத்த, அவர்கள் (மீண்டும்) ஸ்டேக்கில் >33%-ஐத் திரட்டி அதை (மீண்டும்) எரிக்க வேண்டும். நெட்வொர்க்கைத் தாக்கும் ஒவ்வொரு முயற்சிக்கும் >$4.6 பில்லியன் செலவாகும் ($1000/ETH மற்றும் 14M ETH ஸ்டேக் செய்யப்பட்ட நிலையில்). Attacker slashed செய்யப்பட்ட பிறகு, அவர்களை மீண்டும் நெட்வொர்க்கில் சேர்க்க activation queue வழியாகச் செல்ல வேண்டியிருக்கும். அதாவது, மீண்டும் நிகழும் தாக்குதல் விகிதமானது, தாக்குபவர் மொத்த ஸ்டேக்கில் >33%-ஐத் திரட்டக்கூடிய விகிதத்திற்கு மட்டுமல்ல, அவருடைய அனைத்து சரிபார்ப்பாளர்களையும் நெட்வொர்க்கில் சேர்ப்பதற்கு எடுக்கும் நேரத்திற்கும் மட்டுப்படுத்தப்பட்டுள்ளது. ஒவ்வொரு முறையும் தாக்குபவர் தாக்குதல் நடத்தும்போது, அவர் மிகச் சிறிது பணம் இழக்கிறார், மற்றவர்கள் நிறைய பணம் பெறுகின்றனர், ஏனெனில் resulting supply shock மூலம். + +51% attacks அல்லது finality reversion போன்ற பிற தாக்குதல்கள், மொத்த stake இன் 66% ஐ உடையதாக இருப்பது போன்றவை, மிகவும் அதிக ETH தேவைப்படுவதாகவும், attacker க்கு மிகுந்த செலவாகவும் இருக்கும். + +இதை proof-of-work உடன் ஒப்பிடுகை. proof-of-work Ethereum-இல் ஒரு தாக்குதலைத் தொடங்குவதற்கான செலவு என்பது, மொத்த நெட்வொர்க் ஹாஷ் விகிதத்தில் >50%-ஐ தொடர்ந்து வைத்திருப்பதற்கான செலவாகும். இதற்கான செலவு, மற்ற miners களை முந்தி proof-of-work தீர்வுகளைத் தொடர்ந்து கண்டுபிடிக்கத் தேவையான கணிப்பொறி சக்திக்கான hardware மற்றும் இயங்கும் செலவுகள் ஆகும். Ethereum பெரும்பாலும் GPUs ஐப் பயன்படுத்தி mined செய்யப்பட்டது, இது cost ஐ குறைத்தது (ஆனால் Ethereum proof-of-work இல் தொடர்ந்து இருந்திருந்தால், ASIC miningஅதிகமாகப் பிரபலமாகியிருக்கலாம்). Proof-of-work Ethereum நெட்வொர்க்கில் தாக்குதல் நடத்த attacker க்கு அதிக அளவிலான hardware ஐ வாங்கி, அதை இயங்க வைக்கத் தேவையான மின்சாரத்திற்கு செலவு செய்ய வேண்டும், ஆனால் மொத்த cost, ஒரு தாக்குதல் நடத்த போதுமான அளவு ETH சேகரிக்க தேவையான செலவுக்குக் குறைவாகவே இருக்கும். proof-of-stake-ஐ விட proof-of-work-இல் ஒரு 51% தாக்குதல் ~[20x குறைவான](https://youtu.be/1m12zgJ42dI?t=1562) செலவுடையது. தாக்குதல் கண்டறியப்பட்டு chain hard-forked செய்யப்பட்டு அவர்களின் மாற்றங்கள் அகற்றப்பட்டால், attacker அதே hardware ஐப் பயன்படுத்தி புதிய fork மீது மீண்டும் தாக்குதல் நடத்தலாம். + +### சிக்கலான தன்மை {#complexity} + +Proof-of-stake என்பது proof-of-work விட மிக அதிகமாகச் சிக்கலானது. இது proof-of-work க்கு ஆதரவான ஒரு அம்சமாகக் கருதப்படலாம், ஏனெனில் எளிதான நெறிமுறைகளில் தவறுகள் அல்லது எதிர்பாராத விளைவுகளை அறிமுகப்படுத்துவது கடினமாக இருக்கும். இருப்பினும, இந்தச் சிக்கலானதுு பல ஆண்டுகளாக மேற்கொள்ளப்பட்ட ஆராய்ச்சி மற்றும் வளர்ச்சியால, சிக்கல்களைச் சரிசெய்துு, முறைப்படுத்தப்பட்டுள்ளது. Proof-of-stake நெறிமுறைகள் ஐந்து தனித்தனி குழுக்களால் ஐந்து வேறுபட்ட நிரலாக்க மொழிகளில் சுயாதீனமாகச் செயல்படுத்தப்பட்டுள்ளதால், client பிழைகளுக்கு எதிரான பாதுகாப்பு கிடைக்கிறது. + +Proof-of-stake நெருக்கடியான கணிப்பு மற்றும் பரிசோதனைகளுக்குப் பாதுகாப்பாக வளர்த்துச் சோதிக்க, Beacon Chain என்பது proof-of-stake ஐ Ethereum Mainnet இல் செயல்படுத்துவதற்கு இரண்டு ஆண்டுகள் முன்பு அறிமுகப்படுத்தப்பட்டது. Beacon Chain proof-of-stake பரிசோதனைக்கு sandbox ஆகச் செயல்பட்டது, ஏனெனில் இது proof-of-stake க்கு ஏற்பான நெருக்கடியான நெறிமுறையைச் செயல்படுத்தும் நேரடி blockchain ஆக இருந்தது, ஆனால் உண்மையான Ethereum பரிமாற்றங்களைத் தீண்டாமல் - ஒரு முறை proof-of-stake மேல் சம்மதம் பெறுவதில் மட்டுமே செயல்பட்டு வந்தது. இது நன்றாக நிலைத்ததற்கும், பிழையின்றி நீண்ட காலம் செயல்பட்ட பிறகு, Beacon Chain Ethereum Mainnet உடன் "merged" செய்யப்பட்டது. இந்த அனைத்தும் proof-of-stake சிக்கல்பாட்டை சரிசெய்து, எதிர்பாராத விளைவுகளோ அல்லது client பிழைகளின் அபாயம் மிகவும் குறைவாகும். + +### தாக்குதல் பரப்பு {#attack-surface} + +Proof-of-stake என்பது proof-of-work க்கு விட அதிகமாகச் சிக்கலானது, இதனால் அதிக தாக்குதல்களுக்கு வாய்ப்புகள் அதிகரிக்கின்றன. ஒரு peer-to-peer நெட்வொர்க்இணைப்புக்குப் பதிலாகக, இரண்டு தனித்தனிநெறிமுறைகளைச் செயல்படுத்தும் நெட்வொர்க்கள் உள்ளன. ஒவ்வொரு slot இலும் ஒரு குறிப்பிட்ட validator முன்கூட்டியே தேர்ந்தெடுக்கப்படுவது, அந்த validator ஐ இலக்காகக் கொண்டு அதிகளவிலான நெட்வொர்க் போக்குவரத்தால் denial-of-service தாக்குதலை ஏற்படுத்தும் வாய்ப்பை உருவாக்குகிறது. + +மேலும், தங்கள் blocks அல்லது attestations ஐ வெளியிடுவதற்கான நேரத்தைக் கவனமாகத் தேர்ந்தெடுத்து, அதை ஒரு குறிப்பிட்ட அளவிலான நியாயமான network ஆனது பெற்றுக்கொள்வதற்கான வழிகளும் உள்ளன. இதனால், அவர்கள் குறிப்பிட்ட முறையில் வாக்களிக்க ஊக்குவிக்கப்படுகின்றனர். இறுதியாக, ஒரு தாக்குதலாளர் தக்க அளவு ETH சேர்த்துப் stake செய்து, consensus நெறிமுறையை ஆதிக்கப்படுத்த முடியும். இந்த ஒவ்வொரு [தாக்குதல் வழிகளுக்கும் அதனுடன் தொடர்புடைய பாதுகாப்புகள் உள்ளன](/developers/docs/consensus-mechanisms/pos/attack-and-defense), ஆனால் proof-of-work-இன் கீழ் பாதுகாக்கப்பட வேண்டிய இந்த வழிகள் இருப்பதில்லை. + +## பரவலாக்கம் {#decentralization} + +Proof-of-stake என்பது proof-of-work உடன் ஒப்பிடுகையில் மிகுந்த மையமற்ற தன்மையைக் கொண்டுள்ளது, ஏனெனில் mining hardware ஆயுதப் போட்டிகள் தனிநபர்களையும் சிறிய நிறுவனங்களையும் பொருட்செலவிலிருந்து விலக்கி விடுகின்றன. யாரும் நன்கு இயங்கும் சாதாரண hardware மூலம் mining ஐத் தொடங்குவதற்குத் தொழில்நுட்ப ரீதியாக முடியும், ஆனால் தங்களுக்கு ஏதேனும் பலன் கிடைக்கும் வாய்ப்பு, நிறுவன மின்தொழிலாளர் நடவடிக்கைகளுடன் ஒப்பிடுகையில் மிகுந்த சிறியதாகும். Proof-of-stake உடன், staking செலவுகளும், அதிலிருந்து கிடைக்கும் சதவீத லாபமும் அனைவருக்கும் ஒரே மாதிரியானவை. தற்போதைய நிலையில், ஒரு validator ஐ இயக்க 32 ETH செலவாகின்றது. + +மறுபுறம், liquid staking derivatives இன் கண்டுபிடிப்பு மையமயமாக்கல் குறித்த கவலைகளை உருவாக்கியுள்ளது, ஏனெனில் சில பெரிய வழங்குநர்கள் பெரிய அளவிலான staked ETH ஐ நிர்வகிக்கின்றனர். இது ஒரு சிக்கலானது, மேலும் விரைவில் சரிசெய்யப்பட வேண்டியது அவசியமாகிறது. ஆனால் இது தோன்றும் அளவிற்கு எளிமையானது அல்ல. மையமயமாக்கப்பட்ட staking வழங்குநர்கள், அவசியம் validators மீது மையமயமாக்கப்பட்ட கட்டுப்பாட்டைக் கொண்டிருக்கிறார்கள் என்றில்லை - பொதுவாக இது பல சுதந்திரமான node operators க்கு தங்களுடைய சொந்த 32 ETH இல்லாமல் ETH க்கான மையக் குளத்தை உருவாக்க ஒரு வழியாக மட்டுமே உள்ளது. + +Ethereum க்கு சிறந்த தேர்வு, validators ஐ வீட்டு கணினிகளில் உள்ளூர் செயல்படுத்துவது, மையமற்ற தன்மையை அதிகரிப்பதாகும். இதனால் Ethereum node/validator ஐ இயக்குவதற்கான hardware தேவைகளை அதிகரிக்கும் மாற்றங்களை எதிர்க்கின்றது. + +## நிலைத்தன்மை {#sustainability} + +Proof-of-stake என்பது blockchain ஐப் பாதுகாப்பாக வைத்திருக்க மிகக் குறைந்த carbon செலவான வழியாகும். Proof-of-work முறையில், miners ஒரு block ஐ mine செய்யும் உரிமையைப் பெறுவதற்காகப் போட்டிபோடுகின்றனர். Miners அதிக வெற்றியடைவது, அவர்கள் கணக்கீடுகளை விரைவாகச் செய்ய முடியும்போது மட்டுமே ஆகும், இது hardware மற்றும் ஆற்றல் நுகர்வில் முதலீடு செய்யத் தூண்டுகிறது. இது Ethereum க்கு proof-of-stake முறைமைக்கு மாறும் முன்பே கண்டறியப்பட்டது. Proof-of-stake க்கு மாறுவதற்கு முன்னதாக Ethereum சுமார் 78 TWh/yr எனும் அளவுக்கு ஆற்றல் நுகர்ந்து வந்தது - இது ஒரு சிறிய நாட்டிற்கு இணையானது. ஆனால் proof-of-stake க்கு மாறுவதால் இந்த ஆற்றல் செலவு ~99.98% ஆகக் குறைக்கப்பட்டது. Proof-of-stake Ethereum ஐ ஒரு ஆற்றல் திறன் வாய்ந்த, குறைந்த carbon கொண்ட தளமாக மாற்றியது. + +[Ethereum-இன் ஆற்றல் நுகர்வு பற்றி மேலும்](/energy-consumption) + +## வெளியீடு {#issuance} + +Proof-of-stake Ethereum தனது பாதுகாப்பைக் கட்டியணைக்க proof-of-work Ethereum விட மிகவும் குறைவான coins ஐ வெளியிட்டுச் செலுத்த முடியும், ஏனெனில் validators க்கு அதிக மின் கட்டணத்தைச் செலுத்த வேண்டியதில்லை. இதன் விளைவாக, ETH தனது பணவீக்கம் குறையவோ அல்லது பெரும்பாலான ETH அழிக்கப்படும்போது deflationary ஆகவோ மாறும். குறைந்த பணவீக்கம் என்பதற்குள், Ethereum இன் பாதுகாப்பு, proof-of-work விடக் குறைந்த செலவாக உள்ளது. + +## பார்த்து கற்பவரா? {#visual-learner} + +Justin Drake proof-of-stake இன் proof-of-work மீது கிடைக்கும் பலன்களை விளக்கும் காணொளியைப் பாருங்கள்: + + + +## மேலும் வாசிக்க {#further-reading} + +- [Vitalik-இன் proof-of-stake வடிவமைப்புத் தத்துவம்](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [Vitalik-இன் proof-of-stake அடிக்கடி கேட்கப்படும் கேள்விகள்](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [PoS மற்றும் PoW குறித்த "எளிமையாக விளக்கப்பட்ட" காணொளி](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..eec040308c0 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,91 @@ +--- +title: "பங்குச் சான்று வெகுமதிகள் மற்றும் தண்டனைகள்" +description: "பங்குச் சான்று எத்தேரியத்தில் உள்ள நெறிமுறைக்குட்பட்ட ஊக்குவிப்புகள் பற்றி அறியவும்." +lang: ta +--- + +எத்தேரியம் அதன் சொந்த கிரிப்டோகரன்சியான ஈதர் (ETH) ஐப் பயன்படுத்திப் பாதுகாக்கப்படுகிறது. பிளாக்குகளைச் சரிபார்ப்பதிலும், சங்கிலியின் தலையைக் கண்டறிவதிலும் பங்கேற்க விரும்பும் முனை ஆபரேட்டர்கள், எத்தேரியத்தில் உள்ள [வைப்பு ஒப்பந்தத்திற்குள்](/staking/deposit-contract/) ஈதரை டெபாசிட் செய்கிறார்கள். பியர்-டு-பியர் நெட்வொர்க் மூலம் பெறப்பட்ட புதிய பிளாக்குகளின் செல்லுபடியை சரிபார்க்கும் சரிபார்ப்பாளர் மென்பொருளை இயக்குவதற்கும், சங்கிலியின் தலையைக் கண்டறிய ஃபோர்க்-சாய்ஸ் அல்காரிதத்தைப் பயன்படுத்துவதற்கும் அவர்களுக்கு ஈதரில் பணம் செலுத்தப்படுகிறது. + +ஒரு சரிபார்ப்பாளருக்கு இரண்டு முதன்மைப் பாத்திரங்கள் உள்ளன: 1) புதிய பிளாக்குகளைச் சரிபார்த்து, அவை செல்லுபடியாகும் பட்சத்தில் அவற்றுக்கு “சான்றளிப்பது”, 2) மொத்த சரிபார்ப்பாளர் தொகுப்பிலிருந்து தோராயமாகத் தேர்ந்தெடுக்கப்படும்போது புதிய பிளாக்குகளை முன்மொழிவது. கேட்கப்படும்போது இந்த இரண்டு பணிகளில் ஏதேனும் ஒன்றைச் செய்ய சரிபார்ப்பாளர் தவறினால், அவர்கள் ஈதர் செலுத்துகையை இழக்கிறார்கள். சரிபார்ப்பாளர்கள் சில சமயங்களில் கையொப்பத் திரட்டல் மற்றும் ஒத்திசைவுக் குழுக்களில் பங்கேற்கும் பணிகளையும் மேற்கொள்கின்றனர். + +தற்செயலாகச் செய்வதற்கு மிகவும் கடினமான மற்றும் சில தீங்கிழைக்கும் நோக்கத்தைக் குறிக்கும் சில செயல்களும் உள்ளன, அதாவது ஒரே ஸ்லாட்டிற்கு பல பிளாக்குகளை முன்மொழிவது அல்லது ஒரே ஸ்லாட்டிற்கு பல பிளாக்குகளுக்குச் சான்றளிப்பது. இவை “ஸ்லாஷ் செய்யக்கூடிய” நடத்தைகள், இதன் விளைவாக சரிபார்ப்பாளர் நெட்வொர்க்கிலிருந்து அகற்றப்படுவதற்கு முன்பு, ஒரு குறிப்பிட்ட அளவு ஈதர் (1 ETH வரை) எரிக்கப்படும், இதற்கு 36 நாட்கள் ஆகும். ஸ்லாஷ் செய்யப்பட்ட சரிபார்ப்பாளரின் ஈதர் வெளியேறும் காலம் முழுவதும் மெதுவாகக் குறைகிறது, ஆனால் 18 ஆம் நாளில் அவர்கள் ஒரு “தொடர்பு அபராதத்தைப்” பெறுகிறார்கள், இது ஒரே நேரத்தில் அதிக சரிபார்ப்பாளர்கள் ஸ்லாஷ் செய்யப்படும்போது பெரியதாக இருக்கும். எனவே, ஒருமித்த பொறிமுறையின் ஊக்கக் கட்டமைப்பு நேர்மைக்கு வெகுமதி அளிக்கிறது மற்றும் தீய செயல்களைத் தண்டிக்கிறது. + +அனைத்து வெகுமதிகளும் தண்டனைகளும் ஒரு ஈப்பாக்கிற்கு ஒரு முறை பயன்படுத்தப்படுகின்றன. + +மேலும் விவரங்களுக்குத் தொடர்ந்து படிக்கவும்... + +## வெகுமதிகள் மற்றும் தண்டனைகள் {#rewards} + +### பரிசுகள் {#rewards} + +சரிபார்ப்பாளர்கள் மற்ற சரிபார்ப்பாளர்களின் பெரும்பான்மையுடன் ஒத்துப்போகும் வாக்குகளை அளிக்கும்போதும், அவர்கள் பிளாக்குகளை முன்மொழியும்போதும், ஒத்திசைவுக் குழுக்களில் பங்கேற்கும்போதும் வெகுமதிகளைப் பெறுகிறார்கள். ஒவ்வொரு ஈப்பாக்கிலும் உள்ள வெகுமதிகளின் மதிப்பு `base_reward` இலிருந்து கணக்கிடப்படுகிறது. இது மற்ற வெகுமதிகள் கணக்கிடப்படும் அடிப்படை அலகு ஆகும். `base_reward` என்பது ஒரு ஈப்பாக்கிற்கு உகந்த சூழ்நிலையில் ஒரு சரிபார்ப்பாளர் பெறும் சராசரி வெகுமதியைக் குறிக்கிறது. இது சரிபார்ப்பாளரின் செயலிலுள்ள இருப்பு மற்றும் செயலில் உள்ள மொத்த சரிபார்ப்பாளர்களின் எண்ணிக்கையிலிருந்து பின்வருமாறு கணக்கிடப்படுகிறது: + +``` +base_reward = effective_balance * (base_reward_factor / (base_rewards_per_epoch * sqrt(sum(active_balance)))) +``` + +`base_reward_factor` 64 ஆகவும், `base_rewards_per_epoch` 4 ஆகவும் மற்றும் `sum(active balance)` என்பது அனைத்து செயலில் உள்ள சரிபார்ப்பாளர்களிலும் உள்ள மொத்தப் பங்கு வைக்கப்பட்ட ஈதர் ஆகும். + +இதன் பொருள், அடிப்படை வெகுமதி சரிபார்ப்பாளரின் செயலிலுள்ள இருப்புக்கு விகிதாசாரமாகவும், நெட்வொர்க்கில் உள்ள சரிபார்ப்பாளர்களின் எண்ணிக்கைக்கு நேர்மாறாகவும் இருக்கும். சரிபார்ப்பாளர்கள் அதிகமாக இருந்தால், ஒட்டுமொத்த வெளியீடு அதிகமாக இருக்கும் (`sqrt(N)` ஆக), ஆனால் ஒரு சரிபார்ப்பாளருக்கான `base_reward` குறைவாக இருக்கும் (`1/sqrt(N)` ஆக). இந்தக் காரணிகள் ஒரு பங்கு வைப்பு முனைக்கான APR-ஐ பாதிக்கின்றன. [விடாலிக்கின் குறிப்புகளில்](https://notes.ethereum.org/@vbuterin/rkhCgQteN?type=view#Base-rewards) இதற்கான காரணத்தைப் படிக்கவும். + +மொத்த வெகுமதி பின்னர் ஐந்து கூறுகளின் கூட்டுத்தொகையாகக் கணக்கிடப்படுகிறது, ஒவ்வொன்றும் ஒரு எடையைக் கொண்டுள்ளன, இது ஒவ்வொரு கூறும் மொத்த வெகுமதியில் எவ்வளவு சேர்க்கிறது என்பதைத் தீர்மானிக்கிறது. கூறுகளாவன: + +``` +1. மூல வாக்கு: சரிபார்ப்பாளர் சரியான மூல சோதனைச் சாவடிக்கு சரியான நேரத்தில் வாக்களித்துள்ளார் +2. இலக்கு வாக்கு: சரிபார்ப்பாளர் சரியான இலக்கு சோதனைச் சாவடிக்கு சரியான நேரத்தில் வாக்களித்துள்ளார் +3. தலைப் பகுதிக்கான வாக்கு: சரிபார்ப்பாளர் சரியான தலைப் பகுதி பிளாக்கிற்கு சரியான நேரத்தில் வாக்களித்துள்ளார் +4. ஒத்திசைவுக் குழு வெகுமதி: சரிபார்ப்பாளர் ஒரு ஒத்திசைவுக் குழுவில் பங்கேற்றுள்ளார் +5. முன்மொழிபவர் வெகுமதி: சரிபார்ப்பாளர் சரியான ஸ்லாட்டில் ஒரு பிளாக்கை முன்மொழிந்துள்ளார் +``` + +ஒவ்வொரு கூறுக்குமான எடைகள் பின்வருமாறு: + +``` +TIMELY_SOURCE_WEIGHT uint64(14) +TIMELY_TARGET_WEIGHT uint64(26) +TIMELY_HEAD_WEIGHT uint64(14) +SYNC_REWARD_WEIGHT uint64(2) +PROPOSER_WEIGHT uint64(8) +``` + +இந்த எடைகளின் கூட்டுத்தொகை 64 ஆகும். பொருந்தக்கூடிய எடைகளின் கூட்டுத்தொகையை 64 ஆல் வகுப்பதன் மூலம் வெகுமதி கணக்கிடப்படுகிறது. சரியான நேரத்தில் மூலம், இலக்கு மற்றும் தலைப் பகுதி வாக்குகளை அளித்த, ஒரு பிளாக்கை முன்மொழிந்த மற்றும் ஒரு ஒத்திசைவுக் குழுவில் பங்கேற்ற ஒரு சரிபார்ப்பாளர் `64/64 * base_reward == base_reward` பெறலாம். இருப்பினும், ஒரு சரிபார்ப்பாளர் வழக்கமாக ஒரு பிளாக் முன்மொழிபவர் அல்ல, எனவே அவர்களின் அதிகபட்ச வெகுமதி `64-8 /64 * base_reward == 7/8 * base_reward` ஆகும். பிளாக் முன்மொழிபவர்களாகவோ அல்லது ஒத்திசைவுக் குழுவில் இல்லாத சரிபார்ப்பாளர்கள் `64-8-2 / 64 * base_reward == 6.75/8 * base_reward` பெறலாம். + +விரைவான சான்றளிப்புகளை ஊக்குவிக்க கூடுதல் வெகுமதி சேர்க்கப்படுகிறது. இது `inclusion_delay_reward` ஆகும். பிளாக் முன்மொழிவு மற்றும் சான்றளிப்பைப் பிரிக்கும் ஸ்லாட்டுகளின் எண்ணிக்கை `delay` ஆக இருக்கும் இடத்தில், இது `base_reward` ஐ `1/delay` ஆல் பெருக்கினால் கிடைக்கும் மதிப்புக்குச் சமம். உதாரணமாக, பிளாக் முன்மொழிவின் ஒரு ஸ்லாட்டிற்குள் சான்றளிப்பு சமர்ப்பிக்கப்பட்டால், சான்றளிப்பவர் `base_reward * 1/1 == base_reward` ஐப் பெறுகிறார். அடுத்த ஸ்லாட்டில் சான்றளிப்பு வந்தால், சான்றளிப்பவர் `base_reward * 1/2` ஐப் பெறுகிறார், இப்படியே தொடரும். + +பிளாக் முன்மொழிபவர்கள் பிளாக்கில் சேர்க்கப்பட்டுள்ள **ஒவ்வொரு செல்லுபடியான சான்றளிப்புக்கும்** `8 / 64 * base_reward` ஐப் பெறுகிறார்கள், எனவே வெகுமதியின் உண்மையான மதிப்பு சான்றளிக்கும் சரிபார்ப்பாளர்களின் எண்ணிக்கையுடன் அளவிடப்படுகிறது. பிளாக் முன்மொழிபவர்கள் தங்கள் முன்மொழியப்பட்ட பிளாக்கில் மற்ற சரிபார்ப்பாளர்களின் தவறான நடத்தைக்கான ஆதாரத்தைச் சேர்ப்பதன் மூலம் தங்கள் வெகுமதியை அதிகரிக்கலாம். இந்த வெகுமதிகள் சரிபார்ப்பாளர் நேர்மையை ஊக்குவிக்கும் "காரட்கள்" ஆகும். ஸ்லாஷிங்கை உள்ளடக்கிய ஒரு பிளாக் முன்மொழிபவருக்கு `slashed_validators_effective_balance / 512` வெகுமதி அளிக்கப்படும். + +### தண்டனைகள் {#penalties} + +இதுவரை நாங்கள் முற்றிலும் நன்கு நடந்துகொள்ளும் சரிபார்ப்பாளர்களைக் கருத்தில் கொண்டுள்ளோம், ஆனால் சரியான நேரத்தில் தலைப் பகுதி, மூலம் மற்றும் இலக்கு வாக்குகளை அளிக்காத அல்லது மெதுவாகச் செய்யும் சரிபார்ப்பாளர்களைப் பற்றி என்ன? + +இலக்கு மற்றும் மூல வாக்குகளைத் தவறவிட்டதற்கான தண்டனைகள், சான்றளிப்பவர் அவற்றைச் சமர்ப்பித்திருந்தால் பெற்றிருக்கக்கூடிய வெகுமதிகளுக்குச் சமம். இதன் பொருள், வெகுமதியை அவர்களின் இருப்பில் சேர்ப்பதற்குப் பதிலாக, சமமான மதிப்பு அவர்களின் இருப்பிலிருந்து அகற்றப்படும். தலைப் பகுதி வாக்கை தவறவிட்டதற்கு எந்தத் தண்டனையும் இல்லை (அதாவது, தலைப் பகுதி வாக்குகள் மட்டுமே வெகுமதி அளிக்கப்படுகின்றன, ஒருபோதும் தண்டிக்கப்படுவதில்லை). `inclusion_delay` உடன் தொடர்புடைய எந்தத் தண்டனையும் இல்லை - வெகுமதி சரிபார்ப்பாளரின் இருப்பில் சேர்க்கப்படாது. ஒரு பிளாக்கை முன்மொழியத் தவறியதற்கும் எந்தத் தண்டனையும் இல்லை. + +[ஒருமித்த விவரக்குறிப்புகளில்](https://github.com/ethereum/consensus-specs/blob/dev/specs/altair/beacon-chain.md) வெகுமதிகள் மற்றும் தண்டனைகள் பற்றி மேலும் படிக்கவும். பெலாட்ரிக்ஸ் மேம்படுத்தலில் வெகுமதிகள் மற்றும் தண்டனைகள் சரிசெய்யப்பட்டன - இந்த [Peep an EIP வீடியோவில்](https://www.youtube.com/watch?v=iaAEGs1DMgQ) டேனி ரியான் மற்றும் விடாலிக் இது குறித்து விவாதிப்பதைப் பாருங்கள். + +## ஸ்லாஷிங் {#slashing} + +ஸ்லாஷிங் என்பது ஒரு கடுமையான செயலாகும், இதன் விளைவாக ஒரு சரிபார்ப்பாளர் நெட்வொர்க்கிலிருந்து வலுக்கட்டாயமாக அகற்றப்படுவார் மற்றும் அவர்களின் பங்கு வைக்கப்பட்ட ஈதரை இழப்பார். ஒரு சரிபார்ப்பாளரை ஸ்லாஷ் செய்ய மூன்று வழிகள் உள்ளன, இவை அனைத்தும் பிளாக்குகளின் நேர்மையற்ற முன்மொழிவு அல்லது சான்றளிப்பைக் குறிக்கின்றன: + +- ஒரே ஸ்லாட்டிற்கு இரண்டு வெவ்வேறு பிளாக்குகளை முன்மொழிந்து கையொப்பமிடுவதன் மூலம் +- மற்றொன்றைச் "சூழ்ந்துள்ள" ஒரு பிளாக்கிற்கு சான்றளிப்பதன் மூலம் (வரலாற்றைத் திறம்பட மாற்றுவது) +- ஒரே பிளாக்கிற்கு இரண்டு வேட்பாளர்களுக்குச் சான்றளிப்பதன் மூலம் "இரட்டை வாக்களித்தல்" + +இந்த நடவடிக்கைகள் கண்டறியப்பட்டால், சரிபார்ப்பாளர் ஸ்லாஷ் செய்யப்படுகிறார். இதன் பொருள், ஒரு 32 ETH சரிபார்ப்பாளருக்கு (செயலிலுள்ள இருப்புடன் நேரியல் ரீதியாக அளவிடப்படுகிறது) 0.0078125 உடனடியாக எரிக்கப்படுகிறது, பின்னர் 36 நாள் அகற்றும் காலம் தொடங்குகிறது. இந்த அகற்றும் காலத்தில் சரிபார்ப்பாளரின் பங்கு படிப்படியாகக் குறைந்துவிடும். நடுப்பகுதியில் (நாள் 18) ஒரு கூடுதல் தண்டனை பயன்படுத்தப்படுகிறது, அதன் அளவு ஸ்லாஷிங் நிகழ்வுக்கு முந்தைய 36 நாட்களில் ஸ்லாஷ் செய்யப்பட்ட அனைத்து சரிபார்ப்பாளர்களின் மொத்த பங்கு வைக்கப்பட்ட ஈதருடன் அளவிடப்படுகிறது. இதன் பொருள், அதிக சரிபார்ப்பாளர்கள் ஸ்லாஷ் செய்யப்படும்போது, ஸ்லாஷின் அளவு அதிகரிக்கிறது. அதிகபட்ச ஸ்லாஷ் என்பது ஸ்லாஷ் செய்யப்பட்ட அனைத்து சரிபார்ப்பாளர்களின் முழுமையான செயலிலுள்ள இருப்பாகும் (அதாவது, நிறைய சரிபார்ப்பாளர்கள் ஸ்லாஷ் செய்யப்பட்டால் அவர்கள் தங்கள் முழுப் பங்கையும் இழக்க நேரிடும்). மறுபுறம், ஒரு தனிமைப்படுத்தப்பட்ட ஒற்றை ஸ்லாஷிங் நிகழ்வு சரிபார்ப்பாளரின் பங்கில் ஒரு சிறிய பகுதியை மட்டுமே எரிக்கிறது. ஸ்லாஷ் செய்யப்பட்ட சரிபார்ப்பாளர்களின் எண்ணிக்கையுடன் அளவிடப்படும் இந்த நடுப்பகுதி தண்டனை "தொடர்பு அபராதம்" என்று அழைக்கப்படுகிறது. + +## செயலற்ற கசிவு {#inactivity-leak} + +ஒருமித்த அடுக்கு நான்கு ஈப்பாக்குகளுக்கு மேல் இறுதிப்படுத்தப்படாமல் சென்றிருந்தால், "செயலற்ற கசிவு" எனப்படும் அவசரகால நெறிமுறை செயல்படுத்தப்படுகிறது. செயலற்ற கசிவின் இறுதி நோக்கம், சங்கிலி இறுதித்தன்மையை மீட்டெடுக்கத் தேவையான நிலைமைகளை உருவாக்குவதாகும். மேலே விளக்கியபடி, இறுதித்தன்மைக்கு, மொத்தப் பங்கு வைக்கப்பட்ட ஈதரில் 2/3 பெரும்பான்மை மூலம் மற்றும் இலக்கு சோதனைச் சாவடிகளை ஒப்புக்கொள்ள வேண்டும். மொத்த சரிபார்ப்பாளர்களில் 1/3 க்கும் அதிகமானோரைக் குறிக்கும் சரிபார்ப்பாளர்கள் ஆஃப்லைனில் சென்றாலோ அல்லது சரியான சான்றளிப்புகளைச் சமர்ப்பிக்கத் தவறினாலோ, 2/3 பெரும்பான்மையினரால் சோதனைச் சாவடிகளை இறுதி செய்ய முடியாது. செயலற்ற சரிபார்ப்பாளர்களுக்குச் சொந்தமான பங்கு, மொத்தப் பங்கில் 1/3 க்கும் குறைவாக அவர்கள் கட்டுப்படுத்தும் வரை படிப்படியாகக் குறைய செயலற்ற கசிவு அனுமதிக்கிறது, இது மீதமுள்ள செயலில் உள்ள சரிபார்ப்பாளர்களை சங்கிலியை இறுதி செய்ய அனுமதிக்கிறது. செயலற்ற சரிபார்ப்பாளர்களின் தொகுப்பு எவ்வளவு பெரியதாக இருந்தாலும், மீதமுள்ள செயலில் உள்ள சரிபார்ப்பாளர்கள் இறுதியில் பங்கில் >2/3 ஐக் கட்டுப்படுத்துவார்கள். பங்கு இழப்பு என்பது செயலற்ற சரிபார்ப்பாளர்களை விரைவில் மீண்டும் செயல்படுத்த ஒரு வலுவான ஊக்கமாகும்! மெடல்லா டெஸ்ட்நெட்டில் < 66% செயலில் உள்ள சரிபார்ப்பாளர்கள் பிளாக்செயினின் தற்போதைய தலைப் பகுதியில் ஒருமித்த கருத்துக்கு வர முடிந்தபோது ஒரு செயலற்ற கசிவு நிலைமை ஏற்பட்டது. செயலற்ற கசிவு செயல்படுத்தப்பட்டது மற்றும் இறுதித்தன்மை இறுதியில் மீண்டும் பெறப்பட்டது! + +ஒருமித்த பொறிமுறையின் வெகுமதி, தண்டனை மற்றும் ஸ்லாஷிங் வடிவமைப்பு தனிப்பட்ட சரிபார்ப்பாளர்களைச் சரியாக நடந்துகொள்ள ஊக்குவிக்கிறது. இருப்பினும், இந்த வடிவமைப்புத் தேர்வுகளிலிருந்து பல வாடிக்கையாளர்கள் முழுவதும் சரிபார்ப்பாளர்களின் சமமான விநியோகத்தை வலுவாக ஊக்குவிக்கும் ஒரு அமைப்பு உருவாகிறது, மேலும் ஒற்றை-வாடிக்கையாளர் ஆதிக்கத்தை வலுவாக ஊக்கப்படுத்த வேண்டும். + +## மேலும் வாசிக்க {#further-reading} + +- [எத்தேரியத்தை மேம்படுத்துதல்: ஊக்க அடுக்கு](https://eth2book.info/altair/part2/incentives) +- [எத்தேரியத்தின் கலப்பின காஸ்பர் நெறிமுறையில் ஊக்குவிப்புகள்](https://arxiv.org/pdf/1903.04205.pdf) +- [விடாலிக்கின் சிறுகுறிப்பு விவரக்குறிப்பு](https://github.com/ethereum/annotated-spec/blob/master/phase0/beacon-chain.md#rewards-and-penalties-1) +- [Eth2 ஸ்லாஷிங் தடுப்பு குறிப்புகள்](https://medium.com/prysmatic-labs/eth2-slashing-prevention-tips-f6faa5025f50) +- [EIP-7251-இன் கீழ் ஸ்லாஷிங் தண்டனைகளின் பகுப்பாய்வு](https://ethresear.ch/t/slashing-penalty-analysis-eip-7251/16509) + +_ஆதாரங்கள்_ + +- _[https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/](https://benjaminion.xyz/eth2-annotated-spec/phase0/beacon-chain/)_ diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md new file mode 100644 index 00000000000..e9affa341d6 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -0,0 +1,39 @@ +--- +title: "வலுவற்ற அகநிலை" +description: "வலுவற்ற அகநிலை மற்றும் PoS எத்தேரியத்தில் அதன் பங்கு பற்றிய ஒரு விளக்கம்." +lang: ta +--- + +பிளாக்செயின்களில் உள்ள அகநிலை என்பது தற்போதைய நிலையில் உடன்பட சமூகத் தகவல்களைச் சார்ந்திருப்பதாகும். நெட்வொர்க்கில் உள்ள பிற பயனர்களிடமிருந்து சேகரிக்கப்பட்ட தகவல்களின்படி தேர்ந்தெடுக்கப்பட்ட பல செல்லுபடியாகும் ஃபோர்க்குகள் இருக்கலாம். இதற்கு நேர்மாறானது புறநிலைத்தன்மை ஆகும், இது சங்கிலிகளைக் குறிக்கிறது, அங்கு சாத்தியமான ஒரே ஒரு செல்லுபடியாகும் சங்கிலி உள்ளது, அதில் அனைத்து முனைகளும் அவற்றின் குறியிடப்பட்ட விதிகளைப் பயன்படுத்துவதன் மூலம் அவசியமாக ஒப்புக்கொள்ளும். வலுவற்ற அகநிலை எனப்படும் மூன்றாவது நிலையும் உள்ளது. சில ஆரம்பத் தகவல்கள் சமூக ரீதியாகப் பெறப்பட்ட பிறகு புறநிலையாக முன்னேறக்கூடிய ஒரு சங்கிலியை இது குறிக்கிறது. + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +இந்தப் பக்கத்தைப் புரிந்துகொள்ள, முதலில் [பங்குச் சான்று](/developers/docs/consensus-mechanisms/pos/) இன் அடிப்படைகளைப் புரிந்துகொள்வது அவசியம். + +## வலுவற்ற அகநிலை என்ன சிக்கல்களைத் தீர்க்கிறது? {#problems-ws-solves} + +பல்வேறு ஃபோர்க்குகளில் இருந்து சரியான சங்கிலியைத் தேர்ந்தெடுப்பது வரலாற்று வாக்குகளை எண்ணுவதன் மூலம் செய்யப்படுவதால், பங்குச் சான்று பிளாக்செயின்களுக்கு அகநிலை இயல்பாகவே உள்ளது. இது பிளாக்செயினைப் பல தாக்குதல் வழிகளுக்கு வெளிப்படுத்துகிறது, நீண்ட தூரத் தாக்குதல்கள் உட்பட, சங்கிலியில் மிக ஆரம்பத்தில் பங்கேற்ற முனைகள் ஒரு மாற்று ஃபோர்க்கைப் பராமரிக்கின்றன, அவை பின்னர் தங்களுக்குச் சாதகமாக வெளியிடுகின்றன. மாற்றாக, 33% சரிபார்ப்பவர்கள் தங்கள் பங்கைத் திரும்பப் பெற்றாலும், தொடர்ந்து தொகுதிகளை சான்றளித்து உற்பத்தி செய்தால், அவை நியமனச் சங்கிலியுடன் முரண்படும் ஒரு மாற்று ஃபோர்க்கை உருவாக்கக்கூடும். புதிய முனைகள் அல்லது நீண்ட காலமாக ஆஃப்லைனில் இருக்கும் முனைகள் இந்தத் தாக்கும் சரிபார்ப்பவர்கள் தங்கள் நிதியைத் திரும்பப் பெற்றதை அறிந்திருக்க மாட்டார்கள், எனவே தாக்குபவர்கள் தவறான சங்கிலியைப் பின்பற்ற அவர்களை ஏமாற்றக்கூடும். எத்தேரியம் இந்தத் தாக்குதல் வழிகளை பொறிமுறையின் அகநிலை அம்சங்களையும் - அதனால் நம்பகத்தன்மை அனுமானங்களையும் - குறைந்தபட்சமாகக் குறைக்கும் கட்டுப்பாடுகளை விதிப்பதன் மூலம் தீர்க்க முடியும். + +## வலுவற்ற அகநிலைச் சோதனைச் சாவடிகள் {#ws-checkpoints} + +"வலுவற்ற அகநிலைச் சோதனைச் சாவடிகளை"ப் பயன்படுத்துவதன் மூலம் பங்குச் சான்று எத்தேரியத்தில் வலுவற்ற அகநிலை செயல்படுத்தப்படுகிறது. நெட்வொர்க்கில் உள்ள அனைத்து முனைகளும் நியமனச் சங்கிலியில் உள்ளதாக ஒப்புக்கொள்ளும் நிலை மூலங்கள் இவை. பிளாக்செயினில் ஆதியாகம நிலையில் இல்லாததைத் தவிர, அவை ஆதியாகம தொகுதிகளைப் போலவே அதே "உலகளாவிய உண்மை" நோக்கத்திற்குச் சேவை செய்கின்றன. ஃபோர்க் தேர்வு வழிமுறை அந்த சோதனைச் சாவடியில் வரையறுக்கப்பட்ட பிளாக்செயின் நிலை சரியானது என்றும், அந்த இடத்திலிருந்து சங்கிலியை சுயாதீனமாகவும் புறநிலையாகவும் சரிபார்க்கிறது என்றும் நம்புகிறது. வலுவற்ற அகநிலைச் சோதனைச் சாவடிகளுக்கு முன் அமைந்துள்ள தொகுதிகளை மாற்ற முடியாததால், சோதனைச் சாவடிகள் "திரும்புவதற்கான வரம்புகளாக" செயல்படுகின்றன. இது பொறிமுறை வடிவமைப்பின் ஒரு பகுதியாக நீண்ட தூர ஃபோர்க்குகளைச் செல்லாததாக வரையறுப்பதன் மூலம் நீண்ட தூரத் தாக்குதல்களை வெறுமனே குறைமதிப்பிற்கு உட்படுத்துகிறது. வலுவற்ற அகநிலைச் சோதனைச் சாவடிகள் சரிபார்ப்பவர் திரும்பப் பெறும் காலத்தை விட சிறிய தூரத்தால் பிரிக்கப்படுவதை உறுதிசெய்வது, சங்கிலியை ஃபோர்க் செய்யும் சரிபார்ப்பவர் தங்கள் பங்கைத் திரும்பப் பெறுவதற்கு முன்பு குறைந்தபட்சம் சில வரம்புத் தொகையாவது குறைக்கப்படுவதையும், பங்கு திரும்பப் பெறப்பட்ட சரிபார்ப்பவர்களால் புதிய நுழைபவர்கள் தவறான ஃபோர்க்குகளுக்கு ஏமாற்றப்பட முடியாது என்பதையும் உறுதி செய்கிறது. + +## வலுவற்ற அகநிலை சோதனைச் சாவடிகளுக்கும் இறுதி செய்யப்பட்ட தொகுதிகளுக்கும் உள்ள வேறுபாடு {#difference-between-ws-and-finalized-blocks} + +இறுதி செய்யப்பட்ட தொகுதிகள் மற்றும் வலுவற்ற அகநிலை சோதனைச் சாவடிகள் எத்தேரியம் முனைகளால் வித்தியாசமாகக் கையாளப்படுகின்றன. ஒரு முனை இரண்டு போட்டியிடும் இறுதி செய்யப்பட்ட தொகுதிகளைப் பற்றி அறிந்தால், அது இரண்டிற்கும் இடையில் பிரிக்கப்படுகிறது - எது நியமன ஃபோர்க் என்பதைத் தானாக அடையாளம் காண வழி இல்லை. இது ஒருமித்த கருத்து தோல்வியின் அறிகுறியாகும். இதற்கு மாறாக, ஒரு முனை அதன் வலுவற்ற அகநிலை சோதனைச் சாவடியுடன் முரண்படும் எந்தத் தொகுதியையும் நிராகரிக்கிறது. முனையின் கண்ணோட்டத்தில், வலுவற்ற அகநிலை சோதனைச் சாவடியானது ஒரு முழுமையான உண்மையைக் குறிக்கிறது, இது அதன் சக நண்பர்களிடமிருந்து வரும் புதிய அறிவால் குறைக்கப்பட முடியாது. + +## வலுவற்றது எந்தளவிற்கு வலுவற்றது? {#how-weak-is-weak} + +எத்தேரியத்தின் பங்குச் சான்றின் அகநிலை அம்சம் என்பது, ஒத்திசைக்க ஒரு நம்பகமான மூலத்திலிருந்து சமீபத்திய நிலை (வலுவற்ற அகநிலை சோதனைச் சாவடி) தேவைப்படுவதாகும். மோசமான வலுவற்ற அகநிலைச் சோதனைச் சாவடியைப் பெறுவதற்கான ஆபத்து மிகவும் குறைவு, ஏனெனில் அவை தொகுதி ஆய்வு கருவிகள் அல்லது பல முனைகள் போன்ற பல சுயாதீன பொது ஆதாரங்களுக்கு எதிராகச் சரிபார்க்கப்படலாம். இருப்பினும், எந்தவொரு மென்பொருள் பயன்பாட்டையும் இயக்க எப்போதும் ஒரு குறிப்பிட்ட அளவு நம்பிக்கை தேவைப்படுகிறது, எடுத்துக்காட்டாக, மென்பொருள் உருவாக்குநர்கள் நேர்மையான மென்பொருளைத் தயாரித்துள்ளனர் என்று நம்புவது. + +ஒரு வலுவற்ற அகநிலை சோதனைச் சாவடி வாடிக்கையாளர் மென்பொருளின் ஒரு பகுதியாக கூட வரலாம். ஒரு தாக்குபவர் மென்பொருளில் உள்ள சோதனைச் சாவடியை சிதைக்க முடியும், மேலும் மென்பொருளையே அவ்வளவு எளிதாக சிதைக்க முடியும் என்று வாதிடலாம். இந்தப் பிரச்சினைக்கு உண்மையான கிரிப்டோ-பொருளாதார வழி எதுவுமில்லை, ஆனால் பல சுயாதீன வாடிக்கையாளர் குழுக்களைக் கொண்டிருப்பதன் மூலம் எத்தேரியத்தில் நம்பத்தகாத உருவாக்குநர்களின் தாக்கம் குறைக்கப்படுகிறது, ஒவ்வொன்றும் வெவ்வேறு மொழிகளில் சமமான மென்பொருளை உருவாக்குகின்றன, இவை அனைத்தும் நேர்மையான சங்கிலியைப் பராமரிப்பதில் அக்கறை கொண்டுள்ளன. தொகுதி ஆய்வு கருவிகள் வலுவற்ற அகநிலை சோதனைச் சாவடிகளை வழங்கலாம் அல்லது கூடுதல் மூலத்திற்கு எதிராக மற்ற இடங்களிலிருந்து பெறப்பட்ட சோதனைச் சாவடிகளைக் குறுக்கு-குறிப்பு செய்வதற்கான வழியையும் வழங்கலாம். + +இறுதியாக, பிற முனைகளிலிருந்து சோதனைச் சாவடிகளைக் கோரலாம்; ஒரு முழு முனையை இயக்கும் மற்றொரு எத்தேரியம் பயனர் ஒரு சோதனைச் சாவடியை வழங்கலாம், அதை சரிபார்ப்பவர்கள் தொகுதி ஆய்வு கருவியிலிருந்து தரவுகளுக்கு எதிராகச் சரிபார்க்கலாம். ஒட்டுமொத்தமாக, ஒரு வலுவற்ற அகநிலை சோதனைச் சாவடியை வழங்குபவரை நம்புவது வாடிக்கையாளர் உருவாக்குநர்களை நம்புவது போல சிக்கலானதாகக் கருதலாம். தேவைப்படும் ஒட்டுமொத்த நம்பிக்கை குறைவு. பெரும்பான்மையான சரிபார்ப்பவர்கள் பிளாக்செயினின் மாற்று ஃபோர்க்கை உருவாக்க சதி செய்யும் சாத்தியமில்லாத நிகழ்வில் மட்டுமே இந்தக் கருத்தாய்வுகள் முக்கியமானதாக மாறும் என்பதைக் கவனத்தில் கொள்ள வேண்டியது அவசியம். வேறு எந்த சூழ்நிலையிலும், தேர்வு செய்ய ஒரே ஒரு எத்தேரியம் சங்கிலி மட்டுமே உள்ளது. + +## மேலும் வாசிக்க {#further-reading} + +- [Eth2 இல் வலுவற்ற அகநிலை](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [விட்டாலிக்: வலுவற்ற அகநிலையை நான் எப்படி விரும்பக் கற்றுக்கொண்டேன்](https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/) +- [வலுவற்ற அகநிலை (Teku ஆவணங்கள்)](https://docs.teku.consensys.io/concepts/weak-subjectivity) +- [கட்டம்-0 வலுவற்ற அகநிலை வழிகாட்டி](https://github.com/ethereum/consensus-specs/blob/dev/specs/phase0/weak-subjectivity.md) +- [எத்தேரியம் 2.0 இல் வலுவற்ற அகநிலையின் பகுப்பாய்வு](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md new file mode 100644 index 00000000000..4abceb9f562 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md @@ -0,0 +1,64 @@ +--- +title: "திரும்பப் பெறுவதற்கான சான்றுகள்" +description: "சரிபார்ப்பாளர் திரும்பப் பெறும் நற்சான்றிதழ் வகைகளின் (0x00, 0x01, 0x02) விளக்கம் மற்றும் எத்தேரியம் பணயம் வைப்பவர்களுக்கான அவற்றின் தாக்கங்கள்." +lang: ta +--- + +ஒவ்வொரு சரிபார்ப்பாளருக்கும் ஒரு **திரும்பப் பெறும் நற்சான்றிதழ்** உள்ளது, அது அவர்களின் பணயம் வைக்கப்பட்ட ETH மற்றும் வெகுமதிகளை எப்படி, எங்கே திரும்பப் பெறலாம் என்பதைத் தீர்மானிக்கிறது. நற்சான்றிதழ் வகை முதல் பைட்டால் குறிக்கப்படுகிறது: `0x00`, `0x01`, அல்லது `0x02`. தங்கள் பணயத்தை நிர்வகிக்கும் சரிபார்ப்பாளர்களுக்கு இந்த வகைகளைப் புரிந்துகொள்வது முக்கியம். + +## 0x00: ஷபெல்லாவுக்கு முந்தைய நற்சான்றிதழ்கள் {#0x00-credentials} + +`0x00` வகை என்பது ஷபெல்லா மேம்படுத்தலுக்கு (ஏப்ரல் 2023) முந்தைய அசல் திரும்பப் பெறும் நற்சான்றிதழ் வடிவமாகும். இந்த நற்சான்றிதழ் வகையுடைய சரிபார்ப்பாளர்களுக்கு செயல்படுத்தும் அடுக்கு திரும்பப் பெறும் முகவரி எதுவும் அமைக்கப்படவில்லை, அதாவது அவர்களின் நிதிகள் ஒருமித்த அடுக்கில் பூட்டப்பட்டிருக்கும். உங்களிடம் இன்னும் `0x00` நற்சான்றிதழ்கள் இருந்தால், நீங்கள் ஏதேனும் திரும்பப் பெறுதல்களைப் பெறுவதற்கு முன்பு `0x01` அல்லது `0x02` க்கு மேம்படுத்த வேண்டும். + +## 0x01: மரபுவழி திரும்பப் பெறும் நற்சான்றிதழ்கள் {#0x01-credentials} + +`0x01` வகை ஷபெல்லா மேம்படுத்தலுடன் அறிமுகப்படுத்தப்பட்டது மற்றும் செயல்படுத்தும் அடுக்கு திரும்பப் பெறும் முகவரியை அமைக்க விரும்பிய சரிபார்ப்பாளர்களுக்கான தரநிலையாக இது மாறியது. `0x01` நற்சான்றிதழ்களுடன்: + +- 32 ETH க்கு மேல் உள்ள எந்த இருப்பும் உங்கள் திரும்பப் பெறும் முகவரிக்கு **தானாகவே மாற்றப்படும்** +- முழு வெளியேற்றங்கள் நிலையான வெளியேறும் வரிசை மூலம் செல்கின்றன +- 32 ETH க்கு மேலான வெகுமதிகள் கூட்டு வட்டி பெற முடியாது—அவை அவ்வப்போது வெளியேற்றப்படுகின்றன + +**ஏன் சில சரிபார்ப்பாளர்கள் இன்னும் 0x01 ஐப் பயன்படுத்துகிறார்கள்:** இது எளிமையானது மற்றும் பழக்கமானது. பல சரிபார்ப்பாளர்கள் ஷபெல்லாவுக்குப் பிறகு டெபாசிட் செய்து ஏற்கனவே இந்த வகையைக் கொண்டுள்ளனர், மேலும் அதிகப்படியான இருப்பை தானாக திரும்பப் பெற விரும்புவோருக்கு இது நன்றாக வேலை செய்கிறது. + +**ஏன் இது பரிந்துரைக்கப்படவில்லை:** `0x01` உடன், 32 ETH க்கு மேல் வெகுமதிகளைக் கூட்டும் திறனை நீங்கள் இழக்கிறீர்கள். ஒவ்வொரு சிறு உபரியும் தானாகவே மாற்றப்படுகிறது, இது உங்கள் சரிபார்ப்பாளரின் சம்பாதிக்கும் திறனைக் கட்டுப்படுத்துகிறது மற்றும் திரும்பப் பெறப்பட்ட நிதிகளைத் தனியாக நிர்வகிக்க வேண்டும். + +## 0x02: கூட்டு வட்டி பெறும் திரும்பப் பெறும் நற்சான்றிதழ்கள் {#0x02-credentials} + +`0x02` வகை Pectra மேம்படுத்தலுடன் அறிமுகப்படுத்தப்பட்டது மற்றும் இன்றைய சரிபார்ப்பாளர்களுக்கு இது **பரிந்துரைக்கப்பட்ட தேர்வாகும்**. `0x02` நற்சான்றிதழ்களைக் கொண்ட சரிபார்ப்பாளர்கள் சில நேரங்களில் "கூட்டு வட்டி பெறும் சரிபார்ப்பாளர்கள்" என்று அழைக்கப்படுகிறார்கள். + +`0x02` நற்சான்றிதழ்களுடன்: + +- 32 ETH க்கு மேலான வெகுமதிகள் 1 ETH அதிகரிப்புகளில், அதிகபட்சம் 2048 ETH பயனுள்ள இருப்பு வரை **கூட்டு வட்டி பெறும்** +- பகுதி திரும்பப் பெறுதல்களை கைமுறையாகக் கோர வேண்டும் (2048 ETH வரம்புக்கு மேல் மட்டுமே தானியங்கி மாற்றங்கள் நிகழும்) +- சரிபார்ப்பாளர்கள் பல 32 ETH சரிபார்ப்பாளர்களை ஒரே அதிக இருப்பு கொண்ட சரிபார்ப்பாளராக ஒருங்கிணைக்க முடியும் +- முழு வெளியேற்றங்கள் நிலையான வெளியேறும் வரிசை மூலம் இன்னும் ஆதரிக்கப்படுகின்றன + +பகுதி திரும்பப் பெறுதல்கள் மற்றும் ஒருங்கிணைப்புகள் ஆகிய இரண்டையும் [Launchpad சரிபார்ப்பாளர் செயல்பாடுகள்](https://launchpad.ethereum.org/en/validator-actions) வழியாகச் செய்யலாம். + +**சரிபார்ப்பாளர்கள் ஏன் 0x02 ஐ விரும்ப வேண்டும்:** இது கூட்டு வட்டி மூலம் சிறந்த மூலதனத் திறனையும், திரும்பப் பெறுதல்கள் எப்போது நிகழும் என்பதில் அதிகக் கட்டுப்பாட்டையும் வழங்குகிறது, மேலும் சரிபார்ப்பாளர் ஒருங்கிணைப்பையும் ஆதரிக்கிறது. காலப்போக்கில் வெகுமதிகளைக் குவிக்கும் தனி பணயம் வைப்பவர்களுக்கு, கைமுறைத் தலையீடு இல்லாமல் அவர்களின் பயனுள்ள இருப்பு—அதன் மூலம் அவர்களின் வெகுமதிகளும்—32 ETH க்கு மேல் வளர முடியும் என்பதே இதன் பொருள். + +**முக்கியம்:** நீங்கள் `0x01` இலிருந்து `0x02` க்கு மாற்றியவுடன், உங்களால் மீண்டும் பழைய நிலைக்குத் திரும்ப முடியாது. + +வகை 2 நற்சான்றிதழ்களுக்கு மாற்றுவது மற்றும் MaxEB அம்சம் பற்றிய விரிவான வழிகாட்டிக்கு, [MaxEB விளக்கிப் பக்கத்தைப்](/roadmap/pectra/maxeb/) பார்க்கவும். + +## நான் எதைத் தேர்ந்தெடுக்க வேண்டும்? {#what-should-i-pick} + +- **புதிய சரிபார்ப்பாளர்கள்:** `0x02` ஐத் தேர்ந்தெடுக்கவும். இது சிறந்த கூட்டு வட்டி மற்றும் நெகிழ்வுத்தன்மையுடன் கூடிய நவீனத் தரமாகும். +- **தற்போதுள்ள 0x01 சரிபார்ப்பாளர்கள்:** நீங்கள் 32 ETH க்கு மேல் வெகுமதிகள் கூட்டு வட்டி பெற விரும்பினால் அல்லது சரிபார்ப்பாளர்களை ஒருங்கிணைக்கத் திட்டமிட்டால் `0x02` க்கு மாற்றுவதைக் கவனியுங்கள். +- **தற்போதுள்ள 0x00 சரிபார்ப்பாளர்கள்:** உடனடியாக மேம்படுத்தவும்—உங்கள் நற்சான்றிதழ்களைப் புதுப்பிக்காமல் உங்களால் திரும்பப் பெற முடியாது. நீங்கள் முதலில் `0x01` க்கு மாற்ற வேண்டும், பின்னர் நீங்கள் `0x02` க்கு மாற்றலாம். + +## திரும்பப் பெறும் நற்சான்றிதழ்களை நிர்வகிப்பதற்கான கருவிகள் {#withdrawal-credential-tools} + +பல கருவிகள் நற்சான்றிதழ் வகைகளைத் தேர்ந்தெடுப்பதை அல்லது மாற்றுவதை ஆதரிக்கின்றன: + +- **[எத்தேரியம் ஸ்டேக்கிங் லான்ச்பேட்](https://launchpad.ethereum.org/en/validator-actions)** - வைப்புத்தொகை மற்றும் சரிபார்ப்பாளர் நிர்வாகத்திற்கான அதிகாரப்பூர்வ கருவி, நற்சான்றிதழ் மாற்றங்கள் மற்றும் ஒருங்கிணைப்புகள் உட்பட +- **[பெக்ட்ரா ஸ்டேக்கிங் மேனேஜர்](https://pectrastaking.com)** - மாற்றங்கள் மற்றும் ஒருங்கிணைப்புக்காக வாலெட்-கனெக்ட் ஆதரவுடன் கூடிய வலைப் பயனர் இடைமுகம் +- **[பெக்ட்ரா வேலிடேட்டர் ஆப்ஸ் CLI டூல்](https://github.com/Luganodes/Pectra-Batch-Contract)** - தொகுதி மாற்றங்களுக்கான கட்டளை வரி கருவி +- **[Ethereal](https://github.com/wealdtech/ethereal)** - சரிபார்ப்பாளர் மேலாண்மை உள்ளிட்ட எத்தேரியம் செயல்பாடுகளுக்கான CLI கருவி + +ஒருங்கிணைப்புக் கருவிகளின் முழுமையான பட்டியல் மற்றும் விரிவான மாற்று வழிமுறைகளுக்கு, [MaxEB ஒருங்கிணைப்புக் கருவிகள்](/roadmap/pectra/maxeb/#consolidation-tooling) பக்கத்தைப் பார்க்கவும். + +## மேலும் வாசிக்க {#further-reading} + +- [பங்குச் சான்று எத்தேரியத்தில் உள்ள சாவிகள்](/developers/docs/consensus-mechanisms/pos/keys/) - சரிபார்ப்பாளர் சாவிகள் மற்றும் அவை திரும்பப் பெறும் நற்சான்றிதழ்களுடன் எவ்வாறு தொடர்புடையவை என்பதைப் பற்றி அறியுங்கள் +- [MaxEB](/roadmap/pectra/maxeb/) - Pectra மேம்படுத்தல் மற்றும் அதிகபட்ச பயனுள்ள இருப்பு அம்சம் பற்றிய விரிவான வழிகாட்டி diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/index.md new file mode 100644 index 00000000000..b9e774c9668 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/index.md @@ -0,0 +1,114 @@ +--- +title: "வேலைக்கான சான்று (PoW)" +description: "வேலைக்கான சான்று ஒருமித்த நெறிமுறை மற்றும் எத்தேரியத்தில் அதன் பங்கு பற்றிய விளக்கம்." +lang: ta +--- + +எத்தேரியம் நெட்வொர்க் **[வேலைக்கான சான்று (PoW)](/developers/docs/consensus-mechanisms/pow)** உள்ளடக்கிய ஒருமித்த பொறிமுறையைப் பயன்படுத்தித் தொடங்கியது. இது எத்தேரியம் நெட்வொர்க்கின் முனைகளை எத்தேரியம் பிளாக்செயினில் பதிவுசெய்யப்பட்ட அனைத்து தகவல்களின் நிலையை ஒப்புக்கொள்ள அனுமதித்தது மற்றும் சில வகையான பொருளாதாரத் தாக்குதல்களைத் தடுத்தது. இருப்பினும், எத்தேரியம் 2022 இல் வேலைக்கான சான்றை நிறுத்திவிட்டு, அதற்குப் பதிலாக [பங்குக்கான சான்றை](/developers/docs/consensus-mechanisms/pos) பயன்படுத்தத் தொடங்கியது. + + + + + + வேலைக்கான சான்று இப்போது வழக்கற்றுப் போய்விட்டது. எத்தேரியம் இனி அதன் ஒருமித்த பொறிமுறையின் ஒரு பகுதியாக வேலைக்கான சான்றைப் பயன்படுத்துவதில்லை. அதற்குப் பதிலாக, இது பங்குக்கான சான்றைப் பயன்படுத்துகிறது. [பங்குக்கான சான்று](/developers/docs/consensus-mechanisms/pos/) மற்றும் [பங்களிப்பு](/staking/) பற்றி மேலும் படிக்கவும். + + + + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +இந்தப் பக்கத்தை சிறப்பாகப் புரிந்து கொள்ள, [பரிவர்த்தனைகள்](/developers/docs/transactions/), [பிளாக்கள்](/developers/docs/blocks/) மற்றும் [ஒற்றுமை (consensus) முறைமைகளை](/developers/docs/consensus-mechanisms/) முதலில் படிக்க பரிந்துரைக்கப்படுகிறது. + +## வேலைக்கான சான்று (PoW) என்றால் என்ன? {#what-is-pow} + +வேலைக்கான சான்றைப் பயன்படுத்தும் நகமோட்டோ ஒருமித்த கருத்து, பரவலாக்கப்பட்ட எத்தேரியம் நெட்வொர்க் கணக்கு நிலுவைகள் மற்றும் பரிவர்த்தனைகளின் வரிசை போன்ற விடயங்களில் ஒருமித்த கருத்தை (அதாவது, அனைத்து முனைகளும் ஒப்புக்கொள்கின்றன) அடைய ஒரு காலத்தில் அனுமதித்த பொறிமுறையாகும். இது பயனர்கள் தங்கள் நாணயங்களை "இரட்டைச் செலவு" செய்வதைத் தடுத்தது மற்றும் எத்தேரியம் சங்கிலியைத் தாக்குவது அல்லது கையாள்வது மிகவும் கடினம் என்பதை உறுதி செய்தது. இந்த பாதுகாப்புப் பண்புகள் இப்போது [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) எனப்படும் ஒருமித்த பொறிமுறையைப் பயன்படுத்தி பங்குக்கான சான்றிலிருந்து வருகின்றன. + +## வேலைக்கான சான்று மற்றும் சுரங்கம் {#pow-and-mining} + +வேலைக்கான சான்று என்பது வேலைக்கான சான்று பிளாக்செயின்களில் சுரங்கத் தொழிலாளர்கள் செய்யும் வேலைக்கான கடினம் மற்றும் விதிகளை அமைக்கும் அடிப்படைக் அல்காரிதம் ஆகும். சுரங்கம் என்பதே "வேலை" ஆகும். இது சங்கிலியில் செல்லுபடியாகும் தொகுதிகளைச் சேர்க்கும் செயலாகும். பிளாக்செயினின் சரியான ஃபோர்க்கைப் நெட்வொர்க் பின்பற்றுவதற்கு சங்கிலியின் நீளம் உதவுவதால் இது முக்கியமானது. அதிக "வேலை" செய்யப்படும்போது, சங்கிலி நீளமாகவும், தொகுதி எண் அதிகமாகவும் இருக்கும்போது, நெட்வொர்க்கானது தற்போதைய நிலையைப் பற்றி மேலும் உறுதியாக இருக்க முடியும். + +[சுரங்கம் பற்றி மேலும் அறிய](/developers/docs/consensus-mechanisms/pow/mining/) + +## எத்தேரியத்தின் வேலைக்கான சான்று எவ்வாறு வேலை செய்தது? {#how-it-works} + +எத்தேரியம் பரிவர்த்தனைகள் தொகுதிகளாகச் செயல்படுத்தப்படுகின்றன. தற்போது வழக்கற்றுப் போன வேலைக்கான சான்று எத்தேரியத்தில், ஒவ்வொரு தொகுதியிலும் அடங்கியிருந்தது: + +- தொகுதி கடினம் – எடுத்துக்காட்டாக: 3,324,092,183,262,715 +- mixHash – எடுத்துக்காட்டாக: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- நான்ஸ் – எடுத்துக்காட்டாக: `0xd3ee432b4fb3d26b` + +இந்த தொகுதி தரவு நேரடியாக வேலைக்கான சான்றுடன் தொடர்புடையது. + +### வேலைக்கான சான்றில் உள்ள வேலை {#the-work} + +வேலைக்கான சான்று நெறிமுறையான Ethash, ஒரு தொகுதிக்கான நான்ஸைக் கண்டறிய சுரங்கத் தொழிலாளர்கள் முயற்சி மற்றும் பிழையின் தீவிரமான பந்தயத்தில் செல்ல வேண்டியிருந்தது. செல்லுபடியாகும் நான்ஸ் உள்ள தொகுதிகள் மட்டுமே சங்கிலியில் சேர்க்கப்பட முடியும். + +ஒரு தொகுதியை உருவாக்குவதற்கான பந்தயத்தில், ஒரு சுரங்கத் தொழிலாளர் முழு சங்கிலியையும் (ஒரு சுரங்கத் தொழிலாளர் செய்வது போல) பதிவிறக்கம் செய்து இயக்குவதன் மூலம் மட்டுமே பெறக்கூடிய ஒரு தரவுத்தொகுப்பை ஒரு கணிதச் செயல்பாட்டின் மூலம் மீண்டும் மீண்டும் வைத்தார். தொகுதி கடினத்தால் நிர்ணயிக்கப்பட்ட இலக்கிற்குக் கீழே ஒரு mixHash-ஐ உருவாக்க தரவுத்தொகுப்பு பயன்படுத்தப்பட்டது. இதைச் செய்வதற்கான சிறந்த வழி முயற்சி மற்றும் பிழை. + +கடினம் ஹாஷிற்கான இலக்கை தீர்மானித்தது. இலக்கு குறைவாக இருந்தால், செல்லுபடியாகும் ஹாஷ்களின் தொகுப்பு சிறியதாக இருக்கும். உருவாக்கப்பட்டவுடன், மற்ற சுரங்கத் தொழிலாளர்களும் வாடிக்கையாளர்களும் சரிபார்ப்பது நம்பமுடியாத அளவிற்கு எளிதானது. ஒரு பரிவர்த்தனை மாறினாலும் கூட, ஹாஷ் முற்றிலும் வேறுபட்டதாக இருக்கும், இது மோசடியைக் குறிக்கும். + +ஹாஷிங் மோசடியை எளிதில் கண்டறிய உதவுகிறது. ஆனால் ஒரு செயல்முறையாக வேலைக்கான சான்று சங்கிலியைத் தாக்குவதைத் தடுக்கும் ஒரு பெரிய தடுப்பாகவும் இருந்தது. + +### வேலைக்கான சான்று மற்றும் பாதுகாப்பு {#security} + +முக்கிய எத்தேரியம் சங்கிலியில் இந்த வேலையைச் செய்ய சுரங்கத் தொழிலாளர்கள் ஊக்குவிக்கப்பட்டனர். சுரங்கத் தொழிலாளர்களின் ஒரு துணைக்குழு தங்கள் சொந்த சங்கிலியைத் தொடங்க சிறிதளவு ஊக்கமே இருந்தது—இது கணினியை பலவீனப்படுத்துகிறது. பிளாக்செயின்கள் உண்மையின் ஆதாரமாக ஒரே ஒரு நிலையை நம்பியுள்ளன. + +வேலைக்கான சான்றின் நோக்கம் சங்கிலியை நீட்டிப்பதாகும். நீளமான சங்கிலி மிகவும் நம்பத்தகுந்ததாக இருந்தது, ஏனெனில் அதை உருவாக்க அதிக கணினி வேலை செய்யப்பட்டது. எத்தேரியத்தின் PoW அமைப்பிற்குள், பரிவர்த்தனைகளை அழிக்கும், போலியானவற்றை உருவாக்கும் அல்லது இரண்டாவது சங்கிலியைப் பராமரிக்கும் புதிய தொகுதிகளை உருவாக்குவது கிட்டத்தட்ட சாத்தியமற்றது. ஏனெனில் ஒரு தீங்கிழைக்கும் சுரங்கத் தொழிலாளர் மற்ற அனைவரையும் விட எப்போதும் தொகுதி நான்ஸை வேகமாக தீர்க்க வேண்டியிருக்கும். + +தீங்கிழைக்கும் ஆனால் செல்லுபடியாகும் தொகுதிகளை தொடர்ந்து உருவாக்க, ஒரு தீங்கிழைக்கும் சுரங்கத் தொழிலாளருக்கு மற்ற அனைவரையும் தோற்கடிக்க நெட்வொர்க் சுரங்க சக்தியில் 51% க்கும் அதிகமாக தேவைப்பட்டிருக்கும். அந்த அளவு "வேலைக்கு" அதிக விலையுயர்ந்த கணினி சக்தி தேவைப்படுகிறது, மேலும் செலவழிக்கப்பட்ட ஆற்றல் ஒரு தாக்குதலில் பெறப்பட்ட ஆதாயங்களை விட அதிகமாக இருந்திருக்கலாம். + +### வேலைக்கான சான்று பொருளாதாரம் {#economics} + +வேலைக்கான சான்று புதிய நாணயத்தை கணினியில் வெளியிடுவதற்கும், சுரங்கத் தொழிலாளர்களை வேலை செய்ய ஊக்குவிப்பதற்கும் பொறுப்பாக இருந்தது. + +[கான்ஸ்டான்டினோப்பிள் மேம்படுத்தலுக்குப்](/ethereum-forks/#constantinople) பிறகு, ஒரு தொகுதியை வெற்றிகரமாக உருவாக்கும் சுரங்கத் தொழிலாளர்களுக்கு புதிதாக அச்சிடப்பட்ட இரண்டு ETH மற்றும் பரிவர்த்தனைக் கட்டணங்களில் ஒரு பகுதி வெகுமதியாக வழங்கப்பட்டது. Ommer தொகுதிகள் 1.75 ETH ஐயும் ஈடுசெய்தன. Ommer தொகுதிகள் என்பது ஒரு சுரங்கத் தொழிலாளரால் நடைமுறையில் மற்றொரு சுரங்கத் தொழிலாளர் நியமனத் தொகுதியை உருவாக்கிய அதே நேரத்தில் உருவாக்கப்பட்ட செல்லுபடியாகும் தொகுதிகள் ஆகும், இது இறுதியில் எந்த சங்கிலி முதலில் கட்டப்பட்டது என்பதைப் பொறுத்து தீர்மானிக்கப்பட்டது. Ommer தொகுதிகள் பொதுவாக நெட்வொர்க் தாமதத்தால் நிகழ்ந்தன. + +## இறுதிநிலை {#finality} + +ஒரு பரிவர்த்தனை மாற்ற முடியாத ஒரு தொகுதியின் ஒரு பகுதியாக இருக்கும்போது எத்தேரியத்தில் "இறுதிநிலையை" கொண்டுள்ளது. + +சுரங்கத் தொழிலாளர்கள் பரவலாக்கப்பட்ட முறையில் வேலை செய்ததால், ஒரே நேரத்தில் இரண்டு செல்லுபடியாகும் தொகுதிகளைச் சுரங்கப்படுத்த முடியும். இது ஒரு தற்காலிக ஃபோர்க்கை உருவாக்குகிறது. இறுதியில், இந்தச் சங்கிலிகளில் ஒன்று, அடுத்தடுத்த தொகுதிகள் சுரங்கப்படுத்தப்பட்டு அதில் சேர்க்கப்பட்ட பிறகு ஏற்றுக்கொள்ளப்பட்ட சங்கிலியாக மாறியது, இது அதை நீளமாக்கியது. + +விடயங்களை மேலும் சிக்கலாக்க, தற்காலிக ஃபோர்க்கில் நிராகரிக்கப்பட்ட பரிவர்த்தனைகள் ஏற்றுக்கொள்ளப்பட்ட சங்கிலியில் சேர்க்கப்படாமல் இருந்திருக்கலாம். அதாவது அது மாற்றியமைக்கப்படலாம். எனவே இறுதிநிலை என்பது ஒரு பரிவர்த்தனையை மாற்ற முடியாததாகக் கருதுவதற்கு முன்பு நீங்கள் காத்திருக்க வேண்டிய நேரத்தைக் குறிக்கிறது. முந்தைய வேலைக்கான சான்று எத்தேரியத்தின் கீழ், ஒரு குறிப்பிட்ட தொகுதி `N`-இன் மேல் அதிக தொகுதிகள் சுரங்கப்படுத்தப்பட்டால், `N`-இல் உள்ள பரிவர்த்தனைகள் வெற்றிகரமாக இருந்தன மற்றும் மாற்றியமைக்கப்படாது என்ற நம்பிக்கை அதிகமாக இருக்கும். இப்போது, பங்குக்கான சான்றுடன், இறுதிப்படுத்தல் என்பது ஒரு தொகுதியின் நிகழ்தகவு பண்பை விட வெளிப்படையான பண்பாகும். + +## வேலைக்கான சான்று ஆற்றல்-பயன்பாடு {#energy} + +வேலைக்கான சான்றின் ஒரு முக்கிய விமர்சனம் நெட்வொர்க்கைப் பாதுகாப்பாக வைத்திருக்கத் தேவையான ஆற்றல் வெளியீட்டின் அளவு ஆகும். பாதுகாப்பு மற்றும் பரவலாக்கத்தைப் பராமரிக்க, வேலைக்கான சான்றில் உள்ள எத்தேரியம் அதிக அளவு ஆற்றலைப் பயன்படுத்தியது. பங்குக்கான சான்றுக்கு மாறுவதற்குச் சற்று முன்பு, எத்தேரியம் சுரங்கத் தொழிலாளர்கள் கூட்டாக சுமார் 70 TWh/yr (செக் குடியரசின் அளவிற்கு சமமானது - 18-ஜூலை-2022 அன்று [digiconomist](https://digiconomist.net/) படி) நுகர்ந்தனர். + +## நன்மைகள் மற்றும் பாதகங்கள் {#pros-and-cons} + +| நிறைகள் | குறைகள் | +| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| வேலைக்கான சான்று நடுநிலையானது. தொடங்குவதற்கு உங்களுக்கு ETH தேவையில்லை மற்றும் தொகுதி வெகுமதிகள் 0ETH இலிருந்து நேர்மறை இருப்புக்குச் செல்ல உங்களை அனுமதிக்கின்றன. [பங்குக்கான சான்றுடன்](/developers/docs/consensus-mechanisms/pos/) தொடங்குவதற்கு உங்களுக்கு ETH தேவை. | வேலைக்கான சான்று அதிக ஆற்றலைப் பயன்படுத்துவதால் அது சுற்றுச்சூழலுக்கு தீங்கு விளைவிக்கும். | +| வேலைக்கான சான்று என்பது பல ஆண்டுகளாக பிட்காயின் மற்றும் எத்தேரியத்தைப் பாதுகாப்பாகவும் பரவலாக்கப்பட்டதாகவும் வைத்திருக்கும் ஒரு முயற்சி மற்றும் சோதிக்கப்பட்ட ஒருமித்த பொறிமுறையாகும். | நீங்கள் சுரங்கம் செய்ய விரும்பினால், உங்களுக்கு அத்தகைய சிறப்பு உபகரணங்கள் தேவை, தொடங்குவதற்கு இது ஒரு பெரிய முதலீடாகும். | +| பங்குக்கான சான்றுடன் ஒப்பிடும்போது இதைச் செயல்படுத்துவது ஒப்பீட்டளவில் எளிதானது. | அதிகரித்து வரும் கணக்கீடு தேவைப்படுவதால், சுரங்கக் குளங்கள் சுரங்க விளையாட்டில் ஆதிக்கம் செலுத்தக்கூடும், இது மையப்படுத்தல் மற்றும் பாதுகாப்பு அபாயங்களுக்கு வழிவகுக்கும். | + +## பங்குக்கான சான்றுடன் ஒப்பிடுதல் {#compared-to-pos} + +உயர் மட்டத்தில், பங்குக்கான சான்று வேலைக்கான சான்றின் அதே இறுதி இலக்கைக் கொண்டுள்ளது: பரவலாக்கப்பட்ட நெட்வொர்க் பாதுகாப்பாக ஒருமித்த கருத்தை அடைய உதவுவது. ஆனால் இது செயல்முறை மற்றும் பணியாளர்களில் சில வேறுபாடுகளைக் கொண்டுள்ளது: + +- பங்குக்கான சான்று, கணினி சக்தியின் முக்கியத்துவத்தை பங்களிக்கப்பட்ட ETH-க்காக மாற்றுகிறது. +- பங்குக்கான சான்று சுரங்கத் தொழிலாளர்களை சரிபார்ப்பாளர்களுடன் மாற்றுகிறது. சரிபார்ப்பவர்கள் புதிய தொகுதிகளை உருவாக்கும் திறனைச் செயல்படுத்த தங்கள் ETH ஐப் பங்களிக்கிறார்கள். +- சரிபார்ப்பவர்கள் தொகுதிகளை உருவாக்கப் போட்டியிடுவதில்லை, அதற்குப் பதிலாக அவர்கள் ஒரு அல்காரிதம் மூலம் தோராயமாகத் தேர்ந்தெடுக்கப்படுகிறார்கள். +- இறுதிநிலை தெளிவாக உள்ளது: சில சோதனைச் சாவடிகளில், 2/3 சரிபார்ப்பவர்கள் தொகுதியின் நிலையை ஒப்புக்கொண்டால் அது இறுதியானதாகக் கருதப்படுகிறது. சரிபார்ப்பவர்கள் தங்கள் முழுப் பங்கையும் இதில் பந்தயம் கட்ட வேண்டும், எனவே அவர்கள் பின்னர் கூட்டுசேர முயன்றால், அவர்கள் தங்கள் முழுப் பங்கையும் இழப்பார்கள். + +[பங்குக்கான சான்று பற்றி மேலும் அறிய](/developers/docs/consensus-mechanisms/pos/) + +## பார்த்து கற்பவரா? {#visual-learner} + + + +## மேலும் வாசிக்க {#further-reading} + +- [பெரும்பான்மைத் தாக்குதல்](https://en.bitcoin.it/wiki/Majority_attack) +- [தீர்வு இறுதிநிலை பற்றி](https://blog.ethereum.org/2016/05/09/on-settlement-finality/) + +### காணொளிகள் {#videos} + +- [வேலைக்கான சான்று நெறிமுறைகளின் தொழில்நுட்ப விளக்கம்](https://youtu.be/9V1bipPkCTU) + +## தொடர்புடைய தலைப்புகள் {#related-topics} + +- [சுரங்கம் தோண்டுதல்](/developers/docs/consensus-mechanisms/pow/mining/) +- [Proof-of-stake](/developers/docs/consensus-mechanisms/pos/) +- [அதிகாரத்திற்கான சான்று](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/index.md new file mode 100644 index 00000000000..064a4b3adfa --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -0,0 +1,86 @@ +--- +title: "சுரங்கம்" +description: "Ethereum இல் சுரங்கம் எவ்வாறு செயல்பட்டது என்பதற்கான ஒரு விளக்கம்." +lang: ta +--- + + + + + +Proof-of-work இனி Ethereum இன் ஒருமித்த பொறிமுறைக்கு அடிப்படையாக இல்லை, அதாவது சுரங்கம் அணைக்கப்பட்டுள்ளது. அதற்கு பதிலாக, ETH-ஐ ஸ்டேக் செய்யும் சரிபார்ப்பாளர்களால் Ethereum பாதுகாக்கப்படுகிறது. இன்றே உங்கள் ETH-ஐ ஸ்டேக்கிங் செய்யத் தொடங்கலாம். இணைப்பு, proof-of-stake, மற்றும் ஸ்டேக்கிங் பற்றி மேலும் படிக்கவும். இந்தப் பக்கம் வரலாற்று ஆர்வத்திற்காக மட்டுமே. + + + + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +இந்தப் பக்கத்தை சிறப்பாகப் புரிந்து கொள்ள, [பரிவர்த்தனைகள்](/developers/docs/transactions/), [பிளாக்குகள்](/developers/docs/blocks/) மற்றும் [proof-of-work](/developers/docs/consensus-mechanisms/pow/) பற்றி முதலில் படிக்க பரிந்துரைக்கிறோம். + +## Ethereum சுரங்கம் என்றால் என்ன? {#what-is-ethereum-mining} + +சுரங்கம் என்பது Ethereum-இன் இப்போது வழக்கற்றுப்போன proof-of-work கட்டமைப்பில், Ethereum பிளாக்செயினில் சேர்க்கப்பட வேண்டிய பரிவர்த்தனைகளின் ஒரு பிளாக்கை உருவாக்கும் செயல்முறையாகும். + +சுரங்கம் என்ற சொல் கிரிப்டோகரன்சிகளுக்கான தங்க ஒப்புமையின் பின்னணியில் இருந்து உருவானது. தங்கம் அல்லது விலைமதிப்பற்ற உலோகங்கள் பற்றாக்குறையானவை, டிஜிட்டல் டோக்கன்களும் அவ்வாறே, மேலும் ஒரு proof-of-work அமைப்பில் மொத்த அளவை அதிகரிப்பதற்கான ஒரே வழி சுரங்கம் மூலமாகும். Proof-of-work Ethereum இல், வெளியீட்டின் ஒரே முறை சுரங்கம் மூலமாக இருந்தது. இருப்பினும், தங்கம் அல்லது விலைமதிப்பற்ற உலோகங்களைப் போலல்லாமல், Ethereum சுரங்கம் பிளாக்செயினில் பிளாக்குகளை உருவாக்குதல், சரிபார்த்தல், வெளியிடுதல் மற்றும் பரப்புதல் மூலம் நெட்வொர்க்கைப் பாதுகாப்பதற்கான வழியாகவும் இருந்தது. + +ஈதரைச் சுரங்கம் செய்வது = நெட்வொர்க்கைப் பாதுகாத்தல் + +எந்தவொரு proof-of-work பிளாக்செயினின் உயிர்நாடி சுரங்கம் ஆகும். Ethereum சுரங்கர்கள் - மென்பொருளை இயக்கும் கணினிகள் - proof-of-stake க்கு மாறும் முன் பரிவர்த்தனைகளைச் செயல்படுத்தவும், பிளாக்குகளை உருவாக்கவும் தங்கள் நேரத்தையும் கணினி ஆற்றலையும் பயன்படுத்தினர். + +## சுரங்கர்கள் ஏன் இருக்கிறார்கள்? {#why-do-miners-exist} + +Ethereum போன்ற பரவலாக்கப்பட்ட அமைப்புகளில், பரிவர்த்தனைகளின் வரிசையில் அனைவரும் உடன்படுவதை நாம் உறுதி செய்ய வேண்டும். கணினி ரீதியாக கடினமான புதிர்களைத் தீர்ப்பதன் மூலம் பிளாக்குகளை உருவாக்க சுரங்கர்கள் உதவினர், தாக்குதல்களிலிருந்து நெட்வொர்க்கைப் பாதுகாத்தனர். + +[proof-of-work பற்றி மேலும்](/developers/docs/consensus-mechanisms/pow/) + +முன்னர் எவரும் தங்கள் கணினியைப் பயன்படுத்தி Ethereum நெட்வொர்க்கில் சுரங்கம் செய்ய முடிந்தது. இருப்பினும், எல்லோராலும் ஈதரை (ETH) இலாபகரமாகச் சுரங்கம் செய்ய முடியவில்லை. பெரும்பாலான சந்தர்ப்பங்களில், சுரங்கர்கள் பிரத்யேக கணினி வன்பொருளை வாங்க வேண்டியிருந்தது மற்றும் மலிவான எரிசக்தி ஆதாரங்களுக்கான அணுகலைக் கொண்டிருக்க வேண்டியிருந்தது. சராசரி கணினி, சுரங்கம் தொடர்பான செலவுகளை ஈடுகட்ட போதுமான பிளாக் வெகுமதிகளைப் பெறுவது சாத்தியமில்லை. + +### சுரங்கத்தின் செலவு {#cost-of-mining} + +- ஒரு சுரங்க இயந்திரத்தை உருவாக்குவதற்கும் பராமரிப்பதற்கும் தேவையான வன்பொருளின் சாத்தியமான செலவுகள் +- சுரங்க இயந்திரத்தை இயக்குவதற்கான மின்சார செலவு +- நீங்கள் ஒரு பூலில் சுரங்கம் செய்தால், இந்த பூல்கள் பொதுவாக பூலால் உருவாக்கப்பட்ட ஒவ்வொரு பிளாக்கிற்கும் ஒரு தட்டையான % கட்டணத்தை வசூலித்தன. +- சுரங்க இயந்திரத்தை ஆதரிப்பதற்கான உபகரணங்களின் சாத்தியமான செலவு (காற்றோட்டம், ஆற்றல் கண்காணிப்பு, மின்சார வயரிங் போன்றவை) + +சுரங்க லாபத்தை மேலும் ஆராய, [Etherscan](https://etherscan.io/ether-mining-calculator) வழங்கும் ஒன்றைப் போன்ற சுரங்க கால்குலேட்டரைப் பயன்படுத்தவும். + +## Ethereum பரிவர்த்தனைகள் எவ்வாறு சுரங்கம் செய்யப்பட்டன {#how-ethereum-transactions-were-mined} + +பின்வருபவை Ethereum proof-of-work இல் பரிவர்த்தனைகள் எவ்வாறு சுரங்கம் செய்யப்பட்டன என்பதற்கான ஒரு கண்ணோட்டத்தை வழங்குகிறது. Ethereum proof-of-stake க்கான இந்த செயல்முறையின் ஒரு ஒப்பீட்டு விளக்கத்தை [இங்கே](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) காணலாம். + +1. ஒரு பயனர் சில [கணக்கின்](/developers/docs/accounts/) தனிப்பட்ட விசையுடன் ஒரு [பரிவர்த்தனை](/developers/docs/transactions/) கோரிக்கையை எழுதி கையொப்பமிடுகிறார். +2. பயனர் சில [முனையிலிருந்து](/developers/docs/nodes-and-clients/) முழு Ethereum நெட்வொர்க்கிற்கும் பரிவர்த்தனை கோரிக்கையை ஒளிபரப்புகிறார். +3. புதிய பரிவர்த்தனை கோரிக்கையைப் பற்றி கேட்டவுடன், Ethereum நெட்வொர்க்கில் உள்ள ஒவ்வொரு முனையும் கோரிக்கையை தங்கள் உள்ளூர் மெம்பூலில் சேர்க்கிறது, இது ஒரு பிளாக்கில் பிளாக்செயினுக்கு இன்னும் உறுதிப்படுத்தப்படாத அனைத்து பரிவர்த்தனை கோரிக்கைகளின் பட்டியலாகும். +4. ஒரு கட்டத்தில், ஒரு சுரங்க முனையானது பல டஜன் அல்லது நூற்றுக்கணக்கான பரிவர்த்தனை கோரிக்கைகளை ஒரு சாத்தியமான [பிளாக்காக](/developers/docs/blocks/) ஒருங்கிணைக்கிறது, இது பிளாக் கேஸ் வரம்பிற்குள் இருக்கும்போதே அவர்கள் சம்பாதிக்கும் [பரிவர்த்தனை கட்டணங்களை](/developers/docs/gas/) அதிகப்படுத்தும் வகையில் இருக்கும். சுரங்க முனை பின்னர்: + 1. ஒவ்வொரு பரிவர்த்தனை கோரிக்கையின் செல்லுபடியை சரிபார்க்கிறது (அதாவது, யாரும் கையொப்பமிடாத ஒரு கணக்கிலிருந்து ஈதரை மாற்ற முயற்சிக்கவில்லை, கோரிக்கை தவறாக வடிவமைக்கப்படவில்லை, முதலியன), பின்னர் கோரிக்கையின் குறியீட்டை இயக்குகிறது, EVM-இன் அவர்களின் உள்ளூர் நகலின் நிலையை மாற்றுகிறது. சுரங்கர் அத்தகைய ஒவ்வொரு பரிவர்த்தனை கோரிக்கைக்கும் பரிவர்த்தனை கட்டணத்தை தங்கள் சொந்த கணக்கிற்கு வழங்குகிறார். + 2. பிளாக்கில் உள்ள அனைத்து பரிவர்த்தனை கோரிக்கைகளும் சரிபார்க்கப்பட்டு உள்ளூர் EVM நகலில் செயல்படுத்தப்பட்டவுடன், சாத்தியமான பிளாக்கிற்கான proof-of-work "சட்டபூர்வமான சான்றிதழை" உருவாக்கும் செயல்முறையைத் தொடங்குகிறது. +5. இறுதியில், ஒரு சுரங்கர் எங்கள் குறிப்பிட்ட பரிவர்த்தனை கோரிக்கையை உள்ளடக்கிய ஒரு பிளாக்கிற்கான சான்றிதழை உருவாக்கி முடிப்பார். சுரங்கர் பின்னர் பூர்த்தி செய்யப்பட்ட பிளாக்கை ஒளிபரப்புகிறார், அதில் சான்றிதழ் மற்றும் கோரப்பட்ட புதிய EVM நிலையின் செக்சம் ஆகியவை அடங்கும். +6. மற்ற முனைகள் புதிய பிளாக்கைப் பற்றி கேட்கின்றன. அவர்கள் சான்றிதழைச் சரிபார்க்கிறார்கள், பிளாக்கில் உள்ள அனைத்து பரிவர்த்தனைகளையும் அவர்களே இயக்குகிறார்கள் (எங்கள் பயனரால் முதலில் ஒளிபரப்பப்பட்ட பரிவர்த்தனை உட்பட), மேலும் அனைத்து பரிவர்த்தனைகளின் செயலாக்கத்திற்குப் பிறகு அவர்களின் புதிய EVM நிலையின் செக்சம், சுரங்கரின் பிளாக் கோரிய நிலையின் செக்சம் உடன் பொருந்துகிறதா என்பதைச் சரிபார்க்கிறார்கள். அப்போது மட்டுமே இந்த முனைகள் இந்த பிளாக்கை தங்கள் பிளாக்செயினின் வாலில் சேர்க்கின்றன, மேலும் புதிய EVM நிலையை நியமன நிலையாக ஏற்றுக்கொள்கின்றன. +7. ஒவ்வொரு முனையும் புதிய பிளாக்கில் உள்ள அனைத்து பரிவர்த்தனைகளையும் நிறைவேற்றப்படாத பரிவர்த்தனை கோரிக்கைகளின் உள்ளூர் மெம்பூலிலிருந்து நீக்குகிறது. +8. நெட்வொர்க்கில் சேரும் புதிய முனைகள் அனைத்து பிளாக்குகளையும் வரிசையாகப் பதிவிறக்குகின்றன, இதில் நமது ஆர்வமுள்ள பரிவர்த்தனையைக் கொண்ட பிளாக்கும் அடங்கும். அவர்கள் ஒரு உள்ளூர் EVM நகலைத் துவக்குகிறார்கள் (இது ஒரு வெற்று-நிலை EVM ஆகத் தொடங்குகிறது), பின்னர் ஒவ்வொரு பிளாக்கிலும் உள்ள ஒவ்வொரு பரிவர்த்தனையையும் தங்கள் உள்ளூர் EVM நகலின் மேல் செயல்படுத்தும் செயல்முறையின் மூலம் செல்கிறார்கள், வழியில் ஒவ்வொரு பிளாக்கிலும் நிலை செக்சம்களை சரிபார்க்கிறார்கள். + +ஒவ்வொரு பரிவர்த்தனையும் ஒரு முறை சுரங்கம் செய்யப்படுகிறது (ஒரு புதிய பிளாக்கில் சேர்க்கப்பட்டு முதல் முறையாகப் பரப்பப்படுகிறது), ஆனால் நியமன EVM நிலையை முன்னெடுக்கும் செயல்பாட்டில் உள்ள ஒவ்வொரு பங்கேற்பாளராலும் செயல்படுத்தப்பட்டு சரிபார்க்கப்படுகிறது. இது பிளாக்செயினின் மைய மந்திரங்களில் ஒன்றை எடுத்துக்காட்டுகிறது: **நம்ப வேண்டாம், சரிபார்க்கவும்**. + +## ஓம்மர் (uncle) பிளாக்குகள் {#ommer-blocks} + +proof-of-work இல் பிளாக் சுரங்கம் என்பது நிகழ்தகவு அடிப்படையிலானது, அதாவது சில சமயங்களில் நெட்வொர்க் தாமதம் காரணமாக இரண்டு செல்லுபடியாகும் பிளாக்குகள் ஒரே நேரத்தில் வெளியிடப்பட்டன. இந்த வழக்கில், நெறிமுறையானது முன்மொழியப்பட்ட சேர்க்கப்படாத செல்லுபடியாகும் பிளாக்கிற்கு பகுதியளவு வெகுமதி அளிப்பதன் மூலம் சுரங்கர்களிடம் நேர்மையை உறுதி செய்யும் அதே வேளையில், மிக நீளமான (எனவே மிகவும் "செல்லுபடியான") சங்கிலியைத் தீர்மானிக்க வேண்டியிருந்தது. இது நெட்வொர்க்கின் மேலும் பரவலாக்கத்தை ஊக்குவித்தது, ஏனெனில் அதிக தாமதத்தை எதிர்கொள்ளக்கூடிய சிறிய சுரங்கர்கள், [ஓம்மர்](/glossary/#ommer) பிளாக் வெகுமதிகள் மூலம் வருமானத்தை உருவாக்க முடியும். + +"ஓம்மர்" என்ற சொல் ஒரு பெற்றோர் பிளாக்கின் உடன்பிறப்புக்கான விருப்பமான பாலின-நடுநிலைச் சொல்லாகும், ஆனால் இது சில நேரங்களில் "uncle" என்றும் குறிப்பிடப்படுகிறது. **Ethereum proof-of-stake க்கு நகர்ந்ததிலிருந்து, ஓம்மர் பிளாக்குகள் இனி சுரங்கம் செய்யப்படுவதில்லை**, ஏனெனில் ஒவ்வொரு ஸ்லாட்டிலும் ஒரே ஒரு முன்மொழிபவர் மட்டுமே தேர்ந்தெடுக்கப்படுகிறார். சுரங்கம் செய்யப்பட்ட ஓம்மர் பிளாக்குகளின் [வரலாற்று விளக்கப்படத்தைப்](https://ycharts.com/indicators/ethereum_uncle_rate) பார்ப்பதன் மூலம் இந்த மாற்றத்தைக் காணலாம். + +## ஒரு காட்சி விளக்கவுரை {#a-visual-demo} + +சுரங்கம் மற்றும் proof-of-work பிளாக்செயின் மூலம் ஆஸ்டின் உங்களுக்கு வழிகாட்டுவதைப் பாருங்கள். + + + +## சுரங்க வழிமுறை {#mining-algorithm} + +Ethereum மெயின்நெட் ஒரே ஒரு சுரங்க வழிமுறையை மட்டுமே பயன்படுத்தியது - ['Ethash'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/). Ethash என்பது ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) எனப்படும் அசல் R&D வழிமுறையின் வாரிசு ஆகும். + +[சுரங்க வழிமுறைகள் பற்றி மேலும்](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/). + +## தொடர்புடைய தலைப்புகள் {#related-topics} + +- [கேஸ்](/developers/docs/gas/) +- [EVM](/developers/docs/evm/) +- [வேலைக்கான சான்று](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md new file mode 100644 index 00000000000..014a1fb553d --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -0,0 +1,331 @@ +--- +title: Dagger-Hashimoto +description: "Dagger-Hashimoto அல்காரிதத்தின் விரிவான பார்வை." +lang: ta +--- + +Dagger-Hashimoto என்பது எத்தீரியத்தின் மைனிங் அல்காரிதமிற்கான முதன்மை ஆராய்ச்சி செயலாக்கம் மற்றும் விவரக்குறிப்பு ஆகும். Dagger-Hashimoto [Ethash](#ethash) மூலம் மாற்றப்பட்டது. 15 செப்டம்பர் 2022 அன்று [The Merge](/roadmap/merge/) நிகழ்வில் மைனிங் முழுமையாக நிறுத்தப்பட்டது. அதன் பிறகு, எத்தீரியம் ஒரு [ப்ரூஃப்-ஆஃப்-ஸ்டேக்](/developers/docs/consensus-mechanisms/pos) முறைமையைப் பயன்படுத்தி பாதுகாக்கப்படுகிறது. இந்த பக்கம் வரலாற்றுப் பார்வைக்காகவே உள்ளது - இங்கு உள்ள தகவல்கள் Merge பிற எத்தீரியத்திற்கு தொடர்பானவை அல்ல. + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +இந்தப் பக்கத்தை சிறப்பாகப் புரிந்து கொள்ள, முதலில் [ப்ரூஃப்-ஆஃப்-வொர்க் கன்சென்சஸ்](/developers/docs/consensus-mechanisms/pow), [மைனிங்](/developers/docs/consensus-mechanisms/pow/mining) மற்றும் [மைனிங் அல்காரிதம்களைப்](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms) பற்றிப் படிக்குமாறு பரிந்துரைக்கிறோம். + +## Dagger-Hashimoto {#dagger-hashimoto} + +Dagger-Hashimoto இரண்டு குறிக்கோள்களை நிறைவேற்றுவதற்கான முயற்சியாகும்: + +1. **ASIC-எதிர்ப்பு**: அல்காரிதமுக்கான சிறப்பு வன்பொருளை உருவாக்குவதன் மூலம் கிடைக்கும் நன்மை முடிந்தவரை சிறியதாக இருக்க வேண்டும் +2. **லைட் கிளையன்ட் சரிபார்ப்புத்தன்மை**: ஒரு பிளாக்கை லைட் கிளையன்ட் மூலம் திறமையாகச் சரிபார்க்கக்கூடியதாக இருக்க வேண்டும். + +மேலும் ஒரு திருத்தத்துடன், நாம் விரும்பினால் மூன்றாவது குறிக்கோளை நிறைவேற்றுவதற்கான முறையையும் குறிப்பிடுகிறோம், ஆனால் கூடுதல் சிக்கலின் விலைக்கு: + +**முழுச் சங்கிலி சேமிப்பு**: மைனிங்கிற்கு முழுமையான பிளாக்செயின் நிலையைச் சேமிக்க வேண்டும் (Ethereum நிலை ட்ரை-யின் ஒழுங்கற்ற அமைப்பு காரணமாக, சில கத்தரிப்புகள் சாத்தியமாகும் என்று நாங்கள் எதிர்பார்க்கிறோம், குறிப்பாக சில அடிக்கடி பயன்படுத்தப்படும் ஒப்பந்தங்களில், ஆனால் இதை நாங்கள் குறைக்க விரும்புகிறோம்). + +## DAG உருவாக்கம் {#dag-generation} + +அல்காரிதமுக்கான குறியீடு பைதானில் கீழே வரையறுக்கப்படும். முதலில், குறிப்பிட்ட துல்லியத்தின் குறியிடப்படாத முழு எண்களை சரங்களாக மார்ஷல் செய்வதற்கு `encode_int`-ஐ வழங்குகிறோம். இதன் எதிர்மறை குறியீடும் வழங்கப்பட்டுள்ளது: + +```python +NUM_BITS = 512 + +def encode_int(x): + "ஒரு முழு எண் x-ஐ பிக்-எண்டியன் முறையைப் பயன்படுத்தி 64 எழுத்துகள் கொண்ட ஒரு சரமாக குறியாக்கம் செய்யவும்" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "பிக்-எண்டியன் முறையைப் பயன்படுத்தி ஒரு சரத்திலிருந்து ஒரு முழு எண் x-ஐ குறியாக்கம் நீக்கவும்" + x = 0 + for c in s: + x *= 256 + x += ord(c) + return x +``` + +அடுத்து, `sha3` என்பது ஒரு முழு எண்ணை எடுத்து மற்றொரு முழு எண்ணை வெளியிடும் ஒரு செயல்பாடு என்றும், `dbl_sha3` என்பது ஒரு இரட்டை-sha3 செயல்பாடு என்றும் நாங்கள் கருதுகிறோம்; இந்த மேற்கோள் குறியீட்டை ஒரு செயல்படுத்தலாக மாற்றினால், இதைப் பயன்படுத்தவும்: + +```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))) +``` + +### அளவுருக்கள் {#parameters} + +அல்காரிதத்திற்கு பயன்படுத்தப்படும் அளவீடுகள்: + +```python +SAFE_PRIME_512 = 2**512 - 38117 # 2**512-ஐ விடக் குறைவான மிகப்பெரிய பாதுகாப்பான பகா எண் + +params = { + "n": 4000055296 * 8 // NUM_BITS, # தரவுத்தொகுப்பின் அளவு (4 ஜிகாபைட்கள்); 65536-இன் பெருக்கலாக இருக்க வேண்டும் + "n_inc": 65536, # ஒரு காலப்பகுதிக்கு n மதிப்பின் அதிகரிப்பு; 65536-இன் பெருக்கலாக இருக்க வேண்டும் + # epochtime=20000 உடன் வருடத்திற்கு 882 MB வளர்ச்சியை அளிக்கிறது + "cache_size": 2500, # லைட் கிளையன்ட்டின் கேச் அளவு (லைட் கிளையன்ட்டால் தேர்ந்தெடுக்கப்படலாம்; + # அல்காரிதம் விவரக்குறிப்பின் பகுதியாக இல்லை) + "diff": 2**14, # சிரமம் (பிளாக் மதிப்பீட்டின் போது சரிசெய்யப்பட்டது) + "epochtime": 100000, # பிளாக்குகளில் ஒரு எபோக்கின் நீளம் (தரவுத்தொகுப்பு எவ்வளவு அடிக்கடி புதுப்பிக்கப்படுகிறது) + "k": 1, # ஒரு முனையின் பெற்றோர்களின் எண்ணிக்கை + "w": w, # மாடுலர் அடுக்குக்குறி ஹேஷிங்கிற்காகப் பயன்படுத்தப்படுகிறது + "accesses": 200, # ஹஷிமோட்டோவின் போது தரவுத்தொகுப்பு அணுகல்களின் எண்ணிக்கை + "P": SAFE_PRIME_512 # ஹேஷிங் மற்றும் சீரற்ற எண் உருவாக்கத்திற்கான பாதுகாப்பான பகா எண் +} +``` + +இந்த நேர்வில் `P` என்பது `log₂(P)` 512-ஐ விட சற்று குறைவாக இருக்கும்படி தேர்ந்தெடுக்கப்பட்ட ஒரு பகா எண் ஆகும், இது நமது எண்களைக் குறிக்க நாம் பயன்படுத்தும் 512 பிட்களுக்கு ஒத்திருக்கிறது. DAG இன் பின்னணி பாதி மட்டுமே சேமிக்கப்பட வேண்டும், எனவே de-facto RAM தேவைகள் 1 GB இல் தொடங்கி, ஆண்டுக்கு 441 MB ஆக வளர்கின்றன. + +### டாகர் வரைபட உருவாக்கம் {#dagger-graph-building} + +Dagger கிராப் கட்டமைப்பு அடிப்படை கீழே வரையறுக்கப்பட்டுள்ளது: + +```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 +``` + +சாராம்சத்தில், இது ஒரு வரைபடத்தை `sha3(seed)` என்ற ஒற்றை முனையாகத் தொடங்குகிறது, மேலும் அங்கிருந்து சீரற்ற முந்தைய முனைகளின் அடிப்படையில் மற்ற முனைகளை வரிசையாகச் சேர்க்கத் தொடங்குகிறது. ஒரு புதிய முனை உருவாக்கப்படும் போது, `i` ஐ விட குறைவான சில குறியீடுகளை சீரற்ற முறையில் தேர்ந்தெடுக்க (மேலே `x % i` ஐப் பயன்படுத்தி) விதையின் ஒரு மாடுலர் பவர் கணக்கிடப்படுகிறது, மேலும் அந்தக் குறியீடுகளில் உள்ள முனைகளின் மதிப்புகள் `x`-க்கான புதிய மதிப்பை உருவாக்க ஒரு கணக்கீட்டில் பயன்படுத்தப்படுகின்றன, இது பின்னர் ஒரு சிறிய ப்ரூஃப் ஆஃப் வொர்க் செயல்பாட்டிற்கு (XOR அடிப்படையில்) அளிக்கப்பட்டு, இறுதியில் குறியீடு `i`-இல் வரைபடத்தின் மதிப்பை உருவாக்குகிறது. இந்த குறிப்பிட்ட வடிவமைப்பின் பின்னணி, DAG இன் தொடர்ச்சியான அணுகுமுறையை கட்டாயமாக்குவதாகும்; அடுத்த DAG மதிப்பு, தற்போதைய மதிப்பு தெரியும் வரை தீர்மானிக்க முடியாது. இறுதியில், மாடுலர் எExponentiation முடிவை மேலும் ஹாஷ் செய்கிறது. + +இந்த அல்காரிதம் எண்கணிதத்திலிருந்து பல முடிவுகளைப் பொறுத்ததாக உள்ளது. விவாதத்திற்கான இணைப்பு கீழே உள்ளது. + +## லைட் கிளையன்ட் மதிப்பீடு {#light-client-evaluation} + +மேலே உள்ள கிராப் கட்டமைப்பு, கிராப் உள்ள ஒவ்வொரு நொடியையும் மீட்டமைக்க, சில நொடிகளை மட்டுமே கணக்கீடு செய்வதன் மூலம் மற்றும் சிறிய அளவிலான உதவியாளர் நினைவகத்தை மட்டுமே தேவைப்படும் வகையில் உருவாக்கப்பட்டுள்ளது. K=1 என்றால், துணை மரம் DAG இல் முதல் உறுப்பிற்கு செல்லும் மதிப்புகளின் சங்கிலியாகவே இருக்கும். + +DAG க்கான லைட் கிளையன்ட் கணக்கீட்டு செயல்முறை இதற்கானது: + +```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) +``` + +அதாவது, இது மேலே உள்ள அல்காரிதத்தை மீண்டும் எழுதுவதற்காக, முழு DAG க்கான மதிப்புகளை கணக்கீடு செய்வதற்கான சுற்றத்தை அகற்றுகிறது மற்றும் முந்தைய நொடியின் தேடலை மீண்டும் அழைப்புடன் அல்லது கச்சே தேடலுடன் மாற்றுகிறது. `k=1` க்கு கேச் தேவையற்றது என்பதைக் கவனியுங்கள், இருப்பினும் ஒரு மேலதிக மேம்படுத்தல் உண்மையில் DAG-இன் முதல் சில ஆயிரம் மதிப்புகளை முன்கூட்டியே கணக்கிட்டு, அதை கணக்கீடுகளுக்கான ஒரு நிலையான கேச்-ஆக வைத்திருக்கிறது; இதற்கான ஒரு குறியீட்டு செயலாக்கத்திற்கு பின் இணைப்பைப் பார்க்கவும். + +## DAG-களின் இரட்டை இடையகம் {#double-buffer} + +ஒரு முழு கிளையன்டில், மேலே உள்ள சூத்திரத்தால் உருவாக்கப்பட்ட 2 DAG-களின் ஒரு [_இரட்டை இடையகம்_](https://wikipedia.org/wiki/Multiple_buffering) பயன்படுத்தப்படுகிறது. மேலே உள்ள அளவுருக்களின்படி ஒவ்வொரு `epochtime` எண்ணிக்கை பிளாக்குகளுக்கும் DAG-கள் உருவாக்கப்படுகின்றன என்பதே இதன் யோசனை. கிளையன்ட் சமீபத்திய DAG ஐப் பயன்படுத்துவதற்குப் பதிலாக, முந்தையதைப் பயன்படுத்துகிறது. இதன் நன்மை, மைனர்கள் திடீரென அனைத்து தரவுகளையும் மீண்டும் கணக்கீடு செய்ய வேண்டிய படி, காலப்போக்கில் DAG களை மாற்ற அனுமதிக்கிறது. இல்லையெனில், அடிக்கடி சங்கிலி செயலாக்கத்தில் திடீர் தாமதம் ஏற்படுவதற்கான வாய்ப்பு உள்ளது, மேலும் மையமாக்கலை அதிகரிக்கும். எனவே, அனைத்து தரவுகளும் மீண்டும் கணக்கீடு செய்யும் முன் அந்த சில நிமிடங்களில் 51% தாக்குதல்களின் ஆபத்து உள்ளது. + +ஒரு பிளாக்குக்கான வேலை கணக்கீடு செய்ய பயன்படுத்தப்படும் DAG களின் தொகுப்பை உருவாக்குவதற்கான அல்காரிதம் கீழே உள்ளது: + +```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: + # பின்புல இடையகம் சாத்தியமில்லை, முன்பக்க இடையகத்தை மட்டும் உருவாக்கவும் + 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} + +முதன்மை ஹாஷிமோட்டோவின் யோசனை, பிளாக்செயினை ஒரு தரவுத்தொகுப்பாகப் பயன்படுத்துவது, பிளாக்செயினில் இருந்து N குறியீடுகளைத் தேர்ந்தெடுக்க, அந்த குறியீடுகளில் உள்ள பரிமாற்றங்களைப் சேகரித்து, இந்த தரவின் XOR ஐச் செய்யும் கணக்கீட்டைச் செய்வது, மற்றும் முடிவின் ஹாஷை திரும்ப அளிப்பதாகும். Thaddeus Dryja இன் முதன்மை அல்காரிதம், ஒத்திகைக்காக பைதானில் மொழிபெயர்க்கப்பட்டுள்ளது: + +```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) +``` + +அவசியமாக, ஹாஷிமோட்டோ RAM கடினமாகக் கருதப்படும், ஆனால் இது 256-பிட் கணக்கீட்டில் அதிகமான கணக்கீட்டு சுமையை நம்புகிறது. இருப்பினும், Dagger-Hashimoto தனது தரவுத்தொகுப்பை அடையாளம் காண 64 பிட்ஸ்தான் பயன்படுத்துகிறது. + +```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) +``` + +இரட்டை SHA3 பயன்படுத்துவது, ஒரு வகை பூஜ்ஜிய தரவுகளை, உடனடி முன்-சரிபார்ப்பு, சரியான இடைக்கால மதிப்பு வழங்கப்பட்டது என்பதை மட்டும் சரிபார்க்கிறது. இந்த வெளிப்புற ப்ரூஃப்-ஆஃப்-வொர்க் மிகக் குறைவான ASIC-க்கு உகந்தது மற்றும் மிகவும் பலவீனமானது, ஆனால் DDoS ஐ இன்னும் கடினமாக்குவதற்காகவே உள்ளது, ஏனெனில் ஒரு பிளாக்கை உடனடியாக நிராகரிக்கப்படாத வகையில் உருவாக்க, அந்த சிறிய அளவிலான வேலை செய்ய வேண்டும். இங்கு லைட்-கிளையன்ட் பதிப்பு உள்ளது: + +```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) +``` + +## மைனிங் மற்றும் சரிபார்த்தல் {#mining-and-verifying} + +இப்போது, இதனை மைனிங் அல்காரிதமாக ஒன்றிணைப்போம்: + +```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 +``` + +இங்கு சரிபார்ப்பு அல்காரிதம்: + +```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 +``` + +லைட்-கிளையன்ட் நட்பு சரிபார்ப்பு: + +```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 +``` + +மேலும், Dagger-Hashimoto பிளாக் தலைப்பில் கூடுதல் தேவைகளை விதிக்கிறது: + +- இரண்டு அடுக்கு சரிபார்ப்பு செயல்பட, ஒரு பிளாக் தலைப்பில் nonce மற்றும் மத்திய மதிப்பு முன்-sha3 இருக்க வேண்டும் +- எங்கு வேண்டுமானாலும், ஒரு பிளாக் தலைப்பு தற்போதைய seedset இன் sha3 ஐ சேமிக்க வேண்டும் + +## மேலும் வாசிக்க {#further-reading} + +_உங்களுக்கு உதவிய ஒரு சமூக வளம் பற்றி தெரியுமா?_ இந்தப் பக்கத்தைத் திருத்தி அதைச் சேர்க்கவும்!_ + +## பின் இணைப்பு {#appendix} + +மேலே குறிப்பிடப்பட்டுள்ளது போல, DAG உருவாக்கத்திற்கு பயன்படுத்தப்படும் RNG எண்கணிதத்தின் சில முடிவுகளை நம்புகிறது. முதலில், `picker` மாறிக்கு அடிப்படையாக இருக்கும் Lehmer RNG ஒரு பரந்த கால அளவைக் கொண்டுள்ளது என்ற உறுதியை நாங்கள் வழங்குகிறோம். இரண்டாவதாக, `x ∈ [2,P-2]` எனத் தொடங்கினால் `pow(x,3,P)` ஆனது `x`-ஐ `1` அல்லது `P-1` க்கு மேப் செய்யாது என்பதை நாங்கள் காட்டுகிறோம். இறுதியாக, `pow(x,3,P)` ஒரு ஹேஷிங் செயல்பாடாகக் கருதப்படும்போது குறைந்த மோதல் விகிதத்தைக் கொண்டுள்ளது என்பதை நாங்கள் காட்டுகிறோம். + +### Lehmer சீரற்ற எண் ஜெனரேட்டர் {#lehmer-random-number} + +`produce_dag` செயல்பாடு சார்பற்ற சீரற்ற எண்களை உருவாக்க வேண்டிய அவசியமில்லை என்றாலும், `seed**i % P` ஒரு சில மதிப்புகளை மட்டுமே எடுப்பது ஒரு சாத்தியமான அச்சுறுத்தலாகும். இது மைனர்களுக்குப் பயன்பாட்டைப் புரிந்துகொள்ளும் வாய்ப்பு அளிக்கலாம். + +இதிலிருந்து தவிர்க்க, எண்கணிதத்தின் ஒரு முடிவுக்கு கோரப்படுகிறது. ஒரு [_பாதுகாப்பான பகா எண்_](https://en.wikipedia.org/wiki/Safe_prime) என்பது `P` என்ற ஒரு பகா எண் என வரையறுக்கப்படுகிறது, அதில் `(P-1)/2` என்பதும் ஒரு பகா எண்ணாக இருக்கும். [பெருக்கல் குலம்](https://en.wikipedia.org/wiki/Multiplicative_group_of_integers_modulo_n) `ℤ/nℤ`-இன் உறுப்பினர் `x`-இன் _வரிசை_ என்பது 
xᵐ mod P ≡ 1
+என இருக்கும்படியான குறைந்தபட்ச `m` என வரையறுக்கப்படுகிறது +இந்த வரையறைகளைக் கொண்டு, நாம் பெறுவது: + +> கவனிப்பு 1. பாதுகாப்பான பகா எண் `P`-க்கான பெருக்கல் குலம் `ℤ/Pℤ`-இன் உறுப்பினராக `x`-ஐக் கொள்வோம். `x mod P ≠ 1 mod P` மற்றும் `x mod P ≠ P-1 mod P` எனில், `x`-இன் வரிசை `P-1` அல்லது `(P-1)/2` ஆக இருக்கும். + +_நிரூபணம்_. `P` ஒரு பாதுகாப்பான பகா எண் என்பதால், [லக்ராஞ்சியின் தேற்றத்தின்][lagrange] படி `x`-இன் வரிசை `1`, `2`, `(P-1)/2`, அல்லது `P-1` ஆக இருக்கும். + +`x`-இன் வரிசை `1` ஆக இருக்க முடியாது, ஏனெனில் ஃபெர்மாவின் சிறிய தேற்றத்தின்படி நாம் பெறுவது: + +
xP-1 mod P ≡ 1
+ +எனவே `x` ஆனது `ℤ/nℤ`-இன் பெருக்கல் சமனியாக இருக்க வேண்டும், அது தனித்துவமானது. எடுகோளின்படி `x ≠ 1` என நாம் கருதியதால், இது சாத்தியமில்லை. + +`x`-இன் வரிசை `2` ஆக இருக்க முடியாது, `x = P-1` ஆக இருந்தாலன்றி, ஏனெனில் இது `P` ஒரு பகா எண் என்பதை மீறும். + +மேற்கண்ட கூற்றிலிருந்து, `(picker * init) % P`-ஐ திரும்பத் திரும்பச் செய்வது குறைந்தது `(P-1)/2` என்ற சுழற்சி நீளத்தைக் கொண்டிருக்கும் என்பதை நாம் அறியலாம். ஏனெனில், இரண்டின் உயர் அடுக்குக்கு ஏறக்குறைய சமமான ஒரு பாதுகாப்பான பகா எண்ணாக `P`-ஐ நாங்கள் தேர்ந்தெடுத்துள்ளோம், மற்றும் `init` என்பது `[2,2**256+1]` என்ற இடைவெளியில் உள்ளது. `P`-இன் பருமனைப் பார்க்கும்போது, மாடுலர் அடுக்குக்குறியிலிருந்து ஒரு சுழற்சியை நாம் ஒருபோதும் எதிர்பார்க்கக்கூடாது. + +DAG-இல் உள்ள முதல் செல்லுக்கு ( `init` என பெயரிடப்பட்ட மாறி) மதிப்பை ஒதுக்கும்போது, `pow(sha3(seed) + 2, 3, P)`-ஐ கணக்கிடுகிறோம். முதல் பார்வையில், இதன் விளைவு `1` ஆகவோ அல்லது `P-1` ஆகவோ இருக்காது என்பதற்கு இது உத்தரவாதம் அளிக்காது. இருப்பினும், `P-1` ஒரு பாதுகாப்பான பகா எண் என்பதால், எங்களிடம் பின்வரும் கூடுதல் உறுதி உள்ளது, இது கவனிப்பு 1-இன் ஒரு கிளைத்தேற்றம் ஆகும்: + +> கவனிப்பு 2. பாதுகாப்பான பகா எண் `P`-க்கான பெருக்கல் குலம் `ℤ/Pℤ`-இன் உறுப்பினராக `x`-ஐயும், `w` ஒரு இயல் எண்ணாகவும் கொள்வோம். If `x mod P ≠ 1 mod P` and `x mod P ≠ P-1 mod P`, as well as `w mod P ≠ P-1 mod P` and `w mod P ≠ 0 mod P`, then `xʷ mod P ≠ 1 mod P` and `xʷ mod P ≠ P-1 mod P` + +### ஒரு ஹேஷ் செயல்பாடாக மாடுலர் அடுக்குக்குறி {#modular-exponentiation} + +`P` மற்றும் `w`-இன் சில மதிப்புகளுக்கு, `pow(x, w, P)` என்ற செயல்பாட்டில் பல மோதல்கள் இருக்கலாம். உதாரணமாக, `pow(x,9,19)` ஆனது `{1,18}` என்ற மதிப்புகளை மட்டுமே எடுக்கும். + +`P` ஒரு பகா எண் என்பதால், ஒரு மாடுலர் அடுக்குக்குறி ஹேஷிங் செயல்பாட்டிற்கு பொருத்தமான `w`-ஐ பின்வரும் முடிவைப் பயன்படுத்தித் தேர்ந்தெடுக்கலாம்: + +> கவனிப்பு 3. `P` ஒரு பகா எண்ணாக இருக்கட்டும்; `ℤ/Pℤ`-இல் உள்ள அனைத்து `a` மற்றும் `b`-க்கும் பின்வருமாறு இருந்தால், இருந்தால் மட்டுமே `w` மற்றும் `P-1` சார்பகா எண்களாகும்:
`aʷ mod P ≡ bʷ mod P` என இருந்தால், இருந்தால் மட்டுமே `a mod P ≡ b mod P` ஆகும்
+ +ஆக, `P` ஒரு பகா எண் மற்றும் `w` ஆனது `P-1`-க்கு சார்பகா எண்ணாக இருப்பதால், `|{pow(x, w, P) : x ∈ ℤ}| = P` என நாம் பெறுகிறோம், இது ஹேஷிங் செயல்பாடு சாத்தியமான குறைந்தபட்ச மோதல் விகிதத்தைக் கொண்டிருப்பதைக் குறிக்கிறது. + +நாம் தேர்ந்தெடுத்தபடி `P` ஒரு பாதுகாப்பான பகா எண்ணாக இருக்கும் சிறப்பு நேர்வில், `P-1` ஆனது 1, 2, `(P-1)/2` மற்றும் `P-1` ஆகியவற்றை மட்டுமே காரணிகளாகக் கொண்டுள்ளது. `P` > 7 என்பதால், 3 ஆனது `P-1`-க்கு சார்பகா எண் என்பதை நாம் அறிவோம், எனவே `w=3` மேற்கண்ட கூற்றை நிறைவு செய்கிறது. + +## மேலும் திறமையான கேச்-அடிப்படையிலான மதிப்பீட்டு அல்காரிதம் {#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/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md new file mode 100644 index 00000000000..62d83a18561 --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -0,0 +1,1023 @@ +--- +title: Ethash +description: "Ethash நெறிமுறையைப் பற்றிய ஒரு விரிவான பார்வை." +lang: ta +--- + + + + + + Ethash என்பது Ethereum-இன் வேலைக்கான சான்று சுரங்க நெறிமுறை ஆகும். வேலைக்கான சான்று இப்போது **முழுவதுமாக அணைக்கப்பட்டுள்ளது** மேலும் Ethereum இப்போது அதற்குப் பதிலாக [பங்குக்கான சான்று](/developers/docs/consensus-mechanisms/pos/) ஐப் பயன்படுத்திப் பாதுகாக்கப்படுகிறது. [தி மெர்ஜ்](/roadmap/merge/), [பங்குக்கான சான்று](/developers/docs/consensus-mechanisms/pos/) மற்றும் [ஸ்டேக்கிங்](/staking/) பற்றி மேலும் படிக்கவும். இந்தப் பக்கம் வரலாற்று ஆர்வத்திற்காக மட்டுமே! + + + + +Ethash என்பது [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) நெறிமுறையின் மாற்றியமைக்கப்பட்ட பதிப்பாகும். Ethash வேலைக்கான சான்று [நினைவக கடினமானது](https://wikipedia.org/wiki/Memory-hard_function), இது நெறிமுறையை ASIC எதிர்க்கும் என்று கருதப்பட்டது. Ethash ASIC-கள் இறுதியில் உருவாக்கப்பட்டன, ஆனால் வேலைக்கான சான்று அணைக்கப்படும் வரை GPU சுரங்கம் ஒரு சாத்தியமான தேர்வாக இருந்தது. Ethash இன்னும் மற்ற Ethereum அல்லாத வேலைக்கான சான்று நெட்வொர்க்குகளில் மற்ற காயின்களை சுரங்கப்படுத்தப் பயன்படுத்தப்படுகிறது. + +## Ethash எப்படி வேலை செய்கிறது? {#how-does-ethash-work} + +நான்ஸ் மற்றும் பிளாக் ஹெடரைச் சார்ந்த ஒரு நிலையான வளத்தின் துணைக்குழுக்களைத் தேர்வுசெய்யும் வேலைக்கான சான்று நெறிமுறையுடன் நினைவகக் கடினத்தன்மை அடையப்படுகிறது. இந்த வளம் (சில ஜிகாபைட் அளவு) ஒரு DAG என்று அழைக்கப்படுகிறது. DAG ஒவ்வொரு 30000 பிளாக்குகளுக்கும் மாற்றப்படுகிறது, இது ஒரு யுகம் (epoch) (~125-மணிநேர சாளரம், தோராயமாக 5.2 நாட்கள்) என்று அழைக்கப்படுகிறது மற்றும் உருவாக்க சிறிது நேரம் எடுக்கும். DAG ஆனது பிளாக் உயரத்தை மட்டுமே சார்ந்து இருப்பதால், அதை முன்பே உருவாக்க முடியும், ஆனால் அது இல்லையெனில், ஒரு பிளாக்கை உருவாக்க இந்த செயல்முறையின் இறுதி வரை கிளையன்ட் காத்திருக்க வேண்டும். கிளையன்ட்கள் DAG-களை முன்கூட்டியே உருவாக்கித் தற்காலிகச் சேமிக்கவில்லை என்றால், ஒவ்வொரு யுக மாற்றத்திலும் நெட்வொர்க்கில் பெரும் பிளாக் தாமதம் ஏற்படலாம். வேலைக்கான சான்றை சரிபார்க்க DAG உருவாக்கப்பட வேண்டியதில்லை என்பதை நினைவில் கொள்ளவும், இது குறைந்த CPU மற்றும் சிறிய நினைவகம் இரண்டையும் கொண்டு சரிபார்ப்பை அனுமதிக்கிறது. + +நெறிமுறை எடுக்கும் பொதுவான பாதை பின்வருமாறு: + +1. ஒவ்வொரு பிளாக்கிற்கும் கணக்கிடக்கூடிய ஒரு **விதை** உள்ளது, அது அந்த புள்ளி வரை பிளாக் ஹெடர்களை ஸ்கேன் செய்வதன் மூலம் கணக்கிடப்படுகிறது. +2. விதை மூலம், **16 MB போலி சீரற்ற தற்காலிகச் சேமிப்பை** கணக்கிடலாம். லைட் கிளையன்ட்கள் தற்காலிகச் சேமிப்பை சேமிக்கின்றன. +3. தற்காலிகச் சேமிப்பிலிருந்து, நாம் **1 GB தரவுத்தொகுப்பை** உருவாக்கலாம், தரவுத்தொகுப்பில் உள்ள ஒவ்வொரு உருப்படியும் தற்காலிகச் சேமிப்பிலிருந்து ஒரு சிறிய எண்ணிக்கையிலான உருப்படிகளை மட்டுமே சார்ந்துள்ளது என்ற பண்புடன். முழு கிளையன்ட்கள் மற்றும் சுரங்கத் தொழிலாளர்கள் தரவுத்தொகுப்பை சேமிக்கின்றனர். தரவுத்தொகுப்பு காலப்போக்கில் நேரியல் ரீதியாக வளர்கிறது. +4. சுரங்கமானது தரவுத்தொகுப்பின் சீரற்ற துண்டுகளை எடுத்து அவற்றை ஒன்றாக ஹாஷிங் செய்வதை உள்ளடக்கியது. சரிபார்ப்பை குறைந்த நினைவகம் மூலம் செய்ய முடியும், உங்களுக்குத் தேவையான தரவுத்தொகுப்பின் குறிப்பிட்ட பகுதிகளை மீண்டும் உருவாக்க தற்காலிகச் சேமிப்பைப் பயன்படுத்தி, எனவே நீங்கள் தற்காலிகச் சேமிப்பை மட்டுமே சேமிக்க வேண்டும். + +பெரிய தரவுத்தொகுப்பு ஒவ்வொரு 30000 பிளாக்குகளுக்கும் ஒருமுறை புதுப்பிக்கப்படுகிறது, எனவே ஒரு சுரங்கத் தொழிலாளியின் பெரும்பான்மையான முயற்சி தரவுத்தொகுப்பைப் படிப்பதாக இருக்கும், அதில் மாற்றங்களைச் செய்வதில்லை. + +## வரையறைகள் {#definitions} + +நாங்கள் பின்வரும் வரையறைகளைப் பயன்படுத்துகிறோம்: + +``` +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 +``` + +### 'SHA3' இன் பயன்பாடு {#sha3} + +எத்தேரியத்தின் வளர்ச்சி SHA3 தரநிலையின் வளர்ச்சியுடன் ஒத்துப்போனது, மற்றும் +தரநிலைகள் செயல்முறை இறுதிப்படுத்தப்பட்ட ஹாஷ் நெறிமுறையின் பேடிங்கில் தாமதமான மாற்றத்தை ஏற்படுத்தியது, இதனால் எத்தேரியத்தின் +"sha3_256" மற்றும் "sha3_512" ஹாஷ்கள் நிலையான sha3 ஹாஷ்கள் அல்ல, ஆனால் மற்ற சூழல்களில் பெரும்பாலும் +"Keccak-256" மற்றும் "Keccak-512" என்று குறிப்பிடப்படும் ஒரு மாறுபாடாகும். உதாரணமாக, [இங்கே](https://eips.ethereum.org/EIPS/eip-1803), [இங்கே](http://ethereum.stackexchange.com/questions/550/which-cryptographic-hash-function-does-ethereum-use), அல்லது [இங்கே](http://bitcoin.stackexchange.com/questions/42055/what-is-the-approach-to-calculate-an-ethereum-address-from-a-256-bit-private-key/42057#42057) விவாதத்தைப் பார்க்கவும். + +கீழே உள்ள நெறிமுறையின் விளக்கத்தில் "sha3" ஹாஷ்கள் குறிப்பிடப்பட்டுள்ளதால், அதை மனதில் கொள்ளவும். + +## அளவுருக்கள் {#parameters} + +Ethash இன் தற்காலிகச் சேமிப்பு மற்றும் தரவுத்தொகுப்பிற்கான அளவுருக்கள் பிளாக் எண்ணைச் சார்ந்துள்ளது. தற்காலிகச் சேமிப்பு அளவு மற்றும் தரவுத்தொகுப்பு அளவு இரண்டும் நேரியல் ரீதியாக வளர்கின்றன; இருப்பினும், சுழற்சி நடத்தைக்கு வழிவகுக்கும் தற்செயலான ஒழுங்குகளின் அபாயத்தைக் குறைக்க, நேரியல் ரீதியாக வளர்ந்து வரும் வரம்பிற்குக் கீழே உள்ள மிக உயர்ந்த பிரதானத்தை நாங்கள் எப்போதும் எடுத்துக்கொள்கிறோம். + +```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 +``` + +தரவுத்தொகுப்பு மற்றும் தற்காலிகச் சேமிப்பு அளவு மதிப்புகளின் அட்டவணைகள் பிற்சேர்க்கையில் வழங்கப்பட்டுள்ளன. + +## தற்காலிகச் சேமிப்பு உருவாக்கம் {#cache-generation} + +இப்போது, தற்காலிகச் சேமிப்பை உருவாக்குவதற்கான செயல்பாட்டை நாங்கள் குறிப்பிடுகிறோம்: + +```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 +``` + +தற்காலிகச் சேமிப்பு உற்பத்தி செயல்முறையானது முதலில் 32 MB நினைவகத்தை வரிசையாக நிரப்புவதை உள்ளடக்கியது, பின்னர் செர்ஜியோ டெமியன் லெர்னரின் [_Strict Memory Hard Hashing Functions_ (2014)](http://www.hashcash.org/papers/memohash.pdf) இலிருந்து _RandMemoHash_ நெறிமுறையின் இரண்டு பாஸ்களைச் செய்கிறது. வெளியீடு 524288 64-பைட் மதிப்புகளின் தொகுப்பாகும். + +## தரவு திரட்டல் செயல்பாடு {#date-aggregation-function} + +சில சந்தர்ப்பங்களில் XOR-க்கு ஒரு கூட்டு அல்லாத மாற்றாக [FNV ஹாஷ்](https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function) மூலம் ஈர்க்கப்பட்ட ஒரு நெறிமுறையைப் பயன்படுத்துகிறோம். FNV-1 ஸ்பெக்குக்கு மாறாக, முழு 32-பிட் உள்ளீட்டைக் கொண்டு பிரதானத்தைப் பெருக்குகிறோம் என்பதை நினைவில் கொள்ளவும், இது ஒரு பைட் (octet) உடன் பிரதானத்தைப் பெருக்குகிறது. + +```python +FNV_PRIME = 0x01000193 + +def fnv(v1, v2): + return ((v1 * FNV_PRIME) ^ v2) % 2**32 +``` + +மஞ்சள் தாள் கூட fnv-ஐ v1\*(FNV_PRIME ^ v2) என குறிப்பிடுகிறது, தற்போதைய அனைத்து செயலாக்கங்களும் தொடர்ந்து மேலே உள்ள வரையறையைப் பயன்படுத்துகின்றன என்பதை நினைவில் கொள்ளவும். + +## முழு தரவுத்தொகுப்பு கணக்கீடு {#full-dataset-calculation} + +முழு 1 GB தரவுத்தொகுப்பில் உள்ள ஒவ்வொரு 64-பைட் உருப்படியும் பின்வருமாறு கணக்கிடப்படுகிறது: + +```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) +``` + +அடிப்படையில், 256 போலி சீரற்ற முறையில் தேர்ந்தெடுக்கப்பட்ட தற்காலிகச் சேமிப்பு முனைகளிலிருந்து தரவை இணைத்து, தரவுத்தொகுப்பு முனையைக் கணக்கிட அதை ஹாஷ் செய்கிறோம். முழு தரவுத்தொகுப்பும் பின்வருமாறு உருவாக்கப்படுகிறது: + +```python +def calc_dataset(full_size, cache): + return [calc_dataset_item(cache, i) for i in range(full_size // HASH_BYTES)] +``` + +## முக்கிய வளையம் {#main-loop} + +இப்போது, பிரதான "hashimoto"-போன்ற வளையத்தை நாங்கள் குறிப்பிடுகிறோம், அங்கு ஒரு குறிப்பிட்ட ஹெடர் மற்றும் நான்ஸிற்கான எங்கள் இறுதி மதிப்பை உருவாக்க முழு தரவுத்தொகுப்பிலிருந்து தரவை நாங்கள் திரட்டுகிறோம். கீழேயுள்ள குறியீட்டில், `header` என்பது ஒரு _துண்டிக்கப்பட்ட_ பிளாக் ஹெடரின் RLP பிரதிநிதித்துவத்தின் SHA3-256 _ஹாஷைக்_ குறிக்கிறது, அதாவது, **mixHash** மற்றும் **nonce** புலங்களைத் தவிர்த்து ஒரு ஹெடர். `nonce` என்பது பிக்-எண்டியன் வரிசையில் 64 பிட் கையொப்பமிடப்படாத முழு எண்ணின் எட்டு பைட்டுகள் ஆகும். எனவே `nonce[::-1]` என்பது அந்த மதிப்பின் எட்டு-பைட் லிட்டில்-எண்டியன் பிரதிநிதித்துவமாகும்: + +```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]) +``` + +அடிப்படையில், நாங்கள் 128 பைட் அகலமுள்ள ஒரு "கலவையை" பராமரிக்கிறோம், மேலும் முழு தரவுத்தொகுப்பிலிருந்தும் 128 பைட்டுகளை வரிசையாக மீண்டும் மீண்டும் பெற்று, அதை கலவையுடன் இணைக்க `fnv` செயல்பாட்டைப் பயன்படுத்துகிறோம். 128 பைட்டுகளின் வரிசைமுறை அணுகல் பயன்படுத்தப்படுகிறது, அதனால் நெறிமுறையின் ஒவ்வொரு சுற்றிலும் எப்போதும் RAM-இலிருந்து ஒரு முழுப் பக்கத்தைப் பெறுகிறது, ASIC-கள் கோட்பாட்டளவில் தவிர்க்கக்கூடிய டிரான்ஸ்லேஷன் லூக்சைட் பஃபர் தவறுகளைக் குறைக்கிறது. + +இந்த நெறிமுறையின் வெளியீடு விரும்பிய இலக்குக்குக் கீழே இருந்தால், நான்ஸ் செல்லுபடியாகும். இறுதியில் `sha3_256` இன் கூடுதல் பயன்பாடு, குறைந்தபட்சம் ஒரு சிறிய அளவு வேலை செய்யப்பட்டது என்பதை நிரூபிக்க வழங்கக்கூடிய ஒரு இடைநிலை நான்ஸ் இருப்பதை உறுதி செய்கிறது என்பதை நினைவில் கொள்ளவும்; இந்த விரைவான வெளிப்புற PoW சரிபார்ப்பு DDoS எதிர்ப்பு நோக்கங்களுக்காக பயன்படுத்தப்படலாம். முடிவு ஒரு பாரபட்சமற்ற, 256-பிட் எண் என்ற புள்ளிவிவர உத்தரவாதத்தை வழங்கவும் இது உதவுகிறது. + +## சுரங்கம் {#mining} + +சுரங்க நெறிமுறை பின்வருமாறு வரையறுக்கப்பட்டுள்ளது: + +```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 +``` + +## விதை ஹாஷை வரையறுத்தல் {#seed-hash} + +ஒரு குறிப்பிட்ட பிளாக்கின் மேல் சுரங்கம் செய்யப் பயன்படுத்தப்படும் விதை ஹாஷைக் கணக்கிட, பின்வரும் நெறிமுறையைப் பயன்படுத்துகிறோம்: + +```python + def get_seedhash(block): + s = '\x00' * 32 + for i in range(block.number // EPOCH_LENGTH): + s = serialize_hash(sha3_256(s)) + return s +``` + +சுமுகமான சுரங்கம் மற்றும் சரிபார்ப்புக்கு, எதிர்கால விதை ஹாஷ்கள் மற்றும் தரவுத்தொகுப்புகளை ஒரு தனி திரட்டில் முன்கூட்டியே கணக்கிட பரிந்துரைக்கிறோம். + +## மேலும் வாசிக்க {#further-reading} + +_உங்களுக்கு உதவிய ஒரு சமூக வளம் பற்றி தெரியுமா?_ இந்தப் பக்கத்தைத் திருத்தி அதைச் சேர்க்கவும்!_ + +## பின் இணைப்பு {#appendix} + +மேலே உள்ள பைதான் ஸ்பெக்கை குறியீடாக இயக்க நீங்கள் ஆர்வமாக இருந்தால், பின்வரும் குறியீடு முன் சேர்க்கப்பட வேண்டும். + +```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 +``` + +### தரவு அளவுகள் {#data-sizes} + +பின்வரும் தேடல் அட்டவணைகள் தரவு அளவுகள் மற்றும் தற்காலிகச் சேமிப்பு அளவுகளின் தோராயமாக 2048 அட்டவணைப்படுத்தப்பட்ட யுகங்களை வழங்குகின்றன. + +```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/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md new file mode 100644 index 00000000000..d366d38472a --- /dev/null +++ b/public/content/translations/ta/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -0,0 +1,42 @@ +--- +title: "சுரங்க வழிமுறைகள்" +description: "எத்தேரியம் சுரங்கத்திற்குப் பயன்படுத்தப்படும் அல்காரிதம்களைப் பற்றிய விரிவான பார்வை." +lang: ta +--- + + + + + +Proof-of-work இனி Ethereum இன் ஒருமித்த பொறிமுறைக்கு அடிப்படையாக இல்லை, அதாவது சுரங்கம் அணைக்கப்பட்டுள்ளது. அதற்கு பதிலாக, ETH-ஐ ஸ்டேக் செய்யும் சரிபார்ப்பாளர்களால் Ethereum பாதுகாக்கப்படுகிறது. இன்றே உங்கள் ETH-ஐ ஸ்டேக்கிங் செய்யத் தொடங்கலாம். இணைப்பு, proof-of-stake, மற்றும் ஸ்டேக்கிங் பற்றி மேலும் படிக்கவும். இந்தப் பக்கம் வரலாற்று ஆர்வத்திற்காக மட்டுமே. + + + + +எத்தேரியம் சுரங்கம் ஈத்தாஷ் எனப்படும் ஒரு அல்காரிதத்தைப் பயன்படுத்தியது. இந்த அல்காரிதத்தின் அடிப்படைக் கருத்து என்னவென்றால், கணக்கிடப்பட்ட சிரமத்தால் தீர்மானிக்கப்பட்ட ஒரு வரம்பை விட விளைந்த ஹாஷ் சிறியதாக இருக்கும்படி, ஒரு சுரங்கத் தொழிலாளி brute-force கணக்கீட்டைப் பயன்படுத்தி ஒரு நான்ஸ் உள்ளீட்டைக் கண்டுபிடிக்க முயற்சிக்கிறார். இந்த சிரம அளவை மாறும் வகையில் சரிசெய்யலாம், இது பிளாக் உற்பத்தியை ஒரு வழக்கமான இடைவெளியில் நடக்க அனுமதிக்கிறது. + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +இந்தப் பக்கத்தை நன்கு புரிந்துகொள்ள, நீங்கள் முதலில் [வேலைக்கான ஆதாரம் ஒருமித்த கருத்து](/developers/docs/consensus-mechanisms/pow) மற்றும் [சுரங்கம்](/developers/docs/consensus-mechanisms/pow/mining) பற்றிப் படிக்குமாறு பரிந்துரைக்கிறோம். + +## Dagger Hashimoto {#dagger-hashimoto} + +Dagger Hashimoto என்பது எத்தேரியம் சுரங்கத்திற்கான ஒரு முன்னோடி ஆராய்ச்சி அல்காரிதம் ஆகும், அதனை ஈத்தாஷ் மாற்றியமைத்தது. இது இரண்டு வெவ்வேறு அல்காரிதம்களின் கலவையாகும்: Dagger மற்றும் Hashimoto. இது ஒரு ஆராய்ச்சிச் செயலாக்கமாக மட்டுமே இருந்தது மற்றும் எத்தேரியம் மெயின்நெட் தொடங்கப்பட்ட நேரத்தில் ஈத்தாஷ் மூலம் மாற்றியமைக்கப்பட்டது. + +[Dagger](http://www.hashcash.org/papers/dagger.html) என்பது ஒரு [திசைப்படுத்தப்பட்ட சுழற்சியற்ற வரைபடத்தை](https://en.wikipedia.org/wiki/Directed_acyclic_graph) உருவாக்குவதை உள்ளடக்கியது, அதன் சீரற்ற துண்டுகள் ஒன்றாக ஹாஷ் செய்யப்படுகின்றன. ஒவ்வொரு நான்ஸுக்கும் ஒரு பெரிய மொத்த தரவு மரத்தின் ஒரு சிறிய பகுதி மட்டுமே தேவைப்படுகிறது என்பதே அடிப்படைக் கொள்கையாகும். ஒவ்வொரு நான்ஸுக்கும் துணைமரத்தை மீண்டும் கணக்கிடுவது சுரங்கத்திற்குத் தடைசெய்யக்கூடியதாகும் - எனவே மரத்தைச் சேமிக்க வேண்டிய அவசியம் உள்ளது - ஆனால் ஒரு நான்ஸ் மதிப்பிலான சரிபார்ப்புக்கு இது போதுமானது. Scrypt போன்ற ஏற்கெனவே இருக்கும் அல்காரிதம்களுக்கு மாற்றாக Dagger வடிவமைக்கப்பட்டது, அவை நினைவக-கடினமானவை (memory-hard) ஆனால் அவற்றின் நினைவக-கடினத்தன்மை உண்மையிலேயே பாதுகாப்பான நிலைகளுக்கு அதிகரிக்கும் போது சரிபார்ப்பது கடினம். இருப்பினும், Dagger பகிரப்பட்ட நினைவக வன்பொருள் முடுக்கத்திற்கு ஆளாகக்கூடியதாக இருந்தது மற்றும் பிற ஆராய்ச்சி வழிகளுக்கு ஆதரவாக கைவிடப்பட்டது. + +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) என்பது I/O வரம்புக்குட்பட்டதாக (I/O bound) இருப்பதன் மூலம் ASIC-எதிர்ப்பைச் சேர்க்கும் ஒரு அல்காரிதம் ஆகும் (அதாவது, சுரங்கச் செயல்பாட்டில் நினைவக வாசிப்புகளே கட்டுப்படுத்தும் காரணியாக உள்ளன). கணக்கீட்டை விட RAM அதிகமாகக் கிடைக்கிறது என்பதே கோட்பாடு; பல பில்லியன் டாலர் மதிப்புள்ள ஆராய்ச்சி, பல்வேறு பயன்பாட்டு நிகழ்வுகளுக்காக RAM-ஐ மேம்படுத்துவதை ஏற்கெனவே ஆய்வு செய்துள்ளது, இது பெரும்பாலும் சீரற்ற அணுகல் முறைகளை உள்ளடக்கியது (எனவே "சீரற்ற அணுகல் நினைவகம்"). இதன் விளைவாக, அல்காரிதத்தை மதிப்பிடுவதற்கு ஏற்கெனவே உள்ள RAM ஓரளவு உகந்த நிலைக்கு அருகில் இருக்க வாய்ப்புள்ளது. Hashimoto பிளாக்செயினை தரவின் ஆதாரமாகப் பயன்படுத்துகிறது, ஒரே நேரத்தில் மேலே உள்ள (1) மற்றும் (3) ஐ திருப்திப்படுத்துகிறது. + +Dagger-Hashimoto, Dagger மற்றும் Hashimoto அல்காரிதம்களின் திருத்தப்பட்ட பதிப்புகளைப் பயன்படுத்தியது. Dagger Hashimoto மற்றும் Hashimoto-க்கு இடையிலான வேறுபாடு என்னவென்றால், பிளாக்செயினை தரவு மூலமாகப் பயன்படுத்துவதற்குப் பதிலாக, Dagger Hashimoto ஒரு தனிப்பயனாக்கப்பட்ட தரவுத் தொகுப்பைப் பயன்படுத்துகிறது, இது ஒவ்வொரு N பிளாக்குகளுக்கும் பிளாக் தரவின் அடிப்படையில் புதுப்பிக்கப்படுகிறது. Dagger அல்காரிதத்தைப் பயன்படுத்தி தரவுத்தொகுப்பு உருவாக்கப்படுகிறது, இது லைட் கிளையன்ட் சரிபார்ப்பு அல்காரிதத்திற்காக ஒவ்வொரு நான்ஸுக்கும் குறிப்பிட்ட ஒரு துணைத்தொகுப்பை திறமையாக கணக்கிட அனுமதிக்கிறது. Dagger Hashimoto மற்றும் Dagger-க்கு இடையேயான வேறுபாடு என்னவென்றால், அசல் Dagger-ஐப் போலல்லாமல், பிளாக்கை வினவப் பயன்படுத்தப்படும் தரவுத்தொகுப்பு அரை-நிரந்தரமானது, இது அவ்வப்போது (எ.கா., வாரத்திற்கு ஒரு முறை) மட்டுமே புதுப்பிக்கப்படுகிறது. இதன் பொருள், தரவுத்தொகுப்பை உருவாக்கும் முயற்சியின் ஒரு பகுதி பூஜ்ஜியத்திற்கு அருகில் உள்ளது, எனவே பகிரப்பட்ட நினைவக வேக அதிகரிப்புகள் தொடர்பான செர்ஜியோ லெர்னரின் வாதங்கள் மிகக்குறைந்த முக்கியத்துவம் கொண்டதாகிவிடுகின்றன. + +[Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) பற்றி மேலும். + +## ஈத்தாஷ் {#ethash} + +ஈத்தாஷ் என்பது, இப்போது வழக்கொழிந்த வேலைக்கான-ஆதார கட்டமைப்பின் கீழ் உண்மையான எத்தேரியம் மெயின்நெட்டில் பயன்படுத்தப்பட்ட சுரங்க அல்காரிதம் ஆகும். ஈத்தாஷ் என்பது, Dagger-Hashimoto-வின் ஒரு குறிப்பிட்ட பதிப்பிற்கு, அந்த அல்காரிதம் கணிசமாகப் புதுப்பிக்கப்பட்ட பிறகு கொடுக்கப்பட்ட ஒரு புதிய பெயராகும், அதே சமயம் அது தனது முன்னோடியின் அடிப்படைக் கொள்கைகளை மரபுரிமையாகக் கொண்டிருந்தது. எத்தேரியம் மெயின்நெட் எப்போதுமே ஈத்தாஷை மட்டுமே பயன்படுத்தியது - Dagger Hashimoto என்பது எத்தேரியம் மெயின்நெட்டில் சுரங்கம் தொடங்குவதற்கு முன்பு மாற்றியமைக்கப்பட்ட சுரங்க அல்காரிதத்தின் ஒரு R&D பதிப்பாகும். + +[ஈத்தாஷ் பற்றி மேலும்](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash). + +## மேலும் வாசிக்க {#further-reading} + +_உங்களுக்கு உதவிய ஒரு சமூக வளம் பற்றி தெரியுமா?_ இந்தப் பக்கத்தைத் திருத்தி அதைச் சேர்க்கவும்!_ diff --git a/public/content/translations/ta/developers/docs/dapps/index.md b/public/content/translations/ta/developers/docs/dapps/index.md new file mode 100644 index 00000000000..75c99b532ca --- /dev/null +++ b/public/content/translations/ta/developers/docs/dapps/index.md @@ -0,0 +1,96 @@ +--- +title: "dapps-க்கான தொழில்நுட்ப அறிமுகம்" +description: +lang: ta +--- + +ஒரு பரவலாக்கப்பட்ட செயலி (dapp) என்பது ஒரு பரவலாக்கப்பட்ட நெட்வொர்க்கில் கட்டமைக்கப்பட்ட ஒரு செயலியாகும், இது ஒரு [ஸ்மார்ட் ஒப்பந்தம்](/developers/docs/smart-contracts/) மற்றும் ஒரு முகப்பு பயனர் இடைமுகத்தை ஒருங்கிணைக்கிறது. எதீரியம் பரவலாக அணுகக்கூடிய மற்றும் வெளிப்படையான ஸ்மார்ட் ஒப்பந்தங்களை வழங்குகிறது – திறந்த API க்கள் போன்ற – எனவே உங்கள் dapp மற்றவர்கள் எழுதிய ஸ்மார்ட் ஒப்பந்தத்தைக் கூடச் சேர்க்கலாம். + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +dapps பற்றி அறிந்துகொள்வதற்கு முன், நீங்கள் [பிளாக்செயின் அடிப்படைகளை](/developers/docs/intro-to-ethereum/)ப் படித்து, Ethereum நெட்வொர்க் மற்றும் அது எவ்வாறு பரவலாக்கப்பட்டுள்ளது என்பதைப் பற்றி படிக்க வேண்டும். + +## dapp-இன் வரையறை {#definition-of-a-dapp} + +ஒரு dapp இன் பின்னணி குறியீடு மையமற்ற பீர்-টু-பீர் நெட்வொர்க் மீது இயங்குகிறது. இதனை மையமாக்கப்பட்ட சேவையகங்களில் இயங்கும் பயன்பாடுகளுடன் ஒப்பிடுங்கள். + +ஒரு dapp இன் முன்னணி குறியீடு மற்றும் பயனர் இடைமுகங்களை எது மொழியில் எழுதலாம் (ஒரு பயன்பாட்டைப் போல) அதன் பின்னணிக்கு அழைப்புகளைச் செய்ய. மேலும், அதன் முகப்பை [IPFS](https://ipfs.io/) போன்ற பரவலாக்கப்பட்ட சேமிப்பகத்தில் ஹோஸ்ட் செய்யலாம். + +- **பரவலாக்கப்பட்டது** - dapps Ethereum-இல் இயங்குகின்றன, இது ஒரு திறந்த பொது பரவலாக்கப்பட்ட தளமாகும், இதில் எந்தவொரு நபரோ அல்லது குழுவோ கட்டுப்பாட்டைக் கொண்டிருக்கவில்லை +- **தீர்மானகரமானது** - dapps அவை செயல்படுத்தப்படும் சூழலைப் பொருட்படுத்தாமல் ஒரே செயல்பாட்டைச் செய்கின்றன +- **டியூரிங் கம்ப்ளீட்** - தேவையான வளங்கள் கொடுக்கப்பட்டால் dapps எந்தவொரு செயலையும் செய்ய முடியும் +- **தனிமைப்படுத்தப்பட்டது** - dapps, Ethereum Virtual Machine எனப்படும் ஒரு மெய்நிகர் சூழலில் செயல்படுத்தப்படுகின்றன, இதனால் ஸ்மார்ட் ஒப்பந்தத்தில் பிழை இருந்தாலும், அது பிளாக்செயின் நெட்வொர்க்கின் இயல்பான செயல்பாட்டைத் தடுக்காது + +### ஸ்மார்ட் ஒப்பந்தங்கள் பற்றி {#on-smart-contracts} + +Dapps ஐ அறிமுகப்படுத்த நாங்கள் ஸ்மார்ட் ஒப்பந்தங்களை அறிமுகம் செய்ய வேண்டும் – dapp இன் பின்னணி என்று சொல்லலாம். விரிவான கண்ணோட்டத்திற்கு, எங்கள் [ஸ்மார்ட் ஒப்பந்தங்கள்](/developers/docs/smart-contracts/) பகுதிக்குச் செல்லவும். + +ஒரு ஸ்மார்ட் ஒப்பந்தம் எதீரியம் பிளாக்செய்னில் வாழும் மற்றும் திட்டமிட்டவாறு செயல்படும் குறியீடாகும். ஸ்மார்ட் ஒப்பந்தங்கள் நெட்வொர்க்கில் விநியோகிக்கப்பட்ட பிறகு, நீங்கள் அவற்றை மாற்ற முடியாது. Dapps மையமற்றதாக இருக்க முடியும், ஏனெனில் அவற்றைப் கட்டுப்படுத்தும் நோக்கத்தை ஒப்பந்தத்தில் எழுதப்பட்டுள்ளது, ஒருவரும் அல்லது நிறுவனமும் அல்ல. இதன் அர்த்தம் உங்கள் ஒப்பந்தங்களை மிகவும் கவனமாக வடிவமைக்கவும், முறையாகச் சோதிக்கவும் வேண்டும். + +## dapp உருவாக்கத்தின் நன்மைகள் {#benefits-of-dapp-development} + +- **செயலிழப்பு இல்லாத நேரம்** – ஸ்மார்ட் ஒப்பந்தம் பிளாக்செயினில் பயன்படுத்தப்பட்டவுடன், ஒப்பந்தத்துடன் தொடர்பு கொள்ள விரும்பும் வாடிக்கையாளர்களுக்கு நெட்வொர்க் முழுவதுமாக எப்போதும் சேவை செய்ய முடியும். ஆகையால், தீய நோக்கமுடையவர்கள் தனித்துவ dapps க்கு நோக்கித் தவிர்க்கும் தாக்குதல்களை எடுக்க முடியாது. +- **தனியுரிமை** – ஒரு dapp-ஐ பயன்படுத்த அல்லது அதனுடன் தொடர்பு கொள்ள நீங்கள் நிஜ-உலக அடையாளத்தை வழங்கத் தேவையில்லை. +- **தணிக்கைக்கு எதிர்ப்பு** – நெட்வொர்க்கில் உள்ள எந்தவொரு தனி நிறுவனமும் பயனர்களை பரிவர்த்தனைகளைச் சமர்ப்பிப்பதிலிருந்தோ, dapps-களைப் பயன்படுத்துவதிலிருந்தோ, அல்லது பிளாக்செயினிலிருந்து தரவைப் படிப்பதிலிருந்தோ தடுக்க முடியாது. +- **முழுமையான தரவு நேர்மை** – கிரிப்டோகிராஃபிக் ப்ரிமிட்டிவ்களுக்கு நன்றி, பிளாக்செயினில் சேமிக்கப்பட்ட தரவு மாற்ற முடியாதது மற்றும் மறுக்க முடியாதது. தீய நோக்கமுடையவர்கள் ஏற்கனவே வெளிப்படுத்தப்பட்ட பரிமாற்றங்களை அல்லது பிற தரவுகளை உருவாக்க முடியாது. +- **நம்பிக்கையற்ற கணக்கீடு/சரிபார்க்கக்கூடிய நடத்தை** – ஒரு மைய அதிகாரத்தை நம்ப வேண்டிய அவசியமின்றி, ஸ்மார்ட் ஒப்பந்தங்களைப் பகுப்பாய்வு செய்யலாம் மற்றும் அவை கணிக்கக்கூடிய வழிகளில் செயல்படுத்தப்படும் என்று உத்தரவாதம் அளிக்கப்படுகிறது. பாரம்பரிய மாதிரிகளில் இது உண்மை அல்ல; எடுத்துக்காட்டாக, நாங்கள் ஆன்லைன் வங்கி முறைகளைப் பயன்படுத்தும்போது, நாங்கள் நிதி நிறுவனங்கள் நமது நிதி தரவுகளைத் தவறாகப் பயன்படுத்தாதது, பதிவுகளை மாற்றாதது அல்லது 해킹 செய்யாதது என்பதை நம்ப வேண்டியுள்ளது. + +## dapp உருவாக்கத்தின் குறைபாடுகள் {#drawbacks-of-dapp-development} + +- **பராமரிப்பு** – Dapps-களைப் பராமரிப்பது கடினமாக இருக்கலாம், ஏனெனில் பிளாக்செயினில் வெளியிடப்பட்ட குறியீடு மற்றும் தரவை மாற்றுவது கடினம். Dapps (அல்லது dapp சேமிக்கப்படும் அடிப்படை தரவுகள்) விநியோகிக்கப்பட்ட பிறகு மேம்படுத்துவதில் developers க்கு சிரமமாக இருக்கிறது, பழைய பதிப்பில் பிழைகள் அல்லது பாதுகாப்பு ஆபத்துகள் அடையாளம் காணப்பட்டாலும். +- **செயல்திறன் கூடுதல் சுமை** – ஒரு பெரிய செயல்திறன் கூடுதல் சுமை உள்ளது, மேலும் அளவிடுதல் மிகவும் கடினம். எதீரியம் நம்பகத்தன்மை, வெளிப்படைத்தன்மை மற்றும் நம்பிக்கையுள்ள நிலையினை அடைய, ஒவ்வொரு நெட்வொர்க் ஓர் பாகம் ஒவ்வொரு பரிமாற்றத்தையும் ஓடுகிறது மற்றும் சேமிக்கிறது. அதற்கு மேலாக, proof-of-stake கருத்துகூட்டம் நேரம் எடுக்கும். +- **நெட்வொர்க் நெரிசல்** – ஒரு dapp அதிகப்படியான கணினி வளங்களைப் பயன்படுத்தும்போது, முழு நெட்வொர்க்கும் ஸ்தம்பிக்கிறது. தற்போதைய நிலைமையில், நெட்வொர்க் ஒரு நிமிடத்திற்கு சுமார் 10-15 பரிமாற்றங்களை மட்டுமே செயலாக்கக்கூடியது; இதற்கேற்ப வேகமாகப் பரிமாற்றங்கள் அனுப்பப்பட்டால், நிலைமையற்ற பரிமாற்றங்களின் குவிப்பு விரைவில் பெருக்கலாம். +- **பயனர் அனுபவம்** – உண்மையிலேயே பாதுகாப்பான முறையில் பிளாக்செயினுடன் தொடர்பு கொள்ள தேவையான ஒரு கருவி அடுக்கை அமைப்பதை சராசரி இறுதிப் பயனர் மிகவும் கடினமாக உணரக்கூடும் என்பதால், பயனருக்கு ஏற்ற அனுபவங்களை வடிவமைப்பது கடினமாக இருக்கலாம். +- **மையப்படுத்தல்** – Ethereum-இன் அடிப்படை அடுக்கின் மேல் கட்டமைக்கப்பட்ட பயனருக்கு ஏற்ற மற்றும் உருவாக்குநருக்கு ஏற்ற தீர்வுகள், எப்படியும் மையப்படுத்தப்பட்ட சேவைகளைப் போலவே தோற்றமளிக்கலாம். எடுத்துக்காட்டாக, அத்தகைய சேவைகள் கீகளை அல்லது பிற மெச்சப்பட்ட தகவல்களைச் சர்வர் பக்கம் சேமிக்கலாம், மைய சேவையைக் கொண்டு ஒரு முன்னணி வழங்கலாம், அல்லது பிளாக்செய்னில் எழுதுவதற்கு முந்தைய முக்கிய வணிக கட்டளையை மைய சேவையில் ஓடிடலாம். மையமையல் பிளாக்செயினின் பல (என்றாலும் அனைத்தும்) ஆதவுகளை குறைக்கிறது. + +## பார்த்து கற்பவரா? {#visual-learner} + + + +## dapps-களை உருவாக்குவதற்கான கருவிகள் {#dapp-tools} + +**Scaffold-ETH _- உங்கள் ஸ்மார்ட் ஒப்பந்தத்திற்கு ஏற்றவாறு மாறும் முகப்பைப் பயன்படுத்தி Solidity-உடன் விரைவாக பரிசோதனை செய்யுங்கள்._** + +- [GitHub](https://github.com/scaffold-eth/scaffold-eth-2) +- [எடுத்துக்காட்டு dapp](https://punkwallet.io/) + +**Create Eth App _- ஒரே கட்டளையில் Ethereum-ஆல் இயக்கப்படும் செயலிகளை உருவாக்குங்கள்._** + +- [GitHub](https://github.com/paulrberg/create-eth-app) + +**One Click Dapp _- ஒரு [ABI](/glossary/#abi)-இலிருந்து dapp முகப்புகளை உருவாக்குவதற்கான FOSS கருவி._** + +- [oneclickdapp.com](https://oneclickdapp.com) +- [GitHub](https://github.com/oneclickdapp/oneclickdapp-v1) + +**Etherflow _- Ethereum உருவாக்குநர்கள் தங்கள் node-ஐச் சோதிக்கவும், உலாவியில் இருந்து RPC அழைப்புகளை உருவாக்கவும் மற்றும் பிழைதிருத்தம் செய்யவும் உதவும் FOSS கருவி._** + +- [etherflow.quiknode.io](https://etherflow.quiknode.io/) +- [GitHub](https://github.com/abunsen/etherflow) + +**thirdweb _- ஒவ்வொரு மொழியிலும் உள்ள SDK-கள், ஸ்மார்ட் ஒப்பந்தங்கள், கருவிகள், மற்றும் web3 உருவாக்கத்திற்கான உள்கட்டமைப்பு._** + +- [முகப்புப்பக்கம்](https://thirdweb.com/) +- [ஆவணங்கள்](https://portal.thirdweb.com/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Crossmint _- ஸ்மார்ட் ஒப்பந்தங்களைப் பயன்படுத்தவும், கிரெடிட் கார்டு மற்றும் கிராஸ் செயின் கட்டணங்களை இயக்கவும், மற்றும் NFT-களை உருவாக்க, விநியோகிக்க, விற்க, சேமிக்க, மற்றும் திருத்த API-களைப் பயன்படுத்தவும் உதவும் நிறுவன தரத்திலான web3 மேம்பாட்டுத் தளம்._** + +- [crossmint.com](https://www.crossmint.com) +- [ஆவணங்கள்](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +## மேலும் வாசிக்க {#further-reading} + +- [dapps-களை ஆராயுங்கள்](/apps) +- [ஒரு Web 3.0 பயன்பாட்டின் கட்டமைப்பு](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _ப்ரீத்தி காசிரெட்டி_ +- [பரவலாக்கப்பட்ட செயலிகளுக்கான 2021 வழிகாட்டி](https://limechain.tech/blog/what-are-dapps-the-2021-guide/) - _LimeChain_ +- [பரவலாக்கப்பட்ட செயலிகள் என்றால் என்ன?](https://www.gemini.com/cryptopedia/decentralized-applications-defi-dapps) - _Gemini_ +- [பிரபலமான dapps](https://www.alchemy.com/dapps) - _Alchemy_ + +_உங்களுக்கு உதவிய ஒரு சமூக வளம் பற்றி தெரியுமா?_ இந்தப் பக்கத்தைத் திருத்தி அதைச் சேர்க்கவும்!_ + +## தொடர்புடைய தலைப்புகள் {#related-topics} + +- [Ethereum ஸ்டேக்கிற்கான அறிமுகம்](/developers/docs/ethereum-stack/) +- [உருவாக்க கட்டமைப்புகள்](/developers/docs/frameworks/) diff --git a/public/content/translations/ta/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/ta/developers/docs/data-and-analytics/block-explorers/index.md new file mode 100644 index 00000000000..e7bae0cf9fe --- /dev/null +++ b/public/content/translations/ta/developers/docs/data-and-analytics/block-explorers/index.md @@ -0,0 +1,254 @@ +--- +title: "தொகுதி ஆய்வு கருவி" +description: "தொகுதி ஆய்வு கருவிகளுக்கான ஒரு அறிமுகம், பிளாக்செயின் தரவுகளின் உலகத்திற்கான உங்கள் நுழைவாயில், இங்கு பரிவர்த்தனைகள், கணக்குகள், ஒப்பந்தங்கள் மற்றும் பலவற்றைப் பற்றிய தகவல்களை நீங்கள் வினவலாம்." +lang: ta +sidebarDepth: 3 +--- + +தொகுதி ஆய்வு கருவிகள் எத்தேரியத்தின் தரவுகளுக்கான உங்கள் நுழைவாயிலாகும். தொகுதிகள், பரிவர்த்தனைகள், சரிபார்ப்பவர்கள், கணக்குகள் மற்றும் பிற ஆன்செயின் செயல்பாடுகள் குறித்த நிகழ்நேரத் தரவைக் காண அவற்றைப் பயன்படுத்தலாம். + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +ஒரு தொகுதி ஆய்வு கருவி உங்களுக்கு வழங்கும் தரவைப் புரிந்துகொள்ள, நீங்கள் எத்தேரியத்தின் அடிப்படைக் கருத்துக்களைப் புரிந்து கொள்ள வேண்டும். [எத்தேரியம் அறிமுகம்](/developers/docs/intro-to-ethereum/) மூலம் தொடங்கவும். + +## சேவைகள் {#services} + +- [Etherscan](https://etherscan.io/) -_சீன, கொரிய, ரஷ்ய மற்றும் ஜப்பானிய மொழிகளிலும் கிடைக்கிறது_ +- [3xpl](https://3xpl.com/ethereum) +- [Beaconcha.in](https://beaconcha.in/) +- [Blockchair](https://blockchair.com/ethereum) -_ஸ்பானிஷ், பிரெஞ்சு, இத்தாலியன், டச்சு, போர்த்துகீசியம், ரஷ்யன், சீனம் மற்றும் ஃபார்ஸி மொழிகளிலும் கிடைக்கிறது_ +- [Blockscout](https://eth.blockscout.com/) +- [Chainlens](https://www.chainlens.com/) +- [DexGuru தொகுதி ஆய்வு கருவி](https://ethereum.dex.guru/) +- [Etherchain](https://www.etherchain.org/) +- [Ethplorer](https://ethplorer.io/) -_சீனம், ஸ்பானிஷ், பிரஞ்சு, துருக்கியம், ரஷ்யன், கொரியன் மற்றும் வியட்நாமிய மொழிகளிலும் கிடைக்கிறது_ +- [EthVM](https://www.ethvm.com/) +- [OKLink](https://www.oklink.com/eth) +- [Ethseer](https://ethseer.io) + +## திறந்த மூலக் கருவிகள் {#open-source-tools} + +- [Otterscan](https://otterscan.io/) +- [lazy-etherscan](https://github.com/woxjro/lazy-etherscan) + +## தரவு {#data} + +எத்தேரியம் வடிவமைப்பால் வெளிப்படையானது, எனவே எல்லாவற்றையும் சரிபார்க்க முடியும். தொகுதி ஆய்வு கருவிகள் இந்தத் தகவலைப் பெறுவதற்கான இடைமுகத்தை வழங்குகின்றன. மேலும் உங்களுக்கு அந்தத் தரவு தேவைப்பட்டால், இது பிரதான எத்தேரியம் நெட்வொர்க் மற்றும் சோதனை நெட்வொர்க்குகள் இரண்டிற்கும் பொருந்தும். தரவு செயல்படுத்தல் தரவு மற்றும் கருத்தொற்றுமை தரவு என பிரிக்கப்பட்டுள்ளது. செயல்படுத்தல் தரவு ஒரு குறிப்பிட்ட தொகுதியில் செயல்படுத்தப்பட்ட பரிவர்த்தனைகளைக் குறிக்கிறது. கருத்தொற்றுமை தரவு தொகுதிகளையும் அவற்றை முன்மொழிந்த சரிபார்ப்பவர்களையும் குறிக்கிறது. + +ஒரு தொகுதி ஆய்வு கருவியில் இருந்து நீங்கள் பெறக்கூடிய தரவு வகைகளின் சுருக்கம் இதோ. + +### செயல்படுத்தல் தரவு {#execution-data} + +ஒவ்வொரு 12 வினாடிகளுக்கும் புதிய தொகுதிகள் எத்தேரியத்தில் சேர்க்கப்படுகின்றன (ஒரு தொகுதி முன்மொழிபவர் தனது வாய்ப்பைத் தவறவிட்டால் தவிர), எனவே ஏறக்குறைய நிலையான தரவுத் தொடர் தொகுதி ஆய்வு கருவிகளில் சேர்க்கப்படுகிறது. தொகுதிகளில் நீங்கள் பயனுள்ளதாகக் காணக்கூடிய பல முக்கியமான தரவுகள் உள்ளன: + +**நிலையான தரவு** + +- தொகுதி உயரம் - தற்போதைய தொகுதியை உருவாக்கும்போது தொகுதி எண் மற்றும் பிளாக்செயினின் நீளம் (தொகுதிகளில்) +- நேரமுத்திரை - ஒரு தொகுதி முன்மொழியப்பட்ட நேரம் +- பரிவர்த்தனைகள் - தொகுதிக்குள் சேர்க்கப்பட்ட பரிவர்த்தனைகளின் எண்ணிக்கை +- கட்டணம் பெறுபவர் - பரிவர்த்தனைகளிலிருந்து எரிவாயு கட்டண டிப்ஸ்களைப் பெற்ற முகவரி +- தொகுதி வெகுமதி - தொகுதியை முன்மொழிந்த சரிபார்ப்பவருக்கு வழங்கப்படும் ETH அளவு +- அளவு - தொகுதிக்குள் உள்ள தரவின் அளவு (பைட்டுகளில் அளவிடப்படுகிறது) +- பயன்படுத்தப்பட்ட எரிவாயு - தொகுதியில் உள்ள பரிவர்த்தனைகளால் பயன்படுத்தப்பட்ட எரிவாயுவின் மொத்த அலகுகள் +- எரிவாயு வரம்பு - தொகுதியில் உள்ள பரிவர்த்தனைகளால் அமைக்கப்பட்ட மொத்த எரிவாயு வரம்புகள் +- ஒரு எரிவாயுவிற்கான அடிப்படைக் கட்டணம் - ஒரு பரிவர்த்தனை ஒரு தொகுதியில் சேர்க்கப்படுவதற்குத் தேவையான குறைந்தபட்ச பெருக்கி +- எரிக்கப்பட்ட கட்டணங்கள் - தொகுதியில் எவ்வளவு ETH எரிக்கப்படுகிறது +- கூடுதல் தரவு - உருவாக்குபவர் தொகுதியில் சேர்த்துள்ள எந்த கூடுதல் தரவும் + +**மேம்பட்ட தரவு** + +- துண்டி - தொகுதி தலைப்பைக் குறிக்கும் கிரிப்டோகிராஃபிக் துண்டி (தொகுதியின் தனிப்பட்ட அடையாளங்காட்டி) +- பெற்றோர் துண்டி - தற்போதைய தொகுதிக்கு முன் வந்த தொகுதியின் துண்டி +- StateRoot - கணினியின் முழு நிலையையும் சேமிக்கும் Merkle trie-யின் ரூட் துண்டி + +### எரிவாயு {#gas} + +தொகுதி ஆய்வு கருவிகள் பரிவர்த்தனைகள் மற்றும் தொகுதிகளில் எரிவாயு பயன்பாடு பற்றிய தரவை உங்களுக்கு வழங்குவதோடு மட்டுமல்லாமல், சில நெட்வொர்க்கின் தற்போதைய எரிவாயு விலைகள் பற்றிய தகவலையும் வழங்கும். இது நெட்வொர்க் பயன்பாட்டைப் புரிந்துகொள்ளவும், பாதுகாப்பான பரிவர்த்தனைகளைச் சமர்ப்பிக்கவும், எரிவாயுவிற்கு அதிகமாக செலவழிக்காமல் இருக்கவும் உங்களுக்கு உதவும். உங்கள் தயாரிப்பின் இடைமுகத்தில் இந்தத் தகவலைப் பெற உதவும் API-களைத் தேடுங்கள். எரிவாயு-குறிப்பிட்ட தரவு உள்ளடக்கியது: + +- பாதுகாப்பான ஆனால் மெதுவான பரிவர்த்தனைக்குத் தேவையான எரிவாயுவின் மதிப்பிடப்பட்ட அலகுகள் (+ மதிப்பிடப்பட்ட விலை மற்றும் கால அளவு) +- சராசரி பரிவர்த்தனைக்குத் தேவையான எரிவாயுவின் மதிப்பிடப்பட்ட அலகுகள் (+ மதிப்பிடப்பட்ட விலை மற்றும் கால அளவு) +- வேகமான பரிவர்த்தனைக்குத் தேவையான எரிவாயுவின் மதிப்பிடப்பட்ட அலகுகள் (+ மதிப்பிடப்பட்ட விலை மற்றும் கால அளவு) +- எரிவாயு விலையின் அடிப்படையில் சராசரி உறுதிப்படுத்தல் நேரம் +- எரிவாயுவை பயன்படுத்தும் ஒப்பந்தங்கள் - வேறுவிதமாகக் கூறினால், நெட்வொர்க்கில் அதிக பயன்பாட்டைக் காணும் பிரபலமான தயாரிப்புகள் +- எரிவாயு செலவழிக்கும் கணக்குகள் - வேறுவிதமாகக் கூறினால், அடிக்கடி நெட்வொர்க் பயன்படுத்துபவர்கள் + +### பரிவர்த்தனைகள் {#transactions} + +மக்கள் தங்கள் பரிவர்த்தனைகளின் முன்னேற்றத்தைக் கண்காணிக்க தொகுதி ஆய்வு கருவிகள் ஒரு பொதுவான இடமாக மாறிவிட்டன. ஏனென்றால், நீங்கள் பெறக்கூடிய விவரங்களின் நிலை கூடுதல் உறுதியை வழங்குகிறது. பரிவர்த்தனைத் தரவில் அடங்குபவை: + +**நிலையான தரவு** + +- பரிவர்த்தனை துண்டி - பரிவர்த்தனை சமர்ப்பிக்கப்படும்போது உருவாக்கப்படும் ஒரு துண்டி +- நிலை - பரிவர்த்தனை நிலுவையில் உள்ளதா, தோல்வியடைந்ததா அல்லது வெற்றிகரமானதா என்பதற்கான ஒரு அறிகுறி +- தொகுதி - பரிவர்த்தனை சேர்க்கப்பட்டுள்ள தொகுதி +- நேரமுத்திரை - ஒரு சரிபார்ப்பவரால் முன்மொழியப்பட்ட ஒரு தொகுதியில் ஒரு பரிவர்த்தனை சேர்க்கப்பட்ட நேரம் +- இருந்து - பரிவர்த்தனையைச் சமர்ப்பித்த கணக்கின் முகவரி +- க்கு - பரிவர்த்தனை தொடர்பு கொள்ளும் பெறுநரின் அல்லது ஸ்மார்ட் ஒப்பந்தத்தின் முகவரி +- மாற்றப்பட்ட டோக்கன்கள் - பரிவர்த்தனையின் ஒரு பகுதியாக மாற்றப்பட்ட டோக்கன்களின் பட்டியல் +- மதிப்பு - மாற்றப்படும் மொத்த ETH மதிப்பு +- பரிவர்த்தனைக் கட்டணம் - பரிவர்த்தனையைச் செயல்படுத்த சரிபார்ப்பவருக்கு செலுத்தப்பட்ட தொகை (எரிவாயு விலை\*பயன்படுத்தப்பட்ட எரிவாயு மூலம் கணக்கிடப்படுகிறது) + +**மேம்பட்ட தரவு** + +- எரிவாயு வரம்பு - இந்த பரிவர்த்தனை பயன்படுத்தக்கூடிய அதிகபட்ச எரிவாயு அலகுகளின் எண்ணிக்கை +- பயன்படுத்தப்பட்ட எரிவாயு - பரிவர்த்தனை பயன்படுத்திய எரிவாயு அலகுகளின் உண்மையான அளவு +- எரிவாயு விலை - ஒரு எரிவாயு அலகுக்கு நிர்ணயிக்கப்பட்ட விலை +- நான்ஸ் - `from` முகவரிக்கான பரிவர்த்தனை எண் (இது 0 இலிருந்து தொடங்குகிறது என்பதை நினைவில் கொள்ளுங்கள், எனவே `100` என்ற நான்ஸ் உண்மையில் இந்தக் கணக்கிலிருந்து சமர்ப்பிக்கப்பட்ட 101வது பரிவர்த்தனையாக இருக்கும்) +- உள்ளீட்டுத் தரவு - பரிவர்த்தனைக்குத் தேவைப்படும் ஏதேனும் கூடுதல் தகவல் + +### கணக்குகள் {#accounts} + +ஒரு கணக்கைப் பற்றி நீங்கள் அணுகக்கூடிய பல தரவுகள் உள்ளன. இதனால்தான் பல கணக்குகளைப் பயன்படுத்த பரிந்துரைக்கப்படுகிறது, அதனால் உங்கள் சொத்துகளையும் மதிப்பையும் எளிதில் கண்காணிக்க முடியாது. பரிவர்த்தனைகள் மற்றும் கணக்குச் செயல்பாடுகளை மேலும் தனிப்பட்டதாக மாற்றுவதற்கு சில தீர்வுகள் உருவாக்கப்பட்டு வருகின்றன. ஆனால் கணக்குகளுக்குக் கிடைக்கும் தரவு இதோ: + +**பயனர் கணக்குகள்** + +- கணக்கு முகவரி - நீங்கள் நிதி அனுப்பப் பயன்படுத்தக்கூடிய பொது முகவரி +- ETH இருப்பு - அந்த கணக்குடன் தொடர்புடைய ETH இன் அளவு +- மொத்த ETH மதிப்பு - ETH இன் மதிப்பு +- டோக்கன்கள் - கணக்குடன் தொடர்புடைய டோக்கன்கள் மற்றும் அவற்றின் மதிப்பு +- பரிவர்த்தனை வரலாறு - இந்த கணக்கு அனுப்புநராகவோ அல்லது பெறுநராகவோ இருந்த அனைத்து பரிவர்த்தனைகளின் பட்டியல் + +**ஸ்மார்ட் ஒப்பந்தங்கள்** + +ஸ்மார்ட் ஒப்பந்தக் கணக்குகள் ஒரு பயனர் கணக்கு கொண்டிருக்கும் அனைத்து தரவையும் கொண்டிருக்கும், ஆனால் சில தொகுதி ஆய்வு கருவிகள் சில குறியீட்டுத் தகவலையும் காண்பிக்கும். எடுத்துக்காட்டுகளில் அடங்குபவை: + +- ஒப்பந்த உருவாக்குநர் - ஒப்பந்தத்தை Mainnet-க்கு பயன்படுத்திய முகவரி +- உருவாக்கும் பரிவர்த்தனை - Mainnet-க்கு பயன்படுத்தியதை உள்ளடக்கிய பரிவர்த்தனை +- மூலக் குறியீடு - ஸ்மார்ட் ஒப்பந்தத்தின் Solidity அல்லது Vyper குறியீடு +- ஒப்பந்த ABI - ஒப்பந்தத்தின் பயன்பாட்டு பைனரி இடைமுகம்—ஒப்பந்தம் செய்யும் அழைப்புகள் மற்றும் பெறப்பட்ட தரவு +- ஒப்பந்த உருவாக்கக் குறியீடு - ஸ்மார்ட் ஒப்பந்தத்தின் தொகுக்கப்பட்ட பைட் குறியீடு—நீங்கள் Solidity அல்லது Vyper போன்றவற்றில் எழுதப்பட்ட ஸ்மார்ட் ஒப்பந்தத்தைத் தொகுக்கும்போது உருவாக்கப்பட்டது. +- ஒப்பந்த நிகழ்வுகள் - ஸ்மார்ட் ஒப்பந்தத்தில் அழைக்கப்பட்ட முறைகளின் வரலாறு—அடிப்படையில் ஒப்பந்தம் எவ்வாறு பயன்படுத்தப்படுகிறது மற்றும் எவ்வளவு அடிக்கடி பயன்படுத்தப்படுகிறது என்பதைப் பார்ப்பதற்கான ஒரு வழி + +### டோக்கன்கள் {#tokens} + +டோக்கன்கள் ஒரு வகை ஒப்பந்தம், எனவே அவை ஸ்மார்ட் ஒப்பந்தத்தைப் போன்ற தரவைக் கொண்டிருக்கும். ஆனால் அவற்றுக்கு மதிப்பு இருப்பதால் மற்றும் வர்த்தகம் செய்யப்படலாம் என்பதால் அவற்றுக்கு கூடுதல் தரவு புள்ளிகள் உள்ளன: + +- வகை - அவை ERC-20, ERC-721 அல்லது மற்றொரு டோக்கன் தரநிலையா என்பது +- விலை - அவை ERC-20 ஆக இருந்தால், அவற்றுக்கு தற்போதைய சந்தை மதிப்பு இருக்கும் +- சந்தை மூலதனம் - அவை ERC-20 ஆக இருந்தால், அவற்றுக்கு சந்தை மூலதனம் இருக்கும் (விலை\*மொத்த வழங்கல் மூலம் கணக்கிடப்படுகிறது) +- மொத்த வழங்கல் - புழக்கத்தில் உள்ள டோக்கன்களின் எண்ணிக்கை +- வைத்திருப்பவர்கள் - டோக்கனை வைத்திருக்கும் முகவரிகளின் எண்ணிக்கை +- இடமாற்றங்கள் - டோக்கன் கணக்குகளுக்கு இடையில் மாற்றப்பட்ட முறைகளின் எண்ணிக்கை +- பரிவர்த்தனை வரலாறு - டோக்கன் உட்பட அனைத்து பரிவர்த்தனைகளின் வரலாறு +- ஒப்பந்த முகவரி - Mainnet-இல் பயன்படுத்தப்பட்ட டோக்கனின் முகவரி +- தசமங்கள் - ERC-20 டோக்கன்கள் பிரிக்கக்கூடியவை மற்றும் தசம இடங்களைக் கொண்டுள்ளன + +### நெட்வொர்க் {#network} + +சில தொகுதித் தரவு எத்தேரியத்தின் ஆரோக்கியத்தைப் பற்றி முழுமையாக அக்கறை கொண்டுள்ளது. + +- மொத்த பரிவர்த்தனைகள் - எத்தேரியம் உருவாக்கப்பட்டதிலிருந்து பரிவர்த்தனைகளின் எண்ணிக்கை +- விநாடிக்கு பரிவர்த்தனைகள் - ஒரு விநாடிக்குள் செயலாக்கக்கூடிய பரிவர்த்தனைகளின் எண்ணிக்கை +- ETH விலை - 1 ETH இன் தற்போதைய மதிப்பீடுகள் +- மொத்த ETH வழங்கல் - புழக்கத்தில் உள்ள ETH இன் எண்ணிக்கை—ஒவ்வொரு தொகுதியையும் உருவாக்கும்போது தொகுதி வெகுமதிகள் வடிவில் புதிய ETH உருவாக்கப்படுகிறது என்பதை நினைவில் கொள்ளுங்கள் +- சந்தை மூலதனம் - விலை\*வழங்கல் கணக்கீடு + +## கருத்தொற்றுமை அடுக்குத் தரவு {#consensus-layer-data} + +### சகாப்தம் {#epoch} + +பாதுகாப்பு காரணங்களுக்காக, ஒவ்வொரு சகாப்தத்தின் முடிவிலும் (ஒவ்வொரு 6.4 நிமிடங்களுக்கும்) சரிபார்ப்பவர்களின் சீரற்ற குழுக்கள் உருவாக்கப்படுகின்றன. சகாப்தத் தரவில் அடங்குபவை: + +- சகாப்த எண் +- இறுதி செய்யப்பட்ட நிலை - சகாப்தம் இறுதி செய்யப்பட்டதா (ஆம்/இல்லை) +- நேரம் - சகாப்தம் முடிந்த நேரம் +- சான்றளிப்புகள் - சகாப்தத்தில் உள்ள சான்றளிப்புகளின் எண்ணிக்கை (இடங்களுக்குள் உள்ள தொகுதிகளுக்கான வாக்குகள்) +- வைப்புத்தொகைகள் - சகாப்தத்தில் சேர்க்கப்பட்ட ETH வைப்புத்தொகைகளின் எண்ணிக்கை (சரிபார்ப்பவர்கள் சரிபார்ப்பவர்களாக மாற ETH-ஐ பங்கு வைக்க வேண்டும்) +- வெட்டுதல்கள் - தொகுதி முன்மொழிபவர்கள் அல்லது சான்றளிப்பவர்களுக்கு வழங்கப்படும் தண்டனைகளின் எண்ணிக்கை +- வாக்களிப்பு பங்கேற்பு - தொகுதிகளுக்குச் சான்றளிக்கப் பயன்படுத்தப்படும் பங்கு வைக்கப்பட்ட ETH இன் அளவு +- சரிபார்ப்பவர்கள் - சகாப்தத்திற்குச் செயலில் உள்ள சரிபார்ப்பவர்களின் எண்ணிக்கை +- சராசரி சரிபார்ப்பவர் இருப்பு - செயலில் உள்ள சரிபார்ப்பவர்களுக்கான சராசரி இருப்பு +- இடங்கள் - சகாப்தத்தில் சேர்க்கப்பட்டுள்ள இடங்களின் எண்ணிக்கை (இடங்களில் ஒரு செல்லுபடியாகும் தொகுதி அடங்கும்) + +### ஸ்லாட் {#slot} + +ஸ்லாட்டுகள் தொகுதி உருவாக்கத்திற்கான வாய்ப்புகள், ஒவ்வொரு ஸ்லாட்டிற்கும் கிடைக்கும் தரவு உள்ளடக்கியது: + +- சகாப்தம் - ஸ்லாட் செல்லுபடியாகும் சகாப்தம் +- ஸ்லாட் எண் +- நிலை - ஸ்லாட்டின் நிலை (முன்மொழியப்பட்டது/தவறியது) +- நேரம் - ஸ்லாட் நேரமுத்திரை +- முன்மொழிபவர் - ஸ்லாட்டிற்கான தொகுதியை முன்மொழிந்த சரிபார்ப்பவர் +- தொகுதி ரூட் - BeaconBlock-இன் ஹாஷ்-ட்ரீ-ரூட் +- பெற்றோர் ரூட் - முன் வந்த தொகுதியின் துண்டி +- ஸ்டேட் ரூட் - BeaconState-இன் ஹாஷ்-ட்ரீ-ரூட் +- கையொப்பம் +- Randao வெளிப்படுத்தல் +- சுவரெழுத்து - ஒரு தொகுதி முன்மொழிபவர் தனது தொகுதி முன்மொழிவில் 32 பைட் நீள செய்தியைச் சேர்க்கலாம் +- செயல்படுத்தல் தரவு + - தொகுதி துண்டி + - வைப்புத்தொகை எண்ணிக்கை + - வைப்புத்தொகை ரூட் +- சான்றளிப்புகள் - இந்த ஸ்லாட்டில் உள்ள தொகுதிக்கான சான்றளிப்புகளின் எண்ணிக்கை +- வைப்புத்தொகைகள் - இந்த ஸ்லாட்டின் போது வைப்புத்தொகைகளின் எண்ணிக்கை +- தன்னார்வ வெளியேற்றங்கள் - ஸ்லாட்டின் போது வெளியேறிய சரிபார்ப்பவர்களின் எண்ணிக்கை +- வெட்டுதல்கள் - தொகுதி முன்மொழிபவர்கள் அல்லது சான்றளிப்பவர்களுக்கு வழங்கப்படும் தண்டனைகளின் எண்ணிக்கை +- வாக்குகள் - இந்த ஸ்லாட்டில் உள்ள தொகுதிக்கு வாக்களித்த சரிபார்ப்பவர்கள் + +### தொகுதிகள் {#blocks-1} + +பங்குச் சான்று நேரத்தை ஸ்லாட்டுகள் மற்றும் சகாப்தங்களாகப் பிரிக்கிறது. அதனால் புதிய தரவு என்று பொருள்! + +- முன்மொழிபவர் - புதிய தொகுதியை முன்மொழிய வழிமுறைப்படி தேர்ந்தெடுக்கப்பட்ட சரிபார்ப்பவர் +- சகாப்தம் - தொகுதி முன்மொழியப்பட்ட சகாப்தம் +- ஸ்லாட் - தொகுதி முன்மொழியப்பட்ட ஸ்லாட் +- சான்றளிப்புகள் - ஸ்லாட்டில் சேர்க்கப்பட்டுள்ள சான்றளிப்புகளின் எண்ணிக்கை—சான்றளிப்புகள் என்பது தீப்பந்த சங்கிலிக்குச் செல்லத் தொகுதி தயாராக உள்ளது என்பதைக் குறிக்கும் வாக்குகளைப் போன்றது + +### சரிபார்ப்பவர்கள் {#validators} + +சரிபார்ப்பவர்கள் ஸ்லாட்டுகளுக்குள் தொகுதிகளை முன்மொழிவதற்கும் அவற்றுக்குச் சான்றளிப்பதற்கும் பொறுப்பானவர்கள். + +- சரிபார்ப்பவர் எண் - சரிபார்ப்பவரைக் குறிக்கும் தனிப்பட்ட எண் +- தற்போதைய இருப்பு - வெகுமதிகள் உட்பட சரிபார்ப்பவரின் இருப்பு +- செயல்படும் இருப்பு - பங்கு வைப்பதற்காகப் பயன்படுத்தப்படும் சரிபார்ப்பவரின் இருப்பு +- வருமானம் - சரிபார்ப்பவர் பெற்ற வெகுமதிகள் அல்லது தண்டனைகள் +- நிலை - சரிபார்ப்பவர் தற்போது ஆன்லைனில் மற்றும் செயலில் இருக்கிறாரா இல்லையா என்பது +- சான்றளிப்பு செயல்திறன் - சரிபார்ப்பவரின் சான்றளிப்புகள் சங்கிலியில் சேர்க்கப்படுவதற்கு எடுக்கும் சராசரி நேரம் +- செயல்படுத்துவதற்கான தகுதி - சரிபார்ப்பவர் சரிபார்க்கக் கிடைத்த தேதி (மற்றும் சகாப்தம்) +- செயலில் இருந்து - சரிபார்ப்பவர் செயலுக்கு வந்த தேதி (மற்றும் சகாப்தம்) +- முன்மொழியப்பட்ட தொகுதிகள் - சரிபார்ப்பவர் முன்மொழிந்த தொகுதி +- சான்றளிப்புகள் - சரிபார்ப்பவர் வழங்கிய சான்றளிப்புகள் +- வைப்புத்தொகைகள் - சரிபார்ப்பவர் செய்த பங்கு வைப்பின் 'இருந்து' முகவரி, பரிவர்த்தனை துண்டி, தொகுதி எண், நேரமுத்திரை, தொகை மற்றும் நிலை + +### சான்றளிப்புகள் {#attestations} + +சான்றளிப்புகள் சங்கிலியில் தொகுதிகளைச் சேர்ப்பதற்கான "ஆம்" வாக்குகள் ஆகும். அவர்களின் தரவு சான்றளிப்பின் பதிவு மற்றும் சான்றளித்த சரிபார்ப்பவர்களுடன் தொடர்புடையது + +- ஸ்லாட் - சான்றளிப்பு நடந்த ஸ்லாட் +- குழு அட்டவணை - கொடுக்கப்பட்ட ஸ்லாட்டில் உள்ள குழுவின் அட்டவணை +- திரட்டல் பிட்கள் - சான்றளிப்பில் பங்கேற்கும் அனைத்து சரிபார்ப்பவர்களின் திரட்டப்பட்ட சான்றளிப்பைக் குறிக்கிறது +- சரிபார்ப்பவர்கள் - சான்றளிப்புகளை வழங்கிய சரிபார்ப்பவர்கள் +- தீப்பந்த தொகுதி ரூட் - சரிபார்ப்பவர்கள் சான்றளிக்கும் தொகுதியைக் குறிக்கிறது +- மூலம் - சமீபத்திய நியாயப்படுத்தப்பட்ட சகாப்தத்தைக் குறிக்கிறது +- இலக்கு - சமீபத்திய சகாப்த எல்லையைக் குறிக்கிறது +- கையொப்பம் + +### நெட்வொர்க் {#network-1} + +கருத்தொற்றுமை அடுக்கின் உயர் மட்ட தரவு பின்வருவனவற்றை உள்ளடக்கியது: + +- தற்போதைய சகாப்தம் +- தற்போதைய ஸ்லாட் +- செயலில் உள்ள சரிபார்ப்பவர்கள் - செயலில் உள்ள சரிபார்ப்பவர்களின் எண்ணிக்கை +- நிலுவையில் உள்ள சரிபார்ப்பவர்கள் - செயலில் ஆக்கப்படுவதற்காகக் காத்திருக்கும் சரிபார்ப்பவர்களின் எண்ணிக்கை +- பங்கு வைக்கப்பட்ட ETH - நெட்வொர்க்கில் பங்கு வைக்கப்பட்ட ETH இன் அளவு +- சராசரி இருப்பு - சரிபார்ப்பவர்களின் சராசரி ETH இருப்பு + +## தொகுதி ஆய்வுக் கருவிகள் {#block-explorers} + +- [Etherscan](https://etherscan.io/) - எத்தேரியம் மெயின்நெட் மற்றும் டெஸ்ட்நெட்டிற்கான தரவைப் பெற நீங்கள் பயன்படுத்தக்கூடிய ஒரு தொகுதி ஆய்வு கருவி +- [3xpl](https://3xpl.com/ethereum) - ஒரு விளம்பரமில்லாத திறந்த மூல எத்தேரியம் ஆய்வு கருவி, அதன் தரவுத்தொகுப்புகளைப் பதிவிறக்க அனுமதிக்கிறது +- [Beaconcha.in](https://beaconcha.in/) - எத்தேரியம் மெயின்நெட் மற்றும் டெஸ்ட்நெட்டிற்கான ஒரு திறந்த மூல தொகுதி ஆய்வு கருவி +- [Blockchair](https://blockchair.com/ethereum) - மிகவும் தனியார் எத்தேரியம் ஆய்வு கருவி. மேலும் (mempool) தரவை வரிசைப்படுத்துவதற்கும் வடிகட்டுவதற்கும் +- [Etherchain](https://www.etherchain.org/) - எத்தேரியம் மெயின்நெட்டிற்கான ஒரு தொகுதி ஆய்வு கருவி +- [Ethplorer](https://ethplorer.io/) - எத்தேரியம் மெயின்நெட் மற்றும் கோவன் டெஸ்ட்நெட்டிற்கான டோக்கன்களில் கவனம் செலுத்தும் ஒரு தொகுதி ஆய்வு கருவி + +## மேலும் வாசிக்க {#further-reading} + +_உங்களுக்கு உதவிய ஒரு சமூக வளம் பற்றி தெரியுமா?_ இந்தப் பக்கத்தைத் திருத்தி அதைச் சேர்க்கவும்!_ + +## தொடர்புடைய தலைப்புகள் {#related-topics} + +- [பரிவர்த்தனைகள்](/developers/docs/transactions/) +- [கணக்குகள்](/developers/docs/accounts/) +- [வலையமைப்புகள்](/developers/docs/networks/) diff --git a/public/content/translations/ta/developers/docs/data-and-analytics/index.md b/public/content/translations/ta/developers/docs/data-and-analytics/index.md new file mode 100644 index 00000000000..18f6993689c --- /dev/null +++ b/public/content/translations/ta/developers/docs/data-and-analytics/index.md @@ -0,0 +1,72 @@ +--- +title: "தகவல்களும் பகுப்பாய்வுகளும்" +description: "உங்கள் டாப்களில் பயன்படுத்துவதற்காக ஆன்செயின் பகுப்பாய்வுகளையும் தரவுகளையும் பெறுவது எப்படி" +lang: ta +--- + +## அறிமுகம் {#Introduction} + +நெட்வொர்க்கின் பயன்பாடு தொடர்ந்து வளர்ந்து வருவதால், ஆன்செயின் தரவுகளில் மதிப்புமிக்க தகவல்களின் அளவு அதிகரித்துக்கொண்டே இருக்கும். தரவுகளின் அளவு வேகமாக அதிகரித்து வருவதால், ஒரு டாப்பை அறிக்கையிட அல்லது இயக்க இந்தத் தகவலைக் கணக்கிடுவது மற்றும் ஒருங்கிணைப்பது நேரம் மற்றும் செயல்முறை சார்ந்த ஒரு பெரும் முயற்சியாக மாறும். + +தற்போதுள்ள தரவு வழங்குநர்களைப் பயன்படுத்துவது மேம்பாட்டை விரைவுபடுத்தும், துல்லியமான முடிவுகளை உருவாக்கும் மற்றும் தற்போதைய பராமரிப்பு முயற்சிகளைக் குறைக்கும். இது ஒரு குழு தங்கள் திட்டம் வழங்க முயற்சிக்கும் முக்கிய செயல்பாட்டில் கவனம் செலுத்த உதவும். + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +தரவு பகுப்பாய்வு சூழலில் அவற்றைப் பயன்படுத்துவதை நன்கு புரிந்துகொள்ள [தொகுதி ஆய்வுக் கருவிகளின்](/developers/docs/data-and-analytics/block-explorers/) அடிப்படைக் கருத்தை நீங்கள் புரிந்து கொள்ள வேண்டும். கூடுதலாக, ஒரு கணினி வடிவமைப்பில் அவை சேர்க்கும் நன்மைகளைப் புரிந்துகொள்ள [குறியீட்டின்](/glossary/#index) கருத்தாக்கத்துடன் உங்களைப் பழக்கப்படுத்திக் கொள்ளுங்கள். + +கட்டமைப்பு அடிப்படைகளைப் பொறுத்தவரை, கோட்பாட்டளவில் கூட [API](https://www.wikipedia.org/wiki/API) மற்றும் [REST](https://www.wikipedia.org/wiki/Representational_state_transfer) என்றால் என்ன என்பதைப் புரிந்துகொள்வது அவசியம். + +## தொகுதி ஆய்வுக் கருவிகள் {#block-explorers} + +பல [தொகுதி ஆய்வுக் கருவிகள்](/developers/docs/data-and-analytics/block-explorers/) [RESTful](https://www.wikipedia.org/wiki/Representational_state_transfer) [API](https://www.wikipedia.org/wiki/API) நுழைவாயில்களை வழங்குகின்றன. அவை தொகுதிகள், பரிவர்த்தனைகள், சரிபார்ப்பவர்கள், கணக்குகள் மற்றும் பிற ஆன்செயின் செயல்பாடுகள் குறித்த நிகழ்நேரத் தரவுகளை உருவாக்குநர்களுக்குக் காண்பிக்கும். + +உருவாக்குநர்கள் இந்தத் தரவைச் செயலாக்கி மாற்றுவதன் மூலம் தங்கள் பயனர்களுக்கு [பிளாக்செயினுடன்](/glossary/#blockchain) தனித்துவமான பார்வைகளையும் தொடர்புகளையும் வழங்க முடியும். உதாரணமாக, [Etherscan](https://etherscan.io) மற்றும் [Blockscout](https://eth.blockscout.com) ஒவ்வொரு 12s ஸ்லாட்டிற்கும் செயல்படுத்தல் மற்றும் ஒருமித்த தரவை வழங்குகின்றன. + +## தி கிராஃப் {#the-graph} + +[தி கிராஃப்](https://thegraph.com/) என்பது ஒரு குறியீட்டு நெறிமுறையாகும், இது துணை வரைபடங்கள் எனப்படும் திறந்த API-கள் மூலம் பிளாக்செயின் தரவை வினவுவதற்கான எளிதான வழியை வழங்குகிறது. + +தி கிராஃப் மூலம், உருவாக்குநர்கள் இதன் மூலம் பயனடையலாம்: + +- பரவலாக்கப்பட்ட குறியீட்டு முறை: பல குறியீட்டாளர்கள் மூலம் பிளாக்செயின் தரவைக் குறியிட உதவுகிறது, இதனால் தோல்விக்கான ஒற்றை முனையை நீக்குகிறது +- GraphQL வினவல்கள்: குறியிடப்பட்ட தரவை வினவுவதற்கு சக்திவாய்ந்த GraphQL இடைமுகத்தை வழங்குகிறது, இது தரவு மீட்டெடுப்பை மிகவும் எளிதாக்குகிறது +- தனிப்பயனாக்கம்: பிளாக்செயின் தரவை மாற்றுவதற்கும் சேமிப்பதற்கும் உங்கள் சொந்த தர்க்கத்தை வரையறுக்கவும், மேலும் தி கிராஃப் நெட்வொர்க்கில் உள்ள பிற உருவாக்குநர்களால் வெளியிடப்பட்ட துணை வரைபடங்களை மீண்டும் பயன்படுத்தவும் + +5 நிமிடங்களுக்குள் ஒரு துணை வரைபடத்தை உருவாக்க, பயன்படுத்த மற்றும் வினவ இந்த [விரைவு-தொடக்க](https://thegraph.com/docs/en/quick-start/) வழிகாட்டியைப் பின்பற்றவும். + +## கிளையன்ட் பன்முகத்தன்மை {#client-diversity} + +[கிளையன்ட் பன்முகத்தன்மை](/developers/docs/nodes-and-clients/client-diversity/) எத்தேரியம் நெட்வொர்க்கின் ஒட்டுமொத்த ஆரோக்கியத்திற்கு முக்கியமானது, ஏனெனில் இது பிழைகள் மற்றும் சுரண்டல்களுக்கு நெகிழ்தன்மையை வழங்குகிறது. [clientdiversity.org](https://clientdiversity.org/), [rated.network](https://www.rated.network), [supermajority.info](https://supermajority.info//) மற்றும் [Ethernodes](https://ethernodes.org/) உட்பட பல கிளையன்ட் பன்முகத்தன்மை டாஷ்போர்டுகள் இப்போது உள்ளன. + +## Dune அனலிட்டிக்ஸ் {#dune-analytics} + +[Dune அனலிட்டிக்ஸ்](https://dune.com/) பிளாக்செயின் தரவை தொடர்புடைய தரவுத்தள (DuneSQL) அட்டவணைகளில் முன்கூட்டியே செயலாக்குகிறது, பயனர்கள் SQL ஐப் பயன்படுத்தி பிளாக்செயின் தரவை வினவவும், வினவல் முடிவுகளின் அடிப்படையில் டாஷ்போர்டுகளை உருவாக்கவும் அனுமதிக்கிறது. ஆன்செயின் தரவு 4 மூல அட்டவணைகளாக ஒழுங்கமைக்கப்பட்டுள்ளது: `blocks`, `transactions`, (நிகழ்வு) `logs` மற்றும் (அழைப்பு) `traces`. பிரபலமான ஒப்பந்தங்கள் மற்றும் நெறிமுறைகள் டிகோட் செய்யப்பட்டுள்ளன, மேலும் ஒவ்வொன்றும் அதன் சொந்த நிகழ்வு மற்றும் அழைப்பு அட்டவணைகளின் தொகுப்பைக் கொண்டுள்ளது. அந்த நிகழ்வு மற்றும் அழைப்பு அட்டவணைகள் மேலும் செயலாக்கப்பட்டு, நெறிமுறைகளின் வகையின்படி சுருக்க அட்டவணைகளாக ஒழுங்கமைக்கப்படுகின்றன, எடுத்துக்காட்டாக, dex, கடன், ஸ்டேபிள்காயின்கள் போன்றவை. + +## SQD {#sqd} + +[SQD](https://sqd.dev/) என்பது ஒரு பரவலாக்கப்பட்ட, ஹைப்பர்-ஸ்கேலபிள் தரவுத் தளமாகும், இது அதிக அளவு தரவுகளுக்கு திறமையான, அனுமதியற்ற அணுகலை வழங்குவதற்காக உகந்ததாக்கப்பட்டுள்ளது. இது தற்போது வரலாற்று ஆன்-செயின் தரவை வழங்குகிறது, இதில் நிகழ்வு பதிவுகள், பரிவர்த்தனை ரசீதுகள், தடயங்கள் மற்றும் ஒரு பரிவர்த்தனைக்கான நிலை வேறுபாடுகள் ஆகியவை அடங்கும். SQD தனிப்பயன் தரவு பிரித்தெடுத்தல் மற்றும் செயலாக்க பைப்லைன்களை உருவாக்குவதற்கான ஒரு சக்திவாய்ந்த கருவித்தொகுப்பை வழங்குகிறது, இது வினாடிக்கு 150k தொகுதிகள் வரை குறியீட்டு வேகத்தை அடைகிறது. + +தொடங்குவதற்கு, [ஆவணத்தைப்](https://docs.sqd.dev/) பார்வையிடவும் அல்லது SQD உடன் நீங்கள் எதை உருவாக்கலாம் என்பதற்கான [EVM எடுத்துக்காட்டுகளைப்](https://github.com/subsquid-labs/squid-evm-examples) பார்க்கவும். + +## சப்குவெரி நெட்வொர்க் {#subquery-network} + +[சப்குவெரி](https://subquery.network/) ஒரு முன்னணி தரவு குறியீட்டாளர் ஆகும், இது உருவாக்குநர்களுக்கு அவர்களின் web3 திட்டங்களுக்கு வேகமான, நம்பகமான, பரவலாக்கப்பட்ட மற்றும் தனிப்பயனாக்கப்பட்ட API-களை வழங்குகிறது. சப்குவெரி 165+க்கும் மேற்பட்ட சுற்றுச்சூழல் அமைப்புகளிலிருந்து (எத்தேரியம் உட்பட) உருவாக்குநர்களுக்கு அவர்களின் பயனர்களுக்கு உள்ளுணர்வு மற்றும் ஆழமான அனுபவங்களை உருவாக்க செறிவூட்டப்பட்ட குறியிடப்பட்ட தரவுகளுடன் அதிகாரம் அளிக்கிறது. சப்குவெரி நெட்வொர்க் உங்கள் தடுக்க முடியாத பயன்பாடுகளை ஒரு நெகிழ்திறன் மற்றும் பரவலாக்கப்பட்ட உள்கட்டமைப்பு நெட்வொர்க்குடன் பலப்படுத்துகிறது. தரவு செயலாக்க நடவடிக்கைகளுக்காக ஒரு தனிப்பயன் பின்தளத்தை உருவாக்க நேரம் செலவழிக்காமல், எதிர்காலத்தின் web3 பயன்பாடுகளை உருவாக்க சப்குவெரியின் பிளாக்செயின் உருவாக்குநர் கருவித்தொகுப்பைப் பயன்படுத்தவும். + +தொடங்குவதற்கு, [சப்குவெரியின் நிர்வகிக்கப்பட்ட சேவையில்](https://managedservice.subquery.network/) அல்லது [சப்குவெரியின் பரவலாக்கப்பட்ட நெட்வொர்க்கில்](https://app.subquery.network/dashboard) நேரலைக்குச் செல்வதற்கு முன், சோதனைக்காக உள்ளூர் Docker சூழலில் நிமிடங்களில் எத்தேரியம் பிளாக்செயின் தரவைக் குறியிடத் தொடங்க [எத்தேரியம் விரைவு தொடக்க வழிகாட்டியைப்](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) பார்வையிடவும். + +## EVM வினவல் மொழி {#evm-query-language} + +EVM வினவல் மொழி (EQL) என்பது EVM (எத்தேரியம் மெய்நிகர் இயந்திரம்) சங்கிலிகளை வினவ வடிவமைக்கப்பட்ட SQL போன்ற ஒரு மொழியாகும். EQL-இன் இறுதி இலக்கு, EVM சங்கிலியின் முதல்-வகுப்பு குடிமக்களான (தொகுதிகள், கணக்குகள் மற்றும் பரிவர்த்தனைகள்) மீது சிக்கலான தொடர்புடைய வினவல்களை ஆதரிப்பதாகும், அதே நேரத்தில் உருவாக்குநர்கள் மற்றும் ஆராய்ச்சியாளர்களுக்கு அன்றாட பயன்பாட்டிற்கான பணிச்சூழலியல் தொடரியலை வழங்குகிறது. EQL உடன், உருவாக்குநர்கள் பழக்கமான SQL போன்ற தொடரியலைப் பயன்படுத்தி பிளாக்செயின் தரவைப் பெறலாம் மற்றும் சிக்கலான பாய்லர்பிளேட் குறியீட்டின் தேவையை அகற்றலாம். EQL நிலையான பிளாக்செயின் தரவுக் கோரிக்கைகளை ஆதரிக்கிறது (எ.கா., எத்தேரியத்தில் ஒரு கணக்கின் நான்ஸ் மற்றும் இருப்பைப் பெறுதல் அல்லது தற்போதைய தொகுதி அளவு மற்றும் நேரமுத்திரையைப் பெறுதல்) மேலும் சிக்கலான கோரிக்கைகள் மற்றும் அம்சத் தொகுப்புகளுக்கான ஆதரவைத் தொடர்ந்து சேர்த்து வருகிறது. + +## மேலும் வாசிக்க {#further-reading} + +- [கிரிப்டோ தரவை ஆராய்தல் I: தரவு ஓட்ட கட்டமைப்புகள்](https://web.archive.org/web/20250125012042/https://research.2077.xyz/exploring-crypto-data-1-data-flow-architectures) +- [கிராஃப் நெட்வொர்க் கண்ணோட்டம்](https://thegraph.com/docs/en/about/) +- [கிராஃப் வினவல் விளையாட்டு மைதானம்](https://thegraph.com/explorer/subgraph/graphprotocol/graph-network-mainnet?version=current) +- [EtherScan-இல் API குறியீடு எடுத்துக்காட்டுகள்](https://etherscan.io/apis#contracts) +- [Blockscout-இல் API ஆவணம்](https://docs.blockscout.com/devs/apis) +- [Beaconcha.in பீக்கன் செயின் ஆய்வுக் கருவி](https://beaconcha.in) +- [Dune அடிப்படைகள்](https://docs.dune.com/#dune-basics) +- [சப்குவெரி எத்தேரியம் விரைவு தொடக்க வழிகாட்டி](https://academy.subquery.network/indexer/quickstart/quickstart_chains/ethereum-gravatar.html) +- [SQD நெட்வொர்க் கண்ணோட்டம்](https://docs.sqd.dev/) +- [EVM வினவல் மொழி](https://eql.sh/blog/alpha-release-notes) diff --git a/public/content/translations/ta/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/ta/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..9fe853e0a56 --- /dev/null +++ b/public/content/translations/ta/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "பிளாக்செயின் தரவு சேமிப்பு உத்திகள்" +description: "பிளாக்செயினைப் பயன்படுத்தி தரவைச் சேமிக்க பல வழிகள் உள்ளன. இந்தக் கட்டுரை வெவ்வேறு உத்திகள், அவற்றின் செலவுகள் மற்றும் வர்த்தகங்கள், மற்றும் அதைப் பாதுகாப்பாகப் பயன்படுத்துவதற்கான தேவைகள் ஆகியவற்றை ஒப்பிடும்." +lang: ta +--- + +தகவலை நேரடியாக பிளாக்செயினில் அல்லது பிளாக்செயினால் பாதுகாக்கப்பட்ட முறையில் சேமிக்க பல வழிகள் உள்ளன: + +- EIP-4844 blobs +- Calldata +- L1 வழிமுறைகளுடன் ஆஃப்செயின் +- ஒப்பந்த "குறியீடு" +- நிகழ்வுகள் +- EVM சேமிப்பகம் + +எந்த முறையைப் பயன்படுத்த வேண்டும் என்ற தேர்வு பல அளவுகோல்களை அடிப்படையாகக் கொண்டது: + +- தகவலின் மூலம். Calldata வில் உள்ள தகவல்கள் பிளாக்செயினில் இருந்து நேரடியாக வர முடியாது. +- தகவலின் இலக்கு. Calldata அதை உள்ளடக்கிய பரிவர்த்தனையில் மட்டுமே கிடைக்கும். நிகழ்வுகளை ஆன்செயினில் அணுக முடியாது. +- எவ்வளவு சிரமம் ஏற்றுக்கொள்ளத்தக்கது? முழு அளவிலான முனையை இயக்கும் கணினிகள், உலாவியில் இயங்கும் ஒரு பயன்பாட்டில் உள்ள லைட் கிளைன்ட்டை விட அதிக செயலாக்கத்தைச் செய்ய முடியும். +- ஒவ்வொரு முனையிலிருந்தும் தகவல்களுக்கு எளிதாக அணுகுவதை எளிதாக்குவது அவசியமா? +- பாதுகாப்பு தேவைகள். + +## பாதுகாப்பு தேவைகள் {#security-requirements} + +பொதுவாக, தகவல் பாதுகாப்பு மூன்று பண்புகளைக் கொண்டுள்ளது: + +- _இரகசியத்தன்மை_, அங்கீகரிக்கப்படாத நிறுவனங்கள் தகவலைப் படிக்க அனுமதிக்கப்படவில்லை. பல சந்தர்ப்பங்களில் இது முக்கியமானது, ஆனால் இங்கே இல்லை. _பிளாக்செயினில் இரகசியங்கள் எதுவும் இல்லை_. பிளாக்செயின்கள் வேலை செய்கின்றன, ஏனெனில் யார் வேண்டுமானாலும் நிலை மாற்றங்களைச் சரிபார்க்க முடியும், எனவே இரகசியங்களை நேரடியாக சேமிக்க அவற்றைப் பயன்படுத்துவது சாத்தியமில்லை. பிளாக்செயினில் இரகசியமான தகவல்களைச் சேமிப்பதற்கான வழிகள் உள்ளன, ஆனால் அவை அனைத்தும் குறைந்தபட்சம் ஒரு திறவுகோலைச் சேமிக்க சில ஆஃப்செயின் கூறுகளை நம்பியுள்ளன. + +- _ஒருமைப்பாடு_, தகவல் சரியானது, அதை அங்கீகரிக்கப்படாத நிறுவனங்களால் மாற்ற முடியாது, அல்லது அங்கீகரிக்கப்படாத வழிகளில் மாற்ற முடியாது (உதாரணமாக, ஒரு `Transfer` நிகழ்வு இல்லாமல் [ERC-20 டோக்கன்களை](https://eips.ethereum.org/EIPS/eip-20#events) மாற்றுவது). பிளாக்செயினில், ஒவ்வொரு முனையும் ஒவ்வொரு நிலை மாற்றத்தையும் சரிபார்க்கிறது, இது ஒருமைப்பாட்டை உறுதி செய்கிறது. + +- _கிடைக்கும்தன்மை_, தகவல் எந்தவொரு அங்கீகரிக்கப்பட்ட நிறுவனத்திற்கும் கிடைக்கிறது. பிளாக்செயினில், ஒவ்வொரு [முழு முனையிலும்](https://ethereum.org/developers/docs/nodes-and-clients#full-node) தகவலைக் கிடைக்கச் செய்வதன் மூலம் இது பொதுவாக அடையப்படுகிறது. + +இங்குள்ள வெவ்வேறு தீர்வுகள் அனைத்தும் சிறந்த ஒருமைப்பாட்டைக் கொண்டுள்ளன, ஏனெனில் ஹாஷ்கள் L1 இல் வெளியிடப்படுகின்றன. இருப்பினும், அவை வெவ்வேறு கிடைக்கும் தன்மை உத்தரவாதங்களைக் கொண்டுள்ளன. + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +[பிளாக்செயின் அடிப்படைகள்](/developers/docs/intro-to-ethereum/) பற்றிய நல்ல புரிதல் உங்களுக்கு இருக்க வேண்டும். இந்தப் பக்கம் வாசகருக்கு [தொகுதிகள்](/developers/docs/blocks/), [பரிவர்த்தனைகள்](/developers/docs/transactions/) மற்றும் பிற தொடர்புடைய தலைப்புகளில் பரிச்சயம் இருப்பதாகக் கருதுகிறது. + +## EIP-4844 blobs {#eip-4844-blobs} + +[Dencun ஹார்டுஃபோர்க்கில்](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md) இருந்து, Ethereum பிளாக்செயினில் [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) சேர்க்கப்பட்டுள்ளது, இது Ethereum-க்கு வரையறுக்கப்பட்ட ஆயுட்காலத்துடன் (ஆரம்பத்தில் சுமார் [18 நாட்கள்](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration)) தரவுத் தொகுப்புகளைச் சேர்க்கிறது. இந்த ப்ளாப்ஸ்கள் [செயல்படுத்தும் கேஸிலிருந்து](/developers/docs/gas) தனித்தனியாக விலை நிர்ணயிக்கப்படுகின்றன, இருப்பினும் இது ஒரு ஒத்த வழிமுறையைப் பயன்படுத்துகிறது. தற்காலிகத் தரவை இடுகையிட அவை ஒரு மலிவான வழியாகும். + +EIP-4844 ப்ளாப்ஸ்களின் முக்கிய பயன்பாட்டு நிகழ்வு, ரோலப்கள் தங்கள் பரிவர்த்தனைகளை வெளியிடுவதாகும். [ஆப்டிமிஸ்டிக் ரோலப்கள்](/developers/docs/scaling/optimistic-rollups) தங்கள் பிளாக்செயின்களில் பரிவர்த்தனைகளை வெளியிட வேண்டும். ரோலப்பின் [சீக்வென்ஸர்](https://docs.optimism.io/connect/resources/glossary#sequencer) தவறான நிலை மூலத்தை இடுகையிட்டால், [சரிபார்ப்பாளர்கள்](https://docs.optimism.io/connect/resources/glossary#validator) தவறை சரிசெய்ய, அந்தப் பரிவர்த்தனைகள் [சவால் காலத்தில்](https://docs.optimism.io/connect/resources/glossary#challenge-period) யாருக்கும் கிடைக்க வேண்டும். + +இருப்பினும், சவால் காலம் முடிந்து, நிலை மூலம் இறுதி செய்யப்பட்டவுடன், இந்தப் பரிவர்த்தனைகளை அறிவதற்கான மீதமுள்ள நோக்கம், சங்கிலியின் தற்போதைய நிலையைப் பிரதிபலிப்பதே ஆகும். இந்த நிலை சங்கிலி முனைகளிலிருந்தும் கிடைக்கிறது, இதற்கு மிகக் குறைவான செயலாக்கம் தேவைப்படுகிறது. எனவே பரிவர்த்தனைத் தகவல்கள் [பிளாக் எக்ஸ்ப்ளோரர்கள்](/developers/docs/data-and-analytics/block-explorers) போன்ற சில இடங்களில் இன்னும் பாதுகாக்கப்பட வேண்டும், ஆனால் Ethereum வழங்கும் தணிக்கை எதிர்ப்பு நிலைக்கு பணம் செலுத்த வேண்டிய அவசியமில்லை. + +[ஜீரோ-நாலேட்ஜ் ரோலப்களும்](/developers/docs/scaling/zk-rollups/#data-availability) தற்போதுள்ள நிலையை மற்ற முனைகள் பிரதியெடுக்க மற்றும் செல்லுபடியாகும் சான்றுகளை சரிபார்க்க தங்கள் பரிவர்த்தனைத் தரவை இடுகையிடுகின்றன, ஆனால் மீண்டும் அது ஒரு குறுகிய காலத் தேவையாகும். + +எழுதும் நேரத்தில், EIP-4844 இல் இடுகையிடுவதற்கு ஒரு பைட்டிற்கு ஒரு wei (10-18 ETH) செலவாகும், இது [ப்ளாப்ஸ்களைப் பதிவிடும் பரிவர்த்தனை உட்பட, எந்தவொரு பரிவர்த்தனைக்கும் செலவாகும் 21,000 செயல்பாட்டுக் கேஸ் உடன்](https://eth.blockscout.com/tx/0xf6cfaf0431c73dd1d96369a5e6707d64f463ccf477a4131265397f1d81466929?tab=index) ஒப்பிடுகையில் மிகக் குறைவானதாகும். தற்போதைய EIP-4844 விலையை [blobscan.com](https://blobscan.com/blocks) இல் நீங்கள் காணலாம். + +சில பிரபலமான ரோலப்களால் இடுகையிடப்பட்ட ப்ளாப்ஸ்களைக் காண முகவரிகள் இங்கே உள்ளன. + +| ரோலப் | அஞ்சல்பெட்டி முகவரி | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | +| [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} + +Calldata என்பது பரிவர்த்தனையின் ஒரு பகுதியாக அனுப்பப்படும் பைட்டுகளைக் குறிக்கிறது. இது அந்த பரிவர்த்தனையை உள்ளடக்கிய தொகுதியில் பிளாக்செயினின் நிரந்தர பதிவின் ஒரு பகுதியாக சேமிக்கப்படுகிறது. + +பிளாக்செயினில் நிரந்தரமாக தரவை வைப்பதற்கான மலிவான முறை இதுவாகும். ஒரு பைட்டிற்கான செலவு 4 செயல்படுத்தும் கேஸ் (பைட் பூஜ்ஜியமாக இருந்தால்) அல்லது 16 கேஸ் (வேறு எந்த மதிப்பிற்கும்) ஆகும். தரவு சுருக்கப்பட்டால், இது ஒரு நிலையான நடைமுறையாகும், பின்னர் ஒவ்வொரு பைட் மதிப்பும் சமமாக இருக்க வாய்ப்புள்ளது, எனவே சராசரி செலவு ஒரு பைட்டிற்கு தோராயமாக 15.95 கேஸ் ஆகும். + +எழுதும் நேரத்தில், விலைகள் 12 gwei/கேஸ் மற்றும் 2300 $/ETH ஆகும், அதாவது ஒரு கிலோபைட்டிற்கான செலவு தோராயமாக 45 சென்ட்கள் ஆகும். EIP-4844க்கு முன்பு இதுவே மலிவான முறையாக இருந்ததால், ரோலப்கள் பரிவர்த்தனைத் தகவல்களைச் சேமிக்கப் பயன்படுத்திய முறை இதுவாகும், இது [தவறு சவால்களுக்கு](https://docs.optimism.io/stack/protocol/overview#fault-proofs) கிடைக்க வேண்டும், ஆனால் ஆன்செயினில் நேரடியாக அணுக வேண்டிய அவசியமில்லை. + +சில பிரபலமான ரோலப்களால் இடுகையிடப்பட்ட பரிவர்த்தனைகளைக் காண முகவரிகள் இங்கே உள்ளன. + +| ரோலப் | அஞ்சல்பெட்டி முகவரி | +| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | +| [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) | + +## L1 வழிமுறைகளுடன் ஆஃப்செயின் {#offchain-with-l1-mechs} + +உங்கள் பாதுகாப்பு வர்த்தகங்களைப் பொறுத்து, தகவலை வேறு இடத்தில் வைப்பதும், தேவைப்படும்போது தரவு கிடைப்பதை உறுதி செய்யும் ஒரு வழிமுறையைப் பயன்படுத்துவதும் ஏற்றுக்கொள்ளத்தக்கதாக இருக்கலாம். இது வேலை செய்ய இரண்டு தேவைகள் உள்ளன: + +1. தரவின் [ஹாஷை](https://en.wikipedia.org/wiki/Cryptographic_hash_function) பிளாக்செயினில் இடுகையிடவும், இது _உள்ளீட்டு அர்ப்பணிப்பு_ என்று அழைக்கப்படுகிறது. இது ஒரு ஒற்றை 32-பைட் வார்த்தையாக இருக்கலாம், எனவே இது விலை உயர்ந்ததல்ல. உள்ளீட்டு அர்ப்பணிப்பு கிடைக்கும் வரை, ஒருமைப்பாடு உறுதி செய்யப்படுகிறது, ஏனெனில் அதே மதிப்பிற்கு ஹாஷ் செய்யும் வேறு எந்த தரவையும் கண்டுபிடிப்பது சாத்தியமில்லை. எனவே தவறான தரவு வழங்கப்பட்டால், அதைக் கண்டறிய முடியும். + +2. கிடைப்பதை உறுதி செய்யும் ஒரு பொறிமுறையைக் கொண்டிருங்கள். உதாரணமாக, [Redstone](https://redstone.xyz/docs/what-is-redstone) இல் எந்த முனையும் ஒரு கிடைக்கும் தன்மை சவாலைச் சமர்ப்பிக்கலாம். சீக்வென்ஸர் காலக்கெடுவிற்குள் ஆன்செயினில் பதிலளிக்கவில்லை என்றால், உள்ளீட்டு அர்ப்பணிப்பு நிராகரிக்கப்படுகிறது, எனவே தகவல் ஒருபோதும் இடுகையிடப்படவில்லை என்று கருதப்படுகிறது. + +இது ஒரு ஆப்டிமிஸ்டிக் ரோலப்பிற்கு ஏற்றுக்கொள்ளத்தக்கது, ஏனெனில் நிலை மூலத்திற்கு குறைந்தபட்சம் ஒரு நேர்மையான சரிபார்ப்பாளரை நாம் ஏற்கனவே நம்பியிருக்கிறோம். அத்தகைய நேர்மையான சரிபார்ப்பாளர், தொகுதிகளைச் செயல்படுத்தத் தேவையான தரவுகள் தன்னிடம் உள்ளதா என்பதை உறுதிசெய்து, தகவல் ஆஃப்செயினில் கிடைக்கவில்லை என்றால், ஒரு கிடைக்கும் தன்மை சவாலை வெளியிடுவார். இந்த வகையான ஆப்டிமிஸ்டிக் ரோலப் [பிளாஸ்மா](/developers/docs/scaling/plasma/) என்று அழைக்கப்படுகிறது. + +## ஒப்பந்தக் குறியீடு {#contract-code} + +ஒருமுறை மட்டும் எழுதப்பட வேண்டிய, ஒருபோதும் மேலெழுதப்படாத மற்றும் ஆன்செயினில் கிடைக்க வேண்டிய தகவல்களை ஒப்பந்தக் குறியீடாகச் சேமிக்கலாம். இதன் பொருள், நாம் தரவுடன் ஒரு "ஸ்மார்ட் கான்ட்ராக்டை" உருவாக்கி, பின்னர் தகவலைப் படிக்க [`EXTCODECOPY`](https://www.evm.codes/#3c?fork=shanghai) ஐப் பயன்படுத்துகிறோம். குறியீட்டை நகலெடுப்பது ஒப்பீட்டளவில் மலிவானது என்பதே இதன் நன்மை. + +நினைவக விரிவாக்கத்தின் செலவைத் தவிர, `EXTCODECOPY` ஒரு ஒப்பந்தத்திற்கான முதல் அணுகலுக்கு (அது "குளிர்ச்சியாக" இருக்கும்போது) 2600 கேஸையும், அதே ஒப்பந்தத்திலிருந்து அடுத்தடுத்த நகல்களுக்கு 100 கேஸையும் மற்றும் 32 பைட் வார்த்தைக்கு 3 கேஸையும் செலவழிக்கிறது. ஒரு பைட்டிற்கு 15.95 செலவாகும் calldata உடன் ஒப்பிடும்போது, இது சுமார் 200 பைட்டுகளில் இருந்து மலிவானது. [நினைவக விரிவாக்கச் செலவுகளுக்கான சூத்திரத்தின்](https://www.evm.codes/about#memoryexpansion) அடிப்படையில், உங்களுக்கு 4MB-க்கு மேல் நினைவகம் தேவையில்லாத வரை, நினைவக விரிவாக்கச் செலவு calldata-வைச் சேர்ப்பதற்கான செலவை விடக் குறைவு. + +நிச்சயமாக, இது தரவைப் _படிப்பதற்கான_ செலவு மட்டுமே. ஒப்பந்தத்தை உருவாக்க தோராயமாக 32,000 கேஸ் + 200 கேஸ்/பைட் செலவாகும். வெவ்வேறு பரிவர்த்தனைகளில் ஒரே தகவலை பலமுறை படிக்க வேண்டியிருக்கும் போது மட்டுமே இந்த முறை சிக்கனமானது. + +ஒப்பந்தக் குறியீடு `0xEF` உடன் தொடங்காத வரை, அது பொருளற்றதாக இருக்கலாம். `0xEF` உடன் தொடங்கும் ஒப்பந்தங்கள் [எத்தேரியம் பொருள் வடிவமாக](https://notes.ethereum.org/@ipsilon/evm-object-format-overview) விளக்கப்படுகின்றன, இது மிகவும் கடுமையான தேவைகளைக் கொண்டுள்ளது. + +## நிகழ்வுகள் {#events} + +[நிகழ்வுகள்](https://docs.alchemy.com/docs/solidity-events) ஸ்மார்ட் கான்ட்ராக்ட்களால் வெளியிடப்பட்டு, ஆஃப்செயின் மென்பொருளால் படிக்கப்படுகின்றன. +ஆஃப்செயின் குறியீடு நிகழ்வுகளைக் கேட்க முடியும் என்பதே அவற்றின் நன்மை. செலவு [கேஸ்](https://www.evm.codes/#a0?fork=cancun), 375 மற்றும் ஒரு பைட் தரவிற்கு 8 கேஸ் ஆகும். 12 gwei/கேஸ் மற்றும் 2300 $/ETH இல், இதன் செலவு ஒரு சென்ட் மற்றும் ஒரு கிலோபைட்டிற்கு 22 சென்ட்கள் ஆகும். + +## சேமிப்பகம் {#storage} + +ஸ்மார்ட் கான்ட்ராக்ட்கள் [தொடர்ச்சியான சேமிப்பகத்திற்கு](https://docs.alchemy.com/docs/smart-contract-storage-layout#what-is-storage-memory) அணுகலைக் கொண்டுள்ளன. இருப்பினும், இது மிகவும் விலை உயர்ந்தது. முன்பு காலியாக இருந்த சேமிப்பு ஸ்லாட்டில் 32 பைட் வார்த்தையை எழுதுவதற்கு [22,100 கேஸ் செலவாகும்](https://www.evm.codes/#55?fork=cancun). 12 gwei/கேஸ் மற்றும் 2300 $/ETH இல், இது ஒரு எழுதும் செயல்பாட்டிற்கு சுமார் 61 சென்ட்கள் அல்லது ஒரு கிலோபைட்டிற்கு $19.5 ஆகும். + +இது Ethereum இல் மிகவும் விலையுயர்ந்த சேமிப்பு வடிவமாகும். + +## சுருக்கம் {#summary} + +இந்த அட்டவணை பல்வேறு விருப்பங்களையும், அவற்றின் நன்மைகள் மற்றும் தீமைகளையும் சுருக்கமாகக் கூறுகிறது. + +| சேமிப்பக வகை | தரவின் மூலம் | கிடைக்கும் தன்மை உத்தரவாதம் | ஆன்செயின் கிடைக்கும் தன்மை | கூடுதல் வரம்புகள் | +| --------------------------- | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | +| EIP-4844 blobs | ஆஃப்செயின் | [~18 நாட்களுக்கு](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) Ethereum உத்தரவாதம் | ஹாஷ் மட்டுமே கிடைக்கிறது | | +| Calldata | ஆஃப்செயின் | என்றென்றும் Ethereum உத்தரவாதம் (பிளாக்செயினின் ஒரு பகுதி) | ஒரு ஒப்பந்தத்தில் எழுதப்பட்டால் மற்றும் அந்தப் பரிவர்த்தனையில் மட்டுமே கிடைக்கும் | | +| L1 வழிமுறைகளுடன் ஆஃப்செயின் | ஆஃப்செயின் | சவால் காலத்தில் "ஒரு நேர்மையான சரிபார்ப்பாளர்" உத்தரவாதம் | ஹாஷ் மட்டும் | சவால் பொறிமுறையால் உத்தரவாதம் அளிக்கப்படுகிறது, சவால் காலத்தில் மட்டுமே | +| ஒப்பந்தக் குறியீடு | ஆன்செயின் அல்லது ஆஃப்செயின் | என்றென்றும் Ethereum உத்தரவாதம் (பிளாக்செயினின் ஒரு பகுதி) | ஆம் | ஒரு "சீரற்ற" முகவரிக்கு எழுதப்பட்டது, `0xEF` உடன் தொடங்க முடியாது | +| நிகழ்வுகள் | ஆன்செயின் | என்றென்றும் Ethereum உத்தரவாதம் (பிளாக்செயினின் ஒரு பகுதி) | இல்லை | | +| சேமிப்பு | ஆன்செயின் | என்றென்றும் Ethereum உத்தரவாதம் (பிளாக்செயினின் ஒரு பகுதி மற்றும் மேலெழுதப்படும் வரை தற்போதைய நிலை) | ஆம் | | diff --git a/public/content/translations/ta/developers/docs/data-availability/index.md b/public/content/translations/ta/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..8fdc2bda141 --- /dev/null +++ b/public/content/translations/ta/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: "தரவு கிடைக்கும் தன்மை" +description: "எத்தேரியத்தில் தரவு கிடைப்பது தொடர்பான சிக்கல்கள் மற்றும் தீர்வுகள் பற்றிய கண்ணோட்டம்" +lang: ta +--- + +"நம்ப வேண்டாம், சரிபார்க்கவும்" என்பது எத்தேரியத்தில் ஒரு பொதுவான கொள்கையாகும். யோசனை என்னவென்றால், உங்கள் முனை, முன்மொழியப்பட்ட மாற்றங்கள் முனையால் சுயாதீனமாக கணக்கிடப்பட்டவற்றுடன் துல்லியமாகப் பொருந்துகின்றன என்பதை உறுதி செய்வதற்காக, சக கணினிகளிடமிருந்து அவர்கள் பெறும் பிளாக்குகளில் உள்ள அனைத்துப் பரிவர்த்தனைகளையும் செயல்படுத்துவதன் மூலம் அது பெறும் தகவல்கள் சரியானவை என்பதைச் சுயாதீனமாகச் சரிபார்க்க முடியும். இதன் பொருள், பிளாக்கை அனுப்புபவர்கள் நேர்மையானவர்கள் என்று முனைகள் நம்ப வேண்டியதில்லை. தரவு விடுபட்டிருந்தால் இது சாத்தியமில்லை. + +**தரவு கிடைப்பது** என்பது ஒரு பிளாக்கைச் சரிபார்க்கத் தேவைப்படும் தரவுகள் அனைத்து நெட்வொர்க் பங்கேற்பாளர்களுக்கும் உண்மையில் கிடைக்கின்றன என்பதில் ஒரு பயனர் கொண்டிருக்கக்கூடிய நம்பிக்கையைக் குறிக்கிறது. எத்தேரியம் லேயர் 1-இல் உள்ள முழு முனைகளுக்கு இது ஒப்பீட்டளவில் எளிதானது; முழு முனையும் ஒவ்வொரு பிளாக்கிலும் உள்ள எல்லாத் தரவுகளின் நகலையும் பதிவிறக்குகிறது - பதிவிறக்கம் சாத்தியமாவதற்குத் தரவு _கிடைக்க_ வேண்டும். விடுபட்ட தரவுகளுடன் கூடிய ஒரு பிளாக் பிளாக்செயினில் சேர்க்கப்படுவதற்குப் பதிலாக நிராகரிக்கப்படும். இது "ஆன்செயின் தரவு கிடைக்கும் தன்மை" ஆகும், மேலும் இது ஒற்றைக்கல் பிளாக்செயின்களின் ஒரு அம்சமாகும். முழு முனைகளும் தங்களுக்காக ஒவ்வொரு பரிவர்த்தனையையும் பதிவிறக்கம் செய்து செயல்படுத்துவதால், செல்லாத பரிவர்த்தனைகளை ஏற்கும்படி ஏமாற்ற முடியாது. இருப்பினும், மாடுலர் பிளாக்செயின்கள், லேயர் 2 ரோலப்கள் மற்றும் லைட் வாடிக்கையாளர்களுக்கு, தரவு கிடைக்கும் தன்மைச் சூழல் மிகவும் சிக்கலானது, இதற்கு இன்னும் சில அதிநவீன சரிபார்ப்பு நடைமுறைகள் தேவைப்படுகின்றன. + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +நீங்கள் [பிளாக்செயின் அடிப்படைகள்](/developers/docs/intro-to-ethereum/), குறிப்பாக [ஒருமித்த கருத்து இயங்கமைப்புகள்](/developers/docs/consensus-mechanisms/) பற்றி நன்கு புரிந்துகொண்டிருக்க வேண்டும். இந்தப் பக்கம் வாசகருக்கு [பிளாக்குகள்](/developers/docs/blocks/), [பரிவர்த்தனைகள்](/developers/docs/transactions/), [முனைகள்](/developers/docs/nodes-and-clients/), [அளவிடுதல் தீர்வுகள்](/developers/docs/scaling/) மற்றும் பிற தொடர்புடைய தலைப்புகள் பற்றி நன்கு தெரியும் என்று கருதுகிறது. + +## தரவு கிடைக்கும் தன்மைச் சிக்கல் {#the-data-availability-problem} + +தரவு கிடைக்கும் தன்மைச் சிக்கல் என்பது, பிளாக்செயினில் சேர்க்கப்படும் சில பரிவர்த்தனைத் தரவுகளின் சுருக்கப்பட்ட வடிவம் உண்மையில் செல்லுபடியாகும் பரிவர்த்தனைகளின் தொகுப்பைக் குறிக்கிறது என்பதை முழு நெட்வொர்க்கிற்கும் நிரூபிக்க வேண்டியதன் அவசியமாகும், ஆனால் அனைத்து முனைகளும் அனைத்துத் தரவுகளையும் பதிவிறக்க வேண்டிய அவசியமின்றி இதைச் செய்ய வேண்டும். பிளாக்குகளை சுயாதீனமாக சரிபார்க்க முழு பரிவர்த்தனை தரவு அவசியம், ஆனால் அனைத்து முனைகளும் அனைத்து பரிவர்த்தனை தரவுகளையும் பதிவிறக்குவது அளவிடுதலுக்கு ஒரு தடையாக உள்ளது. தரவு கிடைக்கும் தன்மைச் சிக்கலுக்கான தீர்வுகள், தங்களுக்காகத் தரவைப் பதிவிறக்கம் செய்து சேமிக்காத நெட்வொர்க் பங்கேற்பாளர்களுக்கு சரிபார்ப்பதற்காக முழுப் பரிவர்த்தனைத் தரவும் கிடைக்கச் செய்யப்பட்டது என்பதற்குப் போதுமான உத்தரவாதங்களை வழங்குவதை நோக்கமாகக் கொண்டுள்ளன. + +[லைட் முனைகள்](/developers/docs/nodes-and-clients/light-clients) மற்றும் [லேயர் 2 ரோலப்கள்](/developers/docs/scaling) ஆகியவை வலுவான தரவு கிடைக்கும் தன்மை உத்தரவாதங்கள் தேவைப்படும், ஆனால் பரிவர்த்தனைத் தரவைத் தாங்களாகவே பதிவிறக்கம் செய்து செயலாக்க முடியாத நெட்வொர்க் பங்கேற்பாளர்களின் முக்கிய எடுத்துக்காட்டுகளாகும். பரிவர்த்தனைத் தரவைப் பதிவிறக்குவதைத் தவிர்ப்பதுதான் லைட் முனைகளை லைட்டாக ஆக்குகிறது மற்றும் ரோலப்களை திறமையான அளவிடுதல் தீர்வுகளாக இருக்க உதவுகிறது. + +பிளாக்குகளைச் சரிபார்க்க நிலைத் தரவைப் பதிவிறக்கம் செய்து சேமிக்கத் தேவையில்லாத எதிர்கால ["நிலை இல்லாத"](/roadmap/statelessness) எத்தேரியம் வாடிக்கையாளர்களுக்கும் தரவு கிடைப்பது ஒரு முக்கியமான கவலையாகும். நிலை இல்லாத வாடிக்கையாளர்கள் தரவு _எங்கோ_ கிடைக்கிறது மற்றும் அது சரியாகச் செயலாக்கப்பட்டுள்ளது என்பதை இன்னும் உறுதிப்படுத்த வேண்டும். + +## தரவு கிடைக்கும் தன்மைத் தீர்வுகள் {#data-availability-solutions} + +### தரவு கிடைக்கும் தன்மை மாதிரியெடுத்தல் (DAS) {#data-availability-sampling} + +தரவு கிடைக்கும் தன்மை மாதிரியெடுத்தல் (DAS) என்பது எந்தவொரு தனிப்பட்ட முனைக்கும் அதிக சிரமத்தைக் கொடுக்காமல் தரவு கிடைப்பதை நெட்வொர்க் சரிபார்க்க ஒரு வழியாகும். ஒவ்வொரு முனையும் (பங்கு வைக்காத முனைகள் உட்பட) மொத்த தரவுகளின் சில சிறிய, தோராயமாக தேர்ந்தெடுக்கப்பட்ட துணைக்குழுவைப் பதிவிறக்குகிறது. மாதிரிகளை வெற்றிகரமாகப் பதிவிறக்குவது, அனைத்துத் தரவும் கிடைக்கிறது என்பதை அதிக நம்பிக்கையுடன் உறுதிப்படுத்துகிறது. இது தரவு அழிக்கும் குறியீட்டைச் சார்ந்துள்ளது, இது தேவையற்ற தகவலுடன் கொடுக்கப்பட்ட தரவுத்தொகுப்பை விரிவுபடுத்துகிறது (இதைச் செய்யும் வழி, தரவுகளின் மீது ஒரு _பல்லுறுப்புக்கோவை_ எனப்படும் ஒரு செயல்பாட்டைப் பொருத்தி, கூடுதல் புள்ளிகளில் அந்த பல்லுறுப்புக்கோவையை மதிப்பிடுவதாகும்). தேவைப்படும்போது தேவையற்ற தரவுகளிலிருந்து அசல் தரவை மீட்டெடுக்க இது அனுமதிக்கிறது. இந்தத் தரவு உருவாக்கத்தின் விளைவு என்னவென்றால், அசல் தரவில் _ஏதேனும்_ கிடைக்கவில்லை என்றால், விரிவாக்கப்பட்ட தரவில் _பாதி_ விடுபட்டிருக்கும்! ஒவ்வொரு முனையாலும் பதிவிறக்கம் செய்யப்பட்ட தரவு மாதிரிகளின் அளவை சரிசெய்யலாம், இதன் மூலம் பாதிக்கும் குறைவான தரவு உண்மையில் கிடைத்தால், ஒவ்வொரு வாடிக்கையாளராலும் மாதிரியாக எடுக்கப்பட்ட தரவுத் துண்டுகளில் ஒன்றாவது விடுபட்டிருக்கும் என்பது _மிகவும்_ சாத்தியம். + +[முழு டான்க்ஷார்டிங்](/roadmap/danksharding/#what-is-danksharding) செயல்படுத்தப்பட்ட பிறகு, ரோலப் ஆபரேட்டர்கள் தங்கள் பரிவர்த்தனைத் தரவை கிடைக்கச் செய்வதை உறுதிசெய்ய DAS பயன்படுத்தப்படும். எல்லாத் தரவும் இருப்பதை உறுதி செய்வதற்காக, மேலே விளக்கப்பட்ட ரிடண்டன்சி திட்டத்தைப் பயன்படுத்தி, எத்தேரியம் முனைகள் பிளாப்களில் வழங்கப்பட்ட பரிவர்த்தனைத் தரவை தோராயமாக மாதிரி எடுக்கும். பாதுகாப்பான லைட் வாடிக்கையாளர்களுக்கு பிளாக் தயாரிப்பாளர்கள் தங்கள் எல்லாத் தரவுகளையும் கிடைக்கச் செய்வதை உறுதிசெய்ய இதே நுட்பத்தைப் பயன்படுத்தலாம். இதேபோல், [முன்மொழிபவர்-உருவாக்குபவர் பிரிவின்](/roadmap/pbs) கீழ், பிளாக் உருவாக்குபவர் மட்டுமே ஒரு முழு பிளாக்கையும் செயலாக்க வேண்டும் - மற்ற சரிபார்ப்பவர்கள் தரவு கிடைக்கும் தன்மை மாதிரியைப் பயன்படுத்தி சரிபார்ப்பார்கள். + +### தரவு கிடைக்கும் தன்மை குழுக்கள் {#data-availability-committees} + +தரவு கிடைக்கும் தன்மை குழுக்கள் (DACs) என்பது தரவு கிடைப்பதை வழங்கும் அல்லது சான்றளிக்கும் நம்பகமான தரப்பினராகும். DAS-க்கு பதிலாக [அல்லது அதனுடன் இணைந்து](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) DAC-களைப் பயன்படுத்தலாம். குழுக்களுடன் வரும் பாதுகாப்பு உத்தரவாதங்கள் குறிப்பிட்ட அமைப்பைப் பொறுத்தது. உதாரணமாக, லைட் முனைகளுக்கான தரவு கிடைப்பதை சான்றளிக்க எத்தேரியம் சரிபார்ப்பவர்களின் தோராயமாக மாதிரி செய்யப்பட்ட துணைக்குழுக்களைப் பயன்படுத்துகிறது. + +சில வாலிடியம்களால் DAC-களும் பயன்படுத்தப்படுகின்றன. DAC என்பது தரவுகளின் நகல்களை ஆஃப்லைனில் சேமிக்கும் முனைகளின் நம்பகமான தொகுப்பாகும். ஒரு தகராறு ஏற்பட்டால் தரவை கிடைக்கச் செய்ய DAC தேவைப்படுகிறது. கூறப்பட்ட தரவு உண்மையில் கிடைக்கிறது என்பதை நிரூபிக்க DAC-யின் உறுப்பினர்கள் ஆன்செயின் சான்றளிப்புகளையும் வெளியிடுகின்றனர். சில வாலிடியம்கள் DAC-களுக்குப் பதிலாக பங்குச் சான்று (PoS) சரிபார்ப்பவர் அமைப்பைப் பயன்படுத்துகின்றன. இங்கே, யார் வேண்டுமானாலும் ஒரு சரிபார்ப்பவராக மாறி, தரவை ஆஃப்செயினில் சேமிக்கலாம். இருப்பினும், அவர்கள் ஒரு "பத்திரத்தை" வழங்க வேண்டும், இது ஒரு ஸ்மார்ட் ஒப்பந்தத்தில் டெபாசிட் செய்யப்படுகிறது. சரிபார்ப்பவர் தரவைத் தடுத்து நிறுத்துவது போன்ற தீங்கிழைக்கும் நடத்தை நிகழ்வில், பத்திரம் குறைக்கப்படலாம். பங்குச் சான்று தரவு கிடைக்கும் தன்மை குழுக்கள் வழக்கமான DAC-களை விட கணிசமாகப் பாதுகாப்பானவை, ஏனெனில் அவை நேர்மையான நடத்தையை நேரடியாக ஊக்குவிக்கின்றன. + +## தரவு கிடைக்கும் தன்மை மற்றும் லைட் முனைகள் {#data-availability-and-light-nodes} + +[லைட் முனைகள்](/developers/docs/nodes-and-clients/light-clients) பிளாக் தரவைப் பதிவிறக்காமல் அவை பெறும் பிளாக் தலைப்புகளின் சரியான தன்மையை சரிபார்க்க வேண்டும். முழு முனைகள் செய்வது போல உள்நாட்டில் பரிவர்த்தனைகளை மீண்டும் செயல்படுத்துவதன் மூலம் பிளாக் தலைப்புகளை சுயாதீனமாக சரிபார்க்க இயலாமை இந்த லேசான தன்மைக்கான விலையாகும். + +எத்தேரியம் லைட் முனைகள் _ஒத்திசைவுக் குழுவிற்கு_ ஒதுக்கப்பட்ட 512 சரிபார்ப்பவர்களின் தோராயமான தொகுப்புகளை நம்புகின்றன. ஒத்திசைவுக் குழு ஒரு ரகசியக் குறியீட்டு கையொப்பத்தைப் பயன்படுத்தி தலைப்பில் உள்ள தரவு சரியானது என்று லைட் வாடிக்கையாளர்களுக்கு சமிக்ஞை செய்யும் ஒரு DAC ஆக செயல்படுகிறது. ஒவ்வொரு நாளும், ஒத்திசைவுக் குழு புதுப்பிக்கப்படுகிறது. ஒவ்வொரு பிளாக் தலைப்பும், _அடுத்த_ பிளாக்கில் கையொப்பமிட எந்த சரிபார்ப்பாளர்களை எதிர்பார்க்க வேண்டும் என்பது குறித்து லைட் முனைகளை எச்சரிக்கிறது, எனவே உண்மையான ஒத்திசைவுக் குழுவாக நடிக்கும் ஒரு தீங்கிழைக்கும் குழுவை நம்பி அவர்கள் ஏமாற முடியாது. + +இருப்பினும், ஒரு தாக்குபவர் எப்படியாவது ஒரு தீங்கிழைக்கும் பிளாக் தலைப்பை லைட் வாடிக்கையாளர்களுக்கு அனுப்பி, அது ஒரு நேர்மையான ஒத்திசைவுக் குழுவால் கையொப்பமிடப்பட்டது என்று அவர்களை நம்ப வைத்தால் என்ன நடக்கும்? அப்படியானால், தாக்குபவர் செல்லாத பரிவர்த்தனைகளைச் சேர்க்கலாம், மேலும் லைட் வாடிக்கையாளர் அவற்றை கண்மூடித்தனமாக ஏற்றுக்கொள்வார், ஏனெனில் அவர்கள் பிளாக் தலைப்பில் சுருக்கமாகக் கூறப்பட்ட அனைத்து நிலை மாற்றங்களையும் சுயாதீனமாகச் சரிபார்க்க மாட்டார்கள். இதிலிருந்து பாதுகாக்க, லைட் வாடிக்கையாளர் மோசடிச் சான்றுகளைப் பயன்படுத்தலாம். + +இந்த மோசடிச் சான்றுகள் செயல்படும் விதம் என்னவென்றால், ஒரு முழு முனை, நெட்வொர்க்கில் வதந்தியாகப் பரவும் ஒரு செல்லாத நிலை மாற்றத்தைக் கண்டு, முன்மொழியப்பட்ட நிலை மாற்றம் கொடுக்கப்பட்ட பரிவர்த்தனைகளின் தொகுப்பிலிருந்து ஏற்பட வாய்ப்பில்லை என்பதைக் காட்டும் ஒரு சிறிய தரவுத் துண்டை விரைவாக உருவாக்கி, அந்தத் தரவை சக கணினிகளுக்கு ஒளிபரப்ப முடியும். லைட் முனைகள் அந்த மோசடிச் சான்றுகளை எடுத்து, மோசமான பிளாக் தலைப்புகளை நிராகரிக்க அவற்றைப் பயன்படுத்தலாம், அவை முழு முனைகளைப் போலவே நேர்மையான சங்கிலியில் இருப்பதை உறுதிசெய்கின்றன. + +இது முழு முனைகள் முழுப் பரிவர்த்தனைத் தரவிற்கான அணுகலைக் கொண்டிருப்பதைச் சார்ந்துள்ளது. ஒரு மோசமான பிளாக் தலைப்பை ஒளிபரப்பி, பரிவர்த்தனைத் தரவை கிடைக்கச் செய்யத் தவறிய ஒரு தாக்குபவர், முழு முனைகளும் மோசடிச் சான்றுகளை உருவாக்குவதைத் தடுக்க முடியும். முழு முனைகளால் ஒரு மோசமான பிளாக் பற்றிய எச்சரிக்கையை சமிக்ஞை செய்ய முடியும், ஆனால் சான்றை உருவாக்குவதற்கு தரவு கிடைக்காததால், அவற்றால் தங்கள் எச்சரிக்கையைச் சான்றுடன் ஆதரிக்க முடியவில்லை! + +இந்த தரவு கிடைக்கும் தன்மைச் சிக்கலுக்கான தீர்வு DAS ஆகும். லைட் முனைகள் முழு நிலைத் தரவின் மிகச் சிறிய சீரற்ற துண்டுகளைப் பதிவிறக்கி, முழு தரவுத் தொகுப்பும் கிடைப்பதைச் சரிபார்க்க மாதிரிகளைப் பயன்படுத்துகின்றன. N சீரற்ற துண்டுகளைப் பதிவிறக்கிய பிறகு முழுத் தரவு கிடைப்பதை தவறாகக் கருதுவதற்கான உண்மையான நிகழ்தகவைக் கணக்கிடலாம் ([100 துண்டுகளுக்கு வாய்ப்பு 10^-30](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html), அதாவது, நம்பமுடியாத அளவிற்கு வாய்ப்பில்லை). + +இந்தச் சூழ்நிலையில் கூட, சில பைட்டுகளை மட்டும் தடுத்து நிறுத்தும் தாக்குதல்கள், சீரற்ற தரவுக் கோரிக்கைகளைச் செய்யும் வாடிக்கையாளர்களால் கவனிக்கப்படாமல் போகக்கூடும். முன்மொழியப்பட்ட நிலை மாற்றங்களைச் சரிபார்க்கப் பயன்படும் சிறிய விடுபட்ட தரவுத் துண்டுகளை புனரமைப்பதன் மூலம் அழித்தல் குறியீட்டு முறை இதை சரிசெய்கிறது. புனரமைக்கப்பட்ட தரவைப் பயன்படுத்தி ஒரு மோசடிச் சான்றை உருவாக்கலாம், இது லைட் முனைகள் மோசமான தலைப்புகளை ஏற்றுக்கொள்வதைத் தடுக்கிறது. + +**குறிப்பு:** பங்குச் சான்று எத்தேரியம் லைட் வாடிக்கையாளர்களுக்காக DAS மற்றும் மோசடிச் சான்றுகள் இன்னும் செயல்படுத்தப்படவில்லை, ஆனால் அவை செயல்திட்டத்தில் உள்ளன, பெரும்பாலும் ZK-SNARK அடிப்படையிலான சான்றுகளின் வடிவத்தை எடுக்கின்றன. இன்றைய லைட் வாடிக்கையாளர்கள் ஒரு வகையான DAC-ஐ நம்பியுள்ளனர்: அவர்கள் ஒத்திசைவுக் குழுவின் அடையாளங்களைச் சரிபார்த்து, பின்னர் அவர்கள் பெறும் கையொப்பமிடப்பட்ட பிளாக் தலைப்புகளை நம்புகிறார்கள். + +## தரவு கிடைக்கும் தன்மை மற்றும் லேயர் 2 ரோலப்கள் {#data-availability-and-layer-2-rollups} + +[லேயர் 2 அளவிடுதல் தீர்வுகள்](/layer-2/) ஆன [ரோலப்கள்](/glossary/#rollups) போன்றவை, பரிவர்த்தனைகளை ஆஃப்செயினில் செயலாக்குவதன் மூலம் பரிவர்த்தனைச் செலவுகளைக் குறைத்து எத்தேரியத்தின் செயல்திறனை அதிகரிக்கின்றன. ரோலப் பரிவர்த்தனைகள் சுருக்கப்பட்டு எத்தேரியத்தில் தொகுப்புகளாக வெளியிடப்படுகின்றன. தொகுப்புகள் எத்தேரியத்தில் ஒரு பரிவர்த்தனையில் ஆயிரக்கணக்கான தனிப்பட்ட ஆஃப்செயின் பரிவர்த்தனைகளைக் குறிக்கின்றன. இது அடிப்படை அடுக்கில் நெரிசலைக் குறைக்கிறது மற்றும் பயனர்களுக்கான கட்டணங்களைக் குறைக்கிறது. + +இருப்பினும், முன்மொழியப்பட்ட நிலை மாற்றத்தை சுயாதீனமாகச் சரிபார்த்து, அனைத்துத் தனிப்பட்ட ஆஃப்செயின் பரிவர்த்தனைகளையும் பயன்படுத்துவதன் விளைவுதான் என்பதை உறுதிப்படுத்த முடிந்தால் மட்டுமே, எத்தேரியத்தில் வெளியிடப்பட்ட 'சுருக்க' பரிவர்த்தனைகளை நம்ப முடியும். இந்தச் சரிபார்ப்பிற்காக ரோலப் ஆபரேட்டர்கள் பரிவர்த்தனைத் தரவை கிடைக்கச் செய்யவில்லை என்றால், அவர்கள் தவறான தரவை எத்தேரியத்திற்கு அனுப்பலாம். + +[ஆப்டிமிஸ்டிக் ரோலப்கள்](/developers/docs/scaling/optimistic-rollups/) சுருக்கப்பட்ட பரிவர்த்தனைத் தரவை எத்தேரியத்திற்கு அனுப்பி, சுயாதீன சரிபார்ப்பாளர்கள் தரவைச் சரிபார்க்க அனுமதிக்க சிறிது நேரம் (பொதுவாக 7 நாட்கள்) காத்திருக்கின்றன. யாராவது ஒரு சிக்கலைக் கண்டறிந்தால், அவர்கள் ஒரு மோசடிச் சான்றை உருவாக்கி, அதைப் பயன்படுத்தி ரோலப்பைச் சவால் செய்யலாம். இது சங்கிலியை பின்னுக்குத் தள்ளி, செல்லாத பிளாக்கைத் தவிர்க்கச் செய்யும். தரவு கிடைத்தால் மட்டுமே இது சாத்தியம். தற்போது, ஆப்டிமிஸ்டிக் ரோலப்கள் பரிவர்த்தனைத் தரவை L1-க்கு அனுப்ப இரண்டு வழிகள் உள்ளன. சில ரோலப்கள் நிரந்தரமாக ஆன்செயினில் இருக்கும் `CALLDATA` ஆக தரவை நிரந்தரமாகக் கிடைக்கச் செய்கின்றன. EIP-4844-ஐச் செயல்படுத்தியவுடன், சில ரோலப்கள் தங்கள் பரிவர்த்தனைத் தரவை மலிவான பிளாப் சேமிப்பகத்திற்குப் பதிலாக அனுப்புகின்றன. இது நிரந்தர சேமிப்பகம் அல்ல. எத்தேரியம் லேயர்-1-லிருந்து தரவு நீக்கப்படுவதற்கு முன்பு ~18 நாட்களுக்குள் சுயாதீன சரிபார்ப்பாளர்கள் பிளாப்களை வினவி தங்கள் சவால்களை எழுப்ப வேண்டும். அந்த குறுகிய நிலையான சாளரத்திற்கு மட்டுமே எத்தேரியம் நெறிமுறையால் தரவு கிடைக்கும் தன்மைக்கு உத்தரவாதம் அளிக்கப்படுகிறது. அதன் பிறகு, இது எத்தேரியம் சூழலமைப்பில் உள்ள மற்ற நிறுவனங்களின் பொறுப்பாகிறது. எந்த முனையும் DAS-ஐப் பயன்படுத்தி தரவு கிடைப்பதை சரிபார்க்கலாம், அதாவது, பிளாப் தரவின் சிறிய, சீரற்ற மாதிரிகளைப் பதிவிறக்குவதன் மூலம். + +[பூஜ்ஜிய-அறிவு (ZK) ரோலப்களுக்கு](/developers/docs/scaling/zk-rollups) பரிவர்த்தனைத் தரவை அனுப்பத் தேவையில்லை, ஏனெனில் [பூஜ்ஜிய-அறிவு செல்லுபடியாகும் தன்மைச் சான்றுகள்](/glossary/#zk-proof) நிலை மாற்றங்களின் சரியானத்தன்மைக்கு உத்தரவாதம் அளிக்கின்றன. இருப்பினும், தரவு கிடைப்பது இன்னும் ஒரு சிக்கலாகவே உள்ளது, ஏனெனில் அதன் நிலைத் தரவை அணுகாமல் ZK-ரோலப்பின் செயல்பாட்டிற்கு (அல்லது அதனுடன் தொடர்புகொள்வதற்கு) நாங்கள் உத்தரவாதம் அளிக்க முடியாது. உதாரணமாக, ஒரு ஆபரேட்டர் ரோலப்பின் நிலை குறித்த விவரங்களைத் தடுத்து நிறுத்தினால், பயனர்கள் தங்கள் இருப்புகளை அறிய முடியாது. மேலும், புதிதாகச் சேர்க்கப்பட்ட ஒரு பிளாக்கில் உள்ள தகவலைப் பயன்படுத்தி அவர்களால் நிலை புதுப்பிப்புகளைச் செய்ய முடியாது. + +## தரவு கிடைக்கும் தன்மை எதிர் தரவு மீட்டெடுப்பு {#data-availability-vs-data-retrievability} + +தரவு கிடைக்கும் தன்மை என்பது தரவு மீட்டெடுப்பிலிருந்து வேறுபட்டது. தரவு கிடைக்கும் தன்மை என்பது, ஒரு குறிப்பிட்ட பிளாக்குடன் தொடர்புடைய முழுப் பரிவர்த்தனைகளின் தொகுப்பை முழு முனைகளாலும் அணுகி சரிபார்க்க முடிந்தது என்பதற்கான உத்தரவாதமாகும். தரவு எப்போதும் அணுகக்கூடியதாக இருக்கும் என்று இது அவசியமில்லை. + +தரவு மீட்டெடுப்பு என்பது பிளாக்செயினிலிருந்து _வரலாற்றுத் தகவலை_ மீட்டெடுக்கும் முனைகளின் திறன் ஆகும். புதிய பிளாக்குகளை சரிபார்க்க இந்த வரலாற்றுத் தரவு தேவையில்லை, இது ஜெனிசிஸ் பிளாக்கிலிருந்து முழு முனைகளை ஒத்திசைக்க அல்லது குறிப்பிட்ட வரலாற்று கோரிக்கைகளை வழங்க மட்டுமே தேவைப்படுகிறது. + +முக்கிய எத்தேரியம் நெறிமுறை முதன்மையாக தரவு கிடைப்பது பற்றியே அக்கறை கொண்டுள்ளது, தரவு மீட்டெடுப்பு அல்ல. மூன்றாம் தரப்பினரால் இயக்கப்படும் ஒரு சிறிய எண்ணிக்கையிலான காப்பக முனைகளால் தரவு மீட்டெடுப்பை வழங்கலாம், அல்லது [போர்டல் நெட்வொர்க்](https://www.ethportal.net/) போன்ற பரவலாக்கப்பட்ட கோப்பு சேமிப்பகத்தைப் பயன்படுத்தி நெட்வொர்க்கில் விநியோகிக்கப்படலாம். + +## மேலும் வாசிக்க {#further-reading} + +- [தரவு கிடைக்கும் தன்மை என்றால் என்ன?](https://medium.com/blockchain-capital-blog/wtf-is-data-availability-80c2c95ded0f) +- [தரவு கிடைக்கும் தன்மை என்றால் என்ன?](https://coinmarketcap.com/academy/article/what-is-data-availability) +- [தரவு கிடைக்கும் தன்மை சரிபார்ப்புகள் பற்றிய ஒரு அறிமுகம்](https://dankradfeist.de/ethereum/2019/12/20/data-availability-checks.html) +- [ஷார்டிங் + DAS முன்மொழிவின் ஒரு விளக்கம்](https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling) +- [தரவு கிடைக்கும் தன்மை மற்றும் அழித்தல் குறியீட்டு முறை பற்றிய ஒரு குறிப்பு](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) +- [தரவு கிடைக்கும் தன்மை குழுக்கள்.](https://medium.com/starkware/data-availability-e5564c416424) +- [பங்குச் சான்று தரவு கிடைக்கும் தன்மை குழுக்கள்.](https://blog.matter-labs.io/zkporter-a-breakthrough-in-l2-scaling-ed5e48842fbf) +- [தரவு மீட்டெடுப்புச் சிக்கலுக்கான தீர்வுகள்](https://notes.ethereum.org/@vbuterin/data_sharding_roadmap#Who-would-store-historical-data-under-sharding) +- [தரவு கிடைக்கும் தன்மை அல்லது: ரோலப்கள் கவலைப்படுவதை நிறுத்தி எத்தேரியத்தை நேசிக்கக் கற்றுக்கொண்டது எப்படி](https://web.archive.org/web/20250515194659/https://web.archive.org/web/20241108192208/https://research.2077.xyz/data-availability-or-how-rollups-learned-to-stop-worrying-and-love-ethereum) +- [EIP-7623: கால்டேட்டா செலவை அதிகரித்தல்](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/ta/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/ta/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..08c61853938 --- /dev/null +++ b/public/content/translations/ta/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: "தரவு கட்டமைப்புகள் மற்றும் குறியாக்கம்" +description: "Ethereum மிக அதிக அளவு தரவுகளை (data) உருவாக்குகிறது, சேமிக்கிறது மற்றும் பரிமாற்றுகிறது." +lang: ta +sidebarDepth: 2 +--- + +Ethereum மிக அதிக அளவு தரவுகளை (data) உருவாக்குகிறது, சேமிக்கிறது மற்றும் பரிமாற்றுகிறது. இந்தத் தரவு, ஒப்பீட்டளவில் சாதாரணமான நுகர்வோர் தர வன்பொருளில் எவரும் [ஒரு முனையை இயக்க](/run-a-node/) அனுமதிக்கும் வகையில், தரப்படுத்தப்பட்ட மற்றும் நினைவகத் திறன்மிக்க வழிகளில் வடிவமைக்கப்பட வேண்டும். இதனைச் செய்ய, Ethereum stack-இல் பல குறிப்பிட்ட data structures பயன்படுத்தப்படுகின்றன. + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +நீங்கள் Ethereum மற்றும் [கிளையன்ட் மென்பொருள்](/developers/docs/nodes-and-clients/) ஆகியவற்றின் அடிப்படைகளைப் புரிந்து கொள்ள வேண்டும். நெட்வொர்க்கிங் அடுக்கு மற்றும் [Ethereum வெள்ளை அறிக்கை](/whitepaper/) பற்றிய பரிச்சயம் பரிந்துரைக்கப்படுகிறது. + +## தரவுக் கட்டமைப்புகள் {#data-structures} + +### Patricia merkle tries {#patricia-merkle-tries} + +Patricia Merkle Tries என்பது key-value pairs-ஐ ஒரு deterministic மற்றும் cryptographically authenticated trie-ஆக குறியாக்கும் (encode) அமைப்புகள். இவை Ethereum execution layer முழுவதும் பரவலாக (extensively) பயன்படுத்தப்படுகின்றன. + +[Patricia Merkle Tries பற்றி மேலும்](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### Recursive Length Prefix {#recursive-length-prefix} + +Recursive Length Prefix (RLP) என்பது Ethereum execution layer முழுவதும் பரவலாக பயன்படுத்தப்படும் ஒரு serialization method ஆகும். + +[RLP பற்றி மேலும்](/developers/docs/data-structures-and-encoding/rlp) + +### Simple Serialize {#simple-serialize} + +Simple Serialize (SSZ) என்பது Ethereum consensus layer-இல் பிரதான (dominant) serialization format ஆகும். இதன் முக்கிய காரணம், இது merkelization-க்கு ஏற்றதாக (compatible) இருப்பது. + +[SSZ பற்றி மேலும்](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/ta/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/ta/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md new file mode 100644 index 00000000000..7c7f390f811 --- /dev/null +++ b/public/content/translations/ta/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -0,0 +1,280 @@ +--- +title: "மெர்கிள் பேட்ரிசியா டிரை" +description: "மெர்கிள் பேட்ரிசியா டிரைக்கான அறிமுகம்." +lang: ta +sidebarDepth: 2 +--- + +எதிரியத்தின் நிலை (எல்லா கணக்குகள், இருப்புகள் மற்றும் ஸ்மார்ட் ஒப்பந்தங்களை உள்ளடக்கிய மொத்த நிலை) பொதுவாகக் கணினி அறிவியலில் மெர்கிள் மரம் எனப்படும் தரவுத் அமைப்பின் ஒரு சிறப்பு பதிப்பில் குறியாக்கமாக உள்ளது. இந்த அமைப்பு குறியாக்கவியலில் பல பயன்பாடுகளுக்கு பயனுள்ளதாக இருக்கிறது, ஏனெனில் இது மரத்தில் சிக்கியுள்ள அனைத்து தனிப்பட்ட தரவுத் துண்டுகளுக்கும் இடையில் சரிபார்க்கக்கூடிய உறவை உருவாக்குகிறது, இதன் விளைவாக தரவைப் பற்றிய விஷயங்களை நிரூபிக்கப் பயன்படுத்தக்கூடிய ஒற்றை **ரூட்** மதிப்பு கிடைக்கிறது. + +எத்தீரியத்தின் தரவுக் கட்டமைப்பு ஒரு 'மாற்றியமைக்கப்பட்ட மெர்கிள்-பேட்ரிசியா டிரை' ஆகும், இது PATRICIA (Practical Algorithm To Retrieve Information Coded in Alphanumeric) என்பதன் சில அம்சங்களைப் பெறுவதால் அவ்வாறு பெயரிடப்பட்டது, மேலும் இது எத்தீரியம் நிலையை உருவாக்கும் உருப்படிகளைத் திறமையாக மீட்டெடுப்பதற்காக வடிவமைக்கப்பட்டுள்ளது. + +ஒரு மெர்கிள்-பேட்ரிசியா டிரை தீர்மானகரமானது மற்றும் குறியாக்கவியல் ரீதியாக சரிபார்க்கக்கூடியது: ஒரு நிலை ரூட்டை உருவாக்குவதற்கான ஒரே வழி, நிலையின் ஒவ்வொரு தனிப்பட்ட பகுதியிலிருந்தும் அதைக் கணக்கிடுவதாகும், மேலும் ஒரே மாதிரியான இரண்டு நிலைகள் ரூட் ஹாஷ் மற்றும் அதற்கு வழிவகுத்த ஹாஷ்களை ஒப்பிடுவதன் மூலம் எளிதாக நிரூபிக்கப்படலாம் (_ஒரு மெர்க்கிள் ஆதாரம்_). மாறாக, ஒரே ரூட் ஹேஷ் உடைய இரண்டு மாறுபட்ட நிலைகளை உருவாக்க முடியாது, மேலும் மாறுபட்ட மதிப்புகளைக் கொண்ட நிலையை மாற்ற எந்த முயற்சியையும் செய்யும்போது, ஒரு மாறுபட்ட நிலை ரூட் ஹேஷ் உருவாகும். கோட்பாட்டளவில், இந்த அமைப்பு செருகல்கள், தேடல்கள் மற்றும் நீக்கல்களுக்கு `O(log(n))` செயல்திறனின் 'புனித கிண்ணத்தை' வழங்குகிறது. + +சமீபத்திய எதிர்காலத்தில், எத்தீரியம் ஒரு [Verkle Tree](/roadmap/verkle-trees) அமைப்புக்கு இடம்பெயரத் திட்டமிட்டுள்ளது, இது எதிர்கால நெறிமுறை மேம்பாடுகளுக்கு பல புதிய சாத்தியங்களைத் திறக்கும். + +## முன்னேற்றக் கட்டுரை {#prerequisites} + +இந்தப் பக்கத்தை நன்கு புரிந்துகொள்ள, [ஹாஷ்கள்](https://en.wikipedia.org/wiki/Hash_function), [மெர்க்கிள் மரங்கள்](https://en.wikipedia.org/wiki/Merkle_tree), [டிரைகள்](https://en.wikipedia.org/wiki/Trie) மற்றும் [வரிசைப்படுத்தல்](https://en.wikipedia.org/wiki/Serialization) பற்றிய அடிப்படை அறிவு இருப்பது உதவியாக இருக்கும். இந்தக் கட்டுரை ஒரு அடிப்படை [ரேடிக்ஸ் மரத்தின்](https://en.wikipedia.org/wiki/Radix_tree) விளக்கத்துடன் தொடங்குகிறது, பின்னர் எத்தீரியத்தின் மேம்படுத்தப்பட்ட தரவுக் கட்டமைப்பிற்குத் தேவையான மாற்றங்களை படிப்படியாக அறிமுகப்படுத்துகிறது. + +## அடிப்படை ரேடிக்ஸ் டிரைகள் {#basic-radix-tries} + +ஒரு அடிப்படை ரேடிக்ஸ் டிரையில், ஒவ்வொரு நொடும் பின்வருமாறு இருக்கும்: + +``` + [i_0, i_1 ... i_n, value] +``` + +`i_0 ...` `i_n` அகரவரிசையின் குறியீடுகளைக் குறிக்கின்றன (பெரும்பாலும் பைனரி அல்லது ஹெக்ஸ்), `value` என்பது முனையில் உள்ள இறுதி மதிப்பாகும், மேலும் `i_0, i_1 ...` இல் உள்ள மதிப்புகள் `i_n` ஸ்லாட்கள் `NULL` ஆகவோ அல்லது மற்ற முனைகளுக்கான சுட்டிகளாகவோ (நம் விஷயத்தில், ஹாஷ்கள்) உள்ளன. இது ஒரு அடிப்படை `(key, value)` சேமிப்பகத்தை உருவாக்குகிறது. + +நீங்கள் ஒரு ரேடிக்ஸ் மர தரவுச் அமைப்பைப் பயன்படுத்தி முக்கிய மதிப்புகள் குழுவில் ஒரு வரிசையை நிலையாகக் காக்க விரும்பினால். ட்ரையில் `dog` என்ற கீக்கு தற்போது மேப் செய்யப்பட்டுள்ள மதிப்பைக் கண்டறிய, நீங்கள் முதலில் `dog` ஐ அகரவரிசை எழுத்துக்களாக மாற்றுவீர்கள் (`64 6f 67` கொடுக்கும்), பின்னர் நீங்கள் மதிப்பைக் கண்டுபிடிக்கும் வரை அந்தப் பாதையைப் பின்பற்றி டிரையில் இறங்குவீர்கள். அதாவது, நீங்கள் முதலில் பிளாட் முக்கியம்/மதிப்பு தரவுத்தொகுப்பில் ரூட் ஹேஷை தேடுகிறீர்கள், இது டிரையின் ரூட் நொடியாகக் குறிக்கப்படுகிறது. இது மற்ற நொடிகளைப் புள்ளிகள் வகையில் உள்ள முக்கியங்களிலிருந்து அமைக்கப்படுகிறது. நீங்கள் குறியீட்டெண் `6` இல் உள்ள மதிப்பை ஒரு கீயாகப் பயன்படுத்தி, ஒரு நிலை கீழே உள்ள முனையைப் பெற, பிளாட் கீ/மதிப்பு டிபி-யில் அதைத் தேடுவீர்கள். பின்னர் அடுத்த மதிப்பைப் பார்க்க குறியீட்டெண் `4` ஐத் தேர்ந்தெடுக்கவும், பிறகு குறியீட்டெண் `6` ஐத் தேர்ந்தெடுக்கவும், இப்படியே தொடரவும், நீங்கள் பாதையைப் பின்பற்றியவுடன்: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`, நீங்கள் முனையின் மதிப்பைத் தேடி முடிவைத் தருவீர்கள். + +"டிரை" மற்றும் அடிப்படை பிளாட் முக்கியம்/மதிப்பு 'தரவுத்தொகுப்பில்' ஒன்றை தேடும் இடையே ஒரு வித்தியாசம் உள்ளது. இரண்டும் முக்கியம்/மதிப்பு அமைப்புகளை வரையறுக்கின்றன, ஆனால் அடிப்படை தரவுத்தொகுப்பு ஒரு பாரம்பரிய 1 படியாக முக்கியத்தை தேட முடியும். ஒரு முக்கியத்தை டிரையில் தேடுவது பின்வரும் மதிப்பை அடைய பல அடிப்படை தரவுத்தொகுப்பு தேடுதல்களை தேவைப்படும். தெளிவின்மையை நீக்க, பின்னதை ஒரு `path` என்று குறிப்பிடுவோம். + +ரேடிக்ஸ் டிரைகளுக்கான புதுப்பிப்பு மற்றும் நீக்கம் செயல்பாடுகளைப் பின்வருமாறு வரையறுக்கலாம்: + +```python + def update(node_hash, path, value): + curnode = db.get(node_hash) if node_hash 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_hash, path): + if node_hash is NULL: + return NULL + else: + curnode = db.get(node_hash) + 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) +``` + +"மர்கிள்" ரேடிக்ஸ் மரம் முடிச்சுகளைத் தானாக உருவாக்கப்பட்ட கிரிப்டோகிராஃபிக் ஹாஷ் டைக்ஸ்ட் களைப் பயன்படுத்தி கட்டப்படுகிறது. இந்த உள்ளடக்க-முகவரியிடல் (கீ/மதிப்பு டிபி `key == keccak256(rlp(value))` இல்) சேமிக்கப்பட்ட தரவின் குறியாக்கவியல் ஒருமைப்பாட்டு உத்தரவாதத்தை வழங்குகிறது. ஒரு குறிப்பிட்ட டிரையின் ரூட் ஹாஷ் பொதுவாக தெரிந்தால், அதற்கான அடிப்படை கன்றிய மூலத்தை அணுகும் யார் யாரும் ஒரு குறிப்பிட்ட பாதையில் ஒரு குறிப்பிட்ட மதிப்பை அடக்கியுள்ள டிரை உள்ளதாக ஒரு சான்று உருவாக்கலாம், இது குறிப்பிட்ட மதிப்பை மரத்தின் ரூட் க்கு இணைக்கும் ஒவ்வொரு முடிச்சின் ஹாஷ்களை வழங்குவதன் மூலம் சான்றளிக்க முடியும். + +ஒரு தாக்குபவர் இல்லாத ஒரு `(path, value)` ஜோடிக்கு ஒரு ஆதாரத்தை வழங்குவது சாத்தியமற்றது, ஏனெனில் ரூட் ஹாஷ் இறுதியில் அதன் கீழே உள்ள அனைத்து ஹாஷ்களையும் அடிப்படையாகக் கொண்டது. எந்த அடிப்படை மாற்றமும் ரூட் ஹாஷைப் மாற்றும். ஹாஷ் என்பது தரவின் அமைப்பு தகவலின் அழுத்தமான பிரதிநிதியாகக் குறித்துக் கொள்ளலாம், இது ஹாஷிங் செயல்பாட்டின் முன்-சித்திரம் பாதுகாப்பால் பாதுகாக்கப்படுகிறது. + +ஒரு ரேடிக்ஸ் மரத்தின் அணு அலகை (எ.கா., ஒரு ஒற்றை ஹெக்ஸ் எழுத்து, அல்லது 4 பிட் பைனரி எண்) "நிபிள்" என்று குறிப்பிடுவோம். மேலே விவரிக்கப்பட்டுள்ளபடி, ஒரு நேரத்தில் ஒரு நிபிள் என்ற கணக்கில் ஒரு பாதையில் பயணிக்கும்போது, முனைகள் அதிகபட்சமாக 16 கிளைகளைக் குறிப்பிடலாம் ஆனால் ஒரு `value` உறுப்பை உள்ளடக்கியிருக்கும். அதனால், நாம் இவற்றைப் 17 நீளக் கொண்ட முறைமையாகக் குறிப்பிடுகிறோம். இவை 17-எலெமென்ட் முறைமைகளை "உளர்வுப் முடிச்சுகள்" என்று அழைப்போம். + +## மெர்கிள் பேட்ரிசியா டிரை {#merkle-patricia-trees} + +ரேடிக்ஸ் டிரைகளுக்கு ஒரு பெரிய கட்டுப்பாடு உள்ளது: அவை திகட்டிக்கொள்ளப்பட்டவை. எத்தீரியத்தில் உள்ளது போல, பாதை 64 எழுத்துகள் நீளமாக இருக்கும் ஒரு `(path, value)` பிணைப்பை நீங்கள் சேமிக்க விரும்பினால் (`bytes32` இல் உள்ள நிபிள்களின் எண்ணிக்கை), ஒரு எழுத்துக்கு ஒரு நிலை சேமிக்க ஒரு கிலோபைட்டிற்கும் அதிகமான கூடுதல் இடம் தேவைப்படும், மேலும் ஒவ்வொரு தேடலும் அல்லது நீக்கமும் முழு 64 படிகளையும் எடுக்கும். அடுத்ததாக அறிமுகம் செய்யப்படும் பத்திரிசியா டிரை இந்தச் சிக்கலைத் தீர்க்கிறது. + +### மேம்படுத்தல் {#optimization} + +மர்கிள் பத்திரிசியா டிரைவில் ஒரு மூடு பின்வருபவையாக இருக்கும்: + +1. `NULL` (வெற்றுச் சரமாக குறிப்பிடப்படுகிறது) +2. `branch` ஒரு 17-உருப்படி முனை `[ v0 ...` `v15, vt ]` +3. `leaf` ஒரு 2-உருப்படி முனை `[ encodedPath, value ]` +4. `extension` ஒரு 2-உருப்படி முனை `[ encodedPath, key ]` + +64 எழுத்துகளைக் கொண்ட பாதைகளுடன், முதல் சில அடுக்குகளைச் சுலபமாகக் கடக்கும்போது, நீங்கள் ஒரு மூட்டைச் சந்திக்க வேண்டியிருக்கும், அதில் குறைந்தபட்சமாக ஒரு பகுதிவரை வேறுபாடுகள் இல்லாமல் இருக்கும். பாதையில் 15 சிதறிய `NULL` முனைகள் வரை உருவாக்க வேண்டியிருப்பதைத் தவிர்க்க, `[ encodedPath, key ]` வடிவத்தில் ஒரு `extension` முனையை அமைப்பதன் மூலம் இறங்குவதைக் குறுக்குவழியாக்குகிறோம், இங்கு `encodedPath` என்பது முன்னோக்கிச் செல்ல வேண்டிய "பகுதிப் பாதையைக்" கொண்டுள்ளது (கீழே விவரிக்கப்பட்டுள்ள கச்சிதமான குறியாக்கத்தைப் பயன்படுத்தி), மற்றும் `key` என்பது அடுத்த டிபி தேடலுக்கானது. + +ஒரு `leaf` முனைக்கு, `encodedPath`-இன் முதல் நிபிளில் ஒரு கொடியால் குறிக்கப்படலாம், பாதை முந்தைய முனையின் அனைத்து பாதை துண்டுகளையும் குறியாக்குகிறது, மேலும் நாம் நேரடியாக `value`-ஐ தேடலாம். + +மேலே குறிப்பிடப்பட்ட சரிசெய்தல், ஆனால், குழப்பத்தை உருவாக்குகிறது. + +நிபிள்களில் பாதைகளைக் கடக்கும்போது, நாம் கடப்பதற்கு ஒற்றைப்படை எண்ணிக்கையிலான நிபிள்களுடன் முடிவடையலாம், ஆனால் எல்லா தரவுகளும் `bytes` வடிவத்தில் சேமிக்கப்படுகின்றன. உதாரணமாக, நிபிள் `1` மற்றும் நிபிள்கள் `01` ஆகியவற்றுக்கு இடையில் வேறுபடுத்துவது சாத்தியமில்லை (இரண்டும் `<01>` என சேமிக்கப்பட வேண்டும்). ஆடி நீளத்தை குறிப்பதற்காக, பகுதி பாதை ஒரு கொடுப்புக்குறியுடன் முன்னுருவிக்கப்பட்டது. + +### விவரக்குறிப்பு: விருப்ப முனையத்துடன் கூடிய ஹெக்ஸ் வரிசையின் கச்சிதமான குறியாக்கம் {#specification} + +மேலே விவரிக்கப்பட்டுள்ளபடி _ஒற்றைப்படை vs. இரட்டைப்படை மீதமுள்ள பகுதிப் பாதை நீளம்_ மற்றும் _இலை vs. நீட்டிப்பு முனை_ ஆகிய இரண்டின் கொடியிடலும் எந்தவொரு 2-உருப்படி முனையின் பகுதிப் பாதையின் முதல் நிபிளில் உள்ளது. இவை பின்வரும் விளைவுகளை அளிக்கின்றன: + +| ஹெக்ஸ் எழுத்து | பிட்கள் | முனை வகை பகுதி | பாதை நீளம் | +| -------------- | ------- | ------------------------------------ | ---------- | +| 0 | 0000 | நீட்டிப்பு | இரட்டை | +| 1 | 0001 | நீட்டிப்பு | ஒற்றை | +| 2 | 0010 | முடிவடையும் (இலை) | இரட்டை | +| 3 | 0011 | முடிவடையும் (இலை) | ஒற்றை | + +மீதமுள்ள பாதை நீளம் இரட்டைப்படையாக இருந்தால் (`0` அல்லது `2`), மற்றொரு `0` "பேடிங்" நிபிள் எப்போதும் தொடரும். + +```python + 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 + # ஹெக்ஸ்அரே இப்போது ஒரு இரட்டை நீளத்தைக் கொண்டுள்ளது, அதன் முதல் நிபிள் கொடிகளாகும். + o = "" + for i in range(0, len(hexarray), 2): + o += chr(16 * hexarray[i] + hexarray[i + 1]) + return o +``` + +எடுத்துக்காட்டுகள்: + +```python + > [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' +``` + +மெர்கிள் பேட்ரிசியா டிரையில் ஒரு முனையைப் பெறுவதற்கான நீட்டிக்கப்பட்ட குறியீடு இங்கே: + +```python + def get_helper(node_hash, path): + if path == []: + return node_hash + if node_hash == "": + return "" + curnode = rlp.decode(node_hash if len(node_hash) < 32 else db.get(node_hash)) + 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_hash, 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_hash, path2) +``` + +### எடுத்துக்காட்டு டிரை {#example-trie} + +`('do', 'verb')`, `('dog', 'puppy')`, `('doge', 'coins')`, `('horse', 'stallion')` ஆகிய நான்கு பாதை/மதிப்பு ஜோடிகளைக் கொண்ட ஒரு டிரை வேண்டும் என்று வைத்துக்கொள்வோம். + +முதலில், பாதைகள் மற்றும் மதிப்புகள் இரண்டையும் `bytes` ஆக மாற்றுகிறோம். கீழே, _பாதைகளுக்கான_ உண்மையான பைட் பிரதிநிதித்துவங்கள் `<>` ஆல் குறிக்கப்படுகின்றன, இருப்பினும் _மதிப்புகள்_ இன்னும் எளிதாகப் புரிந்துகொள்வதற்காக `''` ஆல் குறிக்கப்படும் சரங்களாகக் காட்டப்படுகின்றன (அவையும் உண்மையில் `bytes` ஆக இருக்கும்): + +``` + <64 6f> : 'verb' + <64 6f 67> : 'puppy' + <64 6f 67 65> : 'coins' + <68 6f 72 73 65> : 'stallion' +``` + +இப்போ நாம உருவாக்கும் trie-க்கு underlying DB-யில் இருக்கும் key/value ஜோடிகள்: + +``` + rootHash: [ <16>, hashA ] + hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ] + hashB: [ <00 6f>, hashC ] + hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ] + hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] +``` + +ஒரு முனை மற்றொரு முனைக்குள் குறிப்பிடப்படும்போது, `len(rlp.encode(node)) >= 32` ஆக இருந்தால் `keccak256(rlp.encode(node))` சேர்க்கப்படும், இல்லையெனில் `node` சேர்க்கப்படும். இங்கு `rlp.encode` என்பது [RLP](/developers/docs/data-structures-and-encoding/rlp) குறியாக்கச் செயல்பாடாகும். + +ஒரு டிரையைப் புதுப்பிக்கும்போது, புதிதாக உருவாக்கப்பட்ட முனையின் நீளம் >= 32 ஆக இருந்தால், `(keccak256(x), x)` என்ற கீ/மதிப்பு ஜோடியை ஒரு நிலையான தேடல் அட்டவணையில் சேமிக்க வேண்டும் என்பதை நினைவில் கொள்க. நீளம் < 32 இருந்தா எதுவும் சேமிக்க வேண்டியதில்லை, ஏன்னா f(x) = x reversible. + +## எத்தீரியத்தில் டிரைகள் {#tries-in-ethereum} + +Ethereum execution layer-ல் இருக்கும் எல்லா Merkle tries-உம் Merkle Patricia Trie (Mpt). + +Block header-ல 3 roots இருக்கும். + +1. stateRoot +2. transactionsRoot +3. receiptsRoot + +### நிலை டிரை {#state-trie} + +Ethereum-ல் ஒரு global state trie இருக்கு. ஒவ்வொரு block process ஆனப்போ அத update ஆகும். அதில், ஒரு `path` எப்போதும்: `keccak256(ethereumAddress)` மற்றும் ஒரு `value` எப்போதும்: `rlp(ethereumAccount)`. குறிப்பாக, ஒரு எத்தீரியம் `account` என்பது `[nonce,balance,storageRoot,codeHash]` கொண்ட 4-உருப்படி வரிசையாகும். இந்த `storageRoot` மற்றொரு பேட்ரிசியா டிரையின் ரூட் என்பதை இந்த கட்டத்தில் குறிப்பிடுவது முக்கியம்: + +### சேமிப்பக டிரை {#storage-trie} + +சேமிப்பக டிரை என்பது _அனைத்து_ ஒப்பந்தத் தரவுகளும் இருக்கும் இடமாகும். ஒவ்வொரு கணக்கிற்கும் தனித்தனி storage trie உண்டு. ஒரு குறிப்பிட்ட முகவரியில் (address) உள்ள storage இடங்களில் உள்ள மதிப்புகளை பெற, அந்த முகவரி, அந்த storage-இல் சேமிக்கப்பட்டுள்ள தரவின் integer நிலை (position), மற்றும் block ID ஆகியவை தேவையாகும். இவை JSON-RPC ஏபிஐ-ல் வரையறுக்கப்பட்ட `eth_getStorageAt`-க்கு தருமதிப்புகளாக அனுப்பப்படலாம், எ.கா., `0x295a70b2de5e3953354a6a8344e616ed314d7251` முகவரிக்கான சேமிப்பக ஸ்லாட் 0-இல் உள்ள தரவை மீட்டெடுக்க: + +```bash +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"} + +``` + +Storage-இல் உள்ள பிற உறுப்புகளை (elements) பெற சிறிது சிக்கலாக இருக்கும், ஏனெனில் storage trie-இல் உள்ள நிலை (position) முதலில் கணக்கிடப்பட வேண்டும். முகவரி மற்றும் சேமிப்பக நிலை ஆகியவற்றின் `keccak256` ஹாஷாக நிலை கணக்கிடப்படுகிறது, இரண்டும் 32 பைட்டுகள் நீளத்திற்கு பூஜ்ஜியங்களுடன் இடது-பேட் செய்யப்படுகின்றன. உதாரணமாக, `0x391694e7e0b0cce554cb130d723a9d27458f9298` முகவரிக்கான சேமிப்பக ஸ்லாட் 1-இல் உள்ள தரவிற்கான நிலை: + +```python +keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) +``` + +Geth console-இல் இதை கணக்கிடுவது: + +``` +// 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 +} +``` + +எனவே, `path` என்பது `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)`. இதைப் பயன்படுத்தி storage trie-இல் இருந்து தரவை பெறலாம்: + +```bash +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"} +``` + +குறிப்பு: இது ஒரு ஒப்பந்தக் கணக்காக இல்லாவிட்டால், ஒரு எத்தீரியம் கணக்கிற்கான `storageRoot` இயல்பாகவே காலியாக இருக்கும். + +### பரிவர்த்தனைகள் டிரை {#transaction-trie} + +ஒவ்வொரு பிளாக்கிற்கும் ஒரு தனி பரிவர்த்தனைகள் டிரை உள்ளது, மீண்டும் `(key, value)` ஜோடிகளைச் சேமிக்கிறது. இங்கு ஒரு பாதை: `rlp(transactionIndex)` இது பின்வருவனவற்றால் தீர்மானிக்கப்படும் ஒரு மதிப்புக்கு ஒத்த கீயைக் குறிக்கிறது: + +```python +if legacyTx: + value = rlp(tx) +else: + value = TxType | encode(tx) +``` + +இது குறித்த கூடுதல் தகவல்களை [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) ஆவணத்தில் காணலாம். + +### ரசீதுகள் டிரை {#receipts-trie} + +ஒவ்வொரு block-க்கும் தனித்தனி Receipts trie உண்டு. இங்கு ஒரு `path`: `rlp(transactionIndex)`. `transactionIndex` என்பது அது சேர்க்கப்பட்ட பிளாக்கிற்குள் அதன் குறியீட்டெண் ஆகும். Receipts trie ஒருபோதும் update செய்யப்படாது. Transactions trie போலவே, இங்கேவும் current மற்றும் legacy receipts உள்ளன. ஒரு குறிப்பிட்ட receipt-ஐ Receipts trie-இல் இருந்து கேட்க, transaction-இன் index, receipt payload மற்றும் transaction type ஆகியவை தேவையாகும். திருப்பியளிக்கப்பட்ட ரசீது `Receipt` வகையாக இருக்கலாம், இது `TransactionType` மற்றும் `ReceiptPayload` ஆகியவற்றின் இணைப்பாக வரையறுக்கப்படுகிறது அல்லது அது `LegacyReceipt` வகையாக இருக்கலாம், இது `rlp([status, cumulativeGasUsed, logsBloom, logs])` என வரையறுக்கப்படுகிறது. + +இது குறித்த கூடுதல் தகவல்களை [EIP 2718](https://eips.ethereum.org/EIPS/eip-2718) ஆவணத்தில் காணலாம். + +## மேலும் வாசிக்க {#further-reading} + +- [மாற்றியமைக்கப்பட்ட மெர்கிள் பேட்ரிசியா டிரை — எத்தீரியம் ஒரு நிலையை எவ்வாறு சேமிக்கிறது](https://medium.com/codechain/modified-merkle-patricia-trie-how-ethereum-saves-a-state-e6d7555078dd) +- [எத்தீரியத்தில் மெர்கிளிங்](https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/) +- [எத்தீரியம் டிரையைப் புரிந்துகொள்ளுதல்](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie/) diff --git a/public/content/translations/ta/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/ta/developers/docs/data-structures-and-encoding/rlp/index.md new file mode 100644 index 00000000000..e4047bae10f --- /dev/null +++ b/public/content/translations/ta/developers/docs/data-structures-and-encoding/rlp/index.md @@ -0,0 +1,165 @@ +--- +title: "தொடர்-நீள முன்னொட்டு (RLP) வரிசைப்படுத்தல்" +description: "எத்தேரியத்தின் செயலாக்க அடுக்கில் உள்ள rlp குறியாக்கத்தின் வரையறை." +lang: ta +sidebarDepth: 2 +--- + +Ethereum இன் execution clients-ல் Recursive Length Prefix (RLP) serialization பரவலாகப் பயன்படுத்தப்படுகிறது. RLP என்பது nodes இடையே தரவை இட சேமிப்பு திறனுடன் (space-efficient) பரிமாறுவதற்கான standardized (ஒரே மாதிரியான) வடிவத்தை வழங்குகிறது. RLP-ன் நோக்கம்: 任 arbitrarily nested arrays of binary data-ஐ encode செய்வது. Ethereum execution layer-இல் objects-ஐ serialize செய்வதற்கான primary encoding method-ஆக RLP பயன்படுத்தப்படுகிறது. RLP-இன் முக்கிய நோக்கம் கட்டமைப்பை குறியாக்கம் செய்வதாகும்; நேர்மறை முழு எண்களைத் தவிர, RLP குறிப்பிட்ட தரவு வகைகளை (எ.கா., சரங்கள், மிதவைகள்) குறியாக்கம் செய்வதை உயர்-வரிசை நெறிமுறைகளுக்கு ஒப்படைக்கிறது. Positive integers → big-endian binary வடிவில் முன்னணி zero இன்றி காட்டப்பட வேண்டும் (அதாவது integer value 0 = காலியான byte array). முன்னணி zero கொண்ட integers-ஐ எந்த மேல் நிலை protocol-னும் invalid (செல்லாதது) எனக் கருத வேண்டும். + +மேலும் தகவலுக்கு [எத்தேரியம் மஞ்சள் தாள் (பின் இணைப்பு B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19) பார்க்கவும். + +RLP-யில் dictionary-ஐ encode செய்ய இரண்டு canonical (பொதுவான) முறைகள் பரிந்துரைக்கப்படுகின்றன: + +- விசைகளை அகராதி வரிசையில் `[[k1,v1],[k2,v2]...]` கொண்டு பயன்படுத்தவும் +- ethereum பயன்படுத்தும் Patricia Tree encoding-ஐ பயன்படுத்தலாம் + +## வரையறை {#definition} + +RLP encoding function-க்கு input-ஆக ஒரு item கொடுக்கப்படும். Item என வரையறுக்கப்படுவது: + +- ஒரு சரம் (அதாவது, பைட் வரிசை) ஒரு உருப்படி ஆகும் +- ஒரு list of items +- ஒரு positive integer + +எடுத்துக்காட்டுகள் (items): + +- ஒரு காலி string ""; +- "cat" என்ற string; +- ஒரு list, அதில் எந்த எண்ணிக்கையிலான strings இருந்தாலும்; +- மற்றும் `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]` போன்ற மிகவும் சிக்கலான தரவு கட்டமைப்புகள். +- `100` என்ற எண் + +இங்கு "string" என்றால் “binary data கொண்ட byte-கள்” என்று பொருள். +எந்தவொரு content encoding-மும் பயன்படுத்தப்படாது. +non-minimal positive integers பயன்படுத்தக்கூடாது என்பதே ஒரே விதி. + +RLP encoding விதிகள்: + +- Positive integer → அதை big-endian byte array ஆக மாற்றி, string encode செய்யும் விதிகளைக் கொண்டு encode செய்ய வேண்டும். +- `[0x00, 0x7f]` (தசம `[0, 127]`) வரம்பில் மதிப்புள்ள ஒற்றை பைட்டிற்கு, அந்த பைட் அதன் சொந்த RLP குறியாக்கமாகும். +- இல்லையெனில், ஒரு சரம் 0-55 பைட்டுகள் நீளமாக இருந்தால், RLP குறியாக்கமானது **0x80** (dec. 128) மதிப்புடன் ஒரு ஒற்றை பைட்டையும், அதைத் தொடர்ந்து சரத்தின் நீளம் மற்றும் சரத்தையும் கொண்டிருக்கும். எனவே முதல் பைட்டின் வரம்பு `[0x80, 0xb7]` (dec. `[128, 183]`) ஆகும். +- ஒரு சரம் 55 பைட்டுகளுக்கு மேல் நீளமாக இருந்தால், RLP குறியாக்கமானது **0xb7** (dec. 183) மதிப்புள்ள ஒரு ஒற்றை பைட்டையும், அதைத் தொடர்ந்து பைனரி வடிவத்தில் உள்ள சரத்தின் நீளத்தின் பைட் நீளத்தையும், பின்னர் சரத்தின் நீளத்தையும், பின்னர் சரத்தையும் கொண்டிருக்கும். உதாரணமாக, 1024 பைட் நீளமுள்ள ஒரு சரம் `\xb9\x04\x00` (dec. `185, 4, 0`) என குறியாக்கம் செய்யப்படும், அதைத் தொடர்ந்து சரம் வரும். இங்கே, முதல் பைட்டாக `0xb9` (183 + 2 = 185), அதைத் தொடர்ந்து உண்மையான சரத்தின் நீளத்தைக் குறிக்கும் `0x0400` (dec. 1024) என்ற 2 பைட்டுகள் வரும். எனவே முதல் பைட்டின் வரம்பு `[0xb8, 0xbf]` (dec. `[184, 191]`) ஆகும். +- ஒரு string 2^64 bytes நீளமோ அல்லது அதற்கு அதிகமோ இருந்தால், அது encode செய்ய முடியாது. +- ஒரு பட்டியலின் மொத்த பேலோட் (அதாவது, அதன் RLP குறியாக்கம் செய்யப்பட்ட அனைத்து உருப்படிகளின் ஒருங்கிணைந்த நீளம்) 0-55 பைட்டுகள் நீளமாக இருந்தால், RLP குறியாக்கமானது **0xc0** மதிப்புடன் ஒரு ஒற்றை பைட்டையும், அதைத் தொடர்ந்து பேலோடின் நீளத்தையும், அதைத் தொடர்ந்து உருப்படிகளின் RLP குறியாக்கங்களின் இணைப்பையும் கொண்டிருக்கும். எனவே முதல் பைட்டின் வரம்பு `[0xc0, 0xf7]` (dec. `[192, 247]`) ஆகும். +- ஒரு பட்டியலின் மொத்த பேலோட் 55 பைட்டுகளுக்கு மேல் நீளமாக இருந்தால், RLP குறியாக்கமானது **0xf7** மதிப்புள்ள ஒரு ஒற்றை பைட்டையும், பைனரி வடிவத்தில் உள்ள பேலோடின் நீளத்தின் பைட் நீளத்தையும், பின்னர் பேலோடின் நீளத்தையும், பின்னர் உருப்படிகளின் RLP குறியாக்கங்களின் இணைப்பையும் கொண்டிருக்கும். எனவே முதல் பைட்டின் வரம்பு `[0xf8, 0xff]` (dec. `[248, 255]`) ஆகும். + +Code-ல், இது: + +```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) +``` + +## எடுத்துக்காட்டுகள் {#examples} + +- the string "dog" = [ 0x83, 'd', 'o', 'g' ] +- பட்டியல் [ "cat", "dog" ] = `[ 0xc8, 0x83, 'c', 'a', 't', 0x83, 'd', 'o', 'g' ]` +- வெற்றுச் சரம் ('null') = `[ 0x80 ]` +- வெற்றுப் பட்டியல் = `[ 0xc0 ]` +- முழு எண் 0 = `[ 0x80 ]` +- பைட் '\\x00' = `[ 0x00 ]` +- பைட் '\\x0f' = `[ 0x0f ]` +- பைட்டுகள் '\\x04\\x00' = `[ 0x82, 0x04, 0x00 ]` +- மூன்றின் [கணக் கோட்பாட்டு பிரதிநிதித்துவம்](http://en.wikipedia.org/wiki/Set-theoretic_definition_of_natural_numbers), `[ [], [[]], [ [], [[]] ] ] = [ 0xc7, 0xc0, 0xc1, 0xc0, 0xc3, 0xc0, 0xc1, 0xc0 ]` +- சரம் "Lorem ipsum dolor sit amet, consectetur adipisicing elit" = `[ 0xb8, 0x38, 'L', 'o', 'r', 'e', 'm', ' ', ...` `, 'e', 'l', 'i', 't' ]` + +## RLP குறிவிலக்கல் {#rlp-decoding} + +RLP encoding-ன் விதிமுறைகள் மற்றும் செயல்முறைகளின்படி, RLP decode-க்கு வழங்கப்படும் input என்பது ஒரு binary data array ஆகக் கருதப்படுகிறது. RLP decoding செயல்முறை பின்வருமாறு: + +1. உள்ளீட்டுத் தரவின் முதல் பைட்டின் (அதாவது, முன்னொட்டு) படி தரவு வகை, உண்மையான தரவின் நீளம் மற்றும் ஆஃப்செட் ஆகியவற்றைக் குறிவிலக்குதல்; + +2. data type மற்றும் offset-ஐப் பொறுத்து, positive integers-க்கு minimal encoding விதியை மதித்து, data-ஐ decode செய்தல்; + +3. input-ன் மீதமுள்ள பகுதியை தொடர்ந்து decode செய்தல்; + +இதில், data type-களை decode செய்வதற்கான விதிமுறைகள் மற்றும் offset பின்வருமாறு: + +1. முதல் பைட்டின் (அதாவது, முன்னொட்டு) வரம்பு [0x00, 0x7f] என இருந்தால், தரவு ஒரு சரமாகும், மேலும் அந்தச் சரமே முதல் பைட் ஆகும்; + +2. முதல் byte-ன் range [0x80, 0xb7] ஆக இருந்தால், அந்த data ஒரு string, அதன் length = முதல் byte - 0x80, மேலும் அந்த string முதல் byte-க்கு பின் வரும்; + +3. முதல் byte-ன் range [0xb8, 0xbf] ஆக இருந்தால், அந்த data ஒரு string, அதன் length (bytes-ல்) = முதல் byte - 0xb7, length-ன் பின்னர் அந்த string வரும்; + +4. முதல் byte-ன் range [0xc0, 0xf7] ஆக இருந்தால், அந்த data ஒரு list, அதன் மொத்த payload = முதல் byte - 0xc0, மேலும் அந்த list-ன் அனைத்து items-ன் RLP encodings-ஐ இணைத்தது முதல் byte-க்கு பின் வரும்; + +5. முதல் byte-ன் range [0xf8, 0xff] ஆக இருந்தால், அந்த data ஒரு list, அதன் மொத்த payload length = முதல் byte - 0xf7, அதன் பின்னர் அந்த payload வரும், மேலும் அந்த list-ன் அனைத்து items-ன் RLP encodings-ஐ இணைத்தது அந்த payload-க்கு பின் வரும்; + +Code-ல், இது: + +```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 +``` + +## மேலும் வாசிக்க {#further-reading} + +- [எத்தேரியத்தில் RLP](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [எத்தேரியம் அண்டர் தி ஹூட்: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Coglio, A. (2020). ACL2 இல் எத்தேரியத்தின் தொடர் நீள முன்னொட்டு. arXiv preprint arXiv:2009.13769.](https://arxiv.org/abs/2009.13769) + +## தொடர்புடைய தலைப்புகள் {#related-topics} + +- [Patricia merkle trie](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) diff --git a/public/content/translations/ta/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/ta/developers/docs/data-structures-and-encoding/ssz/index.md new file mode 100644 index 00000000000..9bd581eb3da --- /dev/null +++ b/public/content/translations/ta/developers/docs/data-structures-and-encoding/ssz/index.md @@ -0,0 +1,153 @@ +--- +title: Simple serialize (Ssz) +description: "எத்தேரியத்தின் SSZ வடிவமைப்பு பற்றிய விளக்கம்." +lang: ta +sidebarDepth: 2 +--- + +**எளிய வரிசைப்படுத்தல் (SSZ)** என்பது தீப்பந்த சங்கிலியில் பயன்படுத்தப்படும் வரிசைப்படுத்தல் முறையாகும். இது execution layer-இல் பயன்படுத்தப்படும் RLP serialization-ஐ மாற்றுகிறது, ஆனால் peer discovery protocol தவிர consensus layer முழுவதும் இதுவே பயன்படுத்தப்படுகிறது. RLP வரிசைப்படுத்தல் பற்றி மேலும் அறிய, [சுழல்நிலை-நீள முன்னொட்டு (RLP)](/developers/docs/data-structures-and-encoding/rlp/) என்பதைப் பார்க்கவும். SSZ deterministic ஆக வடிவமைக்கப்பட்டுள்ளது, மேலும் Merkleize செய்யவும் திறமையாக உள்ளது. SSZ-ஐ இரண்டு பகுதிகளைக் கொண்டதாகக் கருதலாம்: ஒரு serialization scheme, ஒரு Merkleization scheme – இது serialized data structure-உடன் திறமையாக வேலை செய்ய வடிவமைக்கப்பட்டுள்ளது. + +## SSZ எப்படி செயல்படுகிறது? {#how-does-ssz-work} + +### வரிசைப்படுத்தல் {#serialization} + +SSZ என்பது self-describing அல்லாத serialization scheme – அதாவது, முன்கூட்டியே schema தெரிந்திருக்க வேண்டும். SSZ serialization-ன் நோக்கம், எவ்வளவு சிக்கலான object ஆனாலும் அதை byte string ஆக மாற்றுவதாகும். இது "basic types" க்கு மிக எளிமையான செயல்முறை. Element எளிதாகவே hexadecimal bytes-ஆக மாற்றப்படுகிறது. Basic types: + +- unsigned integers +- Booleans + +சிக்கலான "composite types" க்கான serialization இன்னும் சிக்கலாகும். +ஏனெனில் composite type-ல் பல elements இருக்கும், அவற்றின் type அல்லது size வேறுபட்டு இருக்கலாம். இந்த பொருள்கள் அனைத்தும் நிலையான நீளங்களைக் கொண்டிருக்கும் இடங்களில் (அதாவது, உறுப்புகளின் அளவு அவற்றின் உண்மையான மதிப்புகளைப் பொருட்படுத்தாமல் எப்போதும் மாறிலியாக இருக்கும்) வரிசைப்படுத்தல் என்பது கலப்பு வகையிலுள்ள ஒவ்வொரு உறுப்பையும் லிட்டில்-எண்டியன் பைட்ஸ்ட்ரிங்ஸ்களாக மாற்றுவதாகும். பிறகு, அந்த bytestring-கள் இணைக்கப்படும். Serialized object-ல், fixed-length elements-ன் bytelist representation, deserialized object-ல் அவை இருந்த அதே வரிசையில் இருக்கும். + +Variable length கொண்ட types-க்கு serialization வேறுபடும், அந்த element-ன் இடத்தில், actual data-க்கு பதிலாக ஒரு "offset value" வைக்கப்படும். அந்த actual data, serialized object-ன் முடிவில் இருக்கும் heap-ல் சேர்க்கப்படும். அந்த offset value, heap-ல் actual data ஆரம்பிக்கும் இடத்தின் index-ஐ குறிக்கும் (அதாவது, அந்த bytes-ஐச் சுட்டும் pointer ஆக செயல்படும்). + +கீழே உள்ள உதாரணம், fixed மற்றும் variable-length elements இரண்டும் உள்ள ஒரு container-க்கு offset எவ்வாறு செயல்படுகிறது என்பதை விளக்குகிறது: + +```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) + +``` + +`வரிசைப்படுத்தப்பட்ட` தரவு பின்வரும் கட்டமைப்பைக் கொண்டிருக்கும் (இங்கே 4 பிட்டுகளுக்கு மட்டுமே திணிக்கப்பட்டுள்ளது, உண்மையில் 32 பிட்டுகளுக்கு திணிக்கப்படும், மேலும் தெளிவுக்காக `int` பிரதிநிதித்துவம் வைக்கப்பட்டுள்ளது): + +``` +[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] +------------ ----------- ----------- ----------- ---------- + | | | | | + எண்1 எண்2 திசையனுக்கான எண் 3 திசையனுக்கான + ஆஃப்செட் மதிப்பு + +``` + +விளக்கத்திற்காக பல வரிகளாகப் பிரிக்கப்பட்டது: + +``` +[ + 37, 0, 0, 0, # `number1`-இன் லிட்டில்-எண்டியன் குறியாக்கம். + 55, 0, 0, 0, # `number2`-இன் லிட்டில்-எண்டியன் குறியாக்கம். + 16, 0, 0, 0, # `vector`-இன் மதிப்பு எங்கு தொடங்குகிறது என்பதைக் குறிக்கும் "ஆஃப்செட்" (லிட்டில்-எண்டியன் 16). + 22, 0, 0, 0, # `number3`-இன் லிட்டில்-எண்டியன் குறியாக்கம். + 1, 2, 3, 4, # `vector`-இல் உள்ள உண்மையான மதிப்புகள். +] +``` + +இது இன்னும் ஒரு simplification தான் – +மேலே உள்ள schematic-ல் integers மற்றும் zeros உண்மையில் bytelists ஆகச் சேமிக்கப்படும், எடுத்துக்காட்டாக: + +``` +[ + 10100101000000000000000000000000 # `number1`-இன் லிட்டில்-எண்டியன் குறியாக்கம் + 10110111000000000000000000000000 # `number2`-இன் லிட்டில்-எண்டியன் குறியாக்கம். + 10010000000000000000000000000000 # `vector`-இன் மதிப்பு எங்கு தொடங்குகிறது என்பதைக் குறிக்கும் "ஆஃப்செட்" (லிட்டில்-எண்டியன் 16). + 10010110000000000000000000000000 # `number3`-இன் லிட்டில்-எண்டியன் குறியாக்கம். + 10000001100000101000001110000100 # `bytes` புலத்தின் உண்மையான மதிப்பு. +] +``` + +இதனால், variable-length types-ன் actual values serialized object-ன் இறுதியில் உள்ள heap-ல் சேமிக்கப்படும், +மற்றும் அவற்றின் offset values சரியான இடத்தில் (ordered list of fields-ல்) வைக்கப்படும். + +வரிசைப்படுத்தலின் போது நீள வரம்பைச் சேர்க்கவும், வரிசைநீக்கத்தின் போது அகற்றவும் தேவைப்படும் `BitList` வகை போன்ற குறிப்பிட்ட சிகிச்சை தேவைப்படும் சில சிறப்பு நிகழ்வுகளும் உள்ளன. முழு விவரங்களும் [SSZ விவரக்குறிப்பில்](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) கிடைக்கின்றன. + +### வரிசைநீக்கம் {#deserialization} + +ஒரு object-ஐ deserialize செய்ய schema தேவைப்படுகிறது. Schema தான் serialized data-வின் சரியான அமைப்பை (precise layout) வரையறுக்கிறது. அதன் மூலம் ஒவ்வொரு element-மும் bytes blob-இலிருந்து மீண்டும் பொருத்தமான object-ஆக மாற்றப்படும், மேலும் அவை சரியான type, value, size, position உடன் மீள்பெறும். Schema தான் deserializer-க்கு எந்த values actual values, எந்த values offsets என்பதைச் சொல்கிறது. ஒரு object serialize ஆனபோது, அதன் field names அனைத்தும் மறைந்து விடும். ஆனால் deserialization போது schema அடிப்படையில் மீண்டும் field names உருவாக்கப்படும். + +இதற்கான ஒரு ஊடாடும் விளக்கத்திற்கு [ssz.dev](https://www.ssz.dev/overview) ஐப் பார்க்கவும். + +## மெர்க்கிலைசேஷன் {#merkleization} + +இந்த SSZ serialized object-ஐ Merkleize செய்யலாம் – அதாவது, அதே தரவின் Merkle-tree representation ஆக மாற்றலாம். முதலில், serialized object-இல் எத்தனை 32-byte chunks உள்ளன என்பதை தீர்மானிக்க வேண்டும். இவை தான் மரத்தின் "leaves". மொத்த leaves எண்ணிக்கை 2-ன் சக்தியாக (power of 2) இருக்க வேண்டும், அப்போதுதான் அவற்றை ஒன்றாக hash செய்யும் போது இறுதியில் ஒரு single hash-tree-root உருவாகும். இது இயல்பாக இல்லாவிட்டால், 32 bytes zeros கொண்ட கூடுதல் leaves சேர்க்கப்படும். Diagrammatically: + +``` + ஹாஷ் மரத்தின் மூலம் + / \ + / \ + / \ + / \ + இலைகள் 1 மற்றும் 2-இன் ஹாஷ் இலைகள் 3 மற்றும் 4-இன் ஹாஷ் + / \ / \ + / \ / \ + / \ / \ + இலை1 இலை2 இலை3 இலை4 +``` + +சில நேரங்களில், tree-ன் leaves மேலே காட்டிய மாதிரி சமமாகப் பகிரப்படாது. உதாரணமாக, leaf 4 ஒரு container ஆக இருந்து, அதில் பல elements இருக்கலாம். +அப்படியானால், Merkle tree-க்கு கூடுதல் "depth" சேர்க்கப்பட வேண்டும், இதனால் tree uneven ஆகும். + +இந்த tree elements-ஐ leaf X, node X என்று குறிப்பிடுவதற்கு பதிலாக, அவற்றிற்கு generalized indices கொடுக்கலாம், root = 1 என்று தொடங்கி, ஒவ்வொரு level-இலும் இடமிருந்து வலமாக எண்ணலாம். இது மேலே விளக்கப்பட்ட generalized index ஆகும். வரிசைப்படுத்தப்பட்ட பட்டியலில் உள்ள ஒவ்வொரு உறுப்புக்கும் `2**depth + idx` க்கு சமமான ஒரு பொதுவான குறியீடு உள்ளது, இங்கு idx என்பது வரிசைப்படுத்தப்பட்ட பொருளில் அதன் பூஜ்ஜிய-குறியீட்டு நிலையாகும், மேலும் டெப்த் என்பது மெர்க்கல் மரத்தில் உள்ள நிலைகளின் எண்ணிக்கையாகும், இது உறுப்புகளின் (இலைகள்) எண்ணிக்கையின் அடி-இரண்டு மடக்கையாக தீர்மானிக்கப்படலாம். + +## பொதுவான குறியீடுகள் {#generalized-indices} + +ஒரு பொதுவான குறியீடு என்பது ஒரு முழு எண் ஆகும், இது ஒரு பைனரி மெர்க்கல் மரத்தில் ஒரு முனையை பிரதிபலிக்கிறது, அங்கு ஒவ்வொரு முனைக்கும் `2 ** depth + index in row` என்ற பொதுவான குறியீடு உள்ளது. + +``` + 1 --டெப்த் = 0 2**0 + 0 = 1 + 2 3 --டெப்த் = 1 2**1 + 0 = 2, 2**1+1 = 3 + 4 5 6 7 --டெப்த் = 2 2**2 + 0 = 4, 2**2 + 1 = 5... + +``` + +இந்த representation, Merkle tree-இல் உள்ள ஒவ்வொரு data-க்கும் ஒரு node index-ஐ உருவாக்குகிறது. + +## பல்சான்றுகள் {#multiproofs} + +ஒரு குறிப்பிட்ட element-ஐ குறிக்கும் generalized indices பட்டியல் வழங்கப்படும்போது, அதை hash-tree-root-க்கு எதிராக சரிபார்க்க முடியும். இந்த root தான் நாங்கள் ஏற்றுக்கொண்டுள்ள உண்மை (accepted version of reality). எந்த data கொடுக்கப்பட்டாலும், அதை அதன் generalized index தீர்மானிக்கும் சரியான இடத்தில் Merkle tree-இல் வைத்து, root மாறாமல் இருப்பதை கவனிப்பதன் மூலம் அந்த data-ஐ உண்மைக்கெதிராக சரிபார்க்க முடியும். [இங்கே](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) உள்ள விவரக்குறிப்பில், ஒரு குறிப்பிட்ட பொதுவான குறியீடுகளின் தொகுப்பின் உள்ளடக்கங்களைச் சரிபார்க்கத் தேவையான குறைந்தபட்ச முனைகளின் தொகுப்பை எவ்வாறு கணக்கிடுவது என்பதைக் காட்டும் செயல்பாடுகள் உள்ளன. + +உதாரணமாக, கீழே உள்ள tree-இல் index 9-இல் உள்ள data-ஐ verify செய்ய, indices 8, 9, 5, 3, 1-இல் உள்ள data-வின் hash தேவைப்படும். +(8,9)-இன் hash, (4)-இன் hash-க்கு சமமாக இருக்க வேண்டும், அது 5-உடன் hash செய்யப்பட்டு 2 ஆகும், அது 3-உடன் hash செய்யப்பட்டு tree root 1 ஆகும். 9-க்கு தவறான data கொடுக்கப்பட்டால், root மாறிவிடும் – இதை நாம் கண்டறிந்து, அந்த branch verify ஆகாமல் போகும். + +``` +* = சான்றை உருவாக்க தேவையான தரவு + + 1* + 2 3* + 4 5* 6 7 +8* 9* 10 11 12 13 14 15 + +``` + +## மேலும் வாசிக்க {#further-reading} + +- [எத்தேரியத்தை மேம்படுத்துதல்: SSZ](https://eth2book.info/altair/part2/building_blocks/ssz) +- [எத்தேரியத்தை மேம்படுத்துதல்: மெர்க்கிலைசேஷன்](https://eth2book.info/altair/part2/building_blocks/merkleization) +- [SSZ செயலாக்கங்கள்](https://github.com/ethereum/consensus-specs/issues/2138) +- [SSZ கால்குலேட்டர்](https://simpleserialize.com/) +- [SSZ.dev](https://www.ssz.dev/)