ແມ່ນອົງປະກອບທີ່ສໍາຄັນຂອງໂຄງສ້າງພື້ນຖານຂອງ blockchain. ພວກເຂົາຈັດການການສື່ສານລະຫວ່າງບັນຊີລາຍການທີ່ບໍ່ປ່ຽນແປງໄດ້ແບບກະຈາຍແລະຄໍາຮ້ອງສະຫມັກດ້ານຫນ້າ. ໂຄງສ້າງພື້ນຖານຂອງຕົວກາງເຫຼົ່ານີ້ເຮັດຫນ້າທີ່ເປັນຜູ້ສົ່ງສານທີ່ອໍານວຍຄວາມສະດວກຕໍ່ການຮ້ອງຂໍແລະການຕອບສະຫນອງລະຫວ່າງ nodes ແລະການບໍລິການທີ່ສ້າງຂຶ້ນໃນ blockchain. RPC (Remote Procedure Call) Nodes ໂຫນດ RPC ແມ່ນຄືກັນກັບການບໍລິການໄປສະນີສະຫະລັດ (USPS), ເຊິ່ງອໍານວຍຄວາມສະດວກໃນການເຄື່ອນໄຫວຂອງຂໍ້ມູນຈາກ dApp ໄປຫາ blockchain ແລະກັບຄືນໄປບ່ອນ. ຄືກັນກັບທີ່ທ່ານອີງໃສ່ການບໍລິການໄປສະນີເພື່ອໃຫ້ໄດ້ຮັບເມລຂອງທ່ານຈາກຈຸດຫນຶ່ງໄປອີກ, dApps ແມ່ນຂຶ້ນກັບ RPC nodes ເພື່ອເຂົ້າເຖິງ blockchain. ແລະໂດຍບໍ່ມີຂໍ້ເຫຼົ່ານີ້, ຄໍາຮ້ອງສະຫມັກທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງຈະຕໍ່ສູ້ກັບການເຮັດວຽກ. nodes RPC ໄດ້ພັດທະນາຢ່າງຫຼວງຫຼາຍໃນໄລຍະ 10 ປີທີ່ຜ່ານມາ, ແຕ່ການລວມສູນຂອງໂຄງສ້າງພື້ນຖານໄດ້ນໍາສະເຫນີຈຸດອ່ອນທີ່ເຊື່ອງໄວ້. ບົດຄວາມນີ້ມີຈຸດປະສົງເພື່ອຄົ້ນຫາບົດບາດຂອງ RPC nodes, ອັນຕະລາຍຂອງການສູນກາງ, ແລະທາງເລືອກທີ່ສາມາດປົກປ້ອງ dApps ຂອງທ່ານຈາກຄວາມອ່ອນແອ. ວິວັດທະນາການຂອງໂຄງສ້າງພື້ນຖານ RPC ແນວຄວາມຄິດຂອງຂັ້ນຕອນການໂທຫາທາງໄກມີມາຕັ້ງແຕ່ປີ 1970 ເມື່ອນັກວິທະຍາສາດຄອມພິວເຕີຊອກຫາວິທີຕິດຕໍ່ສື່ສານລະຫວ່າງເຄື່ອງຈັກຕ່າງໆເພື່ອເຮັດໃຫ້ຄອມພິວເຕີແຈກຢາຍມີຄວາມໂປ່ງໃສຕໍ່ນັກພັດທະນາ. ໃນຊຸມປີ 1980, RPC ທໍາອິດໄດ້ຖືກພັດທະນາໂດຍ Sun Microsystem ເອີ້ນວ່າລະບົບໄຟລ໌ເຄືອຂ່າຍ. Sun Microsystem ພັດທະນາໂປໂຕຄອນ Open Network Computing RPC, ແລະນີ້ໄດ້ກາຍເປັນມາດຕະຖານສໍາລັບການສື່ສານລະຫວ່າງບັນດາໂຄງການຕ່າງໆໃນເຄືອຂ່າຍ. ຢ່າງໃດກໍຕາມ, ໃນຕົ້ນຊຸມປີ 1990, Microsoft ພັດທະນາແລະປະຕິບັດ RPC ຮຸ່ນຂອງຕົນເພື່ອໃຫ້ສາມາດສື່ສານລະຫວ່າງຂະບວນການໃນລະບົບທີ່ໃຊ້ Windows. ໃນຕົ້ນຊຸມປີ 2000, JSON RPC, ເຊິ່ງໃຊ້ JSON ສໍາລັບການເຂົ້າລະຫັດຂໍ້ມູນ, ໄດ້ຖືກນໍາສະເຫນີ. ມັນໄດ້ກາຍເປັນຊື່ສຽງໃນບັນດານັກພັດທະນາແລະນັກຂຽນໂປລແກລມຍ້ອນຄວາມງ່າຍໃນການໂອນຂໍ້ມູນມາດຕະຖານ. ໃນທົດສະວັດທີ່ຜ່ານມາ, dApps ໄດ້ກາຍເປັນສ່ວນຫນຶ່ງທີ່ສໍາຄັນຂອງອຸດສາຫະກໍາ blockchain ແລະ RPC ໄດ້ເປັນໂຄງສ້າງພື້ນຖານທີ່ສົມບູນແບບທີ່ຈໍາເປັນເພື່ອເຮັດສໍາເລັດ maze ໄດ້. ເປັນຫຍັງ? ຄວາມສາມາດຂອງຕົນໃນການໂທຫາຫນ້າທີ່ຫ່າງໄກສອກຫຼີກໃນຄອມພິວເຕີອື່ນເຊັ່ນການໂທຫາຫນ້າທີ່ທ້ອງຖິ່ນແມ່ນດີເລີດສໍາລັບສະຖາປັດຕະ blockchain. ຄວາມບໍ່ມີລັດແລະນ້ໍາຫນັກເບົາຂອງມັນໃຫ້ອໍານາດ blockchain ແລະເປັນປະໂຫຍດໃນສະຖານະການຈໍາກັດແບນວິດແລະຄອມພິວເຕີ້. ເນື່ອງຈາກຜົນປະໂຫຍດ, RPC ໄດ້ຖືກນໍາໃຊ້ຢ່າງກວ້າງຂວາງຢ່າງໄວວາ. RPC ໄດ້ຖືກສະເຫນີໃຫ້ເປີດໃຊ້ຄໍາຮ້ອງສະຫມັກທີ່ຂຽນເປັນພາສາທີ່ແຕກຕ່າງກັນເພື່ອເຊື່ອມຕໍ່ແລະຕິດຕໍ່ສື່ສານ. ແນວຄວາມຄິດພື້ນຖານທີ່ຢູ່ເບື້ອງຫລັງ RPC ແມ່ນການໂທຫາຫນ້າທີ່ຫ່າງໄກສອກຫຼີກໃນຄອມພິວເຕີຫຼືເຄື່ອງແມ່ຂ່າຍອື່ນຄືກັບວ່າມັນເປັນການໂທຫາຫນ້າທີ່ທ້ອງຖິ່ນ. ໃນຊຸມປີມໍ່ໆມານີ້, ມີສາມປະເພດຕົ້ນຕໍຂອງ RPCs (Centralized, Decentralized, ແລະ Self-Hosted) ແລະແຕ່ລະຄົນແມ່ນເປັນເອກະລັກຂອງມັນ. ອັນຕະລາຍຂອງຈຸດສູນກາງ RPC ໂຫນດ RPC ສູນກາງແມ່ນ nodes ທີ່ຖືກຄຸ້ມຄອງແລະຄວບຄຸມໂດຍຫນ່ວຍງານດຽວ. ໂຫນດທີ່ເປັນສູນກາງເຫຼົ່ານີ້ມີຕົວແບບທີ່ຄ້າຍຄືກັບບໍລິການໂຮດຕິ້ງຄລາວຂອງ web2 ເຊັ່ນ AWS (Amazon Web Services), Microsoft Azure, ແລະ Google Cloud Protocol (GCP). ເຖິງແມ່ນວ່າຜູ້ໃຫ້ບໍລິການ web3 RPC ທີ່ເປັນສູນກາງເຫຼົ່ານີ້ຮັກສາໂຄງສ້າງພື້ນຖານຂອງ node ສໍາລັບຄໍາຮ້ອງສະຫມັກທີ່ມີການແບ່ງສ່ວນ, ການເບິ່ງເລິກເຂົ້າໄປໃນລະບົບໄດ້ເປີດເຜີຍວ່າພວກເຂົາເປັນສູນກາງແນວໃດ. ຜູ້ໃຫ້ບໍລິການພື້ນຖານໂຄງລ່າງຂອງ web3 ເຫຼົ່ານີ້ແມ່ນທາດເຫຼັກທີ່ຂຶ້ນກັບໂຄງສ້າງພື້ນຖານຂອງເຄື່ອງແມ່ຂ່າຍ web2 cloud hosting ເພື່ອຮັກສາການບໍລິການຂອງພວກເຂົາ. ດັ່ງນັ້ນ, ເມື່ອຜູ້ໃຫ້ບໍລິການຟັງເຫຼົ່ານີ້ປະສົບກັບບັນຫາການຢຸດງານ, ການບໍລິການ web3, ເຊິ່ງຫມາຍເຖິງການແບ່ງຂັ້ນຄຸ້ມຄອງ, ຍັງປະສົບກັບເວລາຢຸດເຮັດວຽກ. ນີ້ແມ່ນຕົວຢ່າງຂອງຈຸດສູນກາງ RPC: Alchemy, Infura, Quicknode, ແລະອື່ນໆ. ໃຫ້ກວດເບິ່ງອັນຕະລາຍທີ່ເກີດຈາກຈຸດສູນກາງ RPC ກັບໂຄງສ້າງພື້ນຖານຂອງ web3. ມີຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວສະເຫມີຜົນກະທົບຕໍ່ຄວາມຫນ້າເຊື່ອຖືຂອງລະບົບ. ເຄື່ອງແມ່ຂ່າຍດຽວຫຼືເຄືອຂ່າຍຂອງເຄື່ອງແມ່ຂ່າຍທີ່ຄວບຄຸມໂດຍຫນ່ວຍງານດຽວຈະແນະນໍາຈຸດສໍາຄັນທີ່ສາມາດນໍາໄປສູ່ຄວາມລົ້ມເຫຼວຂອງ dApp ຂອງທ່ານ. ຈຸດດຽວຂອງຄວາມລົ້ມເຫລວ: ຖ້າເຄື່ອງແມ່ຂ່າຍຂໍ້ມູນຖືກສົ່ງຜ່ານລົ້ມເຫລວ, ການເຊື່ອມຕໍ່ລະຫວ່າງ blockchain ແລະ dApp ຈະແຕກຫັກແລະລະບົບລົ້ມເຫລວ. ຈຸດດຽວຂອງຄວາມລົ້ມເຫລວຈະສົ່ງຜົນກະທົບຕໍ່ຄວາມຫນ້າເຊື່ອຖືຂອງລະບົບໂດຍສະເພາະໃນແອັບຯທີ່ກ່ຽວຂ້ອງກັບການເງິນເຊັ່ນ: ເວທີ DeFi. : ໂນດ RPC ສູນກາງສາມາດກາຍເປັນຂໍ້ບົກຜ່ອງໃນຊ່ວງເວລາທີ່ມີການຈະລາຈອນສູງ ແລະນີ້ຈຳກັດການຂະຫຍາຍຂອງ dApp. ເມື່ອເຄືອຂ່າຍມີຄວາມແອອັດເນື່ອງຈາກການເອື່ອຍອີງຢູ່ໃນໂຫນດດຽວ, ມັນມີຜົນກະທົບຕໍ່ປະສິດທິພາບຂອງ dApps ແລະເພີ່ມຄວາມລ່າຊ້າ, ເຊິ່ງຜົນກະທົບຕໍ່ຜູ້ໃຊ້. ບັນຫາການຂະຫຍາຍຂະໜາດ ເນື່ອງຈາກວ່າມັນເປັນລະບົບສູນກາງ, ການເພີ່ມຂະຫນາດຂອງ dApp ແມ່ນເປັນໄປບໍ່ໄດ້. ໂນດທີ່ເປັນສູນກາງ ຫຼື ສະເພາະແມ່ນເປີດໃຫ້ມີຄວາມສ່ຽງ ແລະ ສາມາດເປັນເປົ້າໝາຍທີ່ງ່າຍສຳລັບບຸກຄົນທີ່ບໍ່ມີສະຕິປັນຍາ. ຂໍ້ມູນສາມາດຖືກເປີດເຜີຍ ແລະຈັດການໄດ້, ແລະໃນທີ່ສຸດຜົນກະທົບຕໍ່ການຕັດສິນໃຈໃນ dApps. ຄວາມສ່ຽງດ້ານຄວາມປອດໄພ ແລະ ຄວາມອ່ອນແອ: ຍິ່ງໄປກວ່ານັ້ນ, ການໂຈມຕີປະສານງານກັບຜູ້ໃຫ້ບໍລິການຍັງສາມາດປະຕິບັດໄດ້ງ່າຍ, ໃນທີ່ສຸດກໍ່ເປີດເຜີຍຜູ້ໃຊ້ Dapp. ໜ່ວຍງານດຽວສາມາດບັງຄັບໃຫ້ໜ່ວຍງານລັດຖະບານປິດແອັບພລິເຄຊັນໄດ້. ນີ້ແມ່ນຕົວຢ່າງ: ໃນປີ 2022, MetaMask ຖືກກ່າວຫາວ່າໄດ້ຂັດຂວາງຜູ້ໃຊ້ທີ່ມີທີ່ຢູ່ IP ຂອງເວເນຊູເອລາແລະອີຣ່ານຈາກການເຮັດທຸລະກໍາໃນ blockchain. ອັນນີ້ເປັນໄປໄດ້ເນື່ອງຈາກ RPC ສູນກາງ (Infura) ທີ່ໃຊ້ໂດຍ web3 wallet. ກໍລະນີສຶກສາຂອງສູນກາງ RPC Nodes ລົ້ມເຫລວ ແລະຊ່ອງໂຫວ່ Centralized RPC ອາດຈະເບິ່ງຄືວ່າພວກເຂົາປອດໄພແຕ່ພວກເຂົາບໍ່ແມ່ນ. ຢ່າງໃດກໍຕາມ, ໃນຄວາມສົງໃສກ່ຽວກັບເລື່ອງນີ້, ໃຫ້ກວດເບິ່ງບາງກໍລະນີສຶກສາກ່ຽວກັບຄວາມລົ້ມເຫຼວທີ່ຜ່ານມາຂອງ RPCs ສູນກາງ. ກໍລະນີຂອງ Infura ແມ່ນຫນຶ່ງໃນບັນດາຜູ້ໃຫ້ບໍລິການ Blockchain Backend Infrastructure as a Service (IaaS) ທໍາອິດໃນ web3, ນໍາມາໃຫ້ທ່ານໂດຍຄວາມເຫັນດີນໍາ. ໂຄງສ້າງພື້ນຖານໄດ້ຖືກອ້າງວ່າສາມາດໃຊ້ໄດ້ສໍາລັບ 99.9% uptime ແລະສາມາດໃຊ້ໄດ້ກັບ 16 blockchain EVMs. Infura ຈົນກ່ວາ 2020, Infura ໄດ້ຖືກພິຈາລະນາເປັນວິລະຊົນ, ເປັນຫນຶ່ງໃນຊາຍແດນສໍາລັບການພັດທະນາ dApp ແລະນໍາພາການຮັບຮອງເອົາມະຫາຊົນຂອງ crypto / blockchain. ໃນວັນທີ 11 ພະຈິກ 2020, Infura ປະສົບກັບການບໍລິການຂັດຂວາງເນື່ອງຈາກມີຂໍ້ຜິດພາດທີ່ມີຜົນກະທົບກັບເວີຊັນຂອງ GEth ທີ່ດໍາເນີນການໂດຍ Infura. ບັນຫາຕົ້ນຕໍຢູ່ທີ່ນີ້ແມ່ນວ່າລະບົບ Infura ຫຼຸດລົງແລະຜູ້ໃຊ້ພື້ນຖານໂຄງລ່າງ Infura ທັງຫມົດບໍ່ສາມາດເຊື່ອມຕໍ່ກັບ blockchain ໄດ້. ເຊີບເວີຖືກລົບກວນເນື່ອງຈາກມີຂໍ້ບົກພ່ອງ, ແລະຄວາມສ່ຽງຂອງການເປັນສູນກາງຢູ່ເບື້ອງຫຼັງເຄືອຂ່າຍທີ່ມີການແບ່ງແຍກໄດ້ຖືກເປີດເຜີຍ. Metamask, ກະເປົາເງິນ Ethereum ທີ່ປະເຊີນກັບຜູ້ບໍລິໂພກທີ່ໃຫຍ່ທີ່ສຸດທີ່ມີຜູ້ໃຊ້ຫຼາຍລ້ານຄົນຖືກລົບກວນ. ທັງຫມົດຍ້ອນວ່າພວກເຂົາອີງໃສ່ Infura, ຜູ້ໃຫ້ບໍລິການ RPC ສູນກາງ. ຄວາມກັງວົນສູນກາງໃນລະຫວ່າງການປັບປຸງເຄືອຂ່າຍ ໃນລະຫວ່າງການຍົກລະດັບເຄືອຂ່າຍ / hardforks, ປົກກະຕິແລ້ວມີຄວາມກັງວົນກ່ຽວກັບຄວາມລົ້ມເຫຼວຂອງການບໍລິການໂດຍສະເພາະກ່ຽວກັບ dAapps ທີ່ອີງໃສ່ຜູ້ໃຫ້ບໍລິການພື້ນຖານໂຄງລ່າງສູນກາງ. ຄວາມກັງວົນເຫຼົ່ານີ້ລວມມີ: ຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວ, ຊຶ່ງສາມາດລົບກວນກິດຈະກໍາແລະນໍາໄປສູ່ການ downtime. ນີ້ແມ່ນບາງຕົວຢ່າງທີ່ຜ່ານມາ: ໃນລະຫວ່າງ , ຜູ້ໃຫ້ບໍລິການ RPC ສູນກາງຈໍານວນຫຼາຍປະສົບກັບເວລາຢຸດເຮັດວຽກ. ບາງສ່ວນຂອງການ downtime ເຫຼົ່ານີ້ແມ່ນເປັນຜົນມາຈາກເຄືອຂ່າຍໂດຍຜ່ານການຍົກລະດັບ. ແອັບ DeFi ບໍ່ສາມາດປະມວນຜົນທຸລະກຳໄດ້, ເຮັດໃຫ້ຜູ້ໃຊ້ຢູ່ໃນຂອບເຂດ. Ethereum Istanbul hardfork ໃນປີ 2019 ໃນລະຫວ່າງ , ຜູ້ໃຫ້ບໍລິການ RPC ປະເຊີນກັບບັນຫາການເຊື່ອມຕໍ່ແລະບໍ່ໄດ້ synchronized ກັບເຄືອຂ່າຍ blockchain. ຜູ້ໃຊ້ບໍ່ສາມາດເຂົ້າເຖິງ DeFi dApps ເປັນເວລາຫຼາຍຊົ່ວໂມງ, ດັ່ງນັ້ນ, ການເຮັດທຸລະກໍາແມ່ນຊັກຊ້າຫຼືລົ້ມເຫລວ. ການຍົກລະດັບ Polygon Heimdall Solana RPC Overload ໃນປີ 2021 ປະສົບກັບບັນຫາທີ່ເກີດຂື້ນຫຼາຍຄັ້ງໃນປີ 2021. ຫນຶ່ງໃນຄວາມບໍ່ຊື່ສັດແມ່ນເກີດມາຈາກການໂຫຼດເກີນຂອງການບໍລິການ RPC ສູນກາງໃນຊ່ວງເວລາສູງສຸດ. ໃນຂະນະທີ່ຂໍ້ບົກຜ່ອງຂອງສາທາລະນະໄດ້ຄອບຄຸມ, ຜູ້ໃຊ້ບໍ່ສາມາດພົວພັນກັບ Solana Blockchain ເປັນເວລາຫຼາຍຊົ່ວໂມງແລະເຄືອຂ່າຍໄດ້ປະເຊີນກັບການຢຸດເຊົາການບໍລິການເຕັມເວລາຫຼາຍຊົ່ວໂມງ. Solana ກໍລະນີເຫຼົ່ານີ້ຂອງ facepalms ແລະອື່ນ ໆ countless ເປີດເຜີຍຄວາມສໍາຄັນຂອງຜູ້ໃຫ້ບໍລິການ RPC ກັບຜົນປະໂຫຍດ blockchain. ໃນຂະນະທີ່ຜູ້ໃຫ້ບໍລິການສູນກາງຍັງຖືກນໍາໃຊ້ໂດຍ dApps ຈໍານວນຫຼາຍ (ອາດຈະອອກຈາກຄວາມບໍ່ຮູ້ຫຼືຄວາມຄິດທີ່ບໍ່ມີຄວາມຄິດ), ໃນໄລຍະປີທີ່ຜ່ານມາມີທາງເລືອກອື່ນ. ໃນພາກຕໍ່ໄປ, ພວກເຮົາຈະນໍາທ່ານຜ່ານທາງເລືອກອື່ນແລະວິທີທີ່ພວກເຂົາເປັນທາງເລືອກທີ່ດີສໍາລັບການພັດທະນາ blockchain. Decentralizing DApp ຂອງທ່ານ: ທາງເລືອກດ້ານເທິງເພື່ອ Centralized RPC Nodes Nodes RPC ທີ່ເປັນເຈົ້າພາບດ້ວຍຕົນເອງ ດັ່ງທີ່ຊື່ຂອງມັນຫມາຍເຖິງ, ໂຫນດ RPC ທີ່ໂຮດເອງແມ່ນ nodes ທີ່ທ່ານເປັນເຈົ້າພາບຫຼືຈັດການໃນຮາດແວຫຼືໂຄງສ້າງຄລາວຂອງທ່ານເອງ. ແທນທີ່ຈະອີງໃສ່ຜູ້ໃຫ້ບໍລິການ RPC ພາກສ່ວນທີສາມ, ທ່ານສາມາດເປັນເຈົ້າພາບ nodes RPC ຂອງທ່ານເອງ. ທ່ານສາມາດເຂົ້າເຖິງເຄືອຂ່າຍ blockchain ໂດຍກົງ, ກວດສອບການເຮັດທຸລະກໍາ, ສອບຖາມຂໍ້ມູນ blockchain ໂດຍກົງ, ແລະພົວພັນກັບ dApps. ຜົນປະໂຫຍດຂອງ Nodes RPC ທີ່ເປັນເຈົ້າພາບດ້ວຍຕົນເອງປະກອບມີ: : ແລ່ນ nodes ຂອງທ່ານຫມາຍຄວາມວ່າທ່ານມີການຄວບຄຸມຢ່າງເຕັມທີ່ກ່ຽວກັບການຕັ້ງຄ່າຂອງ nodes. ທ່ານສາມາດປັບຊອບແວໃຫ້ເຫມາະສົມກັບຄວາມຕ້ອງການຂອງທ່ານ, ນໍາໃຊ້ການປັບປຸງຕາມຄວາມຕັດສິນໃຈຂອງທ່ານ, ແລະການຄຸ້ມຄອງຄວາມປອດໄພ. Autonomy/Control : ທ່ານບໍ່ຈໍາເປັນຕ້ອງຊອກຫາການຢຸດການບໍລິການ, ຫຼືຄວາມລົ້ມເຫລວເນື່ອງຈາກບັນຫາຂອງຜູ້ໃຫ້ບໍລິການ, ທົ່ວໄປຂອງພາກສ່ວນທີສາມ nodes ສູນກາງ. ຄວາມຫນ້າເຊື່ອຖື : ແລ່ນ nodes ໃນໂຄງສ້າງພື້ນຖານຂອງທ່ານຫມາຍຄວາມວ່າທ່ານມີຄວາມຮັບຜິດຊອບສໍາລັບການບໍລິການຂອງເຂົາເຈົ້າ, ທ່ານມີການເຂົ້າເຖິງ latency ຕ່ໍາກັບເຄືອຂ່າຍ blockchain. ການເຂົ້າເຖິງເຄືອຂ່າຍໂດຍກົງ ໃນຂະນະທີ່ຂໍ້ທີ່ຕົນເອງເປັນເຈົ້າພາບເບິ່ງຄືວ່າມີຄວາມຫນ້າເຊື່ອຖືຫຼາຍກ່ວາທາງເລືອກທີ່ເປັນສູນກາງຂອງພວກເຂົາ, ພວກເຂົາມີຂໍ້ເສຍຂອງພວກເຂົາ. ແລະນີ້ພວກເຂົາເຈົ້າແມ່ນ: . ການເປັນເຈົ້າພາບ node RPC ຕ້ອງການພື້ນທີ່ດິດທີ່ສໍາຄັນເພື່ອເກັບຮັກສາປະຫວັດສາດ blockchain. ການເກັບຮັກສາ, ແບນວິດ, ແລະພະລັງງານການປຸງແຕ່ງທີ່ຈໍາເປັນເພື່ອດໍາເນີນການ nodes RPC ສາມາດ overwhelming. ຄວາມຕ້ອງການຊັບພະຍາກອນສູງ ຍິ່ງໄປກວ່ານັ້ນ, ທ່ານຕ້ອງການ synchronization ຄົງທີ່ກັບ blockchain, ແລະນີ້ສາມາດບໍລິໂພກແບນວິດເປັນຈໍານວນຫຼວງຫຼາຍທີ່ສາມາດ overwhelming. ພະລັງງານການປຸງແຕ່ງທີ່ຈໍາເປັນຍັງສາມາດ overwhelming, ໂດຍສະເພາະໃນເວລາທີ່ການປຸງແຕ່ງຂໍ້ມູນຂ່າວສານໃນລະຫວ່າງສະຖານະການການຈະລາຈອນສູງ. : ການຕັ້ງຄ່າ nodes ທີ່ເປັນເຈົ້າພາບດ້ວຍຕົນເອງເບິ່ງຄືວ່າເປັນທາງເລືອກທີ່ດີກວ່າ, ແຕ່ມັນບໍ່ແມ່ນ. ຄ່າໃຊ້ຈ່າຍຂອງຮາດແວ, ຄ່າໃຊ້ຈ່າຍໃນການດໍາເນີນງານ, ແລະຄ່າໃຊ້ຈ່າຍໃນໂອກາດສາມາດ overwhelming. ລາຄາແພງໃນການຄຸ້ມຄອງ ຄ່າໃຊ້ຈ່າຍໃນການດໍາເນີນງານເຊັ່ນ: ໄຟຟ້າ, ແບນວິດອິນເຕີເນັດ, ແລະຄ່າບໍລິການຄລາວ (ຖ້າທ່ານໃຊ້ໂຄງສ້າງພື້ນຖານຂອງຄລາວ) ສາມາດ overwhelming. ເພື່ອດໍາເນີນການ node ທີ່ປະສົບຜົນສໍາເລັດ, ທ່ານຕ້ອງການທີມງານຜູ້ຊ່ຽວຊານທີ່ອຸທິດຕົນເພື່ອສະແຕນບາຍເພື່ອແກ້ໄຂບັນຫາໃດໆຫຼືທ່ານມີຄວາມສ່ຽງຕໍ່ໄຟໄຫມ້ເປັນເວລາຫຼາຍຊົ່ວໂມງ. : ທ່ານຕ້ອງການຄວາມເຂົ້າໃຈຢ່າງຫນັກແຫນ້ນຂອງເທກໂນໂລຍີ blockchain, ການຄຸ້ມຄອງເຄື່ອງແມ່ຂ່າຍ, ແລະການປະຕິບັດທີ່ດີທີ່ສຸດດ້ານຄວາມປອດໄພ. ການບຳລຸງຮັກສາປົກກະຕິເພື່ອຫຼີກເວັ້ນການເກີດການຂັດຂ້ອງເຊັ່ນ: ການອັບເດດຊອບແວ, ແຜ່ນປ້ອງກັນຄວາມປອດໄພ, ແລະການອັບເກຣດຮາດແວເພື່ອຮັກສາໃຫ້ໂນດເຮັດວຽກຢ່າງຖືກຕ້ອງ. ການຕິດຕັ້ງແລະການບໍາລຸງຮັກສາທີ່ຊັບຊ້ອນ : ບໍ່ເຫມືອນກັບຜູ້ໃຫ້ບໍລິການພາກສ່ວນທີສາມທີ່ມີຮູບແບບເພື່ອແກ້ໄຂບັນຫານີ້, ເພື່ອພົວພັນກັບ blockchain ຫຼາຍ, ທ່ານຈໍາເປັນຕ້ອງເປັນເຈົ້າພາບ nodes ສໍາລັບແຕ່ລະ blockchain ທີ່ສາມາດເປັນຊັບພະຍາກອນຫຼາຍແລະບໍ່ຍືນຍົງ. ຄວາມສາມາດໃນການຂະຫຍາຍທີ່ຈໍາກັດແລະບໍ່ສະຫນັບສະຫນູນ Multichain nodes ທີ່ເປັນເຈົ້າພາບຂອງຕົນເອງສະຫນອງຄວາມເປັນເອກະລາດ, ການຄວບຄຸມທີ່ຍິ່ງໃຫຍ່ຂອງການໂຕ້ຕອບ blockchain, ແລະຄວາມເປັນສ່ວນຕົວ. ພວກເຂົາຕ້ອງການຊັບພະຍາກອນທີ່ສໍາຄັນ, ຄວາມຊໍານານດ້ານເຕັກໂນໂລຢີແລະການບໍາລຸງຮັກສາ, ເຊິ່ງເປັນໄປບໍ່ໄດ້ສໍາລັບທີມງານພັດທະນາ blockchain ທີ່ເຂັ້ມແຂງທີ່ສຸດທີ່ມີຢູ່. ໂນດ RPC ແບບກະຈາຍ Decentralized RPCs ແມ່ນເຄື່ອງແມ່ຂ່າຍຂອງ blockchain ທີ່ອະນຸຍາດໃຫ້ dApps ຕິດຕໍ່ສື່ສານກັບ blockchain ໃນລັກສະນະການກະຈາຍ. ຜູ້ໃຫ້ບໍລິການ RPC ທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງແຈກຢາຍໂຄງສ້າງພື້ນຖານຂອງພວກເຂົາໃນທົ່ວຫຼາຍໂຫນດ. ນີ້ຫຼຸດຜ່ອນຈຸດດຽວຂອງຄວາມລົ້ມເຫຼວ, ປັບປຸງຄວາມຫມັ້ນຄົງຂອງເຄືອຂ່າຍແລະການຂະຫຍາຍ, ແລະຫຼຸດຜ່ອນການ latency. ຜົນປະໂຫຍດຂອງ Decentralized RPC nodes ຫຼາຍກວ່າອື່ນໆປະກອບມີ : ເຄືອຂ່າຍທີ່ແຈກຢາຍຂອງຜູ້ໃຫ້ບໍລິການ node ກໍາລັງເຮັດວຽກເພື່ອປະມວນຜົນການຮ້ອງຂໍ, ຕອບສະຫນອງຕໍ່ການສອບຖາມ, ແລະພົວພັນກັບ blockchain. ເຄືອຂ່າຍແຈກຢາຍ : ບໍ່ໄວ້ວາງໃຈຜູ້ໃຫ້ບໍລິການດຽວ. ການຮ້ອງຂໍແມ່ນຖືກແຈກຢາຍໃນທົ່ວຜູ້ໃຫ້ບໍລິການຫຼາຍເພື່ອຮັບປະກັນວ່າບໍ່ມີຝ່າຍດຽວສາມາດຄວບຄຸມຂໍ້ມູນຫຼືຄໍາຮ້ອງຂໍໄດ້ຢ່າງສົມບູນ. ການດໍາເນີນງານແມ່ນບໍ່ມີຄວາມຫນ້າເຊື່ອຖື : ເນື່ອງຈາກ RPC nodes ບໍ່ໄດ້ຕັ້ງຢູ່ໃນເຂດອຳນາດດຽວກັນ, ໜ່ວຍງານ/ສິດອຳນາດບໍ່ສາມາດ censor, block ຫຼືຈຳກັດການເຂົ້າເຖິງ blockchain ໄດ້ຢ່າງງ່າຍດາຍ. ຖ້າໂຄງສ້າງພື້ນຖານ RPC ປິດລົງເນື່ອງຈາກນະໂຍບາຍຈາກເຂດປົກຄອງ, ການຮ້ອງຂໍຂອງ dApp ສາມາດຖືກສົ່ງໄປຫາໂຫນດ RPC ອື່ນໆຈາກເຂດປົກຄອງທີ່ແຕກຕ່າງກັນ. Censorship Resistance : ຮູບແບບການແບ່ງຂັ້ນຄຸ້ມຄອງຂອງການບໍລິການ RPC ເຮັດໃຫ້ພວກເຂົາທົນທານຕໍ່ການເກີດໄຟໄໝ້. ຖ້າໂນດຖືກເອົາລົງ, ອີກອັນໜຶ່ງຈະປ່ຽນແທນການບໍລິການ. ນີ້ຊ່ວຍຫຼຸດຜ່ອນເວລາຢຸດເຮັດວຽກ ແລະຮັບປະກັນຄວາມພ້ອມ. Fault Tolerance ສິ່ງທ້າທາຍລວມມີ: : ຖ້າບໍ່ຖືກຕັ້ງຄ່າຢ່າງຖືກຕ້ອງ, ບໍລິການ RPC ແບບກະຈາຍສາມາດແນະນໍາການ latency ຍ້ອນວ່າມັນສາມາດຖືກສົ່ງຜ່ານຫຼາຍໂຫນດ. ການກະຈາຍອໍານາດຂອງຂໍ້ RPC ສາມາດກາຍເປັນຊ້ໍາຊ້ອນ, ແລະເປັນຜົນມາຈາກການນີ້, ຂໍ້ມູນສາມາດຖືກສົ່ງຜ່ານເຄື່ອງແມ່ຂ່າຍຫຼາຍອັນທີ່ເພີ່ມຂຶ້ນ latency. Latency : ເນື່ອງຈາກ nodes ຖືກຈັດການໂດຍຫນ່ວຍງານທີ່ແຕກຕ່າງກັນ, nodes ອາດຈະບໍ່ໄດ້ຮັບຄວາມປອດໄພເທົ່າທຽມກັນ. ຄວາມປອດໄພ : ການຮັບປະກັນຂໍ້ມູນທີ່ສອດຄ່ອງ ແລະເຊື່ອຖືໄດ້ສາມາດເປັນສິ່ງທ້າທາຍ. ກົນໄກຕ້ອງຢູ່ໃນບ່ອນເພື່ອກວດຫາ ແລະຫຼຸດຜ່ອນຂໍ້ທີ່ເປັນອັນຕະລາຍ/ຜິດພາດ. Consensus ລະຫວ່າງ Nodes ຕົວຢ່າງຂອງຂໍ້ Decentralized RPC ປະກອບມີ: dRPC, Pocket network, ແລະ Ankr ການປະຕິບັດທີ່ດີທີ່ສຸດເພື່ອຫຼີກເວັ້ນການຄວາມສ່ຽງສູນກາງໃນການພັດທະນາ dApp ຄວາມຫຼາກຫຼາຍຂອງຜູ້ໃຫ້ບໍລິການ Node ດ້ວຍການເລືອກຜູ້ໃຫ້ບໍລິການ node RPC ແບບແບ່ງຂັ້ນຄຸ້ມຄອງເຊັ່ນ dRPC, ທ່ານສາມາດຫລີກລ້ຽງຄວາມສ່ຽງຕໍ່ສູນກາງ. ຜູ້ໃຫ້ບໍລິການ RPC ທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງມີລະບົບເພື່ອໃຫ້ແນ່ໃຈວ່າ nodes ເຮັດວຽກຕາມຄຸນສົມບັດທີ່ຕ້ອງການເຊັ່ນ: load balancers, node provider monitoring, and incentive for good actors. ຕົວຢ່າງ, dRPC ໃຫ້ທ່ານເຂົ້າເຖິງ dashboard ສໍາລັບການຕິດຕາມຄວາມຫຼາກຫຼາຍຂອງໂຄງສ້າງພື້ນຖານຂອງ node ຂອງທ່ານ. ເຖິງແມ່ນວ່າທ່ານບໍ່ມີການຄວບຄຸມໂດຍກົງກ່ຽວກັບຂໍ້ໃດທີ່ທ່ານໃຊ້ແລະວິທີການແບ່ງອອກເປັນສູນກາງ, dashboard ຊ່ວຍໃຫ້ທ່ານເຫັນວ່າການແບ່ງສ່ວນຂອງ nodes ແມ່ນແນວໃດ. ການເບິ່ງໃນຮູບພາບຂ້າງເທິງໄດ້ສະແດງໃຫ້ເຫັນວ່າການເຊື່ອມຕໍ່ໄດ້ຖືກແບ່ງອອກເປັນສູນກາງລະຫວ່າງສີ່ຜູ້ໃຫ້ບໍລິການ node RPC ທີ່ແຕກຕ່າງກັນ ( ). ສະແດງໃຫ້ເຫັນຕົວເລກສະສົມຂອງລະດັບການກະຈາຍອຳນາດໂດຍ “ໜຶ່ງ” ເປັນການກະຈາຍອຳນາດຫຼາຍທີ່ສຸດ ແລະ “ສູນ” ເປັນສູນກາງທີ່ສຸດ. Besked, drpc-free, drpc-public-multiregion, p2p-validator-optimism-free ດັດຊະນີການກະຈາຍອຳນາດ 0.563 ການຕິດຕາມແລະການຄຸ້ມຄອງສຸຂະພາບຂອງ Node ນັກພັດທະນາຄວນຈະສາມາດກວດສອບຂໍ້ RPC ທີ່ໃຊ້ໂດຍ dApp ຂອງເຂົາເຈົ້າ. ນີ້ຮັບປະກັນຄວາມຫນ້າເຊື່ອຖືຂອງ dApp. ເຖິງແມ່ນວ່າທ່ານອາດຈະບໍ່ສາມາດຄວບຄຸມວິທີການທີ່ຜູ້ໃຫ້ບໍລິການ RPC ຄຸ້ມຄອງລະບົບຂອງພວກເຂົາ, ຜູ້ໃຫ້ບໍລິການ RPC ທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງເຊັ່ນ dRPC ມີລະບົບໃນການຕິດຕາມຜູ້ໃຫ້ບໍລິການຂອງ RPC node. ໃຫ້ທ່ານເຂົ້າເຖິງການວິເຄາະທີ່ສົມບູນແບບເພື່ອຕິດຕາມເບິ່ງວ່າ dApp ຂອງທ່ານພົວພັນກັບໂຄງສ້າງພື້ນຖານແນວໃດ. ໃນ dashboard dRPC, ສໍາລັບການຍົກຕົວຢ່າງ, ທ່ານສາມາດເຂົ້າເຖິງບັນທຶກຄວາມຜິດພາດຈາກ dashboard ໄດ້. dashboard SaaS ຂອງ dRPC ທ່ານສາມາດຕິດຕາມຈໍານວນການຮ້ອງຂໍທັງຫມົດໂດຍ dApp ຂອງທ່ານໃນມື້ທີ່ເລືອກ, ຕິດຕາມກວດກາ RPC node decentralization, ແລະການແຈກຢາຍການຮ້ອງຂໍໂດຍອີງໃສ່ລະຫັດ API. ນອກຈາກ dashboard ການວິເຄາະ dRPC, dRPC ມີກົນໄກ backend ເພື່ອຕິດຕາມຜູ້ໃຫ້ບໍລິການ node ແລະປ້ອງກັນບໍ່ໃຫ້ພວກເຂົາຂີ້ຕົວະ. ອ່ານເພີ່ມເຕີມກ່ຽວກັບກົນໄກ backend ເຫຼົ່ານີ້ທີ່ນີ້. ສະຫຼຸບ ໂຫນດ RPC ມີບົດບາດສໍາຄັນໃນການອໍານວຍຄວາມສະດວກໃນການສື່ສານລະຫວ່າງຄໍາຮ້ອງສະຫມັກທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງແລະ blockchain. ຢ່າງໃດກໍຕາມ, ສູນກາງຂອງ RPCs ມີຄວາມສ່ຽງທີ່ສໍາຄັນຕໍ່ dApp ຂອງທ່ານແລະເຄືອຂ່າຍ blockchain ຂະຫນາດໃຫຍ່. ດັ່ງທີ່ເຫັນໄດ້ໃນຄວາມລົ້ມເຫລວທີ່ຜ່ານມາຈາກກໍລະນີສຶກສາທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ການອີງໃສ່ຜູ້ໃຫ້ບໍລິການ RPC ສູນກາງເຮັດໃຫ້ເກີດຄວາມສ່ຽງຕໍ່ຄວາມລົ້ມເຫຼວຂອງຈຸດດຽວແລະສາມາດນໍາໄປສູ່ການຂັດຂວາງການບໍລິການ web3 ທີ່ສໍາຄັນ. ນັກພັດທະນາບໍ່ແມ່ນບໍ່ມີທາງເລືອກ. RPCs ທີ່ເປັນເຈົ້າພາບຂອງຕົນເອງແລະການແບ່ງຂັ້ນຄຸ້ມຄອງສະເຫນີການແກ້ໄຂທີ່ເຊື່ອຖືໄດ້ທີ່ສາມາດຊ່ວຍສ້າງຄໍາຮ້ອງສະຫມັກທີ່ທົນທານຕໍ່. ໂດຍການຍອມຮັບ RPCs ແບບແບ່ງຂັ້ນຄຸ້ມຄອງເຊັ່ນ , ນັກພັດທະນາສາມາດຫຼຸດຜ່ອນຄວາມສ່ຽງຂອງການເປັນສູນກາງແລະສ້າງຄໍາຮ້ອງສະຫມັກທີ່ມີປະສິດທິພາບ, ທົນທານ, ທົນທານຕໍ່ censorship, ແລະປອດໄພ. dRPC
