Ang Pagre-review sa Code ay Nakaka-Numbing: Q&A Sa Bitcoin Maintainer na si Andrew Chow

Ilang tao ang nakakaunawa sa mga pangunahing isyung teknikal na kasalukuyang kinakaharap ng nangingibabaw Cryptocurrency sa mundo . ONE na rito si Andrew Chow.

ONE si Chow sa apat na “maintainer” para sa Bitcoin CORE (o CORE lang ), ang pinakasikat na software para sa pagkonekta sa network ng Bitcoin .

Sinusuri ng mga maintainer ang mga pagbabago sa Bitcoin CORE na kilala bilang “commits,” na isinumite – ng mga kapwa developer ng Bitcoin – bilang “pull requests” o “PRs.” Pagkatapos ay aprubahan o "pagsamahin" ni Chow at ng iba pang mga maintainer ang mga pagbabagong iyon sa source code ng Core. Ang "pagsusuri ng code" ay mahalaga sa pagtiyak na walang buggy code na maisasama.

Ang proseso ay transparent, at habang si Chow ay nagsusuklay sa pamamagitan ng commit niya livestream ang proseso sa Twitch.

Si Chow ay isang pusong gamer, at nakapasok lang sa Bitcoin noong high school para magbayad para sa mga video game na T niya kayang bayaran. Ang kanyang mga magulang ay T magbibigay sa kanya ng isang credit card, magbukas ng isang bank account para sa kanya o kahit na magbigay sa kanya ng isang allowance. Siya resorted sa freelancing sa BitcoinTalk forum at nagsimulang magsulat ng code kapalit ng Bitcoin (BTC).

Si Chow, na nagsasabing siya ay nasa mid-20s na ngayon, ay binabayaran bilang isang engineer sa Bitcoin infrastructure firm na Blockstream, kung saan bukod sa ilang mga corporate na gawain, ang kanyang pangunahing priyoridad ay nagtatrabaho sa Bitcoin CORE.

Sinabi niya na ang pagsusuri ng code ay ONE sa mga pinakamalaking hamon na kinakaharap ng Bitcoin ngayon. Karamihan sa mga CORE developer ay masigasig na magsulat ng code para sa mga bagong feature, ngunit kakaunti ang nasiyahan sa mas karaniwang gawain ng pagrepaso ng code na isinumite ng kanilang mga kapantay. Sinabi ni Chow na mas maraming Contributors ang kailangang tumuon sa pagsusuri ng code upang matugunan ang 300-plus na PR sa Core's GitHub repository. Ang komunidad ay may a Bitcoin CORE PR Review Club na nagpupulong linggu-linggo upang matulungan ang mga bagong Contributors Learn ang tungkol sa proseso ng pagsusuri.

Sumang-ayon si Chow sa isang panayam sa CoinDesk sa Pagsulong ng Bitcoin kumperensya sa London. Ipinaliwanag niya kung bakit napakahalaga ng pagsusuri ng code, ipinaliwanag kung ano ang ginagawa ng mga Contributors ng Bitcoin CORE araw-araw, at tinitimbang ang kasalukuyang debate tungkol sa op_vault at Mabilis na Pagsubok. Narito ang isang bahagyang transcript ng panayam na iyon.

CoinDesk: Paano mo natuklasan ang Bitcoin?

Andrew Chow: Noong bata pa ako, noong high school, T akong bank account dahil wala pa akong 18. T ako ONE ng mga magulang ko. T akong credit card – kahit isang pinangangasiwaang credit card – at T akong allowance. Pero singaw ay nagbebenta ng mga laro para sa Bitcoin. Kung naglalaro ka ng PC, maaari mong i-download ang Steam at mayroon itong karaniwang lahat ng mga laro sa PC.

Gayundin, sa pitaka.io, maaari kang magbenta ng Bitcoin para sa mga bagay-bagay. Well, gusto kong maglaro. Nais kong bilhin ang mga ito. I mean, okay lang ako sa pirating pero, you know, parang sketchy ang pirating things. T mo alam kung ano ang iyong dina-download. Maaaring ito ay kumpletong malware.

Kaya ako ay, tulad ng, ito Bitcoin bagay ay ganap na electronic. Siguro magagamit ko iyon para bumili ng mga laro – ngunit paano ako makakakuha ng Bitcoin? Siguro maaari akong gumawa ng ilang trabaho at mabayaran sa Bitcoin.

May kakilala akong ilang tao na gumawa niyan. Kaya ayun natuto ako ng programming. Pupunta ako sa BitcoinTalk at sasabihin ng mga tao, "Babayaran kita kahit gaano kalaki para magsulat ako ng script na gumagawa nito."

Well, iyon ay tila sapat na simple. Nagkaroon din ako ng kaibigan noong high school. Siya ay, tulad ng, "Hoy, narinig mo na ba ang tungkol sa bagay na ito sa Bitcoin ? Sa tingin ko ay magustuhan mo ito." Tiyak na bumibili siya ng mga gamot gamit ang Bitcoin.

Kaya ayun nakapasok ako sa Bitcoin. At kalaunan ay nasabi ko, "Buweno, ginagamit ko ang wallet na ito at napapaharap ako sa mga isyung ito. Malinaw na alam ko kung paano magsulat ng isang programa. Siguro maaari kong ayusin ang wallet na ito." Iyon ay kung paano ako pumasok sa paggawa ng pag-unlad.

Pinapatakbo ko ang bagay na ito na tinatawag Armory. Na karaniwang hindi pinananatili. Ibig kong sabihin, ito ay pinapanatili pa rin ng ONE lalaki, kaya bahagya.

Sa oras na ginagamit ko ito, ito ay isang uri ng gulo at T ito palaging gumagana. Nalaman ko na ang ilan sa mga problemang nangyayari sa Armory ay sanhi ng mga bagay na ginagawa ng Bitcoin CORE . Kaya nagsimula akong pumunta sa Bitcoin CORE at magtanong kung ano ang ginagawa ng Bitcoin CORE ? Oh, may ganitong bug ang Bitcoin CORE na nagiging sanhi ng pagkakaroon natin ng bug.

May ginagawa si Armory na hindi inirerekomenda, na basahin ang mga block file nang direkta mula sa Bitcoin CORE – hindi mo dapat gawin iyon. Noong binago nila ang format, sinira nito ang lahat.

Sinusubukan kong ipagkasundo ang dalawa, at pagkatapos ay medyo nahulog si Armory sa aking mapa. Ganyan ako lumipat sa Bitcoin CORE. Sa kalaunan ay tumigil ako sa pagtatrabaho sa Armory dahil mas marami akong nagawa sa CORE.

Kahapon ay pinag-usapan natin ang ratio ng mga Contributors ng Bitcoin na nagsusuri ng code kumpara sa mga Contributors na nagsusulat ng code. Maaari mo bang ibahagi ang iyong mga saloobin tungkol diyan?

Ang aming pangunahing bottleneck sa Bitcoin CORE ay nasuri. Mayroon kaming 300-plus Mga PR bukas at kailangan nilang suriin. Kung ito ay para lamang matiyak na ang code ay mabuti o tulad ng konsepto, "Gusto ba natin ang pagbabagong ito?"

Ang problema sa bawat PR ay karaniwang ONE tao ang nagsusulat nito, ngunit kailangan namin ng maraming tao upang suriin ito, magbigay ng pag-apruba o mag-iwan ng mga komento. Samakatuwid, dapat tayong magkaroon ng mas maraming tagasuri kaysa sa mga taong nagsusulat, ngunit hindi iyon kung paano ito gumagana.

Sa personal, nakikita kong BIT boring ang pagsusuri ng code. Ito ay medyo nakakainis at maaari itong maging isang uri ng isip-numbing. Pero ginagawa ko pa rin. I guess it's like a needed evil and it's because I do T find it fun. If I do it enoug I start feeling like I'll burn out because it's no longer enjoyable.

Kaya kailangan mong makahanap ng ilang balanse sa pagitan ng pagsulat ng code at pagsusuri ng code. Ito ay isang BIT ng catch-22. Kailangan nating magkaroon ng mas maraming reviewer kaysa sa mga coder, ngunit paano ka magiging sapat na kakayahan upang suriin ang code kung hindi ka nagsusulat ng code? Ito ay isang palaisipan.

Kami ay nasa isang bear market at ang mga organisasyon tulad ng Brink na nagpopondo sa pagpapaunlad ng Bitcoin ay nagsasabi na ang pagpopondo ay bumaba ng humigit-kumulang 50%. Bakit kailangan nating magbayad ng mga Bitcoin Contributors at developer?

Sa panimula, ang bawat piraso ng software ay may mga bug. Palaging may mga bug na hahanapin at mga bug na aayusin. Pangkalahatang maintenance ng software lang yan ang dapat mangyari.

At kahit na noon, ang software na umiiral ngayon ay hindi maaaring tumagal magpakailanman. Magbabago ang mga operating system at mag-evolve at magbabago ang mga library. Sa kalaunan ang software ay hihinto lamang sa pag-compile sa isang computer; baka huminto lang ito sa pagtakbo. At kaya, kailangang magkaroon ng patuloy na trabaho para lang KEEP itong napapanahon.

Kaya laging may mga bagay na dapat i-update, kahit na walang mga bagong feature. Ngunit may mga bagong feature at gusto naming pagbutihin ang Bitcoin. Hindi lang ang mga patakaran ng pinagkasunduan, kundi pati na rin kung paano namin i-relay ang mga transaksyon, kung anong uri ng mga transaksyon ang tinatanggap namin sa mempool at ang peer-to-peer na protocol.

Maaaring meron DoS mga vector na gusto nating ayusin o baguhin na marahil ay T pa natutuklasan. Laging may something.

Kung isa akong bagong CORE contributor, ano ang ilan sa malalaking isyu na kailangan kong malaman?

Sa kasalukuyan ay may ilang mga isyu na umiiral, tulad ng pag-atake ng pinning, na medyo mahusay na dokumentado. Tila ONE nagsasamantala sa kanila, ngunit hindi iyon magandang dahilan upang hindi ayusin ang mga ito.

Nagkaroon ng maraming trabaho sa mempool – paano at anong mga transaksyon ang tinatanggap sa mempool, kung anong mga pamamaraan ang mayroon para sa pagtaas ng bayad, at mga bagay na katulad niyan. Ito ay may kaugnayan sa Kidlat at iba pang [layer 2] network.

Ano ang "pinning attack?"

Kung pareho tayong magbubukas ng Lightning channel nang magkasama, magagawa ko ito upang hindi mo mabayaran ang bayad sa transaksyong iyon. Kaya't maaari kong gawin itong walang hanggang mababang bayad at hindi na ito mamimina, pagkatapos ay subukang i-double-gastos ito sa ibang pagkakataon.

Mayroong maraming mga pag-atake na maaari mong gawin sa mga umiiral nang Policy sa mempool. Nakadokumento ang mga ito sa mailing list at tiyak na mga problema ang mga ito. Kung sinubukan ng isang tao na pagsamantalahan ang mga ito ay nakakainis, ngunit sa palagay ko ay T namin nakita ang sinumang sumubok na pagsamantalahan sila.

Gusto pa rin naming ayusin ang mga ito at napakaraming trabaho sa paggawa ng mga pagpapabuti para T kami magkaroon ng mga pag-atakeng ito sa pag-pin, o hindi bababa sa, kung gusto mong mag-pin ng isang transaksyon, talagang magastos.

Tinalakay din namin ang op_vault at Speed ​​Trial kahapon. Nagkaroon ng ilang tensyon sa rekomendasyon ni James O'Beirne na mag-deploy ng op_vault gamit ang Speedy Trial. Any comments?

Sa isang bagong panukala na tulad nito, ang pag-deploy ay dapat ang huling bagay na dapat isipin.

Ang ilang mga ideya sa kung paano mag-deploy ng mga bagay ay, sa ilang kadahilanan, pinagtatalunan. Kung gusto mong magkaroon ng talakayan tungkol sa panukala, ang pagkakaroon ng deployment doon ay nagiging sanhi ng pagkadiskaril nito.

Kaya sa palagay ko, malamang na isang pagkakamali ang paglalagay ni James. Ang Taproot Ang seksyon ng deployment ay T tinukoy hanggang pagkatapos ng Taproot. Ang mga pagbabago sa code mismo ay pinagsama sa Bitcoin CORE ngunit hindi aktibo. Hindi karaniwan na sabihing haharapin natin ang pag-deploy pagkatapos nating malaman kung ano ang gusto nating maging pagbabago sa code.

Ang Speedy Trial ay isang eksperimento para sa Taproot. Sinubukan namin ang iba't ibang paraan ng pag-deploy sa mga nakaraang taon na may iba't ibang antas ng tagumpay.