Harnessing Shared Security ສໍາລັບ Secure Cross-Chain Interoperability

ດ້ວຍການໂຈມຕີກ່ຽວກັບຂົວ blockchain ທີ່ນໍາໄປສູ່ການສູນເສຍຫຼາຍຕື້ໂດລາ, ມັນບໍ່ແປກໃຈທີ່ການສົນທະນາກ່ຽວກັບຄວາມປອດໄພຂ້າມຕ່ອງໂສ້ມັກຈະເຮັດໃຫ້ເກີດການໂຕ້ວາທີທີ່ຮຸນແຮງ. ແຕ່ພວກເຮົາເຊື່ອໃນການໃຊ້ວິທີການປະຕິບັດໄດ້ຫຼາຍກວ່າເກົ່າ—ອັນໜຶ່ງທີ່ກ່ຽວຂ້ອງກັບການວິເຄາະບັນຫາຂອງການເຊື່ອມໂຍງກັນຢ່າງປອດໄພຈາກຫຼັກການທໍາອິດ ແລະການອອກແບບກົນໄກເພື່ອເພີ່ມການຮັບປະກັນຄວາມປອດໄພສໍາລັບຄໍາຮ້ອງສະຫມັກຂ້າມຕ່ອງໂສ້ ແລະຜູ້ໃຊ້ຂອງເຂົາເຈົ້າ.

ໃນບົດຄວາມນີ້, ພວກເຮົາຈະສໍາຫຼວດແນວຄວາມຄິດຂອງ ຄວາມປອດໄພຮ່ວມກັນ ແລະອະທິບາຍວິທີການອອກແບບຄວາມປອດໄພຮ່ວມກັນ (ເຊັ່ນ Lagrange State Committees) ສາມາດຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍຂອງ bootstrapping ຄຸນສົມບັດຄວາມປອດໄພທີ່ມີຄວາມຫມາຍສໍາລັບອະນຸສັນຍາ interoperability. ໃນຂະນະທີ່ພວກເຮົາສຸມໃສ່ຄວາມປອດໄພຮ່ວມກັນສໍາລັບໂປໂຕຄອນການສື່ສານຂ້າມຕ່ອງໂສ້, ຄໍາຮ້ອງສະຫມັກທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງໃດໆ - ໂດຍບໍ່ຄໍານຶງເຖິງກໍລະນີການນໍາໃຊ້ - ສາມາດນໍາໃຊ້ເຕັກໂນໂລຢີທີ່ພົ້ນເດັ່ນຂື້ນນີ້ເພື່ອບັນລຸການແບ່ງຂັ້ນຄຸ້ມຄອງທີ່ພຽງພໍແລະການຫຼຸດຜ່ອນຄວາມໄວ້ວາງໃຈໂດຍບໍ່ຈໍາເປັນຕ້ອງມີຄ່າໃຊ້ຈ່າຍໃນການດໍາເນີນງານຫຼາຍເກີນໄປ.

ການແນະນໍາທີ່ບໍ່ເປັນທາງການກ່ຽວກັບຄວາມປອດໄພຮ່ວມກັນ

“ຄວາມປອດໄພຮ່ວມກັນ” ໝາຍເຖິງຄວາມປອດໄພທີ່ໂປຣໂຕຄໍມາຈາກແຫຼ່ງພາຍນອກ. ໃນລະບົບຄວາມປອດໄພຮ່ວມກັນ, ຊັບພະຍາກອນທີ່ລວມກັນໂດຍຜູ້ເຂົ້າຮ່ວມໃນໂປຣໂຕຄໍໜຶ່ງ (ຕົວຢ່າງ, ທຶນ ຫຼື ພະລັງງານການຄຳນວນ) ແມ່ນໃຊ້ເພື່ອສ້າງຄວາມປອດໄພທາງເສດຖະກິດໃຫ້ກັບໂປຣໂຕຄໍອື່ນ. ຄວາມປອດໄພທີ່ໃຊ້ຮ່ວມກັນແຕກຕ່າງຈາກຮູບແບບມາດຕະຖານທີ່ແຕ່ລະເຄືອຂ່າຍຮັບຜິດຊອບຕໍ່ຄວາມປອດໄພຂອງມັນ.

ສໍາລັບຕົວຢ່າງ, blockchains ສາທາລະນະເຊັ່ນ Bitcoin ແລະ Ethereum, ປະສົມປະສານວິທີການເປັນເອກະສັນກັບກົນໄກການຕໍ່ຕ້ານ Sybil - ເຊັ່ນຫຼັກຖານການເຮັດວຽກຫຼືຫຼັກຖານສະແດງຂອງສະເຕກ - ເພື່ອຮັບປະກັນຊີວິດແລະພ້ອມກັນເພີ່ມຄ່າໃຊ້ຈ່າຍຂອງການໂຈມຕີຂອງສັດຕູ (ເຊັ່ນ: ການໂຈມຕີ Sybil , ການໂຈມຕີໄລຍະໄກ , eclipse. ການ​ໂຈມ​ຕີ ​, ການ​ໂຈມ​ຕີ​ຂະ​ບວນ​ການ​ທີ່​ໃຊ້​ເວ​ລາ ​, ແລະ ​ການ​ໂຈມ​ຕີ​ສິນ​ບົນ ​)​.

ເຖິງແມ່ນວ່າໂຄງການຄວາມປອດໄພຮ່ວມກັນຈະເຮັດວຽກແຕກຕ່າງກັນ, ປົກກະຕິແລ້ວເປົ້າຫມາຍແມ່ນປະມານສອງຈຸດປະສົງ:

• ການເພີ່ມປະສິດທິພາບຂອງທຶນໃນເຄືອຂ່າຍ blockchain ໂດຍບໍ່ມີການສ້າງຄວາມສ່ຽງເພີ່ມເຕີມ (ການ stacking ຄວາມສ່ຽງ) ຫຼືແນະນໍາການສົມມຸດຕິຖານຄວາມປອດໄພເພີ່ມເຕີມ.
• ການປັບປຸງຄວາມສາມາດຂອງເຄືອຂ່າຍ blockchain (ໂດຍສະເພາະໂປໂຕຄອນ nascent) ເພື່ອປ້ອງກັນການຫັນປ່ຽນຂອງລັດທີ່ບໍ່ຖືກຕ້ອງ, re-orgs, ການຕໍ່ຕ້ານການເຊັນເຊີ, ແລະອື່ນໆຕໍ່ກັບການໂຈມຕີຕໍ່ຊີວິດແລະຄວາມປອດໄພຂອງອະນຸສັນຍາ.

ຄວາມປອດໄພຮ່ວມກັນບໍ່ແມ່ນແນວຄວາມຄິດໃຫມ່ຢ່າງແທ້ຈິງ; ຕົວຢ່າງ, ການຂຸດຄົ້ນບໍ່ແຮ່ລວມ ໄດ້ຖືກນໍາສະເຫນີໃນປີ 2011, ຊ່ວຍໃຫ້ຜູ້ແຮ່ທາດສາມາດໃຊ້ລະຫັດລັບດຽວກັນກັບຫຼັກຖານສະແດງການເຮັດວຽກ (PoW) ເພື່ອສ້າງບລັອກໃນຕ່ອງໂສ້ PoW ສອງ (ຫຼືຫຼາຍກວ່ານັ້ນ) ທີ່ແຕກຕ່າງກັນທີ່ປະຕິບັດ ການເຫັນດີຂອງ Nakamoto . ນີ້ອະນຸຍາດໃຫ້ໂປຣໂຕຄອນທີ່ອີງໃສ່ PoW ໃໝ່ກວ່າ (ເຊັ່ນ: Namecoin ແລະ Rootstock), ເຊິ່ງໂທເຄັນພື້ນເມືອງບໍ່ມີຄຸນຄ່າພຽງພໍເພື່ອດຶງດູດຄວາມສົນໃຈຈາກຜູ້ແຮ່ທາດ, ເພື່ອແບ່ງປັນຄວາມປອດໄພໂດຍການນໍາໃຊ້ຊັບພະຍາກອນຄອມພິວເຕີ້ຄືນໃຫມ່ທີ່ອຸທິດຕົນເພື່ອຮັບປະກັນເຄືອຂ່າຍ Bitcoin ເພື່ອເພີ່ມຄວາມຫຍຸ້ງຍາກຂອງຕັນ. ຢູ່ໃນພິທີການໃໝ່.

ທີ່ເວົ້າວ່າ, ການຂຸດຄົ້ນບໍ່ແຮ່ປະສົມປະສານແມ່ນຖືວ່າເປັນການສະຫນອງຮູບແບບທີ່ອ່ອນແອຂອງຄວາມຫມັ້ນຄົງທາງດ້ານເສດຖະກິດສໍາລັບເຄືອຂ່າຍທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງເນື່ອງຈາກການຂາດຄວາມປອດໄພທີ່ຮັບຜິດຊອບ. ໃນວັນນະຄະດີທາງວິຊາການ, ຄວາມປອດໄພທີ່ຮັບຜິດຊອບສະທ້ອນເຖິງຄວາມສາມາດຂອງໂປຣໂຕຄໍໃນການກວດສອບໂນດທີ່ (ອາດຈະ) ລະເມີດກົດລະບຽບຂອງໂປຣໂຕຄໍ ແລະລົງໂທດພຶດຕິກຳທີ່ເປັນອັນຕະລາຍ. ຕົວຢ່າງເຊັ່ນ, ຫຼັກຖານສະແດງໂປຣໂຕຄອນທີ່ອີງໃສ່ສະເຕກຕ້ອງການ nodes ເພື່ອລັອກຫຼັກປະກັນ (ໂດຍການຖືລະຫັດຕົ້ນສະບັບຂອງໂປຣໂຕຄໍ) ກ່ອນທີ່ຈະເຂົ້າຮ່ວມໃນຄວາມເຫັນດີເຫັນພ້ອມ, ແລະສາມາດທໍາລາຍ / ຢຸດ ("slash") ຫຼັກປະກັນນີ້ຖ້າຫຼັກຖານສະແດງການກະທໍາທີ່ບໍ່ຖືກຕ້ອງຂອງຜູ້ກວດສອບ.

ໃນກໍລະນີຂອງການຂຸດຄົ້ນບໍ່ແຮ່ລວມ, ໂນດທີ່ເຈດຕະນາຍອມຮັບຕັນທີ່ບໍ່ຖືກຕ້ອງຢູ່ໃນລະບົບຕ່ອງໂສ້ການຂຸດຄົ້ນບໍ່ແຮ່ສາມາດຖືກກວດພົບຢ່າງຫນ້າເຊື່ອຖື. ຍິ່ງໄປກວ່ານັ້ນ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະລົງໂທດຂໍ້ດັ່ງກ່າວ (ເຖິງແມ່ນວ່າມັນເປັນໄປໄດ້ທີ່ຈະລະບຸພວກມັນ) ຍ້ອນວ່າມັນຈະຮຽກຮ້ອງໃຫ້ມີມາດຕະການທີ່ຮຸນແຮງເຊັ່ນການເຜົາໄຫມ້ຫຼືທໍາລາຍຮາດແວຂຸດຄົ້ນບໍ່ແຮ່. ໃນຂະນະທີ່ໄພຂົ່ມຂູ່ຂອງການສູນເສຍ token ຂອງລະບົບຕ່ອງໂສ້ merge-mined ເນື່ອງຈາກການໂຈມຕີກ່ຽວກັບຄວາມປອດໄພຂອງຕົນອາດຈະເບິ່ງຄືວ່າພຽງພໍທີ່ຈະຂັດຂວາງພຶດຕິກໍາຂອງ Byzantine, ຜູ້ແຮ່ທາດທີ່ເປັນອັນຕະລາຍມີຫນ້ອຍທີ່ຈະສູນເສຍນັບຕັ້ງແຕ່ມູນຄ່າຂອງລະບົບຕ່ອງໂສ້ຕົ້ນສະບັບ (e. g. Bitcoin) ບໍ່ຫນ້າຈະໄດ້ຮັບຜົນກະທົບ.

ແນວຄິດທີ່ທັນສະໄຫມຂອງຄວາມປອດໄພຮ່ວມກັນບໍ່ພຽງແຕ່ພັດທະນາເພື່ອລວມເອົາຄວາມປອດໄພທີ່ຮັບຜິດຊອບເທົ່ານັ້ນ, ແຕ່ຍັງຫັນໄປສູ່ການນໍາໃຊ້ຫນ່ວຍການລົງທຶນທີ່ແຕກຕ່າງກັນ - ທຶນ - ເປັນພື້ນຖານຂອງຄວາມປອດໄພຮ່ວມກັນ. ໃນການອອກແບບນີ້, ມີໂປໂຕຄອນພື້ນຖານທີ່ສະຫນອງຄວາມປອດໄພສໍາລັບໂປໂຕຄອນ PoS ອື່ນໆທີ່ສ້າງຂຶ້ນ; nodes ທໍາອິດເຂົ້າຮ່ວມເຄືອຂ່າຍຕົ້ນຕໍ (ໂດຍການລັອກ token ເດີມຂອງເຄືອຂ່າຍເປັນສະເຕກ) ກ່ອນທີ່ຈະເຂົ້າຮ່ວມໃນການຮັກສາເຄືອຂ່າຍຮອງ.

ການອອກແບບນີ້ສາມາດມີຮູບແບບທີ່ແຕກຕ່າງກັນ:

• Validators ເຂົ້າຮ່ວມໃນເຄືອຂ່າຍຕົ້ນຕໍແລະເຄືອຂ່າຍທີສອງ ພ້ອມໆກັນ
• ຊຸດຍ່ອຍຂອງ validators (ຈາກເຄືອຂ່າຍຕົ້ນຕໍ) ຖືກສຸ່ມຕົວຢ່າງເພື່ອກວດສອບແລະຮັບປະກັນເຄືອຂ່າຍທີສອງ.
• ເຄືອ​ຂ່າຍ​ຮອງ​ແມ່ນ​ຮັບ​ປະ​ກັນ​ໂດຍ​ຊຸດ​ເອ​ກະ​ລາດ​ຂອງ validators ຜູກ​ມັດ​ຢູ່​ໃນ​ເຄືອ​ຂ່າຍ​ຕົ້ນ​ຕໍ​
• ຜູ້ກວດສອບຄວາມຖືກຕ້ອງຈາກເຄືອຂ່າຍຫຼັກຈະມອບທຶນສະເຕກຄືນໃໝ່ໃຫ້ກັບຜູ້ກວດສອບໃນເຄືອຂ່າຍທີສອງ

ໂດຍບໍ່ຄໍານຶງເຖິງລາຍລະອຽດການປະຕິບັດ, ລາຍລະອຽດທີ່ສໍາຄັນສໍາລັບໂຄງການຄວາມປອດໄພຮ່ວມກັນທີ່ອະທິບາຍຂ້າງເທິງນີ້ແມ່ນວ່າໂປໂຕຄອນພື້ນຖານຕ້ອງມີວິທີການລົງໂທດຜູ້ກວດສອບທີ່ເປັນອັນຕະລາຍຕໍ່ເຄືອຂ່າຍທີສອງ. ເນື່ອງຈາກມີເງິນທຶນຫນ້ອຍທີ່ຮັບປະກັນເຄືອຂ່າຍຂັ້ນສອງ, ຄວາມເປັນໄປໄດ້ຂອງກຸ່ມໃຫຍ່ທີ່ເປັນອັນຕະລາຍທີ່ຈະລັກລອບອະນຸສັນຍາແມ່ນເປັນຄວາມກັງວົນແທ້ໆ.

ການແກ້ໄຂແມ່ນເພື່ອໃຫ້ແນ່ໃຈວ່າຫນຶ່ງຫຼືຫຼາຍຜູ້ເຂົ້າຮ່ວມທີ່ຊື່ສັດ (ປະກອບເປັນຊົນເຜົ່າສ່ວນນ້ອຍ) ສາມາດຮັບຜິດຊອບສ່ວນໃຫຍ່ໂດຍການລິເລີ່ມການຂັດແຍ້ງແລະການເຜີຍແຜ່ຫຼັກຖານຂອງພຶດຕິກໍາການລະເມີດອະນຸສັນຍາໄປສູ່ຊັ້ນພື້ນຖານ. ຖ້າພິທີການພື້ນຖານ (ເຮັດຫນ້າທີ່ເປັນ "ຜູ້ພິພາກສາ") ຍອມຮັບຫຼັກຖານນັ້ນ, ພາກສ່ວນທີ່ບໍ່ຊື່ສັດສາມາດຖືກລົງໂທດໂດຍການຫັກຄໍ້າປະກັນ (ວາງໄວ້ເປັນພັນທະບັດ) ໃນເຄືອຂ່າຍຕົ້ນຕໍ. ສິ່ງສໍາຄັນ, ຊັ້ນພື້ນຖານພຽງແຕ່ຕ້ອງກວດສອບຫຼັກຖານທີ່ສະຫນອງໃຫ້, ແລະບໍ່ຈໍາເປັນຕ້ອງປະຕິບັດຄວາມເຫັນດີນໍາເພີ່ມເຕີມ, ກ່ອນທີ່ຈະແກ້ໄຂຂໍ້ຂັດແຍ້ງ - ຫຼຸດຜ່ອນການປະສານງານ.

ຈຸດອ່ອນກວ່ານັ້ນແມ່ນ ພຶດຕິກຳທີ່ຜິດພາດຕ້ອງແມ່ນ ມາ ຈາກບາງພັກເພື່ອຫຼຸດກົນໄກເພື່ອໃຫ້ມີປະສິດທິຜົນ. ໃນເຄືອຂ່າຍທີ່ອີງໃສ່ PoS, ຕ້ອງມີຜູ້ກວດສອບຄວາມຖືກຕ້ອງເພື່ອສ້າງຄູ່ລະຫັດສາທາລະນະ - ເອກະຊົນທີ່ເຮັດຫນ້າທີ່ເປັນຕົວຕົນການເຂົ້າລະຫັດລັບທີ່ເປັນເອກະລັກພາຍໃນໂປໂຕຄອນເປັນເອກະສັນ. ໃນ​ລະ​ຫວ່າງ​ການ​ເຮັດ​ວຽກ​ທີ່​ເປັນ​ປົກ​ກະ​ຕິ​, ເຊັ່ນ​: ການ​ສະ​ເຫນີ block ຫຼື​ການ​ຢັ້ງ​ຢືນ (ຄວາມ​ຖືກ​ຕ້ອງ​ຂອງ​) blocks​, validator ເຊັນ​ຂໍ້​ມູນ​ຂອງ block ດ້ວຍ​ກະ​ແຈ​ສ່ວນ​ຕົວ​ຂອງ​ຕົນ — ມີ​ປະ​ສິດ​ທິ​ຜົນ​ຜູກ​ມັດ​ມັນ​ກັບ​ທາງ​ເລືອກ​ນັ້ນ​.

ນີ້ເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະຕັດຕົວກວດສອບສໍາລັບການປະຕິບັດທີ່ແຕກຕ່າງກັນທີ່ຈະຖືກສະແດງວ່າເປັນການໂຈມຕີຕໍ່ຄວາມປອດໄພຫຼືຊີວິດຂອງໂປໂຕຄອນ (ຫຼືທັງສອງກໍລະນີ):

• ການລົງນາມສອງຕັນທີ່ຂັດແຍ້ງກັນໃນລະຫວ່າງໄລຍະເວລາດຽວກັນ (ເອີ້ນວ່າ "equivocation")
• ເຊັນບົດບັນທຶກບໍ່ຖືກຕ້ອງ (ບໍ່ວ່າໃນລະຫວ່າງການສະເໜີ ຫຼືການຢັ້ງຢືນ)
• ການເຊັນເຊີຫນຶ່ງຫຼືຫຼາຍທຸລະກໍາ
• ເຊື່ອງບາງສ່ວນ ຫຼືທັງໝົດຂອງຂໍ້ມູນຂອງບລັອກ

ໃນຂະນະທີ່ການກະທຳຜິດສອງຄັ້ງທຳອິດສາມາດກວດພົບໄດ້ດ້ວຍວິທີດຽວກັນ (ໂດຍການກູ້ລະຫັດສາທາລະນະຂອງຜູ້ກວດສອບຈາກລາຍເຊັນຂອງມັນ), ສອງຄັ້ງສຸດທ້າຍຕ້ອງການກົນໄກອື່ນໆ ເຊັ່ນ: ລາຍຊື່ລວມ ແລະ ລະຫັດລຶບ . ໃນທຸກໆກໍລະນີ, ການນໍາໃຊ້ການເຂົ້າລະຫັດລັບເຮັດໃຫ້ການກວດສອບທີ່ເຊື່ອຖືໄດ້ແລະການລົງໂທດຂອງພຶດຕິກໍາທີ່ເປັນອັນຕະລາຍທີ່ສາມາດທໍາລາຍຄຸນສົມບັດຄວາມປອດໄພທີ່ຕ້ອງການໃນໂປໂຕຄອນ - ເຊັ່ນ: ການຕໍ່ຕ້ານການເຊັນເຊີແລະຄວາມຖືກຕ້ອງຂອງທຸລະກໍາ. ນີ້ສະຫນອງບາງສະພາບການກ່ຽວກັບຄວາມຫມາຍຂອງ "ຄວາມປອດໄພທາງດ້ານເສດຖະກິດລະຫັດລັບ", ເຊິ່ງກ່ຽວຂ້ອງກັບການສົມທົບກົນໄກການເຂົ້າລະຫັດລັບກັບສິ່ງຈູງໃຈທາງເສດຖະກິດເພື່ອຮັບປະກັນເຄືອຂ່າຍທີ່ມີການແບ່ງແຍກ.

ພວກເຮົາສາມາດສະແດງໃຫ້ເຫັນແນວຄວາມຄິດນີ້ - ແລະປຽບທຽບມັນກັບການຂຸດຄົ້ນບໍ່ແຮ່ - ໂດຍໃຊ້ຕົວຢ່າງຂອງ PoS blockchain ໃຫມ່ທີ່ແບ່ງປັນຄວາມປອດໄພຂອງ Ethereum. ໂປໂຕຄອນຂອງຫຼິ້ນຂອງພວກເຮົາມີຄຸນສົມບັດຕໍ່ໄປນີ້ (ໃຫ້ສັງເກດວ່າເປັນຕົວຢ່າງທີ່ງ່າຍດາຍເກີນໄປທີ່ໃຊ້ເພື່ອຈຸດປະສົງທີ່ເປັນຕົວຢ່າງ):

• ຜູ້ປະກອບການ Node ຈໍາເປັນຕ້ອງຝາກຈໍານວນ ETH tokens ທີ່ກໍານົດໄວ້ເປັນຫຼັກຊັບຄໍ້າປະກັນໃນສັນຍາສະຫມາດ Ethereum ກ່ອນທີ່ຈະລົງທະບຽນເປັນຜູ້ກວດສອບໃນເຄືອຂ່າຍ PoS.
• ໃນລະຫວ່າງຊ່ວງເວລາ, ຜູ້ສະເໜີບລັອກໃນໂປໂຕຄອນ PoS ສົ່ງ hashes ຂອງຫົວບລັອກ (ເຊິ່ງລວມມີລາຍເຊັນຂອງຜູ້ກວດສອບ) ກັບ Ethereum ໂດຍການເກັບຮັກສາມັນໄວ້ໃນສັນຍາສະຫມາດ.
• ຄວາມ​ປອດ​ໄພ​ແມ່ນ​ອີງ​ໃສ່ ​ຫຼັກ​ຖານ​ການ​ສໍ້​ໂກງ — ຕ່ອງ​ໂສ້​ແມ່ (Ethereum​) ບໍ່​ໄດ້​ກວດ​ສອບ​ການ​ປ່ຽນ​ແປງ​ຂອງ​ລັດ​, ແຕ່​ວ່າ​ມັນ​ສາ​ມາດ​ກວດ​ສອບ​ຕົວ​ຢ່າງ​ທີ່​ສະ​ແດງ​ໃຫ້​ເຫັນ​ວ່າ​ການ​ຫັນ​ປ່ຽນ​ຂອງ​ລັດ​ສະ​ເພາະ​ແມ່ນ​ບໍ່​ຖືກ​ຕ້ອງ
• ກົນ​ໄກ​ການ​ຕັດ​ຕໍ່​ຕ່ອງ​ໂສ້​ຖືກ​ກະ​ຕຸ້ນ​ຖ້າ​ຫາກ​ວ່າ​ການ​ຫັນ​ປ່ຽນ​ລັດ​ສະ​ເພາະ​ໃດ​ຫນຶ່ງ​ຖືກ​ໂຕ້​ຖຽງ​ກັນ​ໂດຍ​ຫນຶ່ງ​ຫຼື​ຫຼາຍ​ຝ່າຍ

ຕອນນີ້, ສົມມຸດວ່າໂຫນດສ່ວນໃຫຍ່ທີ່ເປັນອັນຕະລາຍຢູ່ໃນເຄືອຂ່າຍທີສອງໄດ້ສົມຮູ້ຮ່ວມຄິດເພື່ອສະຫຼຸບບລັອກທີ່ບໍ່ຖືກຕ້ອງເພື່ອລັກເອົາເງິນທີ່ຝາກໄວ້ໃນສັນຍາຂົວ. ໃນສະຖານະການນີ້, ຜູ້ກວດສອບຄວາມຖືກຕ້ອງທີ່ຊື່ສັດຈະກະຕຸ້ນກົນໄກການຂູດລະບົບຕ່ອງໂສ້ໃນ Ethereum ໂດຍການເຜີຍແຜ່ຫຼັກຖານການສໍ້ໂກງແລະການກໍານົດຜູ້ກວດສອບທີ່ລະເມີດໂປໂຕຄອນ. ຖ້າກົດລະບຽບຂອງໂປໂຕຄອນອະນຸຍາດໃຫ້ຕັດສະເຕກທັງໝົດຂອງຜູ້ກວດສອບໄດ້, ຄ່າໃຊ້ຈ່າຍໃນການສໍ້ລາດບັງຫຼວງຂອງລະບົບຕ່ອງໂສ້ PoS ແມ່ນອັດຕາສ່ວນກັບຈຳນວນທີ່ຖືຫຸ້ນໂດຍຜູ້ກວດສອບສ່ວນໃຫຍ່.

ຕົວຢ່າງນີ້ສະແດງໃຫ້ເຫັນວ່າຄວາມປອດໄພທີ່ຮັບຜິດຊອບແມ່ນເນັ້ນໃສ່ການອອກແບບຄວາມປອດໄພຮ່ວມກັນແລະປະສິດທິຜົນອະນຸຍາດໃຫ້ເຄືອຂ່າຍຂະຫນາດນ້ອຍໄດ້ຮັບການຮັບປະກັນໂດຍໂປໂຕຄອນທີ່ໃຫຍ່ກວ່າທີ່ເຮັດໃຫ້ຄວາມປອດໄພທາງດ້ານເສດຖະກິດທີ່ສໍາຄັນແລະອວດອ້າງເຖິງລະດັບການກະຈາຍອໍານາດແລະຄວາມຫນ້າເຊື່ອຖືທີ່ສູງຂຶ້ນ. ພວກເຮົາຍັງສາມາດເຫັນໄດ້ວ່າກົນໄກການພິສູດຂອງສະເຕກນໍາໄປສູ່ການອອກແບບຄວາມປອດໄພຮ່ວມກັນທີ່ມີແນວຄິດຄວາມປອດໄພທີ່ເຂັ້ມແຂງກວ່າເມື່ອທຽບກັບການຂຸດຄົ້ນບໍ່ແຮ່ (ເຊິ່ງໃຊ້ພະລັງງານຄອມພິວເຕີ້ເປັນພື້ນຖານຂອງຄວາມປອດໄພທາງດ້ານເສດຖະກິດ).

ຍິ່ງໄປກວ່ານັ້ນ, ມັນແນະນໍາແນວຄວາມຄິດຂອງໂປໂຕຄອນໃຫມ່ໂດຍໃຊ້ token ຂອງເຄືອຂ່າຍອື່ນສໍາລັບການຕັ້ງຖິ່ນຖານເພື່ອຫຼຸດຜ່ອນ "ບັນຫາ bootstrapping" (ບ່ອນທີ່ໂປໂຕຄອນ blockchain ໃຫມ່ມີຄວາມປອດໄພທາງດ້ານເສດຖະກິດຕໍ່າເພາະວ່າ token ຂອງມັນບໍ່ໄດ້ຮັບມູນຄ່າພຽງພໍ). ໃນຂະນະທີ່ບັນຫາ bootstrapping ສາມາດແກ້ໄຂໄດ້ດ້ວຍວິທີການຕ່າງໆເຊັ່ນ: ການຂຸດຄົ້ນບໍ່ແຮ່ລວມ - ທີ່ໃຊ້ການລົງທືນຂອງຮາດແວເປັນຫນ່ວຍຄວາມຫມັ້ນຄົງທາງດ້ານເສດຖະກິດ, ປະເພດຂອງຄວາມປອດໄພຮ່ວມກັນນີ້ແມ່ນເຫມາະສົມທີ່ສຸດສໍາລັບເຫດຜົນບາງຢ່າງ (ບາງອັນທີ່ພວກເຮົາໄດ້ກໍານົດໄວ້ກ່ອນຫນ້ານີ້):

• ການລົງທຶນດ້ານທຶນຮອນ - ເຊິ່ງຄາດວ່າຈະມີຄ່າໃຊ້ຈ່າຍທີ່ສໍາຄັນຕໍ່ພຶດຕິກໍາທີ່ເປັນອັນຕະລາຍຕໍ່ການກວດສອບຄວາມຖືກຕ້ອງ - ແມ່ນ implicit ແລະຍາກທີ່ຈະນໍາໃຊ້ເພື່ອຄວາມປອດໄພທາງເສດຖະກິດ. ການເຮັດໃຫ້ການລົງທຶນທາງດ້ານທຶນຮອນຢ່າງຈະແຈ້ງໃນກໍລະນີຂອງການຂຸດຄົ້ນບໍ່ແຮ່ PoW ຈະຕ້ອງໃຊ້ມາດຕະການທີ່ຮຸນແຮງເຊັ່ນ: ການທໍາລາຍຮາດແວການຂຸດຄົ້ນບໍ່ແຮ່ໃນກໍລະນີທີ່ມີພຶດຕິກຳທີ່ເປັນອັນຕະລາຍ, ເຊິ່ງເປັນສິ່ງທີ່ບໍ່ເປັນຈິງໃນສະຖານະການຕົວຈິງ ແລະຍາກທີ່ຈະນຳໃຊ້ໄດ້.
• Merge-mining (ຫຼືການອອກແບບຄວາມປອດໄພຮ່ວມກັນໃດໆທີ່ການມີສ່ວນຮ່ວມໃນການເປັນເອກະສັນແມ່ນຜູກມັດກັບໂຄງສ້າງພື້ນຖານທີ່ເຮັດວຽກ) ແມ່ນຍາກທີ່ຈະປັບຂະຫນາດ. ຕົວຢ່າງ, ມັນມີຂໍ້ຜູກມັດດ້ານເທິງກ່ຽວກັບວ່າມີຕ່ອງໂສ້ PoW ເທົ່າໃດທີ່ສາມາດລວມເຂົ້າກັນໄດ້ພ້ອມກັນກ່ອນທີ່ ROI ຂອງຜູ້ແຮ່ທາດຈະເລີ່ມຫຼຸດລົງ.

ໃນທາງກົງກັນຂ້າມ, ໂຄງການຄວາມປອດໄພຮ່ວມກັນທີ່ອີງໃສ່ PoS ທີ່ນໍາໃຊ້ການລົງທຶນທຶນເປັນຫນ່ວຍງານຂອງການລົງທຶນມີຄຸນສົມບັດບາງຢ່າງທີ່ເປັນປະໂຫຍດສໍາລັບການແກ້ໄຂບັນຫາການ bootstrapping ເຄືອຂ່າຍໃຫມ່ຢ່າງມີປະສິດທິພາບແລະປະສິດທິຜົນ:

• ການລົງທຶນທາງດ້ານທຶນຮອນແມ່ນຈະແຈ້ງ (ຜູ້ລົງທຶນລົງທຶນໃນການຊື້ tokens ເພື່ອຕອບສະຫນອງຄວາມຕ້ອງການສໍາລັບການຄໍ້າປະກັນ) ແລະສາມາດ leveraged ສໍາລັບການຄໍ້າປະກັນທີ່ເຂັ້ມແຂງແລະແນ່ນອນດ້ານເສດຖະກິດ. ຕົວຢ່າງ, ມັນເປັນເລື່ອງງ່າຍທີ່ຈະເບິ່ງເຫັນວ່າໂປໂຕຄອນມີແນວໂນ້ມທີ່ຈະປອດໄພກວ່າເມື່ອມັນມີ 1 ETH ມູນຄ່າຂອງສະເຕກທີ່ຮັບປະກັນ 0.9 ETH ມູນຄ່າຂອງການເຮັດທຸລະກໍາຫຼາຍກ່ວາເວລາທີ່ 0.9 ETH ມູນຄ່າຂອງສະເຕກຮັບປະກັນ 1 ETH ມູນຄ່າຂອງການເຮັດທຸລະກໍາ.
• ນັບຕັ້ງແຕ່ການມີສ່ວນຮ່ວມໃນຄວາມເຫັນດີນໍາແມ່ນຜູກມັດກັບການລົງທຶນທຶນ "ບໍລິສຸດ", ມັນງ່າຍຕໍ່ການຂະຫຍາຍຄວາມປອດໄພທາງດ້ານເສດຖະກິດແລະມີຜູ້ກວດສອບທີ່ຮັບປະກັນຫຼາຍໂປໂຕຄອນໂດຍບໍ່ມີການເຮັດໃຫ້ເກີດການປະສານງານຫຼາຍເກີນໄປ (ໂດຍສະເພາະໃນເວລາທີ່ຄວາມຕ້ອງການຮາດແວຕ່ໍາ).

ຢ່າງໃດກໍຕາມ, ທຸກໆວິທີການຈະມີຂໍ້ບົກຜ່ອງແລະການແບ່ງປັນຄວາມປອດໄພ - ໂດຍຜ່ານການສະເຕກແມ່ນບໍ່ມີຂໍ້ຍົກເວັ້ນ; ຕົວຢ່າງ, ການກໍານົດຈໍານວນຜູ້ກວດສອບຫຼັກຊັບຄວນໃສ່ໃນໂປໂຕຄອນ PoS ເປັນບັນຫາຍາກທີ່ຈະແກ້ໄຂ. ພວກເຮົາຈະເອົາເລື່ອງນີ້ເຂົ້າໄປໃນບໍລິບົດໂດຍການພິຈາລະນາຄໍາຖະແຫຼງນີ້ຈາກວັກກ່ອນຫນ້າ: " ມັນງ່າຍທີ່ຈະເຫັນພາບທີ່ໂປໂຕຄອນມີແນວໂນ້ມທີ່ຈະປອດໄພກວ່າເມື່ອມັນມີ 1 ETH ມູນຄ່າຂອງສະເຕກທີ່ຮັບປະກັນການເຮັດທຸລະກໍາ 0.9 ETH ຫຼາຍກ່ວາເວລາທີ່ມີມູນຄ່າ 0.9 ETH. ຂອງສະເຕກແມ່ນຮັບປະກັນ 1 ETH ມູນຄ່າຂອງການເຮັດທຸລະກໍາ. ”

ໃນຂະນະທີ່ຄໍາຖະແຫຼງນີ້ເບິ່ງຄືວ່າສົມເຫດສົມຜົນ, ການວິເຄາະທີ່ເລິກເຊິ່ງສະແດງໃຫ້ເຫັນຄວາມຫຍຸ້ງຍາກໃນການເລືອກຄວາມຕ້ອງການພັນທະບັດທີ່ດີທີ່ສຸດ:

• ການຮຽກຮ້ອງໃຫ້ມີ 1 ETH ຈາກຜູ້ກວດສອບເພື່ອຮັບປະກັນຊັບສິນມູນຄ່າ 0.9 ETH ຫຼຸດລົງປະສິດທິພາບຂອງທຶນ ແລະສົ່ງຜົນໃຫ້ການຄໍ້າປະກັນເກີນ.
• ການຮັບປະກັນການເຮັດທຸລະກໍາມູນຄ່າ 2 ETH ກັບ 1 ETH ມູນຄ່າຂອງສະເຕກເຮັດໃຫ້ ແບນວິດທາງເສດຖະກິດ ຫຼຸດລົງ (ຫຼື "leverage") ໃນ PoS blockchain ແລະສົ່ງຜົນໃຫ້ undercollateralization.

ໃນສະຖານະການທີ່ເຫມາະສົມ, ຜູ້ອອກແບບໂປໂຕຄອນຕ້ອງການໃຫ້ມີ 1 ETH ຂອງສະເຕກເພື່ອຮັບປະກັນ 1 ETH ມູນຄ່າຂອງການເຮັດທຸລະກໍາ. ແຕ່ຄວາມສົມດຸນດັ່ງກ່າວເປັນການຍາກທີ່ຈະບັນລຸໄດ້ໃນສະພາບຕົວຈິງສໍາລັບເຫດຜົນທີ່ແຕກຕ່າງກັນ; ສໍາລັບຕົວຢ່າງ, ຈໍານວນທຶນທີ່ຈະຮັບປະກັນຕໍ່ຫນ່ວຍເວລາ (ຫນ້າທີ່ຂອງມູນຄ່າຂອບຂອງທຸລະກໍາຕໍ່ຕັນ / ໄລຍະເວລາ) ແມ່ນແບບເຄື່ອນໄຫວ. ນີ້ເຮັດໃຫ້ການກໍານົດພັນທະບັດທີ່ເຫມາະສົມໃນລະບົບ PoS ເປັນບັນຫາກົນໄກທີ່ມີຄວາມຫຍຸ້ງຍາກຫຼາຍແລະການພິຈາລະນາທີ່ສໍາຄັນສໍາລັບໂຄງການຄວາມປອດໄພຮ່ວມກັນທີ່ອີງໃສ່ສະເຕກ, ເຊັ່ນ: ການຢຸດຄືນ (ທີ່ພວກເຮົາສົນທະນາໃນພາກຕໍ່ໄປ).

ແບ່ງປັນຄວາມປອດໄພຈາກການຢຸດພັກ ແລະຈຸດກວດກາ

ຢຸດຄືນ

Restaking ແມ່ນຮາກຖານຢູ່ໃນ rehypothecation - ການປະຕິບັດດ້ານການເງິນແບບດັ້ງເດີມທີ່ຜູ້ໃຫ້ກູ້ໃຊ້ຊັບສິນ (ກ່ອນຫນ້ານັ້ນໄດ້ສັນຍາໄວ້ໂດຍຜູ້ກູ້ຢືມ) ເປັນຫລັກປະກັນເພື່ອຮັບປະກັນເງິນກູ້ໃຫມ່. ຢູ່ທີ່ນີ້, ຄູ່ຮ່ວມສັນຍາໃໝ່ຖືວ່າສິດໃນຊັບສິນຄ້ຳປະກັນເດີມ ເຊັ່ນວ່າ ຖ້າຫົວໜ່ວຍທີ່ເອົາເງິນກູ້ໃໝ່ມາເສຍເງິນຄືນ, ມັນສາມາດປະມູນຊັບສິນເພື່ອເອົາເງິນຄືນຄືນໄດ້.

ເມື່ອປະຕິບັດຢ່າງຖືກຕ້ອງ, rehypothecation ສາມາດເປັນປະໂຫຍດ. ສໍາລັບການເລີ່ມຕົ້ນ, ມັນຊ່ວຍໃຫ້ປະສິດທິພາບທຶນສູງຂຶ້ນແລະສະພາບຄ່ອງໂດຍການນໍາໃຊ້ຊັບສິນຄືນໃຫມ່ - ເຊິ່ງຖ້າບໍ່ດັ່ງນັ້ນຈະນອນຢູ່ - ເພື່ອຮັບປະກັນການສະຫນອງທຶນໄລຍະສັ້ນສໍາລັບກິດຈະກໍາສ້າງກໍາໄລ. ຖ້າຜົນກຳໄລຈາກການກູ້ຢືມເກີນມູນຄ່າຂອງຄ້ຳປະກັນຄືນໃໝ່, ທຸກພາກສ່ວນທີ່ກ່ຽວຂ້ອງ (ຜູ້ກູ້ຢືມຕົ້ນ, ຜູ້ໃຫ້ກູ້ ແລະ ຜູ້ໃຫ້ກູ້) ໄດ້ຮັບຜົນປະໂຫຍດ.

Rehypothecation ກ່ຽວຂ້ອງກັບຄວາມສ່ຽງຢ່າງຫຼວງຫຼາຍ (ສ່ວນຫນຶ່ງຂອງເຫດຜົນການປະຕິບັດໄດ້ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍໃນບັນດາສະຖາບັນ TradFi), ໂດຍສະເພາະແມ່ນຜູ້ກູ້ຢືມຕົ້ນສະບັບທີ່ອາດຈະສູນເສຍສິດທິໃນຊັບສິນຂອງເຂົາເຈົ້າໃນເວລາທີ່ການຊໍາລະເງິນເກີດຂຶ້ນ. ຜູ້ໃຫ້ກູ້ນຳໃຊ້ຫຼັກປະກັນຄືນມາຍັງມີຄວາມສ່ຽງ, ຫຼາຍກວ່ານັ້ນ, ຖ້າມັນຈໍາເປັນຕ້ອງຈ່າຍຄືນຜູ້ກູ້ຢືມຫຼັງຈາກຄູ່ສັນຍາໃຫມ່ໄດ້ຍຶດເອົາຫຼັກຊັບຄໍ້າປະກັນຍ້ອນການກູ້ຢືມເງິນກູ້ຢືມ.

ຄວາມສ່ຽງອື່ນແມ່ນອັນໜຶ່ງທີ່ພວກເຮົາໄດ້ອະທິບາຍໂດຍຫຍໍ້ກ່ອນໜ້ານີ້ ແລະ ໝູນວຽນໄປເຖິງການມີຊັບສິນຄ້ຳປະກັນເກີນຕົວ ທຽບກັບການຄ້າຊັບຊ້ອນດ້ານຊັບຊ້ອນ. ໃນຕົວຢ່າງທີ່ໄດ້ຍົກໃຫ້ເຫັນໃນເມື່ອກ່ອນ, ຖ້າທະນາຄານ B (ທະນາຄານຂອງ John) ເຂົ້າໄປໃນຕໍາແຫນ່ງ leveraged ຫຼາຍເກີນໄປ - ບ່ອນທີ່ມັນກູ້ຢືມຫຼາຍກ່ວາມູນຄ່າຂອງຫຼັກຊັບຂອງ John - ແລະປະສົບກັບການສູນເສຍ, ມັນຍາກທີ່ຈະຈ່າຍຄືນເງິນກູ້ຢືມຈາກທະນາຄານ B (ຫຼືສົ່ງຄືນ John's. ຊັບ​ສິນ). ທະນາຄານ B ອາດຈະປົກປ້ອງກໍລະນີແຂບນີ້ໂດຍການຂໍໃຫ້ທະນາຄານ A (ທະນາຄານຂອງ John) ກູ້ຢືມຫນ້ອຍກວ່າມູນຄ່າຂອງຫຼັກຊັບຂອງ John; ຢ່າງ ໃດ ກໍ ຕາມ, ທີ່ ເພີ່ມ ທະ ວີ ການ inefficient ທຶນ ສໍາ ລັບ ທະ ນາ ຄານ A ແລະ ຫຼຸດ ຜ່ອນ ຜົນ ໄດ້ ຮັບ ຈາກ rehypothecating ຫຼັກ ຊັບ John ໃນ ສະ ຖານ ທີ່ ທໍາ ອິດ.

ຊຸດດຽວກັນຂອງຂໍ້ດີແລະຂໍ້ເສຍຍັງໃຊ້ກັບການພັກຜ່ອນ. ກ່ອນທີ່ຈະໄປຕື່ມອີກ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຊີ້ແຈງລາຍລະອຽດທີ່ສໍາຄັນ: ສະເຕກຂອງຜູ້ພັກຜ່ອນສະເຫມີຜ່ານໂປໂຕຄອນພື້ນຖານກ່ອນ. ຕົວຢ່າງ, ຜູ້ພັກຜ່ອນໃນ Ethereum ຈະຕ້ອງຝາກ 32 ETH ເຂົ້າໃນສັນຍາ Beacon Chain ຫຼືມອບ ETH ໃຫ້ກັບຜູ້ກວດສອບທີ່ດໍາເນີນການໂດຍການບໍລິການສະເຕກ - ຂຶ້ນກັບວ່າ ການພັກຜ່ອນແບບພື້ນເມືອງ ຫຼື ການພັກຜ່ອນຂອງແຫຼວ ຖືກນໍາໃຊ້.

ໃນລະດັບສູງ, ການພັກຜ່ອນໃນກໍລະນີຂອງ Ethereum ປະກອບດ້ວຍດັ່ງຕໍ່ໄປນີ້:

#1: ໃຫ້ສິດການເປັນເຈົ້າຂອງໂປຣໂຕຄໍທີ່ຢຸດພັກ (ຫຼືການຮຽກຮ້ອງ) ໃຫ້ກັບ ETH ທີ່ຖືຫຸ້ນ

ໃນການພັກຜ່ອນແບບເດີມ, ຜູ້ກວດສອບຈະຕ້ອງປ່ຽນທີ່ຢູ່ການຖອນເງິນຂອງເຂົາເຈົ້າໄປສູ່ສັນຍາອັດສະລິຍະທີ່ຄຸ້ມຄອງໂດຍໂປຣໂຕຄໍການຢຸດຄືນ. ດັ່ງນັ້ນ, ແທນທີ່ຈະເປັນເງິນໄປຫາຜູ້ກວດສອບໂດຍກົງຫຼັງຈາກອອກຈາກລະບົບຕ່ອງໂສ້ Beacon, ສະເຕກຈະຜ່ານໂປຣໂຕຄອນການພັກຜ່ອນກ່ອນກ່ອນທີ່ຈະໄປຫາຜູ້ກວດສອບ (ພວກເຮົາຈະເບິ່ງວ່າເປັນຫຍັງຈຶ່ງເປັນກໍລະນີໃນໄວໆນີ້).

ມັນຍັງເປັນໄປໄດ້ທີ່ຈະຝາກຕົວແທນ fungible (derivatives) ຂອງ ETH staked ໃນສັນຍາສະຫມາດຂອງ retaking protocol (ການພັກຜ່ອນຂອງແຫຼວ). ເອີ້ນວ່າ "tokens staked ຂອງແຫຼວ", tokens ດັ່ງກ່າວແມ່ນອອກໃຫ້ໂດຍຜູ້ປະຕິບັດການ staking-as-service (ເຊັ່ນ: RocketPool, Lido, Coinbase, ແລະອື່ນໆ). ແລະເປັນຕົວແທນການຮຽກຮ້ອງສ່ວນຫນຶ່ງຂອງ ETH ທີ່ຖືຫຸ້ນໂດຍຜູ້ກວດສອບ (ລວມທັງຜົນຕອບແທນຈາກລາງວັນ) ແລະສາມາດແລກໄດ້ໃນອັດຕາສ່ວນ 1: 1 ສໍາລັບ tokens ETH ພື້ນເມືອງ.

#2: ການເລືອກເຂົ້າໃນເງື່ອນໄຂການຕັດເພີ່ມເຕີມທີ່ບັງຄັບໃຊ້ໂດຍໂປໂຕຄອນການຢຸດຄືນ

ໂປໂຕຄອນການຢຸດພັກໂດຍປົກກະຕິເຮັດໜ້າທີ່ເປັນ "ຕົວກາງ" ທີ່ເຄືອຂ່າຍ ແລະແອັບພລິເຄຊັນຕ່າງໆທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງສາມາດສຽບເຂົ້າເພື່ອຄວາມປອດໄພທາງເສດຖະກິດ. ໂດຍທົ່ວໄປແລ້ວສິ່ງເຫຼົ່ານີ້ຈະລວມເຖິງໂປຣໂຕຄໍທີ່ຮຽກຮ້ອງໃຫ້ມີການຢັ້ງຢືນບາງຮູບແບບໂດຍພາກສ່ວນຕ່າງໆ ເຊັ່ນ: ເຄືອຂ່າຍ oracle - ແຕ່ເຄື່ອງໝາຍຫຼັກຂອງພວກມັນຍັງບໍ່ທັນມີຄ່າພຽງພໍເພື່ອນຳໃຊ້ໃນການຕັ້ງຄ່າຫຼັກຖານສະເຕກ.

ແທນທີ່ຈະສ້າງຊຸດຜູ້ກວດສອບໃໝ່ຈາກຈຸດເລີ່ມຕົ້ນ, ແອັບພລິເຄຊັ່ນດັ່ງກ່າວສາມາດລົງທະບຽນການບໍລິການຂອງຜູ້ກວດສອບທີ່ມີຢູ່ແລ້ວຜ່ານໂປຣໂຕຄໍການພັກຜ່ອນ. ການບໍລິການສາມາດລະບຸເງື່ອນໄຂການຫັກລົບທີ່ເປັນເອກະລັກກ່ຽວກັບຫຼັກປະກັນ ທີ່ຖືກປັບປຸງຄືນ ຂອງຜູ້ກວດສອບໄດ້ - ເຊິ່ງໂປຣໂຕຄອນການຢຸດສາມາດບັງຄັບໃຊ້ໄດ້ເນື່ອງຈາກຕອນນີ້ມັນຄວບຄຸມການຖອນຕົວຂອງຜູ້ກວດສອບ - ຫຼຸດອຸປະສັກຕໍ່ຄວາມປອດໄພທາງດ້ານເສດຖະກິດ.

ຂໍ້ສັງເກດທີ່ສໍາຄັນ: ເງື່ອນໄຂການຂູດ AVS ແມ່ນເອກະລາດຈາກເງື່ອນໄຂການຂັດທີ່ຖືກບັງຄັບໃຊ້ໂດຍ Ethereum's Beacon Chain consensus, ດັ່ງນັ້ນສະເຕກ ETH ຂອງຜູ້ກວດສອບສາມາດຖືກຕັດໄດ້ເຖິງແມ່ນວ່າພວກເຂົາບໍ່ໄດ້ກະທໍາຜິດຕໍ່ Ethereum ເອງ. ນີ້ສາມາດນໍາໄປສູ່ສິ່ງທີ່ພວກເຮົາອະທິບາຍວ່າເປັນ "ການຊ້ອນກັນຄວາມສ່ຽງ": ເພື່ອຕອບແທນປະສິດທິພາບຂອງທຶນທີ່ສູງຂຶ້ນ, ເຄືອຂ່າຍຕົ້ນຕໍໄດ້ຮັບຄວາມສ່ຽງເພີ່ມເຕີມຫຼາຍກ່ວາມັນ. (ການຊ້ອນກັນຄວາມສ່ຽງຍັງມີຜົນສະທ້ອນຕໍ່ໂປຣໂຕຄໍ EigenLayer ຫຼັກຂອງມັນເອງດັ່ງທີ່ພວກເຮົາຈະເຫັນຕໍ່ມາ.)

#3: ໄດ້ຮັບລາງວັນເພີ່ມເຕີມ

Restaking ຮຽກຮ້ອງໃຫ້ມີຄວາມສ່ຽງທີ່ສໍາຄັນ (ເຊັ່ນ: ການກວດສອບ restaked ອາດຈະຖືກຕັດໂດຍບັງເອີນເນື່ອງຈາກ bug ໃນກົນໄກການ slashing on-chain) ແຕ່ຄືກັນກັບ rehypothecation ປົດລັອກສະພາບຄ່ອງໃນ TradFi, retaking ສາມາດປັບປຸງປະສິດທິພາບທຶນໃນລະບົບນິເວດ PoS ແລະສ້າງສູງກວ່າ. - ຜົນ​ຜະ​ລິດ​ສະ​ເລ່ຍ​ສໍາ​ລັບ stakeers​.

ນີ້ແມ່ນອີງໃສ່ຄວາມຈິງທີ່ວ່າການບໍລິການຜູ້ທີ່ໃຊ້ທຶນ retaked ສໍາລັບຄວາມປອດໄພແມ່ນຕ້ອງການໃຫ້ລາງວັນຜູ້ກວດສອບການບໍລິການຂອງພວກເຂົາ. ເພື່ອເປັນຕົວຢ່າງ, ຜູ້ກວດສອບທີ່ຖືກຖອນຄືນທີ່ເຂົ້າຮ່ວມໃນເຄືອຂ່າຍ oracle ຈະໄດ້ຮັບຄ່າທຳນຽມໃນການກວດສອບການອັບເດດ oracle ໂດຍການຈ່າຍເງິນມາຈາກແອັບພລິເຄຊັນພາກສ່ວນທີສາມອື່ນໆທີ່ອີງໃສ່ການບໍລິການຂອງ oracle. ດ້ວຍຜູ້ກວດສອບຍັງໄດ້ຮັບຮາງວັນຈາກ Beacon Chain, ການຢຸດພັກຜ່ອນເຮັດໃຫ້ສາມາດສ້າງລາຍໄດ້ຈາກໂປໂຕຄອນ PoS ຫຼາຍອັນໂດຍບໍ່ຈໍາເປັນຕ້ອງໃຊ້ທຶນສົດໃຫ້ກັບລະບົບນິເວດໃໝ່.

ເຖິງແມ່ນວ່າພວກເຮົາສຸມໃສ່ການພັກຜ່ອນ Ethereum ໃນຕົວຢ່າງນີ້, ໂປໂຕຄອນ Proof of Stake ອື່ນໆຍັງໄດ້ປະຕິບັດຕົວແປຂອງ retaking ເພື່ອບັນລຸຈຸດປະສົງທີ່ຄ້າຍຄືກັນ (ການຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການເປີດຕົວໂປໂຕຄອນ / ຄໍາຮ້ອງສະຫມັກໃຫມ່, ການປັບປຸງປະສິດທິພາບຂອງທຶນ, ແລະການຂະຫຍາຍຄວາມປອດໄພທາງດ້ານເສດຖະກິດ). ໃນຄວາມເປັນຈິງ, ໃນພາກຕໍ່ໄປສົນທະນາ EigenLayer - Ethereum's premier restaking protocol - ກ່ອນທີ່ຈະດໍາເນີນການເນັ້ນໃສ່ການພັກຜ່ອນໃນລະບົບນິເວດອື່ນໆ:

EigenLayer

EigenLayer ແມ່ນໂປໂຕຄອນການພັກຜ່ອນທີ່ຖືກສ້າງຂື້ນເພື່ອຂະຫຍາຍຄວາມປອດໄພທາງດ້ານເສດຖະກິດຂອງ Ethereum ເພື່ອຮັບປະກັນແອັບພລິເຄຊັນທີ່ແຈກຢາຍ, ເຄືອຂ່າຍ, ແລະໂປໂຕຄອນໃຫມ່ (ເຊິ່ງມັນອະທິບາຍລວມວ່າເປັນ "ບໍລິການທີ່ຢືນຢັນຢ່າງຈິງຈັງ" ຫຼື AVSs ສໍາລັບສັ້ນ). ຖ້າທ່ານໄດ້ອ່ານພາກກ່ອນຫນ້າທີ່ອະທິບາຍຕົວຢ່າງຂອງການພັກຜ່ອນໃນ Ethereum, ຫຼັງຈາກນັ້ນທ່ານເຂົ້າໃຈການປະຕິບັດງານຂອງ EigenLayer ໃນລະດັບສູງ; ແນວໃດກໍ່ຕາມ, ພວກເຮົາຈະລວມເອົາບາງລາຍລະອຽດເພີ່ມເຕີມສໍາລັບສະພາບການ.

ຫຼັງຈາກ retaking ETH (ໂດຍການຊີ້ໃບຢັ້ງຢືນການຖອນຕົວທີ່ກ່ຽວຂ້ອງກັບຜູ້ກວດສອບສັນຍາສະຫມາດທີ່ຄວບຄຸມໂດຍ EigenLayer), ຜູ້ກວດສອບແມ່ນຈໍາເປັນເພື່ອປະຕິບັດວຽກງານທີ່ກໍານົດໂດຍ AVS ທີ່ພວກເຂົາຕ້ອງການດໍາເນີນການ. ຍົກຕົວຢ່າງ, ຖ້າ AVS ເປັນ sidechain, ຜູ້ກວດສອບທີ່ຖືກຍຶດຄືນຕ້ອງດໍາເນີນການຊອບແວລູກຄ້າສໍາລັບ sidechain ເພື່ອດໍາເນີນການທຸລະກໍາແລະກວດສອບຕັນ, ໃນຂະນະທີ່ໄດ້ຮັບລາງວັນສໍາລັບການປະຕິບັດວຽກງານເຫຼົ່ານີ້ຢ່າງຖືກຕ້ອງ. ກວ້າງກວ່ານັ້ນ, ວຽກງານສາມາດແຕກຕ່າງກັນໄປຕາມລັກສະນະຂອງ AVS:

• ການເກັບຮັກສາຂໍ້ມູນໃນເຄືອຂ່າຍ ການມີຂໍ້ມູນ

• ການອະນຸມັດທຸລະກຳເງິນຝາກ ແລະ ຖອນເງິນສຳລັບຂົວຂ້າມຕ່ອງໂສ້ ຫຼື ອະນຸມັດຂໍ້ຄວາມສຳລັບໂປຣໂຕຄອນການສົ່ງຂໍ້ຄວາມຂ້າມຕ່ອງໂສ້

• ການສ້າງ ແລະກວດສອບຫຼັກຖານທີ່ບໍ່ມີຄວາມຮູ້ສຳລັບແອັບພລິເຄຊັນທີ່ເນັ້ນຄວາມເປັນສ່ວນຕົວ ຫຼືເຄືອຂ່າຍການຈ່າຍເງິນແບບປ້ອງກັນ

• ການເກັບຮັກສາ ແລະກວດສອບສ່ວນຫົວຂອງບລັອກ ແລະເຄື່ອງສົ່ງຕໍ່/oracles ແລ່ນສໍາລັບໂປຣໂຕຄອນການເຮັດວຽກຮ່ວມກັນຂ້າມຕ່ອງໂສ້

  
  

ຜູ້ອ່ານທີ່ມີສະຕິປັນຍາຈະສັງເກດເຫັນສອງຢ່າງ: (a) ວຽກງານທີ່ກໍານົດໂດຍ AVS ສາມາດເປັນວຽກທີ່ຕົນເອງມັກ (b) ວຽກງານທີ່ກໍານົດ AVS ທີ່ແຕກຕ່າງກັນຮຽກຮ້ອງໃຫ້ມີລະດັບການລົງທຶນແລະຄວາມພະຍາຍາມທີ່ຈະແຕກຕ່າງກັນ. ເພື່ອສະແດງໃຫ້ເຫັນເຖິງຈຸດສຸດທ້າຍ, ມັນເປັນໄປໄດ້ທີ່ຈະຈິນຕະນາການວ່າການເກັບຮັກສາຫົວບລັອກໃນໂປໂຕຄອນຂ້າມລະບົບຕ່ອງໂສ້ຈະຕ້ອງການພື້ນທີ່ດິດ / ຫນ່ວຍຄວາມຈໍາຫນ້ອຍລົງເມື່ອທຽບກັບການເກັບຮັກສາແລະການສະຫນອງຂໍ້ມູນໃນເຄືອຂ່າຍຄວາມພ້ອມຂອງຂໍ້ມູນ (ເຖິງແມ່ນວ່າເຕັກນິກເຊັ່ນ: ການເກັບຕົວຢ່າງຄວາມພ້ອມຂອງຂໍ້ມູນ ຈະຫຼຸດຜ່ອນພາລະການເກັບຮັກສາ. ຢູ່ໃນແຕ່ລະ nodes).

ນີ້ແມ່ນເຫດຜົນຫນຶ່ງທີ່ EigenLayer ອະນຸຍາດໃຫ້ຜູ້ກວດສອບທີ່ຖືກຢຸດຄືນເພື່ອມອບມອບການປະຕິບັດວຽກງານທີ່ກໍານົດ AVS ໃຫ້ກັບພາກສ່ວນ ອື່ນ (ຜູ້ປະຕິບັດການ) ຜູ້ທີ່ແບ່ງປັນລາງວັນທີ່ໄດ້ຮັບຈາກ AVS ກັບຜູ້ກວດສອບ. ວິທີການນີ້ມີລະດັບຄວາມສ່ຽງທີ່ແຕກຕ່າງກັນສໍາລັບຜູ້ກວດສອບທີ່ຖືກຍຶດຄືນໂດຍອີງຕາມຂອບເຂດທີ່ພາລະຂອງການຂັດຂືນ - ເຊິ່ງສາມາດເກີດຂື້ນໄດ້ຖ້າຜູ້ປະຕິບັດການບໍ່ສາມາດປະຕິບັດວຽກງານ AVS ຢ່າງຖືກຕ້ອງ - ຖືກແບ່ງປັນລະຫວ່າງຜູ້ກວດສອບທີ່ຖືກຢຸດພັກແລະຜູ້ປະກອບການພາກສ່ວນທີສາມ.

ແຕ່ລະ AVS ກໍານົດເງື່ອນໄຂທີ່ກໍານົດໄວ້ພາຍໃຕ້ການທີ່ສະເຕກຂອງ EigenLayer retaker ສາມາດຖືກຕັດ. ຕົວຢ່າງເຊັ່ນ, ເຄືອຂ່າຍຄວາມພ້ອມຂອງຂໍ້ມູນທີ່ປະຕິບັດການພິສູດພື້ນທີ່/ກົນໄກການເກັບຮັກສາອາດຈະຫຼຸດຜູ້ປະຕິບັດການທີ່ບໍ່ສາມາດເກັບຂໍ້ມູນໃນໄລຍະເວລາທີ່ຕົກລົງກັນໄດ້. Slashing ເຮັດໃຫ້ເກີດການ freezing ຂອງ operator ພາຍໃນ EigenLayer - ປ້ອງກັນການມີສ່ວນຮ່ວມຕື່ມອີກໃນຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນການບໍລິການທີ່ມີການກວດສອບຢ່າງຫ້າວຫັນ - ແລະການຫຼຸດຜ່ອນການດຸ່ນດ່ຽງ ETH ຂອງຜູ້ກວດສອບໃນທີ່ສຸດ.

ສໍາລັບການຕັດທີ່ເກີດຂື້ນ, ການກະທໍາຜິດຈະຕ້ອງເປັນການພິສູດ - ເຊິ່ງເປັນສິ່ງທີ່ອະນຸຍາດໃຫ້ອະນຸສັນຍາພື້ນຖານ (Ethereum ໃນກໍລະນີນີ້) - ເພື່ອຕັດສິນການຂັດແຍ້ງແລະລົງໂທດຝ່າຍທີ່ບໍ່ຊື່ສັດ. ການອອກແບບໃນປະຈຸບັນຂອງ Ethereum ອະນຸຍາດໃຫ້ຕັດເຖິງ 50% ຂອງຫຸ້ນຂອງຜູ້ກວດສອບ (16 ETH), ເຊິ່ງເຮັດໃຫ້ EigenLayer ມີສິດທີ່ຈະຕັດສ່ວນທີ່ເຫຼືອ 50% (16 ETH) ໃນກໍລະນີທີ່ຜູ້ປະກອບການລະເມີດກົດລະບຽບທີ່ລະບຸໄວ້ໂດຍ AVS ໃນຂະນະທີ່ປະຕິບັດວຽກງານ.

ກົນໄກການຂູດຂອງ EigenLayer ຍັງຊີ້ໃຫ້ເຫັນເຖິງຄວາມສ່ຽງຕໍ່ການຢຸດຄືນໃຫມ່: ການຖືກຕັດໂດຍການບໍລິການຫນຶ່ງຫຼຸດຜ່ອນການດຸ່ນດ່ຽງໂດຍລວມຂອງຜູ້ກວດສອບໃນສັນຍາສະຫມາດ EigenLayer ແລະ Beacon Chain ຂອງ Ethereum. ສິ່ງທີ່ສໍາຄັນ, ສະຖານະການທີ່ມີຂອບຈະປາກົດ, ແນວໃດກໍ່ຕາມ, ເມື່ອການຂູດຂື້ນເກີດຂື້ນເນື່ອງຈາກຂໍ້ບົກພ່ອງໃນເຫດຜົນຂອງການຂູດຮີດຂອງ AVS ໂດຍສະເພາະແລະບໍ່ແມ່ນຜົນມາຈາກການກະທໍາຜິດທີ່ພິສູດໄດ້. ໃນກໍລະນີນີ້, ການສູນເສຍລາງວັນຈາກການກວດສອບລະບົບຕ່ອງໂສ້ Ethereum ຕົ້ນຕໍ - ສົມມຸດວ່າສູງກວ່າລາງວັນຈາກການກວດສອບ AVS - ຈະເຮັດໃຫ້ ROI ຈາກການຟື້ນຕົວສູງສຸດຈາກທັດສະນະຂອງຜູ້ກວດສອບ.

ຄວາມສ່ຽງອີກອັນຫນຶ່ງທີ່ມີການຢຸດຄືນແບບ EigenLayer ກ່ຽວຂ້ອງກັບຄວາມສ່ຽງຂອງການ overcollateralization ແລະ undercollaterilaztion validator ແລະແນວຄວາມຄິດຂອງ stacking ຄວາມສ່ຽງ. ຈາກຕົວຢ່າງທີ່ຜ່ານມາຂອງ rehypothecation, ພວກເຮົາເຫັນວ່າພາກສ່ວນທີ່ rehypothecating ຫຼັກຊັບອາດຈະເປັນຫນີ້ສິນພ້ອມກັນກັບຜູ້ກູ້ຢືມທໍາອິດ (ທີ່ຄ້ໍາປະກັນແມ່ນໃຊ້ໃນການກູ້ຢືມເງິນໃຫມ່) ແລະຜູ້ໃຫ້ກູ້ສຸດທ້າຍໃນຕ່ອງໂສ້ (ຜູ້ທີ່ມີຂໍ້ຮຽກຮ້ອງກ່ຽວກັບຫຼັກຊັບຄໍ້າປະກັນສັນຍາ. ໂດຍຜູ້ກູ້ຢືມຕົ້ນສະບັບ).

ການເຄື່ອນໄຫວທີ່ຄ້າຍຄືກັນສາມາດຫຼິ້ນໄດ້ໃນການກໍ່ສ້າງຄືນໃຫມ່ເຊັ່ນ EigenLayer ຖ້າຜູ້ກວດສອບທີ່ຖືກຢຸດຄືນ (ໂດຍເຈດຕະນາຫຼືເຈດຕະນາ) ພ້ອມກັນເຮັດການກະທໍາຜິດທີ່ສາມາດຕັດໄດ້ໃນ Ethereum's Beacon Chain ແລະຫນຶ່ງຫຼືຫຼາຍກວ່າ AVSs. ຂຶ້ນກັບບ່ອນທີ່ການທັບຊ້ອນຄັ້ງທຳອິດເກີດຂຶ້ນ, AVSs ອື່ນໆອາດຈະບໍ່ມີສ່ວນຄ້າງໄວ້ເພື່ອຫຼຸດ - ເຮັດໃຫ້ການໂຈມຕີແບບບໍ່ມີຄວາມສ່ຽງຕໍ່ແອັບພລິເຄຊັນທີ່ປອດໄພໂດຍ EigenLayer.

ທີມງານ EigenLayer ໄດ້ຮັບຮູ້ vector ການໂຈມຕີນີ້ (ເບິ່ງເອກະສານຊ້ອນທ້າຍ B: ການວິເຄາະຄວາມສ່ຽງ Cryptoeconomic ຂອງ EigenLayer whitepaper ) ແລະໄດ້ເຮັດຫຼາຍຂັ້ນຕອນເພື່ອແກ້ໄຂຄວາມສ່ຽງນີ້. ນີ້ປະກອບມີການສະຫນອງ heuristic ຢ່າງເປັນທາງການສໍາລັບການປະເມີນ staker undercollateralization ແລະ overcollateralization ໃນ AVSs, ແລະຊີ້ໃຫ້ເຫັນແຜນການທີ່ຈະສະຫນອງຂໍ້ມູນການໃຫ້ຄໍາປຶກສາກັບນັກພັດທະນາ AVS ຜ່ານ dashboard ການຄຸ້ມຄອງຄວາມສ່ຽງໃນເວລາເປີດຕົວ.

Polkadot Parachains

ເຖິງແມ່ນວ່າສ່ວນຫຼາຍແມ່ນເປັນທີ່ຮູ້ຈັກສໍາລັບການເຮັດໃຫ້ການເຮັດວຽກຮ່ວມກັນລະຫວ່າງ blockchains heterogeneous, Polkadot ອີງໃສ່ຄວາມປອດໄພຮ່ວມກັນຢ່າງຫຼວງຫຼາຍ. ໃນຄວາມເປັນຈິງ, ຄວາມປອດໄພຮ່ວມກັນແມ່ນເຫດຜົນທີ່ວ່າລະບົບນິເວດຂອງ Polkadot ສາມາດແລກປ່ຽນຂໍ້ຄວາມໄດ້ໂດຍບໍ່ມີການແນະນໍາການສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈຫຼືຄວາມສ່ຽງດ້ານຄວາມປອດໄພ.

ໃນ Polkadot, ຊຸດຍ່ອຍຂອງຕົວກວດສອບຄວາມຖືກຕ້ອງ (ມີ tokens DOT ຢູ່ໃນລະບົບຕ່ອງໂສ້ Relay) ຖືກມອບໃຫ້ແບບສຸ່ມໃຫ້ກັບ parachains (ຄິດວ່າ "ຕ່ອງໂສ້ເດັກນ້ອຍ") ເພື່ອກວດສອບ blocks - ແລະຫຼັກຖານທີ່ກ່ຽວຂ້ອງ (PoV) - ຜະລິດໂດຍແຕ່ລະ parachain collator. collator ແມ່ນ node ທີ່ຮັບຜິດຊອບສໍາລັບການປະຕິບັດທຸລະກໍາຂອງ parachain ແລະສ້າງ "para-block" ທີ່ຖືກສົ່ງໄປຫາກຸ່ມ validator ຂອງ parachain ສໍາລັບການກວດສອບ.

ເນື່ອງຈາກການຢັ້ງຢືນ PoV ຂອງບລັອກແມ່ນມີຄວາມເຂັ້ມຂຸ້ນທາງດ້ານການຄິດໄລ່, ຕົວກວດສອບຕົວກໍານົດຕົວກໍານົດການ (ຊື່ສໍາລັບຜູ້ກວດສອບທີ່ຖືກມອບໝາຍໃຫ້ກັບ parachain) ໄດ້ຮັບລາງວັນເພີ່ມເຕີມສໍາລັບຫນ້າທີ່ນີ້. ຕັນທີ່ຖືກອະນຸມັດໂດຍ para-validators—ຫຼືຖືກຕ້ອງກວ່ານັ້ນ, ຄໍາຫມັ້ນສັນຍາການເຂົ້າລະຫັດລັບກັບ blocks ເຫຼົ່ານັ້ນ, ຖືກສົ່ງສໍາລັບການລວມເຂົ້າໄປໃນ Relay Chain (ຄິດວ່າ "ຕ່ອງໂສ້ພໍ່ແມ່"). ຕັນ parachain ກາຍເປັນສຸດທ້າຍຖ້າການອ້າງອິງບລັອກມັນຖືກອະນຸມັດໂດຍສ່ວນໃຫຍ່ຂອງຜູ້ກວດສອບທີ່ຍັງເຫຼືອຢູ່ໃນ Relay Chain.

ຈຸດສຸດທ້າຍແມ່ນຂ້ອນຂ້າງສໍາຄັນ: ເນື່ອງຈາກຈໍານວນຜູ້ກວດສອບແຕ່ລະ parachain ແມ່ນຕໍ່າ (ປະມານຫ້າຕົວກວດສອບຕໍ່ shard), ຄ່າໃຊ້ຈ່າຍໃນການທໍາລາຍ shards ສ່ວນບຸກຄົນແມ່ນຕໍ່າ. ເພື່ອປ້ອງກັນການໂຈມຕີດັ່ງກ່າວ, ໂປໂຕຄອນ Polkadot ຕ້ອງການ para-blocks ເພື່ອຜ່ານການກວດສອບຂັ້ນສອງໂດຍກຸ່ມອື່ນຂອງ nodes ທີ່ເລືອກແບບສຸ່ມ.

ຖ້າບລ໋ອກຖືກພິສູດແລ້ວວ່າບໍ່ຖືກຕ້ອງຫຼືບໍ່ສາມາດໃຊ້ໄດ້ (ເຊັ່ນ: ບາງສ່ວນຂອງຂໍ້ມູນຂາດຫາຍໄປ), ໂນດທີ່ຊື່ສັດສາມາດເລີ່ມການໂຕ້ແຍ້ງຢູ່ໃນລະບົບຕ່ອງໂສ້ Relay ຫຼັກ ເຊິ່ງຜູ້ກວດສອບ Relay Chain ທັງໝົດ ແມ່ນຕ້ອງການເພື່ອປະຕິບັດການໂຕ້ແຍ້ງຂອງບລັອກຄືນໃໝ່. ການໂຕ້ແຍ້ງສິ້ນສຸດລົງຫຼັງຈາກຜູ້ກວດສອບສູງສຸດ ⅔ ລົງຄະແນນສຽງໃຫ້ຝ່າຍໃດຝ່າຍໜຶ່ງຂອງຂໍ້ພິພາດ, ໂດຍຜູ້ກວດສອບທີ່ກະທໍາຜິດຈະຖືກຕັດເປັນຕ່ອງໂສ້ຖ້າການປະຕິບັດຄືນໃຫມ່ສະຫນັບສະຫນູນການອ້າງສິດຂອງການຕັດ.

ກົນໄກນີ້ຮັບປະກັນວ່າ parachains ທັງຫມົດໃນໂປໂຕຄອນ Polkadot ແບ່ງປັນຄວາມປອດໄພໃນລະດັບດຽວກັນ, ໂດຍບໍ່ຄໍານຶງເຖິງຂະຫນາດຂອງ validator ທີ່ກໍານົດໄວ້ໃນແຕ່ລະ shard. ຍິ່ງໄປກວ່ານັ້ນ, parachains ໄດ້ຮັບຄວາມປອດໄພຈາກແຫຼ່ງດຽວກັນ (ທຸກ para-blocks ໄດ້ຮັບການອະນຸມັດໂດຍ Relay Chain), ພວກເຂົາສາມາດໄວ້ວາງໃຈໃນຄວາມຖືກຕ້ອງຂອງຂໍ້ຄວາມທີ່ມາຈາກ shard ຫ່າງໄກສອກຫຼີກ (ໂດຍບໍ່ຈໍາເປັນຕ້ອງຮູ້ລາຍລະອຽດຂອງຄວາມເຫັນດີຫຼືລັດໃນພາຍຫລັງ).

ຄວາມປອດໄພ Interchain

ຄວາມປອດໄພຂອງ Interchain ໄດ້ຖືກອະທິບາຍວ່າເປັນຄໍາຕອບຂອງ Cosmos ໃນການຢຸດຄືນໃຫມ່ແລະມີຄວາມຄ້າຍຄືກັນກັບຮູບແບບຄວາມປອດໄພຮ່ວມກັນຂອງ Polkadot. ຄ້າຍຄືກັນກັບຄວາມສຳພັນລະຫວ່າງລະບົບຕ່ອງໂສ້ Relay ແລະ parachains ໃນ Polkadot, Cosmos ນຳໃຊ້ຮູບແບບ hub-and-spoke ບ່ອນທີ່ຕ່ອງໂສ້ຫຼາຍສາຍ (“Cosmos Zones”) ເຊື່ອມຕໍ່ກັບຕ່ອງໂສ້ຫຼັກ (“Cosmos Hub”) ແລະໄດ້ຮັບຄວາມປອດໄພຈາກມັນ. ເຫດຜົນຍັງຄ້າຍຄືກັນກັບ Polkadot ຂອງ: ເຮັດໃຫ້ຕ່ອງໂສ້ໃຫມ່ຮັກສາຄວາມປອດໄພໂດຍບໍ່ຈໍາເປັນຕ້ອງ bootstrap ເປັນ validator ທີ່ເຊື່ອຖືໄດ້ທີ່ກໍານົດໄວ້ຕັ້ງແຕ່ເລີ່ມຕົ້ນ (ເປັນວຽກງານທີ່ມີຄວາມຫຍຸ້ງຍາກຫຼາຍ) ແລະແທນທີ່ຈະແບ່ງປັນຄວາມປອດໄພທາງດ້ານເສດຖະກິດ - ປະສົມປະສານໃນຊັ້ນດຽວ - ກັບຕ່ອງໂສ້ອື່ນໆ.

ໃນ iteration ໃນປັດຈຸບັນຂອງຕົນ, ຄວາມປອດໄພ interchain ຮຽກຮ້ອງໃຫ້ມີ validator (ມີ staked tokens ATOM) ເພື່ອ validate ທັງ Cosmos Hub ແລະຕ່ອງໂສ້ຜູ້ບໍລິໂພກທັງຫມົດທີ່ເຊື່ອມຕໍ່ກັບມັນ. ຜູ້ກວດສອບການກະທຳທີ່ເປັນອັນຕະລາຍຕໍ່ລະບົບຕ່ອງໂສ້ຜູ້ບໍລິໂພກມີຄວາມສ່ຽງທີ່ຈະສູນເສຍການມີສ່ວນຮ່ວມໃນຕ່ອງໂສ້ຜູ້ໃຫ້ບໍລິການ (ສູນ Cosmos Hub ໃນກໍລະນີນີ້) ເປັນການຫຼຸດ.

ການຕັດຕົວກວດສອບການກະທຳຜິດໂດຍປົກກະຕິຮຽກຮ້ອງໃຫ້ມີການສົ່ງຕໍ່ແພັກເກັດທີ່ມີຫຼັກຖານຂອງພຶດຕິກຳທີ່ສາມາດຕັດໄດ້ຜ່ານຊ່ອງທາງ IBC (Inter-Blockchain Communication) ລະຫວ່າງຕ່ອງໂສ້ຜູ້ໃຫ້ບໍລິການ ແລະຕ່ອງໂສ້ຜູ້ບໍລິໂພກ. ດັ່ງນັ້ນ, ຄວາມປອດໄພ interchain ສາມາດເຫັນໄດ້ວ່າເປັນຮູບແບບຂອງການພັກຜ່ອນ; ນອກຈາກນັ້ນ, ມັນບັນລຸຈຸດປະສົງທີ່ສໍາຄັນ: ເຮັດໃຫ້ມັນງ່າຍຂຶ້ນໃນການເປີດຕົວ blockchains ສະເພາະຂອງແອັບພລິເຄຊັນໃນລະບົບນິເວດ Cosmos.

ກ່ອນຫນ້ານີ້, ໂຄງການທີ່ພະຍາຍາມສ້າງ blockchains ທີ່ມີອະທິປະໄຕແມ່ນຕ້ອງການເພື່ອສ້າງ token ພື້ນເມືອງສໍາລັບການສະເຕກແລະດຶງດູດຈໍານວນຜູ້ກວດສອບທີ່ພຽງພໍເພື່ອໃຫ້ຜູ້ໃຊ້ໃຫມ່ຮັບປະກັນຄວາມປອດໄພຂັ້ນຕ່ໍາ. ຢ່າງໃດກໍ່ຕາມ, ຄວາມປອດໄພຂອງ interchain ຮັບປະກັນຄວາມປອດໄພຂອງ Cosmos Hub (ຮັບປະກັນໂດຍ ~ $ 2.5b ໃນສະເຕກໃນເວລາຂຽນ) ສາມາດປັບຂະຫນາດເພື່ອຮັບປະກັນລະບົບຕ່ອງໂສ້ທີ່ມີຄ່າຕ່ໍາກວ່າໃຫມ່ໂດຍບໍ່ຈໍາເປັນຕ້ອງຂະຫຍາຍຂະຫນາດຂອງຊຸດ validator ທີ່ມີຢູ່ແລ້ວຂອງ Cosmo.

ໝາຍເຫດ : ສະບັບປັດຈຸບັນຂອງ Cosmos's Interchain Security ປິດການໃຊ້ງານ slashing ໂດຍອີງໃສ່ແພັກເກັດທີ່ສົ່ງຕໍ່ໂດຍລະບົບຕ່ອງໂສ້ຜູ້ບໍລິໂພກເນື່ອງຈາກຄວາມສ່ຽງຂອງລະຫັດອັນຕະລາຍໃນຕ່ອງໂສ້ຜູ້ບໍລິໂພກທີ່ເຮັດໃຫ້ເກີດການສົ່ງຕໍ່ແພັກເກັດສະໄລ້ປອມ ແລະ slashing ຜູ້ກວດສອບຄວາມຊື່ສັດ - ແທນທີ່ຈະເປັນການກະທໍາຜິດເຊັ່ນການລົງຄະແນນສຽງສອງຄັ້ງ (ເຊັນສອງ. blocks ໃນລະດັບຄວາມສູງດຽວກັນ) ແມ່ນຂຶ້ນກັບການ slashing ສັງຄົມໂດຍຜ່ານການປົກຄອງ. ການຂູດຮີດທາງດ້ານສັງຄົມແມ່ນມາພ້ອມກັບຄວາມສ່ຽງຂອງຕົນເອງ, ແນວໃດກໍ່ຕາມ, ດັ່ງທີ່ເຫັນໃນ ການໂຕ້ວາທີທີ່ຜ່ານມາກ່ຽວກັບການ slashing validators ສໍາລັບການລົງນາມສອງຄັ້ງໃນຕ່ອງໂສ້ຜູ້ບໍລິໂພກ (ເຊິ່ງຍັງຊີ້ໃຫ້ເຫັນເຖິງຄວາມສັບສົນບາງຢ່າງຂອງການສ້າງໂປໂຕຄອນຄວາມປອດໄພຮ່ວມກັນ) .

ຄວາມປອດໄພຂອງຕາຫນ່າງ ເປັນທາງເລືອກສໍາລັບຄວາມປອດໄພ interchain ແລະຊອກຫາການປັບປຸງບາງຂໍ້ບົກຜ່ອງອັນສຸດທ້າຍ. ແທນທີ່ຈະດໍາເນີນການຊອບແວສໍາລັບທັງຜູ້ໃຫ້ບໍລິການແລະລະບົບຕ່ອງໂສ້ຜູ້ບໍລິໂພກ, ຜູ້ກວດສອບທີ່ຖືຫຸ້ນຢູ່ໃນລະບົບຕ່ອງໂສ້ຜູ້ໃຫ້ບໍລິການສາມາດມອບຫມາຍຫຸ້ນໃຫ້ກັບຜູ້ກວດສອບໃນລະບົບຕ່ອງໂສ້ຜູ້ບໍລິໂພກ. ອັນນີ້ຍົກພາລະຂອງການກວດສອບສອງຕ່ອງໂສ້ໄປພ້ອມໆກັນ—ການມີສ່ວນຮ່ວມໃນການປົກຄອງ ແລະເປັນເອກະສັນກັນ—ແລະຫຼຸດຜ່ອນຄ່າຈ້າງສຳລັບຜູ້ກວດສອບທີ່ຄ້າງຄືນ (ເຊັ່ນ: ການຫຼຸດຜ່ອນຄວາມຕ້ອງການດ້ານຮາດແວ).

ຄືກັນກັບ EigenLayer (ບ່ອນທີ່ຜູ້ກວດສອບ Ethereum ສາມາດໃຫ້ຜູ້ປະກອບການກວດສອບໜຶ່ງ ຫຼືຫຼາຍກວ່າໜຶ່ງໂປຣໂຕຄອນຂັ້ນຮອງ (AVSs) ໃນນາມຂອງມັນ), ຕົວແທນຜູ້ກວດສອບ ບໍ່ຈຳເປັນຈະຕ້ອງວາງສະເຕກເພື່ອກວດສອບລະບົບຕ່ອງໂສ້ຜູ້ບໍລິໂພກ. ຖ້າຜູ້ກວດສອບຄວາມຖືກຕ້ອງຂອງຕົວແທນບໍ່ສາມາດປະຕິບັດຫນ້າທີ່ໄດ້ຢ່າງຖືກຕ້ອງ (ຕົວຢ່າງ, ປະສົບກັບເວລາຢຸດເຮັດວຽກຫຼືການສ້າງ / ການລົງຄະແນນສຽງສໍາລັບບລັອກທີ່ບໍ່ຖືກຕ້ອງ), ຕົວແທນ ຈະຖືກຕັດຢູ່ໃນລະບົບຕ່ອງໂສ້ຜູ້ບໍລິໂພກຕາມກົດລະບຽບຂອງໂປໂຕຄອນ.

ຄວາມປອດໄພຂອງຕາຫນ່າງຍັງແຕກຕ່າງຈາກຄວາມປອດໄພ interchain ຍ້ອນວ່າມັນອະນຸຍາດໃຫ້ລະບົບຕ່ອງໂສ້ຜູ້ບໍລິໂພກສາມາດເຊົ່າຄວາມປອດໄພຈາກລະບົບຕ່ອງໂສ້ຜູ້ໃຫ້ບໍລິການຫຼາຍ (ແທນທີ່ຈະຖືກຈໍາກັດຢູ່ໃນ Cosmos Hub) ແລະອະນຸຍາດໃຫ້ຜູ້ກວດສອບເລືອກວ່າຕ່ອງໂສ້ໃດທີ່ຈະມອບຫມາຍຫຸ້ນສ່ວນ. ໃນຂະນະທີ່ຄຸນສົມບັດສຸດທ້າຍໄດ້ຖືກວາງແຜນເປັນສ່ວນຫນຶ່ງຂອງ ICS v2 rollout, ອະດີດບໍ່ຫນ້າຈະປະຕິບັດໄດ້ (ເຖິງແມ່ນວ່າການໂຕ້ຖຽງແມ່ນຫນ້າສົນໃຈຫຼາຍ).

ຄະນະກໍາມະການ Sync ຂອງ Ethereum

ຄະນະກໍາມະການຊິງຄ໌ ຂອງ Ethereum ແມ່ນກຸ່ມຂອງ 512 validators ທີ່ຮັບຜິດຊອບສໍາລັບການເຊັນ off ສຸດສຸດທ້າຍ Beacon headers. ຄະນະກໍາມະການຊິງຄ໌ໃຫມ່ໄດ້ຖືກປະກອບໃຫມ່ທຸກໆ 256 ໄລຍະເວລາ (ປະມານ 27 ຊົ່ວໂມງ), ໂດຍມີສະມາຊິກທີ່ຖືກຄັດເລືອກຈາກຊຸດຜູ້ກວດສອບທີ່ມີຢູ່ແລ້ວຂອງ Beacon Chain. ໃຫ້ສັງເກດວ່າສະມາຊິກຄາດວ່າຈະສືບຕໍ່ຫນ້າທີ່ຜູ້ກວດສອບປົກກະຕິ (ລວມທັງການຢັ້ງຢືນແລະຂໍ້ສະເຫນີທາງຕັນ) ໃນຂະນະທີ່ເຂົ້າຮ່ວມໃນຄະນະກໍາມະການ Sync.

ຄະນະກໍາມະການ Sync ໄດ້ຖືກປະຕິບັດຄັ້ງທໍາອິດໃນໄລຍະ fork Altair ຂອງ Beacon Chain ເພື່ອເຮັດໃຫ້ລູກຄ້າແສງສະຫວ່າງສາມາດກວດສອບຕັນໃຫມ່ (ໂດຍບໍ່ຮູ້ຊຸດຜູ້ກວດສອບຢ່າງເຕັມທີ່) ແລະຕິດຕາມການປ່ຽນແປງໃນສະຖານະຂອງ Ethereum. ນັບຕັ້ງແຕ່ການເຂົ້າຮ່ວມໃນຄະນະກໍາມະ Sync ຮຽກຮ້ອງໃຫ້ມີຄວາມພະຍາຍາມຫຼາຍກ່ວາພຽງແຕ່ເຂົ້າຮ່ວມໃນ Beacon Chain consensus, ສະມາຊິກໄດ້ຮັບລາງວັນເລັກນ້ອຍ (ນອກຈາກລາງວັນປົກກະຕິສໍາລັບການສໍາເລັດຫນ້າທີ່ລະບົບຕ່ອງໂສ້ Beacon).

ແນວໃດກໍ່ຕາມ, ສະມາຊິກທີ່ລົງນາມໃນສ່ວນຫົວຂອງບຼັອກທີ່ບໍ່ຖືກຕ້ອງແມ່ນບໍ່ຂຶ້ນກັບການຫຼຸດ-ບໍ່ຄືກັບ Beacon Chain. devs ຫຼັກຂອງ Ethereum ໄດ້ປ້ອງກັນການອອກແບບນີ້ໂດຍກ່າວວ່າການທໍາລາຍສະມາຊິກຄະນະກໍາມະການ Sync ທີ່ເປັນອັນຕະລາຍຈະແນະນໍາຄວາມສັບສົນຫຼາຍ, ໃນຂະນະທີ່ຄົນອື່ນໄດ້ຊີ້ໃຫ້ເຫັນເຖິງຄວາມຫຍຸ້ງຍາກຂອງການສົມຮູ້ຮ່ວມຄິດໃນບັນດາສະມາຊິກຄະນະກໍາມະການ Sync ສ່ວນໃຫຍ່ (ສິ່ງທີ່ມັນຕ້ອງການເພື່ອຫລອກລວງລູກຄ້າໃຫ້ຍອມຮັບສິ່ງທີ່ບໍ່ດີ. block header).

ແຕ່ດ້ວຍຄໍາຮ້ອງສະຫມັກທີ່ມີຄ່າສູງ - ເຊັ່ນໂປໂຕຄອນການສື່ສານຂ້າມຕ່ອງໂສ້ - ອີງໃສ່ລູກຄ້າແສງສະຫວ່າງເພື່ອຕິດຕາມສະຖານະຂອງ Ethereum, ຫົວຂໍ້ຂອງ slashing ຄະນະກໍາມະການ Sync ສໍາລັບການເຊັນຫົວບລັອກທີ່ບໍ່ຖືກຕ້ອງໄດ້ດຶງດູດຄວາມສົນໃຈໃຫມ່ (cf. ການສະເຫນີຢ່າງຕໍ່ເນື່ອງໂດຍທີມງານລູກຄ້າ Nimbus. ). ຖ້າຖືກປະຕິບັດ, ການຂູດຮີດຈະເຮັດໃຫ້ການມີສ່ວນຮ່ວມໃນຄະນະກໍາມະການ Sync ເຂົ້າໄປໃນຮູບແບບຂອງການຢຸດຄືນໃຫມ່, ເຊິ່ງຜູ້ກວດສອບເລືອກເຂົ້າໃນເງື່ອນໄຂການຂູດເພີ່ມເຕີມແລະໄດ້ຮັບລາງວັນພິເສດສໍາລັບການບໍລິການຂັ້ນສອງຂອງການເຊັນຊື່ບລັອກ headers.

ເພື່ອສະແດງໃຫ້ເຫັນ, ຜູ້ກວດສອບສາມາດຖືກຕັດ - ເຖິງຍອດສູງສຸດຂອງພວກເຂົາ - ຖ້າພວກເຂົາລະເມີດກົດລະບຽບໂປໂຕຄອນໃນຂະນະທີ່ຢູ່ໃນຄະນະກໍາມະການ Sync, ເຖິງແມ່ນວ່າພວກເຂົາປະຕິບັດຢ່າງຊື່ສັດໃນຂະນະທີ່ເຂົ້າຮ່ວມໃນຄວາມເຫັນດີຂອງ Beacon Chain. ພວກເຮົາຍັງສາມາດປຽບທຽບຄະນະກໍາມະ Sync ກັບລະບົບ parachain ຂອງ Polkadot ແລະຮູບແບບອື່ນໆຂອງຄວາມປອດໄພຮ່ວມກັນທີ່ສຸ່ມຕົວຢ່າງຂອງຂໍ້ຍ່ອຍເພື່ອກວດສອບອະນຸສັນຍາຍ່ອຍພາຍໃນເຄືອຂ່າຍ blockchain ທີ່ໃຫຍ່ກວ່າ (ຕົວຢ່າງ, ຄະນະກໍາມະການຂອງລັດ Lagrange, Subnets ຂອງ Avalanche, ແລະອະນຸສັນຍາຂອງລັດ Algorand) .

ການກວດກາ

ລະບົບຄວາມປອດໄພທີ່ໃຊ້ຮ່ວມກັນໂດຍອີງໃສ່ການກວດກາມັກຈະກ່ຽວຂ້ອງກັບ ລະບົບຕ່ອງໂສ້ການບໍລິໂພກຄວາມປອດໄພ ທີ່ປະກາດຄໍາໝັ້ນສັນຍາການເຂົ້າລະຫັດລັບກັບສະຖານະຫຼ້າສຸດຂອງມັນຕໍ່ກັບ ລະບົບຕ່ອງໂສ້ທີ່ສະໜອງຄວາມປອດໄພ ເປັນໄລຍະໆ. ຕົວຢ່າງ, ຜູ້ສະເໜີບຼັອກອາດຈະຖືກກຳນົດໃຫ້ໂພສ hash ຂອງສ່ວນຫົວບລັອກໃໝ່ຫຼ້າສຸດໃສ່ຕ່ອງໂສ້ຫຼັກ ກ່ອນທີ່ມັນຈະສຳເລັດ.

ຄໍາຫມັ້ນສັນຍາເຫຼົ່ານີ້ຖືກອະທິບາຍວ່າເປັນ "ຈຸດກວດກາ" ເພາະວ່າລະບົບຕ່ອງໂສ້ພໍ່ແມ່ຮັບປະກັນການປະຕິເສດຂອງປະຫວັດຂອງລະບົບຕ່ອງໂສ້ເດັກທີ່ນໍາໄປສູ່ຈຸດນັ້ນ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ລະບົບຕ່ອງໂສ້ພໍ່ແມ່ຮັບປະກັນແລະບັງຄັບໃຊ້ຄໍາສັ່ງທີ່ໃຊ້ເວລາ (canonical) ຂອງລະບົບຕ່ອງໂສ້ເດັກ, ປົກປ້ອງມັນຈາກຄວາມພະຍາຍາມທີ່ຈະຈັດລະບຽບໃຫມ່ແລະສ້າງທາງແຍກທີ່ຂັດແຍ້ງກັນ (ຕົວຢ່າງ. ກັບຄືນການເຮັດທຸລະກໍາເກົ່າແລະປະຕິບັດການໃຊ້ຈ່າຍສອງເທົ່າ). .

ລະບົບຕ່ອງໂສ້ພໍ່ແມ່ອາດຈະຮັບປະກັນຄວາມຖືກຕ້ອງຂອງລະບົບຕ່ອງໂສ້ເດັກ, ໂດຍສະເພາະບ່ອນທີ່ຫົວບລັອກມີຂໍ້ມູນກ່ຽວກັບຜູ້ທີ່ຢັ້ງຢືນ / ຜະລິດບລັອກໂດຍສະເພາະ. ຖ້າຕັນໃດນຶ່ງປະກົດວ່າບໍ່ຖືກຕ້ອງ, ໂຫນດທີ່ຊື່ສັດສາມາດເລີ່ມການທ້າທາຍໃນຕ່ອງໂສ້ພໍ່ແມ່ (ໂດຍລະບົບຕ່ອງໂສ້ແມ່ເປັນຜູ້ຊີ້ຂາດການໂຕ້ແຍ້ງ) ແລະເຮັດໃຫ້ເກີດການເລື່ອນລັດຂອງຕ່ອງໂສ້ລູກ.

ນອກຈາກນັ້ນ, ຖ້າກົນໄກໃນການຄຸ້ມຄອງຜູ້ກວດສອບສະເຕກ (ຄືກັບສັນຍາສະຫຼາດ) ຖືກປະຕິບັດຢູ່ໃນລະບົບຕ່ອງໂສ້ແມ່, ມັນເປັນໄປໄດ້ທີ່ຈະບັງຄັບໃຊ້ຄວາມປອດໄພທີ່ຮັບຜິດຊອບໂດຍການຕັດຜູ້ກວດສອບທີ່ລະເມີດໂປຣໂຕຄໍຫຼັງຈາກຫຼັກຖານການສໍ້ໂກງທີ່ຖືກຕ້ອງຖືກຍອມຮັບໃນລະບົບຕ່ອງໂສ້. ວ່າລະບົບຕ່ອງໂສ້ພໍ່ແມ່ຮັບປະກັນປະຫວັດສາດ canonical ຂອງລະບົບຕ່ອງໂສ້ເດັກແມ່ນສໍາຄັນຢູ່ທີ່ນີ້ນັບຕັ້ງແຕ່ມັນປ້ອງກັນບໍ່ໃຫ້ nodes ຈາກການຂຽນປະຫວັດສາດໃຫມ່ (ໂດຍການຖອນຕັນ) ເພື່ອຊ່ອນຫຼັກຖານຂອງພຶດຕິກໍາທີ່ເປັນອັນຕະລາຍ.

Commit sidechains (Polygon PoS), optimiums (Arbitrum Nova/Metis), rollups, ແລະ chains ປະສົມປະສານກັບໂປໂຕຄອນ checkpointing ເຊັ່ນ Babylon ປະຕິບັດຮູບແບບຂອງຄວາມປອດໄພຮ່ວມກັນນີ້. ໃນທຸກກໍລະນີ, ອະນຸສັນຍາໄດ້ມາຈາກຄວາມປອດໄພທາງເສດຖະກິດຂອງຕົນຈາກລະບົບຕ່ອງໂສ້ blockchain ພາຍນອກໂດຍການນໍາໃຊ້ມັນເປັນຊັ້ນການຕັ້ງຖິ່ນຖານ (ຮັບຜິດຊອບສໍາລັບການສຸດທ້າຍຂອງຕັນ). ສໍາລັບສະພາບການ, Polygon PoS ແລະ Arbitrum Nova/Metis store headers ໃນສັນຍາແບບຕ່ອງໂສ້ໃນ Ethereum, ໃນຂະນະທີ່ Babylon ຖ່າຍທອດ headers ຈາກ Cosmos Zones ທີ່ເຊື່ອມຕໍ່ຫາ Bitcoin.

Layer 2 (L2) rollups ໃຊ້ກົນໄກທີ່ຄ້າຍຄືກັນ (ການໂພດຮາກ block ກັບ Layer 1 blockchain), ໂດຍມີຄວາມແຕກຕ່າງທີ່ສໍາຄັນ: ຂໍ້ມູນທີ່ຕ້ອງການເພື່ອສ້າງ blocks ຂອງມ້ວນແມ່ນໄດ້ຖືກຈັດພີມມາຢູ່ໃນຊັ້ນການຕັ້ງຖິ່ນຖານ. ນີ້ ໝາຍ ຄວາມວ່າຊັ້ນການຕັ້ງຖິ່ນຖານຮັບປະກັນຄວາມປອດໄພຂອງ rollup (ໃນທີ່ສຸດ). ໃນທາງກົງກັນຂ້າມ, ຂໍ້ມູນທີ່ຕ້ອງການເພື່ອສ້າງສະຖານະຂອງ commit sidechain ຫຼືລະບົບຕ່ອງໂສ້ໃນແງ່ດີອາດຈະບໍ່ມີໃຫ້, ໂດຍສະເພາະໃນກໍລະນີຂອງຕົວຕໍ່ເນື່ອງທີ່ເປັນອັນຕະລາຍຫຼືຜູ້ກວດສອບທີ່ກໍານົດໄວ້ປະຕິບັດການໂຈມຕີຫັກຂໍ້ມູນ.

ຄວາມ​ປອດ​ໄພ​ທີ່​ແບ່ງ​ປັນ​ສໍາ​ລັບ​ອະ​ນຸ​ສັນ​ຍາ​ການ​ຮ່ວມ​ມື​ລະ​ບົບ​ຕ່ອງ​ໂສ້​

ໂດຍໄດ້ໃຫ້ຂໍ້ມູນພື້ນຖານອັນກວ້າງຂວາງກ່ຽວກັບຄວາມໝາຍ ແລະວິວັດທະນາການຂອງຄວາມປອດໄພຮ່ວມກັນ, ຕອນນີ້ພວກເຮົາສາມາດເຈາະເລິກເຖິງເຂດແດນໃໝ່ໃນການອອກແບບຄວາມປອດໄພຮ່ວມກັນ. ຫນຶ່ງໃນພື້ນທີ່ການຄົ້ນຄວ້າດັ່ງກ່າວແມ່ນ ຄວາມປອດໄພຮ່ວມກັນສໍາລັບໂປໂຕຄອນຂ້າມຕ່ອງໂສ້ , ເຊິ່ງຊອກຫາວິທີທີ່ຈະປັບປຸງວິທີການສົ່ງຂໍ້ຄວາມໃນປະຈຸບັນແລະການເຊື່ອມໂຍງລະຫວ່າງ blockchains ໂດຍການນໍາໃຊ້ຜົນປະໂຫຍດຂອງຄວາມປອດໄພລວມ (ເສດຖະກິດ).

ຄໍານິຍາມນີ້ອາດຈະເຮັດໃຫ້ເກີດຄໍາຖາມຢູ່ໃນໃຈຂອງຜູ້ອ່ານ, ເຊັ່ນ:

• ເປັນຫຍັງການເນັ້ນຢ່າງຈະແຈ້ງກ່ຽວກັບໂປຣໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນ?

• ຜົນປະໂຫຍດອັນໃດແດ່ທີ່ອະນຸສັນຍາການໂຕ້ຕອບກັນໄດ້ມາຈາກການລວມເຂົ້າກັບເຕັກໂນໂລຊີຄວາມປອດໄພຮ່ວມກັນ?

  
  

Lagrange Labs ກໍາລັງສ້າງ ຄະນະກໍາມະການຂອງລັດ Lagrange — ການແກ້ໄຂຄວາມປອດໄພຮ່ວມກັນສໍາລັບໂປໂຕຄອນທີ່ຮຽກຮ້ອງໃຫ້ມີການເຂົ້າເຖິງຫຼັກຖານສະແດງຄວາມໄວ້ວາງໃຈຂອງລັດຂ້າມຕ່ອງໂສ້. (ຄະນະກໍາມະຂອງລັດໄດ້ລວມເອົາລະບົບຫຼັກຖານ ZK Big Data ຂອງ Lagrange ແລະໂຄງສ້າງພື້ນຖານການພັກຜ່ອນຂອງ EigenLayer ເພື່ອສ້າງພື້ນທີ່ຮ່ວມກັນຂອງຄວາມປອດໄພສໍາລັບໂປໂຕຄອນການເຊື່ອມໂຍງລະຫວ່າງລະບົບຕ່ອງໂສ້. ກໍ​ລະ​ນີ​ສໍາ​ລັບ​ການ​ເຊື່ອມ​ໂຍງ​ຂົວ​, ດັດ​ຊະ​ນີ​, ແລະ​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ຂໍ້​ຄວາມ​ກັບ​ໂຄງ​ລ່າງ​ພື້ນ​ຖານ​ຄະ​ນະ​ກໍາ​ມະ​ລັດ​.

primer ຫຍໍ້ກ່ຽວກັບໂປໂຕຄອນການດໍາເນີນການຮ່ວມກັນ

In Interoperability For Modular Blockchains: The Lagrange Thesis , ພວກເຮົາໄດ້ອະທິບາຍວ່າ ໂປຣໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນແມ່ນສໍາຄັນສໍາລັບການເຊື່ອມຕໍ່ blockchains siled ແລະຫຼຸດຜ່ອນບັນຫາກ່ຽວກັບການ fragmentation ຂອງສະພາບຄ່ອງແລະສະຖານະສໍາລັບຄໍາຮ້ອງສະຫມັກ blockchain (ແລະຜູ້ໃຊ້ຂອງເຂົາເຈົ້າ). ບາງຕົວຢ່າງທີ່ສໍາຄັນທີ່ໄດ້ກ່າວມາໃນບົດຄວາມນັ້ນປະກອບມີ:

• ຂົວທີ່ປະຕິບັດກົນໄກ lock-and-mint ຫຼື burn-and-mint ແລະອະນຸຍາດໃຫ້ໂອນຊັບສິນຈາກ blockchain ພື້ນເມືອງ (ບ່ອນທີ່ມັນຖືກອອກ) ສໍາລັບການນໍາໃຊ້ໃນ blockchain ທີ່ບໍ່ແມ່ນພື້ນເມືອງ

• ໂປຣໂຕຄອນການສົ່ງຂໍ້ຄວາມທີ່ອະນຸຍາດໃຫ້ຜູ້ໃຊ້ສາມາດຖ່າຍທອດຂໍ້ມູນໄດ້ຢ່າງປອດໄພ (ຜ່ານຊຸດຂໍ້ມູນ) ລະຫວ່າງ blockchains ທີ່ບໍ່ແບ່ງປັນແຫຼ່ງຄວາມຈິງອັນດຽວ ແລະບໍ່ສາມາດກວດສອບສະຖານະຂອງກັນແລະກັນໄດ້.

  
  

ພວກ​ເຮົາ​ຍັງ​ໄດ້​ຍົກ​ໃຫ້​ເຫັນ​ຄຸນ​ຄ່າ​ຂອງ​ປະ​ເພດ​ທີ່​ແຕກ​ຕ່າງ​ກັນ​ຂອງ ​ການ​ແກ້​ໄຂ​ການ​ປະ​ຕິ​ບັດ​ການ blockchain . ຕົວຢ່າງເຊັ່ນ, ຂົວຊ່ວຍໃຫ້ຜູ້ໃຊ້ສາມາດເຄື່ອນຍ້າຍໄດ້ຢ່າງບໍ່ຢຸດຢັ້ງລະຫວ່າງລະບົບນິເວດທີ່ແຕກຕ່າງກັນ, ໄດ້ຮັບການເປີດນໍາໃຊ້ຫຼາຍຂື້ນ, ແລະເພີ່ມປະສິດທິພາບຂອງຊັບສິນ (ໂດຍການໃຊ້ປະໂຫຍດຈາກໂອກາດການສ້າງຜົນຜະລິດທີ່ມີຢູ່ໃນ blockchains ອື່ນໆ). ໂປໂຕຄອນການສົ່ງຂໍ້ຄວາມຍັງປົດລັອກກໍລະນີການນໍາໃຊ້ທີ່ກ້າວຫນ້າເຊັ່ນ: ການປ່ອຍເງິນກູ້ຂ້າມຕ່ອງໂສ້, ການຕັດຕ່ອງໂສ້ຂ້າມຕ່ອງໂສ້, ແລະການກໍານົດຂອບເຂດຂອງຕ່ອງໂສ້ຂ້າມຕ່ອງໂສ້ທີ່ອີງໃສ່ການໂອນຂໍ້ມູນ (ຕົວຢ່າງ, ຕໍາແຫນ່ງແລະໂປຣໄຟລ໌ຫນີ້ສິນ) ລະຫວ່າງໂດເມນຕ່າງໆ.

ເຖິງແມ່ນວ່າຖືກອອກແບບເພື່ອຈຸດປະສົງທີ່ແຕກຕ່າງກັນ, ການແກ້ໄຂການໂຕ້ຕອບທີ່ແຕກຕ່າງກັນທັງຫມົດມີຄຸນສົມບັດພື້ນຖານບາງຢ່າງ. ສິ່ງທີ່ ສຳ ຄັນທີ່ສຸດແມ່ນກົນໄກການຢັ້ງຢືນວ່າບາງຂໍ້ມູນກ່ຽວກັບ blockchain ທີ່ກ່ຽວຂ້ອງກັບການເຮັດທຸລະ ກຳ / ການດໍາເນີນງານຂ້າມຕ່ອງໂສ້ - ສະຫນອງໃຫ້ໂດຍຜູ້ໃຊ້ຫຼືແອັບພລິເຄຊັນ - ເປັນຄວາມຈິງ. ໂດຍທົ່ວໄປແລ້ວນີ້ແມ່ນການອ້າງວ່າສະຖານະສະເພາະ (ເຊັ່ນ: ຄ່າທີ່ເກັບໄວ້ໃນບ່ອນເກັບມ້ຽນຂອງສັນຍາອັດສະລິຍະ, ຍອດເງິນຂອງບັນຊີ, ຫຼືການປິດກັ້ນຫຼ້າສຸດ) ມີຢູ່, ຫຼືວ່າທຸລະກໍາເກີດຂຶ້ນຢູ່ໃນລະບົບຕ່ອງໂສ້ທີ່ແຕກຕ່າງກັນ.

ເອົາຕົວຢ່າງຂອງຂົວລະຫວ່າງ Ethereum ແລະ NEAR; ຜູ້ປະຕິບັດການຂອງຂົວຈະຕ້ອງມີການກວດສອບຂໍ້ມູນຕໍ່ໄປນີ້ກ່ຽວກັບສະຖານະຂອງແຕ່ລະຕ່ອງໂສ້ໃນເວລາທີ່ຜູ້ໃຊ້ກໍາລັງເຊື່ອມຕໍ່ຊັບສິນ (ເຊັ່ນ: DAI):

• ກ່ອນທີ່ຈະ minting near DAI tokens ກັບທີ່ຢູ່ NEAR ຂອງຜູ້ໃຊ້, ຜູ້ປະຕິບັດການຂົວຕ້ອງການຫຼັກຖານທີ່ກ່າວວ່າຜູ້ໃຊ້ໄດ້ຝາກ DAI ກັບສັນຍາຂອງຂົວໃນ Ethereum.
• ກ່ອນທີ່ຈະປ່ອຍເງິນຝາກ DAI ຕົ້ນສະບັບ (ເມື່ອຂົວຈາກ NEAR ໄປ Ethereum), ຜູ້ປະຕິບັດການຂົວຕ້ອງການຫຼັກຖານທີ່ກ່າວວ່າຜູ້ໃຊ້ໄດ້ເຜົາຢູ່ໃກ້ກັບ DAI tokens ໃນ NEAR ແລະສົ່ງໃບຮັບເງິນ "ຫຼັກຖານສະແດງການເຜົາໄຫມ້" ທີ່ຈໍາເປັນໄປຫາສັນຍາຂອງຂົວໃນ NEAR.

ອະນຸສັນຍາການສົ່ງຂໍ້ຄວາມລະຫວ່າງຕ່ອງໂສ້ທີ່ໄດ້ກ່າວມາຂ້າງເທິງຈະມີຄວາມຕ້ອງການທີ່ຄ້າຍຄືກັນ, ແຕ່ແຕກຕ່າງກັນເລັກນ້ອຍ. ຖ້າຜູ້ໃຊ້ Ethereum ຮ້ອງຂໍໃຫ້ມີການປະຕິບັດການເຮັດທຸລະກໍາຂ້າມລະບົບຕ່ອງໂສ້ ("ໂທຫາສັນຍາ X ໃນ NEAR"), ໂປໂຕຄອນຕ້ອງກວດສອບວ່າຄໍາຮ້ອງຂໍຂໍ້ຄວາມໄດ້ຖືກວາງໄວ້ໃນເບື້ອງຕົ້ນໃນ Ethereum (ໂດຍປົກກະຕິໂດຍການໂທຫາສັນຍາໃນລະບົບຕ່ອງໂສ້).

ວິທີທີ່ກົງໄປກົງມາໃນການກວດສອບການຮຽກຮ້ອງກ່ຽວກັບການເຮັດທຸລະກໍາຂ້າມຕ່ອງໂສ້ແມ່ນການດໍາເນີນການ node ເຕັມສໍາລັບຕ່ອງໂສ້ໃນຄໍາຖາມ. nodes ເຕັມທີ່ດາວໂຫຼດທຸລະກໍາຈາກແຕ່ລະ block ແລະດໍາເນີນການຄືນໃຫມ່ກ່ອນທີ່ຈະ syncing ສະຖານະຫລ້າສຸດຂອງລະບົບຕ່ອງໂສ້ແມ່ນປົກກະຕິແລ້ວວິທີການທີ່ເຊື່ອຖືໄດ້ຫຼາຍທີ່ສຸດໃນການກວດສອບການຫັນປ່ຽນຂອງລັດໃນ blockchain ໃດ. ຢ່າງໃດກໍຕາມ, ແລ່ນ node ເຕັມແມ່ນທັງສອງຢ່າງລໍາບາກແລະບໍ່ຈໍາເປັນ; ຫຍຸ້ງຍາກເພາະວ່າຂໍ້ເຕັມຕ້ອງການຄວາມຕ້ອງການຮາດແວສູງ, ແລະບໍ່ຈໍາເປັນເພາະວ່າໂປໂຕຄອນຂ້າມຕ່ອງໂສ້ພຽງແຕ່ຕ້ອງການຂໍ້ມູນທີ່ກ່ຽວຂ້ອງກັບບາງຊຸດຂອງທຸລະກໍາແລະສັນຍາ.

ໂຊກດີ, ລູກຄ້າແສງສະຫວ່າງ ສະຫນອງວິທີທີ່ງ່າຍ / ປະສິດທິພາບໃນການຕິດຕາມເຫດການແລະການປ່ຽນແປງຂອງລັດໂດຍບໍ່ຈໍາເປັນຕ້ອງດໍາເນີນການຂອງ node ເຕັມ. ເນື່ອງຈາກພວກເຮົາໄວ້ວາງໃຈໃນການອອກແບບຂອງລູກຄ້າແສງສະຫວ່າງ, ພວກເຮົາພຽງແຕ່ສາມາດດາວໂຫລດຫົວບລັອກເພື່ອກວດສອບຂໍ້ມູນສະເພາະເຊັ່ນການປະກົດຕົວຂອງເງິນຝາກ / ການຖອນເງິນໃນຂົວແລະສະຖານະການຮ້ອງຂໍ / ການປະຕິບັດຂໍ້ຄວາມໃນໂປໂຕຄອນການສົ່ງຂໍ້ຄວາມ.

ເພື່ອເຮັດໃຫ້ການສື່ສານລະຫວ່າງສອງຕ່ອງໂສ້ - ເຊິ່ງພວກເຮົາຈະເອີ້ນວ່າລະບົບຕ່ອງໂສ້ A ແລະຕ່ອງໂສ້ B - ໂປໂຕຄອນທີ່ສາມາດເຮັດວຽກຮ່ວມກັນຈະດໍາເນີນການລູກຄ້າແສງສະຫວ່າງຂອງລະບົບຕ່ອງໂສ້ A ໃນຕ່ອງໂສ້ B ທີ່ເກັບຮັກສາສ່ວນຫົວຂອງຕ່ອງໂສ້ B (ແລະໃນທາງກັບກັນ). ນີ້ເຮັດໃຫ້ມັນສາມາດກວດສອບຫຼັກຖານຕ່າງໆຂອງລັດ / ການເກັບຮັກສາ (ຫົວບລັອກ, ຫຼັກຖານສະແດງ Merkle, ແລະອື່ນໆ) ຜ່ານໂດຍຜູ້ໃຊ້ (ຫຼືບຸກຄົນທີສາມ) ຈາກແອັບພລິເຄຊັນໃນລະບົບຕ່ອງໂສ້ແຫຼ່ງໄປຫາແອັບພລິເຄຊັນອື່ນໃນຕ່ອງໂສ້ປາຍທາງ. ລູກຄ້າແສງສະຫວ່າງເຮັດຫນ້າທີ່ເປັນແຫລ່ງຂໍ້ມູນ (ເປັນ "oracle") ກ່ຽວກັບສະຖານະຂອງສອງ blockchains ດັ່ງທີ່ສະແດງຢູ່ໃນຮູບຂ້າງລຸ່ມນີ້:

ຢ່າງໃດກໍ່ຕາມ, ວິທີການກວດສອບຄວາມຖືກຕ້ອງຂອງລັດຂ້າມຕ່ອງໂສ້ນີ້ແລ່ນເຂົ້າໄປໃນບັນຫາຄວາມໄວ້ວາງໃຈ. ບົດຄວາມຂອງ Vitalik Buterin Trust Models ໃຫ້ຄໍານິຍາມຂອງຄວາມໄວ້ວາງໃຈ: " ຄວາມໄວ້ວາງໃຈແມ່ນການນໍາໃຊ້ສົມມຸດຕິຖານໃດໆກ່ຽວກັບພຶດຕິກໍາຂອງຄົນອື່ນ. ” ບົດຄວາມຍັງກໍານົດແນວຄວາມຄິດຂອງຄວາມບໍ່ໄວ້ວາງໃຈ (ດ້ວຍຄໍາເຕືອນ):

ຫນຶ່ງໃນຄຸນສົມບັດທີ່ມີຄຸນຄ່າທີ່ສຸດຂອງຄໍາຮ້ອງສະຫມັກ blockchain ຈໍານວນຫຼາຍແມ່ນຄວາມຫນ້າເຊື່ອຖື: ຄວາມສາມາດຂອງຄໍາຮ້ອງສະຫມັກທີ່ຈະສືບຕໍ່ປະຕິບັດງານໃນລັກສະນະທີ່ຄາດໄວ້ໂດຍບໍ່ຈໍາເປັນຕ້ອງອີງໃສ່ນັກສະແດງສະເພາະທີ່ຈະປະຕິບັດໃນລັກສະນະສະເພາະໃດຫນຶ່ງເຖິງແມ່ນວ່າຜົນປະໂຫຍດຂອງເຂົາເຈົ້າອາດຈະມີການປ່ຽນແປງແລະຊຸກຍູ້ໃຫ້ເຂົາເຈົ້າປະຕິບັດ. ໃນບາງວິທີທີ່ບໍ່ຄາດຄິດທີ່ແຕກຕ່າງກັນໃນອະນາຄົດ. ຄໍາຮ້ອງສະຫມັກ Blockchain ບໍ່ເຄີຍມີຄວາມຫນ້າເຊື່ອຖືຢ່າງເຕັມທີ່, ແຕ່ບາງຄໍາຮ້ອງສະຫມັກແມ່ນໃກ້ຊິດກັບຄວາມໄວ້ວາງໃຈຫຼາຍກ່ວາຄົນອື່ນ. - Vitalik Buterin

ໃນສະພາບການຂອງພວກເຮົາ (blockchain interoperability), ຄວາມໄວ້ວາງໃຈຈະກາຍເປັນສິ່ງທີ່ຫຼີກລ່ຽງບໍ່ໄດ້ເມື່ອສະຖານະຂອງຕ່ອງໂສ້ສອງຫຼືຫຼາຍກວ່ານັ້ນຖືກກວດສອບຢ່າງເປັນເອກະລາດເຊິ່ງກັນແລະກັນ. ພິ​ຈາ​ລະ​ນາ​ສະ​ຖາ​ນະ​ການ​ທີ່​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ Bob ກ່ຽວ​ກັບ​ຕ່ອງ​ໂສ້ A ໄດ້​ຮັບ​ຫຼັກ​ຖານ​ວ່າ Alice ໄດ້​ເລີ່ມ​ຕົ້ນ​ຂໍ້​ຄວາມ (“lock 5 ETH on chain B and mint 5 Wrapped ETH (WETH) on chain A”). ຫຼັກຖານສະແດງຂໍ້ຄວາມແມ່ນ ຫຼັກຖານສະແດງ Merkle ສະແດງໃຫ້ເຫັນເຖິງການລວມເອົາທຸລະກໍາຂອງ Alice ໃນບລັອກ, ເຊິ່ງ Bob - ຍ້ອນວ່າລາວດໍາເນີນການລູກຄ້າທີ່ມີແສງສະຫວ່າງໃນລະບົບຕ່ອງໂສ້ B - ສາມາດກວດສອບໄດ້ໂດຍການປຽບທຽບຫຼັກຖານຕໍ່ກັບຮາກ Merkle ຂອງທຸລະກໍາທີ່ໄດ້ມາຈາກສ່ວນຫົວຂອງ ບລັອກລະບົບຕ່ອງໂສ້ B ທີ່ຖືກຕ້ອງ.

ແນວໃດກໍ່ຕາມ, "ຖືກຕ້ອງ" ໃນບໍລິບົດຂອງຕັນສາມາດຫມາຍເຖິງສິ່ງທີ່ແຕກຕ່າງກັນ: (a) "ສ່ວນຫົວຂອງບລັອກເປັນຂອງຕັນທີ່ຖືກອະນຸມັດໂດຍຜູ້ກວດສອບລະບົບຕ່ອງໂສ້ແຫຼ່ງສ່ວນໃຫຍ່." (b) "ສ່ວນຫົວຂອງບລັອກເປັນຂອງບລັອກທີ່ມີທຸລະກຳທີ່ຖືກຕ້ອງຕາມກົດເກນຄວາມຖືກຕ້ອງຂອງການເຮັດທຸລະກຳຂອງລະບົບຕ່ອງໂສ້ແຫຼ່ງທີ່ມາ."

Bob ສາມາດປະຕິບັດ #1 ເປັນຫຼັກຖານທີ່ແນ່ນອນຂອງຄວາມຖືກຕ້ອງຂອງຕັນ, ແຕ່ນີ້ແມ່ນອີງໃສ່ການສົມມຸດຕິຖານກ່ຽວກັບຜູ້ກວດສອບລະບົບຕ່ອງໂສ້ແຫຼ່ງ:

• " ຜູ້ກວດສອບສ່ວນໃຫຍ່ໃນລະບົບຕ່ອງໂສ້ A ມີຄວາມຊື່ສັດແລະຈະບໍ່ອະນຸມັດການບລັອກທີ່ມີຫນຶ່ງຫຼືຫຼາຍກວ່າການເຮັດທຸລະກໍາທີ່ບໍ່ຖືກຕ້ອງ. ”
• " ຜູ້ກວດສອບສ່ວນໃຫຍ່ໃນລະບົບຕ່ອງໂສ້ A ແມ່ນນັກສະແດງທີ່ມີເຫດຜົນທາງດ້ານເສດຖະກິດແລະມີແຮງຈູງໃຈຕ່ໍາໃນການອະນຸມັດບລັອກທີ່ມີທຸລະກໍາທີ່ບໍ່ຖືກຕ້ອງ. ”

ໃນທີ່ນີ້, ມັນງ່າຍທີ່ຈະເບິ່ງບ່ອນທີ່ສົມມຸດຕິຖານເຫຼົ່ານີ້ (ຫຼືທັງສອງ) ສາມາດທໍາລາຍ - ຕົວຢ່າງ, ຖ້າ ຈໍານວນຮຸ້ນ <ມູນຄ່າຂອງການເຮັດທຸລະກໍາ ໃນລະບົບຕ່ອງໂສ້ A (ຕົວຢ່າງ, ຈໍານວນທີ່ສາມາດຖືກລັກຈາກຂົວຜ່ານການເຮັດທຸລະກໍາທີ່ຫຼອກລວງ). , ຜູ້ກວດສອບມີແຮງຈູງໃຈທີ່ຈະສໍາເລັດການປິດກັ້ນທີ່ບໍ່ຖືກຕ້ອງ - ເຖິງແມ່ນວ່າມັນຫມາຍຄວາມວ່າຖືກຕັດ - ນັບຕັ້ງແຕ່ກໍາໄລຈາກການໂຈມຕີເກີນຄ່າໃຊ້ຈ່າຍ.

ໂດຍທົ່ວໄປແລ້ວ, ທຸກໆກົນໄກໃນການກວດສອບລັດຂ້າມຕ່ອງໂສ້ແມ່ນຂຶ້ນກັບການສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈ (ພວກເຮົາຈະປຶກສາຫາລືບາງສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈເຫຼົ່ານີ້ໂດຍລະອຽດ). ຈຸດປະສົງທີ່ສໍາຄັນ - ແລະນີ້ແມ່ນຫົວຂໍ້ທີ່ເກີດຂື້ນຕະຫຼອດໃນບົດຄວາມນີ້ - ແມ່ນວ່າພວກເຮົາຕ້ອງການຫຼຸດຜ່ອນຄວາມໄວ້ວາງໃຈໃນການສື່ສານຂ້າມລະບົບຕ່ອງໂສ້ລົງໃນລະດັບທີ່ສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈຕ່າງໆບໍ່ໄດ້ສະແດງເຖິງຄວາມສ່ຽງດ້ານຄວາມປອດໄພອັນໃຫຍ່ຫຼວງສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ສຸມໃສ່ການເຮັດວຽກຮ່ວມກັນ.

ນີ້ແມ່ນຈຸດປະສົງທີ່ສໍາຄັນເພາະວ່າ, ເມື່ອທ່ານສ້າງໂປໂຕຄອນການໂຕ້ຕອບເພື່ອເຊື່ອມຕໍ່ blockchains ທີ່ແຕກຕ່າງກັນ, ແລະແອັບພລິເຄຊັນທີ່ເຮັດວຽກຢູ່ຂ້າງຫນຶ່ງຂອງການແບ່ງປັນຍອມຮັບການອ້າງທີ່ບໍ່ຖືກຕ້ອງວ່າບາງເຫດການທີ່ຕົນເອງມັກເກີດຂື້ນໃນອີກດ້ານຫນຶ່ງ, ສິ່ງທີ່ບໍ່ດີ - ສິ່ງທີ່ບໍ່ດີແທ້ໆ—ສາມາດເກີດຂຶ້ນໄດ້. ເພື່ອເປັນຕົວຢ່າງ, ການຂູດຮີດຂົວໄດ້ເກີດຂຶ້ນເນື່ອງຈາກວ່າ bug ໄດ້ເປີດໃຫ້ແຮັກເກີທີ່ມີຄວາມຮູ້ຄວາມສາ ມາດສົ່ງຕໍ່ສົບຜົນສໍາເລັດ (ປອມ) ຫຼັກຖານສະແດງຂອງຄໍາຮ້ອງຂໍຂໍ້ຄວາມທີ່ບໍ່ມີຢູ່ແລ້ວ ແລະ mint tokens ໃນຕ່ອງໂສ້ປາຍທາງໂດຍບໍ່ມີການຝາກຫຼັກຊັບໃນຕ່ອງໂສ້ແຫຼ່ງ.

ການວິເຄາະກົນໄກຄວາມປອດໄພຂ້າມຕ່ອງໂສ້ທີ່ມີຢູ່

ຕັ້ງແຕ່ນັ້ນມາ, ຜູ້ອອກແບບອະນຸສັນຍາໄດ້ມາເຖິງການແກ້ໄຂບັນຫາຂອງການກວດສອບຂໍ້ມູນໃນການສື່ສານຂ້າມຕ່ອງໂສ້; ທົ່ວໄປທີ່ສຸດແມ່ນການໃຊ້ພາກສ່ວນທີສາມເພື່ອກວດສອບການມີຢູ່ / ຄວາມຖືກຕ້ອງຂອງທຸລະກໍາຂ້າມຕ່ອງໂສ້. ເຫດຜົນແມ່ນງ່າຍດາຍ: ຄໍາຮ້ອງສະຫມັກກ່ຽວກັບລະບົບຕ່ອງໂສ້ A ອາດຈະບໍ່ສາມາດກວດສອບສະຖານະຂອງລະບົບຕ່ອງໂສ້ B, ແຕ່ພວກເຮົາສາມາດກວດສອບໄດ້ວ່າກຸ່ມຄົນ (ທີ່ພວກເຮົາໄວ້ວາງໃຈຫຼືຄາດວ່າຈະມີຄວາມຊື່ສັດໂດຍຜ່ານກົນໄກບາງຢ່າງ) ໄດ້ກວດສອບຊິ້ນສ່ວນຂອງ. ຂໍ້​ມູນ (ຫຼື​ການ​ຮ້ອງ​ຂໍ​) ອ້າງ​ອີງ​ເຖິງ​ສະ​ພາບ​ຂອງ​ຕ່ອງ​ໂສ້ B​.

ອັນນີ້ເອີ້ນວ່າ "ການກວດສອບພາຍນອກ" ນັບຕັ້ງແຕ່ພາກສ່ວນອື່ນ ທີ່ຢູ່ນອກ blockchain ເຮັດຫນ້າທີ່ເປັນແຫຼ່ງຂອງຄວາມຈິງສໍາລັບເຫດການໃນລະບົບຕ່ອງໂສ້ແລະ (ໂດຍປົກກະຕິ) ກ່ຽວຂ້ອງກັບຫນຶ່ງຫຼືຫຼາຍຕົວກວດສອບການດໍາເນີນການລາຍເຊັນໃນ blockheads ຈາກລະບົບຕ່ອງໂສ້ແຫຼ່ງ. ເມື່ອແອັບພລິເຄຊັນໃນລະບົບຕ່ອງໂສ້ປາຍທາງໄດ້ຮັບສ່ວນຫົວທີ່ເຊັນນີ້, ມັນສາມາດກວດສອບຫຼັກຖານຂອງລັດຕ່າງໆທີ່ໃຫ້ໂດຍຜູ້ໃຊ້ (ຍອດເງິນ, ເຫດການ, ເງິນຝາກ / ຖອນເງິນ, ແລະອື່ນໆ) ຕໍ່ກັບມັນ.

ເພື່ອສ້າງຄວາມທົນທານຕໍ່ຄວາມຜິດບາງລະດັບ, ບາງໂປຣໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນໄດ້ໃຊ້ລະບົບການລົງນາມໃນຂອບເຂດທີ່ຕ້ອງໃຊ້ລະຫັດສ່ວນຕົວໜ້ອຍສຸດເພື່ອດຳເນີນການລາຍເຊັນເພື່ອຄວາມຖືກຕ້ອງ (ຫຼາຍລາຍເຊັນ ແລະຫຼາຍຝ່າຍ (MPC) wallets ແມ່ນຕົວຢ່າງທົ່ວໄປ). ແຕ່ການມີຈຳນວນຫຼາຍ ( k ຂອງ n ) ຫຼືຂອງຕົວກວດສອບທີ່ຢືນຢັນເຖິງລັດຂ້າມຕ່ອງໂສ້ບໍ່ແມ່ນລູກປືນໃຫຍ່ເພື່ອຄວາມປອດໄພ, ໂດຍສະເພາະສຳລັບຜູ້ກວດສອບຊຸດນ້ອຍໆ.

ຕົວຢ່າງ, ບາງຄົນອາດຈະປະນີປະນອມພຽງແຕ່ຜູ້ລົງນາມພຽງພໍໃນໂຄງການ multisig ແລະດໍາເນີນການອະນຸຍາດໃຫ້ຖອນເງິນທີ່ຫຼອກລວງອອກຈາກຂົວຂ້າມຕ່ອງໂສ້. ການຕັ້ງຄ່າ MPC ແມ່ນມີຄວາມປອດໄພກວ່າເລັກນ້ອຍ (ເກນການອະນຸມັດສາມາດປ່ຽນແປງໄດ້ ແລະສ່ວນແບ່ງກະແຈຖືກໝຸນຂຶ້ນເລື້ອຍໆ), ແຕ່ຍັງມີຄວາມອ່ອນໄຫວຕໍ່ກັບການໂຈມຕີ (ໂດຍສະເພາະໃນກໍລະນີທີ່ຝ່າຍໜຶ່ງຄວບຄຸມສ່ວນແບ່ງຫຼັກສ່ວນໃຫຍ່).

ຢືນ

ວິທີຫນຶ່ງເພື່ອຫຼຸດຜ່ອນການສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈສໍາລັບອະນຸສັນຍາລະຫວ່າງປະເທດແລະເສີມຂະຫຍາຍຄວາມປອດໄພຂອງການສື່ສານຜ່ານລະບົບຕ່ອງໂສ້ແມ່ນການໃຫ້ຜູ້ກວດສອບພາຍນອກມີຫຼັກຊັບຄໍ້າປະກັນເປັນພັນທະບັດກ່ອນທີ່ຈະປະຕິບັດຫນ້າທີ່ກວດສອບ. Staking ສ້າງຄວາມປອດໄພສໍາລັບລະບົບການຢັ້ງຢືນຈາກພາຍນອກ, ໂດຍສະເພາະຍ້ອນວ່າຫຼັກຊັບຜູກມັດສາມາດຖືກຕັດໄດ້ຖ້າ node ກວດສອບປະຕິບັດລາຍເຊັນຢູ່ໃນຫົວບລັອກທີ່ບໍ່ຖືກຕ້ອງຫຼືອະນຸມັດທຸລະກໍາຂ້າມຕ່ອງໂສ້ທີ່ບໍ່ຖືກຕ້ອງ).

ແຕ່ເຖິງແມ່ນວິທີການນີ້ມາພ້ອມກັບບັນຫາຂຶ້ນກັບວ່າສະເຕກໄດ້ຮັບການອະນຸຍາດຫຼືບໍ່ອະນຸຍາດ. ລະບົບການອະນຸຍາດ (ບ່ອນທີ່ຜູ້ກວດສອບຕ້ອງຖືກບັນຊີຂາວ) ມັກຈະຖືກຈໍາກັດຢູ່ໃນບາງຫນ່ວຍງານທີ່ໄດ້ຮັບການອະນຸມັດກ່ອນແລະງ່າຍຕໍ່ການພັດທະນາ - ບໍ່ຈໍາເປັນຕ້ອງລົງທຶນໃນການອອກແບບແຮງຈູງໃຈທີ່ກວ້າງຂວາງ, ໂດຍສະເພາະບ່ອນທີ່ຜູ້ກວດສອບແມ່ນເປັນທີ່ຮູ້ຈັກສາທາລະນະແລະມີແຮງຈູງໃຈທີ່ຈະປະຕິບັດຢ່າງຊື່ສັດເພື່ອຮັກສາພວກມັນ. ຊື່ສຽງ. ມັນຍັງມີປະສິດທິພາບນັບຕັ້ງແຕ່ການສື່ສານ - ມີຄວາມຈໍາເປັນສໍາລັບການບັນລຸຄວາມເຫັນດີນໍາ - ເກີດຂຶ້ນລະຫວ່າງສອງສາມພາກສ່ວນທີ່ຮູ້ຈັກຕົນເອງແລ້ວ.

ແນ່ນອນ, ການມີລະບົບການອະນຸຍາດທີ່ມີຜູ້ເຂົ້າຮ່ວມທີ່ສາມາດກໍານົດໄດ້ເປີດປະຕູສໍາລັບການໂຈມຕີຂອງສັດຕູ; ຕົວຢ່າງ, ຜູ້ໂຈມຕີອາດຈະປອມຕົວ ຫຼືໃຫ້ສິນບົນບາງຜູ້ກວດສອບໄດ້ຢ່າງສຳເລັດຜົນ ແລະ ດ້ວຍເຫດນີ້ຈຶ່ງຖືວ່າການຄວບຄຸມສ່ວນໃຫຍ່. ຮ້າຍແຮງໄປກວ່ານັ້ນ, ລະບົບຫຼັກຖານສະແດງສິດອໍານາດ (PoA) ທີ່ຜູ້ກວດສອບບໍ່ໄດ້ຢູ່ໃນຕົວຈິງ (ແລະຖືກແຕ່ງຕັ້ງພຽງແຕ່) ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການໂຈມຕີລະບົບໃຫ້ສູນ (ຜູ້ໂຈມຕີພຽງແຕ່ສາມາດປະນີປະນອມຜູ້ກວດສອບ PoA ໂດຍຜ່ານລະບົບວິສະວະກໍາສັງຄົມແລະ hijack ລະບົບ, ສໍາລັບການຍົກຕົວຢ່າງ) .

ລະບົບສະເຕກທີ່ບໍ່ມີການອະນຸຍາດຈະເພີ່ມຄ່າໃຊ້ຈ່າຍໃນການສໍ້ລາດບັງຫຼວງຂອງລະບົບໂດຍການອະນຸຍາດໃຫ້ພາກສ່ວນທີ່ສົນໃຈ (ດ້ວຍຈໍານວນທຶນທີ່ເຫມາະສົມ) ເລີ່ມຕົ້ນການກວດສອບການດໍາເນີນງານຂ້າມຕ່ອງໂສ້. ຖ້າສົມທົບກັບໂປໂຕຄອນເປັນເອກະສັນກັນທີ່ຕ້ອງການ ≥ ⅔ ສ່ວນໃຫຍ່ເພື່ອຢືນຢັນການປິດກັ້ນສ່ວນຫົວ, ຄ່າໃຊ້ຈ່າຍໃນການສໍ້ລາດບັງຫຼວງຂອງລະບົບຈະເທົ່າກັບຈໍານວນຕໍາ່ສຸດທີ່ຕ້ອງການເພື່ອທໍາລາຍຜູ້ກວດສອບສ່ວນໃຫຍ່ໃນລະບົບ. ນອກຈາກນັ້ນ, ຜູ້ໃຊ້ມີການສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈຫນ້ອຍລົງ (ຜູ້ກວດສອບສາມາດຖືກຕັດໄດ້), ແລະຊຸດຕົວກວດສອບແບບເຄື່ອນໄຫວເພີ່ມຄວາມຫຍຸ້ງຍາກໃນການປະນີປະນອມຂໍ້ສະເພາະໂດຍຜ່ານເຕັກນິກເຊັ່ນວິສະວະກໍາສັງຄົມ.

ສິ່ງທີ່ອາດຈະຜິດພາດ? ຫຼາຍ, ຕົວຈິງແລ້ວ. ສໍາລັບການເລີ່ມຕົ້ນ, ຈໍານວນເງິນຂອງຫຼັກຊັບທີ່ຮັບປະກັນລະບົບຈະຕ້ອງເທົ່າກັບຫຼືສູງກວ່າມູນຄ່າທັງຫມົດຂອງຊັບສິນທີ່ມີຄວາມສ່ຽງຖ້າເຫດການຄວາມປອດໄພ (ການທໍາລາຍຄວາມປອດໄພຫຼືການດໍາລົງຊີວິດຂອງໂປໂຕຄອນ) ເກີດຂຶ້ນ. ຖ້າການປີ້ນກັບກັນແມ່ນຄວາມຈິງ ( ການຖືຫຸ້ນທັງຫມົດຮັບປະກັນລະບົບ < ມູນຄ່າລວມທີ່ມີຄວາມສ່ຽງ ), ເຖິງແມ່ນວ່າການຂົ່ມຂູ່ຂອງການຕັດໄມ້ຈະບໍ່ມີປະສິດທິພາບໃນການຮັບປະກັນຄວາມປອດໄພນັບຕັ້ງແຕ່ຜົນກໍາໄລຈາກການສໍ້ລາດບັງຫຼວງຂອງລະບົບຫຼາຍກວ່າຄ່າໃຊ້ຈ່າຍຂອງການທໍາລາຍມັນ.

ຍິ່ງໄປກວ່ານັ້ນ, ຄວາມພະຍາຍາມເພື່ອປະຕິບັດຊັບສິນຄວາມປອດໄພທີ່ໄດ້ກ່າວມາຂ້າງເທິງນີ້ອາດຈະຮຽກຮ້ອງໃຫ້ມີການກໍານົດຄວາມຕ້ອງການສະເຕກທີ່ສູງຂຶ້ນສໍາລັບຜູ້ກວດສອບທີ່ອາດຈະເປັນໄປໄດ້. ອັນນີ້ຊີ້ໃຫ້ເຫັນບັນຫາຂອງຄວາມບໍ່ມີປະສິດທິພາບຂອງທຶນຮອນ - ນັບຕັ້ງແຕ່ຄວາມປອດໄພແມ່ນອີງໃສ່ໂຫນດຜູ້ກວດສອບທີ່ເຮັດສອງຢ່າງ:

• ຝາກເງິນຈຳນວນຫຼວງຫຼາຍໄວ້ລ່ວງໜ້າ (ເປັນສະເຕກ) ກ່ອນທີ່ຈະເຂົ້າຮ່ວມໜ້າທີ່ກວດສອບ

• ການປະໄວ້ເງິນທີ່ບໍ່ໄດ້ໃຊ້ເປັນເວລາດົນນານ (ເພື່ອຄວາມປອດໄພ, ໂປໂຕຄອນ PoS ກໍານົດການຊັກຊ້າທີ່ຍາວນານໃນການຖອນເງິນ - ບາງອາທິດຫຼືຫຼາຍເດືອນ - ເພື່ອປ້ອງກັນກໍລະນີທີ່ຜູ້ກວດສອບໄດ້ກະທໍາຜິດແລະພະຍາຍາມຖອນເງິນທັນທີເພື່ອຫຼີກເວັ້ນການສູນເສຍເງິນ. )

  
  

ສິ່ງອື່ນທີ່ພວກເຮົາບໍ່ໄດ້ກ່າວເຖິງແມ່ນພາລະຂອງນັກພັດທະນາທີ່ປະຈຸບັນຕ້ອງໃຫ້ເຫດຜົນກ່ຽວກັບແຮງຈູງໃຈທາງເສດຖະກິດ crypto ເພື່ອຂັດຂວາງພຶດຕິກໍາທີ່ບໍ່ຊື່ສັດແລະການອອກແບບຫນ້າທີ່ຊັບຊ້ອນທີ່ສັບສົນສໍາລັບ token ຂອງໂປໂຕຄອນ. ນອກເຫນືອຈາກການເອົາໃຈໃສ່ຈາກກິດຈະກໍາທີ່ສໍາຄັນເຊັ່ນ: ການພັດທະນາຜະລິດຕະພັນແລະການມີສ່ວນຮ່ວມຂອງຊຸມຊົນ - ມັນຍັງເພີ່ມຄວາມຊັບຊ້ອນແລະສະຕິປັນຍາຂອງວົງຈອນການພັດທະນາສໍາລັບທີມງານທີ່ສ້າງໂຄງສ້າງພື້ນຖານຂອງການເຮັດວຽກຮ່ວມກັນ.

ການຢັ້ງຢືນໃນແງ່ດີ

"ການຢືນຢັນໃນແງ່ດີ" ແມ່ນການພິຈາລະນາບັນຫາຄວາມປອດໄພຂ້າມຕ່ອງໂສ້ອີກຢ່າງຫນຶ່ງ: ແທນທີ່ຈະຂໍໃຫ້ພາກສ່ວນຫຼືກຸ່ມທີ່ເຊື່ອຖືໄດ້ເພື່ອຢັ້ງຢືນສະຖານະຂ້າມຕ່ອງໂສ້, ພວກເຮົາອະນຸຍາດໃຫ້ ໃຜ ເຮັດມັນ. ສໍາຄັນ, ພາກສ່ວນທີ່ອ້າງສິດກ່ຽວກັບລັດຂ້າມຕ່ອງໂສ້ຕໍ່ກັບຄໍາຮ້ອງສະຫມັກການໂຕ້ຕອບຂອງລູກຄ້າ (ໂດຍປົກກະຕິເອີ້ນວ່າ "relayer") ບໍ່ຈໍາເປັນຕ້ອງໃຫ້ຫຼັກຖານສະແດງວ່າລັດທີ່ຢັ້ງຢືນຖືກຕ້ອງ. ນີ້ແມ່ນມາຈາກການສົມມຸດຕິຖານ "ໃນແງ່ດີ" ທີ່ relayers ຈະປະຕິບັດຢ່າງຊື່ສັດແລະພຽງແຕ່ເຮັດໃຫ້ການຮຽກຮ້ອງທີ່ຖືກຕ້ອງກ່ຽວກັບລັດຂ້າມຕ່ອງໂສ້.

ແຕ່ແນ່ນອນ, ພວກເຮົາຄາດຫວັງຢ່າງເຕັມທີ່ວ່າຫນຶ່ງຫຼືສອງ (ຫຼືຫຼາຍ) relayers ຈະໄປ rogue, ຊຶ່ງເປັນເຫດຜົນທີ່ວ່າລະບົບການຢັ້ງຢືນ optimistically ຮຽກຮ້ອງໃຫ້ relayers ປະກາດພັນທະບັດຂະຫນາດນ້ອຍກ່ອນທີ່ຈະສົ່ງຫຼັກຖານສະແດງຂອງລັດ. ການປະຕິບັດທຸລະກໍາທີ່ອ້າງອີງລັດຂ້າມຕ່ອງໂສ້ລາຍງານໂດຍ relayer - ຍັງຊັກຊ້າເພື່ອໃຫ້ຜູ້ໃດເບິ່ງລະບົບມີເວລາພຽງພໍທີ່ຈະໂຕ້ແຍ້ງການຮຽກຮ້ອງທີ່ບໍ່ຖືກຕ້ອງພາຍໃນໄລຍະເວລາ ທີ່ທ້າທາຍ . ຖ້າການຮຽກຮ້ອງຂອງຜູ້ສົ່ງຕໍ່ປະກົດວ່າບໍ່ຖືກຕ້ອງ, ພັນທະບັດທີ່ວາງໄວ້ຈະຖືກຕັດລົງ - ໂດຍບາງສ່ວນຂອງມັນຈະໄປຫາຜູ້ທ້າທາຍ.

ການກວດສອບໃນແງ່ດີເຮັດໃຫ້ບັນຫາທີ່ຕ້ອງເຊື່ອຖືຜູ້ຢັ້ງຢືນຈຳນວນຫຼາຍ ( k ຂອງ n ) ຫຼືສ່ວນໃຫຍ່ ( m ຂອງ n ) ໄປສູ່ບັນຫາການໄວ້ວາງໃຈຜູ້ກວດສອບຄົນໜຶ່ງ ( 1 ຂອງ n ) ເພື່ອປະຕິບັດຢ່າງຊື່ສັດ. ສໍາລັບໂປໂຕຄອນທີ່ຖືກຢືນຢັນໃນແງ່ດີເພື່ອຮັກສາຄວາມປອດໄພ, ມັນພຽງພໍທີ່ຈະມີນັກສະແດງຫນຶ່ງທີ່ມີຂໍ້ມູນຂອງລັດພຽງພໍທີ່ຈະປະຕິບັດການເຮັດທຸລະກໍາຄືນໃຫມ່ແລະສ້າງ ຫຼັກຖານສະແດງການສໍ້ໂກງ ເພື່ອທ້າທາຍການເຮັດທຸລະກໍາທີ່ມີການສໍ້ໂກງພາຍໃນໄລຍະເວລາຊັກຊ້າ (ເພາະສະນັ້ນ 1 of n ການສົມມຸດຕິຖານຄວາມປອດໄພ).

ນີ້ຊ່ວຍຫຼຸດຜ່ອນການ overhead ເນື່ອງຈາກວ່າລະບົບສາມາດເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງດ້ວຍ relayer ດຽວ (ເຖິງແມ່ນວ່າພວກເຮົາອາດຈະຕ້ອງການສອງຫຼືຫຼາຍກວ່ານັ້ນເພື່ອຮັບປະກັນຊີວິດ). ມັນຍັງຊ່ວຍຫຼຸດຈໍານວນສະເຕກທີ່ຕ້ອງການເພື່ອຄວາມປອດໄພ ແລະຊຸກຍູ້ໃຫ້ກໍານົດເວລາການຖອນສະເຕກໄວຂຶ້ນ (ຫຼັກຊັບຄ້ຳປະກັນສາມາດຖອນໄດ້ເມື່ອໄລຍະເວລາຊັກຊ້າ).

ຍິ່ງໄປກວ່ານັ້ນ, ອະນຸສັນຍາລະຫວ່າງປະເທດໂດຍອີງໃສ່ການກວດສອບໃນແງ່ດີໄດ້ຖືກອະທິບາຍວ່າເປັນ "ການສືບທອດຄວາມປອດໄພຂອງ blockchain ທີ່ຕິດພັນ"; ນີ້ແມ່ນອີງໃສ່ຄວາມຄິດທີ່ວ່າຖ້າ blockchain ພື້ນຖານແມ່ນມີຊີວິດຢູ່ແລະບໍ່ censoring ຫຼັກຖານການສໍ້ໂກງ, relayer malicious ບໍ່ສາມາດຫນີໄປດ້ວຍພຶດຕິກໍາທີ່ບໍ່ຊື່ສັດ. ຍິ່ງໄປກວ່ານັ້ນ, ການໂຈມຕີອະນຸສັນຍາຈະຮຽກຮ້ອງໃຫ້ມີການໂຈມຕີ blockchain ຕົວຂອງມັນເອງນັບຕັ້ງແຕ່ censoring ການເຮັດທຸລະກໍາສໍາລັບໄລຍະເວລາທີ່ຍາວນານຮຽກຮ້ອງໃຫ້ມີການຄວບຄຸມສ່ວນໃຫຍ່ຂອງ nodes - ແລະໂດຍການຂະຫຍາຍ, stake / mining power - ໃນເຄືອຂ່າຍ.

ແຕ່ເຖິງແມ່ນວ່າການກວດສອບໃນແງ່ດີກໍ່ມີຂໍ້ບົກຜ່ອງທີ່ເປັນເອກະລັກ. ສໍາລັບຕົວຢ່າງ, ການຊັກຊ້າໃນຂັ້ນຕອນສຸດທ້າຍແລະການປະຕິບັດການເຮັດທຸລະກໍາຂົວຫຼືຄໍາຮ້ອງຂໍຂໍ້ຄວາມຈະເພີ່ມຄວາມລ່າຊ້າແລະເຮັດໃຫ້ປະສົບການຂອງຜູ້ໃຊ້ໂດຍລວມຫຼຸດລົງ. ປະເພດຂອງຄວາມປອດໄພຂ້າມຕ່ອງໂສ້ນີ້ຍັງມີ "gotchas" ເລັກນ້ອຍທີ່ມີຜົນກະທົບດ້ານຄວາມປອດໄພເຊັ່ນ: ຄວາມເປັນໄປໄດ້ຂອງຝ່າຍທີ່ເປັນອັນຕະລາຍທີ່ທ້າທາຍການເຮັດທຸລະກໍາ ທີ່ຖືກຕ້ອງ ກັບ "ຄວາມໂສກເສົ້າ" relayers ທີ່ຊື່ສັດແລະປະຕິບັດການໂຈມຕີປະເພດ DDoS.

ເນື່ອງຈາກຫຼັກຖານການສໍ້ໂກງແມ່ນ (ສ່ວນຫຼາຍແມ່ນ) ໂຕ້ຕອບໂດຍທໍາມະຊາດ, ສິ່ງທ້າທາຍທີ່ບໍ່ຖືກຕ້ອງຈະເຮັດໃຫ້ຜູ້ສົ່ງຕໍ່ທີ່ຊື່ສັດເສຍຊັບພະຍາກອນ - ລວມທັງເງິນທຶນທີ່ໃຊ້ໃນຄ່າທໍານຽມອາຍແກັສສໍາລັບທຸລະກໍາໃນລະບົບຕ່ອງໂສ້. ດັ່ງນັ້ນ, ຜູ້ສົ່ງຕໍ່ທີ່ຊື່ສັດອາດຈະສູນເສຍແຮງຈູງໃຈໃນການຖ່າຍທອດຂໍ້ມູນຂ້າມຕ່ອງໂສ້, ເຊິ່ງອາດຈະເຮັດໃຫ້ໂອກາດສໍາລັບຜູ້ສົ່ງຕໍ່ ທີ່ບໍ່ຊື່ສັດ ໃນການຖ່າຍທອດຂໍ້ມູນຂ້າມຕ່ອງໂສ້. ການຮຽກຮ້ອງໃຫ້ຜູ້ທ້າທາຍໃນການປະກາດເງິນຝາກຂັ້ນຕ່ໍາສາມາດຂັດຂວາງຄວາມໂສກເສົ້າ, ແຕ່ເງິນຝາກຕ່ໍາສຸດທີ່ສູງສາມາດຂັດຂວາງຜູ້ເບິ່ງ ທີ່ຊື່ສັດ (ຜູ້ທີ່ຂາດທຶນ) ຈາກການທ້າທາຍການອັບເດດຂອງລັດທີ່ບໍ່ຖືກຕ້ອງ.

ບາງໂປໂຕຄອນເຮັດວຽກກ່ຽວກັບບັນຫານີ້ໂດຍການຈໍາກັດສິ່ງທ້າທາຍຕໍ່ຊຸດຜູ້ເບິ່ງທີ່ໄດ້ຮັບອະນຸຍາດ, ແຕ່ນັ້ນເຮັດໃຫ້ພວກເຮົາກັບຄືນສູ່ບັນຫາຕົ້ນສະບັບຂອງການມີຜູ້ເຂົ້າຮ່ວມ (ທີ່ເຊື່ອຖືໄດ້) ຊຸດນ້ອຍເພື່ອຮັບປະກັນລະບົບ. ວິທີການນີ້ຍັງສາມາດສ້າງຜົນສະທ້ອນທີ່ບໍ່ໄດ້ຕັ້ງໃຈຫຼາຍ, ເຊັ່ນ: ການຫຼຸດຜ່ອນອຸປະສັກຕໍ່ການສົມຮູ້ຮ່ວມຄິດລະຫວ່າງ nodes watcher ແລະການປັບປຸງໂອກາດຂອງຜູ້ໂຈມຕີທີ່ຈະທໍາລາຍສ່ວນໃຫຍ່ຂອງ nodes ທີ່ເບິ່ງລະບົບ.

ການກວດສອບການເຂົ້າລະຫັດລັບ

ວິທີການສຸດທ້າຍໃນການຮັບປະກັນອະນຸສັນຍາການເຮັດວຽກຮ່ວມກັນຂ້າມຕ່ອງໂສ້ທີ່ພວກເຮົາຈະພິຈາລະນາແມ່ນມາຈາກຂອບເຂດຂອງຫຼັກຖານການເຂົ້າລະຫັດລັບ. ແນວຄວາມຄິດແມ່ນງ່າຍດາຍ: ແທນທີ່ຈະໄວ້ວາງໃຈປະຊາຊົນເພື່ອກວດສອບລັດຂ້າມຕ່ອງໂສ້ (ເຊິ່ງພາກສ່ວນທີ່ຜ່ານມາໄດ້ສະແດງໃຫ້ເຫັນວ່າເປັນອັນຕະລາຍໃນບາງກໍລະນີ), ພວກເຮົາແທນທີ່ຈະໃຊ້ກົນໄກການກວດສອບການເຂົ້າລະຫັດລັບ - ຫຼຸດຜ່ອນການສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈໃຫ້ຕໍ່າສຸດ.

ທີ່ນີ້, ນັກສະແດງຫນຶ່ງຫຼືຫຼາຍກວ່ານັ້ນສ້າງ SNARK (Succinct Non-Interactive Argument of Knowledge) ຫຼັກຖານສະແດງສະຖານະຂອງລະບົບຕ່ອງໂສ້ (ທີ່ຖືກຕ້ອງ) ສໍາລັບການນໍາໃຊ້ພາຍໃນຄໍາຮ້ອງສະຫມັກທີ່ມີການໂຕ້ຕອບ. ຫຼັກຖານເຫຼົ່ານີ້ສາມາດ ກວດສອບໄດ້ : ພວກເຮົາສາມາດເອົາຫຼັກຖານການເຂົ້າລະຫັດລັບຂອງສະຖານະຂ້າມຕ່ອງໂສ້, ເຊັ່ນວ່າອັນຫນຶ່ງທີ່ມາຈາກຫົວຂໍ້ບລັອກ, ແລະຢືນຢັນຄວາມຖືກຕ້ອງຂອງມັນ. ພວກມັນຍັງ ບໍ່ມີການໂຕ້ຕອບ : ຫຼັກຖານທີ່ສ້າງຂຶ້ນໂດຍຝ່າຍດຽວສາມາດກວດສອບໄດ້ໂດຍ ພາກ ສ່ວນຕ່າງໆໂດຍບໍ່ມີໃຜຕິດຕໍ່ສື່ສານ (ບໍ່ຄືກັບຫຼັກຖານສະແດງການສໍ້ໂກງແບບໂຕ້ຕອບ). ໂປຣໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນທີ່ອອກແບບມາດ້ວຍວິທີນີ້ມັກຈະມີການສົມມຸດຕິຖານຄວາມເຊື່ອຖືຕໍ່າສຸດ, ຍ້ອນວ່າລະບົບຫຼັກຖານພື້ນຖານແມ່ນດີ (ເຊັ່ນ, ສັດຕູບໍ່ສາມາດສ້າງຫຼັກຖານທີ່ຖືກຕ້ອງສໍາລັບການຮຽກຮ້ອງທີ່ບໍ່ຖືກຕ້ອງ, ຍົກເວັ້ນຄວາມເປັນໄປໄດ້ທີ່ລະເລີຍ).

ໂປໂຕຄອນດັ່ງກ່າວຍັງແຕກຕ່າງຈາກລະບົບການຢັ້ງຢືນພາຍນອກ, ໂດຍສະເພາະບ່ອນທີ່ຫຼັກຖານການເຂົ້າລະຫັດລັບກວດສອບວ່າແຕ່ລະຕັນແມ່ນຖືກຕ້ອງຕາມອະນຸສັນຍາຂອງລະບົບຕ່ອງໂສ້. ດັ່ງນັ້ນ, ສັດຕູຈະຕ້ອງຄວບຄຸມສ່ວນໃຫຍ່ຂອງຊຸດຜູ້ກວດສອບລະບົບຕ່ອງໂສ້ແຫຼ່ງທີ່ມາ - ຕ້ອງການເພື່ອເຮັດສໍາເລັດການບລັອກທີ່ບໍ່ຖືກຕ້ອງ - ເພື່ອທໍາລາຍໂປຣໂຕຄອນການໂຕ້ຕອບກັນໂດຍໃຊ້ຫຼັກຖານລະຫັດລັບຂອງສະຖານະຂ້າມຕ່ອງໂສ້.

ມັນຍັງເປັນເລື່ອງງ່າຍທີ່ຈະເບິ່ງວ່າວິທີການນີ້ລົບລ້າງບາງຂໍ້ບົກຜ່ອງທີ່ກ່ຽວຂ້ອງກັບກົນໄກຄວາມປອດໄພຂ້າມຕ່ອງໂສ້ບາງອັນທີ່ໄດ້ສົນທະນາກ່ອນຫນ້ານີ້:

1. ການຂາດປະສິດທິພາບຂອງນະຄອນຫຼວງ : ການນໍາໃຊ້ zkSNARKs ເພື່ອກວດສອບລັດຂ້າມຕ່ອງໂສ້ການລົບລ້າງຄວາມຈໍາເປັນສໍາລັບກົນໄກການ staking / ພັນທະບັດແລະຄວາມບໍ່ມີປະສິດທິພາບທີ່ກ່ຽວຂ້ອງຂອງ tokens ກັບໄລຍະເວລາ lockup. ເຊັ່ນດຽວກັນ, relayers ບໍ່ຈໍາເປັນຕ້ອງປະກາດພັນທະບັດ (ບໍ່ເຫມືອນກັບການກວດສອບໃນແງ່ດີ) ກ່ອນທີ່ຈະເຮັດການຮຽກຮ້ອງກ່ຽວກັບການເຮັດທຸລະກໍາຂ້າມຕ່ອງໂສ້ນັບຕັ້ງແຕ່ຫຼັກຖານທີ່ມາພ້ອມ ກັບ ການຢືນຢັນການຮຽກຮ້ອງ.
2. ເວລາ latency ຕໍ່າ : ໂດຍບໍ່ມີການຈໍາເປັນຕ້ອງປະຕິບັດໄລຍະເວລາຊັກຊ້າ - ເພື່ອເປີດໃຊ້ການພິສູດການສໍ້ໂກງທີ່ທັນເວລາ - ໂປໂຕຄອນການໂຕ້ຕອບສາມາດປະຕິບັດຂໍ້ຄວາມຂ້າມຕ່ອງໂສ້ຫຼືການເຊື່ອມສານເມື່ອຫຼັກຖານ SNARK ຮັບປະກັນມັນຖືກກວດສອບ. ທີ່ເວົ້າວ່າ, ການຜະລິດຫຼັກຖານສະແດງໂດຍທົ່ວໄປແມ່ນໃຊ້ຄອມພິວເຕີ້ຫຼາຍ, ດັ່ງນັ້ນລະບົບການຢັ້ງຢືນພາຍນອກອາດຈະມີປະສິດທິພາບຫຼາຍເມື່ອທຽບໃສ່ກັບໂປໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນທີ່ອີງໃສ່ SNARK.

ໃນເວລາທີ່ການປະເມີນຄວາມປອດໄພຂອງການແກ້ໄຂການໂຕ້ຕອບ "ການເຂົ້າລະຫັດລັບທີ່ຖືກຢືນຢັນ", ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເບິ່ງຢ່າງໃກ້ຊິດວ່າຂໍ້ມູນໃດໆກ່ຽວກັບລັດຂ້າມຕ່ອງໂສ້ທີ່ຖືກພິສູດແລະຢືນຢັນ. ຫຼັກຖານຄວາມຮູ້ທີ່ບໍ່ມີຄວາມຮູ້ໄດ້ກາຍເປັນຄໍາເວົ້າທີ່ຫຼາຍໂປໂຕຄອນໄດ້ຕິດຢູ່ໃນຄໍາສັ່ງທີ່ຈະສັບສົນກັບສົມມຸດຕິຖານຄວາມເຊື່ອຫມັ້ນທີ່ແທ້ຈິງທີ່ຢູ່ພາຍໃຕ້ໂປໂຕຄອນຂອງພວກເຂົາ.

ສໍາລັບຕົວຢ່າງ, ເນື່ອງຈາກວ່າການກວດສອບລາຍເຊັນທັງຫມົດໃນທົ່ວຊຸດ Ethereum validators ( ຫຼາຍກວ່າ 925,000 validators ຕໍ່ຕົວເລກປະຈຸບັນ ) ໃນວົງຈອນ zkSNARK ສາມາດມີລາຄາແພງ, ບາງໂປໂຕຄອນໄດ້ນໍາໃຊ້ປະຫວັດສາດວິທີການອື່ນເພື່ອການພິສູດຂອງລັດ Ethereum. ຕົວຢ່າງຫນຶ່ງແມ່ນຂົວ " Ethereum to X " (ບ່ອນທີ່ X ສາມາດເປັນ blockchain ໃດ) ທີ່ສ້າງຫຼັກຖານສະແດງວ່າຫົວບລັອກໄດ້ຖືກລົງນາມໂດຍຄະນະກໍາມະການ Sync ຂອງ Ethereum ສ່ວນໃຫຍ່ (ທີ່ພວກເຮົາແນະນໍາກ່ອນຫນ້ານີ້).

ນີ້ແມ່ນວິທີການທີ່ເປັນໄປໄດ້ຫຼາຍກວ່າ (ເມື່ອປຽບທຽບກັບການກວດສອບລະຫັດສາທາລະນະຂອງຕົວກວດສອບຫຼາຍພັນຄົນທີ່ຢືນຢັນເປັນບລັອກ). ແຕ່ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ກ່ອນຫນ້ານີ້, ຜູ້ກວດສອບຄວາມຖືກຕ້ອງໃນຄະນະກໍາມະການ Sync ບໍ່ໄດ້ຖືກຕັດສໍາລັບການລົງນາມໃນສ່ວນຫົວບລັອກທີ່ບໍ່ຖືກຕ້ອງ - ເຊິ່ງເຮັດໃຫ້ຄວາມເປັນໄປໄດ້ທີ່ບໍ່ມີການລະເລີຍທີ່ສະມາຊິກຄະນະກໍາມະການ Sync ສ່ວນໃຫຍ່ສາມາດສົມຮູ້ຮ່ວມຄິດຫຼືຖືກສິນບົນເຂົ້າໄປໃນການຫລອກລວງລູກຄ້າແສງສະຫວ່າງແລະເປັນອັນຕະລາຍຕໍ່ຄວາມປອດໄພຂອງຂົວ. /messaging protocols ອີງໃສ່ຄະນະກໍາມະການ Sync ສໍາລັບຂໍ້ມູນ.

ຍິ່ງໄປກວ່ານັ້ນ, ດັ່ງທີ່ໄດ້ອະທິບາຍໄວ້ໃນ ບົດຄວາມຕົ້ນສະບັບທີ່ແນະນໍາຄະນະກໍາມະການຂອງລັດ Lagrange , ພວກເຮົາໄດ້ອະທິບາຍວ່າ, ໃນໂລກທີ່ເຫມາະສົມທີ່ຄະນະກໍາມະການ Sync ທີ່ເປັນອັນຕະລາຍຕ້ອງຮັບຜິດຊອບຕໍ່ການຂູດຮີດ, ຄວາມປອດໄພທາງດ້ານເສດຖະກິດຈະຖືກຈໍາກັດໃນຈໍານວນສູງສຸດທີ່ສາມາດຕັດໄດ້. ນີ້ແມ່ນບາງສ່ວນທີ່ຍົກອອກມາຈາກໂພສນັ້ນສຳລັບບໍລິບົດ:

ຄວາມປອດໄພຂອງຂົວລູກຄ້າແສງສະຫວ່າງ, ຂົວ ZK ແລະຫຼັກຖານສະແດງຄະນະກໍາມະການຊິງຄ໌ແມ່ນທັງຫມົດໂດຍອີງໃສ່ການຢັ້ງຢືນລາຍເຊັນຈາກຄະນະກໍາມະການ sync ລູກຄ້າແສງສະຫວ່າງ Ethereum. ເນື່ອງຈາກຂະຫນາດຂອງຄະນະກໍາມະການ sync ໄດ້ຖືກສ້ອມແຊມ, ຄວາມປອດໄພທາງດ້ານເສດຖະກິດທີ່ສະຫນັບສະຫນູນມັນຍັງຖືກປົກຄຸມດ້ວຍປ່ອງຢ້ຽມ 27 ຊົ່ວໂມງ. ເມື່ອ slashing ໄດ້ຖືກປະຕິບັດໃນທີ່ສຸດສໍາລັບຄະນະກໍາມະການ sync Ethereum, ຄວາມປອດໄພທາງດ້ານເສດຖະກິດຈະຖືກຜູກມັດດັ່ງຕໍ່ໄປນີ້:

• ຄວາມປອດໄພທາງດ້ານເສດຖະກິດຂອງຄະນະກໍາມະການ Sync = 512 nodes * 32 Eth * $1650 USD/ETH = $27,033,600
• ເກນເພື່ອປະນີປະນອມຄະນະກໍາມະການຊິງຄ໌ = $27,033,600 * 2/3 = $18,022,400

ໃນຂະນະທີ່ຂົວລູກຄ້າແສງສະຫວ່າງແລະຂົວລູກຄ້າແສງສະຫວ່າງ ZK ຖືກຄິດວ່າເປັນມາດຕະຖານຄໍາສໍາລັບການເຮັດວຽກຮ່ວມກັນລະຫວ່າງລະບົບຕ່ອງໂສ້, ຈໍານວນຊັບສິນທີ່ພວກເຂົາສາມາດຮັບປະກັນກັບຄະນະກໍາມະການ sync randomized ແມ່ນຈໍາກັດຢ່າງຮຸນແຮງ. ດັ່ງທີ່ສະແດງໃຫ້ເຫັນກ່ອນຫນ້ານີ້, ຈໍານວນຫຼັກຊັບທີ່ colluding nodes ຈະຕ້ອງເຜົາໄຫມ້ເພື່ອພ້ອມກັນປະນີປະນອມລູກຄ້າໄຟ Ethereum ທັງຫມົດແລະຂົວລູກຄ້າແສງສະຫວ່າງ ZK ແມ່ນກວມເອົາທີ່ $ 18m.

ພິຈາລະນາສະຖານະການ, ບ່ອນທີ່ຜົນລວມຂອງມູນຄ່າຂອງຊັບສິນທັງຫມົດທີ່ຮັບປະກັນໂດຍລູກຄ້າແສງສະຫວ່າງທັງຫມົດແລະຂົວລູກຄ້າແສງສະຫວ່າງ ZK ແມ່ນຈໍານວນ k. ເມື່ອ k < 18 ລ້ານໂດລາ, ຊັບສິນທັງຫມົດທີ່ຮັບປະກັນໃນທົ່ວຂົວແມ່ນປອດໄພ, ເນື່ອງຈາກວ່າການໂຈມຕີແມ່ນບໍ່ເປັນໄປໄດ້ທາງດ້ານເສດຖະກິດ. ເມື່ອ k ເຕີບໂຕຂຶ້ນເຊັ່ນ k > $ 27m, ມັນຈະກາຍເປັນກໍາໄລສໍາລັບກຸ່ມຂອງນັກສະແດງທີ່ບໍ່ດີໃນຄະນະກໍາມະການ sync ເພື່ອຢັ້ງຢືນກັບຕັນທີ່ເປັນອັນຕະລາຍເພື່ອປະນີປະນອມຊັບສິນທີ່ຮັບປະກັນ.

ພວກເຮົາຊຸກຍູ້ໃຫ້ອ່ານບົດຄວາມທັງຫມົດ, ໂດຍສະເພາະພາກສ່ວນກ່ຽວກັບຂໍ້ຈໍາກັດຂອງ ຂົວລູກຄ້າແສງສະຫວ່າງ ຂອງ Ethereum, ສໍາລັບສະພາບການເພີ່ມເຕີມກ່ຽວກັບບັນຫາກ່ຽວກັບການອີງໃສ່ຄະນະກໍາມະການ sync randomized ເພື່ອເອົາຫຼັກຖານສະແດງຂອງລັດຂ້າມຕ່ອງໂສ້. ພວກເຮົາຍັງແນະນໍາໃຫ້ທ່ານປະຕິບັດຕາມຄວາມພະຍາຍາມຂອງ Polyhedra Network ເພື່ອ ພິສູດຄວາມເຫັນດີເຫັນພ້ອມຂອງ Ethereum PoS ຢ່າງເຕັມທີ່ໃນວົງຈອນ ZK .

ຄະນະກໍາມະການຂອງລັດ Lagrange: ແບ່ງປັນຄວາມປອດໄພເປັນການບໍລິການສໍາລັບໂປໂຕຄອນການສື່ສານຂ້າມຕ່ອງໂສ້

ດ້ວຍສ່ວນສໍາຄັນຂອງການແນະນໍາຂອງບົດຄວາມນີ້ກ່ຽວກັບຄວາມປອດໄພຮ່ວມກັນ, ມັນເປັນພຽງແຕ່ເຫມາະສົມທີ່ພວກເຮົາແນະນໍາການແກ້ໄຂຄວາມປອດໄພຮ່ວມກັນທີ່ພວກເຮົາໄດ້ເຮັດວຽກຢູ່ Lagrange Labs: Lagrange State Committees . ໃນພາກນີ້, ພວກເຮົາຈະຄົ້ນຫາການເຮັດວຽກພາຍໃນຂອງເຄືອຂ່າຍຄະນະກໍາມະການລັດ Lagrange ແລະເຂົ້າໃຈການເຊື່ອມຕໍ່ຂອງມັນກັບ stack ZK Big Data ຂອງ Lagrange ແລະເປົ້າຫມາຍຂອງການກໍ່ສ້າງເຄື່ອງມືເພື່ອໃຫ້ສາມາດເຂົ້າເຖິງລັດທີ່ປອດໄພແລະ ສະແດງອອກ ໃນລະບົບຕ່ອງໂສ້ແລະລະຫວ່າງຕ່ອງໂສ້.

ຄະນະກໍາມະການລັດ Lagrange ແມ່ນຫຍັງ?

ເຄືອຂ່າຍຄະນະກໍາມະລັດ Lagrange (LSC) ແມ່ນໂປໂຕຄອນລູກຄ້າແສງສະຫວ່າງ ZK ທີ່ງ່າຍດາຍແລະມີປະສິດທິພາບສໍາລັບການມ້ວນໃນແງ່ດີ (ORUs) ທີ່ຕັ້ງຢູ່ໃນ Ethereum (ຕົວຢ່າງ, Optimism, Arbitrum, Base, ແລະ Mantle). LSCs ມີແນວຄວາມຄິດຄ້າຍຄືກັນກັບຄະນະກໍາມະການ Sync ຂອງ Ethereum ແລະສະຫນັບສະຫນູນຄໍາຮ້ອງສະຫມັກທີ່ອີງໃສ່ລູກຄ້າທີ່ເບົາບາງເຊັ່ນ: ຂົວແລະຊັ້ນຂໍ້ຄວາມ interchain - ທີ່ຕ້ອງການໃຊ້ສະຖານະຂອງການລວບລວມຂໍ້ມູນໃນແງ່ດີໂດຍບໍ່ມີການສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈຫຼາຍເກີນໄປ.

ຄະນະກໍາມະການຂອງລັດ Lagrange ແມ່ນກຸ່ມລູກຄ້າທີ່ເອົາຄືນມູນຄ່າ 32 ETH ຂອງຫຼັກຊັບໃນ Ethereum ຜ່ານ EigenLayer. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ແມ່ນ AVS ຫຼື ບໍລິການທີ່ມີການກວດສອບຢ່າງຈິງຈັງ . ຄະນະກໍາມະການຂອງລັດ Lagrange ແຕ່ລະຄົນຢືນຢັນເຖິງຄວາມສຸດທ້າຍຂອງຕັນສໍາລັບການລວບລວມຂໍ້ມູນໃນແງ່ດີທີ່ກໍານົດເມື່ອຊຸດທຸລະກໍາທີ່ກ່ຽວຂ້ອງຖືກສະຫຼຸບໃນຊັ້ນຂໍ້ມູນ (DA). ຫຼັງຈາກນັ້ນ, ການຢັ້ງຢືນເຫຼົ່ານີ້ຖືກໃຊ້ເພື່ອສ້າງຫຼັກຖານຂອງລັດ, ເຊິ່ງຄໍາຮ້ອງສະຫມັກສາມາດປະຕິບັດເປັນແຫຼ່ງຂອງຄວາມຈິງສໍາລັບສະຖານະຂອງການລວບລວມໃນແງ່ດີໂດຍສະເພາະ.

ໃນຂະນະທີ່ຄະນະກໍາມະການຊິງຄ໌ຂອງ Ethereum ຖືກຫຸ້ມຢູ່ທີ່ 512 nodes, ແຕ່ລະເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ສະຫນັບສະຫນູນຊຸດຂອງ nodes ທີ່ບໍ່ມີຂອບເຂດ. ນີ້ຮັບປະກັນວ່າຄວາມຫມັ້ນຄົງທາງດ້ານເສດຖະກິດບໍ່ຖືກປິດບັງປອມແລະຈໍານວນຂອງຂໍ້ຢືນຢັນເຖິງສະຖານະຂອງການມ້ວນໃນແງ່ດີສາມາດຂະຫຍາຍໄດ້, ດັ່ງນັ້ນການເພີ່ມຄວາມຫມັ້ນຄົງທາງດ້ານເສດຖະກິດຕາມຫຼັກຖານຂອງລັດ Lagrange.

ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ເຮັດວຽກແນວໃດ?

ສອງອົງປະກອບຫຼັກຂອງພິທີການຄະນະກໍາມະການຂອງລັດ Lagrange ແມ່ນ sequencer ແລະ nodes ລູກຄ້າ ("ຂໍ້ລູກຄ້າ" ແມ່ນຊື່ອື່ນສໍາລັບຜູ້ກວດສອບທີ່ລົງທະບຽນກັບຄະນະກໍາມະການລັດ Lagrange). ລໍາດັບແມ່ນຫນ່ວຍງານກາງທີ່ຮັບຜິດຊອບສໍາລັບການປະສານງານການຢັ້ງຢືນໃນເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ແລະຮັບໃຊ້ການຢັ້ງຢືນກັບຜູ້ພິສູດທີ່ຜະລິດຫຼັກຖານຂອງລັດ. The sequencer node ຕົວຈິງແລ້ວແມ່ນການປະສົມປະສານຂອງສາມໂມດູນທີ່ມີຫນ້າທີ່ແຕກຕ່າງກັນ: Sequencer , Consensus , ແລະ Governance .

ໃນຊ່ວງເວລາສະເພາະ, ໂມດູນ Sequencer ຮ້ອງຂໍການຢັ້ງຢືນຈາກໂຫມດລູກຄ້າໄປຫາ rollup blocks ທີ່ເປັນຜົນມາຈາກການປະຕິບັດການເຮັດທຸລະກໍາທີ່ຂຽນໄວ້ໃນຊັ້ນ DA. ແທນ​ທີ່​ຈະ​ປະ​ຕິ​ບັດ​ການ​ປົກ​ກະ​ຕິ​ນີ້​ສໍາ​ລັບ​ທຸກ​ຕັນ​ມ້ວນ​ໃນ​ແງ່​ດີ​, ພວກ​ເຮົາ​ຂ້າງ​ລຸ່ມ​ນີ້​ແມ່ນ​ການ​ວິ​ເຄາະ​ໂດຍ​ຫຍໍ້​ຂອງ​ແຕ່​ລະ​ອົງ​ປະ​ກອບ​ໃນ​ຂໍ້​ຄວາມ block ໄດ້​:

(1). Block_header : ສ່ວນຫົວຂອງບຼັອກການລວບລວມຂໍ້ມູນໃນແງ່ດີສຸດທ້າຍ (ORU). "Finality" ໃນທີ່ນີ້ຫມາຍເຖິງບລັອກທີ່ໄດ້ມາຈາກການລວບລວມຂໍ້ມູນຈາກຂໍ້ມູນການເຮັດທຸລະກໍາທີ່ສໍາເລັດໃນຊັ້ນ DA ທີ່ກໍານົດໄວ້. ຕົວຢ່າງ, ສຸດທ້າຍແມ່ນຖືກກໍານົດໂດຍ ຫົວ L2 ທີ່ປອດໄພ ສໍາລັບການລວບລວມ stack Optimism / OP ແລະຕັນ L2 ທີ່ມີ Ethereum ສຸດທ້າຍ ສໍາລັບ Arbitrum ແລະ Arbitrum Orbit chains. (ຮຽນ​ຮູ້​ເພີ່ມ​ເຕີມ​ກ່ຽວ​ກັບ​ການ​ສະ​ບັບ​ສຸດ​ທ້າຍ​ໃນ ​ບົດ​ຄວາມ​ນີ້ .)

(2). current_committee : ຄໍາຫມັ້ນສັນຍາການເຂົ້າລະຫັດລັບກັບຊຸດຂອງກະແຈສາທາລະນະທີ່ກ່ຽວຂ້ອງກັບ nodes ລູກຄ້າອະນຸຍາດໃຫ້ເຊັນບລັອກ b. ໂນດລູກຄ້າຄາດວ່າຈະສ້າງຕົ້ນໄມ້ Merkle, ດ້ວຍໃບທີ່ເປັນຕົວແທນຂອງກະແຈສາທາລະນະຂອງສະມາຊິກຄະນະກໍາມະການທີ່ມີການເຄື່ອນໄຫວທັງຫມົດ, ແລະເຊັນຊື່ຮາກຂອງຕົ້ນໄມ້ Merkle ດ້ວຍກະແຈ BLS12-381 ຂອງມັນ.

(3). next_committee : ຄໍາຫມັ້ນສັນຍາການເຂົ້າລະຫັດລັບກັບຊຸດຂອງກະແຈສາທາລະນະທີ່ກ່ຽວຂ້ອງກັບ nodes ອະນຸຍາດໃຫ້ເຊັນບລັອກຕໍ່ໄປ (b+1). ໂນດທີ່ຕ້ອງການທີ່ຈະອອກຈາກຄະນະກໍາມະການຂອງລັດຕ້ອງສົ່ງທຸລະກໍາໃນຕອນທ້າຍຂອງໄລຍະເວລາການຢັ້ງຢືນໃຫ້ກັບສັນຍາ Lagrange Service ໃນ Ethereum ທີ່ຈັດການການລົງທະບຽນແລະການຍົກເລີກການລົງທະບຽນຂອງຜູ້ປະກອບການໃນຄະນະກໍາມະການຂອງລັດ AVS.

ໃນຕອນທ້າຍຂອງແຕ່ລະໄລຍະການຢັ້ງຢືນ, ຊຸດຂອງຄະນະກໍາມະອາດຈະມີການປ່ຽນແປງຖ້າຫາກວ່າຜູ້ປະກອບການຮ້ອງຂໍໃຫ້ອອກຈາກຫຼືເຂົ້າຮ່ວມກ່ອນທີ່ໄລຍະເວລາການຢັ້ງຢືນຕໍ່ໄປຈະເລີ່ມຕົ້ນ. ໂນດລູກຄ້າຄາດວ່າຈະສ້າງ ຕົ້ນໄມ້ Merkle ຂອງຄະ next_committee ໂດຍການດຶງເອົາຊຸດຂອງໂຫນດປະຈຸບັນທີ່ລົງທະບຽນກັບແຕ່ລະຄະນະກໍາມະການຈາກສັນຍາການບໍລິການ Lagrange.

ELI5: ຫຼັກຖານຂອງລັດແມ່ນຫຍັງ?

ຫຼັກຖານສະແດງຂອງລັດ ແມ່ນຫຼັກຖານສະແດງການເຂົ້າລະຫັດລັບຂອງສະຖານະຂອງ blockchain: ຫຼັກຖານສະແດງຂອງຫົວບລັອກຈາກລະບົບຕ່ອງໂສ້ແຫຼ່ງ (ຕ່ອງໂສ້ A), ເຊິ່ງສາມາດຖືກນໍາໃຊ້ເພື່ອພິສູດເຖິງລະບົບຕ່ອງໂສ້ປາຍທາງການມີຢູ່ຂອງລັດໃນລະບົບຕ່ອງໂສ້ແຫຼ່ງ, ເຊັ່ນ: ການເຮັດທຸລະກໍາໂດຍສະເພາະ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ຫຼັກຖານສະແດງຂອງລັດສະແດງເຖິງຫຼັກຖານຂອງສະຖານະຂອງລະບົບຕ່ອງໂສ້ແຫຼ່ງທີ່ລະດັບຄວາມສູງທີ່ກໍານົດໄວ້.

ເພື່ອສະແດງໃຫ້ເຫັນການນໍາໃຊ້ຕົວຢ່າງທີ່ຜ່ານມາ: ຫົວຕັນຈາກລະບົບຕ່ອງໂສ້ແຫຼ່ງ (ຕ່ອງໂສ້ A), ເຊິ່ງຄໍາຮ້ອງສະຫມັກຂອງ Bob ໃນລະບົບຕ່ອງໂສ້ປາຍທາງ (ຕ່ອງໂສ້ B) ໃຊ້ເພື່ອກວດສອບການມີຢູ່ຂອງທຸລະກໍາຂົວ Alice, ເປັນຫຼັກຖານຂອງລັດ. ມັນສະແດງເຖິງການສະຫຼຸບສັງລວມການດັດແປງສະພາບຂອງລະບົບຕ່ອງໂສ້ແຫຼ່ງລະຫວ່າງບລັອກກ່ອນຫນ້າແລະບລັອກປະຈຸບັນ. ຖ້າຫຼັກຖານ Merkle ຂອງ Alice ຢືນຢັນຕໍ່ກັບການເຮັດທຸລະກໍາຂອງຮາກຕົ້ນໄມ້ທີ່ເກັບໄວ້ໃນສ່ວນຫົວຂອງລະບົບຕ່ອງໂສ້ A, Bob ສາມາດອະນຸມັດການເຮັດທຸລະກໍາຂົວຕໍ່ລະບົບຕ່ອງໂສ້ B (ລະບົບຕ່ອງໂສ້ປາຍທາງ) ດ້ວຍຄວາມໝັ້ນໃຈຍ້ອນວ່າຫຼັກຖານຂອງລັດຢັ້ງຢືນການປະຕິບັດຄໍາຮ້ອງຂໍຂໍ້ຄວາມຂອງ Alice ໃນລະບົບຕ່ອງໂສ້ຕົ້ນກໍາເນີດ.

ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ຖືກອອກແບບມາເພື່ອສ້າງຫຼັກຖານຂອງລັດສໍາລັບການລວບລວມຂໍ້ມູນໃນແງ່ດີທີ່ຮັບປະກັນໂດຍ Ethereum. ຫຼັກຖານຂອງລັດແມ່ນສ້າງຂຶ້ນໂດຍການລວບລວມລາຍເຊັນ BL12–381 ໃນ tuple ທີ່ອະທິບາຍໄວ້ກ່ອນຫນ້ານີ້ ( block_header , prev_committee , ແລະ next_committee ) ຈາກຢ່າງຫນ້ອຍສອງສ່ວນສາມຂອງ nodes ໃນຄະນະກໍາມະການຂອງລັດ. ຫຼັງຈາກນັ້ນ, ຫຼັກຖານຂອງລັດແມ່ນຜະລິດໂດຍວົງຈອນ SNARK ໂດຍອີງໃສ່ນ້ໍາຫນັກລວມຂອງລາຍເຊັນທີ່ຢືນຢັນກັບຫົວບລັອກທີ່ໃຫ້.

ວິທີການຮຽກຮ້ອງໃຫ້ຜູ້ຢັ້ງຢືນໃຫ້ຄໍາຫມັ້ນສັນຍາກັບຄະນະກໍາມະການຂອງລັດໃນປະຈຸບັນແລະຕໍ່ໄປແມ່ນຄ້າຍຄືກັນກັບ Ethereum Sync Committee protocol ແລະບັນລຸເປົ້າຫມາຍທີ່ຄ້າຍຄືກັນ: ເຮັດໃຫ້ລູກຄ້າເບົາສາມາດກວດສອບຄວາມຖືກຕ້ອງຂອງສ່ວນຫົວຂອງ block rollup ໃນແງ່ດີຢ່າງມີປະສິດທິພາບແລະປອດໄພ. ຫຼັກຖານຂອງລັດແຕ່ລະແມ່ນເຊື່ອມຕໍ່ cryptographically ໂດຍຊຸດຂອງຄໍາຫມັ້ນສັນຍາ next_committee ທີ່ຊີ້ບອກວ່າ nodes ຄວນເຊັນໃນ block ຕໍ່ໄປ. ດັ່ງນັ້ນ, ມັນພຽງພໍທີ່ຈະກວດສອບຫຼັກຖານ SNARK ທີ່ພິສູດຄຸນສົມບັດ recursive ດັ່ງຕໍ່ໄປນີ້ໃນ block object ທີ່ເຊັນໂດຍ nodes ຢືນຢັນ:

• ຢ່າງຫນ້ອຍ ⅔ ຂອງ n nodes ໃນຄະນະກໍາມະການຂອງລັດໄດ້ລົງນາມໃນຫົວຂໍ້ບລັອກ b.

• current_committee ຂອງ block b ເທົ່າກັບຕົ້ນໄມ້ next_committee ຂອງ block b-1.

• ຕັນ b-1 ແມ່ນທັງ genesis block, ຫຼືຖືກຕ້ອງກັບສາມເງື່ອນໄຂນີ້.

  
  

ໂປຣໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນ ແລະແອັບພລິເຄຊັນອື່ນໆ ທີ່ຕ້ອງການຄວາມໝັ້ນຄົງໃນແງ່ດີ ດ້ວຍການສິ້ນສຸດໄວ (ຕົວຢ່າງ: ຂົວຂ້າມຕ່ອງໂສ້ ແລະໂປຣໂຕຄໍການສົ່ງຂໍ້ຄວາມ) ສາມາດໃຊ້ຫຼັກຖານຂອງລັດຈາກຄະນະກໍາມະລັດ Lagrange ດ້ວຍການສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈໜ້ອຍທີ່ສຸດ. ສິ່ງສໍາຄັນ, ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ສາມາດຮັບປະກັນຄວາມປອດໄພຂອງຫຼັກຖານຂອງລັດໂດຍການປະຕິບັດການກໍານົດ ການຂູດຮີດ ຂອງຜູ້ຢັ້ງຢືນທີ່ເປັນອັນຕະລາຍແລະ ຫຼັກຖານຄວາມຖືກຕ້ອງ inductive .

ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ຮ່ວມມືກັບ ZK Big Data Stack ແນວໃດ?

ໃນການຕອບທໍາອິດຂອງຊຸດໃນຊຸດຜະລິດຕະພັນຂອງ Lagrange, ພວກເຮົາໄດ້ເນັ້ນໃສ່ຄວາມສໍາພັນລະຫວ່າງພາກສ່ວນຕ່າງໆຂອງ ZK Big Data Stack : Lagrange State Committees, Recproofs, zkMapReduce, ແລະ Lagrange Coprocessor. ແຕ່​ລະ​ອົງ​ປະ​ກອບ​ເຫຼົ່າ​ນີ້​, ເມື່ອ​ລວມ​ເຂົ້າ​ກັນ​, ລວມ​ທັງ​ສະ​ຫນອງ​ຄວາມ​ປອດ​ໄພ​, ປະ​ສິດ​ທິ​ພາບ​ການ​ເຂົ້າ​ເຖິງ​ລັດ​ແລະ​ການ​ສະ​ແດງ​ອອກ​, ການ​ຄິດ​ໄລ່​ແບບ​ເຄື່ອນ​ໄຫວ​ກ່ຽວ​ກັບ​ຂໍ້​ມູນ​ຂອງ​ລັດ​:

#1. ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ປະສົມປະສານກັບອົງປະກອບອື່ນໆຂອງ ZK Big Data Stack ສໍາລັບການປະຕິບັດທີ່ດີກວ່າ

ພວກເຮົາໃຊ້ Recproofs ແລະ zkMapReduce ເພື່ອສ້າງຫຼັກຖານສະແດງຂໍ້ມູນກະແຈສາທາລະນະລວມ (APK) ທີ່ສາມາດປັບປຸງໄດ້ສໍາລັບຄະນະກໍາມະການຂອງລັດ - ອະນຸຍາດໃຫ້ພວກເຮົາຫຼີກເວັ້ນການຂະບວນການທີ່ມີຄ່າໃຊ້ຈ່າຍແລະໃຊ້ເວລາຫຼາຍໃນການລວບລວມແລະລວບລວມລະຫັດສາທາລະນະຂອງຜູ້ທີ່ບໍ່ແມ່ນຜູ້ລົງນາມຄືນໃຫມ່ທຸກຄັ້ງທີ່ລາຍເຊັນລວມໃຫມ່ຕ້ອງມີ. ສ້າງ​ຕັ້ງ​ຂື້ນ​.

ການລວບລວມກະແຈສາທາລະນະ BLS ທີ່ມີປະສິດທິພາບຂອງຜູ້ປະກອບການໃນຄະນະກໍາມະການຂອງລັດ Lagrange AVS ອໍານວຍຄວາມສະດວກໃຫ້ອັດຕາການມີສ່ວນຮ່ວມທີ່ສູງຂຶ້ນໃນ AVS ໂດຍບໍ່ມີ ການເພີ່ມຄ່າໃຊ້ຈ່າຍໃນຄອມພິວເຕີ້ໃນການກວດສອບການຢັ້ງຢືນຈາກຄະນະກໍາມະຂອງລັດ. ນີ້ແມ່ນເຫດຜົນທີ່ຄະນະກໍາມະການຂອງລັດ Lagrange ສາມາດສະຫນັບສະຫນູນຊຸດ nodes ທີ່ມີທ່າແຮງທີ່ບໍ່ມີຂອບເຂດແລະສະແດງຄວາມປອດໄພ superlinear ເນື່ອງຈາກນະຄອນຫຼວງຫຼາຍໄດ້ຖືກລວມເຂົ້າໃນຄະນະກໍາມະການຂອງລັດ. ທ່ານສາມາດຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບຊັບສິນນີ້ຢູ່ໃນຂໍ້ຄວາມຂອງພວກເຮົາກ່ຽວກັບ ການຂະຫຍາຍຄວາມໄວ້ວາງໃຈໃນໂຄງການ EigenLayer ດ້ວຍ ZK Big Data .

ການປະສົມປະສານຄະນະກໍາມະການຂອງລັດ Lagrange ກັບ ZK Big Data stack ຍັງມີຜົນປະໂຫຍດໂດຍກົງຫຼາຍສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງລູກຄ້າທີ່ນໍາໃຊ້ຫຼັກຖານຂອງລັດ Lagrange. ຕົວຢ່າງ, ພວກເຮົາສາມາດໃຊ້ຄຸນສົມບັດ zkMapReduce ຂອງ Lagrange Coprocessor ເພື່ອສົມທົບການພິສູດຂອງລັດຫຼາຍອັນຈາກລະບົບຕ່ອງໂສ້ການມ້ວນໃນແງ່ດີ ເຂົ້າໄປໃນ ຫຼັກຖານລັດຫຼາຍລະບົບຕ່ອງໂສ້ ດຽວ . ນີ້ອະນຸຍາດໃຫ້ສໍາລັບ "ການຢັ້ງຢືນແບບຊ້ອນກັນ", ບ່ອນທີ່ທຸລະກໍາໃນລະບົບຕ່ອງໂສ້ດຽວພ້ອມກັນຢັ້ງຢືນສະຖານະຂອງການລວບລວມໃນແງ່ດີຫຼາຍ, ແລະຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການກວດສອບການບໍລິການລູກຄ້າ.

#2: The Lagrange Coprocessor ປະສົມປະສານກັບເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ເພື່ອພະລັງງານການຄິດໄລ່ນອກລະບົບຕ່ອງໂສ້ທີ່ບໍ່ຫນ້າເຊື່ອຖື

Lagrange Coprocessor—ເຊິ່ງພວກເຮົາຈະວິເຄາະຢ່າງກວ້າງຂວາງໃນບົດຕໍ່ໆໄປ—ສະຫນັບສະຫນູນການຄິດໄລ່ລາຄາຖືກ ແລະສາມາດປັບຂະໜາດໄດ້ໃນຂໍ້ມູນໃນລະບົບຕ່ອງໂສ້ໂດຍການປະຕິບັດການຄິດໄລ່ນອກລະບົບຕ່ອງໂສ້. ໂປຣໂຕຄອນການໂຕ້ຕອບລະຫວ່າງລະບົບຕ່ອງໂສ້ທີ່ປະສົມປະສານກັບຄະນະກໍາມະການຂອງລັດ Lagrange ຍັງສາມາດປະສົມປະສານກັບ Lagrange Coprocessor, ເພື່ອອໍານວຍຄວາມສະດວກໃນການຂະຫຍາຍການສະເຫນີຂາຍຂ້າມຕ່ອງໂສ້ຂອງພວກເຂົາເພື່ອລວມເອົາການຄິດໄລ່ທີ່ສາມາດກວດສອບໄດ້.

ສໍາລັບຕົວຢ່າງ, ນັກພັດທະນາທີ່ສ້າງຄໍາຮ້ອງສະຫມັກການກູ້ຢືມຫຼາຍລະບົບຕ່ອງໂສ້ອາດຈະຕ້ອງການທີ່ຈະຄິດໄລ່ຜົນລວມຂອງຫຼັກຊັບຄ້ຳປະກັນທີ່ຜູ້ໃຊ້ຝາກໄວ້ຕະຫຼອດ n ມ້ວນທີ່ແຕກຕ່າງກັນ. ຜູ້ພັດທະນາທີ່ເປັນມິດຂອງພວກເຮົາສາມາດນຳໃຊ້ຕົວປະມວນຜົນ Lagrange Coprocessor ເພື່ອຄຳນວນຄ່ານີ້, ໂດຍໃຊ້ແຫຼ່ງ block header ໃດກໍໄດ້ທີ່ໂປຣໂຕຄໍຂ້າມຕ່ອງໂສ້ອາໄສຢູ່ແລ້ວ.

ເປັນຫຍັງເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດຂອງ Lagrange ຈຶ່ງເປັນຕົວປ່ຽນແປງເກມສໍາລັບການເຮັດວຽກຮ່ວມກັນໃນການລວບລວມຂໍ້ມູນໃນແງ່ດີ

ແບ່ງປັນ, ຄວາມປອດໄພ superlinear ສໍາລັບລູກຄ້າໃນແງ່ດີ rollup light

ປະຈຸບັນ, ໂປຣໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນທີ່ຮອງຮັບການເຊື່ອມຈອດລະຫວ່າງຕ່ອງໂສ້ການໝູນວຽນໃນແງ່ດີແມ່ນຮັບຜິດຊອບຢ່າງເປັນອິດສະຫຼະໃນການກວດສອບສະຖານະຂອງຕ່ອງໂສ້ແຫຼ່ງທີ່ມາ. ຄວາມປອດໄພຂອງໂປຣໂຕຄອນທີ່ເຮັດຮ່ວມກັນໄດ້ແມ່ນຂຶ້ນກັບກົນໄກເພື່ອກວດສອບວ່າຫົວບລັອກຖືກຕ້ອງ.

ບາງໂປຣໂຕຄອນການສື່ສານຂ້າມຕ່ອງໂສ້ພະຍາຍາມຫຼຸດຜ່ອນການສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈໂດຍການປະຕິບັດການຕັ້ງຖິ່ນຖານເດີມແລະຂໍໃຫ້ຊຸດຂອງຕົວກວດສອບເພື່ອຜູກມັດຫລັກປະກັນກ່ອນທີ່ຈະຢັ້ງຢືນວ່າຕັນສ່ວນຫົວຂອງຕ່ອງໂສ້ແຫຼ່ງ. ແນວໃດກໍ່ຕາມ, ຊິ້ນສ່ວນນີ້ເຮັດໃຫ້ຄວາມປອດໄພທາງດ້ານເສດຖະກິດໃນທົ່ວໂປຣໂຕຄອນຂ້າມຕ່ອງໂສ້ທີ່ແຕກຕ່າງກັນ, ເນື່ອງຈາກຄ່າໃຊ້ຈ່າຍໃນການທໍາລາຍຊຸດຍ່ອຍ ( k ຂອງ n ) ຂອງແຕ່ລະຊຸດຕົວກວດສອບຂອງໂປໂຕຄອນແມ່ນຕໍ່າກວ່າ.

ໃນທາງກົງກັນຂ້າມ, ຄະນະກໍາມະລັດ Lagrange ອະນຸຍາດໃຫ້ອະນຸສັນຍາຂ້າມຕ່ອງໂສ້ຫຼາຍອັນເພື່ອໃຫ້ຄວາມປອດໄພມາຈາກຊຸດ ດຽວ , ໄດນາມິກຂອງ validators ທີ່ສາມາດປັບຂະຫນາດເຖິງຂະຫນາດທີ່ບໍ່ມີຂອບເຂດ. ນີ້ຈະປ່ຽນສະຖານະທີ່ເປັນຢູ່—ເຊິ່ງແຕ່ລະໂປຣໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນມີຄວາມຮັບຜິດຊອບເປັນເອກະລາດໃນການກວດສອບຄວາມຖືກຕ້ອງຂອງລັດຂ້າມຕ່ອງໂສ້—ເປັນບ່ອນທີ່ແອັບພລິເຄຊັນຫຼາຍອັນສາມາດບໍລິໂພກສະຖານະຂ້າມຕ່ອງໂສ້ຈາກແຫຼ່ງດຽວ.

ບໍ່ເຫມືອນກັບໂປໂຕຄອນລູກຄ້າແສງສະຫວ່າງອື່ນໆ, ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ສະຫນັບສະຫນູນຊຸດການຢັ້ງຢືນແບບເຄື່ອນໄຫວ, ບໍ່ມີຂອບເຂດ. ນ້ຳໜັກທາງເສດຖະກິດຂອງລາຍເຊັນທີ່ຮັບປະກັນແຕ່ລະໃບຮັບຮອງສາມາດຂະຫຍາຍໄດ້ຢ່າງຂະຫຍັນຂັນເຄື່ອນ ເມື່ອສະເຕກຫຼາຍຂຶ້ນຖືກລວມເຂົ້າໃນຄະນະກຳມາທິການຂອງລັດ—ເຮັດໃຫ້ການເພີ່ມຄວາມໝັ້ນຄົງສູງຂື້ນ ແລະເພີ່ມຄວາມຫຍຸ້ງຍາກໃນການໂຈມຕີອະນຸສັນຍາຂ້າມຕ່ອງໂສ້ແບບປະສົມປະສານໃນການໂດດດ່ຽວ.

ນີ້ປະສິດທິຜົນເຮັດໃຫ້ຄະນະກໍາມະການຂອງລັດ Lagrange ເປັນ "ເຂດຄວາມປອດໄພຮ່ວມກັນ" ທີ່ໂປໂຕຄອນຂ້າມຕ່ອງໂສ້ໃດໆ (ໂດຍບໍ່ຄໍານຶງເຖິງຂະຫນາດຂອງມັນ) ສາມາດສຽບເຂົ້າໄປໃນຄວາມປອດໄພສູງສຸດ - ຄ້າຍຄືກັບ Relay Chain ໃນ Polkadot ແລະ Cosmos Hub ໃນ Cosmos ຮັບປະກັນເຄືອຂ່າຍຮອງໃນ. ລະບົບນິເວດ multichain. ນອກຈາກນັ້ນ, ການເຊື່ອມໂຍງກັບອຸປະກອນກາງທີ່ພັກຜ່ອນຂອງ EigenLayer ຊ່ວຍໃຫ້ເຄືອຂ່າຍຄະນະກໍາມະລັດ Lagrange ສາມາດຂະຫຍາຍຄວາມປອດໄພທາງເສດຖະກິດຂອງ Ethereum ເພື່ອຮັບປະກັນຈໍານວນທີ່ມັກຂອງໂປຣໂຕຄອນການສື່ສານຂ້າມຕ່ອງໂສ້ທາງລຸ່ມ.

ການຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍສໍາລັບທີມງານພັດທະນາຜະລິດຕະພັນຂ້າມຕ່ອງໂສ້

ຜູ້ພັດທະນາທີ່ສ້າງໂປຣໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນຂ້າມຕ່ອງໂສ້ໃນມື້ນີ້ຕ້ອງພັດທະນາໂຄງສ້າງພື້ນຖານເພື່ອແລ່ນຜູ້ເບິ່ງຢ່າງເປັນເອກະລາດເພື່ອກວດສອບສະຖານະຂອງທຸກໆການລວບລວມຂໍ້ມູນໃນແງ່ດີທີ່ພວກເຂົາສະຫນັບສະຫນູນ. ໃນຂະນະທີ່ຈໍານວນການລວມຕົວໃນແງ່ດີເພີ່ມຂຶ້ນ, ໂຄງສ້າງພື້ນຖານຂອງການຄຸ້ມຄອງຄວາມປອດໄພໃນທົ່ວແຕ່ລະຕ່ອງໂສ້ຕົ້ນກໍາເນີດເພີ່ມຂຶ້ນ.

ການປະສົມປະສານກັບຄະນະກໍາມະການຂອງລັດ Lagrange ອະນຸຍາດໃຫ້ນັກພັດທະນາ outsource ຄວາມປອດໄພຂອງພວກເຂົາແລະແທນທີ່ຈະສຸມໃສ່ຊັບພະຍາກອນໃນການເພີ່ມປະສິດທິພາບຂອງຜະລິດຕະພັນຂອງພວກເຂົາ. ເພື່ອເຮັດໃຫ້ມັນເຂົ້າໄປໃນສະພາບການ: ຫຼັກຖານສະແດງຂອງລັດ Lagrange ແຕ່ລະຄົນມີນ້ໍາຫນັກເບົາພຽງພໍທີ່ຈະກວດສອບໄດ້ຢ່າງມີປະສິດທິພາບໃນລະບົບຕ່ອງໂສ້ທີ່ເຂົ້າກັນໄດ້ກັບ EVM.

ຄວາມ​ປອດ​ໄພ​ເພີ່ມ​ເຕີມ​ສໍາ​ລັບ​ອະ​ນຸ​ສັນ​ຍາ​ການ​ເຮັດ​ວຽກ​ຮ່ວມ​ກັນ​ທີ່​ມີ​ຢູ່​ແລ້ວ​

ຫຼັກຖານສະແດງຂອງລັດ Lagrange ແມ່ນບໍ່ສົນໃຈກັບຊັ້ນການຂົນສົ່ງທີ່ໃຊ້ໃນການຂົນສົ່ງພວກເຂົາໄປສູ່ຕ່ອງໂສ້ປາຍທາງຫນຶ່ງຫຼືຫຼາຍ, ອະນຸຍາດໃຫ້ແອັບພລິເຄຊັນທີ່ເຮັດວຽກຮ່ວມກັນເພື່ອ stack ຫຼັກຖານຂອງລັດ Lagrange ກັບກົນໄກຄວາມປອດໄພທີ່ມີຢູ່ແລ້ວ. ຕົວຢ່າງ, ໂປຣໂຕຄອນການສົ່ງຂໍ້ຄວາມຂ້າມຕ່ອງໂສ້ oracle ຂ້າມຕ່ອງໂສ້ທີ່ມີຊຸດຕົວກວດສອບເອກະລາດສາມາດກວດສອບຫຼັກຖານຂອງລັດ Lagrange ເປັນມາດຕະການຄວາມປອດໄພເພີ່ມເຕີມກ່ອນທີ່ຈະສົ່ງຕໍ່ຄໍາຮ້ອງຂໍຂໍ້ຄວາມຂ້າມຕ່ອງໂສ້ຈາກການລວບລວມໃນແງ່ດີ.

ຍິ່ງໄປກວ່ານັ້ນ, ໂປໂຕຄອນຄວາມສາມາດໃນການເຮັດວຽກຮ່ວມກັນທີ່ມີຢູ່ແລ້ວ - ເມື່ອປະສົມປະສານກັບເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange - ສາມາດເພີ່ມການສະຫນັບສະຫນູນສໍາລັບການລວບລວມໃນແງ່ດີໂດຍບໍ່ຈໍາເປັນຕ້ອງມີຜູ້ກວດສອບເພື່ອເພີ່ມຈໍານວນຕ່ອງໂສ້ທີ່ພວກເຂົາຕິດຕາມ. ໂດຍການນໍາໃຊ້ຫຼັກຖານສະແດງຂອງລັດຈາກເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange, ຜູ້ກວດສອບພຽງແຕ່ຕ້ອງສົ່ງຕໍ່ຄໍາຮ້ອງຂໍຂໍ້ຄວາມລະຫວ່າງການລວບລວມຂໍ້ມູນ. ສັນຍາປະຕູໃນລະບົບຕ່ອງໂສ້ປາຍທາງສາມາດກວດສອບການມີຢູ່ຂອງຂໍ້ຄວາມທີ່ສົ່ງຜ່ານໂດຍ relayers ໂດຍການກວດສອບຫຼັກຖານຂອງລັດ Lagrange.

ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ປຽບທຽບກັບກົນໄກຄວາມປອດໄພຂ້າມຕ່ອງໂສ້ອື່ນໆແນວໃດ?

ຄະນະກໍາມະການຂອງລັດ Lagrange ປຽບທຽບທີ່ເອື້ອອໍານວຍກັບໂຄງສ້າງພື້ນຖານທີ່ມີຄວາມສາມາດຮ່ວມກັນທີ່ມີຢູ່ທີ່ນໍາໃຊ້ການເຊື່ອມໂຍງ / slashing, ການກວດສອບການອະນຸຍາດ, ແລະກົນໄກການຢັ້ງຢືນໃນແງ່ດີ (ໃນບັນດາສິ່ງອື່ນໆ) ເພື່ອເພີ່ມຄວາມປອດໄພຂອງຫຼັກຖານຂອງລັດຂ້າມຕ່ອງໂສ້. ຂ້າງລຸ່ມນີ້ແມ່ນບາງການປຽບທຽບ:

ການກວດສອບພາຍນອກໂດຍຜູ້ກວດສອບທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ

ຮູບແບບການພັກຜ່ອນຂອງ Lagrange ຫຼຸດຜ່ອນບັນຫາທີ່ສໍາຄັນໃນກົນໄກຄວາມປອດໄພຂ້າມຕ່ອງໂສ້ທີ່ປະຕິບັດການວາງ PoS ບໍລິສຸດສໍາລັບຄວາມປອດໄພ: ການ stacking ຄວາມສ່ຽງ . ຕົວຢ່າງເຊັ່ນ, ໂປຣໂຕຄອນຂ້າມຕ່ອງໂສ້ທີ່ຮຽກຮ້ອງໃຫ້ຜູ້ກວດສອບສາມາດຊື້ ແລະລັອກໂທເຄັນເດີມຂອງໂປຣໂຕຄໍສຳລັບໄລຍະເວລາການຜູກມັດ. ເນື່ອງຈາກຄວາມນິຍົມຂອງໂທເຄັນພື້ນເມືອງຂອງລະບົບຕ່ອງໂສ້ຂ້າມຕ່ອງໂສ້ການປ່ຽນແປງ, ການເຫນັງຕີງຂອງລາຄາຊັບສິນສົ່ງຜົນກະທົບຕໍ່ຄວາມຫມັ້ນຄົງທາງດ້ານເສດຖະກິດທັງຫມົດຂອງເຄືອຂ່າຍ.

ການເຫນັງຕີງຂອງລາຄາແມ່ນເປັນບັນຫາຫນ້ອຍສໍາລັບເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ເນື່ອງຈາກຄວາມປອດໄພຂອງຄະນະກໍາມະແມ່ນອີງໃສ່ການຄໍ້າປະກັນຄືນໃຫມ່ຜ່ານ EigenLayer. ນອກຈາກນັ້ນ, ຫຼັກຊັບຄໍ້າປະກັນຄືນໃຫມ່ໄດ້ຫຼຸດລົງຄ່າໃຊ້ຈ່າຍໃນໂອກາດສໍາລັບຜູ້ກວດສອບໃນອະນາຄົດ, ຊຶ່ງຫມາຍຄວາມວ່າການມີສ່ວນຮ່ວມຫຼາຍໃນຄະນະກໍາມະການຂອງລັດແລະລະດັບຄວາມປອດໄພທາງດ້ານເສດຖະກິດທີ່ສູງຂຶ້ນສໍາລັບອະນຸສັນຍາລະຫວ່າງປະເທດ. ສໍາລັບຜູ້ໃຊ້, ນີ້ຫມາຍຄວາມວ່າຄ່າທໍານຽມຕ່ໍາແລະຄວາມປອດໄພຫຼາຍເມື່ອທຽບກັບອະນຸສັນຍາ interoperability ທີ່ bootstrap ຄວາມປອດໄພຂອງເຂົາເຈົ້າເປັນເອກະລາດ.

ພວກເຮົາຍັງສັງເກດວ່າໂປໂຕຄອນເປັນເອກະສັນກັນໃຊ້ໃນຂໍ້ຈໍາກັດຂອງສະຖານທີ່ຫຼັກຖານສະແດງການສະເຕກແບບດັ້ງເດີມກ່ຽວກັບຈໍານວນຜູ້ກວດສອບ (ຕົວຢ່າງ, Tendermint BFT caps participation at 100-200 validators) ແລະປ້ອງກັນບໍ່ໃຫ້ໂປໂຕຄອນ PoS ແບບດັ້ງເດີມຈາກການຂະຫຍາຍຄວາມປອດໄພທາງດ້ານເສດຖະກິດເລື້ອຍໆຕາມຄວາມຕ້ອງການ. ໃນທາງກົງກັນຂ້າມ, ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ໃຊ້ກົນໄກການຢັ້ງຢືນທີ່ສະຫນັບສະຫນູນຊຸດທີ່ບໍ່ມີຂອບເຂດທີ່ມີທ່າແຮງທີ່ເຂົ້າຮ່ວມໃນຄວາມເຫັນດີນໍາ. ນີ້ຮັບປະກັນວ່າເຄືອຂ່າຍສາມາດເພີ່ມຈໍານວນຜູ້ຢັ້ງຢືນຢ່າງເຄື່ອນໄຫວແລະໂດຍການຂະຫຍາຍ, ສະຫນອງການຮັບປະກັນທີ່ເຂັ້ມແຂງທາງດ້ານເສດຖະກິດສໍາລັບຄໍາຮ້ອງສະຫມັກຂອງລູກຄ້າ.

ການກວດສອບພາຍນອກໂດຍຜູ້ກວດສອບທີ່ໄດ້ຮັບອະນຸຍາດ

ໂປໂຕຄອນຂ້າມຕ່ອງໂສ້ທີ່ອີງໃສ່ການພິສູດສິດອຳນາດ (PoA) ອີງໃສ່ການຢັ້ງຢືນເພື່ອບລັອກສ່ວນຫົວຈາກຊຸດນ້ອຍຂອງໂນດທີ່ໄດ້ຮັບອະນຸຍາດ. ວິທີການເຫຼົ່ານີ້ໄດ້ຮັບການພິສູດທາງປະຫວັດສາດວ່າບໍ່ປອດໄພກັບເຫດການທີ່ມີຂໍ້ມູນສູງລວມທັງ ການແຮັກ Ronin (ຜູ້ກວດສອບ 5 ຄົນໃນ 7 ຄົນຖືກລະເມີດ) ແລະ Harmony One Bridge hack (2 ໃນ 5 ຜູ້ກວດສອບຖືກຫຼຸດຫນ້ອຍລົງ).

ການໃຊ້ລະບົບທີ່ບໍ່ໄດ້ຮັບການອະນຸຍາດເຊັ່ນເຄືອຂ່າຍຄະນະກໍາມະລັດ Lagrange ຫຼຸດລົງປະສິດທິພາບບາງຢ່າງເມື່ອທຽບກັບຜູ້ປະຕິບັດການສູນກາງຫຼືຜູ້ກວດສອບກໍານົດການເຊັນຫົວ. ແຕ່ຍ້ອນປະລິມານທີ່ມີຄວາມສ່ຽງ, ພວກເຮົາຖືວ່ານີ້ເປັນການຊື້ຂາຍທີ່ສົມເຫດສົມຜົນ. ລະບົບການກວດສອບການອະນຸຍາດຍັງຫຼຸດລົງພື້ນທີ່ການໂຈມຕີສໍາລັບບໍລິສັດທີ່, ເລື້ອຍໆກ່ວາບໍ່, ອາດຈະສິ້ນສຸດການແລ່ນຜູ້ກວດສອບສ່ວນໃຫຍ່ໃນລະບົບທີ່ໄດ້ຮັບອະນຸຍາດ.

ຂົວ Canonical

ເຄືອຂ່າຍຄະນະກໍາມະການຂອງລັດ Lagrange ລົບລ້າງຄວາມລ່າຊ້າຂອງການສົ່ງຂໍ້ຄວາມຂ້າມຕ່ອງໂສ້ຈາກການລວບລວມໃນແງ່ດີ. ແຕ່ລະ LSC ເຮັດຫນ້າທີ່ເປັນ "ໂຫມດໄວ" ສໍາລັບຂົວແລະໂປໂຕຄອນການສົ່ງຂໍ້ຄວາມທີ່ຜູ້ໃຊ້ຕ້ອງການສ້າງຂົວຈາກການລວບລວມໃນແງ່ດີໂດຍບໍ່ຕ້ອງລໍຖ້າປ່ອງຢ້ຽມທີ່ທ້າທາຍ. ການລວບລວມຂໍ້ມູນໃນແງ່ດີຍັງໄດ້ຮັບຜົນປະໂຫຍດໂດຍກົງຈາກຊັບສິນສຸດທ້າຍໄວຂອງ LSC ຍ້ອນວ່າມັນແກ້ໄຂຈຸດເຈັບປວດ UX ທີ່ສໍາຄັນສໍາລັບຜູ້ໃຊ້ L2.

ການຄໍ້າປະກັນນີ້ແມ່ນມາຈາກການສັງເກດເຫັນວ່າ: (a) ກົນໄກການຂູດຮີດໄດ້ຖືກອອກແບບເພື່ອຍົກສູງຄ່າໃຊ້ຈ່າຍຂອງການກະທໍາຂອງຝ່າຍກົງກັນຂ້າມ, ແລະ (b) ການແບ່ງສ່ວນຂອງຂໍ້ຜູກມັດໃນ LSC ສາມາດເກີດຂື້ນໃນລະບົບຕ່ອງໂສ້ໃນ ໂຫມດຊ້າ ຍ້ອນວ່າມີການຊັກຊ້າເວລາປ່ຽນແປງ. ການ​ຖອນ​ສະ​ເຕກ. ສະຫຼຸບແລ້ວ, ຜູ້ເຂົ້າຮ່ວມໃນ LSC ສະເຫມີມີແຮງຈູງໃຈທີ່ຈະຢືນຢັນເພື່ອແກ້ໄຂລັດຂ້າມຕ່ອງໂສ້ - ເຊິ່ງເຮັດໃຫ້ແອັບພລິເຄຊັນຂ້າມຕ່ອງໂສ້ສາມາດນໍາໃຊ້ຫຼັກຖານຂອງລັດຈາກ LSC ທັນທີແລະມີສົມມຸດຕິຖານຄວາມໄວ້ວາງໃຈຫນ້ອຍທີ່ສຸດທີ່ສະຫນັບສະຫນູນໂດຍ ຂົວ canonical ຂອງ rollup.

ສະຫຼຸບ

ບົດ​ຄວາມ​ນີ້​ໄດ້​ກວມ​ເອົາ​ພື້ນ​ທີ່​ຂ້ອນ​ຂ້າງ​ຫຼາຍ, ແລະ​ພວກ​ເຮົາ​ຫວັງ​ວ່າ​ການ​ອ່ານ​ມັນ​ໄດ້​ຮັບ​ການ​ສຶກ​ສາ — ຖ້າ​ຫາກ​ວ່າ​ບໍ່​ມີ​ຄຸນ​ຄ່າ — ສໍາ​ລັບ​ຜູ້​ກໍ່​ສ້າງ​, ນັກ​ລົງ​ທຶນ​, ກະ​ຕື​ລື​ລົ້ນ​, ແລະ​ຜູ້​ຊົມ​ໃຊ້​ໃນ​ຊ່ອງ​ທີ່​ສາ​ມາດ​ເຮັດ​ວຽກ​ຮ່ວມ​ກັນ​ໄດ້​. ໃນໄລຍະຂອງບົດຄວາມນີ້, ພວກເຮົາໄດ້ຄົ້ນຫາຄໍານິຍາມຂອງຄວາມປອດໄພຮ່ວມກັນ, ມັນຫມາຍຄວາມວ່າແນວໃດສໍາລັບການອອກແບບໂປໂຕຄອນທີ່ປອດໄພ, ແລະວິທີການເຮັດວຽກຮ່ວມກັນລະຫວ່າງລະບົບຕ່ອງໂສ້ສາມາດໄດ້ຮັບຜົນປະໂຫຍດຈາກການລວມເຂົ້າກັບໂຄງສ້າງພື້ນຖານຄວາມປອດໄພຮ່ວມກັນ.

ພວກເຮົາຍັງໄດ້ຄົ້ນຫາຄະນະກໍາມະການຂອງລັດ Lagrange: ການແກ້ໄຂຄວາມປອດໄພຮ່ວມກັນຂອງພວກເຮົາທີ່ອອກແບບມາດ້ວຍໂປໂຕຄອນການສື່ສານຂ້າມຕ່ອງໂສ້ຢູ່ໃນໃຈ. ຄະນະກໍາມະການຂອງລັດ Lagrange ແມ່ນສ່ວນຫນຶ່ງຂອງວິໄສທັດຂອງພວກເຮົາໃນການເຮັດໃຫ້ຄວາມປອດໄພ, ຫຼຸດຜ່ອນຄວາມຫນ້າເຊື່ອຖື, ແລະການເຮັດວຽກຮ່ວມກັນທີ່ມີປະສິດທິພາບແລະຈະເປັນສ່ວນຫນຶ່ງຂອງ stack ຂະຫນາດໃຫຍ່ທີ່ຊ່ວຍໃຫ້ນັກພັດທະນາສາມາດສ້າງຄໍາຮ້ອງສະຫມັກຂ້າມຕ່ອງໂສ້ທີ່ມີປະສິດທິພາບສໍາລັບຜູ້ໃຊ້.

ອະນາຄົດຂອງ multichain ແມ່ນຫຼີກລ່ຽງບໍ່ໄດ້ແລະມັນເປັນສິ່ງສໍາຄັນທີ່ຜູ້ໃຊ້ສາມາດໄປຈາກການນໍາໃຊ້ຕ່ອງໂສ້ຫນຶ່ງໄປຫາ 10000s ຂອງຕ່ອງໂສ້ໂດຍບໍ່ມີການປະສົບການສູນເສຍຄວາມປອດໄພຢ່າງຫຼວງຫຼາຍ. ການແກ້ໄຂເຊັ່ນຄະນະກໍາມະການຂອງລັດ Lagrange (ພ້ອມກັບຄວາມກ້າວຫນ້າອື່ນໆໃນຄວາມປອດໄພຂ້າມຕ່ອງໂສ້) ແມ່ນສໍາຄັນຕໍ່ເປົ້າຫມາຍນີ້. ດ້ວຍການໂຕ້ຕອບທີ່ໄດ້ຮັບຄວາມສົນໃຈຫຼາຍກວ່າທີ່ເຄີຍມີມາ, ໂລກທີ່ການເຄື່ອນຍ້າຍຜ່ານລະບົບຕ່ອງໂສ້ແມ່ນປອດໄພແລະມີປະສິດທິພາບແມ່ນດີຫຼາຍໃນການເຂົ້າເຖິງຜູ້ໃຊ້ crypto ທົ່ວໂລກ.

ຊົມເຊີຍ

Emmanuel Awosika ( 2077 Research ), Omar Yehia ( Lagrange Labs ), Ismael Hishon-Rezaizadeh ( Lagrange Labs ), ແລະ Amir Rezaizadeh ( Lagrange Labs ) ໄດ້ປະກອບສ່ວນເຂົ້າໃນບົດຄວາມນີ້. Emmanuel ໄດ້ຮັບສັນຍາໂດຍ Lagrange Labs ເພື່ອສະຫນັບສະຫນູນການຂຽນບົດຄວາມນີ້.

ສະບັບຂອງບົດຄວາມນີ້ໄດ້ຖືກຈັດພີມມາກ່ອນຫນ້ານີ້ ຢູ່ທີ່ນີ້ .