diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/attestations/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/attestations/index.md new file mode 100644 index 00000000000..1a7922ac7f8 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/attestations/index.md @@ -0,0 +1,92 @@ +--- +title: "تصدیقات" +description: "پروف-آف-اسٹیک Ethereum پر تصدیقات کی تفصیل۔" +lang: ur-in +--- + +ہر ایپوک کے دوران ایک ویلیڈیٹر سے ایک تصدیق بنانے، اس پر دستخط کرنے اور اسے براڈکاسٹ کرنے کی توقع کی جاتی ہے۔ یہ صفحہ اس بات کا خاکہ پیش کرتا ہے کہ یہ تصدیقات کیسی دکھتی ہیں اور کنسنسس کلائنٹس کے درمیان ان پر کارروائی اور ان کا تبادلہ کیسے ہوتا ہے۔ + +## تصدیق کیا ہے؟ {#what-is-an-attestation} + +ہر [ایپوک](/glossary/#epoch) (6.4 منٹ) میں ایک ویلیڈیٹر نیٹ ورک کو ایک تصدیق کی تجویز پیش کرتا ہے۔ تصدیق ایپوک میں ایک مخصوص سلاٹ کے لیے ہوتی ہے۔ تصدیق کا مقصد چین کے بارے میں ویلیڈیٹر کے نظریہ کے حق میں ووٹ دینا ہے، خاص طور پر سب سے حالیہ جائز بلاک اور موجودہ ایپوک کے پہلے بلاک (جسے `source` اور `target` چیک پوائنٹس کے نام سے جانا جاتا ہے) کے حق میں۔ یہ معلومات تمام حصہ لینے والے ویلیڈیٹرز کے لیے یکجا کی جاتی ہیں، جس سے نیٹ ورک بلاک چین کی اسٹیٹ کے بارے میں کنسنسس تک پہنچ پاتا ہے۔ + +تصدیق میں درج ذیل اجزاء ہوتے ہیں: + +- `aggregation_bits`: ویلیڈیٹرز کی ایک بٹ لسٹ جہاں پوزیشن ان کی کمیٹی میں ویلیڈیٹر انڈیکس سے مطابقت رکھتی ہے؛ ویلیو (0/1) اس بات کی نشاندہی کرتی ہے کہ آیا ویلیڈیٹر نے `data` پر دستخط کیے ہیں (یعنی، آیا وہ فعال ہیں اور بلاک پروپوزر سے اتفاق کرتے ہیں) +- `data`: تصدیق سے متعلق تفصیلات، جیسا کہ ذیل میں بیان کیا گیا ہے +- `signature`: ایک BLS دستخط جو انفرادی ویلیڈیٹرز کے دستخطوں کو جمع کرتا ہے + +ایک تصدیق کرنے والے ویلیڈیٹر کے لیے پہلا کام `data` بنانا ہے۔ `data` میں درج ذیل معلومات ہوتی ہیں: + +- `slot`: وہ سلاٹ نمبر جس کا تصدیق حوالہ دیتی ہے +- `index`: ایک نمبر جو یہ شناخت کرتا ہے کہ ایک دیے گئے سلاٹ میں ویلیڈیٹر کس کمیٹی سے تعلق رکھتا ہے +- `beacon_block_root`: اس بلاک کا روٹ ہیش جسے ویلیڈیٹر چین کے ہیڈ پر دیکھتا ہے (فورک-چوائس الگورتھم کو لاگو کرنے کا نتیجہ) +- `source`: فائنلٹی ووٹ کا حصہ جو اس بات کی نشاندہی کرتا ہے کہ ویلیڈیٹرز سب سے حالیہ جائز بلاک کے طور پر کیا دیکھتے ہیں +- `target`: فائنلٹی ووٹ کا حصہ جو اس بات کی نشاندہی کرتا ہے کہ ویلیڈیٹرز موجودہ ایپوک میں پہلے بلاک کے طور پر کیا دیکھتے ہیں + +ایک بار جب `data` بن جاتا ہے، تو ویلیڈیٹر `aggregation_bits` میں اپنے ویلیڈیٹر انڈیکس کے مطابق بٹ کو 0 سے 1 میں پلٹ سکتا ہے تاکہ یہ ظاہر ہو کہ اس نے حصہ لیا تھا۔ + +آخر میں، ویلیڈیٹر تصدیق پر دستخط کرتا ہے اور اسے نیٹ ورک پر براڈکاسٹ کرتا ہے۔ + +### مجموعی تصدیق {#aggregated-attestation} + +ہر ویلیڈیٹر کے لیے نیٹ ورک پر اس ڈیٹا کو منتقل کرنے سے وابستہ ایک خاطر خواہ اوورہیڈ ہے۔ لہذا، انفرادی ویلیڈیٹرز کی تصدیقات کو زیادہ وسیع پیمانے پر براڈکاسٹ کیے جانے سے پہلے سب نیٹس کے اندر جمع کیا جاتا ہے۔ اس میں دستخطوں کو ایک ساتھ جمع کرنا شامل ہے تاکہ براڈکاسٹ ہونے والی تصدیق میں کنسنسس `data` اور ان تمام ویلیڈیٹرز کے دستخطوں کو ملا کر بنایا گیا ایک واحد دستخط شامل ہو جو اس `data` سے اتفاق کرتے ہیں۔ اسے `aggregation_bits` کا استعمال کرکے چیک کیا جاسکتا ہے کیونکہ یہ ان کی کمیٹی میں ہر ویلیڈیٹر کا انڈیکس فراہم کرتا ہے (جس کی ID `data` میں فراہم کی گئی ہے) جسے انفرادی دستخطوں کی استفسار کے لیے استعمال کیا جاسکتا ہے۔ + +ہر ایپوک میں ہر سب نیٹ میں 16 ویلیڈیٹرز کو `aggregators` کے طور پر منتخب کیا جاتا ہے۔ ایگریگیٹرز گوسپ نیٹ ورک پر سنی گئی ان تمام تصدیقات کو جمع کرتے ہیں جن کا `data` ان کے اپنے `data` کے برابر ہوتا ہے۔ ہر مماثل تصدیق کے بھیجنے والے کو `aggregation_bits` میں ریکارڈ کیا جاتا ہے۔ اس کے بعد ایگریگیٹرز تصدیق کے مجموعے کو وسیع تر نیٹ ورک پر براڈکاسٹ کرتے ہیں۔ + +جب کسی ویلیڈیٹر کو بلاک پروپوزر کے طور پر منتخب کیا جاتا ہے تو وہ نئے بلاک میں تازہ ترین سلاٹ تک سب نیٹس سے مجموعی تصدیقات کو پیکج کرتے ہیں۔ + +### تصدیق کی شمولیت کا لائف سائیکل {#attestation-inclusion-lifecycle} + +1. جنریشن +2. پھیلاؤ +3. ایگریگیشن +4. پھیلاؤ +5. شمولیت + +تصدیق کا لائف سائیکل نیچے دیے گئے خاکے میں بیان کیا گیا ہے: + +![تصدیق کا لائف سائیکل](./attestation_schematic.png) + +## انعامات {#rewards} + +ویلیڈیٹرز کو تصدیقات جمع کرنے پر انعام دیا جاتا ہے۔ تصدیق کا انعام شرکت کے فلیگس (سورس، ٹارگٹ اور ہیڈ)، بنیادی انعام اور شرکت کی شرح پر منحصر ہے۔ + +جمع کی گئی تصدیق اور اس کی شمولیت میں تاخیر کے لحاظ سے ہر شرکت کا فلیگ یا تو درست یا غلط ہو سکتا ہے۔ + +بہترین منظرنامہ اس وقت ہوتا ہے جب تینوں فلیگس درست ہوں، اس صورت میں ایک ویلیڈیٹر کمائے گا (فی درست فلیگ): + +`reward += base reward * flag weight * flag attesting rate / 64` + +فلیگ تصدیقی شرح کو دیے گئے فلیگ کے لیے تمام تصدیق کرنے والے ویلیڈیٹرز کے مؤثر بیلنس کے مجموعے کا کل فعال مؤثر بیلنس سے موازنہ کرکے ماپا جاتا ہے۔ + +### بنیادی انعام {#base-reward} + +بنیادی انعام کا حساب تصدیق کرنے والے ویلیڈیٹرز کی تعداد اور ان کے مؤثر اسٹیک شدہ ایتھر بیلنس کے مطابق کیا جاتا ہے: + +`base reward = validator effective balance x 2^6 / SQRT(Effective balance of all active validators)` + +#### شمولیت میں تاخیر {#inclusion-delay} + +جس وقت ویلیڈیٹرز نے چین کے ہیڈ (`block n`) پر ووٹ دیا، اس وقت `block n+1` ابھی تک تجویز نہیں کیا گیا تھا۔ لہذا تصدیقات قدرتی طور پر **ایک بلاک بعد** شامل ہو جاتی ہیں، اس لیے `block n` کو چین کا ہیڈ ہونے پر ووٹ دینے والی تمام تصدیقات `block n+1` میں شامل ہو گئیں، اور **شمولیت میں تاخیر** 1 ہے۔ اگر شمولیت میں تاخیر دوگنی ہو کر دو سلاٹس ہو جاتی ہے، تو تصدیق کا انعام آدھا ہو جاتا ہے، کیونکہ تصدیق کے انعام کا حساب لگانے کے لیے بنیادی انعام کو شمولیت میں تاخیر کے معکوس سے ضرب دیا جاتا ہے۔ + +### تصدیق کے منظرنامے {#attestation-scenarios} + +#### گمشدہ ووٹنگ ویلیڈیٹر {#missing-voting-validator} + +ویلیڈیٹرز کے پاس اپنی تصدیق جمع کرانے کے لیے زیادہ سے زیادہ 1 ایپوک ہوتا ہے۔ اگر ایپوک 0 میں تصدیق چھوٹ گئی تھی، تو وہ اسے ایپوک 1 میں شمولیت میں تاخیر کے ساتھ جمع کرا سکتے ہیں۔ + +#### گمشدہ ایگریگیٹر {#missing-aggregator} + +کل ملا کر ہر ایپوک میں 16 ایگریگیٹرز ہوتے ہیں۔ اس کے علاوہ، بے ترتیب ویلیڈیٹرز **256 ایپوکس کے لیے دو سب نیٹس** کو سبسکرائب کرتے ہیں اور ایگریگیٹرز کے گم ہونے کی صورت میں بیک اپ کے طور پر کام کرتے ہیں۔ + +#### گمشدہ بلاک پروپوزر {#missing-block-proposer} + +نوٹ کریں کہ کچھ معاملات میں ایک خوش قسمت ایگریگیٹر بلاک پروپوزر بھی بن سکتا ہے۔ اگر بلاک پروپوزر کے گم ہو جانے کی وجہ سے تصدیق شامل نہیں کی گئی تھی، تو اگلا بلاک پروپوزر مجموعی تصدیق کو اٹھا کر اگلے بلاک میں شامل کر دے گا۔ تاہم، **شمولیت میں تاخیر** میں ایک کا اضافہ ہو جائے گا۔ + +## مزید پڑھیں {#further-reading} + +- [Vitalik کی اینوٹیٹڈ کنسنسس اسپیک میں تصدیقات](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/ur/developers/docs/consensus-mechanisms/pos/block-proposal/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/block-proposal/index.md new file mode 100644 index 00000000000..a4a1664b5d8 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/block-proposal/index.md @@ -0,0 +1,69 @@ +--- +title: "بلاک کی تجویز" +description: "پروف آف اسٹیک Ethereum میں بلاکس کی تجویز کیسے دی جاتی ہے اس کی وضاحت۔" +lang: ur-in +--- + +بلاک چین کی بنیادی اکائیاں بلاکس ہیں۔ بلاکس معلومات کی مجرد اکائیاں ہیں جو نوڈس کے درمیان منتقل ہوتی ہیں، ان پر اتفاق کیا جاتا ہے اور ہر نوڈ کے ڈیٹا بیس میں شامل کی جاتی ہیں۔ یہ صفحہ وضاحت کرتا ہے کہ وہ کیسے تیار کیے جاتے ہیں۔ + +## شرائط {#prerequisites} + +بلاک کی تجویز پروف آف اسٹیک پروٹوکول کا حصہ ہے۔ اس صفحہ کو سمجھنے میں مدد کے لیے، ہم تجویز کرتے ہیں کہ آپ [proof-of-stake](/developers/docs/consensus-mechanisms/pos/) اور [block architecture](/developers/docs/blocks/) کے بارے میں پڑھیں۔ + +## بلاکس کون تیار کرتا ہے؟ {#who-produces-blocks} + +ویلیڈیٹر اکاؤنٹس بلاکس کی تجویز دیتے ہیں۔ ویلیڈیٹر اکاؤنٹس کو نوڈ آپریٹرز کے ذریعے منظم کیا جاتا ہے جو اپنے ایگزیکیوشن اور کنسینسس کلائنٹس کے حصے کے طور پر ویلیڈیٹر سافٹ ویئر چلاتے ہیں اور انہوں نے ڈیپازٹ کنٹریکٹ میں کم از کم 32 ETH جمع کرائے ہیں۔ تاہم، ہر ویلیڈیٹر صرف کبھی کبھار ہی ایک بلاک کی تجویز دینے کا ذمہ دار ہوتا ہے۔ Ethereum وقت کی پیمائش سلاٹس اور ایپوکس میں کرتا ہے۔ ہر سلاٹ بارہ سیکنڈ کا ہوتا ہے، اور 32 سلاٹس (6.4 منٹ) مل کر ایک ایپوک بناتے ہیں۔ ہر سلاٹ Ethereum پر ایک نیا بلاک شامل کرنے کا ایک موقع ہوتا ہے۔ + +### بے ترتیب انتخاب {#random-selection} + +ہر سلاٹ میں ایک بلاک کی تجویز دینے کے لیے ایک واحد ویلیڈیٹر کو نیم بے ترتیب طور پر منتخب کیا جاتا ہے۔ بلاک چین میں حقیقی بے ترتیبی جیسی کوئی چیز نہیں ہے کیونکہ اگر ہر نوڈ حقیقی طور پر بے ترتیب نمبر تیار کرتا، تو وہ اتفاق رائے پر نہیں پہنچ سکتے۔ اس کے بجائے، مقصد ویلیڈیٹر کے انتخاب کے عمل کو غیر متوقع بنانا ہے۔ Ethereum پر بے ترتیبی RANDAO نامی ایک الگورتھم کا استعمال کرتے ہوئے حاصل کی جاتی ہے جو بلاک پروپوزر سے ایک ہیش کو ایک سیڈ کے ساتھ ملاتا ہے جو ہر بلاک پر اپ ڈیٹ ہوتا ہے۔ یہ قدر کل ویلیڈیٹر سیٹ سے ایک مخصوص ویلیڈیٹر کو منتخب کرنے کے لیے استعمال کی جاتی ہے۔ بعض قسم کی سیڈ کی ہیرا پھیری سے بچانے کے ایک طریقے کے طور پر ویلیڈیٹر کا انتخاب دو ایپوکس پہلے سے طے کیا جاتا ہے۔ + +اگرچہ ویلیڈیٹرز ہر سلاٹ میں RANDAO میں اضافہ کرتے ہیں، لیکن عالمی RANDAO ویلیو ہر ایپوک میں صرف ایک بار اپ ڈیٹ ہوتی ہے۔ اگلے بلاک پروپوزر کے انڈیکس کا حساب لگانے کے لیے، RANDAO ویلیو کو سلاٹ نمبر کے ساتھ ملایا جاتا ہے تاکہ ہر سلاٹ میں ایک منفرد ویلیو حاصل ہو۔ کسی انفرادی ویلیڈیٹر کے منتخب ہونے کا امکان صرف `1/N` نہیں ہے (جہاں `N` = کل فعال ویلیڈیٹرز)۔ اس کے بجائے، اسے ہر ویلیڈیٹر کے مؤثر ETH بیلنس کے حساب سے وزن دیا جاتا ہے۔ زیادہ سے زیادہ مؤثر بیلنس 32 ETH ہے (اس کا مطلب ہے کہ `balance < 32 ETH` کا وزن `balance == 32 ETH` سے کم ہوتا ہے، لیکن `balance > 32 ETH` کا وزن `balance == 32 ETH` سے زیادہ نہیں ہوتا)۔ + +ہر سلاٹ میں صرف ایک بلاک پروپوزر منتخب کیا جاتا ہے۔ عام حالات میں، ایک واحد بلاک پروڈیوسر اپنے مخصوص سلاٹ میں ایک ہی بلاک بناتا اور جاری کرتا ہے۔ ایک ہی سلاٹ کے لیے دو بلاکس بنانا ایک سلیش ایبل جرم ہے، جسے اکثر "equivocation" کہا جاتا ہے۔ + +## بلاک کیسے بنایا جاتا ہے؟ {#how-is-a-block-created} + +بلاک پروپوزر سے توقع کی جاتی ہے کہ وہ اپنے مقامی طور پر چلنے والے فورک چوائس الگورتھم کے مطابق چین کے سب سے حالیہ ہیڈ پر بننے والے ایک دستخط شدہ بیکن بلاک کو براڈکاسٹ کرے۔ فورک چوائس الگورتھم پچھلے سلاٹ سے بچی ہوئی کسی بھی قطار میں لگی تصدیقوں کو لاگو کرتا ہے، پھر اپنی تاریخ میں تصدیقوں کے سب سے زیادہ جمع شدہ وزن والے بلاک کو تلاش کرتا ہے۔ وہ بلاک پروپوزر کے ذریعہ بنائے گئے نئے بلاک کا پیرنٹ ہوتا ہے۔ + +بلاک پروپوزر اپنے مقامی ڈیٹا بیس اور چین کے ویو سے ڈیٹا اکٹھا کرکے ایک بلاک بناتا ہے۔ بلاک کے مندرجات نیچے دیے گئے سنیپٹ میں دکھائے گئے ہیں: + +```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` ڈیپازٹ کنٹریکٹ کے بارے میں بلاک پروپوزر کے ویو کے لیے ایک ووٹ ہے، جس میں ڈیپازٹ مرکل ٹرائی کی روٹ اور ڈیپازٹس کی کل تعداد شامل ہے جو نئے ڈیپازٹس کی تصدیق کو ممکن بناتی ہے۔ `graffiti` ایک اختیاری فیلڈ ہے جسے بلاک میں پیغام شامل کرنے کے لیے استعمال کیا جا سکتا ہے۔ `proposer_slashings` اور `attester_slashings` وہ فیلڈز ہیں جن میں اس بات کا ثبوت ہوتا ہے کہ پروپوزر کے چین کے ویو کے مطابق کچھ ویلیڈیٹرز نے سلیش ایبل جرائم کیے ہیں۔ `deposits` نئے ویلیڈیٹر ڈیپازٹس کی ایک فہرست ہے جن سے بلاک پروپوزر واقف ہے، اور `voluntary_exits` ان ویلیڈیٹرز کی ایک فہرست ہے جو باہر نکلنا چاہتے ہیں جن کے بارے میں بلاک پروپوزر نے کنسینسس لیئر گاسپ نیٹ ورک پر سنا ہے۔ `sync_aggregate` ایک ویکٹر ہے جو یہ دکھاتا ہے کہ کن ویلیڈیٹرز کو پہلے ایک سنک کمیٹی (ویلیڈیٹرز کا ایک سب سیٹ جو لائٹ کلائنٹ ڈیٹا پیش کرتا ہے) کو تفویض کیا گیا تھا اور انہوں نے ڈیٹا پر دستخط کرنے میں حصہ لیا تھا۔ + +`execution_payload` ایگزیکیوشن اور کنسینسس کلائنٹس کے درمیان ٹرانزیکشنز کے بارے میں معلومات کو منتقل کرنے کے قابل بناتا ہے۔ `execution_payload` ایگزیکیوشن ڈیٹا کا ایک بلاک ہے جو ایک بیکن بلاک کے اندر نیسٹ کیا جاتا ہے۔ `execution_payload` کے اندر موجود فیلڈز Ethereum یلو پیپر میں بیان کردہ بلاک کی ساخت کی عکاسی کرتے ہیں، سوائے اس کے کہ کوئی اومرز نہیں ہیں اور `difficulty` کی جگہ `prev_randao` موجود ہے۔ ایگزیکیوشن کلائنٹ کو ٹرانزیکشنز کے ایک مقامی پول تک رسائی حاصل ہے جس کے بارے میں اس نے اپنے گاسپ نیٹ ورک پر سنا ہے۔ یہ ٹرانزیکشنز مقامی طور پر ایگزیکیوٹ کی جاتی ہیں تاکہ ایک اپ ڈیٹ شدہ اسٹیٹ ٹرائی تیار ہو سکے جسے پوسٹ اسٹیٹ کہا جاتا ہے۔ ٹرانزیکشنز کو `execution_payload` میں `transactions` نامی فہرست کے طور پر شامل کیا جاتا ہے اور پوسٹ اسٹیٹ `state-root` فیلڈ میں فراہم کیا جاتا ہے۔ + +یہ تمام ڈیٹا ایک بیکن بلاک میں جمع کیا جاتا ہے، اس پر دستخط کیے جاتے ہیں، اور بلاک پروپوزر کے پیئرز کو براڈکاسٹ کیا جاتا ہے، جو اسے اپنے پیئرز تک پھیلاتے ہیں، وغیرہ۔ + +[blocks کی اناٹومی](/developers/docs/blocks) کے بارے میں مزید پڑھیں۔ + +## بلاک کا کیا ہوتا ہے؟ {#what-happens-to-blocks} + +بلاک کو بلاک پروپوزر کے مقامی ڈیٹا بیس میں شامل کیا جاتا ہے اور کنسینسس لیئر گاسپ نیٹ ورک پر پیئرز کو براڈکاسٹ کیا جاتا ہے۔ جب ایک ویلیڈیٹر کو بلاک موصول ہوتا ہے، تو وہ اس کے اندر موجود ڈیٹا کی تصدیق کرتا ہے، جس میں یہ جانچنا شامل ہے کہ بلاک کا پیرنٹ درست ہے، یہ درست سلاٹ سے مطابقت رکھتا ہے، پروپوزر انڈیکس متوقع ہے، RANDAO ریویل درست ہے اور یہ کہ پروپوزر کو سلیش نہیں کیا گیا ہے۔ `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/) +- [Ethereum کنسینسس کی تفصیلات](https://github.com/ethereum/consensus-specs) +- [Gasper کا تعارف](/developers/docs/consensus-mechanisms/pos/gasper/) +- [Ethereum کو اپ گریڈ کرنا](https://eth2book.info/) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/faqs/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/faqs/index.md new file mode 100644 index 00000000000..169c1894116 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/faqs/index.md @@ -0,0 +1,172 @@ +--- +title: "اکثر پوچھے جانے والے سوالات" +description: "Proof-of-stake Ethereum پر اکثر پوچھے جانے والے سوالات۔" +lang: ur-in +--- + +## Proof-of-stake کیا ہے؟ {#what-is-proof-of-stake} + +Proof-of-stake ایک قسم کا الگورتھم ہے جو بلاک چینز کو سیکورٹی فراہم کر سکتا ہے یہ یقینی بنا کر کہ جو حملہ آور بددیانتی سے کام کرتے ہیں وہ اپنی قیمتی اثاثے کھو دیتے ہیں۔ Proof-of-stake سسٹمز کو ویلیڈیٹرز کے ایک سیٹ کی ضرورت ہوتی ہے تاکہ وہ کچھ اثاثے دستیاب کرائیں جنہیں تباہ کیا جا سکتا ہے اگر ویلیڈیٹر کسی ثابت شدہ بددیانت رویے میں ملوث ہو۔ Ethereum بلاک چین کو محفوظ بنانے کے لیے proof-of-stake میکانزم کا استعمال کرتا ہے۔ + +## Proof-of-stake کا موازنہ proof-of-work سے کیسے کیا جاتا ہے؟ {#comparison-to-proof-of-work} + +Proof-of-work اور proof-of-stake دونوں ایسے میکانزم ہیں جو بدنیتی پر مبنی اداکاروں کو نیٹ ورک کو اسپیم کرنے یا دھوکہ دہی سے معاشی طور پر روکتے ہیں۔ دونوں صورتوں میں، جو نوڈس اتفاق رائے میں فعال طور پر حصہ لیتے ہیں وہ کچھ اثاثہ "نیٹ ورک میں" ڈالتے ہیں جسے وہ بدسلوکی کرنے پر کھو دیں گے۔ + +Proof-of-work میں، یہ اثاثہ توانائی ہے۔ نوڈ، جسے مائنر کہا جاتا ہے، ایک الگورتھم چلاتا ہے جس کا مقصد کسی بھی دوسرے نوڈ سے زیادہ تیزی سے ایک قدر کا حساب لگانا ہے۔ سب سے تیز نوڈ کو چین میں ایک بلاک تجویز کرنے کا حق ہے۔ چین کی تاریخ کو تبدیل کرنے یا بلاک کی تجویز پر غلبہ حاصل کرنے کے لیے، ایک مائنر کے پاس اتنی کمپیوٹنگ طاقت ہونی چاہیے کہ وہ ہمیشہ ریس جیتے۔ یہ ممنوعہ طور پر مہنگا اور عمل میں لانا مشکل ہے، جو چین کو حملوں سے بچاتا ہے۔ Proof-of-work کا استعمال کرتے ہوئے "مائن" کرنے کے لیے درکار توانائی ایک حقیقی دنیا کا اثاثہ ہے جس کے لیے مائنرز ادائیگی کرتے ہیں۔ + +Proof-of-stake میں نوڈس، جنہیں ویلیڈیٹرز کہا جاتا ہے، کو واضح طور پر ایک سمارٹ کنٹریکٹ میں کرپٹو اثاثہ جمع کرنے کی ضرورت ہوتی ہے۔ اگر کوئی ویلیڈیٹر بدسلوکی کرتا ہے، تو اس کرپٹو کو تباہ کیا جا سکتا ہے کیونکہ وہ توانائی کے اخراجات کے ذریعے بالواسطہ طور پر اپنے اثاثوں کو چین میں "اسٹیک" کر رہے ہیں۔ + +Proof-of-work بہت زیادہ توانائی کا بھوکا ہے کیونکہ کان کنی کے عمل میں بجلی جلتی ہے۔ دوسری طرف، Proof-of-stake کے لیے صرف بہت کم توانائی کی ضرورت ہوتی ہے - Ethereum ویلیڈیٹرز Raspberry Pi جیسے کم طاقت والے ڈیوائس پر بھی چل سکتے ہیں۔ Ethereum کا proof-of-stake میکانزم proof-of-work سے زیادہ محفوظ سمجھا جاتا ہے کیونکہ حملہ کرنے کی لاگت زیادہ ہوتی ہے، اور حملہ آور کے لیے نتائج زیادہ سنگین ہوتے ہیں۔ + +Proof-of-work بمقابلہ proof-of-stake ایک متنازعہ موضوع ہے۔ [Vitalik Buterin کا بلاگ](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) اور جسٹن ڈریک اور لن ایلڈن کے درمیان بحث دلائل کا ایک اچھا خلاصہ پیش کرتی ہے۔ + + + +## کیا proof-of-stake توانائی کے لحاظ سے موثر ہے؟ {#is-pos-energy-efficient} + +جی ہاں. ایک proof-of-stake نیٹ ورک پر نوڈس بہت کم توانائی استعمال کرتے ہیں۔ ایک تھرڈ پارٹی مطالعہ نے یہ نتیجہ اخذ کیا کہ پورا proof-of-stake Ethereum نیٹ ورک تقریباً 0.0026 TWh/yr استعمال کرتا ہے - جو صرف امریکہ میں گیمنگ سے تقریباً 13,000 گنا کم ہے۔ + +[Ethereum کی توانائی کی کھپت پر مزید](/energy-consumption/)۔ + +## کیا proof-of-stake محفوظ ہے؟ {#is-pos-secure} + +Ethereum کا proof-of-stake بہت محفوظ ہے۔ اس میکانزم پر لائیو ہونے سے پہلے آٹھ سال سے زیادہ عرصے تک سختی سے تحقیق، ترقی اور جانچ کی گئی۔ سیکورٹی کی ضمانتیں proof-of-work بلاک چینز سے مختلف ہیں۔ Proof-of-stake میں، بدنیتی پر مبنی ویلیڈیٹرز کو فعال طور پر سزا دی جا سکتی ہے ("slashed") اور ویلیڈیٹر سیٹ سے نکال دیا جا سکتا ہے، جس پر ETH کی کافی مقدار خرچ ہوتی ہے۔ Proof-of-work کے تحت، ایک حملہ آور اپنے حملے کو دہراتا رہ سکتا ہے جب تک کہ ان کے پاس کافی ہیش پاور ہو۔ Proof-of-work کے تحت کے مقابلے میں proof-of-stake Ethereum پر مساوی حملے کرنا بھی زیادہ مہنگا ہے۔ چین کی لائیونیس کو متاثر کرنے کے لیے، نیٹ ورک پر کل اسٹیک شدہ ایتھر کا کم از کم 33% درکار ہے (انتہائی پیچیدہ حملوں کے معاملات کے علاوہ جن کی کامیابی کا امکان انتہائی کم ہے)۔ مستقبل کے بلاکس کے مواد کو کنٹرول کرنے کے لیے، کل اسٹیک شدہ ETH کا کم از کم 51% درکار ہے، اور تاریخ کو دوبارہ لکھنے کے لیے، کل اسٹیک کے 66% سے زیادہ کی ضرورت ہے۔ Ethereum پروٹوکول ان اثاثوں کو 33% یا 51% حملے کے منظرناموں میں اور 66% حملے کے منظر نامے میں سماجی اتفاق رائے سے تباہ کر دے گا۔ + +- [حملہ آوروں سے Ethereum proof-of-stake کے دفاع پر مزید](/developers/docs/consensus-mechanisms/pos/attack-and-defense) +- [Proof-of-stake ڈیزائن پر مزید](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) + +## کیا proof-of-stake Ethereum کو سستا بناتا ہے؟ {#does-pos-make-ethereum-cheaper} + +نہیں. ٹرانزیکشن بھیجنے کی لاگت (گیس فیس) کا تعین ایک متحرک فیس مارکیٹ سے ہوتا ہے جو نیٹ ورک کی زیادہ مانگ کے ساتھ بڑھتا ہے۔ اتفاق رائے کا طریقہ کار اس پر براہ راست اثر انداز نہیں ہوتا ہے۔ + +[گیس پر مزید](/developers/docs/gas)۔ + +## نوڈس، کلائنٹس اور ویلیڈیٹرز کیا ہیں؟ {#what-are-nodes-clients-and-validators} + +نوڈس Ethereum نیٹ ورک سے جڑے ہوئے کمپیوٹر ہیں۔ کلائنٹس وہ سافٹ ویئر ہیں جو وہ چلاتے ہیں جو کمپیوٹر کو نوڈ میں بدل دیتا ہے۔ کلائنٹس کی دو قسمیں ہیں: ایگزیکیوشن کلائنٹس اور کنسینسس کلائنٹس۔ نوڈ بنانے کے لیے دونوں کی ضرورت ہے۔ ایک ویلیڈیٹر کنسینسس کلائنٹ کے لیے ایک اختیاری ایڈ آن ہے جو نوڈ کو proof-of-stake کنسینسس میں حصہ لینے کے قابل بناتا ہے۔ اس کا مطلب ہے منتخب ہونے پر بلاکس بنانا اور تجویز کرنا اور نیٹ ورک پر جن بلاکس کے بارے میں وہ سنتے ہیں ان کی تصدیق کرنا۔ ویلیڈیٹر چلانے کے لیے، نوڈ آپریٹر کو ڈپازٹ کنٹریکٹ میں 32 ETH جمع کرنا ضروری ہے۔ + +- [نوڈس اور کلائنٹس پر مزید](/developers/docs/nodes-and-clients) +- [اسٹیکنگ پر مزید](/staking) + +## کیا proof-of-stake ایک نیا خیال ہے؟ {#is-pos-new} + +نہیں. BitcoinTalk پر ایک صارف نے 2011 میں Bitcoin کے اپ گریڈ کے طور پر [proof-of-stake کا بنیادی خیال پیش کیا](https://bitcointalk.org/index.php?topic=27787.0)۔ Ethereum Mainnet پر عمل درآمد کے لیے تیار ہونے میں گیارہ سال لگے۔ کچھ دیگر چینوں نے Ethereum سے پہلے proof-of-stake نافذ کیا، لیکن Ethereum کا مخصوص طریقہ کار نہیں (جسے Gasper کہا جاتا ہے)۔ + +## Ethereum کے proof-of-stake میں کیا خاص ہے؟ {#why-is-ethereum-pos-special} + +Ethereum کا proof-of-stake میکانزم اپنے ڈیزائن میں منفرد ہے۔ یہ ڈیزائن اور نافذ کیا جانے والا پہلا proof-of-stake میکانزم نہیں تھا، لیکن یہ سب سے زیادہ مضبوط ہے۔ Proof-of-stake میکانزم کو "Casper" کہا جاتا ہے۔ Casper یہ بتاتا ہے کہ بلاکس تجویز کرنے کے لیے ویلیڈیٹرز کا انتخاب کیسے کیا جاتا ہے، تصدیق کب اور کیسے کی جاتی ہے، تصدیق کی گنتی کیسے کی جاتی ہے، ویلیڈیٹرز کو دیے جانے والے انعامات اور جرمانے، سلیشنگ کی شرائط، فیل سیف میکانزم جیسے کہ غیر فعال لیک، اور "فائنیلٹی" کی شرائط۔ حتمیت ایک ایسی شرط ہے کہ ایک بلاک کو کینونیکل چین کا مستقل حصہ سمجھا جائے اس کے لیے نیٹ ورک پر کل اسٹیک شدہ ETH کے کم از کم 66% کے ذریعے ووٹ دیا جانا چاہیے۔ محققین نے Casper کو خاص طور پر Ethereum کے لیے تیار کیا، اور Ethereum اسے نافذ کرنے والا پہلا اور واحد بلاک چین ہے۔ + +Casper کے علاوہ، Ethereum کا proof-of-stake ایک فورک چوائس الگورتھم کا استعمال کرتا ہے جسے LMD-GHOST کہا جاتا ہے۔ اس کی ضرورت اس صورت میں ہوتی ہے جب کوئی ایسی حالت پیدا ہو جائے جہاں ایک ہی سلاٹ کے لیے دو بلاکس موجود ہوں۔ یہ بلاک چین کے دو فورک بناتا ہے۔ LMD-GHOST اس کو چنتا ہے جس میں تصدیق کا سب سے زیادہ "وزن" ہوتا ہے۔ وزن ویلیڈیٹرز کے موثر بیلنس سے وزنی تصدیق کی تعداد ہے۔ LMD-GHOST Ethereum کے لیے منفرد ہے۔ + +Casper اور LMD_GHOST کے امتزاج کو Gasper کہا جاتا ہے۔ + +[Gasper پر مزید](/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} + +اسٹیک گرائنڈنگ proof-of-stake نیٹ ورکس پر حملے کی ایک قسم ہے جہاں حملہ آور ویلیڈیٹر سلیکشن الگورتھم کو اپنے ویلیڈیٹرز کے حق میں متعصب کرنے کی کوشش کرتا ہے۔ 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) +- [Vitalik Buterin آن سوشل سلیشنگ](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) + +## nothing-at-stake مسئلہ کیا ہے؟ {#what-is-nothing-at-stake-problem} + +nothing-at-stake مسئلہ کچھ proof-of-stake میکانزم کے ساتھ ایک تصوراتی مسئلہ ہے جہاں صرف انعامات ہوتے ہیں اور کوئی جرمانہ نہیں ہوتا ہے۔ اگر داؤ پر کچھ نہیں ہے تو، ایک عملی ویلیڈیٹر بلاک چین کے کسی بھی، یا یہاں تک کہ متعدد، فورکس کی تصدیق کرنے میں یکساں طور پر خوش ہے، کیونکہ اس سے ان کے انعامات میں اضافہ ہوتا ہے۔ Ethereum ایک کینونیکل چین کو یقینی بنانے کے لیے حتمی شرائط اور سلیشنگ کا استعمال کرتے ہوئے اس سے بچتا ہے۔ + +[nothing-at-stake مسئلے پر مزید](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} + +ایک فورک چوائس الگورتھم ان اصولوں کو نافذ کرتا ہے جو یہ تعین کرتے ہیں کہ کون سی چین کینونیکل ہے۔ بہترین حالات میں، فورک چوائس کے اصول کی کوئی ضرورت نہیں ہے کیونکہ فی سلاٹ صرف ایک بلاک پروپوزر ہے اور اس میں سے انتخاب کرنے کے لیے ایک بلاک ہے۔ تاہم، کبھی کبھار، ایک ہی سلاٹ کے لیے متعدد بلاکس یا دیر سے پہنچنے والی معلومات اس بات کے لیے متعدد اختیارات کا باعث بنتی ہیں کہ چین کے سر کے قریب بلاکس کو کیسے منظم کیا جاتا ہے۔ ان صورتوں میں، تمام کلائنٹس کو کچھ اصولوں کو یکساں طور پر نافذ کرنا چاہیے تاکہ یہ یقینی بنایا جا سکے کہ وہ سب بلاکس کی صحیح ترتیب کا انتخاب کرتے ہیں۔ فورک چوائس الگورتھم ان اصولوں کو انکوڈ کرتا ہے۔ + +Ethereum کا فورک چوائس الگورتھم LMD-GHOST کہلاتا ہے۔ یہ سب سے زیادہ وزن والے تصدیق کے ساتھ فورک کو چنتا ہے، یعنی جس کے لیے سب سے زیادہ اسٹیک شدہ ETH نے ووٹ دیا ہے۔ + +[LMD-GHOST پر مزید](/developers/docs/consensus-mechanisms/pos/gasper/#fork-choice) + +## Proof-of-stake میں حتمیت کیا ہے؟ {#what-is-finality} + +Proof-of-stake میں حتمیت اس بات کی ضمانت ہے کہ ایک دیا گیا بلاک کینونیکل چین کا مستقل حصہ ہے اور اسے اس وقت تک واپس نہیں کیا جا سکتا جب تک کہ کوئی اتفاق رائے ناکام نہ ہو جائے جس میں حملہ آور کل اسٹیک شدہ ایتھر کا 33% جلا دیتا ہے۔ یہ "کرپٹو-اکنامک" حتمیت ہے، "پروبابلیسٹک فائنلٹی" کے برعکس جو proof-of-work بلاک چینز سے متعلق ہے۔ پروبابلیسٹک فائنلٹی میں، بلاکس کے لیے کوئی واضح حتمی/غیر حتمی حالتیں نہیں ہیں - یہ صرف اس بات کا امکان کم سے کم ہوتا جاتا ہے کہ ایک بلاک پرانا ہونے پر چین سے ہٹایا جا سکتا ہے، اور صارفین خود اس بات کا تعین کرتے ہیں کہ وہ کب کافی پراعتماد ہیں کہ ایک بلاک "محفوظ" ہے۔ کرپٹو-اکنامک حتمیت کے ساتھ، چیک پوائنٹ بلاکس کے جوڑوں کو 66% اسٹیک شدہ ایتھر کے ذریعے ووٹ دینا پڑتا ہے۔ اگر یہ شرط پوری ہو جاتی ہے، تو ان چیک پوائنٹس کے درمیان والے بلاکس کو واضح طور پر "فائنلائزڈ" کر دیا جاتا ہے۔ + +[حتمیت پر مزید](/developers/docs/consensus-mechanisms/pos/#finality) + +## "کمزور موضوعیت" کیا ہے؟ {#what-is-weak-subjectivity} + +کمزور موضوعیت proof-of-stake نیٹ ورکس کی ایک خصوصیت ہے جہاں بلاک چین کی موجودہ حالت کی تصدیق کے لیے سماجی معلومات کا استعمال کیا جاتا ہے۔ نئے نوڈس یا نوڈس جو طویل عرصے تک آف لائن رہنے کے بعد نیٹ ورک میں دوبارہ شامل ہو رہے ہیں انہیں حالیہ حالت دی جا سکتی ہے تاکہ نوڈ فوری طور پر دیکھ سکے کہ آیا وہ صحیح چین پر ہیں۔ ان حالتوں کو "کمزور موضوعیت چیک پوائنٹس" کے نام سے جانا جاتا ہے اور انہیں دوسرے نوڈ آپریٹرز سے آؤٹ آف بینڈ، یا بلاک ایکسپلوررز سے، یا کئی عوامی اختتامی پوائنٹس سے حاصل کیا جا سکتا ہے۔ + +[کمزور موضوعیت پر مزید](/developers/docs/consensus-mechanisms/pos/weak-subjectivity) + +## کیا proof-of-stake سنسر شپ مزاحم ہے؟ {#is-pos-censorship-resistant} + +سنسر شپ مزاحمت کو فی الحال ثابت کرنا مشکل ہے۔ تاہم، proof-of-work کے برعکس، proof-of-stake سنسر کرنے والے ویلیڈیٹرز کو سزا دینے کے لیے سلیشنگ کو مربوط کرنے کا اختیار پیش کرتا ہے۔ پروٹوکول میں آنے والی تبدیلیاں ہیں جو بلاک بلڈرز کو بلاک پروپوزر سے الگ کرتی ہیں اور ٹرانزیکشنز کی فہرستیں نافذ کرتی ہیں جنہیں بلڈرز کو ہر بلاک میں شامل کرنا ضروری ہے۔ اس تجویز کو پروپر بلڈر سیپریشن کہا جاتا ہے اور یہ ویلیڈیٹرز کو ٹرانزیکشنز کو سنسر کرنے سے روکنے میں مدد کرتا ہے۔ + +[پروپوزر-بلڈر علیحدگی پر مزید](https://notes.ethereum.org/@fradamt/H1TsYRfJc#Original-basic-scheme) + +## کیا Ethereum کے proof-of-stake سسٹم پر 51% حملہ ہو سکتا ہے؟ {#pos-51-attack} + +جی ہاں. Proof-of-stake 51% حملوں کے لیے کمزور ہے، بالکل proof-of-work کی طرح۔ حملہ آور کو نیٹ ورک کی 51% ہیش پاور کی ضرورت کے بجائے، حملہ آور کو کل اسٹیک شدہ ETH کا 51% درکار ہے۔ ایک حملہ آور جو کل اسٹیک کا 51% جمع کرتا ہے اسے فورک چوائس الگورتھم کو کنٹرول کرنے کا موقع ملتا ہے۔ یہ حملہ آور کو بعض ٹرانزیکشنز کو سنسر کرنے، شارٹ رینج ری آرگس کرنے اور اپنے حق میں بلاکس کو دوبارہ ترتیب دے کر MEV نکالنے کے قابل بناتا ہے۔ + +[proof-of-stake پر حملوں پر مزید](/developers/docs/consensus-mechanisms/pos/attack-and-defense) + +## سماجی ہم آہنگی کیا ہے، اور اس کی ضرورت کیوں ہے؟ {#what-is-social-coordination} + +سماجی ہم آہنگی Ethereum کے لیے دفاع کی آخری لائن ہے جو ایک ایماندار چین کو ایک ایسے حملے سے بازیافت کرنے کی اجازت دے گی جس نے بے ایمان بلاکس کو حتمی شکل دی تھی۔ اس معاملے میں، Ethereum کمیونٹی کو "آؤٹ آف بینڈ" کوآرڈینیٹ کرنا ہوگا اور ایک ایماندار اقلیتی فورک استعمال کرنے پر اتفاق کرنا ہوگا، اس عمل میں حملہ آور کے ویلیڈیٹرز کو سلیش کرنا ہوگا۔ اس کے لیے ایپس اور ایکسچینجز کو بھی ایماندار فورک کو تسلیم کرنے کی ضرورت ہوگی۔ + +[سماجی ہم آہنگی پر مزید پڑھیں](/developers/docs/consensus-mechanisms/pos/attack-and-defense#people-the-last-line-of-defense) + +## کیا proof-of-stake میں امیر اور امیر ہو جاتا ہے؟ {#do-rich-get-richer} + +کسی کے پاس جتنا زیادہ ETH اسٹیک کرنے کے لیے ہوگا، وہ اتنے ہی زیادہ ویلیڈیٹرز چلا سکتا ہے، اور اتنے ہی زیادہ انعامات وہ حاصل کر سکتا ہے۔ انعامات اسٹیک شدہ ETH کی رقم کے ساتھ لکیری طور پر بڑھتے ہیں، اور ہر ایک کو یکساں فیصد منافع ملتا ہے۔ Proof-of-work امیروں کو proof-of-stake سے زیادہ مالا مال کرتا ہے کیونکہ امیر کان کن جو بڑے پیمانے پر ہارڈویئر خریدتے ہیں وہ پیمانے کی معیشتوں سے فائدہ اٹھاتے ہیں، یعنی دولت اور انعام کے درمیان تعلق غیر لکیری ہے۔ + +## کیا proof-of-stake proof-of-work سے زیادہ مرکزیت رکھتا ہے؟ {#is-pos-decentralized} + +نہیں، proof-of-work مرکزیت کی طرف مائل ہوتا ہے کیونکہ کان کنی کے اخراجات بڑھتے ہیں اور افراد کو قیمت سے باہر کر دیتے ہیں، پھر چھوٹی کمپنیوں کو قیمت سے باہر کر دیتے ہیں، وغیرہ۔ proof-of-stake کے ساتھ موجودہ مسئلہ مائع اسٹیکنگ ڈیریویٹوز (LSDs) کا اثر ہے۔ یہ ٹوکنز ہیں جو کسی فراہم کنندہ کے ذریعے اسٹیک کیے گئے ETH کی نمائندگی کرتے ہیں جسے کوئی بھی ثانوی بازاروں میں تبادلہ کر سکتا ہے بغیر اصل ETH کو ان اسٹیک کیے۔ LSDs صارفین کو 32 ETH سے کم کے ساتھ اسٹیک کرنے کی اجازت دیتے ہیں، لیکن وہ مرکزیت کا خطرہ بھی پیدا کرتے ہیں جہاں چند بڑی تنظیمیں زیادہ تر اسٹیک کو کنٹرول کر سکتی ہیں۔ یہی وجہ ہے کہ [سولو اسٹیکنگ](/staking/solo) Ethereum کے لیے بہترین آپشن ہے۔ + +[LSDs میں اسٹیک سنٹرلائزیشن پر مزید](https://notes.ethereum.org/@djrtwo/risks-of-lsd) + +## میں صرف ETH کیوں اسٹیک کر سکتا ہوں؟ {#why-can-i-only-stake-eth} + +ETH Ethereum کی مقامی کرنسی ہے۔ یہ ضروری ہے کہ ایک واحد کرنسی ہو جس میں تمام اسٹیکز کو نامزد کیا گیا ہو، دونوں ووٹوں اور سیکیورٹی کے وزن کے لیے موثر بیلنس کا حساب کتاب کرنے کے لیے۔ ETH خود ایک سمارٹ کنٹریکٹ کے بجائے Ethereum کا ایک بنیادی جزو ہے۔ دیگر کرنسیوں کو شامل کرنے سے پیچیدگی میں نمایاں اضافہ ہوگا اور اسٹیکنگ کی سیکیورٹی میں کمی آئے گی۔ + +## کیا Ethereum واحد proof-of-stake بلاک چین ہے؟ {#is-ethereum-the-only-pos-blockchain} + +نہیں، کئی proof-of-stake بلاک چینز ہیں۔ کوئی بھی Ethereum سے مماثل نہیں ہے؛ Ethereum کا proof-of-stake میکانزم منفرد ہے۔ + +## مرج کیا ہے؟ {#what-is-the-merge} + +مرج وہ لمحہ تھا جب Ethereum نے اپنے proof-of-work پر مبنی اتفاق رائے کے طریقہ کار کو بند کر دیا اور اپنے proof-of-stake پر مبنی اتفاق رائے کے طریقہ کار کو آن کر دیا۔ مرج 15 ستمبر 2022 کو ہوا۔ + +[مرج پر مزید](/roadmap/merge) + +## لائیونیس اور سیفٹی کیا ہیں؟ {#what-are-liveness-and-safety} + +لائیونیس اور سیفٹی ایک بلاک چین کے لیے دو بنیادی سیکورٹی خدشات ہیں۔ لائیونیس ایک حتمی چین کی دستیابی ہے۔ اگر چین کو حتمی شکل دینا بند ہو جائے یا صارفین آسانی سے اس تک رسائی حاصل نہ کر پائیں تو یہ لائیونیس کی ناکامیاں ہیں۔ رسائی کی انتہائی زیادہ لاگت کو بھی لائیونیس کی ناکامی سمجھا جا سکتا ہے۔ حفاظت سے مراد یہ ہے کہ چین پر حملہ کرنا کتنا مشکل ہے - یعنی متصادم چیک پوائنٹس کو حتمی شکل دینا۔ + +[Casper پیپر میں مزید پڑھیں](https://arxiv.org/pdf/1710.09437.pdf) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/gasper/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/gasper/index.md new file mode 100644 index 00000000000..c39eb6f68ac --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/gasper/index.md @@ -0,0 +1,52 @@ +--- +title: Gasper +description: "Gasper پروف آف اسٹیک میکانزم کی وضاحت۔" +lang: ur-in +--- + +Gasper, Casper the Friendly Finality Gadget (Casper-FFG) اور LMD-GHOST فورک چوائس الگورتھم کا ایک امتزاج ہے۔ یہ اجزاء مل کر پروف آف اسٹیک Ethereum کو محفوظ بنانے والا کنسینسس میکانزم بناتے ہیں۔ Casper وہ میکانزم ہے جو بعض بلاکس کو "finalized" میں اپ گریڈ کرتا ہے تاکہ نیٹ ورک میں نئے داخل ہونے والے اس بات پر یقین کر سکیں کہ وہ کینونیکل چین کو مطابقت پذیر کر رہے ہیں۔ فورک چوائس الگورتھم جمع شدہ ووٹوں کا استعمال اس بات کو یقینی بنانے کے لیے کرتا ہے کہ بلاک چین میں جب فورکس پیدا ہوں تو نوڈز آسانی سے درست کا انتخاب کر سکیں۔ + +**نوٹ** کریں کہ Gasper میں شمولیت کے لیے Casper-FFG کی اصل تعریف کو قدرے اپ ڈیٹ کیا گیا تھا۔ اس صفحہ پر ہم اپ ڈیٹ کردہ ورژن پر غور کرتے ہیں۔ + +## شرائط + +اس مواد کو سمجھنے کے لیے [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos/) پر تعارفی صفحہ پڑھنا ضروری ہے۔ + +## Gasper کا کردار {#role-of-gasper} + +Gasper پروف آف اسٹیک بلاک چین کے اوپر ہے جہاں نوڈز سیکیورٹی ڈپازٹ کے طور پر ایتھر فراہم کرتے ہیں جسے تباہ کیا جا سکتا ہے اگر وہ بلاکس کی تجویز یا توثیق کرنے میں سست یا بے ایمان ہوں۔ Gasper وہ میکانزم ہے جو یہ بتاتا ہے کہ توثیق کاروں کو کس طرح انعام اور سزا دی جاتی ہے، یہ فیصلہ کرتا ہے کہ کون سے بلاکس کو قبول اور مسترد کرنا ہے، اور بلاک چین کے کس فورک پر تعمیر کرنا ہے۔ + +## حتمیت کیا ہے؟ {#what-is-finality} + +حتمیت بعض بلاکس کی ایک خصوصیت ہے جس کا مطلب ہے کہ انہیں اس وقت تک واپس نہیں کیا جا سکتا جب تک کہ کوئی اہم اتفاق رائے کی ناکامی نہ ہوئی ہو اور کسی حملہ آور نے کل اسٹیک شدہ ایتھر کا کم از کم 1/3 حصہ تباہ نہ کر دیا ہو۔ حتمی شکل دیے گئے بلاکس کو ایسی معلومات کے طور پر سمجھا جا سکتا ہے جس کے بارے میں بلاک چین کو یقین ہے۔ ایک بلاک کو حتمی شکل دینے کے لیے اسے دو قدمی اپ گریڈ کے طریقہ کار سے گزرنا ہوگا: + +1. کل اسٹیک شدہ ایتھر کے دو تہائی نے اس بلاک کو کینونیکل چین میں شامل کرنے کے حق میں ووٹ دیا ہو۔ یہ شرط بلاک کو "justified" میں اپ گریڈ کرتی ہے۔ جسٹیفائڈ بلاکس کے واپس ہونے کا امکان نہیں ہے، لیکن وہ کچھ شرائط کے تحت ہو سکتے ہیں۔ +2. جب کسی جسٹیفائڈ بلاک کے اوپر دوسرے بلاک کو جسٹیفائڈ کیا جاتا ہے، تو اسے "finalized" میں اپ گریڈ کیا جاتا ہے۔ بلاک کو حتمی شکل دینا اس بلاک کو کینونیکل چین میں شامل کرنے کا ایک عزم ہے۔ اسے اس وقت تک واپس نہیں کیا جا سکتا جب تک کہ کوئی حملہ آور لاکھوں ایتھر (اربوں $USD) تباہ نہ کر دے۔ + +یہ بلاک اپ گریڈ ہر سلاٹ میں نہیں ہوتے ہیں۔ اس کے بجائے، صرف ایپوک-باؤنڈری بلاکس کو جسٹیفائی اور فائنلائز کیا جا سکتا ہے۔ ان بلاکس کو "checkpoints" کے نام سے جانا جاتا ہے۔ اپ گریڈنگ چیک پوائنٹس کے جوڑوں پر غور کرتی ہے۔ دو لگاتار چیک پوائنٹس کے درمیان ایک "سپر میجورٹی لنک" موجود ہونا چاہیے (یعنی، کل اسٹیک شدہ ایتھر کے دو تہائی کا ووٹ دینا کہ چیک پوائنٹ B چیک پوائنٹ A کا صحیح جانشین ہے) تاکہ کم حالیہ چیک پوائنٹ کو فائنلائز کیا جا سکے اور زیادہ حالیہ بلاک کو جسٹیفائی کیا جا سکے۔ + +چونکہ حتمیت کے لیے دو تہائی معاہدے کی ضرورت ہوتی ہے کہ ایک بلاک کینونیکل ہے، اس لیے کوئی حملہ آور اس کے بغیر متبادل حتمی چین نہیں بنا سکتا: + +1. کل اسٹیک شدہ ایتھر کے دو تہائی کی ملکیت یا اس میں ہیرا پھیری کرنا۔ +2. کل اسٹیک شدہ ایتھر کا کم از کم ایک تہائی تباہ کرنا۔ + +پہلی شرط اس لیے پیدا ہوتی ہے کیونکہ ایک چین کو حتمی شکل دینے کے لیے اسٹیک شدہ ایتھر کے دو تہائی کی ضرورت ہوتی ہے۔ دوسری شرط اس لیے پیدا ہوتی ہے کیونکہ اگر کل اسٹیک کے دو تہائی نے دونوں فورکس کے حق میں ووٹ دیا ہے، تو ایک تہائی نے دونوں پر ووٹ دیا ہوگا۔ ڈبل ووٹنگ ایک سلیشنگ شرط ہے جس پر زیادہ سے زیادہ سزا دی جائے گی، اور کل اسٹیک کا ایک تہائی تباہ ہو جائے گا۔ مئی 2022 تک، اس کے لیے ایک حملہ آور کو تقریباً 10 بلین ڈالر مالیت کا ایتھر جلانے کی ضرورت ہے۔ Gasper میں بلاکس کو جسٹیفائی اور فائنلائز کرنے والا الگورتھم [Casper the Friendly Finality Gadget (Casper-FFG)](https://arxiv.org/pdf/1710.09437.pdf) کی قدرے ترمیم شدہ شکل ہے۔ + +### مراعات اور سلیشنگ {#incentives-and-slashing} + +توثیق کاروں کو ایمانداری سے بلاکس کی تجویز اور توثیق کرنے پر انعام ملتا ہے۔ ایتھر کا انعام دیا جاتا ہے اور ان کے اسٹیک میں شامل کیا جاتا ہے۔ دوسری طرف، وہ توثیق کار جو غیر حاضر ہیں اور بلائے جانے پر کام کرنے میں ناکام رہتے ہیں، ان انعامات سے محروم رہ جاتے ہیں اور کبھی کبھی اپنے موجودہ اسٹیک کا ایک چھوٹا سا حصہ کھو دیتے ہیں۔ تاہم، آف لائن ہونے کے جرمانے چھوٹے ہیں اور، زیادہ تر معاملات میں، انعامات سے محروم ہونے کی موقع کی لاگت کے برابر ہیں۔ تاہم، کچھ توثیق کار کے اعمال غلطی سے کرنا بہت مشکل ہیں اور کچھ بدنیتی پر مبنی ارادے کی نشاندہی کرتے ہیں، جیسے کہ ایک ہی سلاٹ کے لیے متعدد بلاکس کی تجویز دینا، ایک ہی سلاٹ کے لیے متعدد بلاکس کی تصدیق کرنا، یا پچھلے چیک پوائنٹ ووٹوں سے متصادم ہونا۔ یہ "سلیش ایبل" رویے ہیں جن پر زیادہ سختی سے سزا دی جاتی ہے—سلیشنگ کے نتیجے میں توثیق کار کے اسٹیک کا کچھ حصہ تباہ ہو جاتا ہے اور توثیق کار کو توثیق کاروں کے نیٹ ورک سے ہٹا دیا جاتا ہے۔ اس عمل میں 36 دن لگتے ہیں۔ پہلے دن، 1 ETH تک کا ابتدائی جرمانہ ہے۔ پھر سلیش شدہ توثیق کار کا ایتھر ایگزٹ پیریڈ کے دوران آہستہ آہستہ ختم ہو جاتا ہے، لیکن 18 ویں دن، انہیں ایک "کوریلیشن پینلٹی" ملتی ہے، جو اس وقت بڑی ہوتی ہے جب ایک ہی وقت میں زیادہ توثیق کاروں کو سلیش کیا جاتا ہے۔ زیادہ سے زیادہ جرمانہ پورا اسٹیک ہے۔ یہ انعامات اور جرمانے ایماندار توثیق کاروں کی حوصلہ افزائی اور نیٹ ورک پر حملوں کی حوصلہ شکنی کے لیے بنائے گئے ہیں۔ + +### غیرفعالیت کا لیک {#inactivity-leak} + +سیکیورٹی کے ساتھ ساتھ، Gasper "قابل فہم لائیونیس" بھی فراہم کرتا ہے۔ یہ وہ شرط ہے کہ جب تک کل اسٹیک شدہ ایتھر کا دو تہائی ایمانداری سے ووٹ دے رہا ہے اور پروٹوکول کی پیروی کر رہا ہے، چین کسی بھی دوسری سرگرمی (جیسے حملے، لیٹینسی کے مسائل، یا سلیشنگز) سے قطع نظر حتمی شکل دے سکے گا۔ دوسرے لفظوں میں، چین کو حتمی شکل دینے سے روکنے کے لیے کل اسٹیک شدہ ایتھر کے ایک تہائی کے ساتھ کسی نہ کسی طرح سمجھوتہ کرنا ہوگا۔ Gasper میں، لائیونیس کی ناکامی کے خلاف دفاع کی ایک اضافی لائن ہے، جسے "غیرفعالیت کا لیک" کہا جاتا ہے۔ یہ میکانزم اس وقت فعال ہوتا ہے جب چین چار سے زیادہ ایپوکس تک حتمی شکل دینے میں ناکام ہو جاتا ہے۔ وہ توثیق کار جو اکثریتی چین کی فعال طور پر تصدیق نہیں کر رہے ہیں، ان کا اسٹیک آہستہ آہستہ ختم ہو جاتا ہے جب تک کہ اکثریت کل اسٹیک کا دو تہائی دوبارہ حاصل نہ کر لے، اس بات کو یقینی بناتے ہوئے کہ لائیونیس کی ناکامیاں صرف عارضی ہیں۔ + +### فورک کا انتخاب {#fork-choice} + +Casper-FFG کی اصل تعریف میں ایک فورک چوائس الگورتھم شامل تھا جس نے یہ اصول نافذ کیا تھا: `اس چین کی پیروی کریں جس میں سب سے زیادہ اونچائی والا جسٹیفائیڈ چیک پوائنٹ ہو` جہاں اونچائی کی تعریف جینیسس بلاک سے سب سے زیادہ فاصلہ کے طور پر کی گئی ہے۔ Gasper میں، اصل فورک چوائس اصول کو LMD-GHOST نامی ایک زیادہ نفیس الگورتھم کے حق میں متروک کر دیا گیا ہے۔ یہ سمجھنا ضروری ہے کہ عام حالات میں، ایک فورک چوائس اصول غیر ضروری ہے - ہر سلاٹ کے لیے ایک ہی بلاک پروپوزر ہوتا ہے، اور ایماندار توثیق کار اس کی تصدیق کرتے ہیں۔ یہ صرف بڑے نیٹ ورک کی غیر مطابقت پذیری کے معاملات میں یا جب کسی بے ایمان بلاک پروپوزر نے گول مول بات کی ہو، تب ہی ایک فورک چوائس الگورتھم کی ضرورت ہوتی ہے۔ تاہم، جب ایسے معاملات پیدا ہوتے ہیں، تو فورک چوائس الگورتھم ایک اہم دفاع ہے جو درست چین کو محفوظ بناتا ہے۔ + +LMD-GHOST کا مطلب ہے "latest message-driven greedy heaviest observed sub-tree"۔ یہ ایک الگورتھم کی تعریف کرنے کا ایک جارگن سے بھرا طریقہ ہے جو تصدیقوں کے سب سے بڑے جمع شدہ وزن والے فورک کو کینونیکل کے طور پر منتخب کرتا ہے (greedy heaviest subtree) اور یہ کہ اگر کسی توثیق کار سے متعدد پیغامات موصول ہوتے ہیں، تو صرف تازہ ترین پر غور کیا جاتا ہے (latest-message driven)۔ سب سے بھاری بلاک کو اپنی کینونیکل چین میں شامل کرنے سے پہلے، ہر توثیق کار اس اصول کا استعمال کرتے ہوئے ہر بلاک کا جائزہ لیتا ہے۔ + +## مزید مطالعہ {#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/ur/developers/docs/consensus-mechanisms/pos/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/index.md new file mode 100644 index 00000000000..7636bc09a4b --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/index.md @@ -0,0 +1,99 @@ +--- +title: "اسٹیک کا ثبوت (PoS)" +description: "اسٹیک کے ثبوت والے اتفاق رائے پروٹوکول اور ایتھیریم میں اس کے کردار کی وضاحت۔" +lang: ur-in +--- + +اسٹیک کا ثبوت (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 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_ +- [ویڈیو: Vitalik Buterin لیکس فریڈمین کو اسٹیک کے ثبوت کی وضاحت کرتے ہوئے](https://www.youtube.com/watch?v=3yrqBG-7EVE) + +## متعلقہ موضوعات {#related-topics} + +- [ثبوتِ کار (Proof-of-work)](/developers/docs/consensus-mechanisms/pow/) +- [ثبوتِ اختیار (Proof-of-authority)](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/keys/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/keys/index.md new file mode 100644 index 00000000000..7926acfb137 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/keys/index.md @@ -0,0 +1,102 @@ +--- +title: "Proof-of-stake Ethereum میں کلیدیں" +description: "Ethereum کے proof-of-stake اتفاق رائے کے طریقہ کار میں استعمال ہونے والی کلیدوں کی وضاحت" +lang: ur-in +--- + +Ethereum پبلک-پرائیویٹ کلیدی کرپٹوگرافی کا استعمال کرتے ہوئے صارف کے اثاثوں کو محفوظ بناتا ہے۔ پبلک کلید کو Ethereum ایڈریس کی بنیاد کے طور پر استعمال کیا جاتا ہے—یعنی، یہ عام لوگوں کو نظر آتی ہے اور ایک منفرد شناخت کنندہ کے طور پر استعمال ہوتی ہے۔ پرائیویٹ (یا 'خفیہ') کلید صرف ایک اکاؤنٹ کے مالک کے لیے قابل رسائی ہونی چاہیے۔ پرائیویٹ کلید کا استعمال ٹرانزیکشنز اور ڈیٹا کو 'سائن' کرنے کے لیے کیا جاتا ہے تاکہ کرپٹوگرافی یہ ثابت کر سکے کہ ہولڈر ایک مخصوص پرائیویٹ کلید کی کچھ کارروائی کو منظور کرتا ہے۔ + +Ethereum کی کلیدیں [elliptic-curve cryptography](https://en.wikipedia.org/wiki/Elliptic-curve_cryptography) کا استعمال کرتے ہوئے تیار کی جاتی ہیں۔ + +تاہم، جب Ethereum نے [proof-of-work](/developers/docs/consensus-mechanisms/pow) سے [proof-of-stake](/developers/docs/consensus-mechanisms/pos) میں سوئچ کیا تو Ethereum میں ایک نئی قسم کی کلید شامل کی گئی۔ اصل کلیدیں اب بھی بالکل پہلے کی طرح کام کرتی ہیں—اکاؤنٹس کو محفوظ کرنے والی elliptic-curve-based کلیدوں میں کوئی تبدیلی نہیں کی گئی تھی۔ تاہم، صارفین کو ETH اسٹیک کرکے اور ویلیڈیٹرز چلا کر proof-of-stake میں حصہ لینے کے لیے ایک نئی قسم کی کلید کی ضرورت تھی۔ یہ ضرورت بڑی تعداد میں ویلیڈیٹرز کے درمیان گزرنے والے بہت سے پیغامات سے وابستہ اسکیل ایبلٹی چیلنجز سے پیدا ہوئی، جس کے لیے ایک ایسے کرپٹوگرافک طریقہ کی ضرورت تھی جسے آسانی سے جمع کیا جا سکے تاکہ نیٹ ورک کو اتفاق رائے پر آنے کے لیے درکار مواصلات کی مقدار کو کم کیا جا سکے۔ + +کلید کی یہ نئی قسم [**Boneh-Lynn-Shacham (BLS)** سگنیچر اسکیم](https://wikipedia.org/wiki/BLS_digital_signature) کا استعمال کرتی ہے۔ BLS دستخطوں کے بہت موثر جمع کرنے کو ممکن بناتا ہے لیکن مجموعی انفرادی ویلیڈیٹر کلیدوں کی ریورس انجینئرنگ کی بھی اجازت دیتا ہے اور ویلیڈیٹرز کے درمیان کارروائیوں کا انتظام کرنے کے لیے مثالی ہے۔ + +## ویلیڈیٹر کلیدوں کی دو اقسام {#two-types-of-keys} + +proof-of-stake میں سوئچ کرنے سے پہلے، Ethereum صارفین کے پاس اپنے فنڈز تک رسائی کے لیے صرف ایک ہی elliptic-curve-based پرائیویٹ کلید تھی۔ proof-of-stake کے تعارف کے ساتھ، جو صارفین سولو اسٹیکرز بننا چاہتے تھے انہیں ایک **ویلیڈیٹر کلید** اور ایک **وڈراول کلید** کی بھی ضرورت تھی۔ + +### ویلیڈیٹر کلید {#validator-key} + +ویلیڈیٹر سائننگ کلید دو عناصر پر مشتمل ہے: + +- ویلیڈیٹر **پرائیویٹ** کلید +- ویلیڈیٹر **پبلک** کلید + +ویلیڈیٹر پرائیویٹ کلید کا مقصد آن چین آپریشنز جیسے کہ بلاک پروپوزل اور اٹیسٹیشنز پر دستخط کرنا ہے۔ اس کی وجہ سے، ان کلیدوں کو ہاٹ والیٹ میں رکھا جانا چاہیے۔ + +اس لچک کا فائدہ یہ ہے کہ ویلیڈیٹر سائننگ کلیدوں کو ایک ڈیوائس سے دوسری ڈیوائس میں بہت تیزی سے منتقل کیا جا سکتا ہے، تاہم، اگر وہ گم ہو جائیں یا چوری ہو جائیں، تو چور چند طریقوں سے **بدنیتی سے کام** کر سکتا ہے: + +- ویلیڈیٹر کو سلیش کروا کر: + - ایک پروپوزر ہونے کے ناطے اور ایک ہی سلاٹ کے لیے دو مختلف بیکن بلاکس پر دستخط کرنا + - ایک اٹیسٹر ہونے کے ناطے اور ایک ایسے اٹیسٹیشن پر دستخط کرنا جو دوسرے کو "گھیرتا" ہے + - ایک اٹیسٹر ہونے کے ناطے اور ایک ہی ہدف والے دو مختلف اٹیسٹیشنز پر دستخط کرنا +- ایک رضاکارانہ اخراج پر مجبور کرنا، جو ویلیڈیٹر کو اسٹیکنگ سے روکتا ہے، اور اس کے ETH بیلنس تک رسائی وڈراول کلید کے مالک کو دیتا ہے + +جب کوئی صارف اسٹیکنگ ڈپازٹ کنٹریکٹ میں ETH جمع کرتا ہے تو **ویلیڈیٹر پبلک کلید** ٹرانزیکشن ڈیٹا میں شامل ہوتی ہے۔ اسے _ڈپازٹ ڈیٹا_ کے نام سے جانا جاتا ہے اور یہ Ethereum کو ویلیڈیٹر کی شناخت کرنے کی اجازت دیتا ہے۔ + +### وڈراول کریڈینشلز {#withdrawal-credentials} + +ہر ویلیڈیٹر کی ایک پراپرٹی ہوتی ہے جسے _وڈراول کریڈینشلز_ کہا جاتا ہے۔ اس 32 بائٹ فیلڈ کا پہلا بائٹ اکاؤنٹ کی قسم کی نشاندہی کرتا ہے: `0x00` اصل BLS (پری-شپیلا، نان-وڈراایبل) کریڈینشلز کی نمائندگی کرتا ہے، `0x01` لیگیسی کریڈینشلز کی نمائندگی کرتا ہے جو ایکزیکیوشن ایڈریس کی طرف اشارہ کرتے ہیں، اور `0x02` جدید کمپاؤنڈنگ کریڈینشل کی قسم کی نمائندگی کرتا ہے۔ + +`0x00` BLS کلیدوں والے ویلیڈیٹرز کو اضافی بیلنس کی ادائیگیوں یا اسٹیکنگ سے مکمل وڈراول کو فعال کرنے کے لیے ان کریڈینشلز کو ایکزیکیوشن ایڈریس کی طرف اشارہ کرنے کے لیے اپ ڈیٹ کرنا ہوگا۔ یہ ابتدائی کلیدی جنریشن کے دوران ڈپازٹ ڈیٹا میں ایکزیکیوشن ایڈریس فراہم کرکے، _یا_ بعد میں وڈراول کلید کا استعمال کرکے ایک `BLSToExecutionChange` پیغام پر دستخط کرنے اور براڈکاسٹ کرنے کے ذریعے کیا جا سکتا ہے۔ + +[ویلیڈیٹر وڈراول کریڈینشلز پر مزید](/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/) + +### وڈراول کلید {#withdrawal-key} + +اگر ابتدائی ڈپازٹ کے دوران سیٹ نہیں کیا گیا ہے، تو وڈراول کریڈینشلز کو ایکزیکیوشن ایڈریس کی طرف اشارہ کرنے کے لیے اپ ڈیٹ کرنے کے لیے وڈراول کلید کی ضرورت ہوگی۔ اس سے اضافی بیلنس کی ادائیگیوں پر کارروائی شروع ہو جائے گی، اور یہ صارفین کو اپنے اسٹیک شدہ ETH کو مکمل طور پر نکالنے کی بھی اجازت دے گا۔ + +ویلیڈیٹر کلیدوں کی طرح، وڈراول کلیدیں بھی دو اجزاء پر مشتمل ہوتی ہیں: + +- وڈراول **پرائیویٹ** کلید +- وڈراول **پبلک** کلید + +وڈراول کریڈینشلز کو `0x01` قسم میں اپ ڈیٹ کرنے سے پہلے اس کلید کو کھونے کا مطلب ویلیڈیٹر بیلنس تک رسائی کھو دینا ہے۔ ویلیڈیٹر اب بھی اٹیسٹیشنز اور بلاکس پر دستخط کر سکتا ہے کیونکہ ان کارروائیوں کے لیے ویلیڈیٹر کی پرائیویٹ کلید کی ضرورت ہوتی ہے، تاہم اگر وڈراول کلیدیں گم ہو جائیں تو اس میں کوئی ترغیب نہیں ہے۔ + +ویلیڈیٹر کلیدوں کو Ethereum اکاؤنٹ کی کلیدوں سے الگ کرنے سے ایک ہی صارف کے ذریعے متعدد ویلیڈیٹرز چلائے جا سکتے ہیں۔ + +![ویلیڈیٹر کلید کا اسکیمیٹک](validator-key-schematic.png) + +**نوٹ**: اسٹیکنگ کے فرائض سے باہر نکلنے اور ویلیڈیٹر کے بیلنس کو نکالنے کے لیے فی الحال ویلیڈیٹر کلید کے ساتھ [رضاکارانہ اخراج کے پیغام (VEM)](https://mirror.xyz/ladislaus.eth/wmoBbUBes2Wp1_6DvP6slPabkyujSU7MZOFOC3QpErs&1) پر دستخط کرنے کی ضرورت ہوتی ہے۔ تاہم، [EIP-7002](https://eips.ethereum.org/EIPS/eip-7002) ایک تجویز ہے جو مستقبل میں کسی صارف کو وڈراول کلید کے ساتھ اخراج کے پیغامات پر دستخط کرکے ویلیڈیٹر کے اخراج کو متحرک کرنے اور اس کے بیلنس کو نکالنے کی اجازت دے گی۔ اس سے ان اسٹیکرز کو اپنے فنڈز پر کنٹرول برقرار رکھنے کے قابل بنا کر اعتماد کے مفروضوں کو کم کیا جائے گا جو ETH کو [اسٹیکنگ-ایز-اے-سروس فراہم کنندگان](/staking/saas/#what-is-staking-as-a-service) کو تفویض کرتے ہیں۔ + +## ایک سیڈ فریز سے کلیدیں اخذ کرنا {#deriving-keys-from-seed} + +اگر ہر 32 ETH اسٹیک کرنے کے لیے 2 مکمل طور پر آزاد کلیدوں کے ایک نئے سیٹ کی ضرورت ہوتی، تو کلیدی انتظام تیزی سے بوجھل ہو جاتا، خاص طور پر متعدد ویلیڈیٹرز چلانے والے صارفین کے لیے۔ اس کے بجائے، متعدد ویلیڈیٹر کلیدیں ایک ہی مشترکہ راز سے اخذ کی جا سکتی ہیں اور اس ایک راز کو ذخیرہ کرنے سے متعدد ویلیڈیٹر کلیدوں تک رسائی کی اجازت ملتی ہے۔ + +[Mnemonics](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) حاصل کرتے وقت ہوتا ہے۔ نیمونک الفاظ کا ایک سلسلہ ہے جو پرائیویٹ کلید کے لیے ابتدائی سیڈ کے طور پر کام کرتا ہے۔ جب اضافی ڈیٹا کے ساتھ ملایا جاتا ہے، تو نیمونک ایک ہیش تیار کرتا ہے جسے 'ماسٹر کلید' کہا جاتا ہے۔ اسے ایک درخت کی جڑ کے طور پر سمجھا جا سکتا ہے۔ اس جڑ سے شاخیں پھر ایک درجہ بندی کے راستے کا استعمال کرتے ہوئے اخذ کی جا سکتی ہیں تاکہ چائلڈ نوڈس اپنے پیرنٹ نوڈ کے ہیش اور درخت میں ان کے انڈیکس کے امتزاج کے طور پر موجود رہ سکیں۔ نیمونک پر مبنی کلیدی جنریشن کے لیے [BIP-32](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) اور [BIP-19](https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki) معیارات کے بارے میں پڑھیں۔ + +ان پاتھز کی ساخت مندرجہ ذیل ہے، جو ان صارفین سے واقف ہوگی جنہوں نے ہارڈویئر والیٹس کے ساتھ تعامل کیا ہے: + +``` +m/44'/60'/0'/0` +``` + +اس پاتھ میں سلیش پرائیویٹ کلید کے اجزاء کو مندرجہ ذیل طور پر الگ کرتے ہیں: + +``` +ماسٹر_کلید / مقصد / کوائن_قسم / اکاؤنٹ / تبدیلی / ایڈریس_انڈیکس +``` + +یہ منطق صارفین کو ایک ہی **نیمونک فریز** سے زیادہ سے زیادہ ویلیڈیٹرز منسلک کرنے کے قابل بناتی ہے کیونکہ درخت کی جڑ مشترک ہو سکتی ہے، اور شاخوں پر تفریق ہو سکتی ہے۔ صارف نیمونک فریز سے **کتنی بھی تعداد میں کلیدیں اخذ** کر سکتا ہے۔ + +``` + [m / 0] + / + / +[m] - [m / 1] + \ + \ + [m / 2] +``` + +ہر شاخ کو `/` سے الگ کیا جاتا ہے لہذا `m/2` کا مطلب ہے ماسٹر کلید سے شروع کریں اور شاخ 2 کی پیروی کریں۔ نیچے دیے گئے اسکیمیٹک میں ایک ہی نیمونک فریز کا استعمال تین وڈراول کلیدوں کو ذخیرہ کرنے کے لیے کیا گیا ہے، جن میں سے ہر ایک کے ساتھ دو منسلک ویلیڈیٹرز ہیں۔ + +![ویلیڈیٹر کلیدی منطق](multiple-keys.png) + +## مزید پڑھیں {#further-reading} + +- [کارل بیکھوئزن کا Ethereum فاؤنڈیشن بلاگ پوسٹ](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/ur/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/pos-vs-pow/index.md new file mode 100644 index 00000000000..cf4a0eefb08 --- /dev/null +++ b/public/content/translations/ur/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 پر مبنی consensus mechanism کے درمیان ایک موازنہ" +lang: ur-in +--- + +جب Ethereum لانچ ہوا، تو proof-of-stake کو Ethereum کو محفوظ بنانے کے لیے بھروسہ کیے جانے سے پہلے بہت زیادہ تحقیق اور ترقی کی ضرورت تھی۔ Proof-of-work ایک آسان میکانزم تھا جسے Bitcoin نے پہلے ہی ثابت کر دیا تھا، جس کا مطلب ہے کہ بنیادی ڈیولپرز Ethereum کو لانچ کرنے کے لیے اسے فوراً نافذ کر سکتے تھے۔ Proof-of-stake کو اس مقام تک پہنچانے میں مزید آٹھ سال لگے جہاں اسے نافذ کیا جا سکتا تھا۔ + +یہ صفحہ Ethereum کے proof-of-work سے proof-of-stake میں سوئچ کرنے کے پیچھے کی منطق اور اس میں شامل تجارتی سمجھوتوں کی وضاحت کرتا ہے۔ + +## سیکیورٹی {#security} + +Ethereum کے محققین proof-of-stake کو proof-of-work سے زیادہ محفوظ سمجھتے ہیں۔ تاہم، اسے حال ہی میں حقیقی Ethereum Mainnet کے لیے نافذ کیا گیا ہے اور یہ proof-of-work کے مقابلے میں کم وقت کا ثابت شدہ ہے۔ مندرجہ ذیل حصے proof-of-work کے مقابلے میں proof-of-stake کے سیکورٹی ماڈل کے فوائد اور نقصانات پر تبادلہ خیال کرتے ہیں۔ + +### حملہ کرنے کی لاگت {#cost-to-attack} + +Proof-of-stake میں، ویلیڈیٹرز کو ایک سمارٹ کنٹریکٹ میں کم از کم 32 ETH ایسکرو ("stake") کرنا ہوتا ہے۔ Ethereum غلط برتاؤ کرنے والے ویلیڈیٹرز کو سزا دینے کے لیے اسٹیک شدہ ایتھر کو تباہ کر سکتا ہے۔ اتفاق رائے پر پہنچنے کے لیے، کل اسٹیک شدہ ایتھر کا کم از کم 66% حصہ بلاکس کے ایک خاص سیٹ کے حق میں ووٹ دینا ہوتا ہے۔ >=66% اسٹیک کے ذریعے ووٹ دیے گئے بلاکس "حتمی" ہو جاتے ہیں، جس کا مطلب ہے کہ انہیں ہٹایا یا دوبارہ منظم نہیں کیا جا سکتا۔ + +نیٹ ورک پر حملہ کرنے کا مطلب ہو سکتا ہے چین کو حتمی شکل دینے سے روکنا یا کینونیکل چین میں بلاکس کی ایک خاص تنظیم کو یقینی بنانا جس سے کسی حملہ آور کو کسی طرح سے فائدہ پہنچے۔ اس کے لیے حملہ آور کو بڑی مقدار میں ایتھر جمع کرکے اور اس کے ساتھ براہ راست ووٹ دے کر یا ایماندار ویلیڈیٹرز کو کسی خاص طریقے سے ووٹ دینے کے لیے دھوکہ دے کر ایماندار اتفاق رائے کے راستے کو موڑنے کی ضرورت ہوتی ہے۔ ایماندار ویلیڈیٹرز کو دھوکہ دینے والے نفیس، کم امکانی حملوں کے علاوہ، Ethereum پر حملہ کرنے کی لاگت اس اسٹیک کی لاگت ہے جو ایک حملہ آور کو اپنے حق میں اتفاق رائے کو متاثر کرنے کے لیے جمع کرنا پڑتا ہے۔ + +حملے کی سب سے کم لاگت کل اسٹیک کا 33% سے زیادہ ہے۔ کل اسٹیک کا 33% سے زیادہ رکھنے والا حملہ آور صرف آف لائن ہو کر حتمیت میں تاخیر کا سبب بن سکتا ہے۔ یہ نیٹ ورک کے لیے نسبتاً معمولی مسئلہ ہے کیونکہ ایک میکانزم ہے جسے "inactivity leak" کے نام سے جانا جاتا ہے جو آف لائن ویلیڈیٹرز سے اسٹیک کو اس وقت تک لیک کرتا ہے جب تک کہ آن لائن اکثریت اسٹیک کے 66% کی نمائندگی نہ کرے اور چین کو دوبارہ حتمی شکل دے سکے۔ یہ بھی نظریاتی طور پر ممکن ہے کہ ایک حملہ آور کل اسٹیک کے 33% سے تھوڑا زیادہ کے ساتھ دوہری حتمیت کا سبب بنے جب انہیں بلاک پروڈیوسر بننے کے لیے کہا جائے تو ایک کے بجائے دو بلاکس بنا کر اور پھر اپنے تمام ویلیڈیٹرز کے ساتھ ڈبل ووٹ دے کر۔ ہر فورک کو صرف 50% باقی ایماندار ویلیڈیٹرز کی ضرورت ہوتی ہے کہ وہ ہر بلاک کو پہلے دیکھیں، لہذا اگر وہ اپنے پیغامات کو صحیح وقت پر منظم کرنے میں کامیاب ہو جاتے ہیں، تو وہ دونوں فورکس کو حتمی شکل دے سکتے ہیں۔ اس کی کامیابی کا امکان کم ہے، لیکن اگر کوئی حملہ آور دوہری حتمیت کا سبب بننے میں کامیاب ہو جاتا ہے، تو Ethereum کمیونٹی کو ایک فورک کی پیروی کرنے کا فیصلہ کرنا پڑے گا، جس صورت میں حملہ آور کے ویلیڈیٹرز کو دوسرے پر لازمی طور پر سلیش کر دیا جائے گا۔ + +کل اسٹیک کے 33% سے زیادہ کے ساتھ، ایک حملہ آور کے پاس Ethereum نیٹ ورک پر معمولی (حتمیت میں تاخیر) یا زیادہ شدید (دوہری حتمیت) اثر ڈالنے کا موقع ہوتا ہے۔ نیٹ ورک پر 14,000,000 سے زیادہ ETH اسٹیک ہونے اور 1000$/ETH کی نمائندہ قیمت کے ساتھ، ان حملوں کو کرنے کی کم از کم لاگت `1000 x 14,000,000 x 0.33 = $4,620,000,000` ہے۔ حملہ آور یہ رقم سلیشنگ کے ذریعے کھو دے گا اور اسے نیٹ ورک سے نکال دیا جائے گا۔ دوبارہ حملہ کرنے کے لیے، انہیں اسٹیک کا 33% سے زیادہ (دوبارہ) جمع کرنا ہوگا اور اسے (دوبارہ) جلانا ہوگا۔ نیٹ ورک پر حملہ کرنے کی ہر کوشش پر 4.6 بلین ڈالر سے زیادہ لاگت آئے گی (1000$/ETH اور 14M ETH اسٹیک پر)۔ حملہ آور کو اس وقت بھی نیٹ ورک سے نکال دیا جاتا ہے جب انہیں سلیش کیا جاتا ہے، اور انہیں دوبارہ شامل ہونے کے لیے ایکٹیویشن قطار میں شامل ہونا پڑتا ہے۔ اس کا مطلب ہے کہ بار بار حملے کی شرح نہ صرف اس شرح تک محدود ہے جس سے حملہ آور کل اسٹیک کا 33% سے زیادہ جمع کر سکتا ہے بلکہ اس وقت تک بھی محدود ہے جو اپنے تمام ویلیڈیٹرز کو نیٹ ورک پر آن بورڈ کرنے میں لگتا ہے۔ ہر بار جب حملہ آور حملہ کرتا ہے، وہ بہت غریب ہو جاتا ہے، اور باقی کمیونٹی امیر ہو جاتی ہے، جس کے نتیجے میں سپلائی کا جھٹکا لگتا ہے۔ + +دیگر حملے، جیسے 51% حملے یا کل اسٹیک کے 66% کے ساتھ حتمیت کی واپسی، کے لیے کافی زیادہ ETH کی ضرورت ہوتی ہے اور یہ حملہ آور کے لیے بہت زیادہ مہنگے ہوتے ہیں۔ + +اس کا proof-of-work سے موازنہ کریں۔ Proof-of-work Ethereum پر حملہ کرنے کی لاگت کل نیٹ ورک ہیش ریٹ کے 50% سے زیادہ کا مسلسل مالک ہونے کی لاگت تھی۔ یہ دوسرے مائنرز کو پیچھے چھوڑ کر مسلسل proof-of-work حل کا حساب لگانے کے لیے کافی کمپیوٹنگ پاور کے ہارڈ ویئر اور چلانے کے اخراجات کے برابر تھا۔ Ethereum کو زیادہ تر ASICs کے بجائے GPUs کا استعمال کرتے ہوئے مائن کیا گیا تھا، جس سے لاگت کم رہی (حالانکہ اگر Ethereum proof-of-work پر رہتا، تو ASIC مائننگ زیادہ مقبول ہو سکتی تھی)۔ ایک مخالف کو proof-of-work Ethereum نیٹ ورک پر حملہ کرنے کے لیے بہت سارے ہارڈ ویئر خریدنے اور اسے چلانے کے لیے بجلی کی ادائیگی کرنی ہوگی، لیکن کل لاگت حملہ شروع کرنے کے لیے کافی ETH جمع کرنے کے لیے درکار لاگت سے کم ہوگی۔ ایک 51% حملہ proof-of-stake کے مقابلے میں proof-of-work پر ~[20 گنا کم](https://youtu.be/1m12zgJ42dI?t=1562) مہنگا ہے۔ اگر حملے کا پتہ چل جاتا اور ان کی تبدیلیوں کو ہٹانے کے لیے چین کو ہارڈ فورک کیا جاتا، تو حملہ آور نئے فورک پر حملہ کرنے کے لیے بار بار اسی ہارڈ ویئر کا استعمال کر سکتا تھا۔ + +### پیچیدگی {#complexity} + +Proof-of-stake, proof-of-work سے کہیں زیادہ پیچیدہ ہے۔ یہ proof-of-work کے حق میں ایک نکتہ ہو سکتا ہے کیونکہ آسان پروٹوکول میں حادثاتی طور پر بگس یا غیر ارادی اثرات متعارف کرانا مشکل ہے۔ تاہم، پیچیدگی کو برسوں کی تحقیق اور ترقی، سمیلیشنز، اور ٹیسٹ نیٹ کے نفاذ کے ذریعے قابو میں لایا گیا ہے۔ Proof-of-stake پروٹوکول کو پانچ الگ الگ ٹیموں نے (ہر ایک ایگزیکیوشن اور کنسنسس لیئرز پر) پانچ پروگرامنگ زبانوں میں آزادانہ طور پر نافذ کیا ہے، جو کلائنٹ بگس کے خلاف لچک فراہم کرتا ہے۔ + +Proof-of-stake کنسنسس منطق کو محفوظ طریقے سے تیار کرنے اور جانچنے کے لیے، Beacon Chain کو Ethereum Mainnet پر proof-of-stake کے نفاذ سے دو سال پہلے لانچ کیا گیا تھا۔ Beacon Chain نے proof-of-stake کی جانچ کے لیے ایک سینڈ باکس کے طور پر کام کیا، کیونکہ یہ ایک لائیو بلاکچین تھا جو proof-of-stake کنسنسس منطق کو نافذ کرتا تھا لیکن حقیقی Ethereum ٹرانزیکشنز کو چھوئے بغیر - مؤثر طریقے سے صرف خود پر اتفاق رائے پر پہنچتا تھا۔ ایک بار جب یہ کافی وقت تک مستحکم اور بگ سے پاک ہو گیا، تو Beacon Chain کو Ethereum Mainnet کے ساتھ "ضم" کر دیا گیا۔ ان سب نے proof-of-stake کی پیچیدگی کو اس مقام تک قابو کرنے میں اہم کردار ادا کیا جہاں غیر ارادی نتائج یا کلائنٹ بگس کا خطرہ بہت کم تھا۔ + +### حملے کی سطح {#attack-surface} + +Proof-of-stake, proof-of-work سے زیادہ پیچیدہ ہے، جس کا مطلب ہے کہ نمٹنے کے لیے زیادہ ممکنہ حملے کے ویکٹرز ہیں۔ کلائنٹس کو جوڑنے والے ایک پیئر ٹو پیئر نیٹ ورک کے بجائے، دو ہیں، ہر ایک الگ پروٹوکول کو نافذ کرتا ہے۔ ہر سلاٹ میں ایک بلاک تجویز کرنے کے لیے پہلے سے منتخب ایک مخصوص ویلیڈیٹر کا ہونا ڈینائل-آف-سروس کا امکان پیدا کرتا ہے جہاں بڑی مقدار میں نیٹ ورک ٹریفک اس مخصوص ویلیڈیٹر کو آف لائن کر دیتی ہے۔ + +ایسے طریقے بھی ہیں جن سے حملہ آور اپنے بلاکس یا توثیق کے اجراء کو احتیاط سے وقت دے سکتے ہیں تاکہ انہیں ایماندار نیٹ ورک کے ایک خاص تناسب سے موصول کیا جا سکے، جس سے وہ بعض طریقوں سے ووٹ دینے پر اثر انداز ہوں۔ آخر میں، ایک حملہ آور صرف اسٹیک کرنے اور کنسنسس میکانزم پر غلبہ حاصل کرنے کے لیے کافی ETH جمع کر سکتا ہے۔ ان میں سے ہر ایک [حملے کے ویکٹر سے منسلک دفاعات ہیں](/developers/docs/consensus-mechanisms/pos/attack-and-defense)، لیکن وہ proof-of-work کے تحت دفاع کے لیے موجود نہیں ہیں۔ + +## وکندریقرت {#decentralization} + +Proof-of-stake, proof-of-work سے زیادہ وکندریقرت ہے کیونکہ مائننگ ہارڈ ویئر کی ہتھیاروں کی دوڑ افراد اور چھوٹی تنظیموں کو قیمت سے باہر کر دیتی ہے۔ جبکہ کوئی بھی تکنیکی طور پر معمولی ہارڈ ویئر کے ساتھ مائننگ شروع کر سکتا ہے، ادارہ جاتی مائننگ آپریشنز کے مقابلے میں ان کے کسی بھی انعام حاصل کرنے کا امکان بہت کم ہے۔ Proof-of-stake کے ساتھ، اسٹیکنگ کی لاگت اور اس اسٹیک پر فیصد واپسی سب کے لیے یکساں ہے۔ اس وقت ایک ویلیڈیٹر چلانے کے لیے 32 ETH کی لاگت آتی ہے۔ + +دوسری طرف، لیکویڈ اسٹیکنگ ڈیریویٹوز کی ایجاد نے مرکزیت کے خدشات کو جنم دیا ہے کیونکہ چند بڑے فراہم کنندگان بڑی مقدار میں اسٹیک شدہ ETH کا انتظام کرتے ہیں۔ یہ مسئلہ ہے اور اسے جلد از جلد درست کرنے کی ضرورت ہے، لیکن یہ اس سے زیادہ باریک بھی ہے جتنا یہ لگتا ہے۔ مرکزی اسٹیکنگ فراہم کرنے والوں کا ویلیڈیٹرز پر لازمی طور پر مرکزی کنٹرول نہیں ہوتا ہے - اکثر یہ ETH کا ایک مرکزی پول بنانے کا ایک طریقہ ہوتا ہے جسے بہت سے آزاد نوڈ آپریٹرز ہر شریک کو اپنے 32 ETH کی ضرورت کے بغیر اسٹیک کر سکتے ہیں۔ + +Ethereum کے لیے بہترین آپشن یہ ہے کہ ویلیڈیٹرز کو گھریلو کمپیوٹرز پر مقامی طور پر چلایا جائے، جس سے وکندریقرت کو زیادہ سے زیادہ کیا جائے۔ یہی وجہ ہے کہ Ethereum ان تبدیلیوں کی مزاحمت کرتا ہے جو نوڈ/ویلیڈیٹر چلانے کے لیے ہارڈ ویئر کی ضروریات میں اضافہ کرتی ہیں۔ + +## پائیداری {#sustainability} + +Proof-of-stake بلاکچین کو محفوظ بنانے کا ایک کاربن-سستا طریقہ ہے۔ Proof-of-work کے تحت مائنرز ایک بلاک مائن کرنے کے حق کے لیے مقابلہ کرتے ہیں۔ مائنرز زیادہ کامیاب ہوتے ہیں جب وہ تیزی سے حساب کتاب کر سکتے ہیں، ہارڈ ویئر اور توانائی کی کھپت میں سرمایہ کاری کی ترغیب دیتے ہیں۔ یہ Ethereum کے proof-of-stake پر سوئچ کرنے سے پہلے اس کے لیے مشاہدہ کیا گیا تھا۔ Proof-of-stake میں منتقلی سے کچھ دیر پہلے، Ethereum تقریباً 78 TWh/yr استعمال کر رہا تھا - جتنا ایک چھوٹا ملک۔ تاہم، proof-of-stake پر سوئچ کرنے سے اس توانائی کے خرچ میں ~99.98% کی کمی واقع ہوئی۔ Proof-of-stake نے Ethereum کو ایک توانائی-موثر، کم کاربن پلیٹ فارم بنایا۔ + +[Ethereum کی توانائی کی کھپت پر مزید](/energy-consumption) + +## اجراء {#issuance} + +Proof-of-stake Ethereum اپنی سیکیورٹی کے لیے proof-of-work Ethereum کے مقابلے میں بہت کم سکے جاری کر کے ادائیگی کر سکتا ہے کیونکہ ویلیڈیٹرز کو بجلی کے زیادہ اخراجات ادا نہیں کرنے پڑتے ہیں۔ نتیجے کے طور پر، ETH اپنی افراط زر کو کم کر سکتا ہے یا یہاں تک کہ جب بڑی مقدار میں ETH جلایا جاتا ہے تو وہ ڈیفلیشنری بھی بن سکتا ہے۔ کم افراط زر کی سطح کا مطلب ہے کہ Ethereum کی سیکیورٹی proof-of-work کے تحت اس سے سستی ہے۔ + +## کیا آپ زیادہ بصری سیکھنے والے ہیں؟ {#visual-learner} + +جسٹن ڈریک کو proof-of-work پر proof-of-stake کے فوائد کی وضاحت کرتے ہوئے دیکھیں: + + + +## مزید پڑھیں {#further-reading} + +- [ویٹالک کا proof-of-stake ڈیزائن فلسفہ](https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51) +- [ویٹالک کے proof-of-stake کے اکثر پوچھے گئے سوالات](https://vitalik.eth.limo/general/2017/12/31/pos_faq.html#what-is-proof-of-stake) +- [pos بمقابلہ pow پر "Simply Explained" ویڈیو](https://www.youtube.com/watch?v=M3EFi_POhps) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md new file mode 100644 index 00000000000..d3963a73f9c --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/rewards-and-penalties/index.md @@ -0,0 +1,91 @@ +--- +title: "پروف-آف-اسٹیک انعامات اور سزائیں" +description: "پروف-آف-اسٹیک Ethereum میں ان-پروٹوکول ترغیبات کے بارے میں جانیں۔" +lang: ur-in +--- + +Ethereum کو اس کی مقامی کرپٹو کرنسی، ایتھر (ETH) کا استعمال کرتے ہوئے محفوظ بنایا گیا ہے۔ نوڈ آپریٹرز جو بلاکس کی توثیق کرنے اور چین کے ہیڈ کی شناخت کرنے میں حصہ لینا چاہتے ہیں، وہ Ethereum پر [ڈیپازٹ کنٹریکٹ](/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 کو متاثر کرتے ہیں۔ [Vitalik's notes](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` ہے۔ اس کی قدر `base_reward` کو `1/delay` سے ضرب دینے کے برابر ہے، جہاں `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) میں انعامات اور سزاؤں کے بارے میں مزید پڑھیں۔ Bellatrix اپ گریڈ میں انعامات اور سزاؤں کو ایڈجسٹ کیا گیا تھا - اس [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 سے زیادہ کو کنٹرول کریں گے۔ اسٹیک کا نقصان غیر فعال ویلیڈیٹرز کے لیے جلد از جلد دوبارہ فعال ہونے کی ایک مضبوط ترغیب ہے! Medalla ٹیسٹ نیٹ پر ایک غیرفعالیت لیک کا منظر نامہ اس وقت پیش آیا جب 66% سے کم فعال ویلیڈیٹرز بلاک چین کے موجودہ ہیڈ پر اتفاق رائے پر پہنچ سکے۔ غیرفعالیت لیک کو فعال کیا گیا اور آخر کار فائنلٹی دوبارہ حاصل کر لی گئی! + +کنسینسس میکانزم کا انعام، سزا اور سلیشنگ کا ڈیزائن انفرادی ویلیڈیٹرز کو صحیح طریقے سے برتاؤ کرنے کی ترغیب دیتا ہے۔ تاہم، ان ڈیزائن کے انتخاب سے ایک ایسا نظام ابھرتا ہے جو متعدد کلائنٹس میں ویلیڈیٹرز کی مساوی تقسیم کی بھرپور ترغیب دیتا ہے، اور اسے سنگل-کلائنٹ کے غلبے کی سختی سے حوصلہ شکنی کرنی چاہیے۔ + +## مزید پڑھیں {#further-reading} + +- [Ethereum کو اپ گریڈ کرنا: ترغیبی لیئر](https://eth2book.info/altair/part2/incentives) +- [Ethereum کے ہائبرڈ کیسپر پروٹوکول میں ترغیبات](https://arxiv.org/pdf/1903.04205.pdf) +- [Vitalik کی تشریح شدہ اسپیک](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/ur/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md new file mode 100644 index 00000000000..3c8becd944c --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/weak-subjectivity/index.md @@ -0,0 +1,39 @@ +--- +title: "کمزور موضوعیت" +description: "کمزور موضوعیت کی وضاحت اور PoS Ethereum میں اس کا کردار۔" +lang: ur-in +--- + +بلاک چینز میں موضوعیت سے مراد موجودہ اسٹیٹ پر متفق ہونے کے لیے سماجی معلومات پر انحصار کرنا ہے۔ نیٹ ورک پر دیگر پیئرز سے جمع کی گئی معلومات کے مطابق متعدد درست فورکس ہو سکتے ہیں جن میں سے انتخاب کیا جاتا ہے۔ اس کے برعکس معروضیت ہے جس سے مراد وہ چینز ہیں جہاں صرف ایک ممکنہ درست چین ہوتی ہے جس پر تمام نوڈس اپنے کوڈ کردہ اصولوں کو لاگو کرکے لازمی طور پر متفق ہوں گے۔ ایک تیسری اسٹیٹ بھی ہے، جسے کمزور موضوعیت کہا جاتا ہے۔ اس سے مراد ایک ایسی چین ہے جو سماجی طور پر کچھ ابتدائی معلومات حاصل کرنے کے بعد معروضی طور پر آگے بڑھ سکتی ہے۔ + +## شرائط {#prerequisites} + +اس صفحہ کو سمجھنے کے لیے پہلے [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos/) کے بنیادی اصولوں کو سمجھنا ضروری ہے۔ + +## کمزور موضوعیت کن مسائل کو حل کرتی ہے؟ {#problems-ws-solves} + +پروف آف اسٹیک بلاک چینز میں موضوعیت فطری ہے کیونکہ متعدد فورکس میں سے درست چین کا انتخاب تاریخی ووٹس کی گنتی کرکے کیا جاتا ہے۔ یہ بلاک چین کو کئی حملوں کے خطرات سے دوچار کرتا ہے، بشمول طویل مدتی حملے جن میں وہ نوڈس جو چین میں بہت شروع میں حصہ لے چکے تھے، ایک متبادل فورک کو برقرار رکھتے ہیں جسے وہ بہت بعد میں اپنے فائدے کے لیے جاری کرتے ہیں۔ متبادل کے طور پر، اگر 33% ویلیڈیٹرز اپنا اسٹیک واپس لے لیں لیکن تصدیق کرنا اور بلاکس بنانا جاری رکھیں، تو وہ ایک متبادل فورک بنا سکتے ہیں جو کینونیکل چین سے متصادم ہو۔ نئے نوڈس یا وہ نوڈس جو طویل عرصے سے آف لائن ہیں شاید اس بات سے واقف نہ ہوں کہ ان حملہ آور ویلیڈیٹرز نے اپنے فنڈز واپس لے لیے ہیں، لہذا حملہ آور انہیں غلط چین کی پیروی کرنے کے لیے دھوکہ دے سکتے ہیں۔ Ethereum ان حملوں کے خطرات کو ایسی پابندیاں لگا کر حل کر سکتا ہے جو میکانزم کے موضوعی پہلوؤں کو — اور اس وجہ سے اعتماد کے مفروضوں کو — کم سے کم کر دیتی ہیں۔ + +## کمزور موضوعیت کے چیک پوائنٹس {#ws-checkpoints} + +پروف آف اسٹیک Ethereum میں کمزور موضوعیت کو "کمزور موضوعیت کے چیک پوائنٹس" کا استعمال کرکے لاگو کیا جاتا ہے۔ یہ اسٹیٹ روٹس ہیں جن پر نیٹ ورک کے تمام نوڈس متفق ہیں کہ وہ کینونیکل چین سے تعلق رکھتے ہیں۔ یہ جینیسس بلاکس کی طرح "آفاقی سچائی" کا مقصد پورا کرتے ہیں، سوائے اس کے کہ وہ بلاک چین میں جینیسس پوزیشن پر نہیں ہوتے۔ فورک چوائس الگورتھم اس بات پر بھروسہ کرتا ہے کہ اس چیک پوائنٹ میں بیان کردہ بلاک چین اسٹیٹ درست ہے اور یہ اس مقام سے آگے چین کی آزادانہ اور معروضی طور پر تصدیق کرتا ہے۔ چیک پوائنٹس "ریورٹ لمٹس" کے طور پر کام کرتے ہیں کیونکہ کمزور موضوعیت کے چیک پوائنٹس سے پہلے موجود بلاکس کو تبدیل نہیں کیا جا سکتا۔ یہ میکانزم ڈیزائن کے حصے کے طور پر طویل مدتی فورکس کو غلط قرار دے کر طویل مدتی حملوں کو کمزور کرتا ہے۔ یہ یقینی بنانا کہ کمزور موضوعیت کے چیک پوائنٹس ویلیڈیٹر کے انخلا کی مدت سے کم فاصلے پر ہوں، اس بات کو یقینی بناتا ہے کہ ایک ویلیڈیٹر جو چین کو فورک کرتا ہے، اسے اپنا اسٹیک واپس لینے سے پہلے کم از کم ایک حد تک کی رقم پر سلیش کیا جائے اور یہ کہ نئے داخل ہونے والوں کو ان ویلیڈیٹرز کے ذریعے غلط فورکس میں دھوکہ نہ دیا جا سکے جن کا اسٹیک واپس لے لیا گیا ہے۔ + +## کمزور موضوعیت کے چیک پوائنٹس اور حتمی شکل دیے گئے بلاکس کے درمیان فرق {#difference-between-ws-and-finalized-blocks} + +حتمی شکل دیے گئے بلاکس اور کمزور موضوعیت کے چیک پوائنٹس کے ساتھ Ethereum نوڈس مختلف طریقے سے برتاؤ کرتے ہیں۔ اگر کوئی نوڈ دو مسابقتی حتمی شکل دیے گئے بلاکس سے آگاہ ہو جاتا ہے، تو وہ دونوں کے درمیان پھنس جاتا ہے - اس کے پاس خود بخود یہ شناخت کرنے کا کوئی طریقہ نہیں ہوتا کہ کینونیکل فورک کون سا ہے۔ یہ اتفاق رائے کی ناکامی کی علامت ہے۔ اس کے برعکس، ایک نوڈ کسی بھی ایسے بلاک کو مسترد کر دیتا ہے جو اس کے کمزور موضوعیت کے چیک پوائنٹ سے متصادم ہو۔ نوڈ کے نقطہ نظر سے، کمزور موضوعیت کا چیک پوائنٹ ایک مطلق سچائی کی نمائندگی کرتا ہے جسے اس کے پیئرز سے حاصل ہونے والے نئے علم سے کمزور نہیں کیا جا سکتا۔ + +## کمزور کتنا کمزور ہے؟ {#how-weak-is-weak} + +Ethereum کے پروف آف اسٹیک کا موضوعی پہلو ایک قابل اعتماد ذریعہ سے حالیہ اسٹیٹ (کمزور موضوعیت کا چیک پوائنٹ) کی ضرورت ہے تاکہ اس سے مطابقت پذیری کی جا سکے۔ خراب کمزور موضوعیت کا چیک پوائنٹ حاصل کرنے کا خطرہ بہت کم ہے کیونکہ انہیں کئی آزاد عوامی ذرائع جیسے کہ بلاک ایکسپلوررز یا متعدد نوڈس کے خلاف چیک کیا جا سکتا ہے۔ تاہم، کسی بھی سافٹ ویئر ایپلیکیشن کو چلانے کے لیے ہمیشہ کچھ حد تک اعتماد کی ضرورت ہوتی ہے، مثال کے طور پر، یہ بھروسہ کرنا کہ سافٹ ویئر ڈویلپرز نے ایماندار سافٹ ویئر تیار کیا ہے۔ + +ایک کمزور موضوعیت کا چیک پوائنٹ کلائنٹ سافٹ ویئر کے حصے کے طور پر بھی آ سکتا ہے۔ یقیناً ایک حملہ آور سافٹ ویئر میں چیک پوائنٹ کو خراب کر سکتا ہے اور اتنی ہی آسانی سے خود سافٹ ویئر کو بھی خراب کر سکتا ہے۔ اس مسئلے کا کوئی حقیقی کرپٹو-اقتصادی حل نہیں ہے، لیکن Ethereum میں ناقابل اعتبار ڈویلپرز کے اثرات کو متعدد آزاد کلائنٹ ٹیمیں رکھ کر کم کیا جاتا ہے، جن میں سے ہر ایک مختلف زبانوں میں مساوی سافٹ ویئر بناتی ہے، اور سب کا ایک ایماندار چین کو برقرار رکھنے میں گہرا مفاد ہوتا ہے۔ بلاک ایکسپلوررز کمزور موضوعیت کے چیک پوائنٹس بھی فراہم کر سکتے ہیں یا کہیں اور سے حاصل کردہ چیک پوائنٹس کا ایک اضافی ذریعہ سے موازنہ کرنے کا طریقہ بھی فراہم کر سکتے ہیں۔ + +آخر میں، چیک پوائنٹس دوسرے نوڈس سے بھی درخواست کیے جا سکتے ہیں؛ شاید کوئی دوسرا Ethereum صارف جو ایک مکمل نوڈ چلاتا ہے، ایک چیک پوائنٹ فراہم کر سکتا ہے جسے ویلیڈیٹرز پھر بلاک ایکسپلورر کے ڈیٹا سے تصدیق کر سکتے ہیں۔ مجموعی طور پر، کمزور موضوعیت کے چیک پوائنٹ فراہم کرنے والے پر بھروسہ کرنا اتنا ہی مشکل سمجھا جا سکتا ہے جتنا کلائنٹ ڈویلپرز پر بھروسہ کرنا۔ مجموعی طور پر درکار اعتماد کم ہے۔ یہ نوٹ کرنا ضروری ہے کہ یہ تحفظات صرف اس انتہائی غیر متوقع صورت میں اہم ہو جاتے ہیں جب ویلیڈیٹرز کی اکثریت بلاک چین کا ایک متبادل فورک بنانے کی سازش کرے۔ کسی بھی دوسرے حالات میں، انتخاب کے لیے صرف ایک ہی Ethereum چین ہوتی ہے۔ + +## مزید مطالعہ {#further-reading} + +- [Eth2 میں کمزور موضوعیت](https://notes.ethereum.org/@adiasg/weak-subjectvity-eth2) +- [Vitalik: میں نے کمزور موضوعیت سے محبت کرنا کیسے سیکھا](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) +- [Ethereum 2.0 میں کمزور موضوعیت کا تجزیہ](https://github.com/runtimeverification/beacon-chain-verification/blob/master/weak-subjectivity/weak-subjectivity-analysis.pdf) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md new file mode 100644 index 00000000000..d44ed0934d5 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pos/withdrawal-credentials/index.md @@ -0,0 +1,64 @@ +--- +title: "وڈرال کریڈینشلز" +description: "توثیق کار کے رقم نکالنے کے کریڈنشیل کی اقسام (0x00، 0x01، 0x02) کی وضاحت اور Ethereum اسٹیکرز کے لیے ان کے مضمرات۔" +lang: ur-in +--- + +ہر توثیق کار کے پاس ایک **رقم نکالنے کا کریڈنشیل** ہوتا ہے جو یہ تعین کرتا ہے کہ ان کے اسٹیک شدہ ETH اور انعامات کیسے اور کہاں سے نکالے جا سکتے ہیں۔ کریڈنشیل کی قسم پہلے بائٹ سے ظاہر کی جاتی ہے: `0x00`، `0x01`، یا `0x02`۔ اپنے اسٹیک کا انتظام کرنے والے توثیق کاروں کے لیے ان اقسام کو سمجھنا اہم ہے۔ + +## 0x00: Shapella سے پہلے کے کریڈنشیلز {#0x00-credentials} + +`0x00` قسم Shapella اپ گریڈ (اپریل 2023) سے پہلے کا اصل رقم نکالنے کے کریڈنشیل کا فارمیٹ ہے۔ اس کریڈنشیل قسم والے توثیق کاروں کے پاس کوئی ایگزیکیوشن لیئر رقم نکالنے کا پتہ سیٹ نہیں ہوتا ہے، یعنی ان کے فنڈز کنسینسس لیئر پر لاک رہتے ہیں۔ اگر آپ کے پاس اب بھی `0x00` کریڈنشیلز ہیں، تو کوئی بھی رقم نکالنے سے پہلے آپ کو `0x01` یا `0x02` پر اپ گریڈ کرنا لازمی ہے۔ + +## 0x01: میراثی رقم نکالنے کے کریڈنشیلز {#0x01-credentials} + +`0x01` قسم Shapella اپ گریڈ کے ساتھ متعارف کرائی گئی تھی اور ان توثیق کاروں کے لیے معیار بن گئی جو ایگزیکیوشن لیئر رقم نکالنے کا پتہ سیٹ کرنا چاہتے تھے۔ `0x01` کریڈنشیلز کے ساتھ: + +- 32 ETH سے اوپر کا کوئی بھی بیلنس **خود بخود منتقل ہو کر** آپ کے رقم نکالنے کے پتے پر چلا جاتا ہے۔ +- مکمل اخراج معیاری اخراج کی قطار سے گزرتا ہے۔ +- 32 ETH سے اوپر کے انعامات کمپاؤنڈ نہیں ہو سکتے—انہیں وقتاً فوقتاً نکال دیا جاتا ہے۔ + +**کچھ توثیق کار اب بھی 0x01 کیوں استعمال کرتے ہیں:** یہ آسان اور جانا پہچانا ہے۔ بہت سے توثیق کاروں نے Shapella کے بعد جمع کیا اور ان کے پاس پہلے سے ہی یہ قسم ہے، اور یہ ان لوگوں کے لیے ٹھیک کام کرتا ہے جو اضافی بیلنس کی خودکار رقم نکالنا چاہتے ہیں۔ + +**اس کی سفارش کیوں نہیں کی جاتی:** `0x01` کے ساتھ، آپ 32 ETH سے اوپر کے انعامات کو کمپاؤنڈ کرنے کی صلاحیت کھو دیتے ہیں۔ ہر اضافی حصہ خود بخود نکال دیا جاتا ہے، جو آپ کے توثیق کار کی کمائی کی صلاحیت کو محدود کرتا ہے اور نکالی گئی رقم کو الگ سے منظم کرنے کی ضرورت ہوتی ہے۔ + +## 0x02: کمپاؤنڈنگ رقم نکالنے کے کریڈنشیلز {#0x02-credentials} + +`0x02` قسم Pectra اپ گریڈ کے ساتھ متعارف کرائی گئی تھی اور آج توثیق کاروں کے لیے **تجویز کردہ انتخاب** ہے۔ `0x02` کریڈنشیلز والے توثیق کاروں کو کبھی کبھی "کمپاؤنڈنگ توثیق کار" کہا جاتا ہے۔ + +`0x02` کریڈنشیلز کے ساتھ: + +- 32 ETH سے اوپر کے انعامات 1 ETH کے اضافے میں 2048 ETH کے زیادہ سے زیادہ مؤثر بیلنس تک **کمپاؤنڈ** ہوتے ہیں۔ +- جزوی رقم نکالنے کی درخواست دستی طور پر کی جانی چاہیے (خودکار منتقلی صرف 2048 ETH کی حد سے اوپر ہوتی ہے) +- توثیق کار متعدد 32 ETH والے توثیق کاروں کو یکجا کر کے ایک ہی زیادہ بیلنس والا توثیق کار بنا سکتے ہیں۔ +- مکمل اخراج اب بھی معیاری اخراج کی قطار کے ذریعے سپورٹ کیے جاتے ہیں۔ + +جزوی رقم نکالنے اور یکجا کرنے، دونوں کام [Launchpad Validator Actions](https://launchpad.ethereum.org/en/validator-actions) کے ذریعے کیے جا سکتے ہیں۔ + +**توثیق کاروں کو 0x02 کو کیوں ترجیح دینی چاہیے:** یہ کمپاؤنڈنگ کے ذریعے بہتر سرمائے کی کارکردگی پیش کرتا ہے، رقم کب نکالی جائے اس پر زیادہ کنٹرول دیتا ہے، اور توثیق کار کو یکجا کرنے کو سپورٹ کرتا ہے۔ ان سولو اسٹیکرز کے لیے جو وقت کے ساتھ انعامات جمع کرتے ہیں، اس کا مطلب ہے کہ ان کا مؤثر بیلنس—اور اس طرح ان کے انعامات—بغیر کسی دستی مداخلت کے 32 ETH سے آگے بڑھ سکتے ہیں۔ + +**اہم:** ایک بار جب آپ `0x01` سے `0x02` میں تبدیل ہو جاتے ہیں، تو آپ واپس نہیں جا سکتے۔ + +ٹائپ 2 کریڈنشیلز میں تبدیل کرنے اور MaxEB فیچر پر ایک تفصیلی گائیڈ کے لیے، [MaxEB explainer page](/roadmap/pectra/maxeb/) دیکھیں۔ + +## مجھے کیا چننا چاہیے؟ {#what-should-i-pick} + +- **نئے توثیق کار:** `0x02` منتخب کریں۔ یہ بہتر کمپاؤنڈنگ اور لچک کے ساتھ جدید معیار ہے۔ +- **موجودہ 0x01 توثیق کار:** `0x02` میں تبدیل کرنے پر غور کریں اگر آپ چاہتے ہیں کہ انعامات 32 ETH سے اوپر کمپاؤنڈ ہوں یا توثیق کاروں کو یکجا کرنے کا ارادہ رکھتے ہیں۔ +- **موجودہ 0x00 توثیق کار:** فوراً اپ گریڈ کریں—آپ اپنے کریڈنشیلز کو اپ ڈیٹ کیے بغیر رقم نہیں نکال سکتے۔ آپ کو پہلے `0x01` میں تبدیل کرنا ہوگا، پھر آپ `0x02` میں تبدیل کر سکتے ہیں۔ + +## رقم نکالنے کے کریڈنشیلز کا انتظام کرنے کے ٹولز {#withdrawal-credential-tools} + +کئی ٹولز کریڈنشیل کی اقسام کے درمیان انتخاب کرنے یا تبدیل کرنے کو سپورٹ کرتے ہیں: + +- **[Ethereum Staking Launchpad](https://launchpad.ethereum.org/en/validator-actions)** - ڈیپازٹس اور توثیق کار کے انتظام کے لیے آفیشل ٹول، بشمول کریڈنشیل کی تبدیلیوں اور یکجا کرنے کے۔ +- **[Pectra Staking Manager](https://pectrastaking.com)** - تبدیلیوں اور یکجا کرنے کے لیے والیٹ-کنیکٹ سپورٹ کے ساتھ ویب UI +- **[Pectra Validator Ops CLI Tool](https://github.com/Luganodes/Pectra-Batch-Contract)** - بیچ کی تبدیلیوں کے لیے کمانڈ لائن ٹول +- **[Ethereal](https://github.com/wealdtech/ethereal)** - Ethereum آپریشنز کے لیے CLI ٹول، بشمول توثیق کار کے انتظام کے + +یکجا کرنے کے ٹولز کی مکمل فہرست اور تفصیلی تبدیلی کی ہدایات کے لیے، [MaxEB consolidation tooling](/roadmap/pectra/maxeb/#consolidation-tooling) دیکھیں۔ + +## مزید پڑھیں {#further-reading} + +- [پروف-آف-اسٹیک Ethereum میں کیز](/developers/docs/consensus-mechanisms/pos/keys/) - توثیق کار کیز اور وہ رقم نکالنے کے کریڈنشیلز سے کیسے تعلق رکھتی ہیں، اس کے بارے میں جانیں۔ +- [MaxEB](/roadmap/pectra/maxeb/) - Pectra اپ گریڈ اور زیادہ سے زیادہ مؤثر بیلنس فیچر پر تفصیلی گائیڈ۔ diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/index.md new file mode 100644 index 00000000000..7d718aa6522 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/index.md @@ -0,0 +1,114 @@ +--- +title: "کام کا ثبوت (PoW)" +description: "کام کے ثبوت پر مبنی اتفاق رائے پروٹوکول اور Ethereum میں اس کے کردار کی وضاحت۔" +lang: ur-in +--- + +Ethereum نیٹ ورک نے ایک اتفاق رائے کے طریقہ کار کا استعمال کرتے ہوئے شروع کیا جس میں **[کام کا ثبوت (PoW)](/developers/docs/consensus-mechanisms/pow)** شامل تھا۔ اس نے Ethereum نیٹ ورک کے نوڈس کو Ethereum بلاک چین پر ریکارڈ کی گئی تمام معلومات کی حالت پر متفق ہونے کی اجازت دی اور کچھ قسم کے معاشی حملوں کو روکا۔ تاہم، Ethereum نے 2022 میں کام کے ثبوت کو بند کر دیا اور اس کے بجائے [اسٹیک کا ثبوت](/developers/docs/consensus-mechanisms/pos) استعمال کرنا شروع کر دیا۔ + + + + + + کام کا ثبوت اب متروک ہو چکا ہے۔ Ethereum اب اپنے اتفاق رائے کے طریقہ کار کے حصے کے طور پر کام کے ثبوت کا استعمال نہیں کرتا۔ اس کے بجائے، یہ اسٹیک کے ثبوت کا استعمال کرتا ہے۔ [اسٹیک کے ثبوت](/developers/docs/consensus-mechanisms/pos/) اور [اسٹیکنگ](/staking/) پر مزید پڑھیں۔ + + + + +## شرائط {#prerequisites} + +اس صفحے کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [ٹرانزیکشنز](/developers/docs/transactions/)، [بلاکس](/developers/docs/blocks/)، اور [اتفاق رائے کے طریقہ کار](/developers/docs/consensus-mechanisms/) کے بارے میں پڑھیں۔ + +## کام کا ثبوت (PoW) کیا ہے؟ {#what-is-pow} + +ناکاموٹو اتفاق رائے، جو کام کے ثبوت کا استعمال کرتا ہے، وہ طریقہ کار ہے جس نے ایک بار غیر مرکزی Ethereum نیٹ ورک کو اکاؤنٹ بیلنس اور ٹرانزیکشنز کی ترتیب جیسی چیزوں پر اتفاق رائے (یعنی، تمام نوڈس متفق ہیں) پر آنے کی اجازت دی تھی۔ اس نے صارفین کو اپنے سکوں کی "ڈبل اسپینڈنگ" سے روکا اور یہ یقینی بنایا کہ Ethereum چین پر حملہ کرنا یا اس میں ہیرا پھیری کرنا انتہائی مشکل تھا۔ یہ حفاظتی خصوصیات اب [Gasper](/developers/docs/consensus-mechanisms/pos/gasper/) کے نام سے جانے جانے والے اتفاق رائے کے طریقہ کار کا استعمال کرتے ہوئے اسٹیک کے ثبوت سے آتی ہیں۔ + +## کام کا ثبوت اور مائننگ {#pow-and-mining} + +کام کا ثبوت وہ بنیادی الگورتھم ہے جو کام کے ثبوت والے بلاک چینز پر مائنرز کے کام کے لیے مشکل اور اصول طے کرتا ہے۔ مائننگ خود "کام" ہے۔ یہ چین میں درست بلاکس شامل کرنے کا عمل ہے۔ یہ اہم ہے کیونکہ چین کی لمبائی نیٹ ورک کو بلاک چین کے صحیح فورک کو فالو کرنے میں مدد کرتی ہے۔ جتنا زیادہ "کام" کیا جائے گا، چین اتنی ہی لمبی ہوگی، اور بلاک نمبر جتنا زیادہ ہوگا، نیٹ ورک چیزوں کی موجودہ حالت کے بارے میں اتنا ہی زیادہ یقینی ہو سکتا ہے۔ + +[مائننگ پر مزید](/developers/docs/consensus-mechanisms/pow/mining/) + +## Ethereum کا کام کا ثبوت کیسے کام کرتا تھا؟ {#how-it-works} + +Ethereum ٹرانزیکشنز کو بلاکس میں پراسیس کیا جاتا ہے۔ اب متروک کام کے ثبوت والے Ethereum میں، ہر بلاک میں شامل تھا: + +- بلاک کی مشکل – مثال کے طور پر: 3,324,092,183,262,715 +- mixHash – مثال کے طور پر: `0x44bca881b07a6a09f83b130798072441705d9a665c5ac8bdf2f39a3cdf3bee29` +- nonce – مثال کے طور پر: `0xd3ee432b4fb3d26b` + +یہ بلاک ڈیٹا براہ راست کام کے ثبوت سے متعلق تھا۔ + +### کام کے ثبوت میں کام {#the-work} + +کام کے ثبوت کا پروٹوکول، Ethash، مائنرز سے تقاضا کرتا تھا کہ وہ ایک بلاک کے لیے نانس (nonce) تلاش کرنے کے لیے آزمائش اور غلطی کی ایک شدید دوڑ سے گزریں۔ صرف ایک درست نانس (nonce) والے بلاکس کو ہی چین میں شامل کیا جا سکتا تھا۔ + +ایک بلاک بنانے کی دوڑ میں، ایک مائنر بار بار ایک ڈیٹاسیٹ، جو صرف پوری چین کو ڈاؤن لوڈ اور چلا کر حاصل کیا جا سکتا تھا (جیسا کہ ایک مائنر کرتا ہے)، کو ایک ریاضیاتی فنکشن کے ذریعے ڈالتا تھا۔ ڈیٹاسیٹ کا استعمال ایک ایسے ہدف سے نیچے ایک mixHash پیدا کرنے کے لیے کیا جاتا تھا جو بلاک کی مشکل سے طے ہوتا ہے۔ ایسا کرنے کا بہترین طریقہ آزمائش اور غلطی ہے۔ + +مشکل نے ہیش کے لیے ہدف کا تعین کیا۔ ہدف جتنا کم ہوگا، درست ہیشز کا سیٹ اتنا ہی چھوٹا ہوگا۔ ایک بار پیدا ہونے کے بعد، دوسرے مائنرز اور کلائنٹس کے لیے اس کی تصدیق کرنا ناقابل یقین حد تک آسان تھا۔ اگر ایک ٹرانزیکشن بھی بدل جائے، تو ہیش بالکل مختلف ہو جائے گا، جو دھوکہ دہی کا اشارہ دے گا۔ + +ہیشنگ دھوکہ دہی کو پکڑنا آسان بناتی ہے۔ لیکن ایک عمل کے طور پر کام کا ثبوت بھی چین پر حملہ کرنے میں ایک بڑی رکاوٹ تھا۔ + +### کام کا ثبوت اور سیکیورٹی {#security} + +مائنرز کو مرکزی Ethereum چین پر یہ کام کرنے کی ترغیب دی گئی تھی۔ مائنرز کے ایک ذیلی سیٹ کے لیے اپنی چین شروع کرنے کی بہت کم ترغیب تھی — یہ نظام کو کمزور کرتا ہے۔ بلاک چینز سچائی کے ذریعہ کے طور پر ایک واحد حالت رکھنے پر انحصار کرتے ہیں۔ + +کام کے ثبوت کا مقصد چین کو بڑھانا تھا۔ سب سے لمبی چین سب سے زیادہ قابل اعتبار تھی کیونکہ اسے پیدا کرنے کے لیے سب سے زیادہ کمپیوٹیشنل کام کیا گیا تھا۔ Ethereum کے PoW نظام کے اندر، ایسے نئے بلاکس بنانا جو ٹرانزیکشنز کو مٹا دیں، جعلی بنائیں، یا دوسری چین کو برقرار رکھیں، تقریبا ناممکن تھا۔ اس کی وجہ یہ ہے کہ ایک بدنیتی پر مبنی مائنر کو باقی سب سے تیز ہمیشہ بلاک نانس (nonce) حل کرنے کی ضرورت ہوتی۔ + +مسلسل بدنیتی پر مبنی لیکن درست بلاکس بنانے کے لیے، ایک بدنیتی پر مبنی مائنر کو باقی سب کو شکست دینے کے لیے نیٹ ورک کی 51% سے زیادہ مائننگ پاور کی ضرورت ہوتی۔ اس مقدار کے "کام" کے لیے بہت زیادہ مہنگی کمپیوٹنگ پاور کی ضرورت ہوتی ہے اور خرچ کی گئی توانائی حملے میں حاصل ہونے والے فوائد سے بھی زیادہ ہو سکتی تھی۔ + +### کام کے ثبوت کی معاشیات {#economics} + +کام کا ثبوت سسٹم میں نئی کرنسی جاری کرنے اور مائنرز کو کام کرنے کی ترغیب دینے کا بھی ذمہ دار تھا۔ + +[Constantinople اپ گریڈ](/ethereum-forks/#constantinople) کے بعد سے، کامیابی سے ایک بلاک بنانے والے مائنرز کو دو نئے بنائے گئے ETH اور ٹرانزیکشن فیس کا ایک حصہ انعام میں دیا جاتا تھا۔ اومر بلاکس نے بھی 1.75 ETH کا معاوضہ دیا۔ اومر بلاکس درست بلاکس تھے جو ایک مائنر نے عملی طور پر اسی وقت بنائے تھے جب دوسرے مائنر نے کینونیکل بلاک بنایا تھا، جس کا تعین بالآخر اس بات سے ہوتا تھا کہ کون سی چین پہلے بنائی گئی تھی۔ اومر بلاکس عام طور پر نیٹ ورک کی تاخیر کی وجہ سے ہوتے تھے۔ + +## حتمیت {#finality} + +Ethereum پر ایک ٹرانزیکشن میں "حتمیت" ہوتی ہے جب وہ ایک ایسے بلاک کا حصہ ہو جو بدل نہیں سکتا۔ + +چونکہ مائنرز ایک غیر مرکزی طریقے سے کام کرتے تھے، ایک ہی وقت میں دو درست بلاکس مائن کیے جا سکتے تھے۔ یہ ایک عارضی فورک بناتا ہے۔ بالآخر، ان میں سے ایک چین بعد کے بلاکس کے مائن ہونے اور اس میں شامل ہونے کے بعد قبول شدہ چین بن گئی، جس سے وہ لمبی ہو گئی۔ + +معاملات کو مزید پیچیدہ بنانے کے لیے، عارضی فورک پر مسترد کی گئی ٹرانزیکشنز شاید قبول شدہ چین میں شامل نہ ہوئی ہوں۔ اس کا مطلب ہے کہ اسے الٹا کیا جا سکتا ہے۔ لہذا حتمیت اس وقت کا حوالہ دیتی ہے جس کا آپ کو کسی ٹرانزیکشن کو ناقابل واپسی سمجھنے سے پہلے انتظار کرنا چاہئے۔ پچھلے کام کے ثبوت والے Ethereum کے تحت، ایک مخصوص بلاک `N` کے اوپر جتنے زیادہ بلاکس مائن کیے جاتے، اتنا ہی زیادہ اعتماد ہوتا کہ `N` میں ٹرانزیکشنز کامیاب تھیں اور انہیں واپس نہیں کیا جائے گا۔ اب، اسٹیک کے ثبوت کے ساتھ، حتمی شکل دینا ایک بلاک کی امکانی خاصیت کے بجائے ایک واضح خاصیت ہے۔ + +## کام کے ثبوت کا توانائی کا استعمال {#energy} + +کام کے ثبوت پر ایک بڑی تنقید توانائی کی وہ مقدار ہے جو نیٹ ورک کو محفوظ رکھنے کے لیے درکار ہوتی ہے۔ سیکیورٹی اور غیر مرکزیت کو برقرار رکھنے کے لیے، کام کے ثبوت پر Ethereum نے بڑی مقدار میں توانائی استعمال کی۔ اسٹیک کے ثبوت پر سوئچ کرنے سے کچھ دیر پہلے، Ethereum کے مائنرز اجتماعی طور پر تقریبا 70 TWh/yr (تقریبا چیک جمہوریہ کے برابر - [digiconomist](https://digiconomist.net/) کے مطابق 18-جولائی-2022 کو) استعمال کر رہے تھے۔ + +## فائدے اور نقصانات {#pros-and-cons} + +| فوائد | نقصانات | +| -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | +| کام کا ثبوت غیر جانبدار ہے۔ شروع کرنے کے لیے آپ کو ETH کی ضرورت نہیں ہے اور بلاک انعامات آپ کو 0ETH سے مثبت بیلنس تک جانے کی اجازت دیتے ہیں۔ [اسٹیک کے ثبوت](/developers/docs/consensus-mechanisms/pos/) کے ساتھ آپ کو شروع کرنے کے لیے ETH کی ضرورت ہے۔ | کام کا ثبوت اتنی زیادہ توانائی استعمال کرتا ہے کہ یہ ماحول کے لیے برا ہے۔ | +| کام کا ثبوت ایک آزمایا ہوا اور پرکھا ہوا اتفاق رائے کا طریقہ کار ہے جس نے کئی سالوں تک Bitcoin اور Ethereum کو محفوظ اور غیر مرکزی رکھا ہے۔ | اگر آپ مائننگ کرنا چاہتے ہیں، تو آپ کو ایسے خصوصی آلات کی ضرورت ہے کہ شروع کرنا ایک بڑی سرمایہ کاری ہے۔ | +| اسٹیک کے ثبوت کے مقابلے میں اسے نافذ کرنا نسبتاً آسان ہے۔ | بڑھتی ہوئی کمپیوٹیشن کی ضرورت کی وجہ سے، مائننگ پولز ممکنہ طور پر مائننگ کے کھیل پر غلبہ حاصل کر سکتے ہیں، جو مرکزیت اور سیکیورٹی کے خطرات کا باعث بنتا ہے۔ | + +## اسٹیک کے ثبوت کے مقابلے میں {#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/) +- [ثبوتِ اختیار (Proof-of-authority)](/developers/docs/consensus-mechanisms/poa/) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/index.md new file mode 100644 index 00000000000..d8f0de8ba8f --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/index.md @@ -0,0 +1,86 @@ +--- +title: "کان کنی" +description: "ایتھریم پر کان کنی کیسے کام کرتی تھی اس کی وضاحت۔" +lang: ur-in +--- + + + + + +کام کا ثبوت اب ایتھریم کے اتفاق رائے کے طریقہ کار کی بنیاد نہیں ہے، جس کا مطلب ہے کہ کان کنی کو بند کر دیا گیا ہے۔ اس کے بجائے، ایتھریم کو توثیق کنندگان کے ذریعے محفوظ کیا جاتا ہے جو ETH کو اسٹیک کرتے ہیں۔ آپ آج ہی اپنے ETH کو اسٹیک کرنا شروع کر سکتے ہیں۔ مرج، حصص کے ثبوت، اور اسٹیکنگ پر مزید پڑھیں۔ یہ صفحہ صرف تاریخی دلچسپی کے لیے ہے۔ + + + + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [لین دین](/developers/docs/transactions/)، [بلاکس](/developers/docs/blocks/) اور [کام کا ثبوت](/developers/docs/consensus-mechanisms/pow/) کے بارے میں پڑھیں۔ + +## ایتھریم کان کنی کیا ہے؟ {#what-is-ethereum-mining} + +کان کنی ایتھریم کے اب متروک کام کے ثبوت کے فن تعمیر میں ایتھریم بلاک چین میں شامل کیے جانے والے لین دین کا ایک بلاک بنانے کا عمل ہے۔ + +کان کنی کا لفظ کرپٹو کرنسیوں کے لیے سونے کی مثال کے تناظر میں شروع ہوا ہے۔ سونا یا قیمتی دھاتیں نایاب ہیں، اسی طرح ڈیجیٹل ٹوکن بھی ہیں، اور کام کا ثبوت والے نظام میں کل حجم کو بڑھانے کا واحد طریقہ کان کنی کے ذریعے ہے۔ کام کا ثبوت والے ایتھریم میں، اجراء کا واحد طریقہ کان کنی کے ذریعے تھا۔ تاہم، سونے یا قیمتی دھاتوں کے برعکس، ایتھریم کان کنی بلاک چین میں بلاکس بنا کر، تصدیق کر کے، شائع کر کے اور پھیلا کر نیٹ ورک کو محفوظ بنانے کا بھی ایک طریقہ تھا۔ + +ایتھر کی کان کنی = نیٹ ورک کو محفوظ بنانا + +کان کنی کسی بھی کام کا ثبوت والے بلاک چین کی جان ہے۔ ایتھریم کان کن - سافٹ ویئر چلانے والے کمپیوٹر - نے حصص کے ثبوت میں منتقلی سے پہلے لین دین پر کارروائی کرنے اور بلاکس تیار کرنے کے لیے اپنا وقت اور کمپیوٹیشنل طاقت استعمال کی۔ + +## کان کن کیوں موجود ہیں؟ {#why-do-miners-exist} + +ایتھریم جیسے غیر مرکزی نظاموں میں، ہمیں یہ یقینی بنانے کی ضرورت ہے کہ ہر کوئی لین دین کی ترتیب پر متفق ہو۔ کان کنوں نے بلاکس تیار کرنے کے لیے حسابی طور پر مشکل پہیلیاں حل کرکے، نیٹ ورک کو حملوں سے محفوظ بنا کر ایسا کرنے میں مدد کی۔ + +[کام کے ثبوت پر مزید](/developers/docs/consensus-mechanisms/pow/) + +پہلے کوئی بھی اپنے کمپیوٹر کا استعمال کرکے ایتھریم نیٹ ورک پر کان کنی کرنے کے قابل تھا۔ تاہم، ہر کوئی منافع بخش طریقے سے ایتھر (ETH) کی کان کنی نہیں کر سکتا تھا۔ زیادہ تر معاملات میں، کان کنوں کو مخصوص کمپیوٹر ہارڈویئر خریدنا پڑتا تھا، اور سستے توانائی کے ذرائع تک رسائی حاصل کرنی پڑتی تھی۔ اوسط کمپیوٹر کے کان کنی سے وابستہ اخراجات کو پورا کرنے کے لیے کافی بلاک انعامات حاصل کرنے کا امکان نہیں تھا۔ + +### کان کنی کی لاگت {#cost-of-mining} + +- کان کنی کی رگ بنانے اور اسے برقرار رکھنے کے لیے ضروری ہارڈویئر کی ممکنہ لاگت +- کان کنی کی رگ کو بجلی فراہم کرنے کی برقی لاگت +- اگر آپ کسی پول میں کان کنی کر رہے تھے، تو یہ پول عام طور پر پول کے ذریعے پیدا ہونے والے ہر بلاک کی ایک فلیٹ % فیس وصول کرتے تھے +- کان کنی کی رگ کو سپورٹ کرنے کے لیے آلات کی ممکنہ لاگت (وینٹیلیشن، توانائی کی نگرانی، بجلی کی وائرنگ، وغیرہ۔) + +کان کنی کے منافع کو مزید دریافت کرنے کے لیے، کان کنی کیلکولیٹر کا استعمال کریں، جیسا کہ [Etherscan](https://etherscan.io/ether-mining-calculator) فراہم کرتا ہے۔ + +## ایتھریم لین دین کی کان کنی کیسے کی گئی {#how-ethereum-transactions-were-mined} + +درج ذیل اس بات کا ایک جائزہ فراہم کرتا ہے کہ ایتھریم کام کے ثبوت میں لین دین کی کان کنی کیسے کی جاتی تھی۔ ایتھریم حصص کے ثبوت کے لیے اس عمل کی ایک مشابہ وضاحت [یہاں](/developers/docs/consensus-mechanisms/pos/#transaction-execution-ethereum-pos) مل سکتی ہے۔ + +1. ایک صارف کسی [اکاؤنٹ](/developers/docs/accounts/) کی نجی کلید کے ساتھ [لین دین](/developers/docs/transactions/) کی درخواست لکھتا اور اس پر دستخط کرتا ہے۔ +2. صارف کسی [نوڈ](/developers/docs/nodes-and-clients/) سے پورے ایتھریم نیٹ ورک پر لین دین کی درخواست کو نشر کرتا ہے۔ +3. نئی لین دین کی درخواست کے بارے میں سننے پر، ایتھریم نیٹ ورک کا ہر نوڈ درخواست کو اپنے مقامی میمپول میں شامل کرتا ہے، جو ان تمام لین دین کی درخواستوں کی ایک فہرست ہے جن کے بارے میں انہوں نے سنا ہے جو ابھی تک کسی بلاک میں بلاک چین کے لیے پرعزم نہیں ہیں۔ +4. کچھ موقع پر، ایک کان کنی نوڈ کئی درجن یا سو لین دین کی درخواستوں کو ایک ممکنہ [بلاک](/developers/docs/blocks/) میں جمع کرتا ہے، اس طرح سے کہ وہ [لین دین کی فیس](/developers/docs/gas/) کو زیادہ سے زیادہ کرتا ہے جو وہ بلاک گیس کی حد کے اندر رہتے ہوئے کماتے ہیں۔ پھر کان کنی نوڈ: + 1. ہر لین دین کی درخواست کی صداقت کی تصدیق کرتا ہے (یعنی، کوئی بھی ایسے اکاؤنٹ سے ایتھر منتقل کرنے کی کوشش نہیں کر رہا ہے جس کے لیے انہوں نے دستخط نہیں کیے ہیں، درخواست غلط نہیں ہے، وغیرہ)، اور پھر درخواست کے کوڈ پر عمل کرتا ہے، EVM کی اپنی مقامی کاپی کی حالت کو تبدیل کرتا ہے۔ کان کن ہر ایسی لین دین کی درخواست کے لیے لین دین کی فیس اپنے اکاؤنٹ میں دیتا ہے۔ + 2. ممکنہ بلاک کے لیے کام کے ثبوت کا "جائز ہونے کا سرٹیفکیٹ" بنانے کا عمل شروع کرتا ہے، ایک بار جب بلاک میں تمام لین دین کی درخواستوں کی تصدیق ہو جاتی ہے اور مقامی EVM کاپی پر عمل درآمد ہو جاتا ہے۔ +5. بالآخر، ایک کان کن ایک ایسے بلاک کے لیے سرٹیفکیٹ بنانا ختم کر دے گا جس میں ہماری مخصوص لین دین کی درخواست شامل ہے۔ پھر کان کن مکمل شدہ بلاک کو نشر کرتا ہے، جس میں سرٹیفکیٹ اور دعوی کردہ نئی EVM حالت کا ایک چیکسم شامل ہوتا ہے۔ +6. دوسرے نوڈز نئے بلاک کے بارے میں سنتے ہیں۔ وہ سرٹیفکیٹ کی تصدیق کرتے ہیں، بلاک پر تمام لین دین خود انجام دیتے ہیں (بشمول ہمارے صارف کے ذریعہ اصل میں نشر کردہ لین دین)، اور تصدیق کرتے ہیں کہ تمام لین دین کے عمل کے بعد ان کی نئی EVM حالت کا چیکسم کان کن کے بلاک کے ذریعہ دعوی کردہ حالت کے چیکسم سے میل کھاتا ہے۔ تب ہی یہ نوڈز اس بلاک کو اپنے بلاک چین کے آخر میں جوڑتے ہیں، اور نئی EVM حالت کو کینونیکل حالت کے طور پر قبول کرتے ہیں۔ +7. ہر نوڈ نئے بلاک میں تمام لین دین کو اپنے مقامی میمپول سے نامکمل لین دین کی درخواستوں سے ہٹا دیتا ہے۔ +8. نیٹ ورک میں شامل ہونے والے نئے نوڈز ترتیب میں تمام بلاکس ڈاؤن لوڈ کرتے ہیں، بشمول وہ بلاک جس میں ہماری دلچسپی کا لین دین ہوتا ہے۔ وہ ایک مقامی EVM کاپی شروع کرتے ہیں (جو ایک خالی حالت EVM کے طور پر شروع ہوتی ہے)، اور پھر اپنی مقامی EVM کاپی کے اوپر ہر بلاک میں ہر لین دین کو انجام دینے کے عمل سے گزرتے ہیں، راستے میں ہر بلاک پر حالت کے چیکسم کی تصدیق کرتے ہیں۔ + +ہر لین دین کی ایک بار کان کنی کی جاتی ہے (ایک نئے بلاک میں شامل کیا جاتا ہے اور پہلی بار پھیلایا جاتا ہے)، لیکن کینونیکل EVM حالت کو آگے بڑھانے کے عمل میں ہر شریک کے ذریعہ اس پر عمل کیا جاتا ہے اور اس کی تصدیق کی جاتی ہے۔ یہ بلاک چین کے مرکزی منتروں میں سے ایک کو اجاگر کرتا ہے: **بھروسہ نہ کریں، تصدیق کریں**۔ + +## اومر (انکل) بلاکس {#ommer-blocks} + +کام کے ثبوت پر بلاک کان کنی امکانی تھی، یعنی کبھی کبھی نیٹ ورک کی تاخیر کی وجہ سے دو درست بلاکس بیک وقت شائع ہو جاتے تھے۔ اس معاملے میں، پروٹوکول کو سب سے لمبی (اور اس لیے سب سے زیادہ "درست") چین کا تعین کرنا پڑا جبکہ کان کنوں کے ساتھ انصاف کو یقینی بناتے ہوئے غیر شامل درست بلاک کو جزوی طور پر انعام دیا گیا۔ اس نے نیٹ ورک کو مزید غیر مرکزی بنانے کی حوصلہ افزائی کی کیونکہ چھوٹے کان کن، جنہیں زیادہ تاخیر کا سامنا کرنا پڑ سکتا ہے، وہ اب بھی [اومر](/glossary/#ommer) بلاک انعامات کے ذریعے منافع کما سکتے ہیں۔ + +اصطلاح "اومر" ایک پیرنٹ بلاک کے بہن بھائی کے لیے ترجیحی صنفی غیر جانبدار اصطلاح ہے، لیکن اسے کبھی کبھی "انکل" بھی کہا جاتا ہے۔ **ایتھریم کے حصص کے ثبوت کی طرف منتقلی کے بعد سے، اومر بلاکس کی مزید کان کنی نہیں کی جاتی ہے** کیونکہ ہر سلاٹ میں صرف ایک تجویز کنندہ منتخب کیا جاتا ہے۔ آپ یہ تبدیلی کان کنی کیے گئے اومر بلاکس کے [تاریخی چارٹ](https://ycharts.com/indicators/ethereum_uncle_rate) کو دیکھ کر دیکھ سکتے ہیں۔ + +## ایک بصری ڈیمو {#a-visual-demo} + +آسٹن کو کان کنی اور کام کے ثبوت والے بلاک چین کے بارے میں بتاتے ہوئے دیکھیں۔ + + + +## کان کنی کا الگورتھم {#mining-algorithm} + +ایتھریم مین نیٹ نے صرف ایک کان کنی الگورتھم کا استعمال کیا - ['ایتھیش'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/)۔ ایتھیش ایک اصل R&D الگورتھم کا جانشین تھا جسے ['Dagger-Hashimoto'](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/) کے نام سے جانا جاتا ہے۔ + +[کان کنی کے الگورتھم پر مزید](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/)۔ + +## متعلقہ موضوعات {#related-topics} + +- [گیس](/developers/docs/gas/) +- [EVM](/developers/docs/evm/) +- [ثبوتِ کار (Proof-of-work)](/developers/docs/consensus-mechanisms/pow/) diff --git a/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md new file mode 100644 index 00000000000..8b393c5d5f6 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto/index.md @@ -0,0 +1,330 @@ +--- +title: Dagger-Hashimoto +description: "Dagger-Hashimoto الگورتھم پر ایک تفصیلی نظر۔" +lang: ur-in +--- + +Dagger-Hashimoto Ethereum کے مائننگ الگورتھم کے لیے اصل تحقیقی نفاذ اور تفصیلات تھیں۔ [Ethash](#ethash) نے Dagger-Hashimoto کی جگہ لے لی۔ 15 ستمبر 2022 کو [The Merge](/roadmap/merge/) پر مائننگ مکمل طور پر بند کر دی گئی تھی۔ تب سے، Ethereum کو اس کے بجائے [proof-of-stake](/developers/docs/consensus-mechanisms/pos) میکانزم کا استعمال کرکے محفوظ کیا گیا ہے۔ یہ صفحہ تاریخی دلچسپی کے لیے ہے - یہاں دی گئی معلومات The Merge کے بعد کے Ethereum کے لیے اب متعلقہ نہیں ہیں۔ + +## شرائط {#prerequisites} + +اس صفحہ کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [proof-of-work consensus](/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} + +الگورتھم کا کوڈ ذیل میں Python میں بیان کیا جائے گا۔ سب سے پہلے، ہم مخصوص درستگی کے غیر دستخط شدہ انٹس کو سٹرنگز میں مارشل کرنے کے لیے `encode_int` دیتے ہیں۔ اس کا الٹا بھی دیا گیا ہے: + +```python +NUM_BITS = 512 + +def encode_int(x): + "ایک big-endian اسکیم کا استعمال کرتے ہوئے ایک انٹیجر x کو 64 حروف کی ایک سٹرنگ کے طور پر انکوڈ کریں" + o = '' + for _ in range(NUM_BITS / 8): + o = chr(x % 256) + o + x //= 256 + return o + +def decode_int(s): + "ایک big-endian اسکیم کا استعمال کرتے ہوئے ایک سٹرنگ سے ایک انٹیجر 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 کے صرف آخری نصف کو ذخیرہ کرنے کی ضرورت ہے، لہذا ڈی-فیکٹو RAM کی ضرورت 1 GB سے شروع ہوتی ہے اور فی سال 441 MB بڑھتی ہے۔ + +### Dagger گراف بنانا {#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 کی اگلی قدر جس تک رسائی حاصل کی جائے گی اس کا تعین اس وقت تک نہیں کیا جا سکتا جب تک کہ موجودہ قدر معلوم نہ ہو۔ آخر میں، ماڈیولر ایکسپونینشن نتیجے کو مزید ہیش کرتا ہے۔ + +یہ الگورتھم نمبر تھیوری کے کئی نتائج پر انحصار کرتا ہے۔ بحث کے لیے نیچے ضمیمہ دیکھیں۔ + +## لائٹ کلائنٹ کی تشخیص {#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 کی پہلی چند ہزار قدروں کا پہلے سے حساب لگاتی ہے اور اسے حساب کے لیے ایک جامد کیشے کے طور پر رکھتی ہے؛ اس کے کوڈ کے نفاذ کے لیے ضمیمہ دیکھیں۔ + +## DAGs کا ڈبل بفر {#double-buffer} + +ایک مکمل کلائنٹ میں، مذکورہ بالا فارمولے سے تیار کردہ 2 DAGs کا ایک [_ڈبل بفر_](https://wikipedia.org/wiki/Multiple_buffering) استعمال کیا جاتا ہے۔ خیال یہ ہے کہ DAGs مذکورہ بالا پیرامیٹرز کے مطابق ہر `epochtime` تعداد کے بلاکس پر تیار کیے جاتے ہیں۔ کلائنٹ تازہ ترین تیار کردہ DAG استعمال کرنے کے بجائے، پچھلا والا استعمال کرتا ہے۔ اس کا فائدہ یہ ہے کہ یہ DAGs کو وقت کے ساتھ تبدیل کرنے کی اجازت دیتا ہے بغیر کسی ایسے قدم کو شامل کرنے کی ضرورت کے جہاں مائنرز کو اچانک تمام ڈیٹا کا دوبارہ حساب لگانا پڑے۔ بصورت دیگر، باقاعدہ وقفوں پر چین پروسیسنگ میں اچانک عارضی سست روی اور مرکزیت میں ڈرامائی طور پر اضافہ ہونے کا امکان ہے۔ اس طرح تمام ڈیٹا کا دوبارہ حساب لگانے سے پہلے ان چند منٹوں کے اندر 51% حملے کا خطرہ ہوتا ہے۔ + +ایک بلاک کے لیے کام کا حساب لگانے کے لیے استعمال ہونے والے DAGs کا سیٹ بنانے کے لیے استعمال ہونے والا الگورتھم مندرجہ ذیل ہے: + +```python +def get_prevhash(n): + from pyethereum.blocks import GENESIS_PREVHASH + from pyethereum import chain_manager + if n <= 0: + return hash_to_int(GENESIS_PREVHASH) + else: + prevhash = chain_manager.index.get_block_by_number(n - 1) + return decode_int(prevhash) + +def get_seedset(params, block): + seedset = {} + seedset["back_number"] = block.number - (block.number % params["epochtime"]) + seedset["back_hash"] = get_prevhash(seedset["back_number"]) + seedset["front_number"] = max(seedset["back_number"] - params["epochtime"], 0) + seedset["front_hash"] = get_prevhash(seedset["front_number"]) + return seedset + +def get_dagsize(params, block): + return params["n"] + (block.number // params["epochtime"]) * params["n_inc"] + +def get_daggerset(params, block): + dagsz = get_dagsize(params, block) + seedset = get_seedset(params, block) + if seedset["front_hash"] <= 0: + # No back buffer is possible, just make front buffer + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": 0}} + else: + return {"front": {"dag": produce_dag(params, seedset["front_hash"], dagsz), + "block_number": seedset["front_number"]}, + "back": {"dag": produce_dag(params, seedset["back_hash"], dagsz), + "block_number": seedset["back_number"]}} +``` + +## Hashimoto {#hashimoto} + +اصل Hashimoto کے پیچھے خیال یہ ہے کہ بلاک چین کو بطور ڈیٹاسیٹ استعمال کیا جائے، ایک ایسا حساب انجام دیا جائے جو بلاک چین سے N انڈیکس منتخب کرتا ہے، ان انڈیکس پر ٹرانزیکشنز کو جمع کرتا ہے، اس ڈیٹا کا XOR انجام دیتا ہے، اور نتیجے کا ہیش واپس کرتا ہے۔ تھڈیئس ڈرائجا کا اصل الگورتھم، مطابقت کے لیے Python میں ترجمہ کیا گیا، مندرجہ ذیل ہے: + +```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) +``` + +بدقسمتی سے، جبکہ Hashimoto کو 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 بلاک ہیڈر پر اضافی تقاضے عائد کرتا ہے: + +- دو-تہہ کی تصدیق کے کام کرنے کے لیے، ایک بلاک ہیڈر میں نونس اور درمیانی قدر دونوں پری-sha3 ہونی چاہئیں۔ +- کہیں، ایک بلاک ہیڈر کو موجودہ سیڈ سیٹ کا sha3 ذخیرہ کرنا چاہیے۔ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## ضمیمہ {#appendix} + +جیسا کہ اوپر ذکر کیا گیا ہے، DAG جنریشن کے لیے استعمال ہونے والا RNG نمبر تھیوری کے کچھ نتائج پر انحصار کرتا ہے۔ سب سے پہلے، ہم یہ یقین دہانی فراہم کرتے ہیں کہ Lehmer RNG جو `picker` متغیر کی بنیاد ہے اس کا ایک وسیع دور ہے۔ دوسرا، ہم دکھاتے ہیں کہ `pow(x,3,P)`، `x` کو `1` یا `P-1` پر میپ نہیں کرے گا بشرطیکہ شروع کرنے کے لیے `x ∈ [2,P-2]` ہو۔ آخر میں، ہم دکھاتے ہیں کہ جب ہیشنگ فنکشن کے طور پر علاج کیا جاتا ہے تو `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` کا _آرڈر_ کم سے کم `m` کے طور پر بیان کیا گیا ہے جیسے کہ 
xᵐ mod P ≡ 1
+ان تعریفوں کو دیکھتے ہوئے، ہمارے پاس ہے: + +> مشاہدہ 1۔ `x` کو ایک سیف پرائم `P` کے لیے ضرب گروپ `ℤ/Pℤ` کا رکن ہونے دیں۔ اگر `x mod P ≠ 1 mod P` اور `x mod P ≠ P-1 mod P`، تو `x` کا آرڈر یا تو `P-1` ہے یا `(P-1)/2`۔ + +_ثبوت_۔ چونکہ `P` ایک سیف پرائم ہے، تب [Lagrange کے تھیورم][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۔ `x` کو ایک سیف پرائم `P` کے لیے ضرب گروپ `ℤ/Pℤ` کا رکن ہونے دیں، اور `w` کو ایک قدرتی عدد ہونے دیں۔ اگر `x mod P ≠ 1 mod P` اور `x mod P ≠ P-1 mod P`، نیز `w mod P ≠ P-1 mod P` اور `w mod P ≠ 0 mod P`، تو `xʷ mod P ≠ 1 mod P` اور `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` کو ایک پرائم ہونے دیں؛ `w` اور `P-1` نسبتاً پرائم ہیں اگر اور صرف اگر `ℤ/Pℤ` میں تمام `a` اور `b` کے لیے:
`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/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md new file mode 100644 index 00000000000..bd5a268ae70 --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash/index.md @@ -0,0 +1,1019 @@ +--- +title: Ethash +description: "ایتھ ہیش الگورتھم پر ایک تفصیلی نظر۔" +lang: ur-in +--- + + + + + + Ethash ایتھیریم کا پروف آف ورک مائننگ الگورتھم تھا۔ پروف آف ورک کو اب **مکمل طور پر بند** کر دیا گیا ہے اور ایتھیریم کو اب اس کے بجائے [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos/) کا استعمال کرکے محفوظ کیا گیا ہے۔ [دی مرج](/roadmap/merge/)، [پروف آف اسٹیک](/developers/docs/consensus-mechanisms/pos/) اور [اسٹیکنگ](/staking/) کے بارے میں مزید پڑھیں۔ یہ صفحہ تاریخی دلچسپی کے لیے ہے! + + + + +ایتھ ہیش [Dagger-Hashimoto](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/dagger-hashimoto) الگورتھم کا ایک ترمیم شدہ ورژن ہے۔ ایتھ ہیش پروف-آف-ورک [میموری ہارڈ](https://wikipedia.org/wiki/Memory-hard_function) ہے، جس کے بارے میں سوچا گیا تھا کہ یہ الگورتھم کو ASIC مزاحم بناتا ہے۔ ایتھ ہیش ASICs آخرکار تیار ہو گئے تھے لیکن GPU مائننگ اس وقت تک ایک قابل عمل آپشن تھا جب تک کہ پروف-آف-ورک کو بند نہیں کر دیا گیا۔ ایتھ ہیش اب بھی دیگر غیر-ایتھیریم پروف-آف-ورک نیٹ ورکس پر دوسرے کوائنز کو مائن کرنے کے لئے استعمال کیا جاتا ہے۔ + +## ایتھ ہیش کیسے کام کرتا ہے؟ {#how-does-ethash-work} + +میموری ہارڈنس ایک پروف آف ورک الگورتھم کے ساتھ حاصل کی جاتی ہے جس کے لئے نانس اور بلاک ہیڈر پر منحصر ایک مقررہ وسیلہ کے سب سیٹ کو منتخب کرنے کی ضرورت ہوتی ہے۔ اس وسیلہ (کچھ گیگا بائٹس سائز میں) کو DAG کہا جاتا ہے۔ DAG ہر 30000 بلاکس پر تبدیل ہوتا ہے، ایک ~125 گھنٹے کی ونڈو جسے ایپوک کہا جاتا ہے (تقریباً 5.2 دن) اور اسے جنریٹ ہونے میں کچھ وقت لگتا ہے۔ چونکہ DAG صرف بلاک کی اونچائی پر منحصر ہے، اسے پہلے سے جنریٹ کیا جا سکتا ہے، لیکن اگر ایسا نہیں ہے تو کلائنٹ کو بلاک بنانے کے لئے اس عمل کے اختتام تک انتظار کرنے کی ضرورت ہے۔ اگر کلائنٹس وقت سے پہلے DAGs کو پہلے سے جنریٹ اور کیش نہیں کرتے ہیں تو نیٹ ورک کو ہر ایپوک کی منتقلی پر بڑے پیمانے پر بلاک میں تاخیر کا سامنا کرنا پڑ سکتا ہے۔ نوٹ کریں کہ پروف-آف-ورک کی تصدیق کے لئے DAG کو جنریٹ کرنے کی ضرورت نہیں ہے جو بنیادی طور پر کم CPU اور چھوٹی میموری دونوں کے ساتھ تصدیق کی اجازت دیتا ہے۔ + +الگورتھم جو عمومی راستہ اختیار کرتا ہے وہ حسب ذیل ہے: + +1. ایک **سیڈ** موجود ہے جسے اس وقت تک بلاک ہیڈرز کو اسکین کرکے ہر بلاک کے لئے شمار کیا جاسکتا ہے۔ +2. سیڈ سے، کوئی **16 MB کا سیوڈو رینڈم کیش** شمار کر سکتا ہے۔ لائٹ کلائنٹس کیش کو اسٹور کرتے ہیں۔ +3. کیش سے، ہم ایک **1 GB ڈیٹاسیٹ** جنریٹ کر سکتے ہیں، اس خصوصیت کے ساتھ کہ ڈیٹاسیٹ میں ہر آئٹم کیش سے صرف چند آئٹمز پر منحصر ہے۔ فل کلائنٹس اور مائنرز ڈیٹاسیٹ کو اسٹور کرتے ہیں۔ ڈیٹاسیٹ وقت کے ساتھ خطی طور پر بڑھتا ہے۔ +4. مائننگ میں ڈیٹاسیٹ کے بے ترتیب سلائسز کو پکڑنا اور انہیں ایک ساتھ ہیش کرنا شامل ہے۔ کیش کا استعمال کرکے کم میموری کے ساتھ تصدیق کی جا سکتی ہے تاکہ ڈیٹاسیٹ کے ان مخصوص ٹکڑوں کو دوبارہ جنریٹ کیا جا سکے جن کی آپ کو ضرورت ہے، لہذا آپ کو صرف کیش کو اسٹور کرنے کی ضرورت ہے۔ + +بڑا ڈیٹاسیٹ ہر 30000 بلاکس میں ایک بار اپ ڈیٹ ہوتا ہے، لہذا ایک مائنر کی زیادہ تر کوشش ڈیٹاسیٹ کو پڑھنے کی ہوگی، نہ کہ اس میں تبدیلیاں کرنے کی۔ + +## تعریفیں {#definitions} + +ہم مندرجہ ذیل تعریفیں استعمال کرتے ہیں: + +``` +WORD_BYTES = 4 # لفظ میں بائٹس +DATASET_BYTES_INIT = 2**30 # جینیسس پر ڈیٹاسیٹ میں بائٹس +DATASET_BYTES_GROWTH = 2**23 # فی ایپوک ڈیٹاسیٹ کی بڑھوتری +CACHE_BYTES_INIT = 2**24 # جینیسس پر کیش میں بائٹس +CACHE_BYTES_GROWTH = 2**17 # فی ایپوک کیش کی بڑھوتری +CACHE_MULTIPLIER=1024 # کیش کے مقابلے میں DAG کا سائز +EPOCH_LENGTH = 30000 # فی ایپوک بلاکس +MIX_BYTES = 128 # مکس کی چوڑائی +HASH_BYTES = 64 # بائٹس میں ہیش کی لمبائی +DATASET_PARENTS = 256 # ہر ڈیٹاسیٹ عنصر کے پیرنٹس کی تعداد +CACHE_ROUNDS = 3 # کیش پروڈکشن میں راؤنڈز کی تعداد +ACCESSES = 64 # ہاشیموٹو لوپ میں رسائیوں کی تعداد +``` + +### '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} + +ایتھ ہیش کے کیش اور ڈیٹاسیٹ کے پیرامیٹرز بلاک نمبر پر منحصر ہیں۔ کیش کا سائز اور ڈیٹاسیٹ کا سائز دونوں خطی طور پر بڑھتے ہیں؛ تاہم، ہم ہمیشہ خطی طور پر بڑھتی ہوئی حد سے نیچے سب سے زیادہ پرائم لیتے ہیں تاکہ چکری رویے کی طرف لے جانے والی حادثاتی باقاعدگیوں کے خطرے کو کم کیا جا سکے۔ + +```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 + + # ترتیب وار ابتدائی ڈیٹاسیٹ تیار کریں + o = [sha3_512(seed)] + for i in range(1, n): + o.append(sha3_512(o[-1])) + + # 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 میموری کو بھرنا شامل ہے، پھر سرجیو ڈیمین لرنر کے [_اسٹرکٹ میموری ہارڈ ہیشنگ فنکشنز_ (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) سے متاثر ایک الگورتھم استعمال کرتے ہیں۔ نوٹ کریں کہ ہم پرائم کو پورے 32-بٹ ان پٹ سے ضرب دیتے ہیں، FNV-1 اسپیک کے برعکس جو پرائم کو باری باری ایک بائٹ (آکٹیٹ) سے ضرب دیتا ہے۔ + +```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 + # مکس کو شروع کریں + mix = copy.copy(cache[i % n]) + mix[0] ^= i + mix = sha3_512(mix) + # اسے i پر مبنی بہت سے بے ترتیب کیش نوڈز کے ساتھ fnv کریں + 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} + +اب، ہم مرکزی "ہاشیموٹو" جیسے لوپ کی وضاحت کرتے ہیں، جہاں ہم ایک خاص ہیڈر اور نانس کے لئے اپنی حتمی قدر پیدا کرنے کے لئے مکمل ڈیٹاسیٹ سے ڈیٹا جمع کرتے ہیں۔ نیچے دیے گئے کوڈ میں، `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 + # 64 بائٹ سیڈ میں ہیڈر+نانس کو یکجا کریں + s = sha3_512(header + nonce[::-1]) + # نقل شدہ s کے ساتھ مکس شروع کریں + mix = [] + for _ in range(MIX_BYTES / HASH_BYTES): + mix.extend(s) + # بے ترتیب ڈیٹاسیٹ نوڈز میں مکس کریں + 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) + # مکس کو کمپریس کریں + 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 سے ایک پورا صفحہ حاصل کرے، ٹرانسلیشن لوک اسائیڈ بفر مسز کو کم سے کم کرتا ہے جس سے ASICs نظریاتی طور پر بچنے کے قابل ہوں گے۔ + +اگر اس الگورتھم کا آؤٹ پٹ مطلوبہ ہدف سے کم ہے، تو نانس درست ہے۔ نوٹ کریں کہ آخر میں `sha3_256` کا اضافی اطلاق اس بات کو یقینی بناتا ہے کہ ایک درمیانی نانس موجود ہے جسے یہ ثابت کرنے کے لئے فراہم کیا جا سکتا ہے کہ کم از کم تھوڑا سا کام کیا گیا تھا؛ اس فوری بیرونی PoW تصدیق کو اینٹی-DDoS مقاصد کے لئے استعمال کیا جا سکتا ہے۔ یہ اس بات کی شماریاتی یقین دہانی فراہم کرنے کا بھی کام کرتا ہے کہ نتیجہ ایک غیر جانبدار، 256 بٹ نمبر ہے۔ + +## مائننگ {#mining} + +مائننگ الگورتھم کی تعریف اس طرح کی گئی ہے: + +```python +def mine(full_size, dataset, header, difficulty): + # ہیش کے ساتھ اسی ہندسے پر موازنہ کرنے کے لئے ہدف کو صفر-پیڈ کریں + 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 + +# لٹل اینڈین بٹ آرڈرنگ فرض کرتا ہے (انٹیل آرکیٹیکچرز کی طرح) +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 ہیش فنکشن، 64 بائٹس آؤٹ پٹ کرتا ہے +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, 26777728, 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/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md new file mode 100644 index 00000000000..b27918625bb --- /dev/null +++ b/public/content/translations/ur/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/index.md @@ -0,0 +1,42 @@ +--- +title: "مائننگ الگورتھم" +description: "Ethereum مائننگ کے لیے استعمال ہونے والے الگورتھم پر ایک تفصیلی نظر۔" +lang: ur-in +--- + + + + + +کام کا ثبوت اب ایتھریم کے اتفاق رائے کے طریقہ کار کی بنیاد نہیں ہے، جس کا مطلب ہے کہ کان کنی کو بند کر دیا گیا ہے۔ اس کے بجائے، ایتھریم کو توثیق کنندگان کے ذریعے محفوظ کیا جاتا ہے جو ETH کو اسٹیک کرتے ہیں۔ آپ آج ہی اپنے ETH کو اسٹیک کرنا شروع کر سکتے ہیں۔ مرج، حصص کے ثبوت، اور اسٹیکنگ پر مزید پڑھیں۔ یہ صفحہ صرف تاریخی دلچسپی کے لیے ہے۔ + + + + +Ethereum مائننگ میں Ethash نامی ایک الگورتھم کا استعمال کیا گیا تھا۔ اس الگورتھم کا بنیادی خیال یہ ہے کہ ایک مائنر بروٹ فورس کمپیوٹیشن کا استعمال کرتے ہوئے ایک نانس ان پٹ تلاش کرنے کی کوشش کرتا ہے تاکہ نتیجہ خیز ہیش حسابی مشکل سے طے شدہ حد سے چھوٹا ہو۔ اس مشکل کی سطح کو متحرک طور پر ایڈجسٹ کیا جا سکتا ہے، جس سے بلاک کی پیداوار ایک باقاعدہ وقفے پر ہو سکتی ہے۔ + +## شرائط {#prerequisites} + +اس صفحے کو بہتر طور پر سمجھنے کے لیے، ہم تجویز کرتے ہیں کہ آپ پہلے [پروف-آف-ورک اتفاق رائے](/developers/docs/consensus-mechanisms/pow) اور [مائننگ](/developers/docs/consensus-mechanisms/pow/mining) کے بارے میں پڑھیں۔ + +## Dagger Hashimoto {#dagger-hashimoto} + +Dagger Hashimoto Ethereum مائننگ کے لیے ایک پیشرو تحقیقی الگورتھم تھا جسے Ethash نے پیچھے چھوڑ دیا۔ یہ دو مختلف الگورتھم کا امتزاج تھا: Dagger اور Hashimoto۔ یہ صرف ایک تحقیقی نفاذ تھا اور Ethereum Mainnet کے لانچ ہونے تک اسے Ethash نے پیچھے چھوڑ دیا تھا۔ + +[Dagger](http://www.hashcash.org/papers/dagger.html) میں ایک [ڈائریکٹڈ ایسائکلک گراف](https://en.wikipedia.org/wiki/Directed_acyclic_graph) کی تخلیق شامل ہے، جس کے بے ترتیب سلائسز کو ایک ساتھ ہیش کیا جاتا ہے۔ بنیادی اصول یہ ہے کہ ہر نانس کو ایک بڑے کل ڈیٹا ٹری کے صرف ایک چھوٹے سے حصے کی ضرورت ہوتی ہے۔ ہر نانس کے لیے سب ٹری کو دوبارہ کمپیوٹ کرنا مائننگ کے لیے ممنوع ہے - اس لیے ٹری کو اسٹور کرنے کی ضرورت ہے - لیکن ایک نانس کی تصدیق کے لیے یہ ٹھیک ہے۔ Dagger کو Scrypt جیسے موجودہ الگورتھم کے متبادل کے طور پر ڈیزائن کیا گیا تھا، جو میموری-ہارڈ ہیں لیکن جب ان کی میموری-ہارڈنیس واقعی محفوظ سطح تک بڑھ جاتی ہے تو ان کی تصدیق کرنا مشکل ہو جاتا ہے۔ تاہم، Dagger مشترکہ میموری ہارڈویئر ایکسلریشن کے لیے کمزور تھا اور تحقیق کے دیگر راستوں کے حق میں اسے چھوڑ دیا گیا۔ + +[Hashimoto](http://diyhpl.us/%7Ebryan/papers2/bitcoin/meh/hashimoto.pdf) ایک الگورتھم ہے جو I/O باؤنڈ ہو کر 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 {#ethash} + +Ethash وہ مائننگ الگورتھم تھا جو اصل میں Ethereum Mainnet پر اب متروک پروف-آف-ورک آرکیٹیکچر کے تحت استعمال کیا گیا تھا۔ Ethash مؤثر طریقے سے Dagger-Hashimoto کے ایک مخصوص ورژن کو دیا گیا ایک نیا نام تھا جب الگورتھم کو نمایاں طور پر اپ ڈیٹ کیا گیا، جبکہ اب بھی اپنے پیشرو کے بنیادی اصولوں کو وراثت میں مل رہا تھا۔ Ethereum Mainnet نے ہمیشہ صرف Ethash کا استعمال کیا - Dagger Hashimoto مائننگ الگورتھم کا ایک R&D ورژن تھا جسے Ethereum Mainnet پر مائننگ شروع ہونے سے پہلے ہی پیچھے چھوڑ دیا گیا تھا۔ + +[Ethash پر مزید](/developers/docs/consensus-mechanisms/pow/mining/mining-algorithms/ethash)۔ + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ diff --git a/public/content/translations/ur/developers/docs/dapps/index.md b/public/content/translations/ur/developers/docs/dapps/index.md new file mode 100644 index 00000000000..bdf0941cb59 --- /dev/null +++ b/public/content/translations/ur/developers/docs/dapps/index.md @@ -0,0 +1,96 @@ +--- +title: "Dapps کا تکنیکی تعارف" +description: +lang: ur-in +--- + +ایک وکندریقرت ایپلیکیشن (dapp) ایک وکندریقرت نیٹ ورک پر بنائی گئی ایک ایپلیکیشن ہے جو ایک [اسمارٹ کنٹریکٹ](/developers/docs/smart-contracts/) اور ایک فرنٹ اینڈ یوزر انٹرفیس کو یکجا کرتی ہے۔ Ethereum پر، اسمارٹ کنٹریکٹس قابل رسائی اور شفاف ہیں – کھلے APIs کی طرح – لہذا آپ کی 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 ورچوئل مشین کہا جاتا ہے تاکہ اگر اسمارٹ کنٹریکٹ میں کوئی بگ ہو تو یہ بلاک چین نیٹ ورک کے معمول کے کام میں رکاوٹ نہ ڈالے + +### اسمارٹ کنٹریکٹس پر {#on-smart-contracts} + +dapps کا تعارف کرانے کے لیے، ہمیں اسمارٹ کنٹریکٹس کا تعارف کرانے کی ضرورت ہے – بہتر اصطلاح کی کمی کی وجہ سے ایک dapp کا بیک اینڈ۔ تفصیلی جائزہ کے لیے، [اسمارٹ کنٹریکٹس](/developers/docs/smart-contracts/) پر ہمارے سیکشن پر جائیں۔ + +ایک اسمارٹ کنٹریکٹ کوڈ ہے جو Ethereum بلاک چین پر رہتا ہے اور بالکل اسی طرح چلتا ہے جیسا کہ پروگرام کیا گیا ہے۔ ایک بار جب اسمارٹ کنٹریکٹس نیٹ ورک پر تعینات ہو جاتے ہیں تو آپ انہیں تبدیل نہیں کر سکتے۔ Dapps کو وکندریقرت کیا جا سکتا ہے کیونکہ وہ کسی فرد یا کمپنی کے بجائے کنٹریکٹ میں لکھی گئی منطق کے ذریعے کنٹرول ہوتے ہیں۔ اس کا یہ بھی مطلب ہے کہ آپ کو اپنے کنٹریکٹس کو بہت احتیاط سے ڈیزائن کرنے اور انہیں اچھی طرح سے ٹیسٹ کرنے کی ضرورت ہے۔ + +## dapp ڈیولپمنٹ کے فوائد {#benefits-of-dapp-development} + +- **زیرو ڈاؤن ٹائم** – ایک بار جب اسمارٹ کنٹریکٹ بلاک چین پر تعینات ہو جاتا ہے، تو نیٹ ورک بحیثیت مجموعی ہمیشہ ان کلائنٹس کی خدمت کرنے کے قابل ہوگا جو کنٹریکٹ کے ساتھ تعامل کرنا چاہتے ہیں۔ لہذا، بدنیتی پر مبنی اداکار انفرادی dapps کو نشانہ بناتے ہوئے سروس سے انکار (denial-of-service) حملے شروع نہیں کر سکتے ہیں۔ +- **رازداری** – آپ کو ایک dapp کو تعینات کرنے یا اس کے ساتھ تعامل کرنے کے لیے حقیقی دنیا کی شناخت فراہم کرنے کی ضرورت نہیں ہے۔ +- **سنسرشپ کے خلاف مزاحمت** – نیٹ ورک پر کوئی بھی واحد ادارہ صارفین کو ٹرانزیکشنز جمع کرنے، dapps تعینات کرنے، یا بلاک چین سے ڈیٹا پڑھنے سے نہیں روک سکتا۔ +- **ڈیٹا کی مکمل سالمیت** – بلاک چین پر ذخیرہ شدہ ڈیٹا کرپٹوگرافک پریمیٹیوز کی بدولت ناقابل تغیر اور ناقابل تردید ہے۔ بدنیتی پر مبنی اداکار ان ٹرانزیکشنز یا دیگر ڈیٹا کو جعلی نہیں بنا سکتے جو پہلے ہی عوامی کر دیا گیا ہو۔ +- **بے اعتماد شمار/قابل تصدیق رویہ** – اسمارٹ کنٹریکٹس کا تجزیہ کیا جا سکتا ہے اور ان کی پیش قیاسی طریقوں سے عمل درآمد کی ضمانت دی جاتی ہے، بغیر کسی مرکزی اتھارٹی پر بھروسہ کرنے کی ضرورت کے۔ روایتی ماڈلز میں یہ سچ نہیں ہے؛ مثال کے طور پر، جب ہم آن لائن بینکنگ سسٹم استعمال کرتے ہیں، تو ہمیں یہ بھروسہ کرنا پڑتا ہے کہ مالیاتی ادارے ہمارے مالیاتی ڈیٹا کا غلط استعمال نہیں کریں گے، ریکارڈز میں چھیڑ چھاڑ نہیں کریں گے، یا ہیک نہیں ہوں گے۔ + +## dapp ڈیولپمنٹ کے نقصانات {#drawbacks-of-dapp-development} + +- **دیکھ بھال** – Dapps کی دیکھ بھال کرنا مشکل ہو سکتا ہے کیونکہ بلاک چین پر شائع کردہ کوڈ اور ڈیٹا میں ترمیم کرنا مشکل ہوتا ہے۔ ڈیولپرز کے لیے ایک بار تعینات ہونے کے بعد اپنی dapps (یا ایک dapp کے ذریعے ذخیرہ کردہ بنیادی ڈیٹا) میں اپ ڈیٹس کرنا مشکل ہوتا ہے، چاہے پرانے ورژن میں بگز یا سیکیورٹی خطرات کی نشاندہی ہی کیوں نہ کی گئی ہو۔ +- **کارکردگی کا اوورہیڈ** – کارکردگی کا ایک بہت بڑا اوورہیڈ ہے، اور اسکیلنگ واقعی مشکل ہے۔ سیکیورٹی، سالمیت، شفافیت، اور بھروسے کی وہ سطح حاصل کرنے کے لیے جس کی Ethereum خواہش کرتا ہے، ہر نوڈ ہر ٹرانزیکشن کو چلاتا اور ذخیرہ کرتا ہے۔ اس کے علاوہ، پروف-آف-اسٹیک اتفاق رائے میں بھی وقت لگتا ہے۔ +- **نیٹ ورک کی بھیڑ** – جب ایک 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 ڈیولپرز کے لیے اپنے نوڈ کو ٹیسٹ کرنے، اور براؤزر سے RPC کالز کمپوز اور ڈیبگ کرنے کے لیے FOSS ٹول۔_** + +- [etherflow.quiknode.io](https://etherflow.quiknode.io/) +- [GitHub](https://github.com/abunsen/etherflow) + +**thirdweb _- ہر زبان میں SDKs، اسمارٹ کنٹریکٹس، ٹولز، اور web3 ڈیولپمنٹ کے لیے انفراسٹرکچر۔_** + +- [ہوم پیج](https://thirdweb.com/) +- [ڈاکومینٹیشن](https://portal.thirdweb.com/) +- [GitHub](https://github.com/thirdweb-dev/) + +**Crossmint _- اسمارٹ کنٹریکٹس تعینات کرنے، کریڈٹ کارڈ اور کراس چین ادائیگیوں کو فعال کرنے، اور NFTs بنانے، تقسیم کرنے، بیچنے، ذخیرہ کرنے، اور ترمیم کرنے کے لیے APIs استعمال کرنے کے لیے انٹرپرائز-گریڈ web3 ڈیولپمنٹ پلیٹ فارم۔_** + +- [crossmint.com](https://www.crossmint.com) +- [ڈاکومینٹیشن](https://docs.crossmint.com) +- [Discord](https://discord.com/invite/crossmint) + +## مزید پڑھیں {#further-reading} + +- [dapps کو دریافت کریں](/apps) +- [The Architecture of a Web 3.0 application](https://www.preethikasireddy.com/post/the-architecture-of-a-web-3-0-application) - _Preethi Kasireddy_ +- [وکندریقرت ایپلیکیشنز کے لیے 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/ur/developers/docs/data-and-analytics/block-explorers/index.md b/public/content/translations/ur/developers/docs/data-and-analytics/block-explorers/index.md new file mode 100644 index 00000000000..90cbc4c5421 --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-and-analytics/block-explorers/index.md @@ -0,0 +1,254 @@ +--- +title: "بلاک ایکسپلوررز" +description: "بلاک ایکسپلوررز کا تعارف، بلاک چین ڈیٹا کی دنیا میں آپ کا پورٹل، جہاں آپ ٹرانزیکشنز، اکاؤنٹس، کانٹریکٹس، اور مزید کے بارے میں معلومات حاصل کر سکتے ہیں۔" +lang: ur-in +sidebarDepth: 3 +--- + +بلاک ایکسپلوررز Ethereum کے ڈیٹا تک آپ کا پورٹل ہیں۔ آپ ان کا استعمال بلاکس، ٹرانزیکشنز، ویلیڈیٹرز، اکاؤنٹس، اور دیگر آن چین سرگرمیوں پر ریئل ٹائم ڈیٹا دیکھنے کے لیے کر سکتے ہیں۔ + +## شرائط {#prerequisites} + +آپ کو Ethereum کے بنیادی تصورات کو سمجھنا چاہئے تاکہ آپ اس ڈیٹا کو سمجھ سکیں جو ایک بلاک ایکسپلورر آپ کو دیتا ہے۔ [Ethereum کے تعارف](/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 Block Explorer](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} + +Ethereum ڈیزائن کے لحاظ سے شفاف ہے لہذا ہر چیز قابل تصدیق ہے۔ بلاک ایکسپلوررز اس معلومات کو حاصل کرنے کے لیے ایک انٹرفیس فراہم کرتے ہیں۔ اور یہ مرکزی Ethereum نیٹ ورک اور ٹیسٹ نیٹ دونوں کے لیے ہے، اگر آپ کو اس ڈیٹا کی ضرورت ہو۔ ڈیٹا کو ایکزیکیوشن ڈیٹا اور کنسینسس ڈیٹا میں تقسیم کیا گیا ہے۔ ایگزیکیوشن ڈیٹا سے مراد وہ ٹرانزیکشنز ہیں جو کسی مخصوص بلاک میں انجام دی گئی ہیں۔ کنسینسس ڈیٹا خود بلاکس اور ان کو تجویز کرنے والے ویلیڈیٹرز سے متعلق ہے۔ + +یہاں اس قسم کے ڈیٹا کا خلاصہ ہے جو آپ بلاک ایکسپلورر سے حاصل کر سکتے ہیں۔ + +### ایگزیکیوشن ڈیٹا {#execution-data} + +ہر 12 سیکنڈ میں Ethereum میں نئے بلاکس شامل کیے جاتے ہیں (جب تک کہ کوئی بلاک پروپوزر اپنی باری سے محروم نہ ہو جائے)، لہذا بلاک ایکسپلوررز میں ڈیٹا کا تقریبا مستقل سلسلہ شامل ہوتا رہتا ہے۔ بلاکس میں بہت سا اہم ڈیٹا ہوتا ہے جو آپ کے لیے کارآمد ہو سکتا ہے: + +**معیاری ڈیٹا** + +- بلاک کی اونچائی - موجودہ بلاک کی تخلیق پر بلاک نمبر اور بلاک چین کی لمبائی (بلاکس میں) +- ٹائم اسٹیمپ - وہ وقت جب ایک بلاک تجویز کیا گیا تھا +- ٹرانزیکشنز - بلاک کے اندر شامل ٹرانزیکشنز کی تعداد +- فیس وصول کنندہ - وہ ایڈریس جس نے ٹرانزیکشنز سے گیس فیس ٹپس وصول کیں +- بلاک کا انعام - بلاک تجویز کرنے والے ویلیڈیٹر کو دی گئی ETH کی رقم +- سائز - بلاک کے اندر ڈیٹا کا سائز (بائٹس میں ماپا جاتا ہے) +- استعمال شدہ گیس - بلاک میں ٹرانزیکشنز کے ذریعے استعمال ہونے والی گیس کی کل اکائیاں +- گیس کی حد - بلاک میں ٹرانزیکشنز کے ذریعے مقرر کردہ گیس کی کل حدیں +- فی گیس بنیادی فیس - کسی ٹرانزیکشن کو بلاک میں شامل کرنے کے لیے درکار کم از کم ملٹی پلائر +- جلائی گئی فیس - بلاک میں کتنی ETH جلائی جاتی ہے +- اضافی ڈیٹا - کوئی بھی اضافی ڈیٹا جو بلڈر نے بلاک میں شامل کیا ہے + +**ایڈوانسڈ ڈیٹا** + +- ہیش - کرپٹوگرافک ہیش جو بلاک ہیڈر کی نمائندگی کرتا ہے (بلاک کا منفرد شناخت کنندہ) +- پیرنٹ ہیش - موجودہ بلاک سے پہلے آنے والے بلاک کا ہیش +- اسٹیٹ روٹ - مرکل ٹرائی کا روٹ ہیش جو سسٹم کی پوری حالت کو اسٹور کرتا ہے + +### گیس {#gas} + +بلاک ایکسپلوررز نہ صرف آپ کو ٹرانزیکشنز اور بلاکس میں گیس کے استعمال کے بارے میں ڈیٹا دیں گے، بلکہ کچھ آپ کو نیٹ ورک کی موجودہ گیس کی قیمتوں کے بارے میں بھی معلومات دیں گے۔ اس سے آپ کو نیٹ ورک کے استعمال کو سمجھنے، محفوظ ٹرانزیکشنز جمع کرانے اور گیس پر زیادہ خرچ نہ کرنے میں مدد ملے گی۔ ایسے APIs تلاش کریں جو آپ کو یہ معلومات اپنے پروڈکٹ کے انٹرفیس میں حاصل کرنے میں مدد دے سکیں۔ گیس سے متعلق ڈیٹا میں شامل ہیں: + +- ایک محفوظ لیکن سست ٹرانزیکشن کے لیے درکار گیس کی تخمینی اکائیاں (+ تخمینی قیمت اور مدت) +- ایک اوسط ٹرانزیکشن کے لیے درکار گیس کی تخمینی اکائیاں (+ تخمینی قیمت اور مدت) +- ایک تیز ٹرانزیکشن کے لیے درکار گیس کی تخمینی اکائیاں (+ تخمینی قیمت اور مدت) +- گیس کی قیمت پر مبنی اوسط تصدیقی وقت +- وہ کانٹریکٹس جو گیس استعمال کر رہے ہیں - دوسرے الفاظ میں، مقبول پروڈکٹس جو نیٹ ورک پر بہت زیادہ استعمال ہو رہے ہیں +- وہ اکاؤنٹس جو گیس خرچ کر رہے ہیں - دوسرے الفاظ میں، نیٹ ورک کے بار بار استعمال کرنے والے + +### ٹرانزیکشنز {#transactions} + +بلاک ایکسپلوررز لوگوں کے لیے اپنے ٹرانزیکشنز کی پیشرفت کو ٹریک کرنے کے لیے ایک عام جگہ بن گئے ہیں۔ اس کی وجہ یہ ہے کہ آپ جو تفصیل حاصل کر سکتے ہیں وہ اضافی یقین دہانی فراہم کرتی ہے۔ ٹرانزیکشن ڈیٹا میں شامل ہیں: + +**معیاری ڈیٹا** + +- ٹرانزیکشن ہیش - ایک ہیش جو ٹرانزیکشن جمع کرانے پر تیار ہوتا ہے +- اسٹیٹس - اس بات کا اشارہ کہ ٹرانزیکشن زیر التوا، ناکام یا کامیاب ہے +- بلاک - وہ بلاک جس میں ٹرانزیکشن شامل کیا گیا ہے +- ٹائم اسٹیمپ - وہ وقت جب ایک ویلیڈیٹر کے ذریعہ تجویز کردہ بلاک میں ایک ٹرانزیکشن شامل کیا گیا تھا +- منجانب - ٹرانزیکشن جمع کرانے والے اکاؤنٹ کا ایڈریس +- بنام - وصول کنندہ یا اسمارٹ کانٹریکٹ کا ایڈریس جس کے ساتھ ٹرانزیکشن تعامل کرتا ہے +- منتقل شدہ ٹوکنز - ٹرانزیکشن کے حصے کے طور پر منتقل کیے گئے ٹوکنز کی فہرست +- ویلیو - منتقل کی جانے والی کل ETH ویلیو +- ٹرانزیکشن فیس - ٹرانزیکشن پر کارروائی کرنے کے لیے ویلیڈیٹر کو ادا کی گئی رقم (گیس کی قیمت\*استعمال شدہ گیس سے حساب کی جاتی ہے) + +**ایڈوانسڈ ڈیٹا** + +- گیس کی حد - گیس کی اکائیوں کی زیادہ سے زیادہ تعداد جو یہ ٹرانزیکشن استعمال کر سکتی ہے +- استعمال شدہ گیس - ٹرانزیکشن کے ذریعہ استعمال شدہ گیس کی اکائیوں کی اصل رقم +- گیس کی قیمت - فی گیس یونٹ مقرر کردہ قیمت +- نونس - `from` ایڈریس کے لیے ٹرانزیکشن نمبر (یاد رکھیں کہ یہ 0 سے شروع ہوتا ہے لہذا `100` کا نونس دراصل اس اکاؤنٹ کے ذریعہ جمع کرایا گیا 101 واں ٹرانزیکشن ہوگا) +- ان پٹ ڈیٹا - ٹرانزیکشن کے لیے درکار کوئی بھی اضافی معلومات + +### اکاؤنٹس {#accounts} + +ایک اکاؤنٹ کے بارے میں بہت سا ڈیٹا ہے جس تک آپ رسائی حاصل کر سکتے ہیں۔ یہی وجہ ہے کہ اکثر متعدد اکاؤنٹس استعمال کرنے کی سفارش کی جاتی ہے تاکہ آپ کے اثاثوں اور قدر کو آسانی سے ٹریک نہ کیا جا سکے۔ ٹرانزیکشنز اور اکاؤنٹ کی سرگرمی کو مزید نجی بنانے کے لیے کچھ حل بھی تیار کیے جا رہے ہیں۔ لیکن یہاں وہ ڈیٹا ہے جو اکاؤنٹس کے لیے دستیاب ہے: + +**صارف کے اکاؤنٹس** + +- اکاؤنٹ ایڈریس - وہ پبلک ایڈریس جسے آپ فنڈز بھیجنے کے لیے استعمال کر سکتے ہیں +- ETH بیلنس - اس اکاؤنٹ سے وابستہ ETH کی رقم +- کل ETH ویلیو - ETH کی ویلیو +- ٹوکنز - اکاؤنٹ سے وابستہ ٹوکنز اور ان کی قدر +- ٹرانزیکشن کی سرگزشت - ان تمام ٹرانزیکشنز کی ایک فہرست جہاں یہ اکاؤنٹ یا تو بھیجنے والا تھا یا وصول کنندہ + +**اسمارٹ معاہدات** + +اسمارٹ کانٹریکٹ اکاؤنٹس میں وہ تمام ڈیٹا ہوتا ہے جو صارف کے اکاؤنٹ میں ہوتا ہے، لیکن کچھ بلاک ایکسپلوررز کچھ کوڈ کی معلومات بھی دکھاتے ہیں۔ مثالوں میں شامل ہیں: + +- کانٹریکٹ بنانے والا - وہ ایڈریس جس نے کانٹریکٹ کو مین نیٹ پر تعینات کیا +- تخلیقی ٹرانزیکشن - وہ ٹرانزیکشن جس میں مین نیٹ پر تعیناتی شامل تھی +- سورس کوڈ - اسمارٹ کانٹریکٹ کا Solidity یا Vyper کوڈ +- کانٹریکٹ ABI - کانٹریکٹ کا ایپلیکیشن بائنری انٹرفیس — وہ کالز جو کانٹریکٹ کرتا ہے اور موصول شدہ ڈیٹا +- کانٹریکٹ تخلیق کوڈ - اسمارٹ کانٹریکٹ کا کمپائلڈ بائٹ کوڈ — جب آپ Solidity یا Vyper وغیرہ میں لکھے گئے اسمارٹ کانٹریکٹ کو کمپائل کرتے ہیں تو بنایا جاتا ہے۔ +- کانٹریکٹ ایونٹس - اسمارٹ کانٹریکٹ میں کال کیے گئے طریقوں کی سرگزشت — بنیادی طور پر یہ دیکھنے کا ایک طریقہ کہ کانٹریکٹ کا استعمال کیسے کیا جا رہا ہے اور کتنی بار + +### ٹوکنز {#tokens} + +ٹوکنز ایک قسم کا کانٹریکٹ ہیں لہذا ان کے پاس اسمارٹ کانٹریکٹ جیسا ہی ڈیٹا ہوگا۔ لیکن چونکہ ان کی قدر ہوتی ہے اور ان کی تجارت کی جا سکتی ہے اس لیے ان کے پاس اضافی ڈیٹا پوائنٹس ہوتے ہیں: + +- قسم - چاہے وہ ERC-20، ERC-721 یا کوئی اور ٹوکن معیار ہوں +- قیمت - اگر وہ ERC-20 ہیں تو ان کی موجودہ مارکیٹ ویلیو ہوگی +- مارکیٹ کیپ - اگر وہ ERC-20 ہیں تو ان کا مارکیٹ کیپ ہوگا (قیمت\*کل سپلائی سے حساب کیا جاتا ہے) +- کل سپلائی - گردش میں موجود ٹوکنز کی تعداد +- ہولڈرز - ٹوکن رکھنے والے ایڈریسز کی تعداد +- منتقلی - ٹوکن کو اکاؤنٹس کے درمیان منتقل کیے جانے کی تعداد +- ٹرانزیکشن کی سرگزشت - ٹوکن سمیت تمام ٹرانزیکشنز کی سرگزشت +- کانٹریکٹ ایڈریس - ٹوکن کا ایڈریس جسے مین نیٹ پر تعینات کیا گیا تھا +- اعشاریے - ERC-20 ٹوکنز قابل تقسیم ہیں اور ان میں اعشاریہ کی جگہیں ہوتی ہیں + +### نیٹ ورک {#network} + +کچھ بلاک ڈیٹا Ethereum کی صحت کے بارے میں زیادہ جامع طور پر فکر مند ہے۔ + +- کل ٹرانزیکشنز - Ethereum کے بنائے جانے کے بعد سے ٹرانزیکشنز کی تعداد +- ٹرانزیکشنز فی سیکنڈ - ایک سیکنڈ میں قابل عمل ٹرانزیکشنز کی تعداد +- ETH کی قیمت - 1 ETH کی موجودہ قیمتیں +- کل ETH سپلائی - گردش میں ETH کی تعداد — یاد رکھیں کہ ہر بلاک کی تخلیق کے ساتھ بلاک انعامات کی شکل میں نیا ETH بنایا جاتا ہے +- مارکیٹ کیپ - قیمت\*سپلائی کا حساب + +## کنسینسس لیئر ڈیٹا {#consensus-layer-data} + +### ایپوک {#epoch} + +سیکورٹی وجوہات کی بنا پر، ہر ایپوک (ہر 6.4 منٹ) کے اختتام پر ویلیڈیٹرز کی بے ترتیب کمیٹیاں بنائی جاتی ہیں۔ ایپوک ڈیٹا میں شامل ہیں: + +- ایپوک نمبر +- حتمی حیثیت - آیا ایپوک کو حتمی شکل دی گئی ہے (ہاں/نہیں) +- وقت - وہ وقت جب ایپوک ختم ہوا +- تصدیقات - ایپوک میں تصدیقات کی تعداد (سلاٹس کے اندر بلاکس کے لیے ووٹ) +- ڈپازٹس - ایپوک میں شامل ETH ڈپازٹس کی تعداد (ویلیڈیٹرز کو ویلیڈیٹر بننے کے لیے ETH اسٹیک کرنا ضروری ہے) +- سلیشنگز - بلاکس یا تصدیق کنندگان کے پروپوزرز کو دی جانے والی سزاؤں کی تعداد +- ووٹنگ میں شرکت - بلاکس کی تصدیق کے لیے استعمال ہونے والی اسٹیک شدہ ETH کی رقم +- ویلیڈیٹرز - ایپوک کے لیے فعال ویلیڈیٹرز کی تعداد +- اوسط ویلیڈیٹر بیلنس - فعال ویلیڈیٹرز کا اوسط بیلنس +- سلاٹس - ایپوک میں شامل سلاٹس کی تعداد (سلاٹس میں ایک درست بلاک شامل ہے) + +### سلاٹ {#slot} + +سلاٹس بلاک کی تخلیق کے مواقع ہیں، ہر سلاٹ کے لیے دستیاب ڈیٹا میں شامل ہیں: + +- ایپوک - وہ ایپوک جس میں سلاٹ درست ہے +- سلاٹ نمبر +- اسٹیٹس - سلاٹ کا اسٹیٹس (تجویز کردہ/چھوٹ گیا) +- وقت - سلاٹ کا ٹائم اسٹیمپ +- پروپوزر - وہ ویلیڈیٹر جس نے سلاٹ کے لیے بلاک تجویز کیا +- بلاک روٹ - بیکن بلاک کا ہیش-ٹری-روٹ +- پیرنٹ روٹ - پہلے آنے والے بلاک کا ہیش +- اسٹیٹ روٹ - بیکن اسٹیٹ کا ہیش-ٹری-روٹ +- دستخط +- Randao ظاہر کرنا +- گریفیٹی - ایک بلاک پروپوزر اپنی بلاک تجویز میں 32 بائٹ طویل پیغام شامل کر سکتا ہے +- ایگزیکیوشن ڈیٹا + - بلاک ہیش + - ڈپازٹ کی گنتی + - ڈپازٹ روٹ +- تصدیقات - اس سلاٹ میں بلاک کے لیے تصدیقات کی تعداد +- ڈپازٹس - اس سلاٹ کے دوران ڈپازٹس کی تعداد +- رضاکارانہ اخراج - سلاٹ کے دوران چھوڑنے والے ویلیڈیٹرز کی تعداد +- سلیشنگز - بلاکس یا تصدیق کنندگان کے پروپوزرز کو دی جانے والی سزاؤں کی تعداد +- ووٹ - وہ ویلیڈیٹرز جنہوں نے اس سلاٹ میں بلاک کے لیے ووٹ دیا + +### بلاکس {#blocks-1} + +پروف آف اسٹیک وقت کو سلاٹس اور ایپوکس میں تقسیم کرتا ہے۔ تو اس کا مطلب ہے نیا ڈیٹا! + +- پروپوزر - وہ ویلیڈیٹر جسے نئے بلاک کی تجویز کے لیے الگورتھم کے طور پر منتخب کیا گیا تھا +- ایپوک - وہ ایپوک جس میں بلاک تجویز کیا گیا تھا +- سلاٹ - وہ سلاٹ جس میں بلاک تجویز کیا گیا تھا +- تصدیقات - سلاٹ میں شامل تصدیق کی تعداد — تصدیقات ووٹوں کی طرح ہیں جو اس بات کی نشاندہی کرتی ہیں کہ بلاک بیکن چین پر جانے کے لیے تیار ہے + +### ویلیڈیٹرز {#validators} + +ویلیڈیٹرز سلاٹس کے اندر بلاکس کی تجویز اور ان کی تصدیق کے ذمہ دار ہیں۔ + +- ویلیڈیٹر نمبر - منفرد نمبر جو ویلیڈیٹر کی نمائندگی کرتا ہے +- موجودہ بیلنس - ویلیڈیٹر کا بیلنس بشمول انعامات +- مؤثر بیلنس - ویلیڈیٹر کا بیلنس جو اسٹیکنگ کے لیے استعمال ہوتا ہے +- آمدنی - ویلیڈیٹر کے ذریعہ موصول ہونے والے انعامات یا جرمانے +- اسٹیٹس - آیا ویلیڈیٹر فی الحال آن لائن اور فعال ہے یا نہیں +- تصدیق کی تاثیر - ویلیڈیٹر کی تصدیقات کو چین میں شامل ہونے میں لگنے والا اوسط وقت +- فعالیت کے لیے اہلیت - تاریخ (اور ایپوک) جب ویلیڈیٹر تصدیق کے لیے دستیاب ہوا +- فعال ہونے کی تاریخ - تاریخ (اور ایپوک) جب ویلیڈیٹر فعال ہوا +- تجویز کردہ بلاکس - وہ بلاک جو ویلیڈیٹر نے تجویز کیا ہے +- تصدیقات - وہ تصدیقات جو ویلیڈیٹر نے فراہم کی ہیں +- ڈپازٹس - ویلیڈیٹر کے ذریعہ کیے گئے اسٹیکنگ ڈپازٹ کا منجانب ایڈریس، ٹرانزیکشن ہیش، بلاک نمبر، ٹائم اسٹیمپ، رقم اور اسٹیٹس + +### تصدیقات {#attestations} + +تصدیقات چین میں بلاکس کو شامل کرنے کے لیے "ہاں" ووٹ ہیں۔ ان کا ڈیٹا تصدیق کے ریکارڈ اور تصدیق کرنے والے ویلیڈیٹرز سے متعلق ہے + +- سلاٹ - وہ سلاٹ جس میں تصدیق ہوئی +- کمیٹی انڈیکس - دیے گئے سلاٹ پر کمیٹی کا انڈیکس +- ایگریگیشن بٹس - تصدیق میں حصہ لینے والے تمام ویلیڈیٹرز کی مجموعی تصدیق کی نمائندگی کرتا ہے +- ویلیڈیٹرز - وہ ویلیڈیٹرز جنہوں نے تصدیقات فراہم کیں +- بیکن بلاک روٹ - اس بلاک کی طرف اشارہ کرتا ہے جس کی ویلیڈیٹرز تصدیق کر رہے ہیں +- ماخذ - تازہ ترین جائز ایپوک کی طرف اشارہ کرتا ہے +- ہدف - تازہ ترین ایپوک کی حد کی طرف اشارہ کرتا ہے +- دستخط + +### نیٹ ورک {#network-1} + +کنسینسس لیئر کے اعلی سطحی ڈیٹا میں درج ذیل شامل ہیں: + +- موجودہ ایپوک +- موجودہ سلاٹ +- فعال ویلیڈیٹرز - فعال ویلیڈیٹرز کی تعداد +- زیر التوا ویلیڈیٹرز - فعال ہونے کے منتظر ویلیڈیٹرز کی تعداد +- اسٹیک شدہ ETH - نیٹ ورک میں اسٹیک شدہ ETH کی رقم +- اوسط بیلنس - ویلیڈیٹرز کا اوسط ETH بیلنس + +## بلاک ایکسپلوررز {#block-explorers} + +- [Etherscan](https://etherscan.io/) - ایک بلاک ایکسپلورر جسے آپ Ethereum مین نیٹ اور ٹیسٹ نیٹ کے لیے ڈیٹا حاصل کرنے کے لیے استعمال کر سکتے ہیں +- [3xpl](https://3xpl.com/ethereum) - ایک اشتہار سے پاک اوپن سورس Ethereum ایکسپلورر جو اپنے ڈیٹاسیٹس کو ڈاؤن لوڈ کرنے کی اجازت دیتا ہے +- [Beaconcha.in](https://beaconcha.in/) - Ethereum مین نیٹ اور ٹیسٹ نیٹ کے لیے ایک اوپن سورس بلاک ایکسپلورر +- [Blockchair](https://blockchair.com/ethereum) - سب سے نجی Ethereum ایکسپلورر۔ ڈیٹا کو ترتیب دینے اور فلٹر کرنے کے لیے بھی (mempool) +- [Etherchain](https://www.etherchain.org/) - Ethereum مین نیٹ کے لیے ایک بلاک ایکسپلورر +- [Ethplorer](https://ethplorer.io/) - Ethereum مین نیٹ اور کوون ٹیسٹ نیٹ کے لیے ٹوکنز پر توجہ مرکوز کرنے والا ایک بلاک ایکسپلورر + +## مزید پڑھیں {#further-reading} + +_کسی کمیونٹی وسیلے کے بارے میں جانتے ہیں جس نے آپ کی مدد کی ہو؟ اس صفحہ میں ترمیم کریں اور اسے شامل کریں!_ + +## متعلقہ موضوعات {#related-topics} + +- [ٹرانزیکشنز](/developers/docs/transactions/) +- [اکاؤنٹس](/developers/docs/accounts/) +- [نیٹ ورکس](/developers/docs/networks/) diff --git a/public/content/translations/ur/developers/docs/data-and-analytics/index.md b/public/content/translations/ur/developers/docs/data-and-analytics/index.md new file mode 100644 index 00000000000..cf7098ad84e --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-and-analytics/index.md @@ -0,0 +1,72 @@ +--- +title: "ڈیٹا اور تجزیات" +description: "اپنے dapps میں استعمال کے لیے آن چین تجزیات اور ڈیٹا کیسے حاصل کریں" +lang: ur-in +--- + +## تعارف {#Introduction} + +جیسے جیسے نیٹ ورک کا استعمال بڑھتا جا رہا ہے، آن چین ڈیٹا میں قیمتی معلومات کی مقدار میں اضافہ ہوتا جائے گا۔ جیسے جیسے ڈیٹا کا حجم تیزی سے بڑھتا ہے، اس معلومات کا حساب لگانا اور اسے جمع کرنا تاکہ اس پر رپورٹ کیا جا سکے یا کسی dapp کو چلایا جا سکے، ایک وقت طلب اور عمل طلب کام بن سکتا ہے۔ + +موجودہ ڈیٹا فراہم کنندگان سے فائدہ اٹھانے سے ڈیولپمنٹ میں تیزی آسکتی ہے، زیادہ درست نتائج پیدا ہوسکتے ہیں، اور جاری دیکھ بھال کی کوششوں کو کم کیا جاسکتا ہے۔ اس سے ایک ٹیم اس بنیادی فعالیت پر توجہ مرکوز کر سکے گی جو ان کا پروجیکٹ فراہم کرنے کی کوشش کر رہا ہے۔ + +## شرائط {#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/) ایک انڈیکسنگ پروٹوکول ہے جو سب گراف کے نام سے معروف اوپن APIs کے ذریعے بلاک چین ڈیٹا کو استفسار کرنے کا ایک آسان طریقہ فراہم کرتا ہے۔ + +دی گراف کے ساتھ، ڈیولپرز اس سے فائدہ اٹھا سکتے ہیں: + +- غیر مرکزی انڈیکسنگ: متعدد انڈیکسرز کے ذریعے بلاک چین ڈیٹا کو انڈیکس کرنے کے قابل بناتا ہے، اس طرح ناکامی کے کسی بھی ایک نقطہ کو ختم کرتا ہے۔ +- 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-analytics} + +[ڈیون اینالیٹکس](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} + +[SubQuery](https://subquery.network/) ایک سرکردہ ڈیٹا انڈیکسر ہے جو ڈیولپرز کو ان کے web3 پروجیکٹس کے لیے تیز، قابل اعتماد، غیر مرکزی، اور حسب ضرورت APIs فراہم کرتا ہے۔ SubQuery 165+ سے زیادہ ایکو سسٹمز (بشمول ایتھیریم) کے ڈیولپرز کو بھرپور انڈیکس شدہ ڈیٹا کے ساتھ بااختیار بناتا ہے تاکہ وہ اپنے صارفین کے لیے ایک بدیہی اور عمیق تجربات تخلیق کر سکیں۔ سب کوئری نیٹ ورک آپ کی نہ رکنے والی ایپس کو ایک لچکدار اور غیر مرکزی انفراسٹرکچر نیٹ ورک کے ساتھ طاقت دیتا ہے۔ ڈیٹا پروسیسنگ سرگرمیوں کے لیے کسٹم بیک اینڈ بنانے میں وقت صرف کیے بغیر، مستقبل کی web3 ایپلی کیشنز بنانے کے لیے SubQuery کے بلاک چین ڈیولپر ٹول کٹ کا استعمال کریں۔ + +شروع کرنے کے لیے، [ایتھیریم کوئیک اسٹارٹ گائیڈ](https://academy.subquery.network/quickstart/quickstart_chains/ethereum-gravatar.html) پر جائیں تاکہ [SubQuery کی مینیجڈ سروس](https://managedservice.subquery.network/) یا [SubQuery کے غیر مرکزی نیٹ ورک](https://app.subquery.network/dashboard) پر لائیو جانے سے پہلے ٹیسٹنگ کے لیے مقامی ڈوکر ماحول میں منٹوں میں ایتھیریم بلاک چین ڈیٹا کو انڈیکس کرنا شروع کریں۔ + +## EVM کوئری لینگویج {#evm-query-language} + +EVM کوئری لینگویج (EQL) ایک SQL جیسی زبان ہے جسے EVM (ایتھیریم ورچوئل مشین) چینز سے استفسار کرنے کے لیے ڈیزائن کیا گیا ہے۔ 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) +- [ڈیون کی بنیادی باتیں](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/ur/developers/docs/data-availability/blockchain-data-storage-strategies/index.md b/public/content/translations/ur/developers/docs/data-availability/blockchain-data-storage-strategies/index.md new file mode 100644 index 00000000000..1a1d6edb05c --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-availability/blockchain-data-storage-strategies/index.md @@ -0,0 +1,118 @@ +--- +title: "بلاک چین ڈیٹا اسٹوریج کی حکمت عملیاں" +description: "بلاک چین کا استعمال کرکے ڈیٹا کو اسٹور کرنے کے کئی طریقے ہیں۔ یہ مضمون مختلف حکمت عملیوں، ان کی لاگتوں اور ٹریڈ آفس، نیز اسے محفوظ طریقے سے استعمال کرنے کی ضروریات کا موازنہ کرے گا۔" +lang: ur-in +--- + +معلومات کو براہ راست بلاک چین پر، یا بلاک چین کے ذریعے محفوظ کردہ طریقے سے اسٹور کرنے کے متعدد طریقے ہیں: + +- EIP-4844 بلابز +- کال ڈیٹا +- L1 میکانزم کے ساتھ آف چین +- کنٹریکٹ "کوڈ" +- ایونٹس +- EVM اسٹوریج + +کون سا طریقہ استعمال کرنا ہے اس کا انتخاب کئی معیارات پر مبنی ہے: + +- معلومات کا ماخذ۔ کال ڈیٹا میں معلومات براہ راست خود بلاک چین سے نہیں آ سکتیں۔ +- معلومات کی منزل۔ کال ڈیٹا صرف اس ٹرانزیکشن میں دستیاب ہوتا ہے جس میں یہ شامل ہو۔ ایونٹس آن چین پر بالکل بھی قابل رسائی نہیں ہیں۔ +- کتنی پریشانی قابل قبول ہے؟ وہ کمپیوٹرز جو ایک مکمل نوڈ چلاتے ہیں، براؤزر میں چلنے والی ایپلیکیشن میں ایک لائٹ کلائنٹ سے زیادہ پروسیسنگ انجام دے سکتے ہیں۔ +- کیا ہر نوڈ سے معلومات تک آسان رسائی کو آسان بنانا ضروری ہے؟ +- سیکورٹی کی ضروریات۔ + +## سیکورٹی کی ضروریات {#security-requirements} + +عام طور پر، معلومات کی سیکورٹی تین خصوصیات پر مشتمل ہوتی ہے: + +- _رازداری_، غیر مجاز اداروں کو معلومات پڑھنے کی اجازت نہیں ہے۔ یہ بہت سے معاملات میں اہم ہے، لیکن یہاں نہیں۔ _بلاک چین پر کوئی راز نہیں ہوتے_۔ بلاک چینز کام کرتے ہیں کیونکہ کوئی بھی اسٹیٹ کی منتقلی کی تصدیق کر سکتا ہے، لہذا ان کا استعمال براہ راست رازوں کو اسٹور کرنے کے لیے کرنا ناممکن ہے۔ بلاک چین پر خفیہ معلومات کو اسٹور کرنے کے طریقے ہیں، لیکن وہ سب کم از کم ایک 'کی' (key) کو اسٹور کرنے کے لیے کسی آف چین جزو پر انحصار کرتے ہیں۔ + +- _سالمیت_، معلومات درست ہے، اسے غیر مجاز اداروں کے ذریعے، یا غیر مجاز طریقوں سے تبدیل نہیں کیا جا سکتا (مثال کے طور پر، `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 بلابز {#eip-4844-blobs} + +[Dencun ہارڈفورک](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/beacon-chain.md) سے شروع ہو کر، ایتھیریم بلاک چین میں [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) شامل ہے، جو ایتھیریم میں محدود عمر والے ڈیٹا بلابز کو شامل کرتا ہے (ابتدائی طور پر تقریباً [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#challenge-period) کے دوران کسی کے لیے بھی دستیاب ہونا چاہیے تاکہ [ویلیڈیٹرز](https://docs.optimism.io/connect/resources/glossary#validator) کو غلطی ٹھیک کرنے کے قابل بنایا جا سکے اگر رول اپ کا [سیکوینسر](https://docs.optimism.io/connect/resources/glossary#sequencer) غلط اسٹیٹ روٹ پوسٹ کرتا ہے۔ + +تاہم، ایک بار جب چیلنج پیریڈ گزر جاتا ہے اور اسٹیٹ روٹ کو حتمی شکل دے دی جاتی ہے، تو ان ٹرانزیکشنز کو جاننے کا باقی مقصد چین کی موجودہ اسٹیٹ کو نقل کرنا ہوتا ہے۔ یہ اسٹیٹ چین نوڈز سے بھی دستیاب ہے، جس میں بہت کم پروسیسنگ کی ضرورت ہوتی ہے۔ لہذا ٹرانزیکشن کی معلومات کو اب بھی کچھ جگہوں پر محفوظ کیا جانا چاہیے، جیسے کہ [بلاک ایکسپلوررز](/developers/docs/data-and-analytics/block-explorers)، لیکن ایتھیریم کی فراہم کردہ سنسر شپ مزاحمت کی سطح کے لیے ادائیگی کرنے کی کوئی ضرورت نہیں ہے۔ + +[زیرو نالج رول اپس](/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} + +کال ڈیٹا ان بائٹس سے مراد ہے جو ٹرانزیکشن کے حصے کے طور پر بھیجی جاتی ہیں۔ اسے بلاک چین کے مستقل ریکارڈ کے حصے کے طور پر اس بلاک میں اسٹور کیا جاتا ہے جس میں وہ ٹرانزیکشن شامل ہوتا ہے۔ + +یہ بلاک چین میں مستقل طور پر ڈیٹا ڈالنے کا سب سے سستا طریقہ ہے۔ فی بائٹ لاگت یا تو 4 ایگزیکیوشن گیس ہے (اگر بائٹ صفر ہے) یا 16 گیس (کوئی دوسری ویلیو)۔ اگر ڈیٹا کمپریس کیا جاتا ہے، جو کہ ایک معیاری عمل ہے، تو ہر بائٹ ویلیو کے مساوی طور پر ممکن ہونے کا امکان ہے، لہذا اوسط لاگت تقریباً 15.95 گیس فی بائٹ ہے۔ + +لکھنے کے وقت، قیمتیں 12 gwei/gas اور 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 گیس کے علاوہ 3 گیس فی 32 بائٹ ورڈ ہے۔ کال ڈیٹا کے مقابلے میں، جس کی لاگت 15.95 فی بائٹ ہے، یہ تقریباً 200 بائٹس سے شروع ہو کر سستا ہے۔ [میموری کی توسیع کی لاگت کے فارمولے](https://www.evm.codes/about#memoryexpansion) کی بنیاد پر، جب تک آپ کو 4MB سے زیادہ میموری کی ضرورت نہیں ہے، میموری کی توسیع کی لاگت کال ڈیٹا شامل کرنے کی لاگت سے کم ہے۔ + +یقیناً، یہ صرف ڈیٹا کو _پڑھنے_ کی لاگت ہے۔ کنٹریکٹ بنانے کی لاگت تقریباً 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/gas اور 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/gas اور 2300 $/ETH پر، یہ تقریباً 61 سینٹ فی رائٹ آپریشن، یا 19.5$ فی کلو بائٹ ہے۔ + +یہ ایتھیریم میں اسٹوریج کی سب سے مہنگی شکل ہے۔ + +## خلاصہ {#summary} + +یہ جدول مختلف آپشنز، ان کے فوائد اور نقصانات کا خلاصہ کرتا ہے۔ + +| اسٹوریج کی قسم | ڈیٹا کا ماخذ | دستیابی کی ضمانت | آن چین دستیابی | اضافی حدود | +| ------------------------- | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------------------------- | +| EIP-4844 بلابز | آف چین | [~18 دن](https://github.com/ethereum/consensus-specs/blob/dev/specs/deneb/p2p-interface.md#configuration) کے لیے ایتھیریم کی ضمانت | صرف ہیش دستیاب ہے | | +| کال ڈیٹا | آف چین | ایتھیریم کی ہمیشہ کے لیے ضمانت (بلاک چین کا حصہ) | صرف اس صورت میں دستیاب ہے جب کسی کنٹریکٹ میں لکھا جائے، اور اس ٹرانزیکشن پر | | +| L1 میکانزم کے ساتھ آف چین | آف چین | چیلنج پیریڈ کے دوران "ایک ایماندار تصدیق کنندہ" کی ضمانت | صرف ہیش | چیلنج میکانزم کے ذریعے ضمانت دی گئی، صرف چیلنج پیریڈ کے دوران | +| کنٹریکٹ کوڈ | آن چین یا آف چین | ایتھیریم کی ہمیشہ کے لیے ضمانت (بلاک چین کا حصہ) | جی ہاں | ایک "بے ترتیب" ایڈریس پر لکھا گیا، `0xEF` سے شروع نہیں ہو سکتا | +| ایونٹس | آن چین | ایتھیریم کی ہمیشہ کے لیے ضمانت (بلاک چین کا حصہ) | نہیں | | +| اسٹوریج | آن چین | ایتھیریم کی ہمیشہ کے لیے ضمانت (بلاک چین کا حصہ اور موجودہ اسٹیٹ جب تک کہ اوور رائٹ نہ ہو جائے) | جی ہاں | | diff --git a/public/content/translations/ur/developers/docs/data-availability/index.md b/public/content/translations/ur/developers/docs/data-availability/index.md new file mode 100644 index 00000000000..43db076952d --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-availability/index.md @@ -0,0 +1,84 @@ +--- +title: "ڈیٹا کی دستیابی" +description: "ایتھیریم میں ڈیٹا کی دستیابی سے متعلق مسائل اور حل کا ایک جائزہ" +lang: ur-in +--- + +"بھروسہ نہ کریں، تصدیق کریں" ایتھیریم میں ایک عام کہاوت ہے۔ خیال یہ ہے کہ آپ کا نوڈ ان بلاکس میں موجود تمام ٹرانزیکشنز کو انجام دے کر آزادانہ طور پر اس بات کی تصدیق کر سکتا ہے کہ اسے موصول ہونے والی معلومات درست ہیں، یہ یقینی بنانے کے لیے کہ تجویز کردہ تبدیلیاں بالکل ان سے ملتی ہیں جو نوڈ کے ذریعے آزادانہ طور پر شمار کی گئی ہیں۔ اس کا مطلب ہے کہ نوڈس کو اس بات پر بھروسہ کرنے کی ضرورت نہیں ہے کہ بلاک کے بھیجنے والے ایماندار ہیں۔ اگر ڈیٹا غائب ہو تو یہ ممکن نہیں ہے۔ + +**ڈیٹا کی دستیابی** سے مراد وہ اعتماد ہے جو ایک صارف اس بات پر کر سکتا ہے کہ کسی بلاک کی تصدیق کے لیے درکار ڈیٹا واقعی تمام نیٹ ورک شرکاء کے لیے دستیاب ہے۔ ایتھیریم لیئر 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) نیٹ ورک کے لیے یہ چیک کرنے کا ایک طریقہ ہے کہ ڈیٹا کسی انفرادی نوڈ پر بہت زیادہ دباؤ ڈالے بغیر دستیاب ہے۔ ہر نوڈ (بشمول نان-اسٹیکنگ نوڈس) کل ڈیٹا کا کچھ چھوٹا، تصادفی طور پر منتخب کردہ سب سیٹ ڈاؤن لوڈ کرتا ہے۔ نمونوں کو کامیابی سے ڈاؤن لوڈ کرنا اعلیٰ اعتماد کے ساتھ اس بات کی تصدیق کرتا ہے کہ تمام ڈیٹا دستیاب ہے۔ یہ ڈیٹا ایریزر کوڈنگ پر انحصار کرتا ہے، جو ایک دیئے گئے ڈیٹا سیٹ کو فالتو معلومات کے ساتھ پھیلاتا ہے (ایسا کرنے کا طریقہ یہ ہے کہ ڈیٹا پر ایک فنکشن جسے _پولینومیل_ کہا جاتا ہے فٹ کیا جائے اور اس پولینومیل کو اضافی پوائنٹس پر جانچا جائے)۔ یہ ضرورت پڑنے پر فالتو ڈیٹا سے اصل ڈیٹا کو بازیافت کرنے کی اجازت دیتا ہے۔ اس ڈیٹا کی تخلیق کا ایک نتیجہ یہ ہے کہ اگر اصل ڈیٹا کا _کوئی بھی_ حصہ دستیاب نہیں ہے، تو توسیع شدہ ڈیٹا کا _آدھا_ حصہ غائب ہو جائے گا! ہر نوڈ کے ذریعے ڈاؤن لوڈ کیے گئے ڈیٹا نمونوں کی مقدار کو اس طرح ٹیون کیا جا سکتا ہے کہ یہ _انتہائی_ ممکن ہے کہ ہر کلائنٹ کے ذریعے نمونہ لیے گئے ڈیٹا کے ٹکڑوں میں سے کم از کم ایک غائب ہو جائے گا _اگر_ نصف سے کم ڈیٹا واقعی دستیاب ہو۔ + +[Full Danksharding](/roadmap/danksharding/#what-is-danksharding) کے نفاذ کے بعد یہ یقینی بنانے کے لیے DAS کا استعمال کیا جائے گا کہ رول اپ آپریٹرز اپنا ٹرانزیکشن ڈیٹا دستیاب کرائیں۔ ایتھیریم نوڈس اوپر بیان کردہ ریڈنڈینسی اسکیم کا استعمال کرتے ہوئے بلابز میں فراہم کردہ ٹرانزیکشن ڈیٹا کا تصادفی طور پر نمونہ لیں گے تاکہ یہ یقینی بنایا جا سکے کہ تمام ڈیٹا موجود ہے۔ اسی تکنیک کو یہ یقینی بنانے کے لیے بھی استعمال کیا جا سکتا ہے کہ بلاک پروڈیوسرز اپنا تمام ڈیٹا محفوظ لائٹ کلائنٹس کو دستیاب کرا رہے ہیں۔ اسی طرح، [proposer-builder separation](/roadmap/pbs) کے تحت، صرف بلاک بلڈر کو ایک پورے بلاک کو پراسیس کرنے کی ضرورت ہوگی - دوسرے ویلیڈیٹرز ڈیٹا کی دستیابی کی سیمپلنگ کا استعمال کرتے ہوئے تصدیق کریں گے۔ + +### ڈیٹا کی دستیابی کی کمیٹیاں {#data-availability-committees} + +ڈیٹا کی دستیابی کی کمیٹیاں (DACs) قابل اعتماد پارٹیاں ہیں جو ڈیٹا کی دستیابی فراہم کرتی ہیں، یا اس کی تصدیق کرتی ہیں۔ DACs کو DAS کے بجائے، [یا اس کے ساتھ ملا کر](https://hackmd.io/@vbuterin/sharding_proposal#Why-not-use-just-committees-and-not-DAS) استعمال کیا جا سکتا ہے۔ کمیٹیوں کے ساتھ آنے والی سیکورٹی کی ضمانتیں مخصوص سیٹ اپ پر منحصر ہوتی ہیں۔ مثال کے طور پر، ایتھیریم لائٹ نوڈس کے لیے ڈیٹا کی دستیابی کی تصدیق کے لیے ویلیڈیٹرز کے تصادفی طور پر نمونہ لیے گئے سب سیٹس کا استعمال کرتا ہے۔ + +کچھ ویلیڈیمز کے ذریعے DACs کا بھی استعمال کیا جاتا ہے۔ DAC نوڈس کا ایک قابل اعتماد سیٹ ہے جو ڈیٹا کی کاپیاں آف لائن اسٹور کرتا ہے۔ تنازعہ کی صورت میں DAC کو ڈیٹا دستیاب کرانے کی ضرورت ہوتی ہے۔ DAC کے اراکین یہ ثابت کرنے کے لیے آن چین تصدیقات بھی شائع کرتے ہیں کہ مذکورہ ڈیٹا واقعی دستیاب ہے۔ کچھ ویلیڈیمز DACs کو پروف-آف-اسٹیک (PoS) ویلیڈیٹر سسٹم سے بدل دیتے ہیں۔ یہاں، کوئی بھی ویلیڈیٹر بن سکتا ہے اور ڈیٹا کو آف چین اسٹور کر سکتا ہے۔ تاہم، انہیں ایک "بانڈ" فراہم کرنا ہوگا، جو ایک اسمارٹ کنٹریکٹ میں جمع کیا جاتا ہے۔ بدنیتی پر مبنی رویے کی صورت میں، جیسے کہ ویلیڈیٹر کا ڈیٹا روکنا، بانڈ کو سلیش کیا جا سکتا ہے۔ پروف-آف-اسٹیک ڈیٹا کی دستیابی کی کمیٹیاں باقاعدہ DACs کے مقابلے میں کافی زیادہ محفوظ ہیں کیونکہ وہ براہ راست ایماندارانہ رویے کی ترغیب دیتی ہیں۔ + +## ڈیٹا کی دستیابی اور لائٹ نوڈس {#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} + +ڈیٹا کی دستیابی ڈیٹا کی بازیافت سے مختلف ہے۔ ڈیٹا کی دستیابی اس بات کی یقین دہانی ہے کہ مکمل نوڈس کسی مخصوص بلاک سے وابستہ ٹرانزیکشنز کے مکمل سیٹ تک رسائی حاصل کرنے اور اس کی تصدیق کرنے میں کامیاب رہے ہیں۔ اس کا لازمی مطلب یہ نہیں ہے کہ ڈیٹا ہمیشہ کے لیے قابل رسائی ہے۔ + +ڈیٹا کی بازیافت نوڈس کی بلاک چین سے _تاریخی معلومات_ بازیافت کرنے کی صلاحیت ہے۔ یہ تاریخی ڈیٹا نئے بلاکس کی تصدیق کے لیے ضروری نہیں ہے، یہ صرف جینیسس بلاک سے مکمل نوڈس کو سنک کرنے یا مخصوص تاریخی درخواستوں کو پورا کرنے کے لیے درکار ہے۔ + +بنیادی ایتھیریم پروٹوکول بنیادی طور پر ڈیٹا کی دستیابی سے متعلق ہے، ڈیٹا کی بازیافت سے نہیں۔ ڈیٹا کی بازیافت تیسرے فریقوں کے ذریعے چلائے جانے والے آرکائیو نوڈس کی ایک چھوٹی آبادی کے ذریعے فراہم کی جا سکتی ہے، یا اسے [Portal Network](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: Calldata کی لاگت میں اضافہ](https://web.archive.org/web/20250515194659/https://research.2077.xyz/eip-7623-increase-calldata-cost) diff --git a/public/content/translations/ur/developers/docs/data-structures-and-encoding/index.md b/public/content/translations/ur/developers/docs/data-structures-and-encoding/index.md new file mode 100644 index 00000000000..5aa2be3dba5 --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-structures-and-encoding/index.md @@ -0,0 +1,32 @@ +--- +title: "ڈیٹا کی ساختیں اور انکوڈنگ" +description: "بنیادی Ethereum ڈیٹا کی ساختوں کا ایک جائزہ۔" +lang: ur-in +sidebarDepth: 2 +--- + +Ethereum بڑی مقدار میں ڈیٹا بناتا، ذخیرہ کرتا اور منتقل کرتا ہے۔ اس ڈیٹا کو معیاری اور میموری کے موافق طریقوں سے فارمیٹ کیا جانا چاہیے تاکہ کسی کو بھی نسبتاً معمولی کنزیومر گریڈ ہارڈویئر پر [ایک نوڈ چلانے](/run-a-node/) کی اجازت دی جا سکے۔ اس کو حاصل کرنے کے لیے، Ethereum اسٹیک پر کئی مخصوص ڈیٹا کی ساختیں استعمال کی جاتی ہیں۔ + +## شرائط {#prerequisites} + +آپ کو Ethereum کی بنیادی باتوں اور [کلائنٹ سافٹ ویئر](/developers/docs/nodes-and-clients/) کو سمجھنا چاہیے۔ نیٹ ورکنگ لیئر اور [Ethereum وائٹ پیپر](/whitepaper/) سے واقفیت کی سفارش کی جاتی ہے۔ + +## ڈیٹا کی ساختیں {#data-structures} + +### Patricia merkle tries {#patricia-merkle-tries} + +Patricia Merkle Tries ایسی ساختیں ہیں جو کلیدی-ویلیو کے جوڑوں کو ایک ڈیٹرمنسٹک اور کرپٹوگرافک طور پر مستند trie میں انکوڈ کرتی ہیں۔ یہ Ethereum کی ایگزیکیوشن لیئر میں بڑے پیمانے پر استعمال ہوتے ہیں۔ + +[Patricia Merkle Tries کے بارے میں مزید](/developers/docs/data-structures-and-encoding/patricia-merkle-trie) + +### Recursive Length Prefix {#recursive-length-prefix} + +Recursive Length Prefix (RLP) ایک سیریلائزیشن طریقہ ہے جو Ethereum کی ایگزیکیوشن لیئر میں بڑے پیمانے پر استعمال ہوتا ہے۔ + +[RLP کے بارے میں مزید](/developers/docs/data-structures-and-encoding/rlp) + +### Simple Serialize {#simple-serialize} + +Simple Serialize (SSZ) Ethereum کی کنسینسس لیئر پر ایک غالب سیریلائزیشن فارمیٹ ہے کیونکہ یہ merklelization کے ساتھ مطابقت رکھتا ہے۔ + +[SSZ کے بارے میں مزید](/developers/docs/data-structures-and-encoding/ssz) diff --git a/public/content/translations/ur/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md b/public/content/translations/ur/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md new file mode 100644 index 00000000000..79875007f1e --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-structures-and-encoding/patricia-merkle-trie/index.md @@ -0,0 +1,266 @@ +--- +title: "مرکل پیٹریشیا ٹرائی" +description: "مرکل پیٹریشیا ٹرائی کا تعارف۔" +lang: ur-in +sidebarDepth: 2 +--- + +ایتھیریم کی اسٹیٹ (تمام اکاؤنٹس، بیلنس، اور اسمارٹ کنٹریکٹس کا مجموعہ)، کو ڈیٹا اسٹرکچر کے ایک خاص ورژن میں انکوڈ کیا جاتا ہے جسے عام طور پر کمپیوٹر سائنس میں مرکل ٹری کہا جاتا ہے۔ یہ اسٹرکچر کرپٹوگرافی میں بہت سی ایپلی کیشنز کے لیے مفید ہے کیونکہ یہ ٹری میں الجھے ہوئے ڈیٹا کے تمام انفرادی ٹکڑوں کے درمیان ایک قابلِ تصدیق تعلق پیدا کرتا ہے، جس کے نتیجے میں ایک واحد **روٹ** ویلیو حاصل ہوتی ہے جسے ڈیٹا کے بارے میں چیزوں کو ثابت کرنے کے لیے استعمال کیا جا سکتا ہے۔ + +ایتھیریم کا ڈیٹا اسٹرکچر ایک 'موڈیفائیڈ مرکل-پیٹریشیا ٹرائی' ہے، جسے یہ نام اس لیے دیا گیا ہے کیونکہ یہ PATRICIA (پریکٹیکل الگورتھم ٹو ریٹریو انفارمیشن کوڈڈ ان ایلفانیومرک) کی کچھ خصوصیات مستعار لیتا ہے، اور کیونکہ اسے ایتھیریم اسٹیٹ پر مشتمل آئٹمز کی موثر ڈیٹا ری**ٹری**ول کے لیے ڈیزائن کیا گیا ہے۔ + +ایک مرکل-پیٹریشیا ٹرائی ڈیٹرمنسٹک اور کرپٹوگرافک طور پر قابلِ تصدیق ہے: اسٹیٹ روٹ بنانے کا واحد طریقہ اسے اسٹیٹ کے ہر انفرادی ٹکڑے سے کمپیوٹ کرنا ہے، اور دو اسٹیٹس جو ایک جیسی ہیں، ان کو روٹ ہیش اور ان ہیشز کا موازنہ کر کے آسانی سے ثابت کیا جا سکتا ہے جنہوں نے اسے بنایا (_ایک مرکل پروف_)۔ اس کے برعکس، ایک ہی روٹ ہیش کے ساتھ دو مختلف اسٹیٹس بنانے کا کوئی طریقہ نہیں ہے، اور مختلف ویلیوز کے ساتھ اسٹیٹ میں ترمیم کرنے کی کوئی بھی کوشش ایک مختلف اسٹیٹ روٹ ہیش کا باعث بنے گی۔ نظریاتی طور پر، یہ اسٹرکچر انسرٹس، لک اپس اور ڈیلیٹس کے لیے `O(log(n))` کی کارکردگی کا 'ہولی گریل' فراہم کرتا ہے۔ + +مستقبل قریب میں، ایتھیریم ایک [ورکل ٹری](/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` دے گا)، اور پھر اس راستے پر چلتے ہوئے ٹرائی میں نیچے جائیں گے جب تک کہ آپ کو ویلیو نہ مل جائے۔ یعنی، آپ ٹرائی کے روٹ نوڈ کو تلاش کرنے کے لیے ایک فلیٹ کی/ویلیو DB میں روٹ ہیش کو دیکھ کر شروع کرتے ہیں۔ اسے دوسرے نوڈس کی طرف اشارہ کرنے والی کلیدوں کی ایک صف کے طور پر ظاہر کیا جاتا ہے۔ آپ انڈیکس `6` پر موجود ویلیو کو ایک کلید کے طور پر استعمال کریں گے اور اسے فلیٹ کی/ویلیو DB میں دیکھیں گے تاکہ ایک لیول نیچے نوڈ حاصل کیا جا سکے۔ پھر اگلی ویلیو دیکھنے کے لیے انڈیکس `4` چنیں، پھر انڈیکس `6`، اور اسی طرح، جب تک کہ آپ اس راستے پر نہ چلیں: `root -> 6 -> 4 -> 6 -> 15 -> 6 -> 7`، آپ نوڈ کی ویلیو دیکھیں گے اور نتیجہ واپس کر دیں گے۔ + +'ٹرائی' اور بنیادی فلیٹ کی/ویلیو 'DB' میں کسی چیز کو تلاش کرنے میں فرق ہے۔ یہ دونوں کی/ویلیو انتظامات کی وضاحت کرتے ہیں، لیکن بنیادی DB ایک کلید کا روایتی 1 قدمی لک اپ کر سکتا ہے۔ ٹرائی میں ایک کلید کو تلاش کرنے کے لیے اوپر بیان کردہ حتمی ویلیو تک پہنچنے کے لیے متعدد بنیادی DB لک اپس کی ضرورت ہوتی ہے۔ آئیے ابہام کو ختم کرنے کے لیے بعد والے کو `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) +``` + +ایک "مرکل" ریڈکس ٹری ڈیٹرمنسٹک طور پر تیار کردہ کرپٹوگرافک ہیش ڈائجسٹ کا استعمال کرتے ہوئے نوڈس کو جوڑ کر بنایا جاتا ہے۔ یہ مواد-ایڈریسنگ (کی/ویلیو DB `key == keccak256(rlp(value))` میں) ذخیرہ شدہ ڈیٹا کی کرپٹوگرافک سالمیت کی گارنٹی فراہم کرتا ہے۔ اگر کسی دیے گئے ٹرائی کا روٹ ہیش عوامی طور پر معلوم ہے، تو کوئی بھی شخص جس کے پاس بنیادی لیف ڈیٹا تک رسائی ہو، وہ اس بات کا ثبوت بنا سکتا ہے کہ ٹرائی میں ایک مخصوص راستے پر ایک دی گئی ویلیو شامل ہے، جس کے لیے وہ ہر نوڈ کے ہیشز فراہم کرے گا جو ایک مخصوص ویلیو کو ٹری روٹ سے جوڑتا ہے۔ + +ایک حملہ آور کے لیے `(path, value)` جوڑے کا ثبوت فراہم کرنا ناممکن ہے جو موجود نہیں ہے کیونکہ روٹ ہیش بالآخر اس کے نیچے کے تمام ہیشز پر مبنی ہے۔ کوئی بھی بنیادی ترمیم روٹ ہیش کو بدل دے گی۔ آپ ہیش کو ڈیٹا کے بارے میں ساختی معلومات کی ایک کمپریسڈ نمائندگی کے طور پر سوچ سکتے ہیں، جو ہیشنگ فنکشن کے پری-امیج تحفظ کے ذریعے محفوظ ہے۔ + +ہم ریڈکس ٹری کی ایک اٹامک اکائی (مثلاً، ایک واحد ہیکس کریکٹر، یا 4 بٹ بائنری نمبر) کو "نبل" کہیں گے۔ جیسا کہ اوپر بیان کیا گیا ہے، ایک وقت میں ایک نبل کے راستے پر چلتے ہوئے، نوڈس زیادہ سے زیادہ 16 بچوں کا حوالہ دے سکتے ہیں لیکن ایک `value` عنصر شامل کرتے ہیں۔ لہذا، ہم انہیں 17 کی لمبائی والی ایک صف کے طور پر ظاہر کرتے ہیں۔ ہم ان 17-عناصر والی صفوں کو "برانچ نوڈس" کہتے ہیں۔ + +## مرکل پیٹریشیا ٹرائی {#merkle-patricia-trees} + +ریڈکس ٹرائیز کی ایک بڑی حد ہے: وہ غیر موثر ہیں۔ اگر آپ ایک `(path, value)` بائنڈنگ کو ذخیرہ کرنا چاہتے ہیں جہاں پاتھ، جیسا کہ ایتھیریم میں ہے، 64 حروف لمبا ہے (`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` اگلے DB لک اپ کے لیے ہے۔ + +`leaf` نوڈ کے لیے، جسے `encodedPath` کے پہلے نبل میں ایک فلیگ کے ذریعے نشان زد کیا جا سکتا ہے، پاتھ تمام پچھلے نوڈ کے پاتھ کے ٹکڑوں کو انکوڈ کرتا ہے اور ہم براہ راست `value` کو دیکھ سکتے ہیں۔ + +تاہم، یہ مذکورہ بالا آپٹمائزیشن ابہام پیدا کرتی ہے۔ + +نبلز میں راستوں کو عبور کرتے وقت، ہمارے پاس عبور کرنے کے لیے نبلز کی ایک طاق تعداد ہو سکتی ہے، لیکن چونکہ تمام ڈیٹا `bytes` فارمیٹ میں ذخیرہ ہوتا ہے۔ مثال کے طور پر، نبل `1`، اور نبلز `01` کے درمیان فرق کرنا ممکن نہیں ہے (دونوں کو `<01>` کے طور پر ذخیرہ کیا جانا چاہیے)۔ طاق لمبائی کی وضاحت کرنے کے لیے، جزوی راستے کو ایک فلیگ کے ساتھ سابقہ لگایا جاتا ہے۔ + +### تفصیلات: اختیاری ٹرمینیٹر کے ساتھ ہیکس ترتیب کی کمپیکٹ انکوڈنگ {#specification} + +جیسا کہ اوپر بیان کیا گیا ہے، _طاق بمقابلہ جفت بقیہ جزوی پاتھ کی لمبائی_ اور _لیف بمقابلہ ایکسٹینشن نوڈ_ دونوں کی فلیگنگ کسی بھی 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 + # 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' +``` + +اب، ہم بنیادی DB میں درج ذیل کی/ویلیو جوڑوں کے ساتھ ایسی ٹرائی بناتے ہیں: + +``` + rootHash: [ <16>, hashA ] + hashA: [ <>, <>, <>, <>, hashB, <>, <>, <>, [ <20 6f 72 73 65>, 'stallion' ], <>, <>, <>, <>, <>, <>, <>, <> ] + hashB: [ <00 6f>, hashC ] + hashC: [ <>, <>, <>, <>, <>, <>, hashD, <>, <>, <>, <>, <>, <>, <>, <>, <>, 'verb' ] + hashD: [ <17>, [ <>, <>, <>, <>, <>, <>, [ <35>, 'coins' ], <>, <>, <>, <>, <>, <>, <>, <>, <>, 'puppy' ] ] +``` + +جب ایک نوڈ کا حوالہ دوسرے نوڈ کے اندر دیا جاتا ہے، تو جو چیز شامل کی جاتی ہے وہ `keccak256(rlp.encode(node))` ہے، اگر `len(rlp.encode(node)) >= 32` ورنہ `node` جہاں `rlp.encode` [RLP](/developers/docs/data-structures-and-encoding/rlp) انکوڈنگ فنکشن ہے۔ + +نوٹ کریں کہ ٹرائی کو اپ ڈیٹ کرتے وقت، کسی کو کی/ویلیو جوڑا `(keccak256(x), x)` کو ایک مستقل لک اپ ٹیبل میں ذخیرہ کرنے کی ضرورت ہے _اگر_ نئے بنائے گئے نوڈ کی لمبائی >= 32 ہے۔ تاہم، اگر نوڈ اس سے چھوٹا ہے، تو کسی کو کچھ بھی ذخیرہ کرنے کی ضرورت نہیں ہے، کیونکہ فنکشن f(x) = x قابلِ واپسی ہے۔ + +## ایتھیریم میں ٹرائیز {#tries-in-ethereum} + +ایتھیریم کی ایگزیکیوشن لیئر میں تمام مرکل ٹرائیز ایک مرکل پیٹریشیا ٹرائی کا استعمال کرتی ہیں۔ + +ایک بلاک ہیڈر سے ان 3 ٹرائیز کے 3 روٹس ہوتے ہیں۔ + +1. stateRoot +2. transactionsRoot +3. receiptsRoot + +### اسٹیٹ ٹرائی {#state-trie} + +ایک عالمی اسٹیٹ ٹرائی ہے، اور جب بھی کوئی کلائنٹ کسی بلاک پر کارروائی کرتا ہے تو اسے اپ ڈیٹ کیا جاتا ہے۔ اس میں، ایک `path` ہمیشہ ہوتا ہے: `keccak256(ethereumAddress)` اور ایک `value` ہمیشہ ہوتی ہے: `rlp(ethereumAccount)`۔ مزید خاص طور پر ایک ایتھیریم `account` ایک 4 آئٹم کی صف ہے `[nonce,balance,storageRoot,codeHash]`۔ اس مقام پر، یہ بات قابل غور ہے کہ یہ `storageRoot` ایک اور پیٹریشیا ٹرائی کا روٹ ہے: + +### اسٹوریج ٹرائی {#storage-trie} + +اسٹوریج ٹرائی وہ جگہ ہے جہاں _تمام_ کنٹریکٹ ڈیٹا رہتا ہے۔ ہر اکاؤنٹ کے لیے ایک الگ اسٹوریج ٹرائی ہوتی ہے۔ کسی دیے گئے ایڈریس پر مخصوص اسٹوریج پوزیشنز پر ویلیوز کو بازیافت کرنے کے لیے اسٹوریج ایڈریس، اسٹوریج میں ذخیرہ شدہ ڈیٹا کی انٹیجر پوزیشن، اور بلاک آئی ڈی کی ضرورت ہوتی ہے۔ اس کے بعد انہیں JSON-RPC API میں بیان کردہ `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"} + +``` + +اسٹوریج میں دیگر عناصر کو بازیافت کرنا قدرے زیادہ پیچیدہ ہے کیونکہ اسٹوریج ٹرائی میں پوزیشن کا پہلے حساب لگانا ضروری ہے۔ پوزیشن کا حساب ایڈریس اور اسٹوریج پوزیشن کے `keccak256` ہیش کے طور پر کیا جاتا ہے، دونوں کو 32 بائٹس کی لمبائی تک صفر کے ساتھ بائیں طرف پیڈ کیا جاتا ہے۔ مثال کے طور پر، ایڈریس `0x391694e7e0b0cce554cb130d723a9d27458f9298` کے لیے اسٹوریج سلاٹ 1 میں ڈیٹا کی پوزیشن یہ ہے: + +```python +keccak256(decodeHex("000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001")) +``` + +Geth کنسول میں، اس کا حساب اس طرح کیا جا سکتا ہے: + +``` +> var key = "000000000000000000000000391694e7e0b0cce554cb130d723a9d27458f9298" + "0000000000000000000000000000000000000000000000000000000000000001" +undefined +> web3.sha3(key, {"encoding": "hex"}) +"0x6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9" +``` + +`path` اس لیے `keccak256(<6661e9d6d8b923d5bbaab1b96e1dd51ff6ea2a93520fdc9eb75d059238b8c5e9>)` ہے۔ اب اسے پہلے کی طرح اسٹوریج ٹرائی سے ڈیٹا بازیافت کرنے کے لیے استعمال کیا جا سکتا ہے: + +```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} + +ہر بلاک کی اپنی رسیدوں کی ٹرائی ہوتی ہے۔ یہاں ایک `path` ہے: `rlp(transactionIndex)`۔ `transactionIndex` اس بلاک کے اندر اس کا انڈیکس ہے جس میں اسے شامل کیا گیا تھا۔ رسیدوں کی ٹرائی کو کبھی اپ ڈیٹ نہیں کیا جاتا۔ ٹرانزیکشنز ٹرائی کی طرح، موجودہ اور لیگیسی رسیدیں ہیں۔ رسیدوں کی ٹرائی میں ایک مخصوص رسید کو استفسار کرنے کے لیے، اس کے بلاک میں ٹرانزیکشن کا انڈیکس، رسید کا پے لوڈ اور ٹرانزیکشن کی قسم درکار ہے۔ واپس کی گئی رسید `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/ur/developers/docs/data-structures-and-encoding/rlp/index.md b/public/content/translations/ur/developers/docs/data-structures-and-encoding/rlp/index.md new file mode 100644 index 00000000000..c9f8faaf378 --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-structures-and-encoding/rlp/index.md @@ -0,0 +1,163 @@ +--- +title: "ریکرسیو-لینتھ پریفکس (RLP) سیریلائزیشن" +description: "Ethereum کی ایگزیکیوشن لیئر میں rlp انکوڈنگ کی ایک تعریف۔" +lang: ur-in +sidebarDepth: 2 +--- + +ریکرسیو لینتھ پریفکس (RLP) سیریلائزیشن کا استعمال Ethereum کے ایگزیکیوشن کلائنٹس میں بڑے پیمانے پر کیا جاتا ہے۔ RLP نوڈز کے درمیان ڈیٹا کی منتقلی کو ایک اسپیس-ایفیشینٹ فارمیٹ میں معیاری بناتا ہے۔ RLP کا مقصد بائنری ڈیٹا کی من مانی طور پر نیسٹڈ اریز کو انکوڈ کرنا ہے، اور RLP Ethereum کی ایگزیکیوشن لیئر میں آبجیکٹس کو سیریلائز کرنے کے لیے استعمال ہونے والا بنیادی انکوڈنگ طریقہ ہے۔ RLP کا بنیادی مقصد اسٹرکچر کو انکوڈ کرنا ہے؛ مثبت انٹیجرز کے علاوہ، RLP مخصوص ڈیٹا کی اقسام (مثلاً، سٹرنگز، فلوٹس) کی انکوڈنگ کو ہائیر-آرڈر پروٹوکولز کو تفویض کرتا ہے۔ مثبت انٹیجرز کی نمائندگی بگ-اینڈین بائنری فارم میں بغیر کسی لیڈنگ زیرو کے کی جانی چاہئے (اس طرح انٹیجر ویلیو صفر کو خالی بائٹ اری کے برابر بناتا ہے)۔ لیڈنگ زیرو والے ڈی سیریلائزڈ مثبت انٹیجرز کو RLP استعمال کرنے والے کسی بھی ہائیر-آرڈر پروٹوکول کے ذریعہ غلط سمجھا جانا چاہئے۔ + +مزید معلومات [ایتھیریم ییلو پیپر (اپینڈکس B)](https://ethereum.github.io/yellowpaper/paper.pdf#page=19) میں۔ + +ایک ڈکشنری کو انکوڈ کرنے کے لئے RLP کا استعمال کرنے کے لئے، دو تجویز کردہ کینونیکل فارمز ہیں: + +- `[[k1,v1],[k2,v2]...]` کا استعمال کریں جس میں کیز لیکسیکوگرافک آرڈر میں ہوں۔ +- ہائیر-لیول پیٹریشیا ٹری انکوڈنگ کا استعمال کریں جیسا کہ Ethereum کرتا ہے۔ + +## تعریف {#definition} + +RLP انکوڈنگ فنکشن ایک آئٹم لیتا ہے۔ ایک آئٹم کی تعریف اس طرح ہے: + +- ایک سٹرنگ (یعنی بائٹ اری) ایک آئٹم ہے +- آئٹمز کی ایک لسٹ ایک آئٹم ہے +- ایک مثبت انٹیجر ایک آئٹم ہے + +مثال کے طور پر، مندرجہ ذیل تمام آئٹمز ہیں: + +- ایک خالی سٹرنگ؛ +- لفظ "cat" پر مشتمل سٹرنگ؛ +- کسی بھی تعداد میں سٹرنگز پر مشتمل ایک لسٹ؛ +- اور مزید پیچیدہ ڈیٹا اسٹرکچرز جیسے `["cat", ["puppy", "cow"], "horse", [[]], "pig", [""], "sheep"]`۔ +- نمبر `100` + +نوٹ کریں کہ اس صفحے کے باقی حصے کے سیاق و سباق میں، 'سٹرنگ' کا مطلب ہے "بائنری ڈیٹا کے بائٹس کی ایک خاص تعداد"؛ کوئی خاص انکوڈنگ استعمال نہیں کی جاتی ہے، اور سٹرنگز کے مواد کے بارے میں کسی علم کا مطلب نہیں ہے (سوائے اس کے کہ غیر کم از کم مثبت انٹیجرز کے خلاف اصول کے مطابق ضرورت ہو)۔ + +RLP انکوڈنگ کی تعریف اس طرح ہے: + +- ایک مثبت انٹیجر کے لیے، اسے سب سے چھوٹی بائٹ اری میں تبدیل کیا جاتا ہے جس کی بگ-اینڈین تشریح انٹیجر ہے، اور پھر نیچے دیے گئے اصولوں کے مطابق ایک سٹرنگ کے طور پر انکوڈ کیا جاتا ہے۔ +- ایک واحد بائٹ کے لیے جس کی ویلیو `[0x00, 0x7f]` (ڈیسیمل `[0, 127]`) رینج میں ہے، وہ بائٹ خود اس کی RLP انکوڈنگ ہے۔ +- بصورت دیگر، اگر کوئی سٹرنگ 0-55 بائٹس لمبی ہے، تو RLP انکوڈنگ ایک واحد بائٹ پر مشتمل ہوتی ہے جس کی ویلیو **0x80** (ڈیسیمل 128) ہوتی ہے، اور اس کے بعد سٹرنگ کی لمبائی اور پھر سٹرنگ آتی ہے۔ اس طرح پہلے بائٹ کی رینج `[0x80, 0xb7]` (ڈیسیمل `[128, 183]`) ہے۔ +- اگر کوئی سٹرنگ 55 بائٹس سے زیادہ لمبی ہے، تو RLP انکوڈنگ **0xb7** (ڈیسیمل 183) کی ویلیو کے ساتھ ایک واحد بائٹ پر مشتمل ہوتی ہے، اور اس کے بعد بائنری فارم میں سٹرنگ کی لمبائی کی بائٹس میں لمبائی، پھر سٹرنگ کی لمبائی، اور پھر سٹرنگ آتی ہے۔ مثال کے طور پر، ایک 1024 بائٹ لمبی سٹرنگ کو `\xb9\x04\x00` (ڈیسیمل `185, 4, 0`) کے طور پر انکوڈ کیا جائے گا جس کے بعد سٹرنگ آئے گی۔ یہاں، `0xb9` (183 + 2 = 185) پہلے بائٹ کے طور پر ہے، جس کے بعد 2 بائٹس `0x0400` (ڈیسیمل 1024) آتے ہیں جو اصل سٹرنگ کی لمبائی کو ظاہر کرتے ہیں۔ اس طرح پہلے بائٹ کی رینج `[0xb8, 0xbf]` (ڈیسیمل `[184, 191]`) ہے۔ +- اگر کوئی سٹرنگ 2^64 بائٹس لمبی، یا اس سے زیادہ لمبی ہے، تو اسے انکوڈ نہیں کیا جا سکتا۔ +- اگر کسی لسٹ کا کل پے لوڈ (یعنی، اس کے تمام آئٹمز کی مشترکہ لمبائی جنہیں RLP انکوڈ کیا جا رہا ہے) 0-55 بائٹس لمبا ہے، تو RLP انکوڈنگ **0xc0** کی ویلیو کے ساتھ ایک واحد بائٹ پر مشتمل ہوتی ہے، اور اس کے بعد پے لوڈ کی لمبائی اور پھر آئٹمز کی RLP انکوڈنگز کا کنکیٹنیشن آتا ہے۔ اس طرح پہلے بائٹ کی رینج `[0xc0, 0xf7]` (ڈیسیمل `[192, 247]`) ہے۔ +- اگر کسی لسٹ کا کل پے لوڈ 55 بائٹس سے زیادہ لمبا ہے، تو RLP انکوڈنگ **0xf7** کی ویلیو کے ساتھ ایک واحد بائٹ پر مشتمل ہوتی ہے، اور اس کے بعد بائنری فارم میں پے لوڈ کی لمبائی کی بائٹس میں لمبائی، پھر پے لوڈ کی لمبائی، اور پھر آئٹمز کی RLP انکوڈنگز کا کنکیٹنیشن آتا ہے۔ اس طرح پہلے بائٹ کی رینج `[0xf8, 0xff]` (ڈیسیمل `[248, 255]`) ہے۔ + +کوڈ میں، یہ ہے: + +```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} + +- سٹرنگ "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 انکوڈنگ کے اصولوں اور عمل کے مطابق، RLP ڈی کوڈ کے ان پٹ کو بائنری ڈیٹا کا ایک اری سمجھا جاتا ہے۔ RLP ڈی کوڈنگ کا عمل اس طرح ہے: + +1. ان پٹ ڈیٹا کے پہلے بائٹ (یعنی پریفکس) کے مطابق ڈیٹا کی قسم، اصل ڈیٹا کی لمبائی اور آفسیٹ کو ڈی کوڈ کرنا؛ + +2. ڈیٹا کی قسم اور آفسیٹ کے مطابق، ڈیٹا کو اسی کے مطابق ڈی کوڈ کریں، مثبت انٹیجرز کے لئے کم از کم انکوڈنگ کے اصول کا احترام کرتے ہوئے؛ + +3. باقی ان پٹ کو ڈی کوڈ کرنا جاری رکھیں؛ + +ان میں سے، ڈیٹا کی اقسام اور آفسیٹ کو ڈی کوڈ کرنے کے اصول اس طرح ہیں: + +1. ڈیٹا ایک سٹرنگ ہے اگر پہلے بائٹ (یعنی پریفکس) کی رینج [0x00, 0x7f] ہے، اور سٹرنگ خود بالکل پہلا بائٹ ہے؛ + +2. ڈیٹا ایک سٹرنگ ہے اگر پہلے بائٹ کی رینج [0x80, 0xb7] ہے، اور وہ سٹرنگ جس کی لمبائی پہلے بائٹ مائنس 0x80 کے برابر ہے پہلے بائٹ کے بعد آتی ہے؛ + +3. ڈیٹا ایک سٹرنگ ہے اگر پہلے بائٹ کی رینج [0xb8, 0xbf] ہے، اور سٹرنگ کی لمبائی جس کی بائٹس میں لمبائی پہلے بائٹ مائنس 0xb7 کے برابر ہے پہلے بائٹ کے بعد آتی ہے، اور سٹرنگ، سٹرنگ کی لمبائی کے بعد آتی ہے؛ + +4. ڈیٹا ایک لسٹ ہے اگر پہلے بائٹ کی رینج [0xc0, 0xf7] ہے، اور لسٹ کے تمام آئٹمز کی RLP انکوڈنگز کا کنکیٹنیشن جس کا کل پے لوڈ پہلے بائٹ مائنس 0xc0 کے برابر ہے پہلے بائٹ کے بعد آتا ہے؛ + +5. ڈیٹا ایک لسٹ ہے اگر پہلے بائٹ کی رینج [0xf8, 0xff] ہے، اور لسٹ کا کل پے لوڈ جس کی لمبائی پہلے بائٹ مائنس 0xf7 کے برابر ہے پہلے بائٹ کے بعد آتا ہے، اور لسٹ کے تمام آئٹمز کی RLP انکوڈنگز کا کنکیٹنیشن لسٹ کے کل پے لوڈ کے بعد آتا ہے؛ + +کوڈ میں، یہ ہے: + +```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} + +- [Ethereum میں RLP](https://medium.com/coinmonks/data-structure-in-ethereum-episode-1-recursive-length-prefix-rlp-encoding-decoding-d1016832f919) +- [Ethereum انڈر دی ہڈ: RLP](https://medium.com/coinmonks/ethereum-under-the-hood-part-3-rlp-decoding-df236dc13e58) +- [Coglio, A. (2020). ACL2 میں Ethereum کا ریکرسیو لینتھ پریفکس۔ 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/ur/developers/docs/data-structures-and-encoding/ssz/index.md b/public/content/translations/ur/developers/docs/data-structures-and-encoding/ssz/index.md new file mode 100644 index 00000000000..5044d561ca4 --- /dev/null +++ b/public/content/translations/ur/developers/docs/data-structures-and-encoding/ssz/index.md @@ -0,0 +1,149 @@ +--- +title: Simple serialize +description: "Ethereum کے SSZ فارمیٹ کی وضاحت۔" +lang: ur-in +sidebarDepth: 2 +--- + +**Simple serialize (SSZ)** وہ سیریلائزیشن طریقہ ہے جو Beacon Chain پر استعمال ہوتا ہے۔ یہ consensus layer میں ہر جگہ execution layer پر استعمال ہونے والی RLP سیریلائزیشن کی جگہ لیتا ہے، سوائے peer discovery protocol کے۔ RLP سیریلائزیشن کے بارے میں مزید جاننے کے لیے، [Recursive-length prefix (RLP)](/developers/docs/data-structures-and-encoding/rlp/) دیکھیں۔ SSZ کو اس طرح ڈیزائن کیا گیا ہے کہ یہ متعین (deterministic) ہو اور مؤثر طریقے سے Merkleize بھی کر سکے۔ SSZ کو دو اجزاء پر مشتمل سمجھا جا سکتا ہے: ایک سیریلائزیشن اسکیم اور ایک Merkleization اسکیم جسے سیریلائزڈ ڈیٹا اسٹرکچر کے ساتھ مؤثر طریقے سے کام کرنے کے لیے ڈیزائن کیا گیا ہے۔ + +## SSZ کیسے کام کرتا ہے؟ {#how-does-ssz-work} + +### سیریلائزیشن {#serialization} + +SSZ ایک سیریلائزیشن اسکیم ہے جو خود اپنی وضاحت نہیں کرتی - بلکہ یہ ایک ایسے اسکیما پر انحصار کرتی ہے جسے پہلے سے معلوم ہونا ضروری ہے۔ SSZ سیریلائزیشن کا مقصد کسی بھی پیچیدگی کی اشیاء (objects) کی نمائندگی بائٹس (bytes) کی اسٹرنگز کے طور پر کرنا ہے۔ یہ "بنیادی اقسام" (basic types) کے لیے ایک بہت آسان عمل ہے۔ عنصر (element) کو سیدھے سادھے ہیکسا ڈیسیمل بائٹس میں تبدیل کر دیا جاتا ہے۔ بنیادی اقسام میں شامل ہیں: + +- غیر دستخط شدہ انٹیجرس (unsigned integers) +- بولینز (Booleans) + +پیچیدہ "مرکب" اقسام (composite types) کے لیے، سیریلائزیشن زیادہ پیچیدہ ہے کیونکہ مرکب قسم میں متعدد عناصر ہوتے ہیں جن کی اقسام یا سائز مختلف ہو سکتے ہیں، یا دونوں۔ جہاں ان تمام اشیاء (objects) کی لمبائی مقرر (fixed) ہوتی ہے (یعنی، عناصر کا سائز ان کی اصل قدروں سے قطع نظر ہمیشہ مستقل رہے گا)، سیریلائزیشن صرف مرکب قسم کے ہر عنصر کو little-endian بائٹ اسٹرنگز میں ترتیب دے کر تبدیل کرنا ہے۔ ان بائٹ اسٹرنگز کو ایک ساتھ جوڑ دیا جاتا ہے۔ سیریلائزڈ آبجیکٹ میں مقررہ لمبائی والے عناصر کی بائٹ لسٹ نمائندگی اسی ترتیب میں ہوتی ہے جس میں وہ ڈی سیریلائزڈ آبجیکٹ میں ظاہر ہوتے ہیں۔ + +متغیر لمبائی والی اقسام کے لیے، سیریلائزڈ آبجیکٹ میں اس عنصر کی پوزیشن پر اصل ڈیٹا کو ایک "آفسیٹ" قدر سے بدل دیا جاتا ہے۔ اصل ڈیٹا کو سیریلائزڈ آبجیکٹ کے آخر میں ایک ہیپ (heap) میں شامل کیا جاتا ہے۔ آفسیٹ قدر ہیپ میں اصل ڈیٹا کے آغاز کے لیے انڈیکس ہے، جو متعلقہ بائٹس کے لیے ایک پوائنٹر کے طور پر کام کرتا ہے۔ + +نیچے دی گئی مثال وضاحت کرتی ہے کہ ایک ایسے کنٹینر کے لیے آفسیٹنگ کیسے کام کرتی ہے جس میں مقررہ اور متغیر لمبائی والے دونوں عناصر ہوں: + +```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) + +``` + +`serialized` کی ساخت درج ذیل ہوگی (یہاں صرف 4 بٹس تک پیڈ کیا گیا ہے، حقیقت میں 32 بٹس تک پیڈ کیا جاتا ہے، اور وضاحت کے لیے `int` نمائندگی کو برقرار رکھا گیا ہے): + +``` +[37, 0, 0, 0, 55, 0, 0, 0, 16, 0, 0, 0, 22, 0, 0, 0, 1, 2, 3, 4] +------------ ----------- ----------- ----------- ---------- + | | | | | + number1 number2 vector کے number 3 vector کی + لیے آفسیٹ قدر + +``` + +وضاحت کے لیے لائنوں میں تقسیم کیا گیا ہے: + +``` +[ + 37, 0, 0, 0, # `number1` کی little-endian انکوڈنگ۔ + 55, 0, 0, 0, # `number2` کی little-endian انکوڈنگ۔ + 16, 0, 0, 0, # وہ "آفسیٹ" جو بتاتا ہے کہ `vector` کی قدر کہاں سے شروع ہوتی ہے (little-endian 16)۔ + 22, 0, 0, 0, # `number3` کی little-endian انکوڈنگ۔ + 1, 2, 3, 4, # `vector` میں اصل قدریں۔ +] +``` + +یہ اب بھی ایک سادہ شکل ہے - اوپر دیے گئے خاکوں میں موجود انٹیجرس اور زیروز دراصل بائٹ لسٹس کے طور پر اسٹور کیے جائیں گے، اس طرح: + +``` +[ + 10100101000000000000000000000000 # `number1` کی little-endian انکوڈنگ + 10110111000000000000000000000000 # `number2` کی little-endian انکوڈنگ۔ + 10010000000000000000000000000000 # وہ "آفسیٹ" جو بتاتا ہے کہ `vector` کی قدر کہاں سے شروع ہوتی ہے (little-endian 16)۔ + 10010110000000000000000000000000 # `number3` کی little-endian انکوڈنگ۔ + 10000001100000101000001110000100 # `bytes` فیلڈ کی اصل قدر۔ +] +``` + +لہذا متغیر لمبائی والی اقسام کی اصل قدریں سیریلائزڈ آبجیکٹ کے آخر میں ایک ہیپ میں اسٹور کی جاتی ہیں اور ان کے آفسیٹس کو فیلڈز کی ترتیب شدہ فہرست میں ان کی صحیح پوزیشنوں پر اسٹور کیا جاتا ہے۔ + +کچھ خاص معاملات بھی ہیں جن کے لیے مخصوص برتاؤ کی ضرورت ہوتی ہے، جیسے کہ `BitList` قسم جس میں سیریلائزیشن کے دوران لمبائی کی حد (length cap) شامل کرنے اور ڈی سیریلائزیشن کے دوران اسے ہٹانے کی ضرورت ہوتی ہے۔ مکمل تفصیلات [SSZ spec](https://github.com/ethereum/consensus-specs/blob/dev/ssz/simple-serialize.md) میں دستیاب ہیں۔ + +### ڈی سیریلائزیشن {#deserialization} + +اس آبجیکٹ کو ڈی سیریلائز کرنے کے لیے اسکیما کی ضرورت ہوتی ہے۔ اسکیما سیریلائزڈ ڈیٹا کی عین ترتیب کی وضاحت کرتا ہے تاکہ ہر مخصوص عنصر کو بائٹس کے ایک blob سے ایک ایسے بامعنی آبجیکٹ میں ڈی سیریلائز کیا جا سکے جس میں عناصر کی قسم، قدر، سائز اور پوزیشن صحیح ہو۔ یہ اسکیما ہی ہے جو ڈی سیریلائزر کو بتاتا ہے کہ کون سی قدریں اصل ہیں اور کون سی آفسیٹ ہیں۔ جب کسی آبجیکٹ کو سیریلائز کیا جاتا ہے تو تمام فیلڈ کے نام غائب ہو جاتے ہیں، لیکن ڈی سیریلائزیشن پر اسکیما کے مطابق انہیں دوبارہ بنایا جاتا ہے۔ + +اس پر ایک انٹرایکٹو وضاحت کنندہ کے لیے [ssz.dev](https://www.ssz.dev/overview) دیکھیں۔ + +## مرکلائزیشن {#merkleization} + +اس SSZ سیریلائزڈ آبجیکٹ کو پھر مرکلائز کیا جا سکتا ہے - یعنی اسی ڈیٹا کی Merkle-tree نمائندگی میں تبدیل کیا جا سکتا ہے۔ سب سے پہلے، سیریلائزڈ آبجیکٹ میں 32-بائٹ کے چنکس (chunks) کی تعداد کا تعین کیا جاتا ہے۔ یہ درخت کے "پتے" (leaves) ہیں۔ پتوں کی کل تعداد 2 کی طاقت (power of 2) ہونی چاہیے تاکہ پتوں کو ایک ساتھ ہیش کرنے پر آخر کار ایک واحد ہیش-ٹری-روٹ (hash-tree-root) بن جائے۔ اگر قدرتی طور پر ایسا نہیں ہے، تو 32 بائٹس کے زیروز پر مشتمل اضافی پتے شامل کیے جاتے ہیں۔ خاکے کے طور پر: + +``` + ہیش ٹری روٹ + / \ + / \ + / \ + / \ + پتے 1 اور 2 کا ہیش پتے 3 اور 4 کا ہیش + / \ / \ + / \ / \ + / \ / \ + پتا 1 پتا 2 پتا 3 پتا 4 +``` + +ایسے معاملات بھی ہیں جہاں درخت کے پتے قدرتی طور پر اس طرح یکساں طور پر تقسیم نہیں ہوتے جیسا کہ اوپر کی مثال میں ہے۔ مثال کے طور پر، پتا 4 ایک ایسا کنٹینر ہو سکتا ہے جس میں متعدد عناصر ہوں جن کے لیے Merkle ٹری میں اضافی "گہرائی" (depth) شامل کرنے کی ضرورت ہوتی ہے، جس سے ایک غیر مساوی درخت بنتا ہے۔ + +درخت کے ان عناصر کو پتا X، نوڈ X وغیرہ کہنے کے بجائے، ہم انہیں عمومی انڈیکس دے سکتے ہیں، جس کی شروعات روٹ = 1 سے ہوتی ہے اور ہر سطح پر بائیں سے دائیں گنتی کی جاتی ہے۔ یہ اوپر بیان کردہ عمومی انڈیکس ہے۔ سیریلائزڈ فہرست میں ہر عنصر کا ایک عمومی انڈیکس ہوتا ہے جو `2**depth + idx` کے برابر ہوتا ہے، جہاں idx سیریلائزڈ آبجیکٹ میں اس کی زیرو-انڈیکسڈ پوزیشن ہے اور depth مرکل ٹری میں سطحوں کی تعداد ہے, جس کا تعین عناصر (پتوں) کی تعداد کے بیس-ٹو لاگرتھم کے طور پر کیا جا سکتا ہے۔ + +## عمومی انڈیکس {#generalized-indices} + +ایک عمومی انڈیکس ایک انٹیجر ہے جو ایک بائنری Merkle ٹری میں ایک نوڈ کی نمائندگی کرتا ہے جہاں ہر نوڈ کا ایک عمومی انڈیکس `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... + +``` + +یہ نمائندگی Merkle ٹری میں موجود ڈیٹا کے ہر ٹکڑے کے لیے ایک نوڈ انڈیکس فراہم کرتی ہے۔ + +## ملٹی پروفس {#multiproofs} + +کسی مخصوص عنصر کی نمائندگی کرنے والے عمومی انڈیکس کی فہرست فراہم کرنا ہمیں اسے ہیش-ٹری-روٹ کے خلاف تصدیق کرنے کی اجازت دیتا ہے۔ یہ روٹ حقیقت کا ہمارا قبول شدہ ورژن ہے۔ ہمیں فراہم کردہ کسی بھی ڈیٹا کی اس حقیقت کے خلاف تصدیق کی جا سکتی ہے، اسے Merkle ٹری میں صحیح جگہ پر داخل کرکے (جس کا تعین اس کے عمومی انڈیکس سے ہوتا ہے) اور یہ دیکھ کر کہ روٹ مستقل رہتا ہے۔ اسپیک میں [یہاں](https://github.com/ethereum/consensus-specs/blob/dev/ssz/merkle-proofs.md#merkle-multiproofs) فنکشنز ہیں جو عمومی انڈیکس کے ایک خاص سیٹ کے مواد کی تصدیق کے لیے درکار نوڈز کے کم سے کم سیٹ کا حساب لگانے کا طریقہ دکھاتے ہیں۔ + +مثال کے طور پر، نیچے دیے گئے ٹری میں انڈیکس 9 پر ڈیٹا کی تصدیق کرنے کے لیے، ہمیں انڈیکس 8، 9، 5، 3، 1 پر موجود ڈیٹا کے ہیش کی ضرورت ہے۔ +(8,9) کا ہیش، ہیش (4) کے برابر ہونا چاہیے، جو 5 کے ساتھ ہیش ہو کر 2 بناتا ہے، جو 3 کے ساتھ ہیش ہو کر ٹری روٹ 1 بناتا ہے۔ اگر 9 کے لیے غلط ڈیٹا فراہم کیا گیا، تو روٹ بدل جائے گا - ہم اس کا پتہ لگا لیں گے اور برانچ کی تصدیق میں ناکام ہو جائیں گے۔ + +``` +* = پروف بنانے کے لیے درکار ڈیٹا + + 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/)