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

ແຕ່ຫນ້າເສຍດາຍ, ເຖິງແມ່ນວ່າ blockchain ມີລັກສະນະພິເສດແລະຜົນປະໂຫຍດຂອງຕົນເອງ, ຄໍາຮ້ອງສະຫມັກສ່ວນໃຫຍ່ທີ່ດໍາເນີນການກັບມັນມີລາຄາແພງກວ່າ, ຊ້າກວ່າ, ແລະ intuitive ຫນ້ອຍກ່ວາຄູ່ແຂ່ງສູນກາງຂອງພວກເຂົາ.

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

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

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

ທໍາອິດໃຫ້ເບິ່ງວິທີການແບບດັ້ງເດີມຫຼາຍ, ເຊິ່ງໃຊ້ blockchain ເປັນຕົວກາງໂດຍກົງລະຫວ່າງຜູ້ໃຊ້ແອັບພລິເຄຊັນ, ແລະບໍ່ຂະຫນາດໂດຍສະເພາະ.

ວິທີການ #1: Blockchain ເປັນ Backend

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

ໃນສະຖານະການໃດກໍ່ຕາມທີ່ພວກເຮົາຕ້ອງການທີ່ຈະທໍາລາຍຕົວກາງດັ່ງກ່າວໂດຍໃຊ້ວິທີການນີ້, ພວກເຮົາຈະພະຍາຍາມເຮັດຊ້ໍາເຫດຜົນທາງທຸລະກິດຂອງລາວໂດຍໃຊ້ສັນຍາສະຫມາດໃນ blockchain ເຊັ່ນ Ethereum.

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

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

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

ມີສອງດ້ານຂອງບັນຫາການຂະຫຍາຍຂະຫນາດກັບວິທີການນີ້. ຫນ້າທໍາອິດ, ຈໍານວນສູງສຸດຂອງທຸລະກໍາຕໍ່ວິນາທີ. ອັນທີສອງ, ຈໍານວນຂໍ້ມູນທີ່ສາມາດຖືກເກັບໄວ້ໃນ blockchain.

ໃຫ້ເຮັດການຄິດໄລ່ຫຍາບຄາຍບາງອັນ. Booking.com ກ່າວວ່າພວກເຂົາມີເກືອບ 2 ລ້ານໂຮງແຮມລົງທະບຽນກັບພວກເຂົາ. ສົມມຸດວ່າໂຮງແຮມສະເລ່ຍມີ 10 ຫ້ອງແລະແຕ່ລະຄົນຖືກຈອງພຽງແຕ່ 20 ເທື່ອຕໍ່ປີ - ເຊິ່ງເຮັດໃຫ້ພວກເຮົາສະເລ່ຍ 13 ຈອງຕໍ່ວິນາທີ.

ເພື່ອເຮັດໃຫ້ຕົວເລກນີ້ເຂົ້າໄປໃນທັດສະນະ, ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າ Ethereum ສາມາດປະມວນຜົນປະມານ 15 ທຸລະກໍາຕໍ່ວິນາທີ.

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

ຍັງມີບັນຫາກ່ຽວກັບຂະຫນາດຢູ່ທີ່ນີ້ - ນ້ໍາຫນັກຂອງ Ethereum blockchain ບໍ່ດົນມານີ້ໄດ້ຜ່ານເຄື່ອງຫມາຍ 2TB. ຖ້າຄໍາຮ້ອງສະຫມັກທີ່ມີວິທີການນີ້ກາຍເປັນທີ່ນິຍົມແທ້ໆ, ເຄືອຂ່າຍ Ethereum ຈະກາຍເປັນທີ່ບໍ່ຫມັ້ນຄົງທີ່ສຸດ.

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

ດັ່ງນັ້ນ, ນັກພັດທະນາ dapp ຕ້ອງໄດ້ປະເມີນຢ່າງລະມັດລະວັງວ່າແຕ່ລະລັກສະນະທີ່ໃຊ້ blockchain ຕ້ອງການການແຈກຢາຍຢ່າງແທ້ຈິງແລະບໍ່ຂຽນ.

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

ຖ້າພວກເຮົາເລີ່ມຖາມຄໍາຖາມເຫຼົ່ານີ້, ພວກເຮົາຈະເລີ່ມເຫັນວ່າພວກເຮົາບໍ່ຈໍາເປັນຕ້ອງມີຄຸນສົມບັດຂອງ blockchain ລາຄາແພງທັງຫມົດສໍາລັບຫນ້າທີ່ຂອງພວກເຮົາທັງຫມົດ. ດັ່ງນັ້ນ, ທາງເລືອກແມ່ນຫຍັງ?

ວິທີການ #2: Blockstack Inspired Architecture

ເຖິງແມ່ນວ່າການເນັ້ນຫນັກໃສ່ຕົ້ນຕໍ Blockstack ໃນແອັບພລິເຄຊັນທີ່ຜູ້ໃຊ້ເປັນເຈົ້າຂອງຂໍ້ມູນຂອງເຂົາເຈົ້າ (ຕົວຢ່າງເຊັ່ນ ອາກາດ, BentenSound, ເຄື່ອງມືເພີ່ມປະສິດທິພາບຮູບພາບ ຫຼື Graphite), blockstack ຍັງມີປັດຊະຍາຂອງການນໍາໃຊ້ blockchain ເບົາບາງ - ພຽງແຕ່ໃນເວລາທີ່ມີຄວາມຈໍາເປັນຢ່າງແທ້ຈິງ. ການໂຕ້ຖຽງຕົ້ນຕໍຂອງພວກເຂົາແມ່ນວ່າ blockchain ແມ່ນຊ້າແລະມີລາຄາແພງ, ແລະດັ່ງນັ້ນຈິ່ງຄວນຈະຖືກນໍາໃຊ້ສໍາລັບການເຮັດທຸລະກໍາດຽວຫຼືເລື້ອຍໆ. ສ່ວນທີ່ເຫຼືອຂອງການໂຕ້ຕອບກັບຄໍາຮ້ອງສະຫມັກຄວນຈະເກີດຂຶ້ນໂດຍຜ່ານ peer-to-peer, i.e. ຜູ້ໃຊ້ຂອງຄໍາຮ້ອງສະຫມັກທີ່ມີການແບ່ງຂັ້ນຄຸ້ມຄອງຕ້ອງແບ່ງປັນຂໍ້ມູນໂດຍກົງກັບກັນແລະກັນ, ແທນທີ່ຈະຜ່ານ blockchain. ຫຼັງຈາກທີ່ທັງຫມົດ, ຄໍາຮ້ອງສະຫມັກການກະຈາຍອໍານາດທີ່ເກົ່າແກ່ທີ່ສຸດແລະປະສົບຜົນສໍາເລັດຫຼາຍທີ່ສຸດເຊັ່ນ BitTorrent, ອີເມວແລະ Tor ຖືກສ້າງຂຶ້ນກ່ອນແນວຄວາມຄິດຂອງ blockchain ຕົວຂອງມັນເອງ.

ຊ້າຍ: ວິທີການທໍາອິດ, ໃນທີ່ຜູ້ໃຊ້ໂຕ້ຕອບຜ່ານ blockchain. ສິດ: ຜູ້ໃຊ້ໂຕ້ຕອບໂດຍກົງກັບກັນແລະກັນ, ແລະ blockchain ຖືກນໍາໃຊ້ພຽງແຕ່ສໍາລັບການກໍານົດແລະຄ້າຍຄືກັນ.

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

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

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

ໃນກໍລະນີຂອງ Blockstack, ພຽງແຕ່ຂໍ້ມູນຕົວຕົນຂອງທ່ານຖືກເກັບໄວ້ໃນ blockchain. ຂໍ້ມູນກ່ຽວກັບວິທີການໄດ້ຮັບຂໍ້ມູນຂອງຜູ້ໃຊ້ແຕ່ລະຄົນຖືກເກັບໄວ້ໃນໄຟລ໌ເຂດແລະແຈກຢາຍຜ່ານເຄືອຂ່າຍ peer-to-peer ໂດຍໃຊ້ nodes. ແລະອີກເທື່ອ ໜຶ່ງ, ທ່ານບໍ່ ຈຳ ເປັນຕ້ອງເຊື່ອຂໍ້ມູນທີ່ໂຫນດໃຫ້, ເພາະວ່າທ່ານສາມາດກວດສອບຄວາມຖືກຕ້ອງຂອງມັນໂດຍການປຽບທຽບກັບ hashes ທີ່ເກັບໄວ້ໃນ blockchain ແລະຜູ້ໃຊ້ອື່ນໆ.

ໃນສະບັບທີ່ງ່າຍດາຍຂອງລະບົບ, ແຂກຈະໃຊ້ Blockstack peer-to-peer network ເພື່ອຊອກຫາໂຮງແຮມແລະໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບຫ້ອງຂອງເຂົາເຈົ້າ. ແລະຄວາມແທ້ຈິງແລະຄວາມສົມບູນຂອງຂໍ້ມູນທັງຫມົດທີ່ທ່ານໄດ້ຮັບສາມາດໄດ້ຮັບການຢັ້ງຢືນໂດຍໃຊ້ກະແຈສາທາລະນະແລະ hashes ເກັບຮັກສາໄວ້ໃນ ວົງຈອນ virtual Blockstack.

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

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

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

ສະຫລຸບ

ຄໍາຮ້ອງສະຫມັກທີ່ເຮັດວຽກຢູ່ໃນ Blockstack ສາມາດຂະຫນາດໄດ້ດີກວ່າຄໍາຮ້ອງສະຫມັກ blockchain ທໍາມະດາ, ແຕ່ວ່າມັນເປັນວິທີການທີ່ອ່ອນກວ່າກັບບັນຫາຂອງຕົນເອງແລະຄໍາຖາມທີ່ບໍ່ມີຄໍາຕອບ.

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

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

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

ແຫຼ່ງຂໍ້ມູນ: www.habr.com