அறிமுகம்

function getAbsolutelyRandomNumer() {
        return 4; // returns absolutely random number!
}

குறியாக்கவியலில் இருந்து முற்றிலும் வலுவான சைஃபர் என்ற கருத்தைப் போலவே, உண்மையான "பொதுவில் சரிபார்க்கக்கூடிய ரேண்டம் பெக்கான்" (இனிமேல் PVRB) நெறிமுறைகள் சிறந்த திட்டத்திற்கு முடிந்தவரை நெருங்க முயற்சி செய்கின்றன, ஏனெனில் உண்மையான நெட்வொர்க்குகளில் இது அதன் தூய வடிவத்தில் பொருந்தாது: ஒரு பிட் மீது கண்டிப்பாக உடன்படுவது அவசியம், பல சுற்றுகள் இருக்க வேண்டும், மேலும் அனைத்து செய்திகளும் விரைவாகவும் எப்போதும் வழங்கப்பட வேண்டும். நிச்சயமாக, இது உண்மையான நெட்வொர்க்குகளில் இல்லை. எனவே, நவீன பிளாக்செயின்களில் குறிப்பிட்ட பணிகளுக்காக PVRBகளை வடிவமைக்கும்போது, ​​அதன் விளைவாக ஏற்படும் சீரற்ற தன்மை மற்றும் கிரிப்டோகிராஃபிக் வலிமையைக் கட்டுப்படுத்த இயலாமை தவிர, இன்னும் பல முற்றிலும் கட்டடக்கலை மற்றும் தொழில்நுட்ப சிக்கல்கள் எழுகின்றன.

PVRBஐப் பொறுத்தவரை, பிளாக்செயின் ஒரு தகவல்தொடர்பு ஊடகமாகும், அதில் செய்திகள் = பரிவர்த்தனைகள். நெட்வொர்க் சிக்கல்கள், செய்திகளை வழங்காதது, மிடில்வேரில் உள்ள சிக்கல்கள் ஆகியவற்றிலிருந்து ஓரளவு சுருக்கம் பெற இது உங்களை அனுமதிக்கிறது - இந்த அபாயங்கள் அனைத்தும் பரவலாக்கப்பட்ட நெட்வொர்க்கால் கருதப்படுகின்றன, மேலும் PVRB க்கு அதன் முக்கிய மதிப்பு ஏற்கனவே அனுப்பப்பட்ட பரிவர்த்தனையை ரத்து செய்யவோ அல்லது சிதைக்கவோ இயலாமை ஆகும். ஒருமித்த கருத்து மீது வெற்றிகரமான தாக்குதலை நடத்தாத வரை, பங்கேற்பாளர்கள் நெறிமுறையில் பங்கேற்க மறுக்க அனுமதிக்காதீர்கள். இந்த அளவிலான பாதுகாப்பு ஏற்றுக்கொள்ளத்தக்கது, எனவே PVRB முக்கிய பிளாக்செயின் சங்கிலியின் அதே அளவிற்கு பங்கேற்பாளர்களின் கூட்டுக்கு எதிர்ப்புத் தெரிவிக்க வேண்டும். மேலும், PVRB முக்கிய பிளாக்செயினில் உடன்படும் பட்சத்தில், PVRB ஒருமித்த பகுதியாக இருக்க வேண்டும் என்பதை இது குறிக்கிறது. அல்லது, PVRB என்பது பிளாக்செயின் மற்றும் தொகுதிகள் தொடர்பாக ஒத்திசைவற்ற முறையில் செயல்படும் ஸ்மார்ட் ஒப்பந்தத்தால் செயல்படுத்தப்படும் ஒரு முழுமையான நெறிமுறையாகும். இரண்டு முறைகளும் அவற்றின் நன்மைகள் மற்றும் தீமைகள் உள்ளன, மேலும் அவற்றுக்கிடையேயான தேர்வு மிகவும் அற்பமானது அல்ல.

PVRB ஐ செயல்படுத்த இரண்டு வழிகள்

PVRB ஐ செயல்படுத்துவதற்கான இரண்டு விருப்பங்களை இன்னும் விரிவாக விவரிப்போம் - பிளாக்செயினிலிருந்து சுயாதீனமான ஸ்மார்ட் ஒப்பந்தத்தைப் பயன்படுத்தி செயல்படும் தனித்த பதிப்பு மற்றும் நெறிமுறையில் கட்டமைக்கப்பட்ட ஒருமித்த-ஒருங்கிணைந்த பதிப்பு, அதன்படி பிணையம் பிளாக்செயினில் ஒப்புக்கொள்கிறது. பரிவர்த்தனைகள் சேர்க்கப்பட வேண்டும். எல்லா சந்தர்ப்பங்களிலும், நான் பிரபலமான பிளாக்செயின் என்ஜின்களைக் குறிக்கிறேன்: Ethereum, EOS மற்றும் ஸ்மார்ட் ஒப்பந்தங்களை ஹோஸ்ட் செய்யும் மற்றும் செயலாக்கும் விதத்தில் அவற்றைப் போன்ற அனைத்தும்.

தனித்த ஒப்பந்தம்

இந்த பதிப்பில், PVRB என்பது சீரற்ற உற்பத்தியாளர்களின் பரிவர்த்தனைகளை ஏற்றுக் கொள்ளும் ஒரு ஸ்மார்ட் ஒப்பந்தமாகும் (இனிமேல் RP என குறிப்பிடப்படுகிறது), அவற்றை செயலாக்குகிறது, முடிவுகளை ஒருங்கிணைக்கிறது, இதன் விளைவாக, எந்தவொரு பயனரும் இந்த ஒப்பந்தத்திலிருந்து பெறக்கூடிய ஒரு குறிப்பிட்ட மதிப்பை அடைகிறது. இந்த மதிப்பானது ஒப்பந்தத்தில் நேரடியாகச் சேமிக்கப்படாமல் இருக்கலாம், மாறாக விளைந்த ரேண்டத்தின் ஒரே ஒரு மதிப்பை நிர்ணயிக்கும் வகையில் பெறக்கூடிய தரவுகளால் மட்டுமே குறிப்பிடப்படும். இந்தத் திட்டத்தில், RP கள் பிளாக்செயினின் பயனர்கள், மேலும் எவரும் தலைமுறை செயல்பாட்டில் பங்கேற்க அனுமதிக்கப்படலாம்.

முழுமையான ஒப்பந்தத்துடன் கூடிய விருப்பம் நல்லது:

• பெயர்வுத்திறன் (ஒப்பந்தங்களை பிளாக்செயினிலிருந்து பிளாக்செயினுக்கு இழுக்கலாம்)
• செயல்படுத்தல் மற்றும் சோதனையின் எளிமை (ஒப்பந்தங்களை எழுதுவது மற்றும் சோதிக்க எளிதானது)
• பொருளாதார திட்டங்களை செயல்படுத்துவதில் வசதி (உங்கள் சொந்த டோக்கனை உருவாக்குவது எளிது, அதன் தர்க்கம் PVRB இன் நோக்கங்களுக்கு உதவுகிறது)
• ஏற்கனவே வேலை செய்யும் பிளாக்செயின்களில் தொடங்குவதற்கான வாய்ப்பு

இது தீமைகளையும் கொண்டுள்ளது:

• கணினி வளங்கள், பரிவர்த்தனை அளவு மற்றும் சேமிப்பிடம் (வேறுவிதமாகக் கூறினால், cpu/mem/io)
• ஒப்பந்தத்தில் உள்ள செயல்பாடுகளுக்கான கட்டுப்பாடுகள் (எல்லா வழிமுறைகளும் கிடைக்கவில்லை, வெளிப்புற நூலகங்களை இணைப்பது கடினம்)
• பிளாக்செயினில் சேர்க்கப்பட்டுள்ள பரிவர்த்தனைகளை விட வேகமாக செய்திகளை ஒழுங்கமைக்க இயலாமை

இந்த விருப்பம் ஏற்கனவே உள்ள நெட்வொர்க்கில் இயங்க வேண்டிய PVRB ஐ செயல்படுத்துவதற்கு ஏற்றது, சிக்கலான கிரிப்டோகிராஃபி இல்லை மற்றும் அதிக எண்ணிக்கையிலான தொடர்புகள் தேவையில்லை.

ஒருமித்த-ஒருங்கிணைந்த

இந்த பதிப்பில், பிவிஆர்பி பிளாக்செயின் நோட் குறியீட்டில் செயல்படுத்தப்படுகிறது, உள்ளமைக்கப்பட்ட அல்லது பிளாக்செயின் முனைகளுக்கு இடையேயான செய்திகளின் பரிமாற்றத்துடன் இணையாக இயங்குகிறது. நெறிமுறையின் முடிவுகள் நேரடியாக தயாரிக்கப்பட்ட தொகுதிகளில் எழுதப்படுகின்றன, மேலும் நெறிமுறை செய்திகள் முனைகளுக்கு இடையில் p2p நெட்வொர்க்கில் அனுப்பப்படுகின்றன. நெறிமுறையானது தொகுதிகளில் எழுதப்பட வேண்டிய எண்களை விளைவிப்பதால், நெட்வொர்க் அவைகளில் ஒருமித்த கருத்தை அடைய வேண்டும். இதன் பொருள், பரிவர்த்தனைகள் போன்ற PVRB செய்திகள் முனைகளால் சரிபார்க்கப்பட வேண்டும் மற்றும் தொகுதிகளில் சேர்க்கப்பட வேண்டும், இதனால் எந்தவொரு நெட்வொர்க் பங்கேற்பாளரும் PVRB நெறிமுறைக்கு இணங்குவதை சரிபார்க்க முடியும். இது தானாகவே வெளிப்படையான தீர்வுக்கு நம்மை இட்டுச் செல்கிறது - நெட்வொர்க் ஒரு பிளாக் மற்றும் அதில் பரிவர்த்தனைகள் பற்றிய ஒருமித்த கருத்தை ஏற்றுக்கொண்டால், PVRB ஒருமித்த நெறிமுறையின் ஒரு பகுதியாக இருக்க வேண்டும், ஒரு தனி நெறிமுறை அல்ல. இல்லையெனில், ஒருமித்த பார்வையில் ஒரு தொகுதி செல்லுபடியாகும், ஆனால் PVRB நெறிமுறை பின்பற்றப்படவில்லை, மேலும் PVRB பார்வையில் இருந்து தொகுதியை ஏற்றுக்கொள்ள முடியாது. எனவே "ஒருமித்த-ஒருங்கிணைந்த" விருப்பம் தேர்ந்தெடுக்கப்பட்டால், PVRB ஒருமித்த ஒரு முக்கிய பகுதியாக மாறும்.

பிணைய ஒருமித்த மட்டத்தில் PVRB செயலாக்கங்களை விவரிக்கும் போது, ​​இறுதிச் சிக்கல்களைத் தவிர்க்க முடியாது. இறுதியானது ஒரு பிளாக்கில் (மற்றும் அதற்கு இட்டுச்செல்லும் சங்கிலி) பூட்டப்படும் உறுதியான கருத்தொற்றுமைகளில் பயன்படுத்தப்படும் ஒரு பொறிமுறையாகும், அது இறுதியானது மற்றும் ஒரு இணையான முட்கரண்டி ஏற்பட்டாலும் அது ஒருபோதும் தூக்கி எறியப்படாது. எடுத்துக்காட்டாக, பிட்காயினில் அத்தகைய பொறிமுறை இல்லை - நீங்கள் அதிக சிக்கலான சங்கிலியை வெளியிட்டால், அது சங்கிலிகளின் நீளத்தைப் பொருட்படுத்தாமல் குறைவான சிக்கலான ஒன்றை மாற்றும். மற்றும் EOS இல், எடுத்துக்காட்டாக, இறுதியானவை கடைசி மீளமுடியாத தொகுதிகள் என்று அழைக்கப்படுகின்றன, அவை சராசரியாக ஒவ்வொரு 432 தொகுதிகளிலும் தோன்றும் (12*21 + 12*15, முன் வாக்கு + முன்-கமிட்). இந்த செயல்முறையானது 2/3 தொகுதி உற்பத்தியாளர்களின் (இனிமேல் BP என குறிப்பிடப்படும்) கையொப்பங்களுக்காக காத்திருக்கிறது. கடந்த எல்ஐபியை விட பழைய ஃபோர்க்குகள் தோன்றும்போது, ​​அவை வெறுமனே நிராகரிக்கப்படுகின்றன. இந்த பொறிமுறையானது, பிளாக்செயினில் பரிவர்த்தனை சேர்க்கப்பட்டுள்ளது என்பதற்கு உத்தரவாதம் அளிப்பதை சாத்தியமாக்குகிறது மற்றும் தாக்குபவர் எந்த ஆதாரங்களைக் கொண்டிருந்தாலும், அது திரும்பப் பெறப்படாது. மேலும், இறுதித் தொகுதிகள் ஹைப்பர்லெட்ஜர், டெண்டர்மிண்ட் மற்றும் பிற pBFT அடிப்படையிலான ஒருமித்த கருத்துக்களில் 2/3 BP ஆல் கையொப்பமிடப்பட்ட தொகுதிகளாகும். மேலும், பிளாக்குகளின் உற்பத்தி மற்றும் வெளியீட்டில் ஒத்திசைவற்ற முறையில் வேலை செய்ய முடியும் என்பதால், ஒருமித்த கருத்துக்கு ஒரு துணை நிரலை இறுதி செய்வதை உறுதி செய்வதற்கான நெறிமுறையை உருவாக்குவது அர்த்தமுள்ளதாக இருக்கிறது. இதோ ஒரு நல்ல விஷயம் கட்டுரை Ethereum இல் இறுதி பற்றி.

இறுதியானது பயனர்களுக்கு மிகவும் முக்கியமானது, அது இல்லாமல் தங்களை "இரட்டை செலவு" தாக்குதலுக்கு ஆளாக நேரிடும், அங்கு BP "தடைகளை" நிறுத்தி, நெட்வொர்க் ஒரு நல்ல பரிவர்த்தனையை "பார்த்த" பிறகு அவற்றை வெளியிடுகிறது. எந்த முடிவும் இல்லை என்றால், வெளியிடப்பட்ட ஃபோர்க் ஒரு "நல்ல" பரிவர்த்தனை மூலம் தொகுதியை மாற்றுகிறது, "கெட்ட" ஃபோர்க்கிலிருந்து, அதே நிதி தாக்குபவர்களின் முகவரிக்கு மாற்றப்படும். PVRB ஐப் பொறுத்தவரை, இறுதித் தேவைகள் இன்னும் கடுமையானவை, ஏனெனில் PVRBக்கான ஃபோர்க்குகளை உருவாக்குவது என்பது தாக்குபவர் மிகவும் லாபகரமான ஒன்றை வெளியிடுவதற்காக பல சீரற்ற விருப்பங்களைத் தயாரிப்பதற்கான வாய்ப்பாகும், மேலும் சாத்தியமான தாக்குதலின் நேரத்தைக் கட்டுப்படுத்துவது ஒரு நல்ல தீர்வு.

எனவே, PVRB மற்றும் ஃபைனலிட்டியை ஒரு நெறிமுறையாக இணைப்பதே சிறந்த வழி - பின்னர் இறுதி செய்யப்பட்ட தொகுதி = இறுதி செய்யப்பட்ட சீரற்றது, இதைத்தான் நாம் பெற வேண்டும். இப்போது வீரர்கள் N வினாடிகளில் உத்தரவாதமான ரேண்டம் பெறுவார்கள், மேலும் அதை மீண்டும் உருட்டவோ அல்லது மீண்டும் இயக்கவோ இயலாது என்பதை உறுதிப்படுத்திக் கொள்ளலாம்.

ஒருமித்த-ஒருங்கிணைந்த விருப்பம் நல்லது:

• தொகுதிகளின் உற்பத்தி தொடர்பாக ஒத்திசைவற்ற செயலாக்கத்தின் சாத்தியம் - தொகுதிகள் வழக்கம் போல் தயாரிக்கப்படுகின்றன, ஆனால் இதற்கு இணையாக, PVRB நெறிமுறை வேலை செய்ய முடியும், இது ஒவ்வொரு தொகுதிக்கும் சீரற்ற தன்மையை உருவாக்காது
• ஸ்மார்ட் ஒப்பந்தங்களுக்கு விதிக்கப்பட்ட கட்டுப்பாடுகள் இல்லாமல், கனமான குறியாக்கவியலைக் கூட செயல்படுத்தும் திறன்
• பரிவர்த்தனைகளை விட வேகமாக செய்திகளின் பரிமாற்றத்தை ஒழுங்கமைக்கும் திறன் பிளாக்செயினில் சேர்க்கப்பட்டுள்ளது, எடுத்துக்காட்டாக, நெறிமுறையின் ஒரு பகுதி நெட்வொர்க்கில் செய்திகளை விநியோகிக்காமல் முனைகளுக்கு இடையில் வேலை செய்ய முடியும்.

இது தீமைகளையும் கொண்டுள்ளது:

• சோதனை மற்றும் மேம்பாட்டில் உள்ள சிரமங்கள் - நீங்கள் பிணைய பிழைகள், காணாமல் போன முனைகள், நெட்வொர்க் ஹார்ட் ஃபோர்க்குகளை பின்பற்ற வேண்டும்
• செயலாக்கப் பிழைகளுக்கு நெட்வொர்க் ஹார்ட்ஃபோர்க் தேவைப்படுகிறது

PVRB ஐ செயல்படுத்துவதற்கான இரண்டு முறைகளும் வாழ்வதற்கான உரிமையைக் கொண்டுள்ளன, ஆனால் நவீன பிளாக்செயின்களில் ஸ்மார்ட் ஒப்பந்தங்களைச் செயல்படுத்துவது கணினி வளங்களில் மிகவும் குறைவாகவே உள்ளது, மேலும் தீவிரமான குறியாக்கவியலுக்கு எந்த மாற்றமும் பெரும்பாலும் சாத்தியமற்றது. மேலும் நமக்கு தீவிர குறியாக்கவியல் தேவைப்படும், அது கீழே காட்டப்படும். இந்த சிக்கல் தெளிவாக தற்காலிகமானது என்றாலும், பல சிக்கல்களைத் தீர்க்க ஒப்பந்தங்களில் தீவிரமான குறியாக்கவியல் தேவைப்படுகிறது, மேலும் அது படிப்படியாகத் தோன்றுகிறது (எடுத்துக்காட்டாக, Ethereum இல் zkSNARKகளுக்கான கணினி ஒப்பந்தங்கள்)

ஒரு வெளிப்படையான மற்றும் நம்பகமான நெறிமுறை செய்தியிடல் சேனலை வழங்கும் Blockchain, இலவசமாக அவ்வாறு செய்வதில்லை. எந்தவொரு பரவலாக்கப்பட்ட நெறிமுறையும் சிபில் தாக்குதலின் சாத்தியத்தை கணக்கில் எடுத்துக்கொள்ள வேண்டும்; எந்தவொரு செயலையும் பல கணக்குகளின் ஒருங்கிணைந்த சக்திகளால் செய்ய முடியும், எனவே, வடிவமைக்கும் போது, ​​தன்னிச்சையான எண்ணிக்கையிலான நெறிமுறையை உருவாக்கும் தாக்குபவர்களின் திறனை கணக்கில் எடுத்துக்கொள்ள வேண்டும். பங்கேற்பாளர்கள் கூட்டாக செயல்படுகிறார்கள்.

PVRB மற்றும் தொகுதி மாறிகள்.

பிளாக்செயின்களில் பல சூதாட்ட பயன்பாடுகளால் சோதிக்கப்பட்ட ஒரு நல்ல பிவிஆர்பியை இதுவரை யாரும் செயல்படுத்தவில்லை என்று நான் சொன்னபோது நான் பொய் சொல்லவில்லை. Ethereum மற்றும் EOS இல் இவ்வளவு சூதாட்ட பயன்பாடுகள் எங்கிருந்து வருகின்றன? இது உங்களை ஆச்சரியப்படுத்துவதைப் போலவே எனக்கும் ஆச்சரியமாக இருக்கிறது, முற்றிலும் தீர்மானிக்கும் சூழலில் இவ்வளவு "தொடர்ச்சியான" ரேண்டம்களை அவர்கள் எங்கிருந்து பெற்றனர்?

பிளாக்செயினில் சீரற்ற தன்மையைப் பெறுவதற்கான விருப்பமான வழி, பிளாக்கில் இருந்து சில வகையான "கணிக்க முடியாத" தகவலை எடுத்து அதன் அடிப்படையில் ஒரு சீரற்ற ஒன்றை உருவாக்குவது - வெறுமனே ஒன்று அல்லது அதற்கு மேற்பட்ட மதிப்புகளை ஹேஷ் செய்வதன் மூலம். இத்தகைய திட்டங்களின் பிரச்சனைகள் பற்றிய நல்ல கட்டுரை இங்கே. தொகுதியில் உள்ள "கணிக்க முடியாத" மதிப்புகளில் ஏதேனும் ஒன்றை நீங்கள் எடுக்கலாம், எடுத்துக்காட்டாக, பிளாக் ஹாஷ், பரிவர்த்தனைகளின் எண்ணிக்கை, நெட்வொர்க் சிக்கலானது மற்றும் முன்கூட்டியே தெரியாத பிற மதிப்புகள். பின்னர், ஒன்று அல்லது அதற்கு மேற்பட்டவற்றை ஹாஷ் செய்து, கோட்பாட்டில், நீங்கள் உண்மையான சீரற்றதைப் பெற வேண்டும். உங்கள் ஸ்கீம் “குவாண்டத்திற்குப் பிந்தைய பாதுகாப்பானது” (குவாண்டம்-ப்ரூஃப் ஹாஷ் செயல்பாடுகள் இருப்பதால் :)) என்பதை நீங்கள் வைட்பேப்பரில் சேர்க்கலாம்.

ஆனால் பிந்தைய குவாண்டம் பாதுகாப்பான ஹாஷ்கள் கூட போதாது, ஐயோ. ரகசியம் PVRB இன் தேவைகளில் உள்ளது, முந்தைய கட்டுரையிலிருந்து அவற்றை உங்களுக்கு நினைவூட்டுகிறேன்:

1. முடிவு ஒரே மாதிரியான விநியோகத்தைக் கொண்டிருக்க வேண்டும், அதாவது வலுவான குறியாக்கவியலின் அடிப்படையில் இருக்க வேண்டும்.
2. முடிவின் எந்த பிட்களையும் கட்டுப்படுத்த முடியாது. இதன் விளைவாக, முடிவை முன்கூட்டியே கணிக்க முடியாது.
3. நெறிமுறையில் பங்கேற்காததன் மூலமோ அல்லது தாக்குதல் செய்திகளுடன் நெட்வொர்க்கை ஓவர்லோட் செய்வதன் மூலமோ நீங்கள் தலைமுறை நெறிமுறையை நாசப்படுத்த முடியாது.
4. மேலே உள்ள அனைத்தும் அனுமதிக்கப்பட்ட எண்ணிக்கையிலான நேர்மையற்ற நெறிமுறை பங்கேற்பாளர்களின் கூட்டுக்கு எதிர்ப்புத் தெரிவிக்க வேண்டும் (எடுத்துக்காட்டாக, பங்கேற்பாளர்களில் 1/3).

இந்த வழக்கில், தேவை 1 மட்டுமே பூர்த்தி செய்யப்படுகிறது, மற்றும் தேவை 2 பூர்த்தி செய்யப்படவில்லை. பிளாக்கில் இருந்து கணிக்க முடியாத மதிப்புகளை ஹேஷிங் செய்வதன் மூலம், சீரான விநியோகம் மற்றும் நல்ல ரேண்டம்களைப் பெறுவோம். ஆனால் BP குறைந்தபட்சம் "தடையை வெளியிடுவதா இல்லையா" என்ற விருப்பம் உள்ளது. எனவே, BP குறைந்தபட்சம் இரண்டு சீரற்ற விருப்பங்களிலிருந்து தேர்வு செய்யலாம்: "அதன் சொந்தம்" மற்றும் வேறு யாராவது தடை செய்தால் அது மாறும். BP ஒரு தொகுதியை வெளியிட்டால், அதைச் செய்யலாமா வேண்டாமா என்று முடிவு செய்தால் என்ன நடக்கும் என்பதை முன்கூட்டியே "ஸ்னூப்" செய்யலாம். எனவே, விளையாடும் போது, ​​எடுத்துக்காட்டாக, "இரட்டை-ஒற்றைப்படை" அல்லது "சிவப்பு/கருப்பு" ரவுலட்டில், அவர் வெற்றியைக் கண்டால் மட்டுமே ஒரு தொகுதியை வெளியிட முடியும். எடுத்துக்காட்டாக, "எதிர்காலத்திலிருந்து" ஒரு தொகுதி ஹாஷைப் பயன்படுத்துவதற்கான உத்தியையும் இது செயல்படுத்தாது. இந்த வழக்கில், “சீரற்றதாகப் பயன்படுத்தப்படும், இது தற்போதைய தரவு மற்றும் எதிர்காலத் தொகுதியின் ஹாஷை உயரத்துடன் ஹேஷ் செய்வதன் மூலம் பெறப்படும், எடுத்துக்காட்டாக, N + 42, அங்கு N என்பது தற்போதைய தொகுதி உயரம். இது திட்டத்தை சிறிது வலுப்படுத்துகிறது, ஆனால் பிபி, வருங்காலத்தில் இருந்தாலும், பிளாக்கை வைத்திருப்பதா அல்லது வெளியிடுவதா என்பதைத் தேர்வுசெய்ய அனுமதிக்கிறது.

இந்த வழக்கில் BP மென்பொருள் மிகவும் சிக்கலானதாகிறது, ஆனால் அதிகம் இல்லை. வெறுமனே, ஒரு தொகுதியில் ஒரு பரிவர்த்தனையைச் சரிபார்த்து, சேர்க்கும்போது, ​​வெற்றி கிடைக்குமா என்பதை விரைவாகச் சரிபார்த்து, வெற்றி பெறுவதற்கான அதிக நிகழ்தகவைப் பெற, ஒரு பரிவர்த்தனை அளவுருக்களைத் தேர்ந்தெடுக்கலாம். அதே நேரத்தில், இதுபோன்ற கையாளுதல்களுக்கு ஸ்மார்ட் பிபியைப் பிடிப்பது கிட்டத்தட்ட சாத்தியமற்றது; ஒவ்வொரு முறையும் நீங்கள் புதிய முகவரிகளைப் பயன்படுத்தலாம் மற்றும் சந்தேகத்தைத் தூண்டாமல் சிறிது சிறிதாக வெற்றி பெறலாம்.

எனவே பிளாக்கில் இருந்து தகவல்களைப் பயன்படுத்தும் முறைகள் PVRB இன் உலகளாவிய செயலாக்கமாக பொருந்தாது. ஒரு வரையறுக்கப்பட்ட பதிப்பில், பந்தய அளவுகள் மீதான கட்டுப்பாடுகள், வீரர்களின் எண்ணிக்கை மற்றும்/அல்லது KYC பதிவு (ஒரு வீரர் பல முகவரிகளைப் பயன்படுத்துவதைத் தடுக்க), இந்தத் திட்டங்கள் சிறிய கேம்களுக்கு வேலை செய்யலாம், ஆனால் அதற்கு மேல் எதுவும் இல்லை.

PVRB மற்றும் உறுதி-வெளிப்படுத்துதல்.

சரி, ஹேஷிங்கிற்கு நன்றி மற்றும் குறைந்தபட்சம் பிளாக் ஹாஷ் மற்றும் பிற மாறிகளின் உறவினர் கணிக்க முடியாத தன்மை. முன்னணியில் இயங்கும் சுரங்கத் தொழிலாளர்களின் சிக்கலை நீங்கள் தீர்த்தால், நீங்கள் இன்னும் பொருத்தமான ஒன்றைப் பெற வேண்டும். இந்தத் திட்டத்தில் பயனர்களைச் சேர்ப்போம் - அவர்கள் சீரற்ற தன்மையையும் பாதிக்கட்டும்: எந்தவொரு தொழில்நுட்ப ஆதரவு ஊழியரும் IT அமைப்புகளில் மிகவும் சீரற்ற விஷயம் பயனர்களின் செயல்கள் என்று உங்களுக்குச் சொல்வார் :)

ஒரு அப்பாவித் திட்டம், பயனர்கள் ரேண்டம் எண்களை அனுப்பினால், அதன் விளைவாக கணக்கிடப்படும் போது, ​​எடுத்துக்காட்டாக, அவர்களின் தொகையின் ஹாஷ் பொருத்தமானதல்ல. இந்த வழக்கில், கடைசி வீரர், தனது சொந்த சீரற்றதைத் தேர்ந்தெடுப்பதன் மூலம், முடிவு என்னவாக இருக்கும் என்பதைக் கட்டுப்படுத்தலாம். இதனால்தான் மிகவும் பரவலாகப் பயன்படுத்தப்படும் உறுதி-வெளிப்படுத்தல் முறை பயன்படுத்தப்படுகிறது. பங்கேற்பாளர்கள் முதலில் தங்கள் ரேண்டம்களில் இருந்து ஹாஷ்களை அனுப்புகிறார்கள் (கமிட்), பின்னர் ரேண்டம்களை அவர்களே திறக்கிறார்கள் (வெளிப்படுத்துகிறார்கள்). தேவையான கமிட்கள் சேகரிக்கப்பட்ட பின்னரே "வெளிப்படுத்துதல்" கட்டம் தொடங்குகிறது, எனவே பங்கேற்பாளர்கள் தாங்கள் முன்பு அனுப்பிய சீரற்ற ஹாஷை சரியாக அனுப்ப முடியும். இப்போது இவை அனைத்தையும் ஒரு தொகுதியின் அளவுருக்களுடன் சேர்த்து, எதிர்காலத்திலிருந்து எடுக்கப்பட்டதை விட சிறந்தது (எதிர்காலத் தொகுதிகளில் ஒன்றில் மட்டுமே சீரற்ற தன்மையைக் காண முடியும்), மற்றும் வோய்லா - சீரற்ற தன்மை தயாராக உள்ளது! இப்போது எந்த வீரரும் அதன் விளைவாக ஏற்படும் சீரற்ற தன்மையை பாதிக்கிறார், மேலும் தீங்கிழைக்கும் BPயை "தோற்கடிக்க" முடியும். பரிவர்த்தனை செய்யும் போது ஒரு குறிப்பிட்ட தொகையை இணைக்க வேண்டும் - ஒரு பாதுகாப்பு வைப்பு, இது வெளிப்படுத்தும் நடைமுறையின் போது மட்டுமே திருப்பித் தரப்படும். இந்த வழக்கில், ஒப்புக்கொள்வது மற்றும் வெளிப்படுத்தாதது லாபமற்றதாக இருக்கும்.

இது ஒரு நல்ல முயற்சி, மேலும் இதுபோன்ற திட்டங்கள் கேமிங் DApps இல் உள்ளன, ஆனால் ஐயோ, இது மீண்டும் போதாது. இப்போது சுரங்கத் தொழிலாளி மட்டுமல்ல, நெறிமுறையில் உள்ள எந்தவொரு பங்கேற்பாளரும் முடிவை பாதிக்கலாம். குறைந்த மாறுபாடு மற்றும் செலவில் மதிப்பைக் கட்டுப்படுத்துவது இன்னும் சாத்தியமாகும், ஆனால், சுரங்கத் தொழிலாளியைப் போலவே, PVRB நெறிமுறையில் பங்கேற்பதற்கான கட்டணத்தை விட வரைபடத்தின் முடிவுகள் மிகவும் மதிப்புமிக்கதாக இருந்தால், சீரற்ற -தயாரிப்பாளர்(RP) வெளிப்படுத்த வேண்டுமா என்பதைத் தீர்மானிக்கலாம் மற்றும் குறைந்தது இரண்டு சீரற்ற விருப்பங்களிலிருந்து தேர்வு செய்யலாம்.
ஆனால் அதை வெளிப்படுத்தாதவர்களை தண்டிக்க முடியும், மேலும் இந்த திட்டம் கைக்கு வரும். அதன் எளிமை ஒரு தீவிர நன்மை - மிகவும் தீவிரமான நெறிமுறைகளுக்கு மிகவும் சக்திவாய்ந்த கணக்கீடுகள் தேவை.

PVRB மற்றும் உறுதியான கையொப்பங்கள்.

RP ஒரு போலி ரேண்டம் எண்ணை வழங்க கட்டாயப்படுத்த மற்றொரு வழி உள்ளது, அது ஒரு "முன் உருவம்" வழங்கப்பட்டால் அது பாதிக்காது - இது ஒரு உறுதியான கையொப்பம். அத்தகைய கையொப்பம், எடுத்துக்காட்டாக, RSA, மற்றும் ECS அல்ல. RP க்கு ஒரு ஜோடி விசைகள் இருந்தால்: RSA மற்றும் ECC, மற்றும் அவர் தனது தனிப்பட்ட விசையுடன் ஒரு குறிப்பிட்ட மதிப்பை கையொப்பமிட்டால், RSA விஷயத்தில் அவர் ஒரே ஒரு கையொப்பத்தைப் பெறுவார், மேலும் ECS விஷயத்தில் அவர் எவ்வளவு வேண்டுமானாலும் உருவாக்கலாம். வெவ்வேறு செல்லுபடியாகும் கையொப்பங்கள். ஏனென்றால், ECS கையொப்பத்தை உருவாக்கும் போது, ​​ஒரு சீரற்ற எண் பயன்படுத்தப்படுகிறது, கையொப்பமிட்டவரால் தேர்ந்தெடுக்கப்படுகிறது, மேலும் அது எந்த வகையிலும் தேர்ந்தெடுக்கப்படலாம், கையொப்பமிடுபவர் பல கையொப்பங்களில் ஒன்றைத் தேர்ந்தெடுக்கும் வாய்ப்பை வழங்குகிறது. RSA விஷயத்தில்: "ஒரு உள்ளீட்டு மதிப்பு" + "ஒரு முக்கிய ஜோடி" = "ஒரு கையெழுத்து". மற்றொரு RP என்ன கையொப்பத்தைப் பெறும் என்பதைக் கணிக்க இயலாது, எனவே ஒரே மதிப்பில் கையொப்பமிட்ட பல பங்கேற்பாளர்களின் RSA கையொப்பங்களை இணைப்பதன் மூலம் உறுதியான கையொப்பங்களைக் கொண்ட PVRB ஐ ஒழுங்கமைக்க முடியும். உதாரணமாக, முந்தைய சீரற்ற. இந்த திட்டம் நிறைய வளங்களை சேமிக்கிறது, ஏனெனில் கையொப்பங்கள் நெறிமுறையின்படி சரியான நடத்தையின் உறுதிப்படுத்தல் மற்றும் சீரற்ற தன்மையின் ஆதாரம்.

இருப்பினும், உறுதியான கையொப்பங்களுடன் கூட, திட்டம் "கடைசி நடிகர்" பிரச்சனைக்கு இன்னும் பாதிக்கப்படக்கூடியது. கையொப்பத்தை வெளியிடலாமா வேண்டாமா என்பதை கடைசி பங்கேற்பாளர் இன்னும் முடிவு செய்யலாம், அதன் மூலம் முடிவைக் கட்டுப்படுத்தலாம். நீங்கள் திட்டத்தை மாற்றலாம், அதில் பிளாக் ஹாஷ்களைச் சேர்க்கலாம், முடிவை முன்கூட்டியே கணிக்க முடியாது, ஆனால் இந்த நுட்பங்கள் அனைத்தும், பல மாற்றங்களை கணக்கில் எடுத்துக்கொண்டாலும், ஒரு பங்கேற்பாளரின் செல்வாக்கின் சிக்கலை இன்னும் தீர்க்காமல் விட்டுவிடுகின்றன. ஒரு நம்பத்தகாத சூழலை ஏற்படுத்துகிறது மற்றும் பொருளாதார மற்றும் நேரக் கட்டுப்பாடுகளின் கீழ் மட்டுமே வேலை செய்ய முடியும். கூடுதலாக, RSA விசைகளின் அளவு (1024 மற்றும் 2048 பிட்கள்) மிகவும் பெரியது, மேலும் பிளாக்செயின் பரிவர்த்தனைகளுக்கான அளவு மிக முக்கியமான அளவுருவாகும். வெளிப்படையாக, சிக்கலைத் தீர்க்க எளிய வழி இல்லை, தொடரலாம்.

PVRB மற்றும் ரகசிய பகிர்வு திட்டங்கள்

கிரிப்டோகிராஃபியில், நெட்வொர்க்கை ஒரே ஒரு PVRB மதிப்பை ஏற்றுக்கொள்ள அனுமதிக்கும் திட்டங்கள் உள்ளன, அதே சமயம் அத்தகைய திட்டங்கள் சில பங்கேற்பாளர்களின் தீங்கிழைக்கும் செயல்களுக்கு எதிர்ப்புத் தெரிவிக்கின்றன. ஷமீரின் ரகசியப் பகிர்வுத் திட்டம் என்பது உங்களுக்குத் தெரிந்திருக்க வேண்டிய பயனுள்ள நெறிமுறைகளில் ஒன்றாகும். இது ஒரு ரகசியத்தை (உதாரணமாக, ஒரு ரகசிய விசையை) பல பகுதிகளாகப் பிரித்து, N பங்கேற்பாளர்களுக்கு இந்த பகுதிகளை விநியோகிக்க உதவுகிறது. N இலிருந்து M பகுதிகளை மீட்டெடுக்க போதுமானதாக இரகசியமானது விநியோகிக்கப்படுகிறது, மேலும் இவை எந்த M பகுதிகளாகவும் இருக்கலாம். விரல்களில் இருந்தால், அறியப்படாத செயல்பாட்டின் வரைபடம் இருந்தால், பங்கேற்பாளர்கள் வரைபடத்தில் புள்ளிகளைப் பரிமாறிக்கொள்வார்கள், மேலும் M புள்ளிகளைப் பெற்ற பிறகு, முழு செயல்பாட்டையும் மீட்டெடுக்க முடியும்.
ஒரு நல்ல விளக்கம் கொடுக்கப்பட்டுள்ளது விக்கி ஆனால் உங்கள் தலையில் உள்ள நெறிமுறையை இயக்க நடைமுறையில் அதனுடன் விளையாடுவது பயனுள்ளதாக இருக்கும் டெமோ பக்கம்.

FSSS (Fiat-Shamir சீக்ரெட் ஷேரிங்) திட்டம் அதன் தூய வடிவில் பொருந்தினால், அது அழியாத PVRB ஆக இருக்கும். அதன் எளிய வடிவத்தில், நெறிமுறை இப்படி இருக்கலாம்:

• ஒவ்வொரு பங்கேற்பாளரும் தங்கள் சொந்த ரேண்டத்தை உருவாக்கி, அதிலிருந்து மற்ற பங்கேற்பாளர்களுக்கு பங்குகளை விநியோகிக்கிறார்கள்
• ஒவ்வொரு பங்கேற்பாளரும் மற்ற பங்கேற்பாளர்களின் ரகசியங்களில் தனது பகுதியை வெளிப்படுத்துகிறார்
• ஒரு பங்கேற்பாளரிடம் M பங்குகளை விட அதிகமாக இருந்தால், இந்த பங்கேற்பாளரின் எண்ணிக்கையை கணக்கிட முடியும், மேலும் வெளிப்படுத்தப்பட்ட பங்கேற்பாளர்களின் தொகுப்பைப் பொருட்படுத்தாமல் அது தனித்துவமாக இருக்கும்.
• வெளிப்படுத்தப்பட்ட ரேண்டம்களின் கலவையானது விரும்பிய PVRB ஆகும்

இங்கே, ஒரு தனிப்பட்ட பங்கேற்பாளர் நெறிமுறையின் முடிவுகளை இனி பாதிக்காது, சீரற்ற தன்மையை வெளிப்படுத்தும் வாசலின் சாதனை அவரை மட்டுமே சார்ந்துள்ளது. எனவே, இந்த நெறிமுறை, நெறிமுறையில் பணிபுரியும் RP களின் தேவையான விகிதத்தில் இருந்தால் மற்றும் கிடைக்கக்கூடியது, வேலை செய்கிறது, கிரிப்டோகிராஃபிக் வலிமைக்கான தேவைகளை செயல்படுத்துகிறது, மேலும் "கடைசி நடிகர்" பிரச்சனைக்கு எதிர்ப்புத் தெரிவிக்கிறது.

இது ஒரு சிறந்த தேர்வாக இருக்கலாம், Fiat-Shamir இரகசியப் பகிர்வின் அடிப்படையில் இந்த PVRB திட்டம் விவரிக்கப்பட்டுள்ளது. இந்த கட்டுரை. ஆனால், மேலே குறிப்பிட்டுள்ளபடி, நீங்கள் அதை பிளாக்செயினில் தலைகீழாகப் பயன்படுத்த முயற்சித்தால், தொழில்நுட்ப வரம்புகள் தோன்றும். EOS ஸ்மார்ட் ஒப்பந்தத்தில் நெறிமுறையை செயல்படுத்துவதற்கான ஒரு எடுத்துக்காட்டு மற்றும் அதன் மிக முக்கியமான பகுதி - வெளியிடப்பட்ட பங்கு பங்கேற்பாளரைச் சரிபார்க்கிறது: மணிக்கு. சான்று சரிபார்ப்புக்கு பல அளவிடல் பெருக்கல்கள் தேவை என்பதை நீங்கள் குறியீட்டிலிருந்து பார்க்கலாம், மேலும் பயன்படுத்தப்படும் எண்கள் மிகப் பெரியவை. பிளாக்செயின்களில், பிளாக்-தயாரிப்பாளர் பரிவர்த்தனையைச் செயல்படுத்தும் தருணத்தில் சரிபார்ப்பு நிகழ்கிறது என்பதை புரிந்து கொள்ள வேண்டும், பொதுவாக, எந்தவொரு பங்கேற்பாளரும் நெறிமுறையின் சரியான தன்மையை எளிதாக சரிபார்க்க வேண்டும், எனவே சரிபார்ப்பு செயல்பாட்டின் வேகத்திற்கான தேவைகள் மிகவும் தீவிரமானவை. . இந்த விருப்பத்தில், சரிபார்ப்பு பரிவர்த்தனை வரம்பிற்குள் (0.5 வினாடிகள்) பொருந்தாததால், விருப்பம் பயனற்றதாக மாறியது.

பொதுவாக, பிளாக்செயினில் எந்த மேம்பட்ட கிரிப்டோகிராஃபிக் திட்டங்களையும் பயன்படுத்துவதற்கு சரிபார்ப்பு திறன் மிக முக்கியமான தேவைகளில் ஒன்றாகும். ஆதாரங்களை உருவாக்குதல், செய்திகளைத் தயாரித்தல் - இந்த நடைமுறைகளை ஆஃப்-செயின் எடுத்து, உயர் செயல்திறன் கொண்ட கணினிகளில் செய்ய முடியும், ஆனால் சரிபார்ப்பைத் தவிர்க்க முடியாது - இது PVRB க்கு மற்றொரு முக்கியமான தேவை.

PVRB மற்றும் வாசல் கையொப்பங்கள்

இரகசியப் பகிர்வுத் திட்டத்தைப் பற்றி அறிந்த பிறகு, "வாசல்" என்ற முக்கிய சொல்லால் ஒன்றிணைக்கப்பட்ட நெறிமுறைகளின் முழு வகுப்பையும் நாங்கள் கண்டுபிடித்தோம். சில தகவல்களை வெளியிடுவதற்கு N இல் இருந்து M நேர்மையான பங்கேற்பாளர்களின் பங்கேற்பு தேவைப்படும்போது, ​​நேர்மையான பங்கேற்பாளர்களின் தொகுப்பு N இன் தன்னிச்சையான துணைக்குழுவாக இருக்கலாம், நாங்கள் "வாசல்" திட்டங்களைப் பற்றி பேசுகிறோம். "கடைசி நடிகர்" சிக்கலைச் சமாளிக்க அவர்கள் எங்களை அனுமதிக்கிறார்கள், இப்போது தாக்குபவர் தனது ரகசியத்தின் பகுதியை வெளிப்படுத்தவில்லை என்றால், மற்றொரு, நேர்மையான பங்கேற்பாளர் அவருக்காக அதைச் செய்வார். பங்கேற்பாளர்களில் சிலரால் நெறிமுறை நாசப்படுத்தப்பட்டாலும், இந்தத் திட்டங்கள் ஒரே ஒரு அர்த்தத்தில் உடன்பாட்டை அனுமதிக்கின்றன.

உறுதியான கையொப்பங்கள் மற்றும் நுழைவுத் திட்டங்களின் கலவையானது PVRB ஐ செயல்படுத்துவதற்கு மிகவும் வசதியான மற்றும் நம்பிக்கைக்குரிய திட்டத்தை உருவாக்குவதை சாத்தியமாக்கியது - இவை நிர்ணயமான வாசல் கையொப்பங்கள். இங்கே கட்டுரை த்ரெஷோல்ட் கையொப்பங்களின் பல்வேறு பயன்பாடுகளைப் பற்றி, இதோ மற்றொரு நல்ல ஒன்று நீண்ட வாசிப்பு டாஷிலிருந்து.

கடைசி கட்டுரை BLS கையொப்பங்களை விவரிக்கிறது (BLS என்பது Boneh-Lynn-Shacham, இங்கே கட்டுரை), இது புரோகிராமர்களுக்கு மிகவும் முக்கியமான மற்றும் மிகவும் வசதியான தரத்தைக் கொண்டுள்ளது - பொது, இரகசிய, பொது விசைகள் மற்றும் BLS கையொப்பங்கள் எளிமையான கணித செயல்பாடுகளைப் பயன்படுத்தி ஒன்றோடொன்று இணைக்கப்படலாம், அதே நேரத்தில் அவற்றின் சேர்க்கைகள் செல்லுபடியாகும் விசைகள் மற்றும் கையொப்பங்களாக இருக்கும், இது பலவற்றை எளிதாக ஒருங்கிணைக்க உங்களை அனுமதிக்கிறது. கையொப்பங்கள் ஒன்று மற்றும் பல பொது விசைகள் ஒன்று. அவை தீர்மானகரமானவை மற்றும் அதே உள்ளீட்டுத் தரவிற்கு ஒரே முடிவை உருவாக்குகின்றன. இந்த தரத்திற்கு நன்றி, BLS கையொப்பங்களின் சேர்க்கைகள் செல்லுபடியாகும் விசைகள் ஆகும், இது Mth இன் N பங்கேற்பாளர்கள் ஒரே ஒரு கையொப்பத்தை உருவாக்கும் ஒரு விருப்பத்தை செயல்படுத்த அனுமதிக்கிறது. பங்கேற்பாளர் .

த்ரெஷோல்ட் BLS கையொப்பங்களைக் கொண்ட திட்டத்தில், ஒவ்வொரு பங்கேற்பாளரும் BLS ஐப் பயன்படுத்தி கையொப்பமிடுவார்கள் (எடுத்துக்காட்டாக, முந்தைய ரேண்டம்), மேலும் பொதுவான நுழைவு கையொப்பம் விரும்பிய சீரற்றதாகும். BLS கையொப்பங்களின் கிரிப்டோகிராஃபிக் பண்புகள் சீரற்ற தரத்திற்கான தேவைகளை பூர்த்தி செய்கின்றன, நுழைவாயில் பகுதி "கடைசி-நடிகர்" க்கு எதிராக பாதுகாக்கிறது, மேலும் விசைகளின் தனித்துவமான ஒருங்கிணைப்பு பல சுவாரஸ்யமான வழிமுறைகளை செயல்படுத்துவதை சாத்தியமாக்குகிறது, எடுத்துக்காட்டாக, நெறிமுறை செய்திகளை திறம்பட ஒருங்கிணைக்க அனுமதிக்கிறது. .

எனவே, நீங்கள் உங்கள் பிளாக்செயினில் PVRB ஐ உருவாக்கினால், நீங்கள் பெரும்பாலும் BLS த்ரெஷோல்ட் கையொப்பத் திட்டத்துடன் முடிவடையும், பல திட்டங்கள் ஏற்கனவே அதைப் பயன்படுத்துகின்றன. எடுத்துக்காட்டாக, DFinity (இங்கே சுற்று செயல்படுத்தும் அளவுகோல், மற்றும் இங்கே சரிபார்க்கக்கூடிய இரகசியப் பகிர்வின் உதாரணத்தைச் செயல்படுத்துதல்), அல்லது Keep.network (அவற்றின் ரேண்டம் பெக்கான் இங்கே உள்ளது மஞ்சள் காகிதம், மற்றும் இங்கே உதாரணமாக நெறிமுறைக்கு சேவை செய்யும் ஸ்மார்ட் ஒப்பந்தம்).

PVRB ஐ செயல்படுத்துதல்

துரதிர்ஷ்டவசமாக, PVRB பிளாக்செயின்களில் செயல்படுத்தப்பட்ட ஒரு ஆயத்த நெறிமுறையை நாங்கள் இன்னும் பார்க்கவில்லை, அது அதன் பாதுகாப்பு மற்றும் நிலைத்தன்மையை நிரூபித்துள்ளது. நெறிமுறைகள் தயாராக இருந்தாலும், தற்போதுள்ள தீர்வுகளுக்கு தொழில்நுட்ப ரீதியாக அவற்றைப் பயன்படுத்துவது எளிதானது அல்ல. மையப்படுத்தப்பட்ட அமைப்புகளுக்கு, PVRB அர்த்தமற்றது, மேலும் பரவலாக்கப்பட்டவை அனைத்து கணினி வளங்களிலும் கண்டிப்பாக வரையறுக்கப்பட்டுள்ளன: CPU, நினைவகம், சேமிப்பு, I/O. PVRBயை வடிவமைத்தல் என்பது, குறைந்தபட்சம் சில சாத்தியமான பிளாக்செயினுக்கான அனைத்து தேவைகளையும் பூர்த்தி செய்யும் வகையில் ஏதாவது ஒன்றை உருவாக்குவதற்காக பல்வேறு நெறிமுறைகளின் கலவையாகும். ஒரு நெறிமுறை மிகவும் திறமையாகக் கணக்கிடுகிறது, ஆனால் RP களுக்கு இடையில் அதிக செய்திகள் தேவை, மற்றொன்றுக்கு மிகக் குறைவான செய்திகள் தேவை, ஆனால் ஒரு ஆதாரத்தை உருவாக்குவது பல்லாயிரக்கணக்கான நிமிடங்கள் அல்லது மணிநேரம் கூட எடுக்கும் ஒரு பணியாக இருக்கலாம்.

தரமான PVRBஐத் தேர்ந்தெடுக்கும்போது நீங்கள் கருத்தில் கொள்ள வேண்டிய காரணிகளை நான் பட்டியலிடுகிறேன்:

• கிரிப்டோகிராஃபிக் வலிமை. உங்கள் PVRB கண்டிப்பாக பக்கச்சார்பற்றதாக இருக்க வேண்டும், ஒரு பிட்டையும் கட்டுப்படுத்தும் திறன் இல்லை. சில திட்டங்களில் இது அவ்வாறு இல்லை, எனவே கிரிப்டோகிராஃபரை அழைக்கவும்
• "கடைசி நடிகர்" பிரச்சனை. ஒன்று அல்லது அதற்கு மேற்பட்ட ஆர்பிகளைக் கட்டுப்படுத்தும் தாக்குபவர் இரண்டு விளைவுகளில் ஒன்றைத் தேர்வுசெய்யும் தாக்குதல்களுக்கு உங்கள் PVRB எதிர்ப்புத் திறன் கொண்டதாக இருக்க வேண்டும்.
• புரோட்டோகால் நாசவேலை பிரச்சனை. ஒன்று அல்லது அதற்கு மேற்பட்ட ஆர்பிகளைக் கட்டுப்படுத்தும் தாக்குபவர் தற்செயலாக வேண்டுமா வேண்டாமா என்பதைத் தீர்மானிக்கும் தாக்குதல்களுக்கு உங்கள் PVRB எதிர்ப்புத் திறன் கொண்டதாக இருக்க வேண்டும்.
• செய்திகளின் எண்ணிக்கையில் சிக்கல். உங்கள் RP கள் பிளாக்செயினுக்கு குறைந்தபட்சம் செய்திகளை அனுப்ப வேண்டும் மற்றும் "நான் சில தகவல்களை அனுப்பினேன், ஒரு குறிப்பிட்ட பங்கேற்பாளரின் பதிலுக்காக காத்திருக்கிறேன்" போன்ற சூழ்நிலைகள் போன்ற ஒத்திசைவான செயல்களை முடிந்தவரை தவிர்க்க வேண்டும். p2p நெட்வொர்க்குகளில், குறிப்பாக புவியியல் ரீதியாக சிதறடிக்கப்பட்ட நெட்வொர்க்குகளில், விரைவான பதிலை நீங்கள் நம்பக்கூடாது
• கணக்கீட்டு சிக்கலான சிக்கல். பிவிஆர்பி ஆன்-செயினின் எந்த நிலையையும் சரிபார்ப்பது மிகவும் எளிதாக இருக்க வேண்டும், ஏனெனில் இது நெட்வொர்க்கின் அனைத்து முழு வாடிக்கையாளர்களாலும் செய்யப்படுகிறது. ஒரு ஸ்மார்ட் ஒப்பந்தத்தைப் பயன்படுத்தி செயல்படுத்தப்பட்டால், வேகத் தேவைகள் மிகவும் கண்டிப்பானவை
• அணுகல் மற்றும் வாழ்வாதாரத்தின் பிரச்சனை. நெட்வொர்க்கின் ஒரு பகுதி குறிப்பிட்ட காலத்திற்கு கிடைக்காமல் போகும் மற்றும் RP இன் ஒரு பகுதி வேலை செய்வதை நிறுத்தும் சூழ்நிலைகளுக்கு உங்கள் PVRB பாடுபட வேண்டும்.
• நம்பகமான அமைவு மற்றும் ஆரம்ப விசை விநியோகத்தின் சிக்கல். உங்கள் PVRB நெறிமுறையின் முதன்மை அமைப்பைப் பயன்படுத்தினால், இது ஒரு பெரிய மற்றும் தீவிரமான கதை. இங்கே உதாரணமாக. நெறிமுறையைத் தொடங்குவதற்கு முன் பங்கேற்பாளர்கள் ஒருவருக்கொருவர் தங்கள் விசைகளைச் சொல்ல வேண்டும் என்றால், பங்கேற்பாளர்களின் கலவை மாறினால் இதுவும் ஒரு சிக்கலாகும்
• வளர்ச்சி சிக்கல்கள். தேவையான மொழிகளில் நூலகங்களின் இருப்பு, அவற்றின் பாதுகாப்பு மற்றும் செயல்திறன், விளம்பரம், சிக்கலான சோதனைகள் போன்றவை.

எடுத்துக்காட்டாக, வாசல் BLS கையொப்பங்கள் குறிப்பிடத்தக்க சிக்கலைக் கொண்டுள்ளன - வேலை செய்யத் தொடங்குவதற்கு முன், பங்கேற்பாளர்கள் ஒருவருக்கொருவர் விசைகளை விநியோகிக்க வேண்டும், ஒரு குழுவை ஒழுங்கமைக்க வேண்டும். இதன் பொருள், ஒரு பரவலாக்கப்பட்ட நெட்வொர்க்கில் குறைந்தபட்சம் ஒரு சுற்று பரிமாற்றம் காத்திருக்க வேண்டும், மேலும் உருவாக்கப்பட்ட ரேண்ட், எடுத்துக்காட்டாக, கேம்களில் அவசியம், கிட்டத்தட்ட உண்மையான நேரத்தில், இந்த கட்டத்தில் நெறிமுறையை நாசப்படுத்துவது சாத்தியமாகும். , மற்றும் வாசல் திட்டத்தின் நன்மைகள் இழக்கப்படுகின்றன. இந்த சிக்கல் ஏற்கனவே முந்தையதை விட எளிமையானது, ஆனால் இன்னும் நுழைவாயில் குழுக்களை உருவாக்குவதற்கான ஒரு தனி செயல்முறையை உருவாக்க வேண்டும், இது பொருளாதார ரீதியாக பாதுகாக்கப்பட வேண்டும், வைப்புத்தொகை மற்றும் பங்கேற்பாளர்களிடமிருந்து நிதிகளை திரும்பப் பெறுதல் (குறைத்தல்) நெறிமுறை. மேலும், ஏற்றுக்கொள்ளக்கூடிய அளவிலான பாதுகாப்பைக் கொண்ட BLS சரிபார்ப்பு வெறுமனே பொருந்தாது, எடுத்துக்காட்டாக, நிலையான EOS அல்லது Ethereum பரிவர்த்தனைக்கு - சரிபார்ப்புக்கு போதுமான நேரம் இல்லை. ஒப்பந்தக் குறியீடு WebAssembly அல்லது EVM ஆகும், இது மெய்நிகர் இயந்திரத்தால் செயல்படுத்தப்படுகிறது. கிரிப்டோகிராஃபிக் செயல்பாடுகள் பூர்வீகமாக (இன்னும்) செயல்படுத்தப்படவில்லை, மேலும் வழக்கமான கிரிப்டோகிராஃபிக் லைப்ரரிகளை விட பத்து மடங்கு மெதுவாக வேலை செய்கிறது. பல நெறிமுறைகள் முக்கிய அளவை அடிப்படையாகக் கொண்ட தேவைகளை பூர்த்தி செய்யவில்லை, எடுத்துக்காட்டாக RSA க்கான 1024 மற்றும் 2048 பிட்கள், Bitcoin மற்றும் Ethereum இல் உள்ள நிலையான பரிவர்த்தனை கையொப்பத்தை விட 4-8 மடங்கு பெரியது.

வெவ்வேறு நிரலாக்க மொழிகளில் செயலாக்கங்களின் இருப்பு ஒரு பாத்திரத்தை வகிக்கிறது - அவற்றில் சில உள்ளன, குறிப்பாக புதிய நெறிமுறைகளுக்கு. ஒருமித்த கருத்துடன் ஒருங்கிணைக்கும் விருப்பத்திற்கு பிளாட்ஃபார்ம் மொழியில் ஒரு நெறிமுறையை எழுத வேண்டும், எனவே நீங்கள் Go for geth, Rust for Parity, C++ இல் EOS இல் குறியீட்டைத் தேட வேண்டும். எல்லோரும் ஜாவாஸ்கிரிப்ட் குறியீட்டைத் தேட வேண்டும், மேலும் ஜாவாஸ்கிரிப்ட் மற்றும் கிரிப்டோகிராஃபி குறிப்பாக நெருங்கிய நண்பர்கள் இல்லை என்பதால், WebAssembly உதவும், இது இப்போது நிச்சயமாக அடுத்த முக்கியமான இணைய தரநிலை என்று கூறுகிறது.

முடிவுக்கு

முந்தையதை நான் நம்புகிறேன் கட்டுரை பரவலாக்கப்பட்ட நெட்வொர்க்குகளின் வாழ்க்கையின் பல அம்சங்களுக்கு பிளாக்செயினில் சீரற்ற எண்களை உருவாக்குவது மிகவும் முக்கியமானது என்பதை நான் உங்களை நம்ப வைக்க முடிந்தது, மேலும் இந்த பணி மிகவும் லட்சியமானது மற்றும் கடினமானது என்பதை நான் காண்பித்தேன், ஆனால் நல்ல தீர்வுகள் ஏற்கனவே உள்ளன. பொதுவாக, நெறிமுறையின் இறுதி வடிவமைப்பு, அமைப்பு முதல் தவறு எமுலேஷன் வரை அனைத்து அம்சங்களையும் கணக்கில் எடுத்துக் கொள்ளும் பாரிய சோதனைகளை நடத்திய பின்னரே சாத்தியமாகும், எனவே நீங்கள் குழு ஒயிட்பேப்பர்கள் மற்றும் கட்டுரைகளில் ஆயத்த சமையல் குறிப்புகளைக் கண்டறிய வாய்ப்பில்லை, நாங்கள் நிச்சயமாக மாட்டோம். அடுத்த ஓரிரு வருடங்களில் முடிவு செய்து "இப்படிச் செய்யுங்கள், சரியாகச் செய்யுங்கள்" என்று எழுதுங்கள்.

வருகிறேன், பிளாக்செயினில் எங்கள் PVRB உருவாக்கப்படுகிறது பீச், த்ரெஷோல்ட் BLS கையொப்பங்களைப் பயன்படுத்துவதில் நாங்கள் முடிவு செய்துள்ளோம், ஏற்றுக்கொள்ளக்கூடிய அளவிலான பாதுகாப்பைக் கொண்ட ஸ்மார்ட் ஒப்பந்தங்களில் சரிபார்ப்பு இன்னும் சாத்தியமில்லாததால், ஒருமித்த நிலையில் PVRB ஐ செயல்படுத்த திட்டமிட்டுள்ளோம். ஒரே நேரத்தில் இரண்டு திட்டங்களைப் பயன்படுத்துவது சாத்தியம்: முதலாவதாக, நீண்ட கால சீரற்ற_விதையை உருவாக்க விலையுயர்ந்த ரகசியப் பகிர்வு, பின்னர் அதை உயர் அதிர்வெண் சீரற்ற உருவாக்கத்திற்கான அடிப்படையாகப் பயன்படுத்துகிறோம். திட்டங்களில் ஒன்று. துரதிர்ஷ்டவசமாக, நெறிமுறை என்னவாக இருக்கும் என்பதை முன்கூட்டியே சொல்ல முடியாது; ஒரே நல்ல விஷயம் என்னவென்றால், அறிவியலைப் போலவே, பொறியியல் சிக்கல்களிலும், எதிர்மறையான முடிவும் ஒரு விளைவாகும், மேலும் சிக்கலைத் தீர்க்க ஒவ்வொரு புதிய முயற்சியும் மற்றொரு படியாகும். பிரச்சனையில் ஈடுபட்டுள்ள அனைவரின் ஆய்வு. வணிகத் தேவைகளைப் பூர்த்தி செய்ய, ஒரு குறிப்பிட்ட நடைமுறைச் சிக்கலைத் தீர்க்கிறோம் - கேமிங் அப்ளிகேஷன்களை நம்பகமான என்ட்ரோபி மூலத்துடன் வழங்குகிறோம், எனவே பிளாக்செயினிலும் கவனம் செலுத்த வேண்டும், குறிப்பாக சங்கிலி இறுதி மற்றும் நெட்வொர்க் ஆளுமை சிக்கல்கள்.

உண்மையான பயன்பாடுகள், பல தணிக்கைகள், சுமைகள் மற்றும் நிச்சயமாக உண்மையான தாக்குதல்களால் சோதிக்கப்படுவதற்கு போதுமான நேரம் பயன்படுத்தப்பட்ட பிளாக்செயின்களில் நிரூபிக்கப்பட்ட எதிர்ப்பு PVRB ஐ நாம் இன்னும் காணவில்லை என்றாலும், சாத்தியமான பாதைகளின் எண்ணிக்கை அதை உறுதிப்படுத்துகிறது. ஒரு தீர்வு உள்ளது, மேலும் இந்த வழிமுறைகள் இறுதியில் சிக்கலை தீர்க்கும். முடிவுகளைப் பகிர்ந்து கொள்வதில் நாங்கள் மகிழ்ச்சியடைவோம் மற்றும் பொறியாளர்கள் ஒரே ரேக்கில் இரண்டு முறை அடியெடுத்து வைக்காததை அனுமதிக்கும் கட்டுரைகள் மற்றும் குறியீட்டிற்காக இந்த சிக்கலில் பணிபுரியும் பிற குழுக்களுக்கு நன்றி கூறுவோம்.

எனவே, பரவலாக்கப்பட்ட சீரற்ற முறையில் வடிவமைக்கும் ஒரு புரோகிராமரை நீங்கள் சந்திக்கும் போது, ​​கவனமாகவும் அக்கறையுடனும் இருக்கவும், தேவைப்பட்டால் உளவியல் உதவியை வழங்கவும் :)

ஆதாரம்: www.habr.com