Pinagdebatehan ng mga Ethereum CORE Developer ang Mga Benepisyo ng Mas Madalas na Hard Forks

Gaano kadalas masyadong madalas na baguhin ang pinagkasunduan?

Tinalakay ng isang pangkat ng mga beteranong open-source na developer ng ethereum ang paksa sa isang bi-weekly meeting noong Biyernes, kung saan ipinalabas nila ang posibilidad na ang mga pag-upgrade sa buong system, na tinatawag ding hard forks, sa software ay maaaring maisabatas nang madalas tuwing tatlong buwan.

Gustong "suriin ang temperatura," ipinaliwanag ng developer na nagtatanong na ang ilang paparating na Ethereum improvement proposals (EIPs) gaya ng renta ng estado mangangailangan ng maramihang pag-upgrade na sunud-sunod na inilalaan para sa ganap na epekto.

Tatlong buwan, gayunpaman, sa mga mata ni Joseph Delong, senior software engineer sa venture capital studio na Consensys, ay "masyadong QUICK para sa isang turnaround."

Sumang-ayon ang pinuno ng pangkat sa Ethereum Foundation Péter Szilágyi, na nagpapaliwanag:

"Bilang isang developer ng kliyente ng [software] kung ang trabaho mo lang ay magpatupad ng mga hard forks at gawin ang mga ito, ayos lang ang tatlong buwan ngunit kadalasan ang mga kliyente ay nangangailangan ng maraming maintenance. Kaya, kung sisimulan mong gumawa ng tatlong buwang hard forks, ito ay talagang aabutin ang lahat ng oras mula sa pangkalahatang pagpapanatili at mga pagpapabuti ng pagganap."

Ang pinuno ng seguridad ng Ethereum Foundation na si Martin Hoste Swende, habang sumasang-ayon na ang isang hard fork tuwing tatlong buwan ay "magiging isang masamang bagay," nabanggit na ang mga partikular na kaso na may mga simpleng pagbabago na nagkakaisang sinang-ayunan ay maaaring magkaroon ng mas maikling oras ng pagtakbo.

"Ang ideya ay hindi mag-iskedyul ng isang hard fork tuwing tatlong buwan ngunit tingnan kung ang feature X ay tapos na at mayroong mga kaso ng pagsubok at ito ay ipinatupad sa lahat ng mga kliyente. Kung gayon, pagkatapos ay maaari kaming mag-hard fork sa lalong madaling panahon," argued Swende sa panahon ng tawag.

Ngunit hinihikayat ang mga developer na gawin ang kanilang mga plano nang "ONE hakbang" sa isang pagkakataon, sinabi ni Fredrik Harryson CTO ng Parity Technologies na kahit na ang isang timeline ng anim na buwan para sa isang nakaplanong Ethereum hard fork ay hindi kailanman nakakamit.

"Mayroong ilang bagay na malamang na kailangan nating i-automate para magawa nang maayos ang [shorter hard forks]. Karamihan sa mga oras na napupunta sa hard fork ay hindi lang paggawa ng code. Ito ang lahat ng nangyayari," sabi ni Harryson.

Bilang karagdagan dito, binanggit ng tagapayo ng Ethereum Foundation na si Greg Colvin na karamihan sa mga koponan na bumubuo ng mga kliyente ng Ethereum software ay walang kasalukuyang "tamang tao" upang mahawakan ang mga mahahalagang trabaho para sa pagpapatupad ng hard fork tulad ng "pag-set up ng mga testnet, pagpapatakbo ng mga kaso ng pagsubok, paggawa ng pagsubok" bukod sa iba pang mga responsibilidad.

Dito, tumugon si Harryson na ang usapin ay tungkol sa kawalan ng sapat na pananalapi upang maisakay ang mga miyembro ng koponan. "Para sa amin, ito ay pera. T kaming sapat na pera sa likod nito," quipped Harryson.

Mga multi-step na pag-upgrade

Ngunit ito ay hindi lamang isang bagay kung mayroon o hindi dapat magkaroon ng mas madalas na mga hard forks.

Tinalakay din ng mga developer sa tawag ngayon kung may pangangailangan para sa ambisyoso, pangmatagalang pagbabago sa kasalukuyang Ethereum blockchain sa liwanag ng napipintong paglipat sa Ethereum 2.0 – isang bagong network ng Ethereum na kapag ganap nang na-activate ang mga user ay lilipat mula sa kasalukuyang mainnet.

Iminumungkahi na ang mga developer tulad ni Alexey Akhunov at tagapagtatag ng Ethereum na si Vitalik Buterin ay nagbabala laban sa "mga pagbabagong T para sa kaligtasan ng [kasalukuyang Ethereum] chain," tanong ni Harryson:

"Gaano tayo kumikilos sa labas nito dahil ang [EIP 615] ay humahantong sa isang mahabang hanay ng mga pagpapabuti na napupunta sa ilang taon bago tayo makakita ng napakalaking benepisyo mula dito."

Ang EIP 615 ay ONE sa limang panukalang isinasaalang-alang para isama sa susunod na Ethereum hard fork na tinatawag na Istanbul. Nilalayon nitong ipakilala ang mga pagpapahusay sa pinakapuso ng Ethereum codebase na kilala bilang Ethereum Virtual Machine (EVM) na responsable para sa pagpapatupad ng lahat ng self-deploying na linya ng code – tinatawag ding mga smart contract – sa platform.

Ang EVM ay isa ring pangunahing Technology na ginagamit ng iba pang enterprise blockchain na mga inisyatiba tulad ng Hyperledger ay naiulat sa nakaraan upang bumuo ng interoperability sa.

"Ang disenyo ng EVM ay nagpapahirap sa mababang gas, mataas na pagganap ng pagpapatupad. Iminumungkahi naming sumulong sa mga panukala upang malutas ang mga problemang ito sa pamamagitan ng paghihigpit sa mga garantiya sa seguridad at pagtulak sa mga limitasyon sa pagganap ng EVM," nagsusulat ang mga may-akda ng EIP 615 Colvin, Brooklyn Zelenka, Pawel Bylic at Christina Reitwiessner.

Gayunpaman, gaya ng binanggit ni Swende sa tawag ngayon, ang EIP 615 gaya ng iminungkahing ay mangangailangan ng hindi bababa sa dalawang hard fork upang ganap na maisakatuparan at "isang positibong epekto ng bilis" sa aktwal na mga pag-compute ng code sa EVM ay hindi magiging kapansin-pansin hangga't hindi naisakatuparan ang huling hard fork.

"Iyan ang aking pangunahing alalahanin tungkol sa EIP na ito, ito ay maraming trabaho ngunit sa palagay ko ay T ito hahantong sa isang mas mahusay na EVM. Maaaring ito ay mas mahusay para sa mga panlabas na tool tulad ng kung ikaw ay gumagawa ng isang reverse analysis ng mga katangian ng seguridad ng isang matalinong kontrata," sabi ni Swende.

Ang ganitong tool na iminungkahi ni Zelenka ay mahalaga upang matiyak ang patuloy na "forward compatibility" sa paparating na mga upgrade ng EVM tulad ng eWASM at isang maayos na karanasan sa onboarding para sa mga smart na developer ng kontrata dahil sa "isang hindi natukoy na petsa ng paglabas ng Ethereum 2.0."

"Mayroong iba pang mga opsyon para sa mga matalinong developer ng kontrata sa labas. Kailangan nating KEEP buhay ang Ethereum 1.x at nangangahulugan iyon ng patuloy na paglipat," argued Zelenka sa tawag ngayon.

Sumasang-ayon na ipagpatuloy ang debate at talakayan sa EIP sa susunod na mga linggo, napagpasyahan ni Swende na sa kasalukuyan ay nananatiling nag-aalinlangan siya tungkol sa "pagpapatupad ng malalaking pagbabago sa lumang makina na karaniwang tumatagal ng ilang matitigas na tinidor bago ito tuluyang naayos."

Ngunit sumasang-ayon sa hindi tiyak na damdamin tungkol sa hinaharap ng Ethereum 2.0, si Harryson, na nagtaas ng unang tanong tungkol sa mapaghangad, multi-hard fork upgrade ay nagsabi:

"T namin dapat ayusin ang aming roadmap o pag-iisip batay sa kung ano ang maaaring o hindi maaaring maging Ethereum 2.0."

Larawan ng tinidor sa pamamagitan ng Shutterstock