ನಾವು ಪರಸ್ಪರ ನಂಬದಿದ್ದರೆ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಸಾಧ್ಯವೇ? ಭಾಗ 1

ಹಲೋ, ಹಬ್ರ್!

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

ಒಬ್ಬರನ್ನೊಬ್ಬರು ನಂಬದ ಪಾಲ್ಗೊಳ್ಳುವವರಲ್ಲಿ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಗಳನ್ನು ರಚಿಸುವುದು ಏಕೆ ಅಗತ್ಯ? ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರದೇಶವು ವಿಕೇಂದ್ರೀಕೃತ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಪಾಲ್ಗೊಳ್ಳುವವರಿಂದ ಪಂತವನ್ನು ಸ್ವೀಕರಿಸುವ ಮತ್ತು 49% ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ಮೊತ್ತವನ್ನು ದ್ವಿಗುಣಗೊಳಿಸುವ ಅಥವಾ 51% ಸಂಭವನೀಯತೆಯೊಂದಿಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್ ನಿಷ್ಪಕ್ಷಪಾತವಾಗಿ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯನ್ನು ಸ್ವೀಕರಿಸಿದರೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆಕ್ರಮಣಕಾರರು ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯ ಜನರೇಟರ್‌ನ ಫಲಿತಾಂಶದ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಿದರೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಪಾವತಿಯನ್ನು ಪಡೆಯುವ ಅವಕಾಶವನ್ನು ಸ್ವಲ್ಪ ಹೆಚ್ಚಿಸಿದರೆ, ಅವನು ಅದನ್ನು ಸುಲಭವಾಗಿ ನಾಶಪಡಿಸುತ್ತಾನೆ.

ನಾವು ವಿತರಿಸಿದ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯ ಉತ್ಪಾದನೆಯ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಿದಾಗ, ಅದು ಮೂರು ಗುಣಲಕ್ಷಣಗಳನ್ನು ಹೊಂದಲು ನಾವು ಬಯಸುತ್ತೇವೆ:

1. ಅವನು ನಿಷ್ಪಕ್ಷಪಾತವಾಗಿರಬೇಕು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಯಾವುದೇ ಭಾಗವಹಿಸುವವರು ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯ ಜನರೇಟರ್ನ ಫಲಿತಾಂಶವನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪ್ರಭಾವಿಸಬಾರದು.

2. ಅವನು ಅನಿರೀಕ್ಷಿತವಾಗಿರಬೇಕು. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ಯಾವುದೇ ಭಾಗವಹಿಸುವವರು ಅದನ್ನು ಉತ್ಪಾದಿಸುವ ಮೊದಲು ಯಾವ ಸಂಖ್ಯೆಯನ್ನು ಉತ್ಪಾದಿಸಲಾಗುತ್ತದೆ (ಅಥವಾ ಅದರ ಯಾವುದೇ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಊಹಿಸಲು) ಊಹಿಸಲು ಸಾಧ್ಯವಾಗಬಾರದು.

3. ಪ್ರೋಟೋಕಾಲ್ ಕಾರ್ಯಸಾಧ್ಯವಾಗಿರಬೇಕು, ಅಂದರೆ, ನಿರ್ದಿಷ್ಟ ಶೇಕಡಾವಾರು ಭಾಗವಹಿಸುವವರು ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುತ್ತಾರೆ ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಿಲ್ಲಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ ಎಂಬ ಅಂಶಕ್ಕೆ ನಿರೋಧಕವಾಗಿರಬೇಕು.

ಈ ಲೇಖನದಲ್ಲಿ ನಾವು ಎರಡು ವಿಧಾನಗಳನ್ನು ನೋಡುತ್ತೇವೆ: RANDAO + VDF ಮತ್ತು ಎರೇಸರ್ ಕೋಡ್ಸ್ ವಿಧಾನ. ಮುಂದಿನ ಭಾಗದಲ್ಲಿ, ಮಿತಿ ಸಹಿಗಳ ಆಧಾರದ ಮೇಲೆ ನಾವು ವಿಧಾನವನ್ನು ವಿವರವಾಗಿ ಪರಿಶೀಲಿಸುತ್ತೇವೆ.

ಆದರೆ ಮೊದಲು, ಕಾರ್ಯಸಾಧ್ಯವಾದ, ಅನಿರೀಕ್ಷಿತ, ಆದರೆ ಪಕ್ಷಪಾತದ ಸರಳ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಬಳಸುವ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ನೋಡೋಣ.

RANDAO

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

ಸಂಖ್ಯೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಮೊದಲು ಹ್ಯಾಶ್‌ಗಳನ್ನು ಪ್ರಕಟಿಸುವ ಹಂತವು ಅವಶ್ಯಕವಾಗಿದೆ ಆದ್ದರಿಂದ ಆಕ್ರಮಣಕಾರರು ಇತರ ಭಾಗವಹಿಸುವವರ ಸಂಖ್ಯೆಯನ್ನು ನೋಡಿದ ನಂತರ ಅವರ ಸಂಖ್ಯೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಇದು ಅವನಿಗೆ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯ ಜನರೇಟರ್‌ನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ವಾಸ್ತವಿಕವಾಗಿ ಏಕಾಂಗಿಯಾಗಿ ನಿರ್ಧರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.

ಪ್ರೋಟೋಕಾಲ್ ಸಮಯದಲ್ಲಿ, ಭಾಗವಹಿಸುವವರು ಎರಡು ಬಾರಿ ಸಾಮಾನ್ಯ ನಿರ್ಧಾರಕ್ಕೆ ಬರಬೇಕಾಗುತ್ತದೆ (ಒಮ್ಮತ ಎಂದು ಕರೆಯುತ್ತಾರೆ) ಸಂಖ್ಯೆ. ಒಬ್ಬರನ್ನೊಬ್ಬರು ನಂಬದ ಭಾಗವಹಿಸುವವರ ನಡುವೆ ಅಂತಹ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು ಸುಲಭದ ಕೆಲಸವಲ್ಲ, ಮತ್ತು ಮುಂದಿನ ಲೇಖನಗಳಲ್ಲಿ ನಾವು ಅದಕ್ಕೆ ಹಿಂತಿರುಗುತ್ತೇವೆ; ಈ ಲೇಖನದಲ್ಲಿ ಅಂತಹ ಒಮ್ಮತದ ಅಲ್ಗಾರಿದಮ್ ನಮಗೆ ಲಭ್ಯವಿದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.

ನಾವು ಮೇಲೆ ವಿವರಿಸಿದ ಯಾವ ಗುಣಲಕ್ಷಣಗಳು RANDAO ಹೊಂದಿದೆ? ಇದು ಅನಿರೀಕ್ಷಿತವಾಗಿದೆ, ಆಧಾರವಾಗಿರುವ ಒಮ್ಮತದ ಪ್ರೋಟೋಕಾಲ್‌ನಂತೆಯೇ ಅದೇ ಹುರುಪು ಹೊಂದಿದೆ, ಆದರೆ ಇದು ಪಕ್ಷಪಾತವಾಗಿದೆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಹೇಳುವುದಾದರೆ, ಆಕ್ರಮಣಕಾರನು ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಗಮನಿಸಬಹುದು ಮತ್ತು ಇತರ ಭಾಗವಹಿಸುವವರು ತಮ್ಮ ಸಂಖ್ಯೆಯನ್ನು ಬಹಿರಂಗಪಡಿಸಿದ ನಂತರ, ಅವರು ತಮ್ಮ XOR ಅನ್ನು ಲೆಕ್ಕ ಹಾಕಬಹುದು ಮತ್ತು ಫಲಿತಾಂಶದ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಲು ಅವರ ಸಂಖ್ಯೆಯನ್ನು ಬಹಿರಂಗಪಡಿಸಬೇಕೆ ಅಥವಾ ಬೇಡವೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಬಹುದು. ಇದು ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯ ಜನರೇಟರ್‌ನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಏಕಾಂಗಿಯಾಗಿ ನಿರ್ಧರಿಸುವುದರಿಂದ ಆಕ್ರಮಣಕಾರರನ್ನು ತಡೆಯುತ್ತದೆ, ಅದು ಇನ್ನೂ 1 ಬಿಟ್ ಪ್ರಭಾವವನ್ನು ನೀಡುತ್ತದೆ. ಮತ್ತು ಆಕ್ರಮಣಕಾರರು ಹಲವಾರು ಭಾಗವಹಿಸುವವರನ್ನು ನಿಯಂತ್ರಿಸಿದರೆ, ಅವರು ನಿಯಂತ್ರಿಸುವ ಬಿಟ್‌ಗಳ ಸಂಖ್ಯೆಯು ಅವರ ನಿಯಂತ್ರಣದಲ್ಲಿರುವ ಭಾಗವಹಿಸುವವರ ಸಂಖ್ಯೆಗೆ ಸಮನಾಗಿರುತ್ತದೆ.

ಭಾಗವಹಿಸುವವರು ಕ್ರಮವಾಗಿ ಸಂಖ್ಯೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಅಗತ್ಯವಿರುವ ಮೂಲಕ ಆಕ್ರಮಣಕಾರರ ಪ್ರಭಾವವನ್ನು ಬಹಳವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು. ನಂತರ ಆಕ್ರಮಣಕಾರರು ಅದನ್ನು ಕೊನೆಯದಾಗಿ ತೆರೆದರೆ ಮಾತ್ರ ಫಲಿತಾಂಶದ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಪ್ರಭಾವವು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆಯಿದ್ದರೂ, ಅಲ್ಗಾರಿದಮ್ ಇನ್ನೂ ಪಕ್ಷಪಾತವಾಗಿದೆ.

RANDAO+VDF

RANDAO ನಿಷ್ಪಕ್ಷಪಾತ ಮಾಡಲು ಒಂದು ಮಾರ್ಗವೆಂದರೆ: ಎಲ್ಲಾ ಸಂಖ್ಯೆಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸಿದ ನಂತರ ಮತ್ತು XOR ಅನ್ನು ಲೆಕ್ಕಹಾಕಿದ ನಂತರ, ಅದರ ಫಲಿತಾಂಶವನ್ನು ಕಾರ್ಯದ ಇನ್‌ಪುಟ್‌ಗೆ ನೀಡಲಾಗುತ್ತದೆ, ಇದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ನೀವು ಸರಿಯಾಗಿ ಪರಿಶೀಲಿಸಲು ಅನುಮತಿಸುತ್ತದೆ ಬಹಳ ವೇಗವಾಗಿ ಲೆಕ್ಕಾಚಾರ.

(vdf_output, vdf_proof) = VDF_compute(input) // это очень медленно
correct = VDF_verify(input, vdf_output, vdf_proof) // это очень быстро

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

ಉತ್ತಮ VDF ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದು ತುಂಬಾ ಕಷ್ಟ. ಇತ್ತೀಚೆಗೆ ಹಲವಾರು ಪ್ರಗತಿಗಳು ಕಂಡುಬಂದಿವೆ, ಉದಾ. ಇದು и ಇದು, ಇದು ಪ್ರಾಯೋಗಿಕವಾಗಿ VDF ಅನ್ನು ಹೆಚ್ಚು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಮಾಡಿತು, ಮತ್ತು Ethereum 2.0 ದೀರ್ಘಾವಧಿಯಲ್ಲಿ RANDAO ಅನ್ನು VDF ಜೊತೆಗೆ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯ ಮೂಲವಾಗಿ ಬಳಸಲು ಯೋಜಿಸಿದೆ. ಈ ವಿಧಾನವು ಅನಿರೀಕ್ಷಿತ ಮತ್ತು ನಿಷ್ಪಕ್ಷಪಾತವಾಗಿದೆ ಎಂಬ ಅಂಶದ ಹೊರತಾಗಿ, ಕನಿಷ್ಠ ಇಬ್ಬರು ಭಾಗವಹಿಸುವವರು ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಲಭ್ಯವಿದ್ದರೆ ಅದು ಕಾರ್ಯಸಾಧ್ಯವಾಗುವ ಹೆಚ್ಚುವರಿ ಪ್ರಯೋಜನವನ್ನು ಹೊಂದಿದೆ (ಅಷ್ಟು ಕಡಿಮೆ ಸಂಖ್ಯೆಯ ಭಾಗವಹಿಸುವವರೊಂದಿಗೆ ವ್ಯವಹರಿಸುವಾಗ ಬಳಸಿದ ಒಮ್ಮತದ ಪ್ರೋಟೋಕಾಲ್ ಕಾರ್ಯಸಾಧ್ಯವಾಗಿದೆ ಎಂದು ಊಹಿಸಿ).

ಈ ವಿಧಾನದ ದೊಡ್ಡ ಸವಾಲು ಎಂದರೆ VDF ಅನ್ನು ಹೊಂದಿಸುವುದು, ಅಂದರೆ ಅತ್ಯಂತ ದುಬಾರಿ ವಿಶೇಷ ಯಂತ್ರಾಂಶವನ್ನು ಹೊಂದಿರುವ ಪಾಲ್ಗೊಳ್ಳುವವರು ಸಹ ಆವಿಷ್ಕಾರ ಹಂತದ ಅಂತ್ಯದ ಮೊದಲು VDF ಅನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ತಾತ್ತ್ವಿಕವಾಗಿ, ಅಲ್ಗಾರಿದಮ್ ಗಮನಾರ್ಹವಾದ ಸುರಕ್ಷತಾ ಅಂಚು ಹೊಂದಿರಬೇಕು, 10x ಎಂದು ಹೇಳಿ. ಕೆಳಗಿನ ಚಿತ್ರವು ವಿಶೇಷವಾದ ASIC ಅನ್ನು ಹೊಂದಿರುವ ನಟನ ದಾಳಿಯನ್ನು ತೋರಿಸುತ್ತದೆ, ಅದು RANDAO ದೃಢೀಕರಣವನ್ನು ಬಹಿರಂಗಪಡಿಸಲು ನಿಗದಿಪಡಿಸಿದ ಸಮಯಕ್ಕಿಂತ ವೇಗವಾಗಿ VDF ಅನ್ನು ಚಲಾಯಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ. ಅಂತಹ ಪಾಲ್ಗೊಳ್ಳುವವರು ತಮ್ಮ ಸಂಖ್ಯೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅಥವಾ ಬಳಸದೆಯೇ ಅಂತಿಮ ಫಲಿತಾಂಶವನ್ನು ಇನ್ನೂ ಲೆಕ್ಕ ಹಾಕಬಹುದು, ಮತ್ತು ನಂತರ, ಲೆಕ್ಕಾಚಾರದ ಆಧಾರದ ಮೇಲೆ, ಅದನ್ನು ತೋರಿಸಬೇಕೆ ಅಥವಾ ಬೇಡವೇ ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡಿ.

ಮೇಲೆ ತಿಳಿಸಿದ VDF ಕುಟುಂಬಕ್ಕೆ, ಮೀಸಲಾದ ASIC ಕಾರ್ಯಕ್ಷಮತೆಯು ಸಾಂಪ್ರದಾಯಿಕ ಹಾರ್ಡ್‌ವೇರ್‌ಗಿಂತ 100+ ಪಟ್ಟು ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ ನಿಯೋಜನೆ ಹಂತವು 10 ಸೆಕೆಂಡುಗಳವರೆಗೆ ಇದ್ದರೆ, ಅಂತಹ ASIC ನಲ್ಲಿ ಕಂಪ್ಯೂಟ್ ಮಾಡಲಾದ VDF 100x ಸುರಕ್ಷತೆಯ ಅಂಚು ಹೊಂದಲು 10 ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚು ತೆಗೆದುಕೊಳ್ಳಬೇಕು ಮತ್ತು ಸರಕು ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಕಂಪ್ಯೂಟ್ ಮಾಡಲಾದ ಅದೇ VDF 100x 100 ಸೆಕೆಂಡುಗಳು = ~3 ಗಂಟೆಗಳ ಕಾಲ ತೆಗೆದುಕೊಳ್ಳಬೇಕು.

Ethereum ಫೌಂಡೇಶನ್ ತನ್ನದೇ ಆದ ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರುವ, ಉಚಿತ ASIC ಗಳನ್ನು ರಚಿಸುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸಲು ಯೋಜಿಸಿದೆ. ಒಮ್ಮೆ ಇದು ಸಂಭವಿಸಿದಲ್ಲಿ, ಎಲ್ಲಾ ಇತರ ಪ್ರೋಟೋಕಾಲ್‌ಗಳು ಈ ತಂತ್ರಜ್ಞಾನದ ಪ್ರಯೋಜನವನ್ನು ಪಡೆಯಬಹುದು, ಆದರೆ ಅಲ್ಲಿಯವರೆಗೆ RANDAO+VDF ವಿಧಾನವು ತಮ್ಮದೇ ಆದ ASIC ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಹೂಡಿಕೆ ಮಾಡದ ಪ್ರೋಟೋಕಾಲ್‌ಗಳಿಗೆ ಕಾರ್ಯಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

VDF ಕುರಿತು ಅನೇಕ ಲೇಖನಗಳು, ವೀಡಿಯೊಗಳು ಮತ್ತು ಇತರ ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲಾಗಿದೆ ಈ ಸೈಟ್.

ನಾವು ಅಳಿಸುವ ಸಂಕೇತಗಳನ್ನು ಬಳಸುತ್ತೇವೆ

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

ಪ್ರೋಟೋಕಾಲ್ನ ಮುಖ್ಯ ಪರಿಕಲ್ಪನೆಯು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ. ಸರಳತೆಗಾಗಿ, ನಿಖರವಾಗಿ 100 ಭಾಗವಹಿಸುವವರು ಇದ್ದಾರೆ ಎಂದು ಭಾವಿಸೋಣ. ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರು ಸ್ಥಳೀಯವಾಗಿ ಕೆಲವು ಖಾಸಗಿ ಕೀಲಿಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರ ಸಾರ್ವಜನಿಕ ಕೀಲಿಗಳು ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರಿಗೆ ತಿಳಿದಿರುತ್ತವೆ ಎಂದು ನಾವು ಊಹಿಸೋಣ:

1. ಪ್ರತಿಯೊಬ್ಬ ಭಾಗವಹಿಸುವವರು ಸ್ಥಳೀಯವಾಗಿ ಉದ್ದವಾದ ಸ್ಟ್ರಿಂಗ್‌ನೊಂದಿಗೆ ಬರುತ್ತಾರೆ, ಅದನ್ನು 67 ಭಾಗಗಳಾಗಿ ವಿಭಜಿಸುತ್ತಾರೆ, 100 ಷೇರುಗಳನ್ನು ಪಡೆಯಲು ಅಳಿಸುವ ಕೋಡ್‌ಗಳನ್ನು ರಚಿಸುತ್ತಾರೆ ಅಂದರೆ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಮರುಪಡೆಯಲು ಯಾವುದೇ 67 ಸಾಕು, ಭಾಗವಹಿಸುವವರಲ್ಲಿ ಒಬ್ಬರಿಗೆ 100 ಷೇರುಗಳನ್ನು ನಿಯೋಜಿಸಿ ಮತ್ತು ಅವುಗಳನ್ನು ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತದೆ ಅದೇ ಭಾಗವಹಿಸುವವರ ಸಾರ್ವಜನಿಕ ಕೀ. ಎಲ್ಲಾ ಎನ್ಕೋಡ್ ಮಾಡಿದ ಷೇರುಗಳನ್ನು ನಂತರ ಪ್ರಕಟಿಸಲಾಗುತ್ತದೆ.

2. ನಿರ್ದಿಷ್ಟ 67 ಭಾಗವಹಿಸುವವರಿಂದ ಕೋಡೆಡ್ ಸೆಟ್‌ಗಳಲ್ಲಿ ಒಪ್ಪಂದವನ್ನು ತಲುಪಲು ಭಾಗವಹಿಸುವವರು ಕೆಲವು ರೀತಿಯ ಒಮ್ಮತವನ್ನು ಬಳಸುತ್ತಾರೆ.

3. ಒಮ್ಮತವನ್ನು ತಲುಪಿದ ನಂತರ, ಪ್ರತಿಯೊಬ್ಬ ಭಾಗವಹಿಸುವವರು ತಮ್ಮ ಸಾರ್ವಜನಿಕ ಕೀಲಿಯೊಂದಿಗೆ ಎನ್‌ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ 67 ಸೆಟ್‌ಗಳಲ್ಲಿ ಎನ್‌ಕೋಡ್ ಮಾಡಲಾದ ಷೇರುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ, ಅಂತಹ ಎಲ್ಲಾ ಷೇರುಗಳನ್ನು ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅಂತಹ ಎಲ್ಲಾ ಡೀಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ಷೇರುಗಳನ್ನು ಪ್ರಕಟಿಸುತ್ತಾರೆ.

4. 67 ಭಾಗವಹಿಸುವವರು ಹಂತವನ್ನು (3) ಪೂರ್ಣಗೊಳಿಸಿದ ನಂತರ, ಅಳಿಸುವ ಕೋಡ್‌ಗಳ ಗುಣಲಕ್ಷಣಗಳಿಂದಾಗಿ ಎಲ್ಲಾ ಒಪ್ಪಿಗೆಯ ಸೆಟ್‌ಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಡಿಕೋಡ್ ಮಾಡಬಹುದು ಮತ್ತು ಮರುನಿರ್ಮಾಣ ಮಾಡಬಹುದು ಮತ್ತು ಅಂತಿಮ ಸಂಖ್ಯೆಯನ್ನು ಭಾಗವಹಿಸುವವರು (1) ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿದ ಆರಂಭಿಕ ಸಾಲುಗಳ XOR ಆಗಿ ಪಡೆಯಬಹುದು. .

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

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

ಹಂತದಲ್ಲಿ (4) ಭಾಗವಹಿಸುವವರು ನಿರ್ದಿಷ್ಟ ಸ್ಟ್ರಿಂಗ್‌ಗೆ 67 ಬೀಟ್‌ಗಳನ್ನು ಅರ್ಥೈಸುತ್ತಾರೆ ಮತ್ತು ಅವರಿಂದ ಮೂಲ ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಮರುನಿರ್ಮಾಣ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದಾಗ, ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದು ಸಾಧ್ಯ:

1. ಸ್ಟ್ರಿಂಗ್ ಅನ್ನು ಮರುಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಮತ್ತು ಅದನ್ನು ಮತ್ತೆ ಅಳಿಸಿ-ಎನ್ಕೋಡ್ ಮಾಡಿದರೆ ಮತ್ತು ಸ್ಥಳೀಯವಾಗಿ ಲೆಕ್ಕಹಾಕಿದ ಷೇರುಗಳಿಗೆ ಮರ್ಕಲ್ ಟ್ರೀ ಅನ್ನು ಲೆಕ್ಕಹಾಕಿದರೆ, ಮೂಲವು ಒಮ್ಮತವನ್ನು ತಲುಪಿದ ಒಂದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುತ್ತದೆ.

2. ಸಾಲನ್ನು ಮರುಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಆದರೆ ಸ್ಥಳೀಯವಾಗಿ ಲೆಕ್ಕಹಾಕಿದ ಮೂಲವು ಒಮ್ಮತವನ್ನು ತಲುಪಿದ ಒಂದಕ್ಕೆ ಹೊಂದಿಕೆಯಾಗುವುದಿಲ್ಲ.

3. ಸಾಲನ್ನು ಪುನಃಸ್ಥಾಪಿಸಲಾಗಿಲ್ಲ.

ಮೇಲಿನ (1) ಆಯ್ಕೆಯು ಕನಿಷ್ಠ ಒಬ್ಬ ಭಾಗವಹಿಸುವವರಿಗೆ ಸಂಭವಿಸಿದರೆ, ನಂತರ ಆಯ್ಕೆ (1) ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರಿಗೆ ಸಂಭವಿಸಿದೆ ಮತ್ತು ಪ್ರತಿಯಾಗಿ, ಆಯ್ಕೆ (2) ಅಥವಾ (3) ಕನಿಷ್ಠ ಒಬ್ಬ ಭಾಗವಹಿಸುವವರಿಗೆ ಸಂಭವಿಸಿದಲ್ಲಿ, ನಂತರ ತೋರಿಸಲು ಸುಲಭವಾಗಿದೆ ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರಿಗೆ ಆಯ್ಕೆ (2) ಅಥವಾ (3) ಸಂಭವಿಸುತ್ತದೆ. ಹೀಗಾಗಿ, ಸೆಟ್‌ನಲ್ಲಿನ ಪ್ರತಿ ಸಾಲಿಗೆ, ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರು ಅದನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಮರುಪಡೆಯುತ್ತಾರೆ, ಅಥವಾ ಎಲ್ಲಾ ಭಾಗವಹಿಸುವವರು ಅದನ್ನು ಮರುಪಡೆಯಲು ವಿಫಲರಾಗುತ್ತಾರೆ. ಪರಿಣಾಮವಾಗಿ ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯು ನಂತರ ಭಾಗವಹಿಸುವವರು ಚೇತರಿಸಿಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವ ಸಾಲುಗಳ XOR ಆಗಿರುತ್ತದೆ.

ಮಿತಿ ಸಹಿಗಳು

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

BLS ಸಹಿಗಳು ಬಹು ಭಾಗವಹಿಸುವವರಿಗೆ ಸಂದೇಶಕ್ಕಾಗಿ ಒಂದು ಸಾಮಾನ್ಯ ಸಹಿಯನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುವ ವಿನ್ಯಾಸವಾಗಿದೆ. ಬಹು ಸಹಿಗಳನ್ನು ಕಳುಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲದ ಮೂಲಕ ಸ್ಥಳಾವಕಾಶ ಮತ್ತು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಅನ್ನು ಉಳಿಸಲು ಈ ಸಹಿಗಳನ್ನು ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. 

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

ಭಾಗವಹಿಸುವವರು ಬಳಸುವ ಖಾಸಗಿ ಕೀಲಿಗಳನ್ನು ನಿರ್ದಿಷ್ಟ ರೀತಿಯಲ್ಲಿ ರಚಿಸಿದರೆ, ಯಾವ 67 ಸಹಿಗಳು (ಅಥವಾ ಹೆಚ್ಚು, ಆದರೆ ಕಡಿಮೆ ಅಲ್ಲ) ಒಟ್ಟುಗೂಡಿಸಿದ್ದರೂ ಸಹ, ಪರಿಣಾಮವಾಗಿ ಸಹಿ ಒಂದೇ ಆಗಿರುತ್ತದೆ. ಇದನ್ನು ಯಾದೃಚ್ಛಿಕತೆಯ ಮೂಲವಾಗಿ ಬಳಸಬಹುದು: ಭಾಗವಹಿಸುವವರು ಮೊದಲು ಅವರು ಸಹಿ ಮಾಡುವ ಕೆಲವು ಸಂದೇಶವನ್ನು ಒಪ್ಪಿಕೊಳ್ಳುತ್ತಾರೆ (ಇದು RANDAO ನ ಔಟ್‌ಪುಟ್ ಆಗಿರಬಹುದು ಅಥವಾ ಕೊನೆಯ ಬ್ಲಾಕ್‌ನ ಹ್ಯಾಶ್ ಆಗಿರಬಹುದು, ಇದು ಪ್ರತಿ ಬಾರಿ ಬದಲಾಗುವವರೆಗೆ ಇದು ನಿಜವಾಗಿಯೂ ಅಪ್ರಸ್ತುತವಾಗುತ್ತದೆ ಮತ್ತು ಸ್ಥಿರವಾಗಿದೆ) ಮತ್ತು ಅದಕ್ಕಾಗಿ BLS ಸಹಿಯನ್ನು ರಚಿಸಿ. 67 ಭಾಗವಹಿಸುವವರು ತಮ್ಮ ಭಾಗಗಳನ್ನು ಒದಗಿಸುವವರೆಗೆ ಪೀಳಿಗೆಯ ಫಲಿತಾಂಶವು ಅನಿರೀಕ್ಷಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ಅದರ ನಂತರ ಔಟ್ಪುಟ್ ಅನ್ನು ಈಗಾಗಲೇ ಪೂರ್ವನಿರ್ಧರಿತವಾಗಿದೆ ಮತ್ತು ಯಾವುದೇ ಪಾಲ್ಗೊಳ್ಳುವವರ ಕ್ರಿಯೆಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿಲ್ಲ.

ಆನ್‌ಲೈನ್‌ನಲ್ಲಿ ಭಾಗವಹಿಸುವವರಲ್ಲಿ ಕನಿಷ್ಠ ⅔ ಇಬ್ಬರೂ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅನುಸರಿಸುವವರೆಗೆ ಯಾದೃಚ್ಛಿಕತೆಯ ಈ ವಿಧಾನವು ಕಾರ್ಯಸಾಧ್ಯವಾಗಿರುತ್ತದೆ ಮತ್ತು ಕನಿಷ್ಠ ⅓ ಭಾಗವಹಿಸುವವರು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಅನುಸರಿಸುವವರೆಗೆ ಪಕ್ಷಪಾತವಿಲ್ಲದ ಮತ್ತು ಅನಿರೀಕ್ಷಿತವಾಗಿರುತ್ತದೆ. ⅓ ಗಿಂತ ಹೆಚ್ಚು ಆದರೆ ⅔ ಗಿಂತ ಕಡಿಮೆ ಭಾಗವಹಿಸುವವರನ್ನು ನಿಯಂತ್ರಿಸುವ ಆಕ್ರಮಣಕಾರರು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ನಿಲ್ಲಿಸಬಹುದು, ಆದರೆ ಅದರ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಊಹಿಸಲು ಅಥವಾ ಪ್ರಭಾವ ಬೀರಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.

ಮಿತಿ ಸಹಿಗಳು ಸ್ವತಃ ಬಹಳ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವಾಗಿದೆ. ಲೇಖನದ ಎರಡನೇ ಭಾಗದಲ್ಲಿ, ಅವರು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ನಾವು ವಿವರವಾಗಿ ವಿಶ್ಲೇಷಿಸುತ್ತೇವೆ ಮತ್ತು ಭಾಗವಹಿಸುವವರ ಕೀಗಳನ್ನು ಹೇಗೆ ನಿಖರವಾಗಿ ರಚಿಸುವುದು ಅವಶ್ಯಕವಾಗಿದೆ, ಇದರಿಂದಾಗಿ ಮಿತಿ ಸಹಿಗಳನ್ನು ಯಾದೃಚ್ಛಿಕ ಸಂಖ್ಯೆಯ ಜನರೇಟರ್ ಆಗಿ ಬಳಸಬಹುದು.

ತೀರ್ಮಾನಕ್ಕೆ

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

ಪ್ರೋಟೋಕಾಲ್ ಕೋಡ್ ತೆರೆದಿರುತ್ತದೆ, ನಮ್ಮ ಅನುಷ್ಠಾನವನ್ನು ರಸ್ಟ್ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಅದನ್ನು ಕಾಣಬಹುದು ಇಲ್ಲಿ.

ಆನ್‌ಲೈನ್ IDE ನಲ್ಲಿ NEAR ಗಾಗಿ ಯಾವ ಅಭಿವೃದ್ಧಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಪ್ರಯೋಗವನ್ನು ನೀವು ನೋಡಬಹುದು ಇಲ್ಲಿ.

ನೀವು ರಷ್ಯನ್ ಭಾಷೆಯಲ್ಲಿ ಎಲ್ಲಾ ಸುದ್ದಿಗಳನ್ನು ಅನುಸರಿಸಬಹುದು ಟೆಲಿಗ್ರಾಮ್ ಗುಂಪು ಮತ್ತು ಸೈನ್ ಇನ್ VKontakte ನಲ್ಲಿ ಗುಂಪು, ಮತ್ತು ಅಧಿಕೃತದಲ್ಲಿ ಇಂಗ್ಲಿಷ್‌ನಲ್ಲಿ ಟ್ವಿಟರ್.

!

ಮೂಲ: www.habr.com