#MultiversXPlansHardForkRecovery A ບັກຄວາມແອັດຕອມລະດັບ VM ຖືກຜັກດັນ ແລະເຮັດໃຫ້ MultiversX ຕ້ອງຢຸດເຄືອຂ່າຍຢ່າງເຕັມຮູບແບບ — ຕອນນີ້ hard fork ກຳລັງຖືກນຳໄປທົດສອບເປັນເສັ້ນທາງການຟື້ນຕົວ.

• MultiversX ລະບຸຕົ້ນເຫດພື້ນຖານວ່າເປັນບັນຫາ atomicity ລະດັບ VM ທີ່ກ່ຽວຂ້ອງກັບຄວາມຜິດພາດໃນການຈັດລຳດັບ ໃນກໍລະນີພິເສດ.

• ຜູ້ກວດສອບ (Validators) ຢຸດການກ້າວໜ້າຂອງເຄືອຂ່າຍ ເພື່ອຄວບຄຸມເຫດການ ແລະປ້ອງກັນການສົ່ງຜົນເພີ່ມ.

• ທີມງານໄດ້ກຽມການປ່ຽນແປງໂຄດ ແລະກຳລັງທົດສອບຂັ້ນຕອນການຟື້ນຕົວ.

• ການຟື້ນຕົວທີ່ວາງແຜນໄວ້ ແມ່ນ hard fork ທີ່ປະສານກັນຈາກ checkpoint ທີ່ຖືກຢືນຢັນວ່າໃຊ້ງານໄດ້ດີ (known-good) ທີ່ຮູ້ແລ້ວ.

• ຄາດວ່າ Validators ຈະຊ້ອມຂັ້ນຕອນນີ້ລ່ວງໜ້າທົ່ວ Testnet ແລະ Devnet ກ່ອນການຟື້ນຕົວໃນ mainnet.

• ຜູ້ໃຊ້ຖືກແຈ້ງໃຫ້ຢ່າສົ່ງ ຫຼືກະຈາຍ (rebroadcast) ທຣານຊາກຊັນ (transactions) ແລະໃຫ້ຫຼີກລ້ຽງການຝາກ/ຖອນ EGLD/ESDT ຜ່ານເວທີຊົງຄ້າ (exchanges) ແລະ bridges ຈົນກວ່າຈະໄດ້ຮັບການຢືນຢັນທີ່ທາງການວ່າທຸກຢ່າງປອດໄພ (all-clear).

ນີ້ແມ່ນຈຸດທີ່ຂ້ອຍຄິດວ່າເລື່ອງຈະນ່າສົນໃຈຂຶ້ນ.

hard fork ເອງບໍ່ແມ່ນສ່ວນທີ່ຂ້ອຍຈັບຕາຈາກຫຼາຍທີ່ສຸດ. ການທົດສອບທີ່ແທ້ ແມ່ນວ່າ MultiversX ສາມາດຟື້ນຟູເຄືອຂ່າຍໄດ້ຢ່າງສະອາດ ໂດຍທີ່ຍັງຮັກສາ state ທີ່ຖືກຕ້ອງ ແລະລົບການປ່ຽນແປງທີ່ບໍ່ຖືກຕ້ອງ (invalid) ທີ່ຖືກສ້າງຂຶ້ນໂດຍ exploit.

ມັນດູງ່າຍໃນເຈ້ຍ. ແຕ່ບໍ່ແມ່ນ.

ການຟື້ນຕົວແບບນີ້ຕ້ອງຈັດປະສານ validators, exchanges, bridges, ຜູ້ໃຫ້ບໍລິການໂຄງສ້າງພື້ນຖານ (infrastructure providers) ແລະຜູ້ໃຊ້ ໃຫ້ຢູ່ບ່ອນສະພາບ chain state ດຽວກັນ. ຂໍ້ອ່ອນໜຶ່ງຈຸດ ສາມາດປ່ຽນການຟື້ນຕົວທາງດ້ານເຕັກນິກ ໃຫ້ກາຍເປັນບັນຫາດ້ານການດຳເນີນງານ (operational mess).

ດັ່ງນັ້ນ ຂ້ອຍບໍ່ໄດ້ສົນໃຈກັບ “hard fork ກຳລັງຈະມາ” ເທົ່າໃດ ແຕ່ສົນໃຈວ່າ ຂັ້ນຕອນການຟື້ນຕົວນັ້ນ ແທ້ໆແລ້ວ ມັນເຮັດວຽກໄດ້ ພາຍໃຕ້ເງື່ອນໄຂຈິງຂອງໂລກ ທີ່ປະສານກັນ.

ຂໍ້ມູນນີ້ບອກຂ້ອຍຫຼາຍກວ່າ ຈາກການປະກາດການ restart ເສຍອີກ.

ຍັງພະຍາຍາມຈະຮູ້ໃຫ້ໄດ້ວ່າ ມັນປ່ຽນແປງຫຍັງແທ້ໆ.