Ang Paghawak ng Pribadong Susi ay Hindi Sapat para sa Seguridad ng Digital na Asset

Ang mga multi‑party computation (MPC) wallet ay ang namumunong paraan para sa mga institusyon na nais mag‑self‑custody ng kanilang mga digital na asset. Karaniwan ito ay isang 2‑sa‑2 na signature scheme kung saan ang customer ay humahawak ng isang key share sa kanilang device at ang vendor ay humahawak ng isa pa. Mas mainam ito kaysa magtiwala sa isang provider ng buong susi at palitan ang iyong direktang pagmamay‑ari ng isang asset para sa isang fractional ownership claim kung ang provider ay hindi nagbabalik ng kanilang mga liability sa mga asset nang 1‑to‑1. Gayunpaman, ito ay sumasaklaw lamang sa ibabaw ng kung ano ang ibig sabihin ng kontrol at pagmamay‑ari ng mga digital assets. Mayroong maraming iba pang mga bahagi sa arkitektura na tumutukoy sa paggamit (o pang‑aabuso) ng susi at kasalukuyang nasa anyo ng isang SaaS blackbox. Panahon na upang ilawan ang mga MPC wallet at ipakita kung bakit ang simpleng paghawak ng key share ay malayo sa anumang konkretong kontrol o lehitimong pag‑claim ng self‑custody.

Ang papel ng mga institusyon sa pag‑evolve ng custody ng digital na asset

Hindi nakakagulat, ang malalaking institusyong pinansyal ang unang napansin ang kamalian na ito matapos ilang taon na subaybayan ang digital asset space. Pagdating sa custody, agad nilang naunawaan ang tanong tungkol sa private key, ang papel ng hardware, at pati na rin ang MPC. Gayunpaman, sa pag‑adopt ng risk‑based na lapit sa pamamahala ng vendor, nais nilang maunawaan kung ano pang mga dependency sa panig ng vendor ang umiiral. Lumalabas na ang mga customer ay patuloy na lubos na umaasa sa vendor para sa maraming bagay na karaniwang bahagi ng serbisyo o paggamit ng software. Halimbawa, maaaring kabilang ang pag‑update ng mga polisiya at business logic sa wallet, pagdaragdag ng mga bagong blockchain, soft recovery at hard recovery ng account pati na rin ang iba pang mga karaniwang at inaasahang pang‑araw‑araw na operasyon. Ipinapakita ito sa karanasan ng gumagamit bilang pag‑kuha ng ilang araw para sa provider na mag‑serbisyo ng mga pagbabago sa antas ng account o i‑update ang mga patakaran sa wallet, na sa huli ay nangangahulugang ang pangunahing kontrol ng customer laban sa ilang natukoy na operational risk ay pansamantalang nasira hanggang maibalik ito sa tamang linya.
Sa pagdadala pa nito nang mas malalim, nauunawaan ng mga stakeholder na may malasakit sa seguridad na hawak nila ang isang key share ngunit nais din nilang maunawaan kung ano ang panganib sa pagkakaroon ng iba pang mga lohikal na bahagi sa arkitektura ng custody na naka‑host ng isang SaaS provider, ang namumunong paraan para mag‑bigay ng MPC wallet software ngayon. Nagdudulot ito ng mga tanong tulad ng:

1. Kung ang isang vendor ang gumagawa ng key share generation, ano ang aking mga katiyakan na wala silang kopya ng aking key share?
2. Kung ang isang vendor ang nagho‑host ng aking mga polisiya, ano ang pumipigil sa vendor na baguhin ang mga ito?
3. Kung ang serbisyo ay naka‑host ng vendor, paano ko matitiyak ang availability ng serbisyo at business continuity?
4. Kung ang vendor ay offline, gaano kabilis ko matutupad ang aking recovery time objective?

Ang mga sagot sa mga tanong na ito ay agad na sumisira sa ilusyon ng anumang tiwala na ang customer ay may kontrol at pagmamay‑ari ng kanilang mga asset. Ang salitang susi dito ay “tiwala”, dahil ang mga sagot sa lahat ng mga tanong na ito ay mga masalimuot na anyo ng: “Magtiwala kayo sa amin” at tulad ng napag‑alamang sa mga kamakailang pangyayari sa merkado, hindi ito gaanong epektibo noon. Ngayon, ang mga institusyon ay naghahangad na lumayo mula sa ganitong kalagayan habang pinapalakas ang kanilang operational resilience patungo sa 2024. Dahil dito, nagsisimula nang pag-isipan ng mga kalahok sa merkado kung paano ang mga panganib at posibleng operating loss ay naaayon sa kanilang risk appetite, regulasyong obligasyon, o anumang kaugnay na balangkas na nagtatakda ng regulatory capital requirements para sa risk‑weighted assets. Ang mga service provider ay, sa huli, isang extension ng surface area ng risk ng kumpanya. Bagaman maaaring i‑delegate ng isang institusyon ang isang function sa ikatlong partido, hindi nito maaaring i‑delegate ang responsibilidad para sa maayos na pamamahala ng risk o regulasyong obligasyon. Kapag mas maraming pag‑asa ang isang kumpanya sa ikatlong partido, tulad ng sa isang MPC wallet provider, mas malaki ang kinakailangang oversight at tiwala.

Palakasin ang kontrol sa mga digital na asset upang mapabuti ang seguridad

Isang paraan upang mabawasan ang pag‑asa sa ikatlong partido ay ang mga institusyon na i‑host ang software mismo sa kanilang sariling data center o pribadong cloud kung saan ang responsibilidad ng vendor ay limitado lamang sa mga gawain tulad ng maintenance at pag‑update ng software. Mas kanais‑nais ito para sa maraming institusyong pinansyal dahil ang mga server ay nasa lugar para sa access, nagpapanatili ng seguridad ng data, at tunay na maaaring mag‑prioritize ng pagmamay‑ari at kontrol sa kanilang mga custody operation. Mayroon ding mga talakayan tungkol sa co‑hosted na modelo na magpapahintulot sa customer na magpatakbo ng isang instance ng custody software habang ang vendor o iba pang ikatlong partido ay nagpapatakbo ng kanilang sariling mga instance sa isang konektadong network. Maaaring gawin ito sa paraang nagsisiguro ng consensus sa pagitan ng bawat partido (tiwala ngunit beripikahin) sa paraang ang vendor ay hindi isang sentralisadong pinagkakatiwalaang bersyon ng katotohanan tulad ng karaniwan ngayon. Ang distributed deployment model na ito ay magpapalakas din ng fault tolerance at magiging mahalagang bahagi ng business continuity planning na kaunti lamang ang kontrol ng mga customer ngayon sa kanilang custody provider. Ang mga limitasyong ito ay umiiral mula nang itayo ang mga MPC wallet noong mas maagang panahon at isinasaalang‑alang ang ibang impormasyon ng customer, ang mga SaaS product ay lubos na opinionated na hindi maganda para sa pag‑reshape nila para sa isang bagong realidad na naglalagay ng mas maraming kapangyarihan sa kamay ng customer. Habang ang mga pangangailangang ito ay nagiging mas kilala at hinahangad, ang merkado ay naghahanap ng mga provider na sumasabay sa pag‑usad habang ang industriya ay nag‑e‑evolve sa susunod na siklo.

Sa kabuuan, mas lalong nais ng mga institusyon na maging mga admin para sa mga produktong self‑custody na ito at pamahalaan ang mga ito sa loob ng kanilang security perimeter habang tinitiyak ang mataas na antas ng availability ng serbisyo at pagiging tumutugon. Kailangan nilang magpatunay ng operational resilience, business continuity, at disaster recovery na may malinaw na mga sagot kung paano ito nangyayari. Ang isang blackbox na SaaS product o “Trust us” ay hindi katanggap‑tanggap. Dahil dito, nagsisimula nang lumipat ang pamamahala mula sa panig ng vendor patungo sa panig ng customer pagdating sa self‑custody technology. Nagsimula ito sa mga private key share, at magpapatuloy ito sa policy engine, mga server, at iba pa. Ang pag‑alis ng gitnang tagapamagitan na vendor ay mabuti para sa customer maliban kung ang provider ay kailangang ganap na i‑outsource ang function na ito, kung saan maaaring kailanganin ng kumpanya ang isang regulated custodian, dahil hindi lamang nito pinapayagan kang mas mahusay na impluwensyahan at lutasin ang panganib kundi maaari ring mag‑alok ng mga pagpapabuti sa negosyo kung ang lisensya ng software ay nagpapahintulot na mag‑build sa itaas para sa mga tiyak na use case o blockchain network na interesado ka. Ang pamamaraang ito ay naaayon sa isang industriya‑wides na pagsisikap na mag‑mature sa 2024, at tataas ang pangangailangan ng mga customer para dito mula sa kanilang mga custody technology provider o lilipat sa provider na makakapag‑pasilita ng mga kanais‑nais na pagpapabuti.