ອະນາຄົດຂອງ Ethereum II - ການຕໍ່ຕ້ານການເຊັນເຊີ

ຊິ້ນນີ້ໃນ Futures of Ethereum ຄົ້ນຫາການຕໍ່ສູ້ຢ່າງຕໍ່ເນື່ອງຂອງມັນສໍາລັບການຕໍ່ຕ້ານການເຊັນເຊີ, ກວດເບິ່ງຜົນກະທົບຂອງຄວາມກົດດັນດ້ານກົດລະບຽບ, ບົດບາດຂອງ Proposer-Builder Separation (PBS), ແລະວິທີແກ້ໄຂທີ່ມີທ່າແຮງເຊັ່ນ mempools ທີ່ຖືກເຂົ້າລະຫັດເພື່ອຮັກສາເຄືອຂ່າຍທີ່ເປັນກາງແລະການແບ່ງສ່ວນ. Ethereum ໄດ້ຮັບຮອງເອົາໂຄງສ້າງ PBS ເພື່ອຫຼຸດຜ່ອນຄວາມສ່ຽງຕໍ່ສູນກາງຂອງກໍາໄລ MEV. ໃນລະບົບນີ້, block proposers (nodes validator ປົກກະຕິ) ມອບຫມາຍການກໍ່ສ້າງ block ໃຫ້ກັບ builders ພິເສດ, ຜູ້ທີ່ optimize ຄໍາສັ່ງເຮັດທຸລະກໍາເພື່ອເພີ່ມການສະກັດ MEV. ຫຼັງຈາກນັ້ນ, ຜູ້ສະເຫນີເລືອກແລະເຊັນຊື່ບລັອກທີ່ມີກໍາໄລຫຼາຍທີ່ສຸດກ່ອນທີ່ຈະກະຈາຍມັນໄປສູ່ເຄືອຂ່າຍ. MEV-Boost, ກົນໄກການປະມູນປິດລະບົບຕ່ອງໂສ້, ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງໃນ Ethereum ໃນມື້ນີ້ເພື່ອອໍານວຍຄວາມສະດວກໃນຂະບວນການນີ້. MEV-Boost ອະນຸຍາດໃຫ້ຜູ້ກໍ່ສ້າງທີ່ມີຄວາມຊ່ຽວຊານສາມາດສະເຫນີການສະເຫນີລາຄາໃຫ້ກັບຜູ້ສະເຫນີ, ແຂ່ງຂັນເພື່ອໃຫ້ມີຕັນຂອງເຂົາເຈົ້າລວມ. ໃນຂະນະທີ່ຊຸດຜູ້ກວດສອບ Ethereum ຍັງຄົງມີການກະຈາຍຕົວສູງ, ການສ້າງຕັນ - ໂດຍສະເພາະແມ່ນການເພີ່ມປະສິດທິພາບສໍາລັບ MEV - ແມ່ນສະລັບສັບຊ້ອນແລະໃຊ້ຊັບພະຍາກອນຫຼາຍ. ເນື່ອງຈາກຄວາມຫນັກຫນ່ວງດ້ານການຄິດໄລ່ແລະໂຄງສ້າງພື້ນຖານທີ່ສູງນີ້, ມັນມີປະສິດທິພາບຫຼາຍຂຶ້ນໃນການຄຸ້ມຄອງການກໍ່ສ້າງຕັນໃນຂະນະທີ່ຮັກສາການຢັ້ງຢືນການແບ່ງຂັ້ນຄຸ້ມຄອງ. ນີ້ແມ່ນຫຼັກການຫຼັກຂອງ PBS: ມັນແຈກຢາຍຜົນກໍາໄລຂອງ MEV ໃຫ້ກັບຜູ້ກວດສອບຢ່າງຍຸຕິທໍາໂດຍການປະມູນທີ່ເກີດຂື້ນໃນທຸກໆຕັນ, ໃນຂະນະທີ່ຮັບປະກັນວ່າຜູ້ກວດສອບທົ່ວໄປ (ລວມທັງຜູ້ຮັບຜິດຊອບໃນເຮືອນ) ບໍ່ໄດ້ຮັບຜິດຊອບກັບຄວາມສັບສົນຂອງການກໍ່ສ້າງຕັນ. ໂດຍການແຍກບົດບາດພິເສດນີ້, PBS ຮັກສາການກະຈາຍອໍານາດຂອງເຄືອຂ່າຍ Ethereum ໂດຍລວມໃນຂະນະທີ່ເພີ່ມປະສິດທິພາບຂອງການຜະລິດຕັນ. ຢ່າງໃດກໍຕາມ, ເນື່ອງຈາກຜູ້ສ້າງທີ່ປະສົບຜົນສໍາເລັດຕ້ອງການຊັບພະຍາກອນທີ່ສໍາຄັນແລະການໄຫຼວຽນຂອງທຸລະກໍາທີ່ມີສິດທິພິເສດ, ມີພຽງແຕ່ຈໍານວນຫນ້ອຍທີ່ຊະນະການປະມູນຢ່າງຕໍ່ເນື່ອງ. ຜູ້ກໍ່ສ້າງບາງຄົນຮັກສາຄວາມເດັ່ນຊັດໂດຍການສ້າງຂໍ້ຕົກລົງສະເພາະກັບກະເປົາເງິນສະເພາະ, dApps, ແລະຜູ້ໃຫ້ບໍລິການການໄຫຼວຽນຂອງຄໍາສັ່ງ, ຮັບປະກັນການເຂົ້າເຖິງທຸລະກໍາ MEV ສູງທີ່ໃຫ້ພວກເຂົາມີການແຂ່ງຂັນໃນການປະມູນຂອງຕັນ. ດັ່ງນັ້ນ, ການແຂ່ງຂັນລະຫວ່າງຜູ້ກໍ່ສ້າງຫຼຸດລົງຕາມເວລາ, ນໍາໄປສູ່ໂຄງສ້າງ oligopolistic. ໃນມື້ນີ້, ປະມານ 90% ຂອງທ່ອນໄມ້ Ethereum ຖືກສ້າງຂຶ້ນໂດຍຜ່ານ MEV-Boost, ມີພຽງແຕ່ສອງຫນ່ວຍງານ - Beaverbuild ແລະ Titan Builder - ກໍ່ສ້າງ 95% ຂອງຕັນເຫຼົ່ານີ້. ຄວາມເຂັ້ມຂົ້ນນີ້ເຮັດໃຫ້ເກີດຄວາມກັງວົນກ່ຽວກັບການຕໍ່ຕ້ານການເຊັນເຊີ, ຄວາມຍຸຕິທໍາການເຮັດທຸລະກໍາ, ແລະການກະຈາຍອໍານາດໃນໄລຍະຍາວຂອງການຜະລິດຕັນຂອງ Ethereum. ເຖິງແມ່ນວ່າການຂັດຂວາງຫຼືພຶດຕິກໍາທີ່ເປັນອັນຕະລາຍໂດຍຜູ້ກໍ່ສ້າງເຫຼົ່ານີ້ບໍ່ມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ຄວາມປອດໄພຂອງເຄືອຂ່າຍ Ethereum, ພວກມັນເຮັດໃຫ້ເກີດໄພຂົ່ມຂູ່ທີ່ຮ້າຍແຮງຕໍ່ການຕໍ່ຕ້ານການເຊັນເຊີ. ຖ້າຜູ້ສ້າງ MEV-Boost ທັງຫມົດຕັດສິນໃຈ censor ການເຮັດທຸລະກໍາຈາກຜູ້ໃຊ້ສະເພາະ, ຜູ້ໃຊ້ເຫຼົ່ານັ້ນພຽງແຕ່ຈະສາມາດສົ່ງທຸລະກໍາຜ່ານບລັອກທີ່ຜະລິດໂດຍຜູ້ກວດສອບທີ່ບໍ່ໃຊ້ MEV-Boost, ເຊິ່ງປະມານ 10% ຂອງຈໍານວນທັງຫມົດ. ດັ່ງນັ້ນ, ການປະມວນຜົນທຸລະກໍາດັ່ງກ່າວຈະໃຊ້ເວລາສະເລ່ຍ 10 ຕັນ (ປະມານ 2 ນາທີ). ສະພາບການດັ່ງກ່າວໄດ້ຍົກອອກມາ 2 ບັນຫາໃຫຍ່ຄື: ຄວາມອ່ອນແອດ້ານກົດລະບຽບ ທໍາອິດ, ມັນສາມາດເຮັດໃຫ້ Ethereum ມີຄວາມສ່ຽງຕໍ່ກົດລະບຽບ. ສໍາລັບຕົວຢ່າງ, ການລົງໂທດຂອງ Tornado Cash ທີ່ຖືກບັງຄັບໂດຍ ໄດ້ເຮັດໃຫ້ຈໍານວນຜູ້ສ້າງແລະຜູ້ກວດສອບຈໍານວນຫຼວງຫຼາຍທີ່ຄວບຄຸມການເຮັດທຸລະກໍາທີ່ກ່ຽວຂ້ອງກັບບັນຊີທີ່ຖືກລົງໂທດຈາກ OFAC. OFAC ໃນປີ 2022 ການແຂ່ງຂັນທີ່ບໍ່ຍຸຕິທໍາໃນໂປໂຕຄອນເຊັ່ນການປະມູນ ອັນທີສອງ, ການເຊັນເຊີສາມາດບິດເບືອນຜົນຂອງການປະມູນໃນລະບົບຕ່ອງໂສ້. ຕົວຢ່າງ, ພິຈາລະນາການປະມູນທີ່ຫນຶ່ງ NFT ຖືກຂາຍໃຫ້ຜູ້ປະມູນສູງສຸດທຸກໆຕັນ. ຜູ້ສ້າງບລັອກສາມາດ censor ການສະເຫນີລາຄາອື່ນໆທັງຫມົດໃນຂະນະທີ່ວາງການສະເຫນີລາຄາຕໍ່າຫຼາຍ, ໃຫ້ພວກເຂົາໄດ້ຮັບ NFT ໃນລາຄາທີ່ຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ວິທີແກ້ໄຂຕ່າງໆໄດ້ເກີດຂື້ນເພື່ອແກ້ໄຂບັນຫາເຫຼົ່ານີ້. ບົດຂຽນນີ້ຈະຄົ້ນຫາວິທີແກ້ໄຂເຫຼົ່ານີ້ຢູ່ໃນສອງປະເພດຕົ້ນຕໍແລະປຶກສາຫາລືກ່ຽວກັບຮູບແບບການຕໍ່ຕ້ານການເຊັນເຊີທີ່ອາດຈະເກີດຂຶ້ນໃນອະນາຄົດຂອງ Ethereum. ການແກ້ໄຂທີ່ເປັນໄປໄດ້ 1: ບັນຊີລາຍຊື່ລວມ ປະຫວັດຄວາມເປັນມາ: ການສະເໜີລາຍຊື່ເບື້ອງຕົ້ນ, EIP-7547 ບັນຊີລາຍຊື່ລວມແມ່ນການແກ້ໄຂການຕໍ່ຕ້ານການເຊັນເຊີທີ່ຮັບປະກັນການເຮັດທຸລະກໍາບາງຢ່າງຖືກລວມຢູ່ໃນບລັອກ. ໂດຍປົກກະຕິມັນສາມາດຖືກປະຕິບັດດັ່ງຕໍ່ໄປນີ້: ນີ້ແມ່ນຕົວແບບທາງຈິດທີ່ງ່າຍດາຍ: ກ່ອນທີ່ຜູ້ກໍ່ສ້າງຈະສ້າງບລັອກ, ຜູ້ສະເຫນີຈະສົ່ງຄໍາສັ່ງທີ່ມີ 'ລາຍການລວມ' ໂດຍກ່າວວ່າ "ລວມເອົາທຸລະກໍາເຫຼົ່ານີ້ຢູ່ໃນບລັອກ." ຜູ້ສ້າງຕ້ອງລວມເອົາທຸລະກໍາເຫຼົ່ານີ້ຢູ່ໃນບລັອກທີ່ພວກເຂົາສ້າງ, ແລະຖ້າບລັອກຖືກສ້າງຂຶ້ນໂດຍບໍ່ມີການເຮັດທຸລະກໍາໃນບັນຊີລາຍຊື່ລວມ, ມັນຖືວ່າບໍ່ຖືກຕ້ອງ. ສໍາລັບ Ethereum ກ່ອນ PBS, mempool, ບ່ອນທີ່ການເຮັດທຸລະກໍາຖືກຈັດຂຶ້ນກ່ອນທີ່ຈະເຂົ້າໄປໃນຕັນ, ໄດ້ຖືກລວມເຂົ້າໃນ Ethereum ເປັນອົງປະກອບທີ່ບໍ່ແມ່ນຄວາມເຫັນດີນໍາ. ດັ່ງນັ້ນ, ຈາກທັດສະນະຂອງຊັ້ນຄວາມເຫັນດີນໍາຂອງ Ethereum, ມັນບໍ່ໄດ້ຮູ້ວ່າການເຮັດທຸລະກໍາທີ່ມີຢູ່ໃນບລັອກມາຈາກໃສ. ຫນຶ່ງໃນເຫດຜົນຕົ້ນຕໍທີ່ MEV ນໍາໄປສູ່ການ censorship ແມ່ນວ່າ mempool ເປັນອົງປະກອບທີ່ບໍ່ເປັນເອກະສັນກັນ, ດັ່ງນັ້ນຜູ້ສ້າງທີ່ສ້າງ block ມີສິດອໍານາດຢ່າງສົມບູນກ່ຽວກັບການເຮັດທຸລະກໍາທີ່ຈະ censor ຫຼືລວມຢູ່ໃນຕັນ. ບັນຊີລາຍຊື່ລວມແນະນໍາກົນໄກທີ່ໃຊ້ຫຼາຍຕົວກວດສອບເພື່ອເຮັດຫນ້າທີ່ເປັນ 'on-chain mempool' ໃນຊັ້ນຄວາມເຫັນດີນໍາ. ດ້ວຍວິທີນີ້, ຊັ້ນຄວາມເຫັນດີເຫັນພ້ອມຢ່າງພຽງພໍຈໍາກັດສິດອໍານາດຂອງຜູ້ກໍ່ສ້າງເພື່ອເລືອກທຸລະກໍາເພື່ອສະຫນອງການຕໍ່ຕ້ານການເຊັນເຊີ. ຫນຶ່ງໃນຂໍ້ສະເຫນີທີ່ໂດດເດັ່ນທີ່ສຸດສໍາລັບການຈັດຕັ້ງປະຕິບັດບັນຊີລາຍຊື່ລວມແມ່ນ , Forward Inclusion List. ການສະເຫນີນີ້ອະນຸຍາດໃຫ້ຜູ້ສະເຫນີລວມເຖິງ 16 ທຸລະກໍາໃນບັນຊີລາຍຊື່ລວມ. ກົນໄກ "ການສົ່ງຕໍ່" ໄດ້ຮັບປະກັນວ່າລາຍການລວມທີ່ສະເໜີໃຫ້ບລັອກ N ຈະຖືກນຳໃຊ້ເພື່ອບລັອກ N+1. EIP-7547 ການສະເຫນີນີ້ໃນເບື້ອງຕົ້ນມີຈຸດປະສົງເພື່ອເປັນສ່ວນຫນຶ່ງຂອງການຍົກລະດັບ Pectra ຂອງ Ethereum, ແຕ່ໃນທີ່ສຸດມັນໄດ້ຖືກຍົກເວັ້ນ, ແລະເຫດຜົນຫນຶ່ງແມ່ນບັນຫາຄວາມເຂົ້າກັນໄດ້ລະຫວ່າງກົນໄກການສົ່ງຕໍ່ແລະ . EIP-3074 EIP-3074 ແນະນຳແບບຟອມຂອງ Native Account Abstraction ທີ່ໃຊ້ opcode ທີ່ເອີ້ນວ່າ AUTHCALL, ເຊິ່ງເຮັດໃຫ້ບັນຊີດຽວສາມາດປັບຍອດເງິນຂອງ EOA ຫຼາຍອັນ (ບັນຊີທີ່ເປັນເຈົ້າຂອງພາຍນອກ). ກົນໄກນີ້ສາມາດທໍາລາຍບັນຊີລາຍຊື່ລວມໄດ້ຢ່າງງ່າຍດາຍ. ຕົວຢ່າງ, ສົມມຸດວ່າ Alice ປະກອບມີການເຮັດທຸລະກໍາ (A) ໃນບັນຊີລາຍຊື່ລວມ, ບ່ອນທີ່ EOA ຂອງນາງສົ່ງ ETH ໄປຫາ Bob. ໃນເວລາດຽວກັນ, ນາງສ້າງທຸລະກໍາອື່ນ (B) ໂດຍໃຊ້ AUTHCALL ຂອງ EIP-3074 ເພື່ອໂອນຍອດເງິນ EOA ທັງຫມົດຂອງນາງໄປຫາບັນຊີອື່ນ. ໃຫ້ສົມມຸດວ່າທຸລະກໍາ B ແມ່ນລວມຢູ່ໃນບລັອກ N, ໃນຂະນະທີ່ທຸລະກໍາ A ແມ່ນລວມຢູ່ໃນລາຍການລວມສໍາລັບຕັນ N + 1. ນີ້ແມ່ນບັນຫາທີ່ສໍາຄັນ: ເມື່ອຜູ້ສະເຫນີສ້າງລາຍຊື່ລວມ, ພວກເຂົາບໍ່ຮູ້ວ່າການເຮັດທຸລະກໍາທີ່ຜູ້ສ້າງຈະລວມຢູ່ໃນບລັອກໃນປະຈຸບັນ. ໃນສະຖານະການນີ້, ທຸລະກໍາ B ໃນບລັອກ N ເຮັດໃຫ້ທຸລະກໍາ A ບໍ່ຖືກຕ້ອງ. ດັ່ງນັ້ນ, ຜູ້ສ້າງບລັອກ N+1 ຈະບໍ່ສາມາດສ້າງບລັອກທີ່ຖືກຕ້ອງໄດ້ເນື່ອງຈາກການບໍ່ຖືກຕ້ອງຂອງທຸລະກໍາ A ໃນບັນຊີລວມ. ມີຄວາມພະຍາຍາມທີ່ຈະແກ້ໄຂບັນຫານີ້ໂດຍຜ່ານຂໍ້ຈໍາກັດເພີ່ມເຕີມພາຍໃນບັນຊີລາຍຊື່ລວມ. ຢ່າງໃດກໍ່ຕາມ, ບັນຫາຫຼັກຍັງຄົງຢູ່: EIP-3074 ໂດຍປົກກະຕິອະນຸຍາດໃຫ້ຈັດການຄວາມສົມດຸນໃນ EOA ອື່ນໆ. ການກວດສອບງ່າຍໆ, ເຊັ່ນການຢືນຢັນທີ່ຢູ່ "ຈາກ", ບໍ່ສາມາດກວດພົບການແຊກແຊງລະຫວ່າງທຸລະກໍາບັນຊີລວມແລະທຸລະກໍາອື່ນໆ. ອັນນີ້ເອີ້ນວ່າບັນຫາການມີຂໍ້ມູນຟຣີ, ທີ່ໄດ້ກ່າວໄວ້ໃນບົດຄວາມ 'ບໍ່ມີອາຫານທ່ຽງຟຣີ - ການອອກແບບລາຍການລວມໃຫມ່.' ເຖິງແມ່ນວ່າ EIP-3074 ໄດ້ຖືກຍົກເວັ້ນຈາກການອັບເກຣດ Pectra, ຟັງຊັນທີ່ຄ້າຍຄືກັນ - EIP-7702 - ໄດ້ຖືກລວມເຂົ້າ. ດັ່ງນັ້ນ, ບັນຫາເຫຼົ່ານີ້ຕ້ອງໄດ້ຮັບການແກ້ໄຂກ່ອນທີ່ EIP-7547 ສາມາດຖືກປະຕິບັດຢູ່ໃນ Ethereum mainnet. ຍິ່ງໄປກວ່ານັ້ນ, EIP-7547 ປະເຊີນກັບສິ່ງທ້າທາຍເພີ່ມເຕີມ, ເຊັ່ນຂໍ້ຈໍາກັດທີ່ຜູ້ສະເຫນີພຽງແຕ່ຄົນດຽວສາມາດສ້າງ Inclusion List ຕໍ່ຕັນ. ປັດໃຈເຫຼົ່ານີ້ເຮັດໃຫ້ມັນຍາກທີ່ຈະນໍາໃຊ້ EIP-7547 ກັບ Ethereum mainnet ຕາມທີ່ເປັນຢູ່. ດັ່ງນັ້ນ, EIP-7547 ໄດ້ຖືກຍົກເວັ້ນຈາກການຍົກລະດັບ Pectra. FOCIL ບໍ່ມີການແກ້ໄຂບັນຫາເຫຼົ່ານີ້ບໍ? ບໍ່ດົນມານີ້, ການແກ້ໄຂທີ່ເອີ້ນວ່າ FOCIL (Fork-choice enforced Inclusion Lists) ໄດ້ຮັບຄວາມສົນໃຈຢ່າງຫຼວງຫຼາຍພາຍໃນລະບົບນິເວດ Ethereum ແລະຖືວ່າເປັນຫນຶ່ງໃນການແກ້ໄຂທີ່ເປັນໄປໄດ້ທີ່ສຸດທີ່ຈະປະຕິບັດຢູ່ໃນ Ethereum mainnet. ສະເໜີເປັນ , FOCIL ນຳສະເໜີກົນໄກທີ່ບໍ່ພຽງແຕ່ໜຶ່ງແຕ່ຫຼາຍຫົວໜ່ວຍສະເໜີລາຍການລວມ. ລາຍລະອຽດແລະລັກສະນະຂອງຕົນແມ່ນດັ່ງຕໍ່ໄປນີ້: EIP-7805 ໃນຫຼັກການຂອງມັນ, FOCIL ຮັບຮອງເອົາແນວຄວາມຄິດບັນຊີລວມ, ຊຶ່ງຫມາຍຄວາມວ່າຜູ້ໃດຜູ້ຫນຶ່ງສ້າງບັນຊີລາຍຊື່ຂອງການເຮັດທຸລະກໍາທີ່ຕ້ອງຖືກລວມຢູ່ໃນທຸກໆຕັນ, ແລະຜູ້ສະເຫນີແມ່ນຕ້ອງການລວມເອົາພວກມັນ. ຢ່າງໃດກໍຕາມ, FOCIL ແຕກຕ່າງຈາກ EIP-7547 ໃນສອງວິທີທີ່ສໍາຄັນ: ແທນທີ່ຈະເປັນຫນຶ່ງຜູ້ສະເຫນີ, ຄະນະກໍາມະການ IL ຂອງ 16 ສະມາຊິກເປັນເອກະລາດສະເຫນີລາຍຊື່ລວມ. ບັນຊີລາຍຊື່ລວມທີ່ສະເຫນີສໍາລັບຕັນ N ແມ່ນລວມຢູ່ໃນບລັອກ N ຕົວຂອງມັນເອງ, ບໍ່ແມ່ນບລັອກ N+1. ລາຍລະອຽດກົນໄກ ການສ້າງລາຍການລວມສໍາລັບຕັນ N ເລີ່ມຕົ້ນເມື່ອຊ່ອງສໍາລັບຕັນ N-1 ເລີ່ມຕົ້ນ. ຄະນະກໍາມະການ IL ທີ່ຖືກຄັດເລືອກແບບສຸ່ມຂອງຜູ້ກວດສອບ 16 ຄົນໄດ້ຮັບ ຕັນ N-1, ກໍານົດມັນເປັນຫົວຫນ້າຂອງພວກເຂົາ, ສ້າງລາຍຊື່ລວມຂອງເຂົາເຈົ້າ, ແລະຂະຫຍາຍພັນເຫຼົ່ານີ້ຜ່ານ peer-to-peer. ຂະບວນການກໍ່ສ້າງສິ້ນສຸດລົງ 9 ວິນາທີເຂົ້າໄປໃນຊ່ອງ N-1 12 ວິນາທີ, ຫຼັງຈາກນັ້ນຄະນະກໍາມະການບໍ່ສາມາດເພີ່ມເຂົ້າໃນບັນຊີລາຍຊື່ໄດ້. ໂດຍໄດ້ຮັບລາຍຊື່ເຫຼົ່ານີ້ຜ່ານເຄືອຂ່າຍ P2P, ຜູ້ສ້າງສໍາລັບຕັນ N ຕ້ອງລວມເອົາພວກມັນໃນຂະນະທີ່ກໍ່ສ້າງຕັນ. ບໍ່ດົນຫຼັງຈາກການເລີ່ມຕົ້ນຂອງຊ່ອງ N, ຕັນໄດ້ຖືກສົ່ງໃຫ້ຜູ້ສະເຫນີ. Validators ກວດສອບ block N ປຽບທຽບການເຮັດທຸລະກໍາໃນ Inclusion Lists ທີ່ພວກເຂົາໄດ້ຮັບກ່ອນຫນ້ານີ້ກັບສິ່ງທີ່ລວມຢູ່ໃນ block N ເພື່ອຮັບປະກັນການປະຕິບັດຕາມ. ຂໍ້ໄດ້ປຽບຂອງ FOCIL ຫຼາຍກວ່າ EIP-7547 ເມື່ອປຽບທຽບກັບ EIP-7547 ທີ່ສະເໜີໄວ້ກ່ອນໜ້ານີ້, FOCIL ສະເໜີຜົນປະໂຫຍດຕໍ່ໄປນີ້: ຄວາມຕ້ານທານສູງຕໍ່ການເຊັນເຊີ ແຕ່ລະຊ່ອງປະກອບດ້ວຍຄະນະກໍາມະການ IL ຂອງຜູ້ກວດສອບ 16 ຄົນທີ່ສ້າງບັນຊີລາຍຊື່ລວມ. ນີ້ສະຫນອງຄວາມຕ້ານທານທີ່ເຂັ້ມແຂງຕໍ່ກັບ censorship ກ່ວາ EIP-7547, ບ່ອນທີ່ມີພຽງແຕ່ຜູ້ກວດສອບດຽວຮັບຜິດຊອບ. ການປະຕິບັດ seamless ໂດຍການນໍາໃຊ້ມາດຕະຖານ API forkChoiceUpdate ທີ່ໃຊ້ໂດຍລູກຄ້າທີ່ເປັນເອກະສັນກັນ, ບັນຊີລາຍຊື່ລວມສາມາດຖືກລວມເຂົ້າກັບໂປໂຕຄອນໄດ້ງ່າຍກວ່າແລະລຽບງ່າຍ. ການຕໍ່ຕ້ານການເຊັນເຊີແບບ “ເວລາຈິງ” ບໍ່ເຫມືອນກັບ EIP-7547, ບ່ອນທີ່ບັນຊີລາຍຊື່ລວມທີ່ສະເຫນີສໍາລັບຕັນ N + 1 ເຮັດໃຫ້ເກີດຄວາມລ່າຊ້າ, FOCIL ປະກອບມີ IL ໃນບລັອກທີ່ສະເຫນີສໍາລັບ N ຕົວຂອງມັນເອງ, ເຮັດໃຫ້ທຸລະກໍາຖືກລວມເຂົ້າກັນໂດຍບໍ່ມີການຊັກຊ້າ. ການສ້າງຕັນ ແລະລາຍຊື່ລວມນີ້ພ້ອມກັນນີ້ ຮັບປະກັນຄວາມເຂົ້າກັນໄດ້ກັບກົນໄກການຫັກລົບບັນຊີທີ່ສະເໜີມາໃນເມື່ອກ່ອນເຊັ່ນ EIP-3074 ຫຼື EIP-7702. ບລັອກກ່ອນໜ້າບໍ່ສາມາດຍົກເລີກການເຮັດທຸລະກຳໃນລາຍການລວມໄດ້. ຜູ້ກໍ່ສ້າງໄດ້ຮັບ IL ກ່ອນທີ່ຈະສໍາເລັດການກໍ່ສ້າງຕັນ, ໃຫ້ພວກເຂົາຍົກເວັ້ນການເຮັດທຸລະກໍາໃດໆທີ່ຈະເຮັດໃຫ້ IL ບໍ່ຖືກຕ້ອງ. ຂະບວນການນີ້ແມ່ນກົງໄປກົງມາ: ຜູ້ສ້າງບັນທຶກ nonce ແລະຄວາມສົມດຸນຂອງ EOA ທັງຫມົດທີ່ກ່ຽວຂ້ອງກັບ IL ແລະປັບປຸງຄ່າເຫຼົ່ານີ້ທຸກຄັ້ງທີ່ມີການປ່ຽນແປງ. ວິທີງ່າຍໆນີ້ເຮັດໃຫ້ຜູ້ສ້າງສາມາດກວດສອບຄວາມຖືກຕ້ອງຂອງການເຮັດທຸລະກໍາ IL ແລະກໍ່ສ້າງຕັນຢ່າງສໍາເລັດຜົນ. ບົດບາດຂອງ FOCIL ໃນທ່ອນໄມ້ FOCIL ອະນຸຍາດໃຫ້ມີເຖິງ 16 Inclusion Lists ຕໍ່ບລັອກ, ໂດຍແຕ່ລະລາຍການຈຳກັດຂະໜາດສູງສຸດ 8KB (8192 bytes). ຖ້າບໍ່ມີການທັບຊ້ອນກັນໃນທຸລະກໍາທີ່ສະເຫນີໂດຍ 16 Inclusion Lists, ຂະຫນາດສູງສຸດຂອງທຸລະກໍາ IL ໃນບລັອກດຽວສາມາດບັນລຸ 128KB. ຂໍ້ຈໍາກັດນີ້ຖືກອອກແບບມາເພື່ອຫຼຸດຜ່ອນການໃຊ້ຊັບພະຍາກອນສໍາລັບຜູ້ກວດສອບເນື່ອງຈາກລາຍຊື່ລວມຖືກເຜີຍແຜ່ຜ່ານເຄືອຂ່າຍ P2P. ດັ່ງນັ້ນ, ຫຼາຍປານໃດຂອງ Ethereum block ສາມາດຖືກສ້າງຂຶ້ນໂດຍໃຊ້ ILs ພາຍໃຕ້ FOCIL? ໃນປະຫວັດສາດ, ຂະຫນາດບລັອກ Ethereum ສະເລ່ຍແມ່ນປະມານ 80-100KB, ສູງສຸດປະມານ 300KB. ຖ້າບໍ່ມີການທັບຊ້ອນກັນໃນການເຮັດທຸລະກໍາທີ່ສະເຫນີໂດຍ 16 Inclusion Lists, ມັນເປັນໄປໄດ້ທາງທິດສະດີທີ່ຈະສ້າງບລັອກ Ethereum ທັງຫມົດໂດຍໃຊ້ພຽງແຕ່ການເຮັດທຸລະກໍາ IL ເທົ່ານັ້ນ. ຢ່າງໃດກໍຕາມ, ສະຖານະການນີ້ແມ່ນບໍ່ເປັນໄປໄດ້. ເນື່ອງຈາກການເຮັດທຸລະກໍາໃນບັນຊີລວມແມ່ນໂດຍທົ່ວໄປແມ່ນມາຈາກ mempool ສາທາລະນະ, ມີຄວາມເປັນໄປໄດ້ສູງທີ່ຈະທັບຊ້ອນກັນເວັ້ນເສຍແຕ່ວ່າສະມາຊິກຄະນະກໍາມະການ 16 IL ໃຊ້ການຕັ້ງຄ່າທີ່ແຕກຕ່າງກັນທັງຫມົດ. ສະຫຼຸບແລ້ວ, ການເຮັດທຸລະກໍາໃນບັນຊີລາຍຊື່ລວມຂອງ FOCIL ຄາດວ່າຈະຄອບຄອງລະຫວ່າງ 6-10% ແລະເຖິງ 100% ຂອງບລັອກ Ethereum, ກໍລະນີທີ່ໃກ້ຊິດກັບຂອບເຂດ 6-10% ສະຫນອງໃຫ້ສະມາຊິກຄະນະກໍາມະການ IL ກໍາລັງຊອກຫາຢູ່ໃນ mempool ສາທາລະນະດຽວກັນ. ນອກເຫນືອຈາກ FOCIL: ການສົມທົບ APS ກັບ FOCIL ຄວາມເປັນມາຂອງ APS ເຫດຜົນຫນຶ່ງທີ່ FOCIL ໄດ້ກາຍເປັນການແກ້ໄຂຊັ້ນນໍາແມ່ນການປະສົມປະສານທີ່ມີທ່າແຮງຂອງມັນກັບການສະເຫນີການແຍກຜູ້ສະຫມັກຜູ້ສະເຫນີ (APS) ເຊັ່ນ: . APS ແມ່ນຫຍັງ, ແລະມັນເສີມ FOCIL ແນວໃດ? ປີ້ປະຕິບັດ APS ສະເຫນີແຍກບົດບາດຂອງຜູ້ສະເຫນີແລະຜູ້ຢັ້ງຢືນສໍາລັບຕັນ. ໃນ Ethereum, ການກໍ່ສ້າງຕັນພາຍໃຕ້ PBS ກ່ຽວຂ້ອງກັບການແບ່ງປັນບົດບາດລະຫວ່າງຜູ້ສະເຫນີ, ຜູ້ທີ່ສະເຫນີຕັນ, ແລະຜູ້ກໍ່ສ້າງ, ຜູ້ທີ່ສ້າງເນື້ອຫາຂອງບລັອກ. ອັນນີ້ປ້ອງກັນການວາງສະເຕກແບບລວມສູນທີ່ສ້າງຂຶ້ນໂດຍພັນທະມິດຜູ້ສ້າງຜູ້ສະເໜີຈາກການຜູກຂາດຜົນກຳໄລ MEV ແລະບັນທຶກ APR ສູງກວ່າຜູ້ກວດສອບປົກກະຕິ, ເຊິ່ງສາມາດລວມສູນການດຳເນີນງານຂອງຜູ້ກວດສອບໄດ້. ບັນຫານີ້ໄດ້ຖືກແກ້ໄຂໂດຍຜ່ານ MEV-Boost, ແລະລະບົບການສົ່ງຕໍ່ໃນພິທີການ (ePBS) ໄດ້ຖືກສະເຫນີເພື່ອແກ້ໄຂບັນຫາການເປັນສູນກາງທີ່ຍັງເຫຼືອ. ຢ່າງໃດກໍຕາມ, PBS ແມ່ນໂຄງສ້າງທີ່ດີທີ່ສຸດບໍ? ບົດບາດສໍາຄັນອັນໜຶ່ງຂອງຊັ້ນຄວາມເຫັນດີເຫັນພ້ອມຂອງ Ethereum ແມ່ນການແຈກຢາຍລາງວັນ ແລະ ການລົງໂທດຕໍ່ຜູ້ກວດສອບ. ຖ້າຂະບວນການນີ້ກາຍເປັນສູນກາງ, ລະບົບຕ່ອງໂສ້ຈະຖືກກະທົບໂດຍຫນ່ວຍງານລວມສູນ, ໂດຍບໍ່ຄໍານຶງເຖິງການລົງຄະແນນສຽງຂອງຜູ້ກວດສອບ. ສະນັ້ນ, ຊັ້ນຄວາມເຫັນດີເຫັນພ້ອມຄວນຍັງຄົງເປັນການແບ່ງຂັ້ນສູງ. ຢ່າງໃດກໍຕາມ, ຊັ້ນປະຕິບັດບໍ່ມີຂໍ້ຈໍາກັດດຽວກັນ. ວຽກງານເຊັ່ນ: ການສະກັດເອົາ MEV ແລະຄໍາສັ່ງການເຮັດທຸລະກໍາແມ່ນສະລັບສັບຊ້ອນແລະຍຸດທະສາດໂດຍພື້ນຖານແລ້ວ, ຈໍາເປັນຕ້ອງມີຫນ່ວຍງານລວມສູນ. ຖ້າຫາກວ່າວຽກງານເຫຼົ່ານີ້ໄດ້ຖືກບັງຄັບໃຫ້ຜູ້ຮັບຜິດຊອບທັງຫມົດ, ມັນຈະຂັບໄລ່ຕ່ອງໂສ້ໄປສູ່ການສູນກາງ. ໃນເລື່ອງນີ້, ປັດຊະຍາຂອງ Ethereum ແມ່ນວ່າ 'ຜູ້ເຂົ້າຮ່ວມເປັນເອກະສັນກັນບໍ່ຄວນຈະຖືກກະຕຸ້ນໃຫ້ດໍາເນີນວຽກງານທີ່ສັບສົນເພື່ອຜົນກໍາໄລສ່ວນບຸກຄົນ.' ຜ່ານ PBS, Ethereum ແຍກຜູ້ກວດສອບຈາກນັກສະແດງ MEV (ຜູ້ກໍ່ສ້າງ, ຜູ້ຄົ້ນຫາ) ເພື່ອແຈກຢາຍຜົນກໍາໄລຂອງ MEV ເທົ່າທຽມກັນໃນທົ່ວເຄືອຂ່າຍທັງຫມົດ. ຢ່າງໃດກໍຕາມ, ຜູ້ສະເຫນີສາມາດໃຊ້ກົນລະຍຸດທີ່ບໍ່ທໍາມະດາເພື່ອໃຫ້ໄດ້ຜົນກໍາໄລເພີ່ມເຕີມ: ການປະທະກັນລະຫວ່າງຜູ້ສະເຫນີແລະຜູ້ກໍ່ສ້າງ ຜູ້ກໍ່ສ້າງແມ່ນສູນກາງຢູ່ແລ້ວ, ແຕ່ຜູ້ສະເຫນີຍັງສະແດງໃຫ້ເຫັນເຖິງສູນກາງບາງຢ່າງ. ສໍາລັບຕົວຢ່າງ, Coinbase ຖືປະມານ 10% ຂອງ ETH ທັງຫມົດ. ຖ້າ Coinbase ສົມທົບກັບຜູ້ກໍ່ສ້າງສະເພາະເພື່ອຮັບເອົາພຽງແຕ່ຕັນຂອງມັນ, ນີ້ຈະແນະນໍາ vector ສູນກາງທີ່ສໍາຄັນເຂົ້າໄປໃນລະບົບນິເວດ. ເກມກຳນົດເວລາຂອງຜູ້ສະເໜີ ເວລາບລັອກ 12 ວິນາທີທີ່ຂ້ອນຂ້າງຍາວຂອງ Ethereum ແນະນຳການເຄື່ອນທີ່ທີ່ໜ້າສົນໃຈເອີ້ນວ່າເກມຈັບເວລາ, ເຊິ່ງຜູ້ສະເໜີເລື່ອນການພິມເຜີຍແຜ່ເພື່ອເພີ່ມກຳໄລ MEV. MEV ທີ່ມີຢູ່ໃນທ່ອນໄມ້ໂດຍທົ່ວໄປແລ້ວເພີ່ມຂຶ້ນເປັນເສັ້ນຕາມເວລາ. ຜູ້ສະເຫນີສາມາດຊັກຊ້າການຂະຫຍາຍພັນເພື່ອຂະຫຍາຍ MEV ຂອງພວກເຂົາໃຫ້ສູງສຸດ, ເຜີຍແຜ່ກ່ອນທີ່ຈະມີຄວາມສ່ຽງຕໍ່ການປະຕິເສດໂດຍຜູ້ສະເຫນີຕໍ່ໄປ. ດັ່ງນັ້ນ, ຜູ້ສະເຫນີສາມາດຂັດຂວາງການພິມເຜີຍແຜ່ພາຍໃນຊ່ອງດຽວ (12 ວິນາທີ) ໄດ້ຫຼາຍປານໃດ? ອີງຕາມຂໍ້ກໍານົດຂອງໂປໂຕຄອນຂອງ Ethereum, ສໍາລັບຜູ້ສະເຫນີຕໍ່ໄປເພື່ອພິຈາລະນາຕັນກ່ອນຫນ້າທີ່ຖືກຕ້ອງ, ຕັນຕ້ອງໄດ້ຮັບຄະແນນສຽງຈາກ 40% ຂອງຜູ້ກວດສອບ (ຜູ້ຢັ້ງຢືນ) ທີ່ມອບໃຫ້ຄະນະກໍາມະການຂອງສະລັອດຕິງທີ່ຜ່ານມາ. ໃນ Ethereum mainnet ໃນປະຈຸບັນ, ຈຸດທີ່ໄດ້ຮັບ 40% ຂອງການລົງຄະແນນສຽງທີ່ຖືກຕ້ອງແມ່ນເກີດຂຶ້ນປະມານ 3.8 ວິນາທີເຂົ້າໄປໃນຊ່ອງສຽບ. ຜູ້ສະເຫນີທີ່ພະຍາຍາມຫຼິ້ນເກມກໍານົດເວລາຈະຮັບຮອງເອົາຍຸດທະສາດການຊັກຊ້າການພິມເຜີຍແຜ່ຫຼາຍເທົ່າທີ່ເປັນໄປໄດ້, ລໍຖ້າຈົນກ່ວາພຽງແຕ່ໄດ້ຮັບຄະແນນສຽງພຽງພໍ (40% ຫຼືຫຼາຍກວ່ານັ້ນ) ເພື່ອຫຼີກເວັ້ນການປະຕິເສດໂດຍຜູ້ສະເຫນີຕໍ່ໄປ. ຢ່າງໃດກໍ່ຕາມ, ຜົນໄດ້ຮັບບໍ່ໄດ້ສອດຄ່ອງກັບຄວາມຕັ້ງໃຈຂອງຜູ້ສະເຫນີ. ຖ້າຕັນບໍ່ໄດ້ຮັບ 40% ຂອງຄະແນນສຽງ, ຜູ້ສະເຫນີຕໍ່ໄປຈະປະຕິເສດມັນ. ໃນກໍລະນີດັ່ງກ່າວ, validators ຜູ້ທີ່ໄດ້ລົງຄະແນນສຽງສໍາລັບຕັນທີ່ຖືກປະຕິເສດໄດ້ລົງຄະແນນສຽງສໍາລັບຕັນທີ່ບໍ່ແມ່ນສ່ວນຫນຶ່ງຂອງລະບົບຕ່ອງໂສ້ canonical, ເຮັດໃຫ້ມີການລົງໂທດການລົງໂທດ. ຖ້າສະຖານະການນີ້ຍັງຄົງຢູ່, ຜູ້ກວດສອບອາດຈະຊັກຊ້າການລົງຄະແນນສຽງຂອງພວກເຂົາເພື່ອສັງເກດເບິ່ງສະຖານະຂອງເຄືອຂ່າຍແລະໃຫ້ແນ່ໃຈວ່າການລົງຄະແນນຂອງພວກເຂົາຖືກຕ້ອງ. ພຶດຕິກໍານີ້ສາມາດເພີ່ມຈໍານວນຂອງ reorgs ໃນລະບົບຕ່ອງໂສ້. ສະຫຼຸບແລ້ວ, ເກມກຳນົດເວລາຂອງຜູ້ສະເໜີສາມາດສົ່ງຜົນກະທົບທາງລົບຕໍ່ຜົນໄດ້ຮັບທີ່ເປັນເອກະສັນກັນຂອງ Ethereum ແລະຕ້ອງໄດ້ຮັບການປ້ອງກັນ. ບົດບາດຂອງ APS APS ແມ່ນການແກ້ໄຂທີ່ຖືກອອກແບບເພື່ອແກ້ໄຂບັນຫານີ້. APS ສະເຫນີການສ້າງ proposer ແຍກຕ່າງຫາກສໍາລັບ layer ການປະຕິບັດ, ຢ່າງສົມບູນແຍກຊັ້ນ consensus ຈາກ MEV. ຕົວຢ່າງ, ຫນຶ່ງໃນການສະເຫນີ APS ຕົວແທນ, Execution Ticket, ແນະນໍາ "execution proposer" ທີ່ແຕກຕ່າງຈາກ beacon chain proposer. ໃນລະບົບນີ້, ໂປໂຕຄອນສ້າງແລະຂາຍປີ້ປະຕິບັດ, ເຊິ່ງໃຫ້ສິດແກ່ຜູ້ຖືຂອງພວກເຂົາທີ່ຈະໄດ້ຮັບການຄັດເລືອກແບບສຸ່ມເປັນຜູ້ສະເຫນີການປະຕິບັດສໍາລັບແຕ່ລະຕັນ. ຜູ້ສະເຫນີການປະຕິບັດເຫຼົ່ານີ້ຈະເອົາພາກສ່ວນຂອງພາລະບົດບາດປະຕິບັດໃນປັດຈຸບັນໂດຍຜູ້ສະເຫນີລະບົບຕ່ອງໂສ້ beacon ໃນ MEV-Boost, ໄດ້ຮັບການປະຕິບັດ payloads ແລະສະເຫນີໃຫ້ເຂົາເຈົ້າ. ເຫດຜົນທີ່ຢູ່ເບື້ອງຫລັງການອອກແບບນີ້ແມ່ນວ່າການເປັນສູນກາງຂອງຜູ້ສະເຫນີການປະຕິບັດບໍ່ແມ່ນບັນຫາ; ໃນຄວາມເປັນຈິງ, ການແຍກພວກມັນອອກຈາກຊັ້ນຄວາມເຫັນດີເຫັນພ້ອມປັບປຸງລະບົບລວມ. ຫຼັງຈາກນັ້ນ, ວຽກງານໃດທີ່ຜູ້ສະເຫນີລະບົບຕ່ອງໂສ້ beacon ຈະຈັດການພາຍໃຕ້ APS? ນອກເຫນືອຈາກການຈັດການເງິນຝາກ, ລາງວັນ, ແລະການລົງໂທດຂອງຜູ້ກວດສອບ (ການຫັນປ່ຽນຂອງລັດພາຍໃນລະບົບຕ່ອງໂສ້ beacon), ຜູ້ສະເຫນີຊັ້ນຄວາມເຫັນດີນໍາມີບົດບາດສໍາຄັນເພີ່ມເຕີມໃນ APS: ການສ້າງລາຍການລວມແລະສົ່ງພວກມັນໄປຫາຊັ້ນປະຕິບັດ. ມັນເປັນຄວາມປາຖະຫນາຫຼາຍສໍາລັບບັນຊີລາຍການລວມທີ່ຈະອີງໃສ່ຊຸດຜູ້ກວດສອບການແບ່ງຂັ້ນສູນກາງຂອງຄວາມເຫັນດີນໍາແທນທີ່ຈະກ່ວາຜູ້ສະເຫນີການປະຕິບັດທີ່ຂ້ອນຂ້າງສູນກາງ. ນີ້ຊ່ວຍຫຼຸດຜ່ອນຄວາມເປັນໄປໄດ້ຂອງການໂຈມຕີ censorship colluding ກັບ proposers ເພື່ອ censor ທຸລະກໍາ. ດັ່ງນັ້ນ, ຂໍ້ສະເໜີຂອງ APS ເຊັ່ນ Execution Ticket ແນະນຳກົນໄກທີ່ຜູ້ກວດສອບຊັ້ນຄວາມເຫັນດີເຫັນພ້ອມກໍ່ສ້າງ Inclusion Lists ເປັນສ່ວນຫນຶ່ງຂອງ beacon block. ບັນຊີລາຍຊື່ເຫຼົ່ານີ້ຫຼັງຈາກນັ້ນເຮັດຫນ້າທີ່ເປັນພື້ນຖານສໍາລັບຜູ້ສະເຫນີການປະຕິບັດການກໍ່ສ້າງແລະສະເຫນີຕັນເຕັມ. ສະຫລຸບລວມແລ້ວ, ການແກ້ໄຂການຕໍ່ຕ້ານການເຊັນເຊີທີ່ອີງໃສ່ລາຍການລວມເຂົ້າສອດຄ່ອງກັບວິໄສທັດຂອງ Ethereum ສໍາລັບ APS. ດັ່ງນັ້ນ, FOCIL ຖືກພິຈາລະນາເປັນຫນຶ່ງໃນວິທີແກ້ໄຂທີ່ໂດດເດັ່ນທີ່ສຸດສໍາລັບການຕໍ່ຕ້ານການເຊັນເຊີ. ຂໍ້ດີຂອງ FOCIL FOCIL ຮັບປະກັນການຕໍ່ຕ້ານ censorship ທີ່ມີປະສິດທິພາບໃນຂະນະທີ່ຮັກສາການນໍາໃຊ້ຊັບພະຍາກອນເຄືອຂ່າຍໃນລະດັບທີ່ສົມເຫດສົມຜົນໂດຍການຈໍາກັດແຕ່ລະ IL ກັບ 8KB ແລະມີຄະນະກໍາມະການ IL ຂອງ 16 validators (ເຊິ່ງເທົ່າກັບຂະຫນາດຂອງຫນຶ່ງ blob). ຕາຕະລາງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນໄລຍະເວລາທີ່ມັນໃຊ້ເວລາສໍາລັບການເຮັດທຸລະກໍາທີ່ຈະລວມຢູ່ໃນລະບົບຕ່ອງໂສ້, ຂຶ້ນກັບອັດຕາສ່ວນຂອງຜູ້ກວດສອບທີ່ຊື່ສັດໃນຄະນະກໍາມະການ IL. ເຖິງແມ່ນວ່າພຽງແຕ່ 15% ຂອງຜູ້ກວດສອບໃນຄະນະກໍາມະການແມ່ນບໍ່ censoring, ການເຮັດທຸລະກໍາຍັງສາມາດຖືກລວມເຂົ້າໃນທັນທີ. ນີ້ສະແດງໃຫ້ເຫັນເຖິງວິທີທີ່ຄະນະກໍາມະການຂະຫນາດນ້ອຍຂອງ 16 ຜູ້ກວດສອບສາມາດບັນລຸການຕໍ່ຕ້ານການເຊັນເຊີທີ່ມີປະສິດທິພາບ. ການແກ້ໄຂທີ່ເປັນໄປໄດ້ 2: ຜູ້ສະເໜີ/ຜູ້ສ້າງພ້ອມກັນຫຼາຍອັນ ແນວໃດກ່ຽວກັບການເຮັດໃຫ້ຜູ້ເຂົ້າຮ່ວມຫຼາຍຄົນສະເຫນີບລັອກທັງຫມົດຮ່ວມກັນ? ແນວຄວາມຄິດນີ້ຖືກເອີ້ນວ່າ "ຜູ້ສະເຫນີທີ່ສອດຄ່ອງຫຼາຍ". ແທນທີ່ຈະເປັນຫົວໜ່ວຍດຽວທີ່ສະເໜີບລັອກຕໍ່ຄັ້ງ, ຫຼາຍຫົວໜ່ວຍສະເໜີບລັອກພ້ອມກັນສຳລັບຊ່ອງດຽວກັນ. ພາຍໃຕ້ເງື່ອນໄຂສະເພາະໃດຫນຶ່ງ, ການຮັບຮອງເອົາການແກ້ໄຂດັ່ງກ່າວສາມາດເພີ່ມຄ່າໃຊ້ຈ່າຍຂອງ censorship ຢ່າງຫຼວງຫຼາຍ. Ethereum ມີກົນໄກທີ່ຜູ້ສະເຫນີ 32 ຕັນໃນແຕ່ລະຍຸກໄດ້ຖືກເປີດເຜີຍພ້ອມໆກັນ. ການຕັ້ງຄ່ານີ້ອະນຸຍາດໃຫ້ມີສະຖານະການທີ່ຜູ້ໃດຜູ້ຫນຶ່ງສາມາດພະຍາຍາມ "ໃຫ້ສິນບົນ" ຜູ້ສະເຫນີເພື່ອເຊັນເຊີການເຮັດທຸລະກໍາສະເພາະ. ແຕ່ຈະເປັນແນວໃດຖ້າບລັອກບໍ່ໄດ້ຖືກສະເຫນີໂດຍຄົນດຽວແຕ່ໂດຍ N proposers ພ້ອມກັນ? ໃນສະຖານະການນີ້, ການໃຊ້ກົນໄກເຊັ່ນຄໍາແນະນໍາທີ່ມີເງື່ອນໄຂເຮັດໃຫ້ມັນເປັນໄປໄດ້ທີ່ຈະແນະນໍາ "ບັນຫານັກໂທດ" ໃນບັນດາຜູ້ສະເຫນີ N, ດັ່ງນັ້ນການເພີ່ມຄ່າໃຊ້ຈ່າຍຂອງການເຊັນເຊີ. ຕົວຢ່າງ, ຈິນຕະນາການສະຖານະການທີ່ N proposers ຖືກມອບຫມາຍໃຫ້ສ້າງບລັອກ, Alice ຮຽກຮ້ອງໃຫ້ພວກເຂົາລວມເອົາທຸລະກໍາຂອງນາງ, ແລະ Bob ກໍາລັງພະຍາຍາມ censor ທຸລະກໍາຂອງ Alice. Alice ສາມາດໃຫ້ສິນບົນກັບຜູ້ສະເຫນີສໍາລັບການລວມເອົາທຸລະກໍາຂອງນາງ, ໃນຂະນະທີ່ Bob ຍັງສາມາດໃຫ້ສິນບົນໃຫ້ເຂົາເຈົ້າເພື່ອ censor ມັນ. ໃນສະຖານະການນີ້, Alice ສາມາດຮັບຮອງເອົາຍຸດທະສາດການໃຫ້ສິນບົນທີ່ເພີ່ມຄ່າໃຊ້ຈ່າຍຂອງ censorship ຂອງ Bob, ດັ່ງນີ້: ຖ້າຜູ້ສະເຫນີສອງຄົນຫຼືຫຼາຍກວ່ານັ້ນປະກອບມີການເຮັດທຸລະກໍາ, Alice ໃຫ້ຄໍາແນະນໍານ້ອຍໆຂອງ t ໃຫ້ກັບພວກເຂົາແຕ່ລະຄົນ. ຖ້າຜູ້ສະເຫນີພຽງແຕ່ຄົນດຽວປະກອບມີການເຮັດທຸລະກໍາ, Alice ໃຫ້ຄໍາແນະນໍາຂະຫນາດໃຫຍ່ຂອງ T ໃຫ້ກັບຜູ້ສະເຫນີນັ້ນ. ໃນກໍລະນີນີ້, ຜູ້ສະເຫນີເຫັນວ່າຕົນເອງຢູ່ໃນສະຖານະການຄ້າຍຄື "ສະຖານະການຂອງນັກໂທດ". ຍຸດທະສາດທີ່ດີທີ່ສຸດສໍາລັບຜູ້ສະເຫນີແຕ່ລະຄົນໃນເກມນີ້ແມ່ນການລວມເອົາທຸລະກໍາແທນທີ່ຈະເຊັນເຊີມັນ. ສໍາລັບ Bob ເພື່ອ censor ການເຮັດທຸລະກໍາຂອງ Alice ສົບຜົນສໍາເລັດ, ລາວຈະຕ້ອງໃຫ້ສິນບົນຜູ້ສະເຫນີ N ທັງຫມົດ, ຄ່າໃຊ້ຈ່າຍຂອງລາວ NT. ໃນອີກດ້ານຫນຶ່ງ, Alice ພຽງແຕ່ຕ້ອງການໃຊ້ເວລາຫຼາຍທີ່ສຸດ Nt ເພື່ອຮັບປະກັນການເຮັດທຸລະກໍາຂອງນາງໄດ້ຖືກລວມເຂົ້າ. ອັນນີ້ເຮັດໃຫ້ຄ່າໃຊ້ຈ່າຍໃນການເຊັນເຊີເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ແນວຄວາມຄິດນີ້ສາມາດຖືກປະຕິບັດຢູ່ເທິງສຸດຂອງ PBS ໃນຫຼາຍວິທີ. ຍົກຕົວຢ່າງ, ຜູ້ສະ ເໜີ ຫຼາຍຄົນສາມາດສ້າງທ່ອນໄມ້ພ້ອມໆກັນ, ຫຼືຜູ້ກໍ່ສ້າງຫຼາຍຄົນສາມາດສ້າງທ່ອນໄມ້ພ້ອມກັນ. ພາກນີ້ແນະນໍາສອງກົນໄກເພື່ອບັນລຸນີ້ພາຍໃນໂຄງສ້າງ PBS: BRAID - ຜູ້ສະເໜີພ້ອມກັນຫຼາຍອັນ BuilderNet - ຫຼາຍຕົວສ້າງພ້ອມກັນ ມັດ ພາບລວມຂອງ BRAID BRAID ແມ່ນການແກ້ໄຂຕ້ານການເຊັນເຊີ Ethereum ທີ່ສະເຫນີໂດຍ Max Resnick, ຜູ້ທີ່ເປັນສ່ວນຫນຶ່ງຂອງກຸ່ມກົນໄກພິເສດ. ກົນໄກແມ່ນອີງໃສ່ແນວຄວາມຄິດທີ່ງ່າຍດາຍແຕ່ມີອໍານາດ: ແທນທີ່ຈະດໍາເນີນການລະບົບຕ່ອງໂສ້ດຽວທີ່ Ethereum ເຮັດໃນປັດຈຸບັນ, k synchronized LMD-GHOST chains ຈະດໍາເນີນການຂະຫນານ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ດ້ວຍ BRAID, ຜູ້ສະເຫນີ k ພ້ອມກັນຜະລິດຕັນຂອງຕົນເອງສໍາລັບແຕ່ລະຊ່ອງ. BRAID ເຮັດວຽກແນວໃດ ຄໍາຖາມທີ່ຊັດເຈນເກີດຂື້ນ: k blocks ຖືກປຸງແຕ່ງແນວໃດ? ເນື່ອງຈາກທ່ອນໄມ້ໃນທີ່ສຸດຕ້ອງຖືກລວມເຂົ້າເປັນອັນດຽວເພື່ອຮັກສາ blockchain ດຽວ, BRAID ໃຊ້ກົດລະບຽບການສັ່ງຊື້ທີ່ກໍານົດໄວ້ກ່ອນເພື່ອລວມພວກມັນ. ຕົວຢ່າງ, ຕັນສາມາດຖືກລວມເຂົ້າກັນໂດຍການເອົາສິ່ງທີ່ຊ້ໍາກັນແລະຈັດລຽງທຸລະກໍາຕາມລໍາດັບຈາກໃຫຍ່ຫານ້ອຍຂອງຄ່າທໍານຽມ. ຫຼັງຈາກນັ້ນ, ຕັນສຸດທ້າຍຈະປະກອບດ້ວຍທຸລະກໍາລວມ, ຄໍາສັ່ງ. ຂໍ້ໄດ້ປຽບ & ຂໍ້ຈໍາກັດ BRAID ສະເໜີຂໍ້ດີຫຼາຍຢ່າງ: ການຕໍ່ຕ້ານການເຊັນເຊີທີ່ເຂັ້ມແຂງ ໂດຍການເຮັດໃຫ້ຜູ້ສະເໜີຫຼາຍຄົນເຮັດວຽກພ້ອມກັນ, BRAID ຈະເພີ່ມຄ່າໃຊ້ຈ່າຍໃນການເຊັນເຊີຢ່າງຫຼວງຫຼາຍ, ຍ້ອນວ່າຫຼາຍໜ່ວຍງານຈະຕ້ອງຖືກໃຫ້ສິນບົນ. ການສັ່ງຊື້ການບັງຄັບໃຊ້ ກົນໄກການກໍານົດການສັ່ງຊື້ທຸລະກໍາຢ່າງຊັດເຈນ, ເຮັດໃຫ້ມັນເຫມາະສົມສໍາລັບຄໍາຮ້ອງສະຫມັກເຊັ່ນການປະມູນໃນລະບົບຕ່ອງໂສ້ໃນເວລາທີ່ແທ້ຈິງທີ່ມີຄວາມອ່ອນໄຫວຕໍ່ກັບຄໍາສັ່ງການເຮັດທຸລະກໍາ. ກະລຸນາຮັບຊາບວ່ານີ້ບໍ່ແມ່ນຂໍ້ໄດ້ປຽບສະເໝີໄປ ເພາະມັນປ້ອງກັນບໍ່ໃຫ້ບາງແອັບພລິເຄຊັນປະຕິບັດກົດລະບຽບການຈັດລໍາດັບສະເພາະແອັບຯຂອງເຂົາເຈົ້າ. ຢ່າງໃດກໍຕາມ, BRAID ຍັງມີຂໍ້ຈໍາກັດ. ເນື່ອງຈາກຕ່ອງໂສ້ k ທັງໝົດຕ້ອງຖືກ synchronized, validators ຕ້ອງການຊັບພະຍາກອນເຄືອຂ່າຍເພີ່ມເຕີມ. ນີ້ຕໍ່ກັບເປົ້າຫມາຍຂອງ Ethereum ໃນການຫຼຸດຜ່ອນຄວາມຕ້ອງການຜູ້ກວດສອບ. BuilderNet ພາບລວມຂອງ BuilderNet BuilderNet ແມ່ນການແກ້ໄຂທີ່ສະເຫນີໂດຍ Flashbots ເພື່ອເພີ່ມຄວາມຕ້ານທານກັບ censorship ໂດຍອະນຸຍາດໃຫ້ຫຼາຍຫນ່ວຍງານເຮັດຫນ້າທີ່ເປັນຜູ້ສ້າງຕັນພ້ອມໆກັນ. ຮຸ່ນເບື້ອງຕົ້ນຂອງ BuilderNet ປະຕິບັດແບບຈໍາລອງຫຼາຍຕົວປະຕິບັດການ, ບ່ອນທີ່ຫຼາຍຫນ່ວຍງານປະຕິບັດຕົວສ້າງດຽວປະຕິບັດຕາມຄໍາແນະນໍາກົດລະບຽບທີ່ແຕກຕ່າງກັນ. ນີ້ຮັບປະກັນຄວາມຕ້ານທານການເຊັນເຊີທີ່ສູງກວ່າເມື່ອທຽບກັບຜູ້ກໍ່ສ້າງຜູ້ປະຕິບັດງານດຽວ. BuilderNet ເປັນຕົວແທນບາດກ້າວໄປສູ່ການສ້າງການແກ້ໄຂ Builder ພ້ອມກັນຫຼາຍອັນ. ການປ່ອຍຕົວທໍາອິດຂອງ BuilderNet ແມ່ນດໍາເນີນການຮ່ວມກັນໂດຍ Flashbots, Beaverbuild, ແລະ Nethermind, ແລະມີແຜນການທີ່ຈະສ້າງຜູ້ສ້າງຕື່ມອີກໃນອະນາຄົດ. ແຜນການກະຈາຍອໍານາດໃນອະນາຄົດສໍາລັບ BuilderNet ຮູບແບບ multi-operator ໃນປັດຈຸບັນຍັງປາກົດເປັນ builder ດຽວກັບຜູ້ສັງເກດການພາຍນອກ, ຈໍາກັດລະດັບຂອງການຕໍ່ຕ້ານ censorship ມັນສາມາດບັນລຸໄດ້. ການປ່ອຍຕົວໃນອະນາຄົດຂອງ BuilderNet ມີຈຸດປະສົງເພື່ອກະຈາຍເຄືອຂ່າຍຂອງຕົນຕື່ມອີກແລະເສີມຂະຫຍາຍການຕໍ່ຕ້ານການເຊັນເຊີໂດຍຜ່ານການປ່ຽນແປງຕໍ່ໄປນີ້: ການແບ່ງປັນ Orderflow ລະຫວ່າງຜູ້ກໍ່ສ້າງ ລຸ້ນ BuilderNet ໃນອະນາຄົດຈະແບ່ງຂັ້ນຄຸ້ມຄອງຂະບວນການສ້າງບລັອກ, ອະນຸຍາດໃຫ້ຜູ້ກໍ່ສ້າງຄົນຫນຶ່ງສາມາດເອົາທຸລະກໍາທີ່ຖືກເຊັນເຊີໂດຍຜູ້ສ້າງອື່ນ. ໃນທາງທິດສະດີ, ຕາບໃດທີ່ຢ່າງຫນ້ອຍຫນຶ່ງຕົວສ້າງທີ່ບໍ່ censoring ມີ, ທຸລະກໍາຂອງຜູ້ໃຊ້ທັງຫມົດຍັງສາມາດຖືກລວມເຂົ້າໃນບລັອກ. ວິທີການນີ້ຄາດວ່າຈະພັດທະນາ BuilderNet ເຂົ້າໄປໃນຕົວແບບ Multiple Concurrent Builder ທີ່ແທ້ຈິງ. ໂຄງສ້າງພື້ນຖານການແບ່ງຂັ້ນຄຸ້ມຄອງ ສະບັບປະຈຸບັນຂອງ BuilderNet ອີງໃສ່ໂຄງສ້າງພື້ນຖານທີ່ເປັນສູນກາງສໍາລັບທຸລະກໍາ ingress ແລະການເກັບຮັກສາຂໍ້ມູນ, ແລະການມີສ່ວນຮ່ວມຮຽກຮ້ອງໃຫ້ມີການອະນຸຍາດ. ຮຸ່ນໃນອະນາຄົດມີຈຸດປະສົງເພື່ອແກ້ໄຂບັນຫານີ້ໂດຍການເຮັດໃຫ້ BuilderNet ບໍ່ໄດ້ຮັບອະນຸຍາດ. TEE ສໍາລັບ UX & DX ທີ່ດີກວ່າ BuilderNet ຍັງສ້າງສະພາບແວດລ້ອມທີ່ເປັນມິດກັບຜູ້ໃຊ້ຫຼາຍຂຶ້ນສໍາລັບແອັບຯ, ກະເປົາເງິນ, ຜູ້ຄົ້ນຫາ, ແລະຜູ້ໃຊ້ໂດຍການໃຊ້ສະພາບແວດລ້ອມການປະຕິບັດທີ່ເຊື່ອຖືໄດ້. TEE ຮັບປະກັນວ່າຊອຟແວປະຕິບັດຕົວຕາມທີ່ລະບຸໄວ້ໂດຍອີງໃສ່ຄວາມໄວ້ວາງໃຈໃນຮາດແວ, ປ້ອງກັນຜູ້ສ້າງຈາກການລະງັບຂໍ້ມູນ ຫຼື ແກ້ໄຂລະຫັດໂດຍຕົນເອງ. ໂດຍການນໍາໃຊ້ BuilderNet, ຜູ້ຄົ້ນຫາໄດ້ຮັບການຮັບປະກັນທີ່ສູງຂຶ້ນເມື່ອສົ່ງຊຸດໃຫ້ກັບຜູ້ສ້າງ, ຍ້ອນວ່າ TEE ບັງຄັບການປະຕິບັດການແຈກຢາຍລາງວັນໃຫ້ກັບຜູ້ຄົ້ນຫາທີ່ປະກອບສ່ວນເຂົ້າໃນການກໍ່ສ້າງຕັນ. ຖ້າເຫດຜົນການແຈກຢາຍລາງວັນມີຄວາມຍຸຕິທໍາພຽງພໍ, ນີ້ຈະໃຫ້ຜູ້ຄົ້ນຫາມີການຮັບປະກັນທາງເສດຖະກິດທຽບກັບສັນຍາຢ່າງເປັນທາງການກັບຜູ້ກໍ່ສ້າງ. ນອກເຫນືອຈາກຜູ້ຄົ້ນຫາ, ແອັບຯແລະກະເປົາເງິນທີ່ມີຈຸດປະສົງເພື່ອເກັບກໍາ MEV ຍັງສາມາດໄດ້ຮັບຜົນປະໂຫຍດຈາກສະຖາປັດຕະຍະກໍາຂອງ BuilderNet. BuilderNet ໃນ L2s ລັກສະນະທີ່ຫນ້າສັງເກດຂອງ BuilderNet ແມ່ນຄວາມສາມາດທີ່ຈະນໍາໃຊ້ກັບ Layer 2 solutions. Ethereum L2s ກໍາລັງພັດທະນາລະບົບການພິສູດຢ່າງຈິງຈັງ ແລະສະຖາປັດຕະຍະກຳຜູ້ກວດສອບການກະຈາຍອຳນາດເພື່ອສືບທອດຄວາມປອດໄພຂອງ Ethereum. ໃນຂະນະທີ່ລະບົບເຫຼົ່ານີ້ຮັບປະກັນຄວາມປອດໄພຂອງກອງທຶນຜູ້ໃຊ້ໃນຂົວ, ພວກເຂົາບໍ່ໄດ້ສືບທອດການຕໍ່ຕ້ານການເຊັນເຊີຂອງ Ethereum. ກົນໄກການບັງຄັບສໍາລັບການເຮັດທຸລະກໍາ L1-to-L2 ໃນປັດຈຸບັນໃຊ້ເວລາຫຼາຍທີ່ສຸດ 12-24 ຊົ່ວໂມງ (ຂຶ້ນກັບການອອກແບບ) ເພື່ອປະກອບມີການເຮັດທຸລະກໍາໃນ L2, ເຊິ່ງບໍ່ສາມາດສະຫນອງການຕໍ່ຕ້ານການເຊັນເຊີໃນເວລາທີ່ແທ້ຈິງ. ໂດຍການສ້າງຕັນ outsourcing ກັບ BuilderNet, L2s ສາມາດບັນລຸການຕໍ່ຕ້ານ censorship ສູງກວ່າ sequencers ດຽວໃນຂະນະທີ່ເຮັດໃຫ້ການແຈກຢາຍ MEV ໂດຍຜ່ານການບັງຄັບໃຊ້ຄໍາສັ່ງທຸລະກໍາກັບ TEE, ຄ້າຍຄືກັນກັບສະຖາປັດຕະເຊັ່ນ Unichain. ສະຫຼຸບ ໂດຍຫລັກການແລ້ວ, blockchains ຄວນຕ້ານການ censorship, ແລະຊຸມຊົນ Ethereum ໄດ້ສະເຫນີວິທີແກ້ໄຂຕ່າງໆເພື່ອແກ້ໄຂບັນຫາການຕໍ່ຕ້ານ censorship ທີ່ເກີດຈາກການສູນກາງ builder. ໃນບັນດາວິທີແກ້ໄຂທີ່ໂດດເດັ່ນທີ່ສຸດແມ່ນ FOCIL, ບ່ອນທີ່ຜູ້ກວດສອບ 16 ຄົນສະເຫນີລາຍຊື່ລວມສໍາລັບແຕ່ລະຕັນ, ສະເຫນີການຕໍ່ຕ້ານ censorship ທີ່ມີປະສິດທິພາບແລະຄວາມເຂົ້າກັນໄດ້ກັບ APS. FOCIL ຄາດວ່າຈະໄດ້ຮັບການປຶກສາຫາລືສໍາລັບການລວມເຂົ້າໃນການຍົກລະດັບ Fusaka ທີ່ກໍານົດໃນທ້າຍປີ 2025 ຫຼືຕົ້ນປີ 2026. ພ້ອມກັນນັ້ນ, ການສົນທະນາກ່ຽວກັບຕົວແບບ Builder ພ້ອມກັນຫຼາຍອັນທີ່ນຳໂດຍ Flashbots ພວມດຳເນີນຢູ່. ຜູ້ສ້າງການແບ່ງຂັ້ນຄຸ້ມຄອງສາມາດປັບປຸງການຕໍ່ຕ້ານການເຊັນເຊີຂອງ Ethereum ຢ່າງຫຼວງຫຼາຍແລະສາມາດປະຕິບັດໄດ້ຢ່າງເປັນເອກະລາດຈາກການພັດທະນາ Ethereum ຫຼັກ, ອະນຸຍາດໃຫ້ມີການຮັບຮອງເອົາໄວຂຶ້ນ. ໂດຍຜ່ານການລິເລີ່ມເຫຼົ່ານີ້, Ethereum ມີຄວາມກ້າວຫນ້າຢ່າງຕໍ່ເນື່ອງໄປສູ່ຊັ້ນການປະຕິບັດທີ່ເປັນກາງທີ່ຫນ້າເຊື່ອຖື, ບ່ອນທີ່ບໍ່ມີຫນ່ວຍງານດຽວມີອິດທິພົນທີ່ບໍ່ສົມຄວນຕໍ່ການລວມເອົາທຸລະກໍາ. ໂດຍການລວມເອົາລາຍຊື່ລວມທີ່ຂັບເຄື່ອນໂດຍຜູ້ກວດສອບຂອງ FOCIL ກັບການກະຈາຍຕົວທີ່ມີທ່າແຮງຂອງຜູ້ສ້າງບລັອກ, Ethereum ສາມາດເພີ່ມຄວາມຢືດຢຸ່ນຕໍ່ກັບການເຊັນເຊີໃນຂະນະທີ່ຮັກສາປະສິດທິພາບແລະຄວາມຍຸຕິທໍາໃນການແຈກຢາຍ MEV. ໃນຂະນະທີ່ການແກ້ໄຂເຫຼົ່ານີ້ພັດທະນາ, ເຄືອຂ່າຍຍັງສືບຕໍ່ຮັກສາຫຼັກການຫຼັກຂອງຕົນໃນການແບ່ງຂັ້ນຄຸ້ມຄອງ, ການເຂົ້າເຖິງທີ່ບໍ່ໄດ້ຮັບອະນຸຍາດ, ແລະຄວາມເປັນກາງ, ຮັບປະກັນວ່າ Ethereum ຍັງຄົງເປັນຊັ້ນການຕັ້ງຖິ່ນຖານທີ່ເຂັ້ມແຂງແລະທົນທານຕໍ່ censorship ສໍາລັບອະນາຄົດ. ສະບັບຂອງບົດຄວາມນີ້ໄດ້ຖືກຈັດພີມມາໃນເບື້ອງຕົ້ນ . ທີ່ນີ້