ಪರಿಚಯ

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

ಕ್ರಿಪ್ಟೋಗ್ರಫಿಯಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಬಲವಾದ ಸೈಫರ್‌ನ ಪರಿಕಲ್ಪನೆಯಂತೆ, ನಿಜವಾದ "ಸಾರ್ವಜನಿಕವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದಾದ ರಾಂಡಮ್ ಬೀಕನ್" (ಇನ್ನು ಮುಂದೆ PVRB) ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಆದರ್ಶ ಯೋಜನೆಗೆ ಸಾಧ್ಯವಾದಷ್ಟು ಹತ್ತಿರವಾಗಲು ಪ್ರಯತ್ನಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ನೈಜ ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ ಇದು ಅದರ ಶುದ್ಧ ರೂಪದಲ್ಲಿ ಅನ್ವಯಿಸುವುದಿಲ್ಲ: ಒಂದು ಬಿಟ್‌ನಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಒಪ್ಪಿಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ, ಹಲವು ಸುತ್ತುಗಳು ಇರಬೇಕು ಮತ್ತು ಎಲ್ಲಾ ಸಂದೇಶಗಳು ಸಂಪೂರ್ಣವಾಗಿ ವೇಗವಾಗಿರಬೇಕು ಮತ್ತು ಯಾವಾಗಲೂ ತಲುಪಿಸಬೇಕು. ಸಹಜವಾಗಿ, ಇದು ನೈಜ ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿ ಅಲ್ಲ. ಆದ್ದರಿಂದ, ಆಧುನಿಕ ಬ್ಲಾಕ್‌ಚೈನ್‌ಗಳಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಕಾರ್ಯಗಳಿಗಾಗಿ PVRB ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವಾಗ, ಪರಿಣಾಮವಾಗಿ ಉಂಟಾಗುವ ಯಾದೃಚ್ಛಿಕತೆ ಮತ್ತು ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಬಲವನ್ನು ನಿಯಂತ್ರಿಸುವ ಅಸಾಧ್ಯತೆಯ ಜೊತೆಗೆ, ಇನ್ನೂ ಅನೇಕ ಸಂಪೂರ್ಣವಾಗಿ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸುತ್ತವೆ.

PVRB ಗಾಗಿ, ಬ್ಲಾಕ್‌ಚೈನ್ ಮೂಲಭೂತವಾಗಿ ಸಂವಹನ ಮಾಧ್ಯಮವಾಗಿದ್ದು, ಇದರಲ್ಲಿ ಸಂದೇಶಗಳು = ವಹಿವಾಟುಗಳು. ನೆಟ್‌ವರ್ಕ್ ಸಮಸ್ಯೆಗಳು, ಸಂದೇಶಗಳ ವಿತರಣೆಯಾಗದಿರುವುದು, ಮಿಡಲ್‌ವೇರ್‌ನೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳಿಂದ ಭಾಗಶಃ ಅಮೂರ್ತವಾಗಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ - ಈ ಎಲ್ಲಾ ಅಪಾಯಗಳನ್ನು ವಿಕೇಂದ್ರೀಕೃತ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಊಹಿಸಲಾಗಿದೆ ಮತ್ತು PVRB ಗಾಗಿ ಅದರ ಮುಖ್ಯ ಮೌಲ್ಯವು ಈಗಾಗಲೇ ಕಳುಹಿಸಲಾದ ವಹಿವಾಟನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳಲು ಅಥವಾ ಭ್ರಷ್ಟಗೊಳಿಸಲು ಅಸಮರ್ಥತೆಯಾಗಿದೆ - ಇದು ಮಾಡುತ್ತದೆ ಭಾಗವಹಿಸುವವರು ಒಮ್ಮತದ ಮೇಲೆ ಯಶಸ್ವಿ ದಾಳಿ ನಡೆಸದ ಹೊರತು ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಭಾಗವಹಿಸಲು ನಿರಾಕರಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ. ಈ ಮಟ್ಟದ ಭದ್ರತೆಯು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆ, ಆದ್ದರಿಂದ PVRB ಮುಖ್ಯ ಬ್ಲಾಕ್‌ಚೈನ್ ಸರಪಳಿಯಂತೆಯೇ ಭಾಗವಹಿಸುವವರ ಒಪ್ಪಂದಕ್ಕೆ ನಿರೋಧಕವಾಗಿರಬೇಕು. ಅಲ್ಲದೆ, PVRB ಮುಖ್ಯ ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಒಪ್ಪಿದರೆ, ಯಾದೃಚ್ಛಿಕ ಫಲಿತಾಂಶದ ಏಕೈಕ ನ್ಯಾಯೋಚಿತವನ್ನು ಸಹ ಒಪ್ಪಿಕೊಂಡರೂ ಸಹ, PVRB ಒಮ್ಮತದ ಭಾಗವಾಗಿರಬೇಕು ಎಂದು ಇದು ಸುಳಿವು ನೀಡುತ್ತದೆ. ಅಥವಾ, PVRB ಸರಳವಾಗಿ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದದ ಮೂಲಕ ಕಾರ್ಯಗತಗೊಳಿಸಲಾದ ಸ್ವತಂತ್ರ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದ್ದು ಅದು ಬ್ಲಾಕ್‌ಚೈನ್ ಮತ್ತು ಬ್ಲಾಕ್‌ಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಅಸಮಕಾಲಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಎರಡೂ ವಿಧಾನಗಳು ಅವುಗಳ ಅನುಕೂಲಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳನ್ನು ಹೊಂದಿವೆ, ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಆಯ್ಕೆಯು ಅತ್ಯಂತ ಕ್ಷುಲ್ಲಕವಲ್ಲ.

PVRB ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಎರಡು ಮಾರ್ಗಗಳು

PVRB ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಎರಡು ಆಯ್ಕೆಗಳನ್ನು ನಾವು ಹೆಚ್ಚು ವಿವರವಾಗಿ ವಿವರಿಸೋಣ - ಬ್ಲಾಕ್‌ಚೈನ್‌ನಿಂದ ಸ್ವತಂತ್ರವಾದ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದವನ್ನು ಬಳಸಿಕೊಂಡು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸ್ವತಂತ್ರ ಆವೃತ್ತಿ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾದ ಒಮ್ಮತ-ಸಂಯೋಜಿತ ಆವೃತ್ತಿ, ಅದರ ಪ್ರಕಾರ ನೆಟ್‌ವರ್ಕ್ ಬ್ಲಾಕ್‌ಚೈನ್ ಅನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ವಹಿವಾಟುಗಳನ್ನು ಸೇರಿಸಬೇಕು. ಎಲ್ಲಾ ಸಂದರ್ಭಗಳಲ್ಲಿ, ನಾನು ಜನಪ್ರಿಯ ಬ್ಲಾಕ್‌ಚೈನ್ ಎಂಜಿನ್‌ಗಳನ್ನು ಅರ್ಥೈಸುತ್ತೇನೆ: ಎಥೆರಿಯಮ್, ಇಒಎಸ್ ಮತ್ತು ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುವ ಮತ್ತು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ರೀತಿಯಲ್ಲಿ ಅವುಗಳನ್ನು ಹೋಲುವ ಎಲ್ಲಾ.

ಸ್ವತಂತ್ರ ಒಪ್ಪಂದ

ಈ ಆವೃತ್ತಿಯಲ್ಲಿ, PVRB ಯಾದೃಚ್ಛಿಕ ನಿರ್ಮಾಪಕರ ವಹಿವಾಟುಗಳನ್ನು ಸ್ವೀಕರಿಸುವ ಒಂದು ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದವಾಗಿದೆ (ಇನ್ನು ಮುಂದೆ RP ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ), ಅವುಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುತ್ತದೆ, ಫಲಿತಾಂಶಗಳನ್ನು ಸಂಯೋಜಿಸುತ್ತದೆ ಮತ್ತು ಪರಿಣಾಮವಾಗಿ, ಈ ಒಪ್ಪಂದದಿಂದ ಯಾವುದೇ ಬಳಕೆದಾರರು ಸ್ವೀಕರಿಸಬಹುದಾದ ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯವನ್ನು ತಲುಪುತ್ತದೆ. ಈ ಮೌಲ್ಯವನ್ನು ಒಪ್ಪಂದದಲ್ಲಿ ನೇರವಾಗಿ ಸಂಗ್ರಹಿಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಫಲಿತಾಂಶದ ಯಾದೃಚ್ಛಿಕದ ಒಂದು ಮತ್ತು ಕೇವಲ ಒಂದು ಮೌಲ್ಯವನ್ನು ನಿರ್ಣಾಯಕವಾಗಿ ಪಡೆಯಬಹುದಾದ ಡೇಟಾದಿಂದ ಮಾತ್ರ ಪ್ರತಿನಿಧಿಸಲಾಗುತ್ತದೆ. ಈ ಯೋಜನೆಯಲ್ಲಿ, RP ಗಳು ಬ್ಲಾಕ್‌ಚೈನ್‌ನ ಬಳಕೆದಾರರಾಗಿದ್ದಾರೆ ಮತ್ತು ಪೀಳಿಗೆಯ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಭಾಗವಹಿಸಲು ಯಾರಾದರೂ ಅನುಮತಿಸಬಹುದು.

ಸ್ವತಂತ್ರ ಒಪ್ಪಂದದ ಆಯ್ಕೆಯು ಉತ್ತಮವಾಗಿದೆ:

• ಪೋರ್ಟಬಿಲಿಟಿ (ಒಪ್ಪಂದಗಳನ್ನು ಬ್ಲಾಕ್‌ಚೈನ್‌ನಿಂದ ಬ್ಲಾಕ್‌ಚೈನ್‌ಗೆ ಎಳೆಯಬಹುದು)
• ಅನುಷ್ಠಾನ ಮತ್ತು ಪರೀಕ್ಷೆಯ ಸುಲಭ (ಒಪ್ಪಂದಗಳನ್ನು ಬರೆಯಲು ಮತ್ತು ಪರೀಕ್ಷಿಸಲು ಸುಲಭ)
• ಆರ್ಥಿಕ ಯೋಜನೆಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವಲ್ಲಿ ಅನುಕೂಲ (ನಿಮ್ಮ ಸ್ವಂತ ಟೋಕನ್ ಅನ್ನು ತಯಾರಿಸುವುದು ಸುಲಭ, ಅದರ ತರ್ಕವು PVRB ಯ ಉದ್ದೇಶಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ)
• ಈಗಾಗಲೇ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಬ್ಲಾಕ್‌ಚೈನ್‌ಗಳಲ್ಲಿ ಪ್ರಾರಂಭಿಸುವ ಸಾಧ್ಯತೆ

ಇದು ಅನಾನುಕೂಲಗಳನ್ನು ಸಹ ಹೊಂದಿದೆ:

• ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳು, ವಹಿವಾಟಿನ ಪ್ರಮಾಣ ಮತ್ತು ಸಂಗ್ರಹಣೆಯ ಮೇಲೆ ಬಲವಾದ ಮಿತಿಗಳು (ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, cpu/mem/io)
• ಒಪ್ಪಂದದೊಳಗಿನ ಕಾರ್ಯಾಚರಣೆಗಳ ಮೇಲಿನ ನಿರ್ಬಂಧಗಳು (ಎಲ್ಲಾ ಸೂಚನೆಗಳು ಲಭ್ಯವಿಲ್ಲ, ಬಾಹ್ಯ ಗ್ರಂಥಾಲಯಗಳನ್ನು ಸಂಪರ್ಕಿಸುವುದು ಕಷ್ಟ)
• ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ಒಳಗೊಂಡಿರುವ ವಹಿವಾಟುಗಳಿಗಿಂತ ವೇಗವಾಗಿ ಸಂದೇಶ ಕಳುಹಿಸುವಿಕೆಯನ್ನು ಸಂಘಟಿಸಲು ಅಸಮರ್ಥತೆ

ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ರನ್ ಮಾಡಬೇಕಾದ PVRB ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಈ ಆಯ್ಕೆಯು ಸೂಕ್ತವಾಗಿದೆ, ಸಂಕೀರ್ಣ ಕ್ರಿಪ್ಟೋಗ್ರಫಿಯನ್ನು ಹೊಂದಿಲ್ಲ ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಸಂವಹನಗಳ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ.

ಒಮ್ಮತ-ಸಂಯೋಜಿತ

ಈ ಆವೃತ್ತಿಯಲ್ಲಿ, PVRB ಅನ್ನು ಬ್ಲಾಕ್‌ಚೈನ್ ನೋಡ್ ಕೋಡ್‌ನಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ, ಬ್ಲಾಕ್‌ಚೈನ್ ನೋಡ್‌ಗಳ ನಡುವಿನ ಸಂದೇಶಗಳ ವಿನಿಮಯದೊಂದಿಗೆ ಅಂತರ್ನಿರ್ಮಿತ ಅಥವಾ ಸಮಾನಾಂತರವಾಗಿ ಚಾಲನೆಯಲ್ಲಿದೆ. ಪ್ರೋಟೋಕಾಲ್‌ನ ಫಲಿತಾಂಶಗಳನ್ನು ನೇರವಾಗಿ ಉತ್ಪಾದಿಸಿದ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಬರೆಯಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಸಂದೇಶಗಳನ್ನು ನೋಡ್‌ಗಳ ನಡುವೆ p2p ನೆಟ್‌ವರ್ಕ್ ಮೂಲಕ ಕಳುಹಿಸಲಾಗುತ್ತದೆ. ಪ್ರೋಟೋಕಾಲ್ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಬರೆಯಬೇಕಾದ ಸಂಖ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗುವುದರಿಂದ, ನೆಟ್‌ವರ್ಕ್ ಅವುಗಳ ಮೇಲೆ ಒಮ್ಮತವನ್ನು ತಲುಪಬೇಕು. ಇದರರ್ಥ ವ್ಯವಹಾರಗಳಂತಹ PVRB ಸಂದೇಶಗಳನ್ನು ನೋಡ್‌ಗಳಿಂದ ಮೌಲ್ಯೀಕರಿಸಬೇಕು ಮತ್ತು ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಸೇರಿಸಬೇಕು ಇದರಿಂದ ಯಾವುದೇ ನೆಟ್‌ವರ್ಕ್ ಭಾಗವಹಿಸುವವರು PVRB ಪ್ರೋಟೋಕಾಲ್‌ನ ಅನುಸರಣೆಯನ್ನು ಮೌಲ್ಯೀಕರಿಸಬಹುದು. ಇದು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ನಮಗೆ ಸ್ಪಷ್ಟವಾದ ಪರಿಹಾರಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ - ನೆಟ್‌ವರ್ಕ್ ಬ್ಲಾಕ್ ಮತ್ತು ಅದರಲ್ಲಿನ ವಹಿವಾಟುಗಳ ಬಗ್ಗೆ ಒಮ್ಮತವನ್ನು ಒಪ್ಪಿಕೊಂಡರೆ, ನಂತರ PVRB ಒಮ್ಮತದ ಭಾಗವಾಗಿರಬೇಕು ಮತ್ತು ಅದ್ವಿತೀಯ ಪ್ರೋಟೋಕಾಲ್ ಅಲ್ಲ. ಇಲ್ಲದಿದ್ದರೆ, ಒಮ್ಮತದ ದೃಷ್ಟಿಕೋನದಿಂದ ಬ್ಲಾಕ್ ಮಾನ್ಯವಾಗಿರುವ ಸಾಧ್ಯತೆಯಿದೆ, ಆದರೆ PVRB ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅನುಸರಿಸಲಾಗುವುದಿಲ್ಲ ಮತ್ತು PVRB ದೃಷ್ಟಿಕೋನದಿಂದ ಬ್ಲಾಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲಾಗುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ "ಒಮ್ಮತ-ಸಂಯೋಜಿತ" ಆಯ್ಕೆಯನ್ನು ಆರಿಸಿದರೆ, PVRB ಒಮ್ಮತದ ಪ್ರಮುಖ ಭಾಗವಾಗುತ್ತದೆ.

ನೆಟ್‌ವರ್ಕ್ ಒಮ್ಮತದ ಮಟ್ಟದಲ್ಲಿ PVRB ಅಳವಡಿಕೆಗಳನ್ನು ವಿವರಿಸುವಾಗ, ಯಾವುದೇ ರೀತಿಯಿಂದಲೂ ಅಂತಿಮ ಸಮಸ್ಯೆಗಳನ್ನು ತಪ್ಪಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಂತಿಮತೆಯು ನಿರ್ಣಾಯಕ ಒಮ್ಮತದಲ್ಲಿ ಬಳಸಲಾಗುವ ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯಾಗಿದ್ದು ಅದು ಒಂದು ಬ್ಲಾಕ್‌ನಲ್ಲಿ ಲಾಕ್ ಆಗುತ್ತದೆ (ಮತ್ತು ಅದಕ್ಕೆ ಕಾರಣವಾಗುವ ಸರಪಳಿ) ಇದು ಅಂತಿಮವಾಗಿರುತ್ತದೆ ಮತ್ತು ಸಮಾನಾಂತರ ಫೋರ್ಕ್ ಸಂಭವಿಸಿದರೂ ಅದನ್ನು ಎಂದಿಗೂ ಎಸೆಯಲಾಗುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಬಿಟ್‌ಕಾಯಿನ್‌ನಲ್ಲಿ ಅಂತಹ ಕಾರ್ಯವಿಧಾನವಿಲ್ಲ - ನೀವು ಹೆಚ್ಚಿನ ಸಂಕೀರ್ಣತೆಯ ಸರಪಳಿಯನ್ನು ಪ್ರಕಟಿಸಿದರೆ, ಅದು ಸರಪಳಿಗಳ ಉದ್ದವನ್ನು ಲೆಕ್ಕಿಸದೆ ಯಾವುದೇ ಕಡಿಮೆ ಸಂಕೀರ್ಣವನ್ನು ಬದಲಾಯಿಸುತ್ತದೆ. ಮತ್ತು EOS ನಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಅಂತಿಮವಾದವುಗಳು ಕೊನೆಯ ಬದಲಾಯಿಸಲಾಗದ ಬ್ಲಾಕ್‌ಗಳು ಎಂದು ಕರೆಯಲ್ಪಡುತ್ತವೆ, ಇದು ಸರಾಸರಿ ಪ್ರತಿ 432 ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ (12*21 + 12*15, ಪೂರ್ವ-ಮತ + ಪೂರ್ವ ಬದ್ಧತೆ). ಈ ಪ್ರಕ್ರಿಯೆಯು ಮೂಲಭೂತವಾಗಿ 2/3 ಬ್ಲಾಕ್-ನಿರ್ಮಾಪಕರು (ಇನ್ನು ಮುಂದೆ BP ಎಂದು ಉಲ್ಲೇಖಿಸಲಾಗುತ್ತದೆ) ಸಹಿಗಳಿಗಾಗಿ ಕಾಯುತ್ತಿದೆ. ಕೊನೆಯ LIB ಗಿಂತ ಹಳೆಯದಾದ ಫೋರ್ಕ್‌ಗಳು ಕಾಣಿಸಿಕೊಂಡಾಗ, ಅವುಗಳನ್ನು ಸರಳವಾಗಿ ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ. ಈ ಕಾರ್ಯವಿಧಾನವು ವಹಿವಾಟನ್ನು ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ ಎಂದು ಖಾತರಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ ಮತ್ತು ಆಕ್ರಮಣಕಾರರು ಯಾವುದೇ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದ್ದರೂ ಅದನ್ನು ಎಂದಿಗೂ ಹಿಂತಿರುಗಿಸಲಾಗುವುದಿಲ್ಲ. ಅಲ್ಲದೆ, ಅಂತಿಮ ಬ್ಲಾಕ್‌ಗಳು ಹೈಪರ್‌ಲೆಡ್ಜರ್, ಟೆಂಡರ್‌ಮಿಂಟ್ ಮತ್ತು ಇತರ pBFT-ಆಧಾರಿತ ಒಮ್ಮತಗಳಲ್ಲಿ 2/3 BP ಯಿಂದ ಸಹಿ ಮಾಡಿದ ಬ್ಲಾಕ್‌ಗಳಾಗಿವೆ. ಅಲ್ಲದೆ, ಅಂತಿಮತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಒಮ್ಮತಕ್ಕೆ ಆಡ್-ಆನ್ ಮಾಡಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದು ಬ್ಲಾಕ್‌ಗಳ ಉತ್ಪಾದನೆ ಮತ್ತು ಪ್ರಕಟಣೆಯೊಂದಿಗೆ ಅಸಮಕಾಲಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇಲ್ಲಿ ಒಂದು ಒಳ್ಳೆಯದು ಲೇಖನ Ethereum ನಲ್ಲಿ ಅಂತಿಮತೆಯ ಬಗ್ಗೆ.

ಬಳಕೆದಾರರಿಗೆ ಅಂತಿಮತೆಯು ಅತ್ಯಂತ ಮುಖ್ಯವಾಗಿದೆ, ಅದು ಇಲ್ಲದೆ ತಮ್ಮನ್ನು ತಾವು "ಡಬಲ್ ಖರ್ಚು" ದಾಳಿಯ ಬಲಿಪಶುಗಳನ್ನು ಕಂಡುಕೊಳ್ಳಬಹುದು, ಅಲ್ಲಿ BP "ಹಿಡಿಯುತ್ತದೆ" ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಉತ್ತಮ ವಹಿವಾಟನ್ನು "ನೋಡಿದ" ನಂತರ ಅವುಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತದೆ. ಯಾವುದೇ ಅಂತಿಮತೆ ಇಲ್ಲದಿದ್ದರೆ, ನಂತರ ಪ್ರಕಟವಾದ ಫೋರ್ಕ್ ಬ್ಲಾಕ್ ಅನ್ನು "ಒಳ್ಳೆಯ" ವಹಿವಾಟು ಜೊತೆಗೆ "ಕೆಟ್ಟ" ಫೋರ್ಕ್ನಿಂದ ಬದಲಾಯಿಸುತ್ತದೆ, ಇದರಲ್ಲಿ ಅದೇ ಹಣವನ್ನು ಆಕ್ರಮಣಕಾರರ ವಿಳಾಸಕ್ಕೆ ವರ್ಗಾಯಿಸಲಾಗುತ್ತದೆ. PVRB ಯ ಸಂದರ್ಭದಲ್ಲಿ, ಅಂತಿಮತೆಯ ಅವಶ್ಯಕತೆಗಳು ಇನ್ನೂ ಹೆಚ್ಚು ಕಠಿಣವಾಗಿವೆ, ಏಕೆಂದರೆ PVRB ಗಾಗಿ ಫೋರ್ಕ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವುದು ಎಂದರೆ ಆಕ್ರಮಣಕಾರರಿಗೆ ಹೆಚ್ಚು ಲಾಭದಾಯಕವಾದದನ್ನು ಪ್ರಕಟಿಸಲು ಹಲವಾರು ಯಾದೃಚ್ಛಿಕ ಆಯ್ಕೆಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಅವಕಾಶ ಮತ್ತು ಸಂಭವನೀಯ ದಾಳಿಯ ಸಮಯವನ್ನು ಸೀಮಿತಗೊಳಿಸುವುದು ಉತ್ತಮ ಪರಿಹಾರ.

ಆದ್ದರಿಂದ, PVRB ಮತ್ತು ಅಂತಿಮತೆಯನ್ನು ಒಂದು ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ಸಂಯೋಜಿಸುವುದು ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ - ನಂತರ ಅಂತಿಮಗೊಳಿಸಿದ ಬ್ಲಾಕ್ = ಅಂತಿಮಗೊಳಿಸಿದ ಯಾದೃಚ್ಛಿಕ, ಮತ್ತು ಇದು ನಿಖರವಾಗಿ ನಾವು ಪಡೆಯಬೇಕಾದದ್ದು. ಈಗ ಆಟಗಾರರು N ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಗ್ಯಾರಂಟಿಯಾದ ಯಾದೃಚ್ಛಿಕವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು ಹಿಂತಿರುಗಿಸಲು ಅಥವಾ ಅದನ್ನು ಮತ್ತೆ ಮರುಪಂದ್ಯ ಮಾಡುವುದು ಅಸಾಧ್ಯವೆಂದು ಖಚಿತವಾಗಿರಬಹುದು.

ಒಮ್ಮತ-ಸಂಯೋಜಿತ ಆಯ್ಕೆಯು ಒಳ್ಳೆಯದು:

• ಬ್ಲಾಕ್‌ಗಳ ಉತ್ಪಾದನೆಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಅಸಮಕಾಲಿಕ ಅನುಷ್ಠಾನದ ಸಾಧ್ಯತೆ - ಬ್ಲಾಕ್‌ಗಳನ್ನು ಎಂದಿನಂತೆ ಉತ್ಪಾದಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಇದರೊಂದಿಗೆ ಸಮಾನಾಂತರವಾಗಿ, PVRB ಪ್ರೋಟೋಕಾಲ್ ಕೆಲಸ ಮಾಡಬಹುದು, ಇದು ಪ್ರತಿ ಬ್ಲಾಕ್‌ಗೆ ಯಾದೃಚ್ಛಿಕತೆಯನ್ನು ಉಂಟುಮಾಡುವುದಿಲ್ಲ
• ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದಗಳ ಮೇಲೆ ಹೇರಿದ ನಿರ್ಬಂಧಗಳಿಲ್ಲದೆ ಭಾರೀ ಗುಪ್ತ ಲಿಪಿ ಶಾಸ್ತ್ರವನ್ನು ಸಹ ಕಾರ್ಯಗತಗೊಳಿಸುವ ಸಾಮರ್ಥ್ಯ
• ವಹಿವಾಟುಗಳಿಗಿಂತ ವೇಗವಾಗಿ ಸಂದೇಶಗಳ ವಿನಿಮಯವನ್ನು ಸಂಘಟಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಪ್ರೋಟೋಕಾಲ್‌ನ ಭಾಗವು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಸಂದೇಶಗಳನ್ನು ವಿತರಿಸದೆ ನೋಡ್‌ಗಳ ನಡುವೆ ಕೆಲಸ ಮಾಡಬಹುದು

ಇದು ಅನಾನುಕೂಲಗಳನ್ನು ಸಹ ಹೊಂದಿದೆ:

• ಪರೀಕ್ಷೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಯಲ್ಲಿನ ತೊಂದರೆಗಳು - ನೀವು ನೆಟ್‌ವರ್ಕ್ ದೋಷಗಳು, ಕಾಣೆಯಾದ ನೋಡ್‌ಗಳು, ನೆಟ್‌ವರ್ಕ್ ಹಾರ್ಡ್ ಫೋರ್ಕ್‌ಗಳನ್ನು ಅನುಕರಿಸಬೇಕು
• ಅನುಷ್ಠಾನ ದೋಷಗಳಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಹಾರ್ಡ್‌ಫೋರ್ಕ್ ಅಗತ್ಯವಿರುತ್ತದೆ

PVRB ಅನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುವ ಎರಡೂ ವಿಧಾನಗಳು ಜೀವನದ ಹಕ್ಕನ್ನು ಹೊಂದಿವೆ, ಆದರೆ ಆಧುನಿಕ ಬ್ಲಾಕ್‌ಚೈನ್‌ಗಳಲ್ಲಿ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದಗಳ ಅನುಷ್ಠಾನವು ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳಲ್ಲಿ ಇನ್ನೂ ಸಾಕಷ್ಟು ಸೀಮಿತವಾಗಿದೆ ಮತ್ತು ಗಂಭೀರ ಕ್ರಿಪ್ಟೋಗ್ರಫಿಗೆ ಯಾವುದೇ ಪರಿವರ್ತನೆಯು ಸಾಮಾನ್ಯವಾಗಿ ಅಸಾಧ್ಯವಾಗಿದೆ. ಮತ್ತು ನಮಗೆ ಗಂಭೀರ ಗುಪ್ತ ಲಿಪಿ ಶಾಸ್ತ್ರದ ಅಗತ್ಯವಿದೆ, ಅದನ್ನು ಕೆಳಗೆ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ. ಈ ಸಮಸ್ಯೆಯು ಸ್ಪಷ್ಟವಾಗಿ ತಾತ್ಕಾಲಿಕವಾಗಿದ್ದರೂ ಸಹ, ಹಲವಾರು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ಒಪ್ಪಂದಗಳಲ್ಲಿ ಗಂಭೀರವಾದ ಗುಪ್ತ ಲಿಪಿ ಶಾಸ್ತ್ರದ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ಇದು ಕ್ರಮೇಣ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಿದೆ (ಉದಾಹರಣೆಗೆ, Ethereum ನಲ್ಲಿ zkSNARK ಗಾಗಿ ಸಿಸ್ಟಮ್ ಒಪ್ಪಂದಗಳು)

ಪಾರದರ್ಶಕ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹ ಪ್ರೋಟೋಕಾಲ್ ಸಂದೇಶ ಕಳುಹಿಸುವ ಚಾನಲ್ ಅನ್ನು ಒದಗಿಸುವ Blockchain, ಉಚಿತವಾಗಿ ಮಾಡುವುದಿಲ್ಲ. ಯಾವುದೇ ವಿಕೇಂದ್ರೀಕೃತ ಪ್ರೋಟೋಕಾಲ್ ಸಿಬಿಲ್ ದಾಳಿಯ ಸಾಧ್ಯತೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳಬೇಕು; ಯಾವುದೇ ಕ್ರಮವನ್ನು ಬಹು ಖಾತೆಗಳ ಸಂಘಟಿತ ಶಕ್ತಿಗಳಿಂದ ಮಾಡಬಹುದು, ಆದ್ದರಿಂದ, ವಿನ್ಯಾಸ ಮಾಡುವಾಗ, ಅನಿಯಂತ್ರಿತ ಸಂಖ್ಯೆಯ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ರಚಿಸುವ ಆಕ್ರಮಣಕಾರರ ಸಾಮರ್ಥ್ಯವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವುದು ಅವಶ್ಯಕ. ಭಾಗವಹಿಸುವವರು ಒಪ್ಪಂದದಲ್ಲಿ ವರ್ತಿಸುತ್ತಾರೆ.

PVRB ಮತ್ತು ಬ್ಲಾಕ್ ವೇರಿಯೇಬಲ್‌ಗಳು.

ಬ್ಲಾಕ್‌ಚೈನ್‌ಗಳಲ್ಲಿ ಅನೇಕ ಜೂಜಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಂದ ಪರೀಕ್ಷಿಸಲ್ಪಟ್ಟ ಉತ್ತಮ PVRB ಅನ್ನು ಯಾರೂ ಇನ್ನೂ ಜಾರಿಗೆ ತಂದಿಲ್ಲ ಎಂದು ನಾನು ಹೇಳಿದಾಗ ನಾನು ಸುಳ್ಳು ಹೇಳಲಿಲ್ಲ. Ethereum ಮತ್ತು EOS ನಲ್ಲಿ ಹೆಚ್ಚಿನ ಜೂಜಿನ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ? ಇದು ನಿಮಗೆ ಆಶ್ಚರ್ಯವನ್ನುಂಟುಮಾಡುವಷ್ಟು ನನಗೆ ಆಶ್ಚರ್ಯವನ್ನುಂಟುಮಾಡುತ್ತದೆ, ಅವರು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ಣಾಯಕ ಪರಿಸರದಲ್ಲಿ ಅನೇಕ "ನಿರಂತರ" ಯಾದೃಚ್ಛಿಕಗಳನ್ನು ಎಲ್ಲಿ ಪಡೆದರು?

ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ಯಾದೃಚ್ಛಿಕತೆಯನ್ನು ಪಡೆಯಲು ನೆಚ್ಚಿನ ಮಾರ್ಗವೆಂದರೆ ಬ್ಲಾಕ್‌ನಿಂದ ಕೆಲವು ರೀತಿಯ "ಅನೂಹ್ಯ" ಮಾಹಿತಿಯನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಮತ್ತು ಅದರ ಆಧಾರದ ಮೇಲೆ ಯಾದೃಚ್ಛಿಕ ಒಂದನ್ನು ಮಾಡುವುದು - ಸರಳವಾಗಿ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಮೌಲ್ಯಗಳನ್ನು ಹ್ಯಾಶ್ ಮಾಡುವ ಮೂಲಕ. ಅಂತಹ ಯೋಜನೆಗಳ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಉತ್ತಮ ಲೇಖನ ಇಲ್ಲಿ. ನೀವು ಬ್ಲಾಕ್ನಲ್ಲಿ ಯಾವುದೇ "ಊಹಿಸಲಾಗದ" ಮೌಲ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು, ಉದಾಹರಣೆಗೆ, ಬ್ಲಾಕ್ ಹ್ಯಾಶ್, ವಹಿವಾಟುಗಳ ಸಂಖ್ಯೆ, ನೆಟ್ವರ್ಕ್ ಸಂಕೀರ್ಣತೆ ಮತ್ತು ಮುಂಚಿತವಾಗಿ ತಿಳಿದಿಲ್ಲದ ಇತರ ಮೌಲ್ಯಗಳು. ನಂತರ ಅವುಗಳನ್ನು ಹ್ಯಾಶ್ ಮಾಡಿ, ಒಂದು ಅಥವಾ ಹೆಚ್ಚು, ಮತ್ತು, ಸಿದ್ಧಾಂತದಲ್ಲಿ, ನೀವು ನಿಜವಾದ ಯಾದೃಚ್ಛಿಕವನ್ನು ಪಡೆಯಬೇಕು. ನಿಮ್ಮ ಸ್ಕೀಮ್ "ಪೋಸ್ಟ್-ಕ್ವಾಂಟಮ್ ಸುರಕ್ಷಿತ" (ಕ್ವಾಂಟಮ್ ಪ್ರೂಫ್ ಹ್ಯಾಶ್ ಫಂಕ್ಷನ್‌ಗಳಿರುವುದರಿಂದ :)) ಎಂದು ನೀವು ವೈಟ್‌ಪೇಪರ್‌ಗೆ ಸೇರಿಸಬಹುದು.

ಆದರೆ ಕ್ವಾಂಟಮ್ ನಂತರದ ಸುರಕ್ಷಿತ ಹ್ಯಾಶ್‌ಗಳು ಸಹ ಸಾಕಾಗುವುದಿಲ್ಲ, ಅಯ್ಯೋ. ರಹಸ್ಯವು PVRB ಯ ಅವಶ್ಯಕತೆಗಳಲ್ಲಿದೆ, ಹಿಂದಿನ ಲೇಖನದಿಂದ ಅವುಗಳನ್ನು ನಿಮಗೆ ನೆನಪಿಸುತ್ತೇನೆ:

1. ಫಲಿತಾಂಶವು ಸಾಬೀತಾಗಿರುವ ಏಕರೂಪದ ವಿತರಣೆಯನ್ನು ಹೊಂದಿರಬೇಕು, ಅಂದರೆ ಸಾಬೀತುಪಡಿಸಬಹುದಾದ ಬಲವಾದ ಗುಪ್ತ ಲಿಪಿ ಶಾಸ್ತ್ರವನ್ನು ಆಧರಿಸಿರಬೇಕು.
2. ಫಲಿತಾಂಶದ ಯಾವುದೇ ಬಿಟ್‌ಗಳನ್ನು ನಿಯಂತ್ರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಫಲಿತಾಂಶವನ್ನು ಮುಂಚಿತವಾಗಿ ಊಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ.
3. ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಭಾಗವಹಿಸದೆ ಅಥವಾ ದಾಳಿಯ ಸಂದೇಶಗಳೊಂದಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಓವರ್‌ಲೋಡ್ ಮಾಡುವ ಮೂಲಕ ನೀವು ಪೀಳಿಗೆಯ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹಾಳುಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.
4. ಮೇಲಿನ ಎಲ್ಲಾ ಅಪ್ರಾಮಾಣಿಕ ಪ್ರೋಟೋಕಾಲ್ ಭಾಗವಹಿಸುವವರ (ಉದಾಹರಣೆಗೆ, ಭಾಗವಹಿಸುವವರಲ್ಲಿ 1/3) ಅನುಮತಿಸುವ ಸಂಖ್ಯೆಯ ಸಂಯೋಜನೆಗೆ ನಿರೋಧಕವಾಗಿರಬೇಕು.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅವಶ್ಯಕತೆ 1 ಅನ್ನು ಮಾತ್ರ ಪೂರೈಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅವಶ್ಯಕತೆ 2 ಅನ್ನು ಪೂರೈಸಲಾಗುವುದಿಲ್ಲ. ಬ್ಲಾಕ್‌ನಿಂದ ಅನಿರೀಕ್ಷಿತ ಮೌಲ್ಯಗಳನ್ನು ಹ್ಯಾಶ್ ಮಾಡುವ ಮೂಲಕ, ನಾವು ಏಕರೂಪದ ವಿತರಣೆ ಮತ್ತು ಉತ್ತಮ ಯಾದೃಚ್ಛಿಕಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಆದರೆ BP ಕನಿಷ್ಠ "ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರಕಟಿಸಲು ಅಥವಾ ಇಲ್ಲ" ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿದೆ. ಹೀಗಾಗಿ, BP ಕನಿಷ್ಠ ಎರಡು ಯಾದೃಚ್ಛಿಕ ಆಯ್ಕೆಗಳಿಂದ ಆಯ್ಕೆ ಮಾಡಬಹುದು: "ಸ್ವಂತ" ಮತ್ತು ಬೇರೊಬ್ಬರು ಬ್ಲಾಕ್ ಮಾಡಿದರೆ ಅದು ಹೊರಹೊಮ್ಮುತ್ತದೆ. BP ಅವರು ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರಕಟಿಸಿದರೆ ಏನಾಗಬಹುದು ಎಂಬುದನ್ನು ಮುಂಚಿತವಾಗಿ "ಸ್ನೂಪ್" ಮಾಡಬಹುದು ಮತ್ತು ಅದನ್ನು ಮಾಡಲು ಅಥವಾ ಮಾಡದಿರಲು ನಿರ್ಧರಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, ಆಡುವಾಗ, ಉದಾಹರಣೆಗೆ, ರೂಲೆಟ್‌ನಲ್ಲಿ “ಸಮ-ಬೆಸ” ಅಥವಾ “ಕೆಂಪು/ಕಪ್ಪು”, ಅವರು ಗೆಲುವು ಕಂಡರೆ ಮಾತ್ರ ಬ್ಲಾಕ್ ಅನ್ನು ಪ್ರಕಟಿಸಬಹುದು. ಇದು ಬಳಸುವ ತಂತ್ರವನ್ನು ಸಹ ಮಾಡುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, "ಭವಿಷ್ಯದಿಂದ" ಬ್ಲಾಕ್ ಹ್ಯಾಶ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುವುದಿಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅವರು ಹೇಳುತ್ತಾರೆ “ಯಾದೃಚ್ಛಿಕವಾಗಿ ಬಳಸಲಾಗುವುದು, ಇದು ಪ್ರಸ್ತುತ ಡೇಟಾ ಮತ್ತು ಭವಿಷ್ಯದ ಬ್ಲಾಕ್‌ನ ಹ್ಯಾಶ್ ಅನ್ನು ಎತ್ತರದೊಂದಿಗೆ ಹ್ಯಾಶ್ ಮಾಡುವ ಮೂಲಕ ಪಡೆಯಲಾಗುತ್ತದೆ, ಉದಾಹರಣೆಗೆ, N + 42, ಅಲ್ಲಿ N ಪ್ರಸ್ತುತ ಬ್ಲಾಕ್ ಎತ್ತರವಾಗಿದೆ. ಇದು ಸ್ಕೀಮ್ ಅನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಬಲಪಡಿಸುತ್ತದೆ, ಆದರೆ ಭವಿಷ್ಯದಲ್ಲಿ ಆದರೂ BP ಅನ್ನು ನಿರ್ಬಂಧಿಸಲು ಅಥವಾ ಪ್ರಕಟಿಸಲು ಆಯ್ಕೆ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ ಬಿಪಿ ಸಾಫ್ಟ್‌ವೇರ್ ಹೆಚ್ಚು ಜಟಿಲವಾಗಿದೆ, ಆದರೆ ಹೆಚ್ಚು ಅಲ್ಲ. ಸರಳವಾಗಿ, ಮೌಲ್ಯೀಕರಿಸುವಾಗ ಮತ್ತು ಬ್ಲಾಕ್‌ನಲ್ಲಿ ವಹಿವಾಟನ್ನು ಸೇರಿಸುವಾಗ, ಗೆಲುವಿದೆಯೇ ಎಂದು ನೋಡಲು ತ್ವರಿತ ಪರಿಶೀಲನೆ ಇರುತ್ತದೆ ಮತ್ತು ಬಹುಶಃ, ಗೆಲ್ಲುವ ಹೆಚ್ಚಿನ ಸಂಭವನೀಯತೆಯನ್ನು ಪಡೆಯಲು ಒಂದು ವಹಿವಾಟಿನ ನಿಯತಾಂಕಗಳ ಆಯ್ಕೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅಂತಹ ಕುಶಲತೆಗಳಿಗಾಗಿ ಸ್ಮಾರ್ಟ್ ಬಿಪಿ ಹಿಡಿಯುವುದು ಅಸಾಧ್ಯವಾಗಿದೆ; ಪ್ರತಿ ಬಾರಿ ನೀವು ಹೊಸ ವಿಳಾಸಗಳನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಅನುಮಾನವನ್ನು ಉಂಟುಮಾಡದೆ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಗೆಲ್ಲಬಹುದು.

ಆದ್ದರಿಂದ ಬ್ಲಾಕ್ನಿಂದ ಮಾಹಿತಿಯನ್ನು ಬಳಸುವ ವಿಧಾನಗಳು PVRB ಯ ಸಾರ್ವತ್ರಿಕ ಅನುಷ್ಠಾನವಾಗಿ ಸೂಕ್ತವಲ್ಲ. ಸೀಮಿತ ಆವೃತ್ತಿಯಲ್ಲಿ, ಬೆಟ್ ಗಾತ್ರಗಳ ಮೇಲಿನ ನಿರ್ಬಂಧಗಳು, ಆಟಗಾರರ ಸಂಖ್ಯೆ ಮತ್ತು/ಅಥವಾ KYC ನೋಂದಣಿ (ಒಬ್ಬ ಆಟಗಾರನು ಬಹು ವಿಳಾಸಗಳನ್ನು ಬಳಸುವುದನ್ನು ತಡೆಯಲು) ಮೇಲಿನ ನಿರ್ಬಂಧಗಳೊಂದಿಗೆ, ಈ ಯೋಜನೆಗಳು ಸಣ್ಣ ಆಟಗಳಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು, ಆದರೆ ಹೆಚ್ಚೇನೂ ಇಲ್ಲ.

PVRB ಮತ್ತು ಬದ್ಧತೆ-ಬಹಿರಂಗ.

ಸರಿ, ಹ್ಯಾಶಿಂಗ್‌ಗೆ ಧನ್ಯವಾದಗಳು ಮತ್ತು ಬ್ಲಾಕ್ ಹ್ಯಾಶ್ ಮತ್ತು ಇತರ ವೇರಿಯೇಬಲ್‌ಗಳ ತುಲನಾತ್ಮಕ ಅನಿರೀಕ್ಷಿತತೆ. ಮುಂಭಾಗದ ಗಣಿಗಾರರ ಸಮಸ್ಯೆಯನ್ನು ನೀವು ಪರಿಹರಿಸಿದರೆ, ನೀವು ಹೆಚ್ಚು ಸೂಕ್ತವಾದದನ್ನು ಪಡೆಯಬೇಕು. ಈ ಯೋಜನೆಗೆ ಬಳಕೆದಾರರನ್ನು ಸೇರಿಸೋಣ - ಅವರು ಯಾದೃಚ್ಛಿಕತೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಲಿ: ಯಾವುದೇ ತಾಂತ್ರಿಕ ಬೆಂಬಲ ಉದ್ಯೋಗಿ ಐಟಿ ವ್ಯವಸ್ಥೆಗಳಲ್ಲಿ ಅತ್ಯಂತ ಯಾದೃಚ್ಛಿಕ ವಿಷಯವೆಂದರೆ ಬಳಕೆದಾರರ ಕ್ರಿಯೆಗಳು ಎಂದು ನಿಮಗೆ ತಿಳಿಸುತ್ತಾರೆ :)

ನಿಷ್ಕಪಟ ಯೋಜನೆ, ಬಳಕೆದಾರರು ಸರಳವಾಗಿ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಗಳನ್ನು ಕಳುಹಿಸಿದಾಗ ಮತ್ತು ಫಲಿತಾಂಶವನ್ನು ಲೆಕ್ಕಹಾಕಿದಾಗ, ಉದಾಹರಣೆಗೆ, ಅವರ ಮೊತ್ತದ ಹ್ಯಾಶ್ ಸೂಕ್ತವಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಕೊನೆಯ ಆಟಗಾರನು ತನ್ನದೇ ಆದ ಯಾದೃಚ್ಛಿಕವನ್ನು ಆರಿಸುವ ಮೂಲಕ, ಫಲಿತಾಂಶ ಏನೆಂದು ನಿಯಂತ್ರಿಸಬಹುದು. ಇದಕ್ಕಾಗಿಯೇ ವ್ಯಾಪಕವಾಗಿ ಬಳಸಲಾಗುವ ಕಮಿಟ್-ರೀವೀಲ್ ಮಾದರಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಭಾಗವಹಿಸುವವರು ಮೊದಲು ತಮ್ಮ ಯಾದೃಚ್ಛಿಕಗಳಿಂದ (ಬದ್ಧತೆಗಳು) ಹ್ಯಾಶ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾರೆ, ಮತ್ತು ನಂತರ ಯಾದೃಚ್ಛಿಕಗಳನ್ನು ಸ್ವತಃ ತೆರೆಯುತ್ತಾರೆ (ಬಹಿರಂಗಪಡಿಸುತ್ತಾರೆ). ಅಗತ್ಯ ಕಮಿಟ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸಿದ ನಂತರವೇ "ಬಹಿರಂಗಪಡಿಸುವ" ಹಂತವು ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಭಾಗವಹಿಸುವವರು ಅವರು ಮೊದಲು ಕಳುಹಿಸಿದ ಯಾದೃಚ್ಛಿಕ ಹ್ಯಾಶ್ ಅನ್ನು ನಿಖರವಾಗಿ ಕಳುಹಿಸಬಹುದು. ಈಗ ನಾವು ಇದನ್ನೆಲ್ಲ ಬ್ಲಾಕ್‌ನ ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಒಟ್ಟುಗೂಡಿಸೋಣ ಮತ್ತು ಭವಿಷ್ಯದಿಂದ ತೆಗೆದುಕೊಂಡ ಒಂದಕ್ಕಿಂತ ಉತ್ತಮವಾಗಿದೆ (ಯಾದೃಚ್ಛಿಕತೆಯನ್ನು ಭವಿಷ್ಯದ ಬ್ಲಾಕ್‌ಗಳಲ್ಲಿ ಒಂದರಲ್ಲಿ ಮಾತ್ರ ಕಾಣಬಹುದು), ಮತ್ತು ವೋಲಾ - ಯಾದೃಚ್ಛಿಕತೆ ಸಿದ್ಧವಾಗಿದೆ! ಈಗ ಯಾವುದೇ ಆಟಗಾರನು ಫಲಿತಾಂಶದ ಯಾದೃಚ್ಛಿಕತೆಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುತ್ತಾನೆ ಮತ್ತು ದುರುದ್ದೇಶಪೂರಿತ BP ಅನ್ನು ತನ್ನದೇ ಆದ, ಮುಂಚಿತವಾಗಿ ತಿಳಿದಿಲ್ಲದ, ಯಾದೃಚ್ಛಿಕತೆಯಿಂದ ಅತಿಕ್ರಮಿಸುವ ಮೂಲಕ "ಸೋಲಿಸಬಹುದು"... ನೀವು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬಹಿರಂಗ ಹಂತದಲ್ಲಿ ತೆರೆಯದಿರುವ ಮೂಲಕ ಅದನ್ನು ಹಾಳುಮಾಡುವುದರ ವಿರುದ್ಧ ರಕ್ಷಣೆಯನ್ನು ಸೇರಿಸಬಹುದು - ಸರಳವಾಗಿ ಬದ್ಧತೆ ಮಾಡುವಾಗ ವಹಿವಾಟಿಗೆ ನಿರ್ದಿಷ್ಟ ಮೊತ್ತವನ್ನು ಲಗತ್ತಿಸಬೇಕಾದ ಅಗತ್ಯವಿರುತ್ತದೆ - ಭದ್ರತಾ ಠೇವಣಿ, ಅದನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಕಾರ್ಯವಿಧಾನದ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ಹಿಂತಿರುಗಿಸಲಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಬದ್ಧತೆ ಮತ್ತು ಬಹಿರಂಗಪಡಿಸದಿರುವುದು ಲಾಭದಾಯಕವಲ್ಲ.

ಇದು ಉತ್ತಮ ಪ್ರಯತ್ನವಾಗಿದೆ, ಮತ್ತು ಅಂತಹ ಯೋಜನೆಗಳು ಗೇಮಿಂಗ್ DApps ನಲ್ಲಿಯೂ ಸಹ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ, ಆದರೆ ಅಯ್ಯೋ, ಇದು ಮತ್ತೆ ಸಾಕಾಗುವುದಿಲ್ಲ. ಈಗ ಮೈನರ್ಸ್ ಮಾತ್ರವಲ್ಲ, ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ ಯಾವುದೇ ಪಾಲ್ಗೊಳ್ಳುವವರು ಫಲಿತಾಂಶದ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಬಹುದು. ಕಡಿಮೆ ವ್ಯತ್ಯಾಸದೊಂದಿಗೆ ಮತ್ತು ವೆಚ್ಚದಲ್ಲಿ ಮೌಲ್ಯವನ್ನು ನಿಯಂತ್ರಿಸಲು ಇನ್ನೂ ಸಾಧ್ಯವಿದೆ, ಆದರೆ, ಗಣಿಗಾರನ ಸಂದರ್ಭದಲ್ಲಿ, ರೇಖಾಚಿತ್ರದ ಫಲಿತಾಂಶಗಳು PVRB ಪ್ರೋಟೋಕಾಲ್ನಲ್ಲಿ ಭಾಗವಹಿಸುವ ಶುಲ್ಕಕ್ಕಿಂತ ಹೆಚ್ಚು ಮೌಲ್ಯಯುತವಾಗಿದ್ದರೆ, ನಂತರ ಯಾದೃಚ್ಛಿಕ -ನಿರ್ಮಾಪಕ (ಆರ್‌ಪಿ) ಬಹಿರಂಗಪಡಿಸಬೇಕೆ ಎಂದು ನಿರ್ಧರಿಸಬಹುದು ಮತ್ತು ಇನ್ನೂ ಕನಿಷ್ಠ ಎರಡು ಯಾದೃಚ್ಛಿಕ ಆಯ್ಕೆಗಳಿಂದ ಆಯ್ಕೆ ಮಾಡಬಹುದು.
ಆದರೆ ಬದ್ಧತೆ ಮತ್ತು ಬಹಿರಂಗಪಡಿಸದವರನ್ನು ಶಿಕ್ಷಿಸಲು ಸಾಧ್ಯವಾಯಿತು ಮತ್ತು ಈ ಯೋಜನೆಯು ಸೂಕ್ತವಾಗಿ ಬರುತ್ತದೆ. ಇದರ ಸರಳತೆಯು ಗಂಭೀರ ಪ್ರಯೋಜನವಾಗಿದೆ - ಹೆಚ್ಚು ಗಂಭೀರವಾದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ ಹೆಚ್ಚು ಶಕ್ತಿಯುತ ಲೆಕ್ಕಾಚಾರಗಳು ಬೇಕಾಗುತ್ತವೆ.

PVRB ಮತ್ತು ನಿರ್ಣಾಯಕ ಸಹಿಗಳು.

RP ಒಂದು ಹುಸಿ-ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯನ್ನು ಒದಗಿಸುವಂತೆ ಒತ್ತಾಯಿಸಲು ಇನ್ನೊಂದು ಮಾರ್ಗವಿದೆ, ಅದು "ಪ್ರಿಮೇಜ್" ಅನ್ನು ಒದಗಿಸಿದರೆ ಅದು ಪ್ರಭಾವಿಸುವುದಿಲ್ಲ - ಇದು ನಿರ್ಣಾಯಕ ಸಹಿಯಾಗಿದೆ. ಅಂತಹ ಸಹಿ, ಉದಾಹರಣೆಗೆ, RSA, ಮತ್ತು ECS ಅಲ್ಲ. RP ಒಂದು ಜೋಡಿ ಕೀಗಳನ್ನು ಹೊಂದಿದ್ದರೆ: RSA ಮತ್ತು ECC, ಮತ್ತು ಅವನು ತನ್ನ ಖಾಸಗಿ ಕೀಲಿಯೊಂದಿಗೆ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮೌಲ್ಯವನ್ನು ಸಹಿ ಮಾಡಿದರೆ, ನಂತರ RSA ಸಂದರ್ಭದಲ್ಲಿ ಅವನು ಒಂದು ಮತ್ತು ಒಂದೇ ಒಂದು ಸಹಿಯನ್ನು ಪಡೆಯುತ್ತಾನೆ ಮತ್ತು ECS ನ ಸಂದರ್ಭದಲ್ಲಿ ಅವನು ಯಾವುದೇ ಸಂಖ್ಯೆಯನ್ನು ರಚಿಸಬಹುದು ವಿಭಿನ್ನ ಮಾನ್ಯ ಸಹಿಗಳು. ಏಕೆಂದರೆ ECS ಸಹಿಯನ್ನು ರಚಿಸುವಾಗ, ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಸಹಿ ಮಾಡುವವರು ಆಯ್ಕೆ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅದನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಸಹಿ ಮಾಡುವವರಿಗೆ ಹಲವಾರು ಸಹಿಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ. RSA ಸಂದರ್ಭದಲ್ಲಿ: "ಒಂದು ಇನ್‌ಪುಟ್ ಮೌಲ್ಯ" + "ಒಂದು ಕೀ ಜೋಡಿ" = "ಒಂದು ಸಹಿ". ಮತ್ತೊಂದು RP ಯಾವ ಸಹಿಯನ್ನು ಪಡೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ಊಹಿಸಲು ಅಸಾಧ್ಯವಾಗಿದೆ, ಆದ್ದರಿಂದ ಒಂದೇ ಮೌಲ್ಯಕ್ಕೆ ಸಹಿ ಮಾಡಿದ ಹಲವಾರು ಭಾಗವಹಿಸುವವರ RSA ಸಹಿಗಳನ್ನು ಸಂಯೋಜಿಸುವ ಮೂಲಕ ನಿರ್ಣಾಯಕ ಸಹಿಗಳೊಂದಿಗೆ PVRB ಅನ್ನು ಆಯೋಜಿಸಬಹುದು. ಉದಾಹರಣೆಗೆ, ಹಿಂದಿನ ಯಾದೃಚ್ಛಿಕ. ಈ ಯೋಜನೆಯು ಬಹಳಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಉಳಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಸಹಿಗಳು ಪ್ರೋಟೋಕಾಲ್ ಪ್ರಕಾರ ಸರಿಯಾದ ನಡವಳಿಕೆಯ ದೃಢೀಕರಣ ಮತ್ತು ಯಾದೃಚ್ಛಿಕತೆಯ ಮೂಲವಾಗಿದೆ.

ಆದಾಗ್ಯೂ, ನಿರ್ಣಾಯಕ ಸಹಿಗಳೊಂದಿಗೆ ಸಹ, ಯೋಜನೆಯು "ಕೊನೆಯ ನಟ" ಸಮಸ್ಯೆಗೆ ಇನ್ನೂ ದುರ್ಬಲವಾಗಿರುತ್ತದೆ. ಕೊನೆಯ ಪಾಲ್ಗೊಳ್ಳುವವರು ಇನ್ನೂ ಸಹಿಯನ್ನು ಪ್ರಕಟಿಸಬೇಕೆ ಅಥವಾ ಬೇಡವೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬಹುದು, ಇದರಿಂದಾಗಿ ಫಲಿತಾಂಶವನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು. ನೀವು ಸ್ಕೀಮ್ ಅನ್ನು ಮಾರ್ಪಡಿಸಬಹುದು, ಅದಕ್ಕೆ ಬ್ಲಾಕ್ ಹ್ಯಾಶ್‌ಗಳನ್ನು ಸೇರಿಸಬಹುದು, ಫಲಿತಾಂಶವನ್ನು ಮುಂಚಿತವಾಗಿ ಊಹಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಸುತ್ತು ಹಾಕಬಹುದು, ಆದರೆ ಈ ಎಲ್ಲಾ ತಂತ್ರಗಳು, ಅನೇಕ ಮಾರ್ಪಾಡುಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡರೂ ಸಹ, ಸಾಮೂಹಿಕವಾಗಿ ಭಾಗವಹಿಸುವವರ ಪ್ರಭಾವದ ಸಮಸ್ಯೆಯನ್ನು ಇನ್ನೂ ಪರಿಹರಿಸಲಾಗುವುದಿಲ್ಲ. ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲದ ವಾತಾವರಣಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ ಮತ್ತು ಆರ್ಥಿಕ ಮತ್ತು ಸಮಯದ ನಿರ್ಬಂಧಗಳ ಅಡಿಯಲ್ಲಿ ಮಾತ್ರ ಕೆಲಸ ಮಾಡಬಹುದು. ಇದರ ಜೊತೆಗೆ, RSA ಕೀಗಳ (1024 ಮತ್ತು 2048 ಬಿಟ್‌ಗಳು) ಗಾತ್ರವು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ಬ್ಲಾಕ್‌ಚೈನ್ ವಹಿವಾಟುಗಳ ಗಾತ್ರವು ಅತ್ಯಂತ ಪ್ರಮುಖ ನಿಯತಾಂಕವಾಗಿದೆ. ಸ್ಪಷ್ಟವಾಗಿ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಯಾವುದೇ ಸರಳ ಮಾರ್ಗವಿಲ್ಲ, ನಾವು ಮುಂದುವರಿಯೋಣ.

PVRB ಮತ್ತು ರಹಸ್ಯ ಹಂಚಿಕೆ ಯೋಜನೆಗಳು

ಕ್ರಿಪ್ಟೋಗ್ರಫಿಯಲ್ಲಿ, ನೆಟ್‌ವರ್ಕ್ ಒಂದೇ ಮತ್ತು ಒಂದೇ ಒಂದು PVRB ಮೌಲ್ಯವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳಲು ಅನುಮತಿಸುವ ಸ್ಕೀಮ್‌ಗಳಿವೆ, ಆದರೆ ಅಂತಹ ಯೋಜನೆಗಳು ಕೆಲವು ಭಾಗವಹಿಸುವವರ ಯಾವುದೇ ದುರುದ್ದೇಶಪೂರಿತ ಕ್ರಿಯೆಗಳಿಗೆ ನಿರೋಧಕವಾಗಿರುತ್ತವೆ. ಶಮೀರ್ ಅವರ ರಹಸ್ಯ ಹಂಚಿಕೆ ಯೋಜನೆಯು ನಿಮ್ಮನ್ನು ಪರಿಚಯ ಮಾಡಿಕೊಳ್ಳಲು ಯೋಗ್ಯವಾದ ಒಂದು ಉಪಯುಕ್ತ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿದೆ. ಇದು ರಹಸ್ಯವನ್ನು (ಉದಾಹರಣೆಗೆ, ರಹಸ್ಯ ಕೀಲಿ) ಹಲವಾರು ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸಲು ಮತ್ತು ಎನ್ ಭಾಗವಹಿಸುವವರಿಗೆ ಈ ಭಾಗಗಳನ್ನು ವಿತರಿಸಲು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. N ನಿಂದ M ಭಾಗಗಳು ಅದನ್ನು ಮರುಪಡೆಯಲು ಸಾಕಾಗುವ ರೀತಿಯಲ್ಲಿ ರಹಸ್ಯವನ್ನು ವಿತರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಇವು ಯಾವುದೇ M ಭಾಗಗಳಾಗಿರಬಹುದು. ಬೆರಳುಗಳ ಮೇಲೆ ಇದ್ದರೆ, ಅಜ್ಞಾತ ಕಾರ್ಯದ ಗ್ರಾಫ್ ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ಭಾಗವಹಿಸುವವರು ಗ್ರಾಫ್ನಲ್ಲಿ ಅಂಕಗಳನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ ಮತ್ತು M ಅಂಕಗಳನ್ನು ಪಡೆದ ನಂತರ, ಸಂಪೂರ್ಣ ಕಾರ್ಯವನ್ನು ಪುನಃಸ್ಥಾಪಿಸಬಹುದು.
ಉತ್ತಮ ವಿವರಣೆಯನ್ನು ನೀಡಲಾಗಿದೆ ವಿಕಿ ಆದರೆ ನಿಮ್ಮ ತಲೆಯಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಪ್ಲೇ ಮಾಡಲು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಅದರೊಂದಿಗೆ ಆಡುವುದು ಉಪಯುಕ್ತವಾಗಿದೆ ಡೆಮೊ ಪುಟ.

FSSS (ಫಿಯಟ್-ಶಮೀರ್ ರಹಸ್ಯ ಹಂಚಿಕೆ) ಯೋಜನೆಯು ಅದರ ಶುದ್ಧ ರೂಪದಲ್ಲಿ ಅನ್ವಯವಾಗಿದ್ದರೆ, ಅದು ಅವಿನಾಶವಾದ PVRB ಆಗಿರುತ್ತದೆ. ಅದರ ಸರಳ ರೂಪದಲ್ಲಿ, ಪ್ರೋಟೋಕಾಲ್ ಈ ರೀತಿ ಕಾಣಿಸಬಹುದು:

• ಪ್ರತಿಯೊಬ್ಬ ಭಾಗವಹಿಸುವವರು ತಮ್ಮದೇ ಆದ ಯಾದೃಚ್ಛಿಕವನ್ನು ರಚಿಸುತ್ತಾರೆ ಮತ್ತು ಅದರಿಂದ ಇತರ ಭಾಗವಹಿಸುವವರಿಗೆ ಷೇರುಗಳನ್ನು ವಿತರಿಸುತ್ತಾರೆ
• ಪ್ರತಿಯೊಬ್ಬ ಭಾಗವಹಿಸುವವರು ಇತರ ಭಾಗವಹಿಸುವವರ ರಹಸ್ಯಗಳ ತನ್ನ ಭಾಗವನ್ನು ಬಹಿರಂಗಪಡಿಸುತ್ತಾರೆ
• ಭಾಗವಹಿಸುವವರು M ಗಿಂತ ಹೆಚ್ಚಿನ ಷೇರುಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಈ ಭಾಗವಹಿಸುವವರ ಸಂಖ್ಯೆಯನ್ನು ಲೆಕ್ಕಹಾಕಬಹುದು ಮತ್ತು ಬಹಿರಂಗಪಡಿಸಿದ ಭಾಗವಹಿಸುವವರ ಗುಂಪನ್ನು ಲೆಕ್ಕಿಸದೆ ಅದು ಅನನ್ಯವಾಗಿರುತ್ತದೆ
• ಬಹಿರಂಗವಾದ ಯಾದೃಚ್ಛಿಕಗಳ ಸಂಯೋಜನೆಯು ಅಪೇಕ್ಷಿತ PVRB ಆಗಿದೆ

ಇಲ್ಲಿ, ಯಾದೃಚ್ಛಿಕ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಯ ಮಿತಿಯ ಸಾಧನೆಯು ಅವನ ಮೇಲೆ ಮಾತ್ರ ಅವಲಂಬಿತವಾಗಿರುವ ಸಂದರ್ಭಗಳಲ್ಲಿ ಹೊರತುಪಡಿಸಿ, ಒಬ್ಬ ವೈಯಕ್ತಿಕ ಪಾಲ್ಗೊಳ್ಳುವವರು ಪ್ರೋಟೋಕಾಲ್ನ ಫಲಿತಾಂಶಗಳ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಈ ಪ್ರೋಟೋಕಾಲ್, ಪ್ರೋಟೋಕಾಲ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಮತ್ತು ಲಭ್ಯವಿರುವ ಆರ್‌ಪಿಗಳ ಅಗತ್ಯವಿರುವ ಅನುಪಾತವಿದ್ದರೆ, ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಸಾಮರ್ಥ್ಯದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ ಮತ್ತು "ಕೊನೆಯ ನಟ" ಸಮಸ್ಯೆಗೆ ನಿರೋಧಕವಾಗಿರುತ್ತದೆ.

ಇದು ಆದರ್ಶ ಆಯ್ಕೆಯಾಗಿರಬಹುದು, ಫಿಯೆಟ್-ಶಮೀರ್ ರಹಸ್ಯ ಹಂಚಿಕೆಯನ್ನು ಆಧರಿಸಿದ ಈ PVRB ಯೋಜನೆಯನ್ನು ಉದಾಹರಣೆಗೆ ವಿವರಿಸಲಾಗಿದೆ ಇದು ಲೇಖನ ಆದರೆ, ಮೇಲೆ ಹೇಳಿದಂತೆ, ನೀವು ಅದನ್ನು ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ತಲೆಗೆ ಅನ್ವಯಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ತಾಂತ್ರಿಕ ಮಿತಿಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ. EOS ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದದಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ನ ಪರೀಕ್ಷಾ ಅನುಷ್ಠಾನದ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ ಮತ್ತು ಅದರ ಪ್ರಮುಖ ಭಾಗವಾಗಿದೆ - ಪ್ರಕಟಿಸಿದ ಷೇರು ಭಾಗವಹಿಸುವವರನ್ನು ಪರಿಶೀಲಿಸುವುದು: ಕೋಡ್. ಪುರಾವೆ ಊರ್ಜಿತಗೊಳಿಸುವಿಕೆಗೆ ಹಲವಾರು ಸ್ಕೇಲಾರ್ ಗುಣಾಕಾರಗಳ ಅಗತ್ಯವಿದೆ ಎಂದು ನೀವು ಕೋಡ್‌ನಿಂದ ನೋಡಬಹುದು ಮತ್ತು ಬಳಸಿದ ಸಂಖ್ಯೆಗಳು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ. ಬ್ಲಾಕ್-ಪ್ರೊಡ್ಯೂಸರ್ ವಹಿವಾಟನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಕ್ಷಣದಲ್ಲಿ ಬ್ಲಾಕ್‌ಚೇನ್‌ಗಳಲ್ಲಿ ಪರಿಶೀಲನೆ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ, ಯಾವುದೇ ಭಾಗವಹಿಸುವವರು ಪ್ರೋಟೋಕಾಲ್‌ನ ನಿಖರತೆಯನ್ನು ಸುಲಭವಾಗಿ ಪರಿಶೀಲಿಸಬೇಕು, ಆದ್ದರಿಂದ ಪರಿಶೀಲನೆ ಕಾರ್ಯದ ವೇಗದ ಅವಶ್ಯಕತೆಗಳು ತುಂಬಾ ಗಂಭೀರವಾಗಿದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು. . ಈ ಆಯ್ಕೆಯಲ್ಲಿ, ಪರಿಶೀಲನೆಯು ವಹಿವಾಟಿನ ಮಿತಿಯಲ್ಲಿ (0.5 ಸೆಕೆಂಡುಗಳು) ಹೊಂದಿಕೆಯಾಗದ ಕಾರಣ ಆಯ್ಕೆಯು ನಿಷ್ಪರಿಣಾಮಕಾರಿಯಾಗಿದೆ.

ಪರಿಶೀಲನಾ ದಕ್ಷತೆಯು ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ಸಾಮಾನ್ಯವಾಗಿ ಯಾವುದೇ ಸುಧಾರಿತ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಸ್ಕೀಮ್‌ಗಳ ಬಳಕೆಗೆ ಪ್ರಮುಖ ಅವಶ್ಯಕತೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಪುರಾವೆಗಳನ್ನು ರಚಿಸುವುದು, ಸಂದೇಶಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು - ಈ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಆಫ್-ಚೈನ್ ತೆಗೆದುಕೊಳ್ಳಬಹುದು ಮತ್ತು ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯ ಕಂಪ್ಯೂಟರ್‌ಗಳಲ್ಲಿ ನಿರ್ವಹಿಸಬಹುದು, ಆದರೆ ಪರಿಶೀಲನೆಯನ್ನು ಬೈಪಾಸ್ ಮಾಡಲಾಗುವುದಿಲ್ಲ - ಇದು PVRB ಗೆ ಮತ್ತೊಂದು ಪ್ರಮುಖ ಅವಶ್ಯಕತೆಯಾಗಿದೆ.

PVRB ಮತ್ತು ಮಿತಿ ಸಹಿಗಳು

ರಹಸ್ಯ ಹಂಚಿಕೆ ಯೋಜನೆಯೊಂದಿಗೆ ಪರಿಚಯವಾದ ನಂತರ, ನಾವು "ಥ್ರೆಶೋಲ್ಡ್" ಎಂಬ ಕೀವರ್ಡ್‌ನಿಂದ ಒಟ್ಟುಗೂಡಿದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಸಂಪೂರ್ಣ ವರ್ಗವನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ. ಕೆಲವು ಮಾಹಿತಿಯ ಬಹಿರಂಗಪಡಿಸುವಿಕೆಗೆ N ನಿಂದ M ಪ್ರಾಮಾಣಿಕ ಭಾಗವಹಿಸುವವರ ಭಾಗವಹಿಸುವಿಕೆ ಅಗತ್ಯವಿರುವಾಗ ಮತ್ತು ಪ್ರಾಮಾಣಿಕ ಭಾಗವಹಿಸುವವರ ಸೆಟ್ N ನ ಅನಿಯಂತ್ರಿತ ಉಪವಿಭಾಗವಾಗಿರಬಹುದು, ನಾವು "ಮಿತಿ" ಯೋಜನೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇವೆ. "ಕೊನೆಯ ನಟ" ಸಮಸ್ಯೆಯನ್ನು ನಿಭಾಯಿಸಲು ಅವರು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತಾರೆ, ಈಗ ಆಕ್ರಮಣಕಾರನು ತನ್ನ ರಹಸ್ಯದ ಭಾಗವನ್ನು ಬಹಿರಂಗಪಡಿಸದಿದ್ದರೆ, ಇನ್ನೊಬ್ಬ, ಪ್ರಾಮಾಣಿಕ ಪಾಲ್ಗೊಳ್ಳುವವರು ಅವನಿಗೆ ಅದನ್ನು ಮಾಡುತ್ತಾರೆ. ಭಾಗವಹಿಸುವವರಲ್ಲಿ ಕೆಲವರು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹಾಳುಮಾಡಿದರೂ ಸಹ, ಈ ಯೋಜನೆಗಳು ಒಂದೇ ಒಂದು ಅರ್ಥದಲ್ಲಿ ಒಪ್ಪಂದವನ್ನು ಅನುಮತಿಸುತ್ತವೆ.

ನಿರ್ಣಾಯಕ ಸಹಿಗಳು ಮತ್ತು ಮಿತಿ ಯೋಜನೆಗಳ ಸಂಯೋಜನೆಯು PVRB ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಅತ್ಯಂತ ಅನುಕೂಲಕರ ಮತ್ತು ಭರವಸೆಯ ಯೋಜನೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು - ಇವು ನಿರ್ಣಾಯಕ ಮಿತಿ ಸಹಿಗಳಾಗಿವೆ. ಇಲ್ಲಿ ಲೇಖನ ಥ್ರೆಶೋಲ್ಡ್ ಸಿಗ್ನೇಚರ್‌ಗಳ ವಿವಿಧ ಉಪಯೋಗಗಳ ಬಗ್ಗೆ, ಮತ್ತು ಇಲ್ಲಿ ಇನ್ನೊಂದು ಒಳ್ಳೆಯದು ದೀರ್ಘ ಓದು ಡ್ಯಾಶ್ ನಿಂದ.

ಕೊನೆಯ ಲೇಖನವು BLS ಸಹಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ (BLS ಎಂದರೆ Boneh-Lynn-Shacham, ನೋಡು ಲೇಖನ), ಇದು ಪ್ರೋಗ್ರಾಮರ್‌ಗಳಿಗೆ ಬಹಳ ಮುಖ್ಯವಾದ ಮತ್ತು ಅತ್ಯಂತ ಅನುಕೂಲಕರ ಗುಣಮಟ್ಟವನ್ನು ಹೊಂದಿದೆ - ಸಾರ್ವಜನಿಕ, ರಹಸ್ಯ, ಸಾರ್ವಜನಿಕ ಕೀಗಳು ಮತ್ತು BLS ಸಹಿಗಳನ್ನು ಸರಳವಾದ ಗಣಿತದ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪರಸ್ಪರ ಸಂಯೋಜಿಸಬಹುದು, ಆದರೆ ಅವುಗಳ ಸಂಯೋಜನೆಗಳು ಮಾನ್ಯವಾದ ಕೀಗಳು ಮತ್ತು ಸಹಿಗಳಾಗಿ ಉಳಿಯುತ್ತವೆ, ಇದು ನಿಮಗೆ ಅನೇಕವನ್ನು ಸುಲಭವಾಗಿ ಒಟ್ಟುಗೂಡಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಸಹಿಗಳು ಒಂದಾಗಿ ಮತ್ತು ಹಲವು ಸಾರ್ವಜನಿಕ ಕೀಗಳನ್ನು ಒಂದಾಗಿ. ಅವು ನಿರ್ಣಾಯಕವಾಗಿವೆ ಮತ್ತು ಅದೇ ಇನ್‌ಪುಟ್ ಡೇಟಾಗೆ ಅದೇ ಫಲಿತಾಂಶವನ್ನು ನೀಡುತ್ತವೆ. ಈ ಗುಣಮಟ್ಟಕ್ಕೆ ಧನ್ಯವಾದಗಳು, BLS ಸಹಿಗಳ ಸಂಯೋಜನೆಗಳು ಸ್ವತಃ ಮಾನ್ಯವಾದ ಕೀಗಳಾಗಿವೆ, ಇದು Mth ನಿಂದ ತೆರೆಯುವವರೆಗೆ Mth ಭಾಗವಹಿಸುವವರು ನಿರ್ಣಾಯಕ, ಸಾರ್ವಜನಿಕವಾಗಿ ಪರಿಶೀಲಿಸಬಹುದಾದ ಮತ್ತು ಅನಿರೀಕ್ಷಿತವಾದ ಒಂದೇ ಒಂದು ಸಹಿಯನ್ನು ಉತ್ಪಾದಿಸುವ ಆಯ್ಕೆಯ ಅನುಷ್ಠಾನಕ್ಕೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಭಾಗವಹಿಸುವವರು.

ಥ್ರೆಶೋಲ್ಡ್ BLS ಸಹಿಯನ್ನು ಹೊಂದಿರುವ ಯೋಜನೆಯಲ್ಲಿ, ಪ್ರತಿಯೊಬ್ಬ ಭಾಗವಹಿಸುವವರು BLS ಅನ್ನು ಬಳಸಿಕೊಂಡು ಏನನ್ನಾದರೂ ಸಹಿ ಮಾಡುತ್ತಾರೆ (ಉದಾಹರಣೆಗೆ, ಹಿಂದಿನ ಯಾದೃಚ್ಛಿಕ), ಮತ್ತು ಸಾಮಾನ್ಯ ಮಿತಿ ಸಹಿ ಅಪೇಕ್ಷಿತ ಯಾದೃಚ್ಛಿಕವಾಗಿರುತ್ತದೆ. BLS ಸಹಿಗಳ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಗುಣಲಕ್ಷಣಗಳು ಯಾದೃಚ್ಛಿಕ ಗುಣಮಟ್ಟದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುತ್ತವೆ, ಮಿತಿ ಭಾಗವು "ಕೊನೆಯ-ನಟ" ದಿಂದ ರಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಕೀಗಳ ವಿಶಿಷ್ಟ ಸಂಯೋಜನೆಯು ಪ್ರೋಟೋಕಾಲ್ ಸಂದೇಶಗಳ ಸಮರ್ಥ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯನ್ನು ಅನುಮತಿಸುವ ಹಲವು ಆಸಕ್ತಿದಾಯಕ ಅಲ್ಗಾರಿದಮ್ಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ. .

ಆದ್ದರಿಂದ, ನೀವು ನಿಮ್ಮ ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ PVRB ಅನ್ನು ನಿರ್ಮಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಹೆಚ್ಚಾಗಿ BLS ಥ್ರೆಶೋಲ್ಡ್ ಸಿಗ್ನೇಚರ್ಸ್ ಸ್ಕೀಮ್‌ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವಿರಿ, ಹಲವಾರು ಯೋಜನೆಗಳು ಈಗಾಗಲೇ ಇದನ್ನು ಬಳಸುತ್ತಿವೆ. ಉದಾಹರಣೆಗೆ, DFinity (ಇಲ್ಲಿ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಮಾನದಂಡ, ಮತ್ತು ಇಲ್ಲಿ ಪರಿಶೀಲಿಸಬಹುದಾದ ರಹಸ್ಯ ಹಂಚಿಕೆಯ ಉದಾಹರಣೆ ಅನುಷ್ಠಾನ), ಅಥವಾ Keep.network (ಇಲ್ಲಿ ಅವುಗಳ ಯಾದೃಚ್ಛಿಕ ದಾರಿದೀಪವಾಗಿದೆ ಹಳದಿ ಕಾಗದ, ಮತ್ತು ಇಲ್ಲಿ ಉದಾಹರಣೆ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಪೂರೈಸುವ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದ).

PVRB ಯ ಅನುಷ್ಠಾನ

ದುರದೃಷ್ಟವಶಾತ್, PVRB ಬ್ಲಾಕ್‌ಚೈನ್‌ಗಳಲ್ಲಿ ಅದರ ಸುರಕ್ಷತೆ ಮತ್ತು ಸ್ಥಿರತೆಯನ್ನು ಸಾಬೀತುಪಡಿಸಿದ ಸಿದ್ಧ-ಸಿದ್ಧ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಾವು ಇನ್ನೂ ನೋಡುತ್ತಿಲ್ಲ. ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಸಿದ್ಧವಾಗಿದ್ದರೂ, ತಾಂತ್ರಿಕವಾಗಿ ಅವುಗಳನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪರಿಹಾರಗಳಿಗೆ ಅನ್ವಯಿಸುವುದು ಸುಲಭವಲ್ಲ. ಕೇಂದ್ರೀಕೃತ ವ್ಯವಸ್ಥೆಗಳಿಗೆ, PVRB ಅರ್ಥವಿಲ್ಲ, ಮತ್ತು ವಿಕೇಂದ್ರೀಕೃತವಾದವುಗಳು ಎಲ್ಲಾ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳಲ್ಲಿ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸೀಮಿತವಾಗಿವೆ: CPU, ಮೆಮೊರಿ, ಸಂಗ್ರಹಣೆ, I/O. PVRB ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು ಕನಿಷ್ಠ ಕೆಲವು ಕಾರ್ಯಸಾಧ್ಯವಾದ ಬ್ಲಾಕ್‌ಚೈನ್‌ಗಾಗಿ ಎಲ್ಲಾ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವ ಯಾವುದನ್ನಾದರೂ ರಚಿಸಲು ವಿಭಿನ್ನ ಪ್ರೋಟೋಕಾಲ್‌ಗಳ ಸಂಯೋಜನೆಯಾಗಿದೆ. ಒಂದು ಪ್ರೋಟೋಕಾಲ್ ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ, ಆದರೆ ಆರ್‌ಪಿಗಳ ನಡುವೆ ಹೆಚ್ಚಿನ ಸಂದೇಶಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆದರೆ ಇನ್ನೊಂದಕ್ಕೆ ಕೆಲವೇ ಸಂದೇಶಗಳು ಬೇಕಾಗುತ್ತವೆ, ಆದರೆ ಪುರಾವೆಯನ್ನು ರಚಿಸುವುದು ಹತ್ತಾರು ನಿಮಿಷಗಳು ಅಥವಾ ಗಂಟೆಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವ ಕಾರ್ಯವಾಗಿದೆ.

ಗುಣಮಟ್ಟದ PVRB ಅನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ ನೀವು ಪರಿಗಣಿಸಬೇಕಾದ ಅಂಶಗಳನ್ನು ನಾನು ಪಟ್ಟಿ ಮಾಡುತ್ತೇನೆ:

• ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಶಕ್ತಿ. ನಿಮ್ಮ PVRB ಕಟ್ಟುನಿಟ್ಟಾಗಿ ನಿಷ್ಪಕ್ಷಪಾತವಾಗಿರಬೇಕು, ಒಂದೇ ಒಂದು ಬಿಟ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುವ ಸಾಮರ್ಥ್ಯವಿಲ್ಲ. ಕೆಲವು ಯೋಜನೆಗಳಲ್ಲಿ ಇದು ಹಾಗಲ್ಲ, ಆದ್ದರಿಂದ ಕ್ರಿಪ್ಟೋಗ್ರಾಫರ್ ಅನ್ನು ಕರೆ ಮಾಡಿ
• "ಕೊನೆಯ ನಟ" ಸಮಸ್ಯೆ. ನಿಮ್ಮ PVRB ದಾಳಿಗಳಿಗೆ ನಿರೋಧಕವಾಗಿರಬೇಕು, ಅಲ್ಲಿ ದಾಳಿಕೋರರು ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ RP ಗಳನ್ನು ನಿಯಂತ್ರಿಸಬಹುದು ಎರಡು ಫಲಿತಾಂಶಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು.
• ಪ್ರೋಟೋಕಾಲ್ ವಿಧ್ವಂಸಕ ಸಮಸ್ಯೆ. ನಿಮ್ಮ PVRB ದಾಳಿಗಳಿಗೆ ನಿರೋಧಕವಾಗಿರಬೇಕು, ಅಲ್ಲಿ ಆಕ್ರಮಣಕಾರರು ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ RP ಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತಾರೆ ಯಾದೃಚ್ಛಿಕವಾಗಿರಬೇಕೇ ಅಥವಾ ಬೇಡವೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತಾರೆ ಮತ್ತು ಖಾತರಿಪಡಿಸಬಹುದು ಅಥವಾ ಇದರ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವ ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ
• ಸಂದೇಶಗಳ ಸಂಖ್ಯೆ ಸಮಸ್ಯೆ. ನಿಮ್ಮ RP ಗಳು ಬ್ಲಾಕ್‌ಚೈನ್‌ಗೆ ಕನಿಷ್ಠ ಸಂದೇಶಗಳನ್ನು ಕಳುಹಿಸಬೇಕು ಮತ್ತು "ನಾನು ಕೆಲವು ಮಾಹಿತಿಯನ್ನು ಕಳುಹಿಸಿದ್ದೇನೆ, ನಿರ್ದಿಷ್ಟ ಭಾಗವಹಿಸುವವರ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ ನಾನು ಕಾಯುತ್ತಿದ್ದೇನೆ" ನಂತಹ ಸಂದರ್ಭಗಳಂತಹ ಸಿಂಕ್ರೊನಸ್ ಕ್ರಿಯೆಗಳನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ತಪ್ಪಿಸಬೇಕು. p2p ನೆಟ್‌ವರ್ಕ್‌ಗಳಲ್ಲಿ, ವಿಶೇಷವಾಗಿ ಭೌಗೋಳಿಕವಾಗಿ ಚದುರಿದವುಗಳಲ್ಲಿ, ನೀವು ತ್ವರಿತ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಲೆಕ್ಕಿಸಬಾರದು
• ಕಂಪ್ಯೂಟೇಶನಲ್ ಸಂಕೀರ್ಣತೆಯ ಸಮಸ್ಯೆ. PVRB ಆನ್-ಚೈನ್‌ನ ಯಾವುದೇ ಹಂತದ ಪರಿಶೀಲನೆಯು ಅತ್ಯಂತ ಸುಲಭವಾಗಿರಬೇಕು, ಏಕೆಂದರೆ ಇದನ್ನು ನೆಟ್‌ವರ್ಕ್‌ನ ಎಲ್ಲಾ ಪೂರ್ಣ ಕ್ಲೈಂಟ್‌ಗಳು ನಿರ್ವಹಿಸುತ್ತಾರೆ. ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದವನ್ನು ಬಳಸಿಕೊಂಡು ಅನುಷ್ಠಾನವನ್ನು ಮಾಡಿದರೆ, ವೇಗದ ಅವಶ್ಯಕತೆಗಳು ತುಂಬಾ ಕಟ್ಟುನಿಟ್ಟಾಗಿರುತ್ತವೆ
• ಪ್ರವೇಶಿಸುವಿಕೆ ಮತ್ತು ಜೀವಂತಿಕೆಯ ಸಮಸ್ಯೆ. ನಿಮ್ಮ PVRB ನೆಟ್‌ವರ್ಕ್‌ನ ಭಾಗವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಲಭ್ಯವಿಲ್ಲದಿರುವಾಗ ಮತ್ತು ಆರ್‌ಪಿಯ ಭಾಗವು ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುವ ಸಂದರ್ಭಗಳಿಗೆ ಚೇತರಿಸಿಕೊಳ್ಳಲು ಶ್ರಮಿಸಬೇಕು
• ವಿಶ್ವಾಸಾರ್ಹ ಸೆಟಪ್ ಮತ್ತು ಆರಂಭಿಕ ಕೀ ವಿತರಣೆಯ ಸಮಸ್ಯೆ. ನಿಮ್ಮ PVRB ಪ್ರೋಟೋಕಾಲ್‌ನ ಪ್ರಾಥಮಿಕ ಸೆಟಪ್ ಅನ್ನು ಬಳಸಿದರೆ, ಇದು ಪ್ರತ್ಯೇಕ ದೊಡ್ಡ ಮತ್ತು ಗಂಭೀರ ಕಥೆಯಾಗಿದೆ. ಇಲ್ಲಿ ಉದಾಹರಣೆ. ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು ಭಾಗವಹಿಸುವವರು ತಮ್ಮ ಕೀಗಳನ್ನು ಪರಸ್ಪರ ಹೇಳಬೇಕಾದರೆ, ಭಾಗವಹಿಸುವವರ ಸಂಯೋಜನೆಯು ಬದಲಾದರೆ ಇದು ಸಮಸ್ಯೆಯಾಗಿದೆ
• ಅಭಿವೃದ್ಧಿ ಸಮಸ್ಯೆಗಳು. ಅಗತ್ಯವಿರುವ ಭಾಷೆಗಳಲ್ಲಿ ಗ್ರಂಥಾಲಯಗಳ ಲಭ್ಯತೆ, ಅವುಗಳ ಭದ್ರತೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ, ಪ್ರಚಾರ, ಸಂಕೀರ್ಣ ಪರೀಕ್ಷೆಗಳು ಇತ್ಯಾದಿ.

ಉದಾಹರಣೆಗೆ, ಥ್ರೆಶೋಲ್ಡ್ BLS ಸಹಿಗಳು ಗಮನಾರ್ಹವಾದ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿವೆ - ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ಭಾಗವಹಿಸುವವರು ಪರಸ್ಪರ ಕೀಗಳನ್ನು ವಿತರಿಸಬೇಕು, ಮಿತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಗುಂಪನ್ನು ಸಂಘಟಿಸಬೇಕು. ಇದರರ್ಥ ವಿಕೇಂದ್ರೀಕೃತ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಕನಿಷ್ಠ ಒಂದು ಸುತ್ತಿನ ವಿನಿಮಯವು ಕಾಯಬೇಕಾಗುತ್ತದೆ, ಮತ್ತು ಉತ್ಪತ್ತಿಯಾದ ರಾಂಡ್, ಉದಾಹರಣೆಗೆ, ಆಟಗಳಲ್ಲಿ ಅಗತ್ಯವಾಗಿದೆ, ಬಹುತೇಕ ನೈಜ ಸಮಯದಲ್ಲಿ, ಇದರರ್ಥ ಪ್ರೋಟೋಕಾಲ್ನ ವಿಧ್ವಂಸಕತೆಯು ಈ ಹಂತದಲ್ಲಿ ಸಾಧ್ಯ , ಮತ್ತು ಮಿತಿ ಯೋಜನೆಯ ಅನುಕೂಲಗಳು ಕಳೆದುಹೋಗಿವೆ. ಈ ಸಮಸ್ಯೆಯು ಹಿಂದಿನ ಸಮಸ್ಯೆಗಳಿಗಿಂತ ಈಗಾಗಲೇ ಸರಳವಾಗಿದೆ, ಆದರೆ ಇನ್ನೂ ಮಿತಿ ಗುಂಪುಗಳ ರಚನೆಗೆ ಪ್ರತ್ಯೇಕ ಕಾರ್ಯವಿಧಾನದ ಅಭಿವೃದ್ಧಿಯ ಅಗತ್ಯವಿರುತ್ತದೆ, ಇದನ್ನು ಅನುಸರಿಸದ ಭಾಗವಹಿಸುವವರಿಂದ ಠೇವಣಿ ಮತ್ತು ಹಣವನ್ನು ಹಿಂತೆಗೆದುಕೊಳ್ಳುವ ಮೂಲಕ (ಕತ್ತರಿಸಿ) ಆರ್ಥಿಕವಾಗಿ ರಕ್ಷಿಸಬೇಕಾಗುತ್ತದೆ. ಶಿಷ್ಟಾಚಾರ. ಅಲ್ಲದೆ, ಸ್ವೀಕಾರಾರ್ಹ ಮಟ್ಟದ ಭದ್ರತೆಯೊಂದಿಗೆ BLS ಪರಿಶೀಲನೆಯು ಸರಳವಾಗಿ ಸರಿಹೊಂದುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ, ಪ್ರಮಾಣಿತ EOS ಅಥವಾ Ethereum ವಹಿವಾಟಿಗೆ - ಪರಿಶೀಲನೆಗೆ ಸಾಕಷ್ಟು ಸಮಯವಿಲ್ಲ. ಒಪ್ಪಂದದ ಕೋಡ್ WebAssembly ಅಥವಾ EVM ಆಗಿದೆ, ಇದನ್ನು ವರ್ಚುವಲ್ ಯಂತ್ರದಿಂದ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ. ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಕಾರ್ಯಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಅಳವಡಿಸಲಾಗಿಲ್ಲ (ಇನ್ನೂ), ಮತ್ತು ಸಾಂಪ್ರದಾಯಿಕ ಕ್ರಿಪ್ಟೋಗ್ರಾಫಿಕ್ ಲೈಬ್ರರಿಗಳಿಗಿಂತ ಹತ್ತಾರು ಪಟ್ಟು ನಿಧಾನವಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಅನೇಕ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಕೇವಲ ಪ್ರಮುಖ ಪರಿಮಾಣದ ಆಧಾರದ ಮೇಲೆ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ, ಉದಾಹರಣೆಗೆ RSA ಗಾಗಿ 1024 ಮತ್ತು 2048 ಬಿಟ್‌ಗಳು, Bitcoin ಮತ್ತು Ethereum ನಲ್ಲಿ ಪ್ರಮಾಣಿತ ವಹಿವಾಟು ಸಹಿಗಿಂತ 4-8 ಪಟ್ಟು ದೊಡ್ಡದಾಗಿದೆ.

ವಿಭಿನ್ನ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ ಅಳವಡಿಕೆಗಳ ಉಪಸ್ಥಿತಿಯು ಸಹ ಒಂದು ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ - ಅದರಲ್ಲಿ ಕೆಲವು, ವಿಶೇಷವಾಗಿ ಹೊಸ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ. ಒಮ್ಮತಕ್ಕೆ ಏಕೀಕರಣದ ಆಯ್ಕೆಯು ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಭಾಷೆಯಲ್ಲಿ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬರೆಯುವ ಅಗತ್ಯವಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಗೋ ಫಾರ್ ಗೆತ್‌ನಲ್ಲಿ, ರಸ್ಟ್ ಫಾರ್ ಪ್ಯಾರಿಟಿಯಲ್ಲಿ, ಇಒಎಸ್‌ಗಾಗಿ ಸಿ ++ ನಲ್ಲಿ ಕೋಡ್‌ಗಾಗಿ ನೋಡಬೇಕಾಗುತ್ತದೆ. ಪ್ರತಿಯೊಬ್ಬರೂ ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಕೋಡ್‌ಗಾಗಿ ನೋಡಬೇಕು ಮತ್ತು ಜಾವಾಸ್ಕ್ರಿಪ್ಟ್ ಮತ್ತು ಕ್ರಿಪ್ಟೋಗ್ರಫಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ನಿಕಟ ಸ್ನೇಹಿತರಲ್ಲದ ಕಾರಣ, ವೆಬ್‌ಅಸೆಂಬ್ಲಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಅದು ಈಗ ಮುಂದಿನ ಪ್ರಮುಖ ಇಂಟರ್ನೆಟ್ ಮಾನದಂಡವಾಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ನಾನು ಹಿಂದಿನದರಲ್ಲಿ ಆಶಿಸುತ್ತೇನೆ ಲೇಖನ ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಗಳನ್ನು ರಚಿಸುವುದು ವಿಕೇಂದ್ರೀಕೃತ ನೆಟ್‌ವರ್ಕ್‌ಗಳ ಜೀವನದ ಹಲವು ಅಂಶಗಳಿಗೆ ನಿರ್ಣಾಯಕವಾಗಿದೆ ಎಂದು ನಾನು ನಿಮಗೆ ಮನವರಿಕೆ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಈ ಲೇಖನದೊಂದಿಗೆ ನಾನು ಈ ಕಾರ್ಯವು ಅತ್ಯಂತ ಮಹತ್ವಾಕಾಂಕ್ಷೆಯ ಮತ್ತು ಕಷ್ಟಕರವಾಗಿದೆ ಎಂದು ತೋರಿಸಿದೆ, ಆದರೆ ಉತ್ತಮ ಪರಿಹಾರಗಳು ಈಗಾಗಲೇ ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಪ್ರೋಟೋಕಾಲ್‌ನ ಅಂತಿಮ ವಿನ್ಯಾಸವು ಸೆಟಪ್‌ನಿಂದ ದೋಷ ಎಮ್ಯುಲೇಶನ್‌ವರೆಗಿನ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಬೃಹತ್ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸಿದ ನಂತರವೇ ಸಾಧ್ಯ, ಆದ್ದರಿಂದ ನೀವು ತಂಡದ ವೈಟ್‌ಪೇಪರ್‌ಗಳು ಮತ್ತು ಲೇಖನಗಳಲ್ಲಿ ಸಿದ್ಧ ಪಾಕವಿಧಾನಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವ ಸಾಧ್ಯತೆಯಿಲ್ಲ, ಮತ್ತು ನಾವು ಖಂಡಿತವಾಗಿಯೂ ಮಾಡುವುದಿಲ್ಲ ಮುಂದಿನ ವರ್ಷ ಅಥವಾ ಎರಡು ವರ್ಷಗಳಲ್ಲಿ ನಿರ್ಧರಿಸಿ "ಈ ರೀತಿ ಮಾಡಿ, ನಿಖರವಾಗಿ ಸರಿ" ಎಂದು ಬರೆಯಿರಿ.

ವಿದಾಯ, ಅಭಿವೃದ್ಧಿಗೊಳ್ಳುತ್ತಿರುವ ಬ್ಲಾಕ್‌ಚೈನ್‌ನಲ್ಲಿರುವ ನಮ್ಮ PVRB ಗಾಗಿ Haya,, ನಾವು ಥ್ರೆಶೋಲ್ಡ್ BLS ಸಹಿಗಳನ್ನು ಬಳಸುವುದನ್ನು ನಿರ್ಧರಿಸಿದ್ದೇವೆ, ಸ್ವೀಕಾರಾರ್ಹ ಮಟ್ಟದ ಭದ್ರತೆಯೊಂದಿಗೆ ಸ್ಮಾರ್ಟ್ ಒಪ್ಪಂದಗಳಲ್ಲಿ ಪರಿಶೀಲನೆ ಇನ್ನೂ ಸಾಧ್ಯವಾಗದ ಕಾರಣ, ಒಮ್ಮತದ ಮಟ್ಟದಲ್ಲಿ PVRB ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ನಾವು ಯೋಜಿಸಿದ್ದೇವೆ. ನಾವು ಏಕಕಾಲದಲ್ಲಿ ಎರಡು ಸ್ಕೀಮ್‌ಗಳನ್ನು ಬಳಸುವ ಸಾಧ್ಯತೆಯಿದೆ: ಮೊದಲನೆಯದಾಗಿ, ದೀರ್ಘಾವಧಿಯ ಯಾದೃಚ್ಛಿಕ_ಬೀಜವನ್ನು ರಚಿಸಲು ದುಬಾರಿ ರಹಸ್ಯ ಹಂಚಿಕೆ, ಮತ್ತು ನಂತರ ನಾವು ನಿರ್ಣಾಯಕ ಮಿತಿ BLS ಸಹಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಹೆಚ್ಚಿನ ಆವರ್ತನದ ಯಾದೃಚ್ಛಿಕ ಉತ್ಪಾದನೆಗೆ ಆಧಾರವಾಗಿ ಬಳಸುತ್ತೇವೆ, ಬಹುಶಃ ನಾವು ನಮ್ಮನ್ನು ಮಾತ್ರ ಸೀಮಿತಗೊಳಿಸುತ್ತೇವೆ. ಯೋಜನೆಗಳಲ್ಲಿ ಒಂದು. ದುರದೃಷ್ಟವಶಾತ್, ಪ್ರೋಟೋಕಾಲ್ ಏನೆಂದು ಮುಂಚಿತವಾಗಿ ಹೇಳುವುದು ಅಸಾಧ್ಯ; ಒಂದೇ ಒಳ್ಳೆಯದು, ವಿಜ್ಞಾನದಲ್ಲಿ, ಎಂಜಿನಿಯರಿಂಗ್ ಸಮಸ್ಯೆಗಳಲ್ಲಿ, ನಕಾರಾತ್ಮಕ ಫಲಿತಾಂಶವೂ ಒಂದು ಫಲಿತಾಂಶವಾಗಿದೆ, ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಪ್ರತಿ ಹೊಸ ಪ್ರಯತ್ನವು ಮತ್ತೊಂದು ಹಂತವಾಗಿದೆ. ಸಮಸ್ಯೆಯಲ್ಲಿ ತೊಡಗಿರುವ ಪ್ರತಿಯೊಬ್ಬರ ಸಂಶೋಧನೆ. ವ್ಯಾಪಾರದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪೂರೈಸಲು, ನಾವು ನಿರ್ದಿಷ್ಟ ಪ್ರಾಯೋಗಿಕ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತೇವೆ - ಗೇಮಿಂಗ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಎಂಟ್ರೊಪಿಯ ವಿಶ್ವಾಸಾರ್ಹ ಮೂಲದೊಂದಿಗೆ ಒದಗಿಸುವುದು, ಆದ್ದರಿಂದ ನಾವು ಬ್ಲಾಕ್‌ಚೈನ್‌ನತ್ತ ಗಮನ ಹರಿಸಬೇಕು, ನಿರ್ದಿಷ್ಟವಾಗಿ ಸರಣಿ ಅಂತಿಮತೆ ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ಆಡಳಿತದ ಸಮಸ್ಯೆಗಳು.

ಮತ್ತು ನಾವು ಇನ್ನೂ ಬ್ಲಾಕ್‌ಚೈನ್‌ಗಳಲ್ಲಿ ಸಾಬೀತಾಗಿರುವ ನಿರೋಧಕ PVRB ಅನ್ನು ನೋಡದಿದ್ದರೂ ಸಹ, ನೈಜ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು, ಬಹು ಲೆಕ್ಕಪರಿಶೋಧನೆಗಳು, ಲೋಡ್‌ಗಳು ಮತ್ತು ಸಹಜವಾಗಿ, ನೈಜ ದಾಳಿಗಳಿಂದ ಪರೀಕ್ಷಿಸಲು ಸಾಕಷ್ಟು ಸಮಯ ಬಳಸಲಾಗುತ್ತಿತ್ತು, ಆದರೆ ಸಂಭವನೀಯ ಮಾರ್ಗಗಳ ಸಂಖ್ಯೆಯು ಅದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ ಒಂದು ಪರಿಹಾರ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ, ಮತ್ತು ಈ ಕ್ರಮಾವಳಿಗಳಲ್ಲಿ ಯಾವುದು ಅಂತಿಮವಾಗಿ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ಫಲಿತಾಂಶಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ ಮತ್ತು ಇಂಜಿನಿಯರ್‌ಗಳು ಒಂದೇ ರೇಕ್‌ನಲ್ಲಿ ಎರಡು ಬಾರಿ ಹೆಜ್ಜೆ ಹಾಕದಂತೆ ಅನುಮತಿಸುವ ಲೇಖನಗಳು ಮತ್ತು ಕೋಡ್‌ಗಳಿಗಾಗಿ ಈ ಸಮಸ್ಯೆಯ ಕುರಿತು ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಇತರ ತಂಡಗಳಿಗೆ ಧನ್ಯವಾದಗಳನ್ನು ಅರ್ಪಿಸುತ್ತೇವೆ.

ಆದ್ದರಿಂದ, ನೀವು ವಿಕೇಂದ್ರೀಕೃತ ಯಾದೃಚ್ಛಿಕ ವಿನ್ಯಾಸದ ಪ್ರೋಗ್ರಾಮರ್ ಅನ್ನು ಭೇಟಿಯಾದಾಗ, ಗಮನ ಮತ್ತು ಕಾಳಜಿ ವಹಿಸಿ ಮತ್ತು ಅಗತ್ಯವಿದ್ದರೆ ಮಾನಸಿಕ ಸಹಾಯವನ್ನು ಒದಗಿಸಿ :)

ಮೂಲ: www.habr.com