Ang Pangangailangan ng Interoperability sa mga Protocol ng Security Token – Mga Nangungunang Isip

Maikling Kasaysayan ng mga Token

Mahigit sampung taon na ang nakalipas mula nang unang ipakilala ng Bitcoin ang teknolohiyang blockchain sa mundo. Sa panahong iyon, mabilis na lumawak ang listahan ng mga posibleng gamit para sa mga distributed ledger, mula sa mga digital na pera, hanggang sa mga supply chain, at pamamahala ng pagkakakilanlan. Sa kanilang pinakapuso, marami sa mga gamit na ito ay may magkatulad na estruktura: pinahihintulutan nila ang mga gumagamit na humawak at maglipat ng digital na asset sa isang peer‑to‑peer na batayan. Sa madaling salita, maaari na nating ipagpalit at subaybayan ang mga digital na asset nang hindi kailangan ng isang sentral na pinagkakatiwalaang awtoridad upang pamahalaan ang proseso.

Ang pag‑evolve ng espasyo ay natural na nagdala sa imbensyon ng “mga token” – mga digital na asset sa isang blockchain na maaaring pag-aari at mailipat sa pagitan ng mga indibidwal. Ang mga token ay nahahati sa dalawang pangunahing kategorya: yaong kumakatawan sa isang likas na digital na asset, at yaong kumakatawan sa isang nakapailalim na real‑world na asset. Sa paggamit ng bagong paradigmang ito, daan‑daang libong iba‑ibang token na ang nalikha sa Ethereum lamang, na may pinagsamang market cap na higit sa $15 bilyon noong panahon ng pagsulat.

Isa sa mga pinakapromising na aplikasyon ng mga token ay ang representasyon ng mga real‑world na securities sa blockchain, na nagpapahintulot sa tradisyonal na illiquid na mga asset tulad ng komersyal na real estate na ma‑fractionalize at mailipat nang peer‑to‑peer. Ang prosesong ito, na kilala bilang “tokenization”, ay nakakuha ng malaking atensyon mula sa parehong legacy na institusyon at mga bagong start‑up, dahil sa potensyal nitong mapagaan ang maraming umiiral na pain point sa loob ng mga pamilihan ng kapital.

Pagsunod sa Regulasyon

Bagaman maaaring gawing mas madali ng blockchain ang teknikal na paglilipat ng pagmamay‑ari, ang mga security token ay patuloy na nasasakop ng parehong mga batas at regulasyon tulad ng tradisyonal na securities. Ang pagtiyak na ang mga security token ay sumusunod sa regulasyon ay kritikal sa anumang potensyal na tokenization, at ito ay naging hadlang sa pag‑adopt hanggang ngayon. Tulad ng makikita sa chart sa ibaba, ang regulatory uncertainty ay malawak na itinuturing na pinakamalaking hadlang sa pag‑adopt ng blockchain.

Maraming proyekto ang lumitaw sa blockchain space, bawat isa ay nagdidisenyo ng protocol na sinusubukang pasimplehin at i‑standardize kung paano nireregula, tinatrade, at pinamamahalaan ang mga security token. Sa Ethereum lamang, ang mga proyektong naglathala ng mga pamantayan para sa problemang ito ay kinabibilangan ng Securitize, Harbor, Polymath, at iba pa. Gayunpaman, sa huli, kung walang pagbabago sa kung paano dinisenyo ang mga protocol na ito, magpapatuloy ang mga mamumuhunan at palitan na makaranas ng malaking friction kapag bumibili at nagbebenta ng mga tokenized na securities. Bakit ito nangyayari? Interoperability.

Mahalaga ang Interoperability

Ang interoperability ay isa sa mga pinakamahalagang benepisyo ng tokenization. Pinahihintulutan nito ang isang buong ekosistema ng mga aplikasyon at produkto sa pamilihan ng kapital na mag‑integrate sa isa’t isa dahil nagbabahagi sila ng mga karaniwang software standard. Subalit upang mapagana ang interoperability sa antas ng aplikasyon at produkto, kailangan itong magsimula sa pinakamababang antas kasama ang mismong mga token. Sa security token space, ang interoperability ay mahalaga para sa dalawang pangunahing partido: mga palitan at mamumuhunan.

Bilang isang palitan, nais mong magkaroon ng kakayahang i‑authorize ang mga mamumuhunan para sa pagbili ng anumang security token na kanilang karapat-dapat bilhin – anuman ang kumpanyang lumikha ng token. Ibig sabihin, hindi kailangang magkaroon ng bespoke integration sa bawat security token, kundi isang simple at generic na integration na pare-pareho sa lahat ng security token.

Bilang isang mamumuhunan, nais mo na ang onboarding process ay maging simple at walang friction hangga’t maaari. Sa kasalukuyan, kapag nais ng isang mamumuhunan bumili ng shares mula sa maraming pinagmulan, kailangan niyang paulit‑ulitin ang pagbibigay ng kanyang personal na impormasyon sa prosesong tinatawag na Know Your Customer “KYC”. May potensyal ang blockchain na baguhin ang prosesong ito sa pamamagitan ng pag‑store ng impormasyong ito nang immutable sa blockchain, kung saan maaari itong i‑reference ng lahat ng security token. Ibig sabihin, hindi na kailangang paulit‑ulitin ang pagbibigay ng parehong personal na impormasyon sa tuwing bibili ng bagong token; tanging karagdagang o na‑update na impormasyon lamang ang kakailanganin pagkatapos ng unang rehistrasyon. Gayunpaman, magiging posible lamang ito kung ang interoperability sa pagitan ng mga security token ay disenyo nang bahagi ng mga pamantayan na namamahala sa sistema.

Ang mga Protocol

Tatlong nangungunang security token protocol ng Ethereum ang inilathala ng Securitize, Harbor, at Polymath. Lahat ng tatlong protocol na ito ay nakabatay sa Ethereum ERC‑20 token standard, na kanilang pinalawak upang ipatupad ang compliance sa pag‑trade ng security token. Ito ay nakakamit sa pamamagitan ng pag‑query sa isang pangalawang kontrata hinggil sa legalidad ng bawat trade sa oras na ito ay mangyari.

Bagaman may magkakaibang pangalan sa mga protocol, ang paggamit ng pangalawang kontrata ay pare‑pareho sa lahat ng tatlo, na nagdudulot ng parehong resulta: paghadlang sa mga hindi compliant na trade. Ang pangalawang ‘Regulator’ contract ay pinapanatiling up‑to‑date gamit ang KYC at accreditation information ng mga gumagamit na ibinibigay ng mga off‑chain na serbisyo na awtorisadong gawin ito – halimbawa ay isang palitan, o ang issuer ng token.

Bagaman maaaring mukhang kumpleto ang tatlong komponent na ito para i‑regulate ang isang security token (at sa pinakasimpleng anyo, sila nga ay), ang paraan ng pag‑programa ng mga komponent ang tunay na nagtatakda ng interoperability. Sa kasamaang palad, kulang ang mga protocol sa interoperability sa dalawang pangunahing larangan, na magpapatuloy na magdulot ng friction at magpapabagal sa pag‑adopt ng teknolohiyang ito:

1. Paano ina‑update ng mga awtorisadong partido ang on‑chain na impormasyon tungkol sa mga gumagamit?

Harbor

Ayon sa kanilang whitepaper, ang Harbor ay mag-iisang partido lamang na awtorisadong mag‑update ng user information on‑chain sa kasalukuyan. Ang sentralisasyon ng papel na ito ay nangangahulugang ang mga palitan ay hindi mag‑update ng anumang data na tinutukoy ng Regulator. Dahil dito, hindi nila magagawang aprubahan ang mga bagong tatanggap ng token, na pumipigil sa mga token na madaling ma‑trade sa labas ng platform ng Harbor.

Securitize

Na‑implement na ng Securitize ang isang sistema kung saan maraming partido ang maaaring awtorisado, ibig sabihin ang mga mamumuhunan ay maaaring i‑register ang kanilang compliance information sa maraming lugar at hindi kinakailangang dumaan sa Securitize mismo. Ang on‑chain data ay pagkatapos ay ina‑update nang direkta ng awtorisadong partido, at maaaring makita ng lahat ng token ng Securitize. Higit pa rito, upang maiwasan ang paulit‑ulit na pagbibigay ng impormasyon, nagdisenyo ang Securitize ng isang API na nagpapahintulot sa mga awtorisadong partido na ma‑access ang pribadong impormasyon tungkol sa mga mamumuhunan na naka‑store off‑chain, na nagbibigay-daan sa kanila na madaling matukoy kung ang isang indibidwal ay compliant o kung kailangan pa ng karagdagang impormasyon.

Polymath

Ang Polymath ay may native digital utility token na tinatawag na POLY na kinakailangan sa buong platform upang magsagawa ng iba’t ibang gawain, kabilang ang pag‑update ng iyong on‑chain data ng isang awtorisadong partido. Upang makapag‑KYC ang isang indibidwal, kailangan muna niyang bumili ng POLY tokens, na walang likidong fiat‑to‑POLY market. Sa halip, kailangang bumili ang indibidwal ng ibang cryptocurrency tulad ng Ethereum “ether” (ETH) gamit ang fiat, at pagkatapos ay i‑exchange ito para sa POLY. Ang mga token ay maaaring gamitin sa Polymath KYC marketplace upang mag‑bid sa isang KYC provider. Kapag inaprubahan ng KYC provider ang alok, binabayaran sila ng POLY tokens upang isagawa ang KYC check para sa indibidwal. Ang prosesong ito ay malinaw na nagdadala ng malaking onboarding friction sa platform ng Polymath, at nagpapakomplikado sa proseso nang higit sa kinakailangan.

2. Paano naman ini‑store at ina‑access on‑chain ang impormasyong ito tungkol sa mga gumagamit?

Harbor

Mula sa pagsusuri ng whitepaper at mga smart contract sa GitHub, teknikal na posible para sa maraming token ng Harbor na mag‑share ng isang karaniwang Regulator contract, at mag‑share ng isang karaniwang pinagmumulan ng user data, subalit ito ay hindi malamang dahil sa pagkakaiba‑iba ng regulasyon sa pagitan ng iba’t ibang token. Ang kawalan ng live na Harbor token sa Ethereum ay hindi naglinaw kung ito nga ang kanilang intensyon, o kung ang bawat token ay ide‑deploy na may sariling Regulator.

Securitize

Dinisenyo ang protocol ng Securitize upang ang kanilang Regulator contract ay mag‑query sa isang ikatlong smart contract na nag‑store ng user information. Pinahihintulutan nito ang bawat token na magkaroon ng natatanging regulasyon na naka‑encode sa kanilang sariling Regulator, habang nagbabahagi pa rin ng isang karaniwang pinagmumulan ng user data sa ikatlong kontrata, ibig sabihin kapag nag‑KYC ang isang user para sa isang Securitize token, ang kanyang impormasyon ay naka‑store at handa nang magamit para sa pagbili ng mga susunod na token.

Polymath

Hindi hayagang nakasaad sa kanilang whitepaper kung ang Polymath ay may isang sentral na pinagmumulan ng compliance data na naka‑store on‑chain na kinokonekta ng bawat Regulator, o kung ang mga token ay may sariling lokal na pinagmumulan ng impormasyon. Subalit, batay sa mga sample contract ng Polymath, tila bawat token ay gumagamit ng lokal na pinagmumulan ng impormasyon, na hindi ibinabahagi sa pagitan ng iba’t ibang token. Bagaman maaaring may mga benepisyo ito, ang ganitong setup ay nagdadala ng panganib ng data redundancy at mga hindi pagkakatugma.

Isang halimbawa: Si Bob ay nagpakita ng interes sa dalawang Polymath security token, ang ABC at DEF, at na‑approve bilang mamumuhunan para sa bawat isa. Ang impormasyong ito ay ipinadala sa Regulator contract ng bawat token. Isang buwan pagkatapos, sinusubukan ni Bob na bumili ng karagdagang DEF token ngunit natuklasan na hindi na siya accredited. Ang impormasyong ito ay ipinadala sa Regulator ng DEF upang i‑update ang status ni Bob bilang non‑accredited. Ngayon, sa on‑chain, may magkasalungat na impormasyon: iniisip ng ABC na si Bob ay isang verified investor, subalit hindi sumasang-ayon ang DEF. Madali makita na ang pagkakaroon ng isang sentral na pinagmumulan ng impormasyon ay makakaiwas sa ganitong mga hindi pagkakatugma.

Interoperability ng mga Protocol

Tulad ng tinalakay kanina, may dalawang pangunahing partido na sangkot sa pag‑issue at pag‑exchange ng mga security token na lubos na apektado ng interoperability: mga palitan at mamumuhunan. Parehong partido na ito ay nagnanais ng maayos na karanasan kapag nakikipag‑interact sa iba’t ibang security token. Kaya, kung gagamitin ang mga protocol nang ganito, tingnan natin kung paano maaapektuhan ang mga palitan at mga gumagamit.

Palitan

Bilang isang palitan, madaling i‑integrate ang mga protocol na ito para sa layunin ng transfer: lahat ng token ay gumagamit ng ERC‑20 token standard, na nagbibigay ng isang pare‑parehong interface para sa pag‑invoke ng transfers, approvals, at balance checks. Subalit ang karagdagang integration sa compliance aspect ng bawat protocol ay nagiging mas kumplikado. Maalala mo na hindi pa posible para sa isang trusted party na maging awtorisado sa protocol ng Harbor – kailangan nilang i‑direct ang mga user sa Harbor upang mag‑KYC. Para naman i‑integrate ang protocol ng Securitize, ang trusted party ay dapat awtorisado ng Securitize, na magbibigay-daan sa kanila na ma‑access ang investor KYC data sa pamamagitan ng off‑chain API, at i‑update ang on‑chain information na naka‑store sa on‑chain data store.

Ang pag‑integrate sa protocol ng Polymath ay marahil ang pinakamahirap. Ang trusted party ay kailangang mag‑register bilang isang KYC provider sa Polymath KYC marketplace at mag‑setup upang tumanggap ng mga bid sa POLY tokens kapalit ng pagbibigay ng KYC services. Sa pagbibigay ng KYC services sa mga mamumuhunan, ang trusted party ay kailangang mag‑organisa ng paraan upang matiyak na ang duplicate na on‑chain data na naka‑store tungkol sa isang user sa bawat security’s Regulator④ ay hindi nagiging hindi tugma.

Hindi lamang magkaiba ang mga interface ng mga protocol na kailangang i‑integrate ng trusted party, may iba‑ibang paraan din ang bawat protocol upang mag‑provide ng error reporting sa palitan. Kapag nagbu‑build ng isang interface, mahalagang ma‑translate ang anumang error na nangyayari sa isang bagay na nauunawaan ng mga user. Halimbawa, kung hindi makabili ang isang user ng token, maaaring maraming dahilan: maaaring may holding period ang security na hindi pa natutupad, o maaaring may limitasyon sa maximum na bilang ng mga holder. Upang maiparating ang mga mensaheng ito sa mga user, kailangang mag‑integrate ang palitan ng ibang method ng error reporting para sa bawat protocol.

Mamumuhunan 

Ang iba’t ibang paraan kung paano dinisenyo ang onboarding ng mga mamumuhunan sa mga protocol ay nangangahulugang malamang na kailangang magbigay ang mga mamumuhunan ng personal na impormasyon nang maraming beses sa iba’t ibang platform at sa iba’t ibang paraan. Ito ay dulot ng katotohanang ang Harbor ay hindi nag‑authorize ng ibang partido, at ang Polymath ay nangangailangan ng mga mamumuhunan na mag‑bid para sa KYC process gamit ang POLY tokens. Ang friction na dulot ng pagpapatupad ng mga compliance method na ito ay maaaring mag‑resulta sa hindi pagnanais o kawalan ng kakayahan ng mga mamumuhunan na bumili ng securities na sana ay kanilang bibilhin.

Ang lawak ng friction na dulot ng mga protocol na ito sa mga mamumuhunan ay maaaring bahagyang maibsan sa pamamagitan ng paraan kung paano nag‑integrate ang mga palitan sa bawat protocol. Halimbawa, kung pipili ang isang mamumuhunan na mag‑KYC sa isang palitan upang bumili ng Polymath token, ang palitang iyon, kung awtorisado, ay maaaring sabay na i‑update ang data storage ng Securitize. Ibig sabihin, ang impormasyon ng mamumuhunan ay nasa on‑chain sakaling kailanganin ito sa hinaharap. Subalit, kung walang pagbabago sa kasalukuyang disenyo ng mga protocol, mananatiling nakakatakot ang proseso ng pag‑rehistro at pagbili ng securities.

Mga Solusyon

Ang solusyon sa problemang ito ay hindi kailangang maging komplikado. Sa katunayan, posible na mag‑introduce ng ilang solusyon nang hindi binabago ang anumang token na kasalukuyang live sa Ethereum. Ang isang ideal na solusyon na nagreresulta sa minimal na friction para sa parehong mga palitan at mamumuhunan, at na pumipigil sa data inconsistencies na dulot ng maraming pinagmumulan ng compliance data ay kahawig ng centralized on‑chain data store ng Securitize; subalit, anumang ganitong set‑up ay kailangang ma‑adopt sa antas ng industriya.

Sa pagkakaroon ng isang sentral na pinagmumulan ng impormasyon on‑chain, naaalis ang panganib ng data inconsistencies, at maaaring bumili ang mga mamumuhunan ng iba’t ibang securities sa pamamagitan lamang ng isang compliance verification. Ang sentral na kontrata ay magsasagawa ng verification na ang transfer ay compliant para sa lahat ng security token, at magpapatuloy o magre‑vert ang transfer. Ang off‑chain API na naa‑access ng lahat ng awtorisadong palitan ay nangangahulugang maaaring i‑communicate ang investor compliance information sa mga palitan at mababawasan ang dami ng beses na kailangang hingin ang data mula sa mga mamumuhunan. Ang mga aspeto na ito ay sabay na magbabawas nang malaki sa dami ng integration work na kinakailangan ng mga palitan.

Ang pagpapakilala ng isang bagong sistema tulad nito ay malinaw na magdudulot ng ilang komplikasyon, at maraming isyu pa ang kailangang ayusin. Halimbawa, sa disenyo kung paano magiging awtorisado ang bawat palitan: sino ang gagawa ng desisyon na ang isang palitan ay dapat pagkatiwalaan? Kailangan ng oras upang mag‑disenyo ng isang sistema na magbibigay‑daan sa consensus.

Konklusyon

Ang tokenization ng securities ay isang larangan na maaga pa sa pag‑unlad at pag‑adopt, na bahagi nito ay dahil sa komplikasyon ng regulatory compliance. Bagaman pinasimple ng pag‑publish ng mga protocol ang pagsunod sa marami sa mga regulasyong ito sa pamamagitan ng pagpapatupad nito sa execution ng bawat transfer, marami pang kailangang gawin bago maging seamless ang prosesong ito. Hanggang sa magkaroon tayo ng kasunduan sa pagitan ng mga protocol kung paano i‑store at i‑update ang investor information sa parehong on‑chain at off‑chain, mananatiling malaki ang friction sa buong proseso ng rehistrasyon at pamumuhunan para sa lahat ng partido.