🥇ການທົດສອບສາທາລະນະ: ການແກ້ໄຂສໍາລັບຄວາມເປັນສ່ວນຕົວແລະຂະຫນາດໃນ Ethereum

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

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

ເພື່ອຮັບປະກັນການແບ່ງຂັ້ນຄຸ້ມຄອງ, ຄວາມປອດໄພແລະຂະຫນາດໃນ blockchain, ດັ່ງນັ້ນການແກ້ໄຂ Scalability Trilemma, ທີມງານພັດທະນາ ໂອກາດ ໄດ້ສ້າງ Plasma Cash, ລະບົບຕ່ອງໂສ້ສາຂາທີ່ປະກອບດ້ວຍສັນຍາສະຫມາດແລະເຄືອຂ່າຍເອກະຊົນໂດຍອີງໃສ່ Node.js, ເຊິ່ງແຕ່ລະໄລຍະຈະໂອນລັດຂອງຕົນໄປສູ່ລະບົບຕ່ອງໂສ້ຮາກ (Ethereum).

ຂະບວນການສໍາຄັນໃນ Plasma Cash

1. ຜູ້ໃຊ້ເອີ້ນຟັງຊັນສັນຍາສະຫມາດ 'ເງິນຝາກ', ເຂົ້າໄປໃນຈໍານວນ ETH ທີ່ລາວຕ້ອງການເງິນຝາກເຂົ້າໄປໃນ Plasma Cash token. ຟັງຊັນສັນຍາສະຫມາດສ້າງ token ແລະສ້າງເຫດການກ່ຽວກັບມັນ.

2. Plasma Cash nodes ທີ່ສະໝັກໃຊ້ກັບເຫດການສັນຍາອັດສະລິຍະໄດ້ຮັບເຫດການກ່ຽວກັບການສ້າງເງິນຝາກ ແລະເພີ່ມທຸລະກໍາກ່ຽວກັບການສ້າງ token ໃຫ້ກັບສະນຸກເກີ.

3. ແຕ່ລະໄລຍະ, ໂຫມດ Plasma Cash ພິເສດເອົາທຸລະກໍາທັງຫມົດຈາກສະນຸກເກີ (ເຖິງ 1 ລ້ານ) ແລະປະກອບເປັນຕັນຈາກພວກເຂົາ, ຄິດໄລ່ຕົ້ນໄມ້ Merkle ແລະຕາມນັ້ນ, hash. ບລັອກນີ້ຖືກສົ່ງໄປຫາຂໍ້ອື່ນເພື່ອກວດສອບ. nodes ກວດເບິ່ງວ່າ Merkle hash ຖືກຕ້ອງຫຼືບໍ່ແລະການເຮັດທຸລະກໍາແມ່ນຖືກຕ້ອງ (ຕົວຢ່າງເຊັ່ນວ່າຜູ້ສົ່ງ token ເປັນເຈົ້າຂອງຂອງມັນ). ຫຼັງຈາກການກວດສອບຕັນ, node ເອີ້ນຟັງຊັນ 'submitBlock' ຂອງສັນຍາສະຫມາດ, ເຊິ່ງຊ່ວຍປະຢັດຈໍານວນບລັອກແລະ Merkle hash ກັບຕ່ອງໂສ້ຂອບ. ສັນຍາສະຫມາດສ້າງເຫດການທີ່ຊີ້ໃຫ້ເຫັນເຖິງຜົນສໍາເລັດຂອງການເພີ່ມຕັນ. ທຸລະກໍາຖືກໂຍກຍ້າຍອອກຈາກສະນຸກເກີ.

4. ໂຫນດທີ່ໄດ້ຮັບເຫດການການຍື່ນສະເຫນີບລັອກເລີ່ມຕົ້ນທີ່ຈະນໍາໃຊ້ທຸລະກໍາທີ່ຖືກເພີ່ມເຂົ້າໃນບລັອກ.

5. ໃນບາງຈຸດ, ເຈົ້າຂອງ (ຫຼືບໍ່ແມ່ນເຈົ້າຂອງ) ຂອງໂທເຄັນຕ້ອງການຖອນມັນອອກຈາກ Plasma Cash. ເພື່ອເຮັດສິ່ງນີ້, ລາວເອີ້ນວ່າຟັງຊັນ 'startExit', ເຂົ້າໄປໃນມັນຂໍ້ມູນກ່ຽວກັບການເຮັດທຸລະກໍາ 2 ສຸດທ້າຍໃນ token, ເຊິ່ງຢືນຢັນວ່າລາວເປັນເຈົ້າຂອງ token. ສັນຍາສະຫມາດ, ໂດຍໃຊ້ Merkle hash, ກວດເບິ່ງການປະກົດຕົວຂອງທຸລະກໍາໃນບລັອກແລະສົ່ງ token ສໍາລັບການຖອນ, ເຊິ່ງຈະເກີດຂຶ້ນໃນສອງອາທິດ.

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

ຄວາມເປັນສ່ວນຕົວແມ່ນບັນລຸໄດ້ໃນສອງທາງ

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

2. ລະບົບຕ່ອງໂສ້ເດັກອະນຸຍາດໃຫ້ເຮັດທຸລະກໍາທີ່ບໍ່ເປີດເຜີຍຊື່ໂດຍໃຊ້ zk-SNARKs.

ເຕັກໂນໂລຍີ stack

NodeJS
Redis
etherium
Sild

ການທົດສອບ

ໃນຂະນະທີ່ພັດທະນາ Plasma Cash, ພວກເຮົາໄດ້ທົດສອບຄວາມໄວຂອງລະບົບແລະໄດ້ຮັບຜົນໄດ້ຮັບດັ່ງຕໍ່ໄປນີ້:

ເຖິງ 35 ທຸລະກໍາຕໍ່ວິນາທີຖືກເພີ່ມເຂົ້າໃນສະນຸກເກີ;
ສູງເຖິງ 1 ທຸລະກໍາສາມາດຖືກເກັບໄວ້ໃນບລັອກ.

ການທົດສອບໄດ້ຮັບການປະຕິບັດໃນ 3 ເຄື່ອງແມ່ຂ່າຍດັ່ງຕໍ່ໄປນີ້:

1. Intel Core i7-6700 Quad-Core Skylake ລວມ. NVMe SSD – 512 GB, RAM 64 GB DDR4
3 ການກວດສອບ Plasma Cash nodes ໄດ້ຖືກຍົກຂຶ້ນມາ.

2. AMD Ryzen 7 1700X Octa-Core “Summit Ridge” (Zen), SATA SSD – 500 GB, RAM 64 GB DDR4
Ropsten testnet ETH node ໄດ້ຖືກຍົກຂຶ້ນມາ.
3 ການກວດສອບ Plasma Cash nodes ໄດ້ຖືກຍົກຂຶ້ນມາ.

3. Intel Core i9-9900K Octa-Core ລວມ. NVMe SSD – 1 TB, RAM 64 GB DDR4
1 ໂຫນດການສົ່ງເງິນ Plasma ຖືກຍົກຂຶ້ນມາ.
3 ການກວດສອບ Plasma Cash nodes ໄດ້ຖືກຍົກຂຶ້ນມາ.
ການທົດສອບໄດ້ຖືກເປີດຕົວເພື່ອເພີ່ມທຸລະກໍາໃນເຄືອຂ່າຍ Plasma Cash.

ລວມ: 10 Plasma Cash nodes ໃນເຄືອຂ່າຍສ່ວນຕົວ.

ການທົດສອບ 1

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

ສະຖານະເບື້ອງຕົ້ນ: ຕັນສຸດທ້າຍ #7; 1 ລ້ານທຸລະກໍາແລະ tokens ຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນ.

00:00 — ເລີ່ມຕົ້ນຂອງການຜະລິດສະຄິບການເຮັດທຸລະກໍາ
01:37 - 1 ລ້ານທຸລະກໍາໄດ້ຖືກສ້າງຂື້ນແລະການສົ່ງໄປຫາ node ໄດ້ເລີ່ມຕົ້ນ
01:46 — ສົ່ງ node ເອົາທຸລະກໍາ 240k ຈາກສະນຸກເກີແລະແບບຟອມ block #8. ພວກເຮົາຍັງເຫັນວ່າການເຮັດທຸລະກໍາ 320k ຖືກເພີ່ມເຂົ້າໃນສະນຸກເກີໃນ 10 ວິນາທີ
01:58 — ຕັນ #8 ຖືກເຊັນແລະສົ່ງສໍາລັບການກວດສອບ
02:03 — ຕັນ #8 ຖືກກວດສອບແລະການທໍາງານ `submitBlock` ຂອງສັນຍາສະຫລາດແມ່ນໄດ້ຖືກເອີ້ນດ້ວຍການ Merkle hash ແລະຈໍານວນ block.
02:10 — ຕົວຢ່າງຕົວຢ່າງສໍາເລັດການເຮັດວຽກ, ທີ່ສົ່ງ 1 ລ້ານທຸລະກໍາໃນ 32 ວິນາທີ
02: 33 - nodes ເລີ່ມໄດ້ຮັບຂໍ້ມູນທີ່ block #8 ຖືກເພີ່ມເຂົ້າໃນລະບົບຕ່ອງໂສ້ຮາກ, ແລະເລີ່ມເຮັດທຸລະກໍາ 240k.
02:40 - 240k ທຸລະກໍາໄດ້ຖືກໂຍກຍ້າຍອອກຈາກສະນຸກເກີ, ເຊິ່ງຢູ່ໃນຕັນ #8 ແລ້ວ.
02:56 - ສົ່ງ node ເອົາທຸລະກໍາທີ່ຍັງເຫຼືອ 760k ຈາກສະນຸກເກີແລະເລີ່ມຄິດໄລ່ Merkle hash ແລະເຊັນບົດບັນທຶກ #9.
03:20 - ທຸກໆ nodes ປະກອບມີ 1 ລ້ານ 240k ທຸລະກໍາແລະ tokens
03:35 — ຕັນ #9 ຖືກເຊັນແລະສົ່ງສໍາລັບການກວດສອບກັບຂໍ້ອື່ນໆ
03:41 - ເຄືອຂ່າຍຜິດພາດເກີດຂຶ້ນ
04:40 — ການລໍຖ້າສໍາລັບ block #9 ການກວດສອບໄດ້ຫມົດເວລາ
04:54 - ສົ່ງ node ເອົາທຸລະກໍາທີ່ຍັງເຫຼືອ 760k ຈາກສະນຸກເກີແລະເລີ່ມຄິດໄລ່ Merkle hash ແລະເຊັນບົດບັນທຶກ #9.
05:32 — ຕັນ #9 ຖືກເຊັນແລະສົ່ງສໍາລັບການກວດສອບກັບຂໍ້ອື່ນໆ
05:53 — ຕັນ #9 ຖືກກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
06:17 - nodes ເລີ່ມໄດ້ຮັບຂໍ້ມູນທີ່ block #9 ຖືກເພີ່ມເຂົ້າໃນລະບົບຕ່ອງໂສ້ຮາກແລະເລີ່ມເຮັດທຸລະກໍາ 760k.
06:47 — ສະນຸກເກີໄດ້ລົບລ້າງການເຮັດທຸລະກໍາທີ່ຢູ່ໃນຕັນ #9
09:06 - nodes ທັງຫມົດປະກອບດ້ວຍ 2 ລ້ານທຸລະກໍາແລະ tokens

ການທົດສອບ 2

ມີຂອບເຂດຈໍາກັດ 350k ຕໍ່ຕັນ. ດັ່ງນັ້ນ, ພວກເຮົາມີ 3 ຕັນ.

ສະຖານະເບື້ອງຕົ້ນ: ຕັນສຸດທ້າຍ #9; 2 ລ້ານທຸລະກໍາແລະ tokens ຖືກເກັບໄວ້ໃນຖານຂໍ້ມູນ

00:00 - script ການຜະລິດທຸລະກໍາໄດ້ຖືກເປີດຕົວແລ້ວ
00:44 - 1 ລ້ານທຸລະກໍາໄດ້ຖືກສ້າງຂື້ນແລະການສົ່ງໄປຫາ node ໄດ້ເລີ່ມຕົ້ນ
00:56 — ສົ່ງ node ເອົາທຸລະກໍາ 320k ຈາກສະນຸກເກີແລະແບບຟອມ block #10. ພວກເຮົາຍັງເຫັນວ່າການເຮັດທຸລະກໍາ 320k ຖືກເພີ່ມເຂົ້າໃນສະນຸກເກີໃນ 10 ວິນາທີ
01:12 — ຕັນ #10 ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
01:18 — ຕົວຢ່າງຕົວຢ່າງສໍາເລັດການເຮັດວຽກ, ທີ່ສົ່ງ 1 ລ້ານທຸລະກໍາໃນ 34 ວິນາທີ
01:20 — ຕັນ #10 ຖືກກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
01: 51 - ທຸກໆ nodes ໄດ້ຮັບຂໍ້ມູນຈາກລະບົບຕ່ອງໂສ້ຮາກທີ່ຕັນ #10 ຖືກເພີ່ມແລະເລີ່ມນໍາໃຊ້ທຸລະກໍາ 320k.
02:01 - ສະນຸກເກີໄດ້ລ້າງສໍາລັບທຸລະກໍາ 320k ທີ່ຖືກເພີ່ມເຂົ້າໃນບລັອກ #10
02:15 - ສົ່ງ node ເອົາທຸລະກໍາ 350k ຈາກສະນຸກເກີແລະແບບຟອມ block #11.
02:34 — ຕັນ #11 ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
02:51 — ຕັນ #11 ຖືກກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
02:55 — ໂຫນດສຸດທ້າຍເຮັດທຸລະກໍາຈາກບລັອກ #10
10:59 - ການເຮັດທຸລະກໍາດ້ວຍການຍື່ນສະເຫນີຂອງຕັນ #9 ໃຊ້ເວລາດົນຫຼາຍໃນລະບົບຕ່ອງໂສ້ຮາກ, ແຕ່ມັນໄດ້ຖືກສໍາເລັດແລະທຸກ nodes ໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບມັນແລະເລີ່ມເຮັດທຸລະກໍາ 350k.
11:05 - ສະນຸກເກີໄດ້ລ້າງສໍາລັບທຸລະກໍາ 320k ທີ່ຖືກເພີ່ມເຂົ້າໃນບລັອກ #11
12:10 - ທຸກໆ nodes ປະກອບມີ 1 ລ້ານ 670k ທຸລະກໍາແລະ tokens
12:17 — ສົ່ງ node ເອົາທຸລະກໍາ 330k ຈາກສະນຸກເກີແລະ forms block #12.
12:32 — ຕັນ #12 ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
12:39 — ຕັນ #12 ຖືກກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
13:44 - ໂຫນດທັງຫມົດໄດ້ຮັບຂໍ້ມູນຈາກລະບົບຕ່ອງໂສ້ຮາກທີ່ຕັນ #12 ຖືກເພີ່ມແລະເລີ່ມນໍາໃຊ້ທຸລະກໍາ 330k.
14:50 - nodes ທັງຫມົດປະກອບດ້ວຍ 2 ລ້ານທຸລະກໍາແລະ tokens

ການທົດສອບ 3

ໃນເຊີບເວີທໍາອິດແລະທີສອງ, ຫນຶ່ງ validating node ໄດ້ຖືກທົດແທນໂດຍ node ສົ່ງ.

ສະຖານະເບື້ອງຕົ້ນ: ຕັນສຸດທ້າຍ #84; 0 ທຸລະກໍາແລະ tokens ບັນທຶກໄວ້ໃນຖານຂໍ້ມູນ

00:00 — 3 ສະຄຣິບໄດ້ຖືກເປີດຕົວທີ່ສ້າງແລະສົ່ງ 1 ລ້ານທຸລະກໍາແຕ່ລະຄົນ
01:38 — 1 ລ້ານທຸລະກໍາໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນແລະການສົ່ງໄປສົ່ງ node #3 ໄດ້ເລີ່ມຕົ້ນ
01:50 — ສົ່ງ node #3 ເອົາທຸລະກໍາ 330k ຈາກສະນຸກເກີແລະແບບຟອມ block #85 (f21). ພວກເຮົາຍັງເຫັນວ່າການເຮັດທຸລະກໍາ 350k ຖືກເພີ່ມເຂົ້າໃນສະນຸກເກີໃນ 10 ວິນາທີ
01:53 — 1 ລ້ານທຸລະກໍາໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນແລະການສົ່ງໄປສົ່ງ node #1 ໄດ້ເລີ່ມຕົ້ນ
01:50 — ສົ່ງ node #3 ເອົາທຸລະກໍາ 330k ຈາກສະນຸກເກີແລະແບບຟອມ block #85 (f21). ພວກເຮົາຍັງເຫັນວ່າການເຮັດທຸລະກໍາ 350k ຖືກເພີ່ມເຂົ້າໃນສະນຸກເກີໃນ 10 ວິນາທີ
02:01 — ສົ່ງ node #1 ເອົາທຸລະກໍາ 250k ຈາກສະນຸກເກີແລະ forms block #85 (65e)
02:06 — ຕັນ #85 (f21) ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
02:08 - ສະຄຣິບຕົວຢ່າງຂອງເຊີບເວີ #3, ເຊິ່ງສົ່ງ 1 ລ້ານທຸລະກໍາໃນ 30 ວິນາທີ, ເຮັດວຽກສໍາເລັດ.
02:14 — ຕັນ #85 (f21) ຖືກກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
02:19 — ຕັນ #85 (65e) ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
02:22 — 1 ລ້ານທຸລະກໍາໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນແລະການສົ່ງໄປສົ່ງ node #2 ໄດ້ເລີ່ມຕົ້ນ
02:27 — ຕັນ #85 (65e) ກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
02:29 — ສົ່ງ node #2 ໄດ້ 111855 ທຸລະກໍາຈາກສະນຸກເກີແລະ forms block #85 (256).
02:36 — ຕັນ #85 (256) ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
02:36 - ສະຄຣິບຕົວຢ່າງຂອງເຊີບເວີ #1, ເຊິ່ງສົ່ງ 1 ລ້ານທຸລະກໍາໃນ 42.5 ວິນາທີ, ເຮັດວຽກສໍາເລັດ.
02:38 — ຕັນ #85 (256) ຖືກກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
03:08 — ເຊີບເວີ # 2 script ເຮັດວຽກແລ້ວ, ເຊິ່ງສົ່ງ 1 ລ້ານທຸລະກໍາໃນ 47 ວິນາທີ
03:38 - ທຸກ nodes ໄດ້ຮັບຂໍ້ມູນຈາກລະບົບຕ່ອງໂສ້ຮາກທີ່ຕັນ #85 (f21), #86(65e), #87(256) ຖືກເພີ່ມ ແລະເລີ່ມນຳໃຊ້ທຸລະກຳ 330k, 250k, 111855.
03:49 - ສະນຸກເກີໄດ້ຖືກເກັບກູ້ຢູ່ທີ່ 330k, 250k, 111855 ທຸລະກໍາທີ່ຖືກເພີ່ມເຂົ້າໃນບລັອກ #85 (f21), #86(65e), #87(256)
03:59 — ສົ່ງ node #1 ໄດ້ 888145 ທຸລະກໍາຈາກສະນຸກເກີແລະ forms block #88 (214), ສົ່ງ node #2 ໄດ້ 750k ທຸລະກໍາຈາກສະນຸກເກີແລະ forms block #88 (50a), ສົ່ງ node #3 ໄດ້ 670k ທຸລະກໍາຈາກ. ສະນຸກເກີແລະຮູບແບບຕັນ #88 (d3b)
04:44 — ບລັອກ #88 (d3b) ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
04:58 — ຕັນ #88 (214) ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
05:11 — ຕັນ #88 (50a) ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
05:11 — ຕັນ #85 (d3b) ຖືກກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
05:36 — ຕັນ #85 (214) ຖືກກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
05:43 - ທຸກໆ nodes ໄດ້ຮັບຂໍ້ມູນຈາກລະບົບຕ່ອງໂສ້ຮາກທີ່ຕັນ #88 (d3b), #89(214) ໄດ້ຖືກເພີ່ມແລະກໍາລັງເລີ່ມນໍາໃຊ້ທຸລະກໍາ 670k, 750k.
06:50 — ເນື່ອງຈາກຄວາມລົ້ມເຫຼວໃນການສື່ສານ, ຕັນ #85 (50a) ບໍ່ໄດ້ຮັບການກວດສອບ
06:55 — ສົ່ງ node #2 ໄດ້ 888145 ທຸລະກໍາຈາກສະນຸກເກີແລະ forms block #90 (50a)
08:14 — ຕັນ #90 (50a) ຖືກເຊັນແລະສົ່ງໄປຍັງ nodes ອື່ນໆສໍາລັບການກວດສອບ
09:04 — ຕັນ #90 (50a) ຖືກກວດສອບແລະສົ່ງໄປຫາຕ່ອງໂສ້ຮາກ
11:23 - ທຸກໆ nodes ໄດ້ຮັບຂໍ້ມູນຈາກລະບົບຕ່ອງໂສ້ຮາກທີ່ຕັນ #90 (50a) ຖືກເພີ່ມ, ແລະເລີ່ມນໍາໃຊ້ທຸລະກໍາ 888145. ໃນຂະນະດຽວກັນ, ເຊີບເວີ #3 ໄດ້ນຳໃຊ້ທຸລະກຳຈາກບລັອກ #88 (d3b), #89(214) ແລ້ວ.
12:11 - ສະນຸກເກີທັງຫມົດແມ່ນຫວ່າງເປົ່າ
13:41 — nodes ທັງຫມົດຂອງ server #3 ມີ 3 ລ້ານທຸລະກໍາແລະ tokens
14:35 — nodes ທັງຫມົດຂອງ server #1 ມີ 3 ລ້ານທຸລະກໍາແລະ tokens
19:24 — nodes ທັງຫມົດຂອງ server #2 ມີ 3 ລ້ານທຸລະກໍາແລະ tokens

ອຸປະສັກ

ໃນລະຫວ່າງການພັດທະນາ Plasma Cash, ພວກເຮົາພົບບັນຫາຕໍ່ໄປນີ້, ເຊິ່ງພວກເຮົາຄ່ອຍໆແກ້ໄຂແລະແກ້ໄຂ:

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

2. ມັນບໍ່ຊັດເຈນທັນທີທັນໃດທີ່ຈະສົ່ງຈໍານວນຂະຫນາດໃຫຍ່ຂອງການເຮັດທຸລະກໍາໃນຂະນະທີ່ຫຼຸດຜ່ອນຄ່າໃຊ້ຈ່າຍໃນການໂອນຂໍ້ມູນ.

3. ມັນບໍ່ຊັດເຈນວ່າຈະເກັບຂໍ້ມູນແນວໃດແລະບ່ອນໃດເພື່ອໃຫ້ບັນລຸຜົນໄດ້ຮັບສູງ.

4. ມັນບໍ່ຈະແຈ້ງກ່ຽວກັບວິທີການຈັດເຄືອຂ່າຍລະຫວ່າງ nodes, ເນື່ອງຈາກວ່າຂະຫນາດຂອງຕັນທີ່ມີ 1 ລ້ານທຸລະກໍາໃຊ້ເວລາປະມານ 100 MB.

5. ການເຮັດວຽກໃນໂຫມດກະທູ້ດຽວທໍາລາຍການເຊື່ອມຕໍ່ລະຫວ່າງ nodes ໃນເວລາທີ່ການຄິດໄລ່ຍາວເກີດຂຶ້ນ (ຕົວຢ່າງ, ການສ້າງຕົ້ນໄມ້ Merkle ແລະການຄິດໄລ່ hash ຂອງມັນ).

ພວກເຮົາໄດ້ຈັດການກັບສິ່ງທັງຫມົດນີ້ແນວໃດ?

ສະບັບທໍາອິດຂອງ Plasma Cash node ແມ່ນປະເພດຂອງການລວມກັນທີ່ສາມາດເຮັດໄດ້ທຸກຢ່າງໃນເວລາດຽວກັນ: ຍອມຮັບການເຮັດທຸລະກໍາ, ສົ່ງແລະກວດສອບຕັນ, ແລະສະຫນອງ API ສໍາລັບການເຂົ້າເຖິງຂໍ້ມູນ. ນັບຕັ້ງແຕ່ NodeJS ເປັນກະທູ້ດຽວໂດຍພື້ນເມືອງ, ຟັງຊັນການຄິດໄລ່ຕົ້ນໄມ້ Merkle ຫນັກໄດ້ສະກັດຟັງຊັນການເພີ່ມການເຮັດທຸລະກໍາ. ພວກເຮົາໄດ້ເຫັນສອງທາງເລືອກໃນການແກ້ໄຂບັນຫານີ້:

1. ເປີດຕົວຂະບວນການ NodeJS ຫຼາຍ, ແຕ່ລະອັນປະຕິບັດຫນ້າທີ່ສະເພາະ.

2. ໃຊ້ worker_threads ແລະຍ້າຍການປະຕິບັດບາງສ່ວນຂອງລະຫັດເຂົ້າໄປໃນຫົວຂໍ້.

ດັ່ງນັ້ນ, ພວກເຮົາໃຊ້ທັງສອງທາງເລືອກໃນເວລາດຽວກັນ: ພວກເຮົາແບ່ງອອກຢ່າງມີເຫດຜົນຫນຶ່ງ node ເປັນ 3 ສ່ວນທີ່ສາມາດເຮັດວຽກແຍກຕ່າງຫາກ, ແຕ່ໃນເວລາດຽວກັນ synchronously.

1. ໂຫນດການຍື່ນສະເຫນີ, ເຊິ່ງຍອມຮັບການເຮັດທຸລະກໍາເຂົ້າໄປໃນສະນຸກເກີແລະສ້າງບລັອກ.

2. node validating ທີ່ກວດສອບຄວາມຖືກຕ້ອງຂອງ nodes.

3. API node - ສະຫນອງ API ສໍາລັບການເຂົ້າເຖິງຂໍ້ມູນ.

ໃນກໍລະນີນີ້, ທ່ານສາມາດເຊື່ອມຕໍ່ກັບແຕ່ລະ node ຜ່ານຊ່ອງສຽບ unix ໂດຍໃຊ້ cli.

ພວກເຮົາໄດ້ຍ້າຍການດໍາເນີນງານທີ່ຮຸນແຮງ, ເຊັ່ນການຄິດໄລ່ຕົ້ນໄມ້ Merkle, ເຂົ້າໄປໃນກະທູ້ແຍກຕ່າງຫາກ.

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ບັນລຸການປະຕິບັດປົກກະຕິຂອງຫນ້າທີ່ Plasma Cash ທັງຫມົດພ້ອມໆກັນແລະບໍ່ມີຄວາມລົ້ມເຫລວ.

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

ເພື່ອເລີ່ມຕົ້ນ, ພວກເຮົາໄດ້ເລີ່ມທົດສອບກົນໄກຂອງການສື່ສານກັບ Plasma Cash ເພື່ອຊອກຫາຄວາມສາມາດສູງສຸດຂອງລະບົບ. ພວກເຮົາຂຽນກ່ອນຫນ້ານີ້ວ່າ Plasma Cash node ສະຫນອງການໂຕ້ຕອບຂອງເຕົ້າຮັບ unix. ໃນເບື້ອງຕົ້ນ, ມັນແມ່ນອີງໃສ່ຂໍ້ຄວາມ. json objects ຖືກສົ່ງໂດຍໃຊ້ `JSON.parse()` ແລະ `JSON.stringify()`.

```json
{
  "action": "sendTransaction",
  "payload":{
    "prevHash": "0x8a88cc4217745fd0b4eb161f6923235da10593be66b841d47da86b9cd95d93e0",
    "prevBlock": 41,
    "tokenId": "57570139642005649136210751546585740989890521125187435281313126554130572876445",
    "newOwner": "0x200eabe5b26e547446ae5821622892291632d4f4",
    "type": "pay",
    "data": "",
    "signature": "0xd1107d0c6df15e01e168e631a386363c72206cb75b233f8f3cf883134854967e1cd9b3306cc5c0ce58f0a7397ae9b2487501b56695fe3a3c90ec0f61c7ea4a721c"
  }
}
```

ພວກເຮົາໄດ້ວັດແທກຄວາມໄວການໂອນຂອງວັດຖຸດັ່ງກ່າວແລະພົບວ່າ ~ 130k ຕໍ່ວິນາທີ. ພວກເຮົາໄດ້ພະຍາຍາມທົດແທນຫນ້າທີ່ມາດຕະຖານສໍາລັບການເຮັດວຽກກັບ json, ແຕ່ການປະຕິບັດບໍ່ໄດ້ປັບປຸງ. ເຄື່ອງຈັກ V8 ຕ້ອງໄດ້ຮັບການປັບປຸງດີສໍາລັບການປະຕິບັດງານເຫຼົ່ານີ້.

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

ການບັນທຶກໃນຖານຂໍ້ມູນ

ໃນເບື້ອງຕົ້ນ, Redis ໄດ້ຖືກເລືອກສໍາລັບການເກັບຮັກສາຂໍ້ມູນເປັນຫນຶ່ງໃນການແກ້ໄຂຜະລິດຕະພັນທີ່ສຸດທີ່ຕອບສະຫນອງຄວາມຕ້ອງການຂອງພວກເຮົາ: ການເກັບຮັກສາທີ່ສໍາຄັນ, ການເຮັດວຽກກັບຕາຕະລາງ hash, ຊຸດ. ພວກເຮົາໄດ້ເປີດຕົວ redis-benchmark ແລະໄດ້ຮັບການປະຕິບັດ ~ 80k ຕໍ່ວິນາທີໃນ 1 ຮູບແບບທໍ່.

ສໍາລັບປະສິດທິພາບສູງ, ພວກເຮົາໄດ້ປັບ Redis ລະອຽດກວ່າ:

ການເຊື່ອມຕໍ່ເຕົ້າຮັບ unix ໄດ້ຖືກສ້າງຕັ້ງຂຶ້ນ.
ພວກເຮົາປິດການບັນທຶກລັດໃສ່ແຜ່ນ (ເພື່ອຄວາມຫນ້າເຊື່ອຖື, ທ່ານສາມາດຕັ້ງ replica ແລະບັນທຶກໃສ່ disk ໃນ Redis ແຍກຕ່າງຫາກ).

ໃນ Redis, ສະນຸກເກີແມ່ນຕາຕະລາງ hash ເພາະວ່າພວກເຮົາຈໍາເປັນຕ້ອງສາມາດດຶງເອົາທຸລະກໍາທັງຫມົດໃນຫນຶ່ງຄໍາຖາມແລະລຶບທຸລະກໍາຫນຶ່ງຄັ້ງ. ພວກເຮົາໄດ້ພະຍາຍາມໃຊ້ບັນຊີລາຍຊື່ປົກກະຕິ, ແຕ່ມັນຊ້າກວ່າເມື່ອ unloading ບັນຊີລາຍຊື່ທັງຫມົດ.

ເມື່ອໃຊ້ NodeJS ມາດຕະຖານ, ຫ້ອງສະຫມຸດ Redis ໄດ້ບັນລຸການປະຕິບັດຂອງທຸລະກໍາ 18k ຕໍ່ວິນາທີ. ຄວາມໄວຫຼຸດລົງ 9 ເທົ່າ.

ນັບຕັ້ງແຕ່ດັດຊະນີໄດ້ສະແດງໃຫ້ພວກເຮົາເຫັນວ່າຄວາມເປັນໄປໄດ້ແມ່ນສູງກວ່າ 5 ເທົ່າ, ພວກເຮົາເລີ່ມເພີ່ມປະສິດທິພາບ. ພວກເຮົາໄດ້ປ່ຽນຫ້ອງສະຫມຸດເປັນ ioredis ແລະໄດ້ຮັບປະສິດທິພາບ 25k ຕໍ່ວິນາທີ. ພວກເຮົາໄດ້ເພີ່ມທຸລະກໍາຫນຶ່ງຄັ້ງໂດຍໃຊ້ຄໍາສັ່ງ 'hset'. ດັ່ງນັ້ນພວກເຮົາໄດ້ສ້າງຄໍາຖາມຈໍານວນຫລາຍໃນ Redis. ແນວຄວາມຄິດເກີດຂຶ້ນເພື່ອສົມທົບການເຮັດທຸລະກໍາເຂົ້າໄປໃນຊຸດແລະສົ່ງພວກມັນດ້ວຍຄໍາສັ່ງດຽວ "hmset". ຜົນໄດ້ຮັບແມ່ນ 32k ຕໍ່ວິນາທີ.

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

ພວກເຮົາຕ້ອງປ່ຽນເປັນ binary protocol ເພາະວ່າ:

1. ລະບົບມັກຈະຄິດໄລ່ hashes, ລາຍເຊັນ, ແລະອື່ນໆ, ແລະສໍາລັບການນີ້ມັນຕ້ອງການຂໍ້ມູນໃນ `Buffer.

2. ເມື່ອສົ່ງລະຫວ່າງການບໍລິການ, ຂໍ້ມູນຖານສອງມີນໍ້າໜັກໜ້ອຍກວ່າຂໍ້ຄວາມ. ຕົວຢ່າງ, ເມື່ອສົ່ງບລັອກທີ່ມີ 1 ລ້ານທຸລະກໍາ, ຂໍ້ມູນໃນຂໍ້ຄວາມສາມາດໃຊ້ເວລາຫຼາຍກວ່າ 300 megabytes.

3. ການປ່ຽນຂໍ້ມູນຢ່າງຕໍ່ເນື່ອງສົ່ງຜົນກະທົບຕໍ່ການປະຕິບັດ.

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

ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ຮັບໂຄງສ້າງຂໍ້ມູນດັ່ງຕໍ່ໄປນີ້:

- ການເຮັດທຸລະກໍາ

  ```json
  {
    prevHash: BD.types.buffer(20),
    prevBlock: BD.types.uint24le,
    tokenId: BD.types.string(null),
    type: BD.types.uint8,
    newOwner: BD.types.buffer(20),
    dataLength: BD.types.uint24le,
    data: BD.types.buffer(({current}) => current.dataLength),
    signature: BD.types.buffer(65),
    hash: BD.types.buffer(32),
    blockNumber: BD.types.uint24le,
    timestamp: BD.types.uint48le,
  }
  ```

- ໂທເຄັນ

  ```json
  {
    id: BD.types.string(null),
    owner: BD.types.buffer(20),
    block: BD.types.uint24le,
    amount: BD.types.string(null),
  }
  ```

— ຕັນ

  ```json
  {
    number: BD.types.uint24le,
    merkleRootHash: BD.types.buffer(32),
    signature: BD.types.buffer(65),
    countTx: BD.types.uint24le,
    transactions: BD.types.array(Transaction.Protocol, ({current}) => current.countTx),
    timestamp: BD.types.uint48le,
  }
  ```

ດ້ວຍຄໍາສັ່ງປົກກະຕິ `BD.encode(block, Protocol).slice();` ແລະ `BD.decode(buffer, Protocol)` ພວກເຮົາປ່ຽນຂໍ້ມູນເປັນ `Buffer` ເພື່ອບັນທຶກໃນ Redis ຫຼືສົ່ງຕໍ່ໄປຫາ node ອື່ນ ແລະດຶງຂໍ້ມູນ. ຂໍ້ມູນຄືນ.

ພວກເຮົາຍັງມີ 2 ໂປໂຕຄອນ binary ສໍາລັບການໂອນຂໍ້ມູນລະຫວ່າງການບໍລິການ:

- ໂປໂຕຄອນສຳລັບການໂຕ້ຕອບກັບ Plasma Node ຜ່ານຊ່ອງສຽບ unix

  ```json
  {
    type: BD.types.uint8,
    messageId: BD.types.uint24le,
    error: BD.types.uint8,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

ບ່ອນທີ່:

`ປະເພດ` — ການປະຕິບັດທີ່ຈະປະຕິບັດ, ສໍາລັບການຍົກຕົວຢ່າງ, 1 — sendTransaction, 2 — getTransaction;
`ການໂຫຼດ` — ຂໍ້ມູນທີ່ຈໍາເປັນຕ້ອງໄດ້ຮັບການສົ່ງກັບຫນ້າທີ່ທີ່ເຫມາະສົມ;
`messageId` — id ຂໍ້ຄວາມເພື່ອໃຫ້ການຕອບສະຫນອງໄດ້ຮັບການກໍານົດ.

- ອະນຸສັນຍາສໍາລັບການໂຕ້ຕອບລະຫວ່າງ nodes

  ```json
  {
    code: BD.types.uint8,
    versionProtocol: BD.types.uint24le,
    seq: BD.types.uint8,
    countChunk: BD.types.uint24le,
    chunkNumber: BD.types.uint24le,
    length: BD.types.uint24le,
    payload: BD.types.buffer(({node}) => node.length)
  }
  ```

ບ່ອນທີ່:

`ລະຫັດ` — ລະຫັດຂໍ້ຄວາມ, ຕົວຢ່າງ 6 — PREPARE_NEW_BLOCK, 7 — BLOCK_VALID, 8 — BLOCK_COMMIT;
`versionProtocol` — ເວີຊັ່ນໂປໂຕຄອນ, ເພາະວ່າໂນດທີ່ມີລຸ້ນຕ່າງໆສາມາດຖືກຍົກຂຶ້ນມາໃນເຄືອຂ່າຍ ແລະ ພວກມັນສາມາດເຮັດວຽກແຕກຕ່າງກັນໄດ້;
`seq` - ຕົວລະບຸຂໍ້ຄວາມ;
`ນັບChunk` и `ຕົວເລກ` ມີຄວາມຈໍາເປັນສໍາລັບການແຍກຂໍ້ຄວາມຂະຫນາດໃຫຍ່;
`ຄວາມຍາວ` и `ການໂຫຼດ` ຄວາມຍາວແລະຂໍ້ມູນຂອງມັນເອງ.

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

ຖ້າຫາກວ່າພວກເຮົາສາມາດບັນລຸຄວາມໄວໄດ້ 35 000 ການເຮັດທຸລະກໍາຕໍ່ວິນາທີ, ພວກເຮົາຍັງຕ້ອງການປຸງແຕ່ງພວກມັນໃນເວລາທີ່ເຫມາະສົມ. ນັບຕັ້ງແຕ່ເວລາການສ້າງຕັນໂດຍປະມານໃຊ້ເວລາ 30 ວິນາທີ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ລວມຢູ່ໃນບລັອກ +1 000 000 ການເຮັດທຸລະກໍາ, ຊຶ່ງຫມາຍຄວາມວ່າສົ່ງຫຼາຍ 100 MB ຂອງຂໍ້ມູນ.

ໃນເບື້ອງຕົ້ນ, ພວກເຮົາໄດ້ໃຊ້ຫ້ອງສະຫມຸດ 'ethereumjs-devp2p' ເພື່ອສື່ສານລະຫວ່າງ nodes, ແຕ່ມັນບໍ່ສາມາດຈັດການກັບຂໍ້ມູນໄດ້ຫຼາຍ. ດັ່ງນັ້ນ, ພວກເຮົາໄດ້ໃຊ້ຫ້ອງສະຫມຸດ `ws` ແລະຕັ້ງຄ່າການສົ່ງຂໍ້ມູນຖານສອງຜ່ານ websocket. ແນ່ນອນ, ພວກເຮົາຍັງພົບບັນຫາໃນເວລາທີ່ສົ່ງຊຸດຂໍ້ມູນຂະຫນາດໃຫຍ່, ແຕ່ພວກເຮົາແບ່ງອອກເປັນ chunks ແລະໃນປັດຈຸບັນບັນຫາເຫຼົ່ານີ້ຫມົດໄປ.

ຍັງປະກອບເປັນຕົ້ນໄມ້ Merkle ແລະການຄິດໄລ່ hash ໄດ້ +1 000 000 ການເຮັດທຸລະກໍາຮຽກຮ້ອງໃຫ້ມີປະມານ 10 ວິນາທີຂອງການຄິດໄລ່ຢ່າງຕໍ່ເນື່ອງ. ໃນລະຫວ່າງເວລານີ້, ການເຊື່ອມຕໍ່ກັບ nodes ທັງຫມົດສາມາດທໍາລາຍ. ມັນໄດ້ຖືກຕັດສິນໃຈຍ້າຍການຄິດໄລ່ນີ້ໄປຫາກະທູ້ແຍກຕ່າງຫາກ.

ຂໍ້ສະຫຼຸບ:

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

ການນໍາໃຊ້ Functional Programming ແທນທີ່ຈະເປັນ Object-Oriented Programming ປັບປຸງຜົນຜະລິດ.
monolith ແມ່ນຮ້າຍແຮງກວ່າສະຖາປັດຕະຍະກໍາການບໍລິການສໍາລັບລະບົບ NodeJS ທີ່ມີປະສິດທິພາບ.
ການໃຊ້ 'worker_threads' ສຳລັບການຄຳນວນຢ່າງໜັກຈະຊ່ວຍປັບປຸງການຕອບສະໜອງຂອງລະບົບ, ໂດຍສະເພາະເມື່ອຈັດການກັບການດຳເນີນການ i/o.
unix socket ມີຄວາມຫມັ້ນຄົງແລະໄວກວ່າການຮ້ອງຂໍ http.
ຖ້າທ່ານຕ້ອງການໂອນຂໍ້ມູນຂະຫນາດໃຫຍ່ຜ່ານເຄືອຂ່າຍຢ່າງໄວວາ, ມັນກໍ່ດີກວ່າທີ່ຈະໃຊ້ websockets ແລະສົ່ງຂໍ້ມູນຖານສອງ, ແບ່ງອອກເປັນ chunks, ເຊິ່ງສາມາດສົ່ງຕໍ່ໄດ້ຖ້າພວກເຂົາບໍ່ມາຮອດ, ແລະຫຼັງຈາກນັ້ນລວມເຂົ້າໄປໃນຂໍ້ຄວາມດຽວ.

ພວກເຮົາເຊີນທ່ານໄປຢ້ຽມຢາມ GitHub ໂຄງການ: https://github.com/opporty-com/Plasma-Cash/tree/new-version

ບົດຄວາມແມ່ນຮ່ວມກັນຂຽນໂດຍ Alexander Nashivan, ຜູ້ພັດທະນາອາວຸໂສ Clever Solution Inc.

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

ການທົດສອບສາທາລະນະ: ການແກ້ໄຂສໍາລັບຄວາມເປັນສ່ວນຕົວແລະຂະຫນາດໃນ Ethereum