Ang unang desisyon ni Gavin matapos bumalik: Hindi na lang gagawa ng infrastructure ang Parity, gagawa na rin ng mga produkto!

Sa nakalipas na dalawang taon, naharap ang Polkadot sa isang pundamental na suliranin: ang teknolohiya ng chain ay world-class na, ngunit napakakaunti ng mga aplikasyon na tunay na tumatakbo rito.

Maaaring tumakbo ang DeFi, ngunit halos natigil ang iba pang mga eksena ng Web3. Walang sapat na panlabas na developer na “gumagamit ng Polkadot para bumuo ng aplikasyon,” kaya’t nagkaroon ng bottleneck sa pagpapalawak ng ecosystem.

Kaya nang bumalik si Gavin sa Parity upang pamunuan ang direksyon, naging napakalinaw ng isang bagay —— kung walang gagawa ng mga Web3 application, kailangang unahin ng Parity na gawin ito mismo.

Hindi lang ito simpleng “gumawa ng ilang demo.” Isa itong estratehikong pagbabago —— mula sa “Parity ang bahala sa infrastructure, ang ecosystem ang bahala sa applications” patungo sa “Parity ang unang gagawa ng tunay na prototype ng application na kayang palitan ang Web2, at personal na patutunayan ang halaga ng teknolohiya ng Polkadot.”

Sa episode na ito ng “Space Monkeys,” unang sistematikong ipinaliwanag ng VP of Engineering na si Pierre ang mga sumusunod:

• Bakit nabigo ang external builder model 
• Bakit kailangang muling gumawa ng produkto 
• Bakit kailangang “EVM muna bago PVM” ang Polkadot Hub 
• Bakit itinutulak ni Gavin ang “iteration every two weeks” 
• Bakit muling binubuo ng Polkadot ang buong application stack ng decentralized computing, storage, notification, at identity 

Makikita mong malinaw na binubuo ng Parity ang isang “decentralized AWS + Web2 replacement layer.” Ito ang magpapasya kung makakabalik sa unahan ang Polkadot sa ikalawang yugto nito.

Bakit kailangang “mismong bumuo ng aplikasyon” ang Parity?

Jay: Maligayang pagdating sa pinakabagong episode ng “Space Monkeys”! Ang panauhin natin ngayon ay si Pierre Aubert, VP of Engineering ng Parity. Napakaswerte naming muli siyang maimbitahan, matagal-tagal na rin mula nang huli siyang bumisita. Noon ay kakapasok pa lang niya sa Parity. Ngayon ay pag-uusapan natin ang mga natutunan niya, mga pagbabagong napansin niya, at ang direksyon ng hinaharap. Welcome back, Pierre!

Pierre: Salamat, hello sa lahat!

Jay: Dati kang nagtrabaho sa Google, at noon pa lang ay iniisip mo na ang anyo ng Web3 network systems at kung paano ka makakatulong dito. Ngayon, ano ang mga natutunan mo?

Pierre: Ngayon ay mas malinaw na sa akin kung paano gumagana ang buong sistema, at may magagandang ideya na rin ako kung ano ang maaari naming gawin. Malaki ang potensyal ng sistemang ito, maraming bagay ang maaaring maisakatuparan, ngunit mahirap itong gawing realidad.

Sa kasalukuyan, maliban sa DeFi (decentralized finance), mabagal ang progreso ng ibang larangan ng Web3. Kamakailan, bumalik si Gav bilang lider ng kumpanya at nagpasya siyang gawing mas nakatuon sa produkto ang kumpanya, at naniniwala akong tama ang direksyong ito.

Dalawang taon na ang nakalilipas, ang aming ideya ay Parity ang magtatayo ng blockchain infrastructure, at ang mga aplikasyon ay gagawin ng mga panlabas na developer. Ngunit napatunayan ng mga pangyayari na hindi ito umunlad ayon sa inaasahan. Ngayon, ang aming estratehiya ay kami mismo ang gagawa, magsisimula sa maliliit na prototype ng aplikasyon, upang ipakita kung paano gamitin ang decentralized system, at patunayan na ang ganitong arkitektura ay kayang gumawa ng kapaki-pakinabang na produkto.

Kaya ang unang hakbang ay kami mismo ang gagawa ng mga application na ito, at kami rin mismo ang gagamit, na tinatawag na “dogfooding” (pagsubok gamit ang sariling produkto). Marami sa mga unang aplikasyon ay tututok sa mga tool na ginagamit namin araw-araw, at ang layunin ay palitan ang mga ito gamit ang decentralized system. Kapag sapat na itong mature sa internal use, saka ito ilalabas sa mga user. Halimbawa, sa Web3 summit, hindi namin nagamit ang sarili naming teknolohiya: ang mga ticket ay binili sa pamamagitan ng tradisyonal na Web2 company, at Euro ang ginamit na pambayad; ang access control system ng venue ay Web2 architecture din. Ito ay isang eksenang maaari naming pasukan, at kayang-kaya naming gamitin ang sarili naming teknolohiya para bumuo ng mas ligtas at mas bukas na sistema.

Jay: Ang mga sistemang ito ay napaka-episyente at stable na. Ano ang saysay ng pag-convert sa Web3 system?

Pierre: Kung tingin mo ay sapat na ang centralized system, ayos lang. Lalo na sa mga eksenang tulad ng ticketing. Pero sa mga eksenang tulad ng access control, kitang-kita ang bentahe ng decentralization. Halimbawa, kapag pumunta ka sa hotel, bibigyan ka ng room card para makapasok, pero sa totoo lang, maraming tao sa hotel ang kayang mag-duplicate ng card at papasukin ang kahit sino. Sa Web3 system, ikaw lang ang makakagawa ng sarili mong access credential, kaya mas mataas ang seguridad.

Kaya depende talaga sa eksena ng aplikasyon. May mga eksenang madaling makita kung bakit mas maganda ang decentralization. Halimbawa, ayaw ko talaga sa mga tradisyonal na Web services ngayon: halos tuwing anim na buwan, may isang kumpanya na naha-hack at nalalantad ang aking data—address, password, bank card info, atbp. Simple lang ang dahilan: hindi sapat ang seguridad ng mga sistemang ito.

Ang gusto ko ay Polkadot na “default secure”: dahil akin ang data ko. Halimbawa, kapag bumili ako ng ticket, hindi ko kailangang ibigay ang home address ko. Kailangan ko lang magbigay ng zero-knowledge proof na talagang nakatira ako sa isang lugar, pero hindi mo malalaman ang eksaktong address ko. Kaya kahit ma-hack ang system mo, hindi pa rin malalantad ang tunay kong impormasyon. Ayaw kong ang personal kong data ay basta-basta na lang kinokolekta at nalalantad. Maaaring dahil sa security, o privacy lang. Sa madaling salita, kahit sa mga mature na system ngayon, kung magagawa itong decentralized, magiging mas maganda at mas secure pa rin ito.

Paano pinapataas ng Parity ang work efficiency?

Jay: Sa nakalipas na dalawang taon, malaki ang effort ninyo sa pagbuo ng decentralized system. Simula nang maging VP of Engineering ka, saang aspeto naging maganda ang performance ng Parity?

Pierre: Sa totoo lang, ang ginawa ko ay mga “basic management” lang, hindi komplikado, inayos lang ang management system. Maganda ang naging resulta, tumaas ang productivity. Simple lang, tulad ng pagtatayo ng standard process system. Lalo na gusto ng mga engineer ang maayos at malinaw na environment. Kapag malinaw ang process at responsibility, natural na lumalabas ang fairness. Halimbawa, pinopromote namin ang mga talagang magaling, at kung sino ang mas magaling ay mas mataas ang sahod, at transparent ang proseso. Gustong-gusto ng mga engineer ang ganitong fairness: kung mas mataas ang sahod mo, ibig sabihin mas magaling ka talaga. Na-appreciate ito ng lahat, at gusto ko rin ang ganitong paraan, naniniwala akong ito ang dapat na takbo ng isang healthy organization.

Jay: Para sa mga namumuno ng team, kahit maliit lang, may practical tips ka ba, tulad ng paano mag-assess ng empleyado, magdesisyon ng promotion o delegation? Anong qualities ang tinitingnan mo sa paglago ng empleyado?

Pierre: Mas pinapahalagahan namin ang resulta, hindi ang proseso. Halimbawa, may mga taong sobrang sipag, at pinapakita sa lahat na nagsusumikap sila, pero walang resulta. Sa kabilang banda, may mga taong matalino magtrabaho, baka 20 oras lang sa isang linggo, pero natatapos ang trabaho at may tunay na impact. Iyon ang mas dapat kilalanin. Sa madaling salita: mas mahalaga ang smart work kaysa hard work.

Jay: Napansin mo ba kung anong common traits ng mga empleyadong hindi nagkakaroon ng resulta? Busy sila pero walang output. Ano ang kadalasang dahilan?

Pierre: Sa totoo lang, kadalasan hindi sila ang may problema, kundi management. Madalas hindi malinaw sa kanila ang goal ng trabaho nila, hindi nila alam kung ano talaga ang dapat gawin. Ang “lack of clarity” na ito ang nagpapahirap sa trabaho. Lalo na sa Parity, malalakas ang mga tao, kaya kung may hindi nakakagawa, kadalasan dahil hindi malinaw ang direksyon.

Kaya ang pinakamahalaga ay gawing malinaw at tiyak ang mga goal. Isa pa, minsan hindi alam ng team member kung kanino lalapit kapag may problema. Dati, hindi maganda ang Parity dito, pero inayos na namin: malinaw na ngayon kung sino ang responsable sa bawat bagay. Ang taong iyon ang magdedesisyon: “kaliwa ba o kanan?” Kapag malinaw ito, tuloy-tuloy ang trabaho ng team.

Jay: Tama, relate ako diyan. Dati, laging may nagtutulak ng responsibilidad: “ibang tao ang magdedesisyon, hintayin ko muna sila bago ako magpatuloy.” Kaya natetengga ang trabaho.

Pierre: Oo, malinaw na responsibilidad ang susi. At hindi naman ito komplikado, kadalasan isulat lang at ipaliwanag. Isa pang hindi maganda, may mga taong kapag nagtagumpay, “dahil magaling ako”; pero kapag pumalpak, kasalanan ng iba. Hindi tama iyon. Hindi puwedeng kunin mo ang credit sa tagumpay, tapos isisi mo sa iba ang failure.

Kaya ang benepisyo ng “clarity” ay mas smooth na takbo ng organization. Hindi nito babaguhin nang malaki ang araw-araw na trabaho mo, pero sa long term, mas efficient ang buong kumpanya.

Ang estratehiya ng Polkadot Hub: EVM muna, saka PVM

Jay: Pag-usapan natin ang Polkadot Hub project. Matagumpay ba ito o hindi?

Pierre: Masasabi kong oo at hindi. Sa kalidad ng produkto, matagumpay ang project, maganda ang naging resulta.

Pero sa paraan ng pagtatrabaho, may mga bagay na puwedeng pagbutihin. Halimbawa: sa simula ng project, pinili naming gamitin ang PVM technology dahil mas maganda ang performance nito. Pero matapos ang isang taon, napansin naming karamihan sa malalaking smart contract sa Ethereum ay hindi tumatakbo sa PVM, at nagulat kami. Dapat mas maaga naming natest ito, pero na-underestimate namin ang complexity ng EVM ecosystem. Nang maglaon, napagtanto naming kailangan talagang suportahan ang EVM. Kaya nag-backport kami ng EVM support sa system, na nagpalito sa project.

Bukod pa rito, na-underestimate din namin ang complexity ng maraming bagay sa Ethereum ecosystem, tulad ng testing frameworks (tulad ng Anvil), Gas mapping, atbp. Kaya, natutunan namin na bago simulan ang project, dapat malinaw at nakasulat ang plano. Lalo na sa complex projects, hindi puwedeng “mukhang madali” lang at basta simulan.

Ngayon sa crypto industry, madalas sinasabi ng iba: “Bahala na, gawin na lang!” Kapag may nagsabi niyan, hinihingi ko agad ng documentation. Maraming bagay na mukhang simple, pero kapag ginawa na, sobrang hirap pala, kaya mas matagal at mas maraming resources ang kailangan kaysa sa inaasahan.

Sa kabuuan, matagumpay ang Hub sa performance at quality, pero hindi pa ideal ang engineering practice, masyadong mahaba ang development cycle.

Jay: Gets. Nakilahok ka ba sa pagpapatupad ng Hub project? Narinig ko na sinusubukan ninyong hikayatin ang ibang projects na lumipat dito.

Pierre: Hindi ako ang technical lead, pero ako ang pumili at bumuo ng tamang team, at nagtakda ng quality standards para siguraduhing stable ang system. Halimbawa, sobrang satisfied ako sa asset migration, maraming effort ang nilaan dito at napaka-professional ng pagkakagawa. Ipinapakita nito na kaya na ng Parity ang malalaking migration nang hindi naaapektuhan ang users. Hindi ito “startup level” na trabaho, kundi engineering quality na pang-malaking kumpanya. Totoong gumastos kami ng oras at resources, pero napatunayan naming kapag nagdesisyon kaming gawin, kayang-kaya naming abutin ang mataas na standard, at magandang signal ito para sa hinaharap: kung mapapanatili namin ang ganitong quality sa mga susunod na project, hindi magiging problema ang technology mismo.

Jay: Ang goal ng ecosystem na ito ay gawing mas madali para sa mga project na sanay sa EVM o Solidity smart contract na mag-deploy. Sa simula, anong mga project ang papasok? Ano ang deployment process? Diretso ba sa EVM, o lilipat sa PVM?

Pierre: Depende. Para sa malalaking contract sa Ethereum, wala silang incentive na lumipat sa PVM. Kaya una naming papayagan silang mag-deploy sa EVM, compatible naman ito at simple lang, diretso lang ang deployment.

Jay: Iyon ang mga “blue-chip” DeFi protocols, tama? Halos lahat ng major chain ay meron sila.

Pierre: Hindi naman sila makikinabang nang husto sa performance ng PVM, hindi naman nila kailangan ng heavy computation. Karamihan sa smart contract nila ay: magbasa ng account balance → mag-execute ng kaunting logic → isulat pabalik ang resulta. Walang heavy computation, ang bottleneck ay sa data read/write, at sapat na ang performance ng EVM dito. Ang bentahe ng PVM ay sa mga task na nangangailangan ng heavy computation, sa hinaharap maaari nating gawin sa chain ang mga bagay na ngayon ay kailangang gawin off-chain. Dito tunay na magagamit ang PVM.

Jay: Halimbawa, anong mga bagay ang puwedeng gawin?

Pierre: Maaari kang mag-compute ng ZK-SNARK on-chain. Sa PVM, maraming bagay na hindi magawa sa EVM ang puwede mong gawin. Maganda ito para sa crypto ecosystem, dahil mas maraming bagay ang mailalagay on-chain, mababawasan ang mga kakaibang offline na solusyon at dependency sa third-party oracles.

Sa kabuuan, mas maraming logic na mailalagay on-chain ay mas maganda. Kung gagayahin ng crypto world ang Web2, palaging puno ang CPU; kapag binigyan mo ng mas maraming computation resources, palaging may paraan ang tao para gamitin ito.

Ngayon meron na tayong Polkadot bilang computation system, at nagtatayo tayo ng storage at notification system

Jay: Sige. Tungkol sa paglipat sa productization, nabanggit ni Gavin sa internal meeting ng Parity na gusto niyang mag-iterate ng produkto kada dalawang linggo, mabilis na maglabas ng maraming produkto. Gagamitin ba ng mga produktong iyon ang PVM at Hub? O iba ang tech stack?

Pierre: Depende sa produkto, pero karamihan ay gagamit ng smart contract.

Jay: Ah, okay. Ibig sabihin, karamihan ng produkto ay hindi muna gagamit ng rollup + parachain na solusyon?

Pierre: Depende, masyado pang maaga para magdesisyon. Halimbawa, ang storage o notification services ay malamang na magiging hiwalay na parachain, pero ang mga eksenang tulad ng access control, kayang-kaya na ng smart contract.

Jay: Kumusta ang progress ng storage project? Parang ilang beses na tayong sumubok ng iba’t ibang storage solution, pero wala pang unified solution.

Pierre: Ang storage ang isa sa pinaka-komplikado at pinaka-importanteng task namin. Ang goal ay gumawa ng usable decentralized storage system. Kahit ang pag-define ng “usable” ay hindi madali, kaya kailangan ng ilang iteration. May team sa ecosystem na gumagawa nito, pati Moonbeam ay may related na trabaho.

Jay: Ang tinutukoy mo ba ay tulad ng DataHaven?

Pierre: Oo, tulad ng DataHaven, pati Eiger (gumagawa rin ng ilang low-level primitives). Sa loob ng Parity, gumagawa rin kami ng built-in on-chain storage; may mga project din tulad ng JamDA. Maraming team ngayon ang nagtutulak ng decentralized storage projects, iba-iba ang features, at maaaring kailanganin natin ng higit sa isang storage solution: kailangan natin ng murang decentralized storage (halimbawa, para sa pag-upload ng larawan, hindi dapat mahal), at kailangan din ng mas “mabilis” na storage para sa madalas na read/write pero hindi kailangang mag-store ng sobrang daming data.

Kaya malamang na magkakaroon ng maraming storage solution, o isang software na configurable sa iba’t ibang mode. Sa ngayon, ang ideya ay maaaring gamitin ang JamDA bilang short-term/temporary storage: pansamantala ang data, halimbawa, mag-e-expire pagkatapos ng 28 araw.

(Maaaring mali ang spelling ng JamDA, welcome ang corrections)

Jay: Maliban na lang kung magre-renew ka?

Pierre: Oo, puwedeng mag-renew. O maaari rin tayong magtayo ng large-scale distributed decentralized system sa ibabaw ng JamDA, para makapili ka ng long-term data retention. Halimbawa, nagsulat ka ng research paper at gusto mong pangmatagalang i-publish, doon gagamitin ang long-term storage. Kaya maaaring maging “temporary + long-term” na two-stage system.

Jay: Anong features ng system na ito ang hindi kayang ibigay ng IPFS?

Pierre: Halimbawa, hindi nagbibigay ng availability guarantee ang IPFS. Maaari mong i-upload ang dokumento, pero walang kasiguraduhan na mababasa mo ito sa hinaharap.

Jay: Ang mga nabanggit mong solution, sa huli ba ay gagamit ng security ng Polkadot? Ibig sabihin, tatakbo sa security model ng Polkadot?

Pierre: Sa huli, oo, pero sa simula, hindi pa.

Jay: Anong ibig sabihin?

Pierre: Halimbawa, maaari muna tayong gumamit ng existing system tulad ng Filecoin, tapos magdagdag ng layer sa ibabaw nito para tingnan kung sapat na ang features. Kapag mature na ang sarili nating solution, saka natin palitan ang Filecoin o iba pang solution. Hindi pa final ang plano.

Ang next step ay gumawa ng built-in on-chain function, tapos JamDA, tapos unti-unting i-integrate ang ibang solution, kaya kailangan pa ng panahon para maging stable ang solution.

Magkaiba ang storage at computation: kung nagka-problema ang computation, puwede mong ulitin, sanay na tayo doon (halimbawa, kapag nagka-problema ang browser, i-refresh lang); pero mas komplikado ang storage, halimbawa, nag-upload ka ng encrypted na larawan online, siguradong gusto mong mabasa ito ulit, hindi man agad-agad, pero dapat 100% sure na mababawi ang backup. Kaya mas mataas ang expectation ng tao sa storage kaysa computation.

Jay: Tama. Palapit na tayo sa paggawa ng decentralized “cloud” o “server,” at unti-unti nang nabubuo ang lahat ng components.

Pierre: Tama, dahan-dahan lang. Makikita mong binubuo namin sa decentralized na paraan ang maraming karaniwang serbisyo sa Web2, iba-iba ang features pero pareho ang core system. Ngayon meron na tayong Polkadot bilang computation system, at nagtatayo tayo ng storage at notification system.

Jay: Nabaggit mo kanina ang “notification system,” ano ang ibig sabihin nito?

Pierre: Halimbawa, may application ka, kapag may nag-reply sa iyo, nag-comment sa dokumento mo, o may interaction, kailangan mong makatanggap ng notification, di ba? Iyan ang notification system. Pero ang problema, sa internet communication, kadalasan pareho tayong nasa likod ng firewall, kaya hindi ako makakonekta diretso sa iyo. Karaniwan, gumagamit ng centralized server bilang relay. Ang server na ito ang “nagbubukas ng pinto,” nagse-set up ng koneksyon, saka tayo makakapag-peer-to-peer communication.

Jay: Parang gumagawa tayo ng private chatroom.

Pierre: Oo, tama. Ang gusto naming gawin ay palitan ang central server ng decentralized solution, pero pareho pa rin ang communication capability. Mas komplikado lang dahil gusto rin naming may extra features, tulad ng: walang dependency sa anumang centralized authority, walang traceable metadata. Halimbawa, sa Signal, hindi alam ng iba kung ano ang pinag-uusapan natin, pero alam nilang “nag-uusap tayo.” Sa system na gusto naming buuin, kahit “kanino ako nakikipag-chat” ay hindi mapapatunayan.

I-follow ang PolkaWorld WeChat Official Account, ibabahagi namin sa susunod na artikulo ang iba pang bahagi ng panayam kay Pierre!