Iilunsad ng Google ang institutional crypto custody platform noong 2027: Paano gumagana ang kanilang MPC technology

2026/11/01 11:01:00

Kinilala ng Google Cloud ang Google Multi-Party Compute (MPC), isang espesyalisadong solusyon sa pagpapamahala at pag-aalaga ng susi para sa mga digital na ari-arian na disenyo para sa mga pandaigdigang bangko, tagapamahala ng ari-arian, at mga reguladong pampinansyal na institusyon. Kasalukuyang nasa private preview na may pagsasalang lamang, tinutukoy ng cloud provider ang komersyal na General Availability (GA) sa unang bahagi ng 2027. Bago ang malawakang komersyal na pagpapalabas, binigyan ng pagsubok ng Google ang arkitektura sa loob ng mga production environment na sumusuporta sa mga pangunahing ecosystem ng blockchain, kabilang ang Ethereum at Solana.

Kumakatawan ang iniciyatibong ito sa isang makabuluhang paglalawak sa institutional Web3 cloud infrastructure. Sa ilang taon, ang mga pangunahing cloud provider ay nakatuon ang kanilang mga serbisyo sa digital asset sa pag-host ng RPC nodes, pag-index ng mga public blockchain dataset sa BigQuery, at pag-aaral ng enterprise settlement networks.

Sa pamamagitan ng pagpapakilala ng native MPC infrastructure, lumalalim ang Google Cloud sa security stack ng institutional digital finance: ang distributed generation, policy verification, at threshold signing ng cryptographic keys. Habang lumalawak ang pakikilahok ng mga reguladong finansyal na institusyon sa tokenized deposits, spot exchange-traded products (ETPs), at real-world asset (RWA) settlement, ang cloud-integrated MPC ay nagtataguyod ng modular na teknikal na pundasyon kasama ang tradisyonal na custody providers at legacy hardware vaults.

Pagsasabwatan ng Klave at Mga Tawid sa Paggamit ng Institusyonal

Ang paglago ng pagkaka-partisipasyon ng mga institusyon sa mga digital asset ay nagpakita ng kahalagahan ng mga matibay na sistema ng pamamahala ng mga susi. Ang pagsubaybay sa kaligtasan ng industriya mula sa mga platform tulad ng DeFiLlama ay patuloy na nagpapakita na ang mga napapalayas na credentials at pagpapakita ng private key ay isa sa pinakamalalaking mga vector ng pagkawala ng kapital sa buong sektor ng cryptocurrency, na nag-aambag ng mga bilyon dolyar sa kumulatibong pagkawala ng industriya sa mga nakaraang siklo ng merkado.

Sa kasaysayan, ang pagsisiguro ng mga digital na ari-arian ng institusyon ay nakabatay sa dalawang pangunahing arkitektural na modelo, bawat isa ay may sariling mga operasyonal na kompromiso para sa mga komersyal na pampalakas na institusyon.

Mga lumang Hardware Security Modules at mga Panganib na Single-Point

Ang tradisyonal na pamamahala ng mga susi sa pananalapi ay nakasalalay sa malaking antas sa mga pisikal na Hardware Security Modules (HSM) at mga kapaligiran ng cold-storage na naka-air-gap. Habang ang HSM ay nag-iisolate ng mga kriptograpikong susi sa loob ng mga hardware na nakakatanggap sa pagbabago, ang mga karaniwang konpigurasyon ng isang susi ay maaari pa ring magdulot ng estruktural na isang punto ng pagkabigo (SPOF).

Upang mag-awtorisyo ng isang karaniwang blockchain transaksyon na may isang-signature, ang buong private key ay dapat umiiral sa loob ng isang memory boundary ng isang module habang nagpapagawa ng signature. Kung ang isang attacker ay makakasira sa host management layer, magpapakita ng firmware vulnerability, o makakalabas sa administrative access controls, ang mga ari-arian na pinag-uukulan ng isang key ay magkakaroon ng direkta at agad na panganib.

Mga Limitasyon ng Multi-Signature sa On-Chain

Upang maiwasan ang pagkakadepende sa isang pambungad na susi, maraming Web3 protokolo ang gumagamit ng on-chain multi-signature (Multi-Sig) na smart contract, tulad ng Safe. Sa isang standard na M of N Multi-Sig na istruktura, kailangan ng maraming independiyenteng pribadong susi na magsumite ng hiwalay na pagpapayag upang matugunan ang mga patakaran sa pagpapatupad ng smart contract.

Habang napakaepektibo ito para sa mga decentralized treasury, ang on-chain Multi-Sig ay nagtataglay ng tatlong praktikal na hadlang para sa mga tradisyonal na workflow ng pagpapautang:

Cross-Chain Incompatibility: Ang logika ng Multi-Sig na smart contract ay hindi magkakatulad sa mga heterogeneous na Layer-1 blockchain. Habang malawakang istandarizado sa Ethereum Virtual Machine (EVM) networks, ang pagpapatupad ng magkakatulad na pamamahala ng smart contract sa mga non-EVM chains (tulad ng Bitcoin o Solana) ay nangangailangan ng iba’t ibang native scripts at hiwalay na operational pipelines.

Mas mataas na gastos sa transaksyon ng network: Dahil sa pag-verify ng maraming cryptographic signature o contract call diretso sa-chain, ang Multi-Sig transactions ay naglalabas ng karagdagang block space at gas fee kumpara sa karaniwang single-signature transfers.

Publikong Kakitaan ng Mga Patakaran sa Pamamahala: Dahil ang mga patakaran sa Multi-Sig ay nagpapatupad sa pamamagitan ng publikong smart contract, ang mga treshold ng quorum, mga address ng signer, at mga pattern ng pagsang-ayon ng organisasyon ay nakikita sa publikong ledger.

Ang mga limitasyong ito ang nagdulot ng pangangailangan ng mga institusyonal para sa off-chain threshold cryptography na nag-uunify ng mga patakaran sa seguridad sa iba’t ibang blockchain.

Paano gumagana ang Google Multi-Party Compute

Tinutugon ng Google Cloud Multi-Party Compute ang mga panganib ng isang puntos ng susi sa pamamagitan ng pagpapatupad ng Threshold Signature Schemes (TSS) na batay sa Multi-Party Computation (MPC). Sa ilalim ng cryptographic model na ito, ang isang buong private key ay hindi kailanman isasama sa anumang iisang device, server memory bus, o data center sa anumang yugto ng pagbuo, pag-iimbak, o pag-sign ng transaksyon.

Ang Hardened DKLs23 Threshold Signature Protocol

Ayon sa teknikal na spesipikasyon para sa platform, ang Google’s ECDSA signing engine ay naglalaman ng hardened na implementasyon ng protokol na DKLs23. Na-named ayon sa mga kriptograpong Döttling, Komargodski, Lai, at Shen, ang DKLs23 ay isang modernong threshold signature protocol na disenyo upang kalkulahin ang elliptic curve signatures nang ligtas sa mga distributed na partido na may minimal na communication overhead.

Ang implementasyon ng Google ay nakatuon sa tatlong operasyonal na priyoridad:

Resilience sa Mapang-aabuso: Ang protokolo ay disenyo upang panatilihin ang unforgeability kahit na isang mananakop ay kompromiso ang isang bahagi ng mga nakikilahok na node sa ilalim ng signing threshold. Ang built-in na pag-check ng pagkakatugma ay nakikita ang mga masamang cryptographic shares habang ang signing ceremony at awtomatikong i-abort ang sesyon bago makapag-produce ng hindi wastong signature.

Optimisasyon ng Low-Latency Round: Madalas na nagdusa ang mga maagang implementasyon ng MPC sa mabagal na pag-sign dahil sa maraming round ng network communication. Sa pamamagitan ng paggamit ng pinapadaliang istruktura ng round ng DKLs23, natatapos ang lokal na kriptograpikong komputasyon sa mga milyong segundo, nagpapahintulot sa mga end-to-end signing workflow na mas mababa sa isang segundo matapos makapasa ang mga pagsusuri sa patakaran ng institusyonal.

Suporta Multi-Curve na Blockchain: Ang arkitektura ay natibong sumusuporta sa Elliptic Curve Digital Signature Algorithm (ECDSA) sa pamamagitan ng secp256k1 curve—ang pamantayan para sa Bitcoin, Ethereum, at mga EVM-compatible na Layer-2 network—kasama ang staging support para sa Edwards-curve Digital Signature Algorithm (EdDSA) sa Ed25519 upang sakop ang mga high-throughput network tulad ng Solana.

Heterogeneous Key-Splitting: Ang 2-of-3 Quorum Model

Sa halip na mag-generate ng private key sa isang lugar at pagkatapos ay i-split ito, gumagamit ang platform ng Distributed Key Generation (DKG), kung saan ang mga independiyenteng node ay matematikal na kumukompyuta ng kanilang mga key share nang walang anumang isang node na nakakakita ng buong key.

Upang maiwasan ang pagkonsentrasyon ng panganib sa isang mag-isa naming cloud vendor, karaniwang ginagamit ng institutional deployments ang heterogeneous 2-of-3 quorum structure:

Bahagi 1 (Client-Controlled Environment): Hosted direkt sa loob ng data center ng pribadong institusyon o dedikadong HSM environment.

Ibahagi ang 2 (Google Cloud Enclave): Naka-host sa loob ng environment ng Confidential Space na may hardware isolation ng Google Cloud.

Ibahagi ang 3 (Independent Recovery o Third-Party Cloud): Naka-host sa isang panlabas na cloud environment (tulad ng AWS o Azure) o naka-imbak nang offline ng isang independiyenteng recovery fiduciary.

Sa ilalim ng istrukturang threshold na 2-of-3, anumang dalawang awtorisadong bahagi ay maaaring magtrabaho nang off-chain upang lumikha ng isang standard na cryptographic signature. Para sa ilalim na blockchain, tila magkakatulad ang resultang transaksyon sa isang normal na single-key transfer.

Kung sakaling masira ng isang attacker ang isang окружина, sila ay makakakuha lamang ng isang hiwalay na bahagi ng susi—na matematikal na hindi nagpapakita ng anumang impormasyon tungkol sa buong pribadong susi at hindi kayang mag-awtorisa ng anumang transaksyon nang mag-isa. Sa kabaligtaran, kung sakaling masira ang lokal na workstation ng isang institusyon, ang attacker ay hindi pa rin kayang ilipat ang mga pondo nang mag-isa maliban kung ang Google Cloud’s enclave ay nag-verify nang hiwalay na sumusunod ang transaksyon sa mga nakapaghanda na patakaran sa seguridad.

Hardware-Level Isolation: Google Cloud Confidential Space (TEE)

Isang kasaysayang pag-aalala sa cloud-hosted key management ay ang host-level privilege escalation: kung ang operating system o hypervisor ng cloud server ay kompromiso, maaaring subukan ng isang may-privilehiyong administrator na suriin ang cryptographic material na naka-hold sa system memory (RAM).

Nilalabasan ng Google ang panganib na ito sa pamamagitan ng pagpapatakbo ng kanyang MPC signing nodes sa loob ng Google Cloud Confidential Space, isang Trusted Execution Environment (TEE) na suportado ng confidential computing hardware:

Hardware Memory Encryption: Gumagamit ang Confidential Space ng pag-encrypt ng memorya sa antas ng processor (tulad ng AMD SEV-SNP), nagtataguyod na mananatiling encrypted ang mga key shares at intermediate signing calculations sa RAM gamit ang hardware keys na hindi ma-access ng host operating system.

Cryptographic Attestation: Bago ma-access ang key share o magsimula ang signing round, ang enclave ay naglalikha ng isang hardware-rooted attestation token na nagpapatotoo sa eksaktong cryptographic hash ng container image at firmware baseline. Kung nagkaroon ng anumang pagbabago sa software image, mabubuksan ang attestation check at ititigil ang signing process.

Ipinagbabawal na Paggamit ng Administratibo: Pinoprotektahan ng Confidential Space ang malakas na paghihiwalay ng workload na nag-aalis sa karaniwang root access o interactive debugging capabilities, na nagpapalit sa mga administrador ng cloud infrastructure mula sa pagtingin sa data sa loob ng isang aktibong enclave.

Pagsasagawa ng Patakaran sa Transaksyon at Mekanismo ng Pag-refresh ng Key Share

Ang pagprotekta sa mga key share mula sa pagkuha ay nalulutas lamang ang bahagi ng hamon sa custody. Sa praktika, maraming insidente sa seguridad ng mga institusyonal na nagmumula sa mga napapalitan na API credentials, mga phishing attack, o hindi awtorisadong panloob na pagpapayag na nagtutulak sa mga wastong sistema na mag-sign ng mga masasamang transaksyon.

Mga Engine ng Pagsusuri ng Patakaran bago ang Pag-sign

Upang protektahan ang hindi awtorisadong pag-transfer sa application layer, binubuo ng Google Cloud ang isang deterministic policy verification engine nang direkta sa loob ng Confidential Space enclave. Bago sumali ang Google’s MPC node sa isang threshold signing round, sinusuri ang proposed transaction payload laban sa mga institusyonal na tatakdaang patakaran—tulad ng whitelisted destination addresses, maximum transaction value limits, velocity caps, time-of-day windows, at multi-approver quorum signatures.

Kung subukan ng isang napapalibutan na endpoint terminal na humingi ng pag-transfer patungo sa isang hindi pinapayagang address o sa itaas ng pinapayagang threshold, tatanggihan ng enclave ang hiling para i-sign bago mangyari ang anumang pagkalkula ng cryptographic share.

Proaktibong Pagbabahagi ng Lihim (Pag-refresh ng Bahagi ng Susi)

Upang mabawasan ang panganib ng isang mayamang manlulupig na maaaring paulit-ulit na kompromisuhin ang maraming node sa loob ng mahabang panahon, ang arkitektura ay sumusuporta sa Proactive Secret Sharing (PSS), karaniwang tinatawag na key share rotation o refresh.

Sa isang nakatakdang talahanayan o pagkatapos ng mga pagbabago sa personnel, ang mga nakikilahok na node ay tumatawag ng isang matematikal na refresh protocol:

Ang mga node ay nagkakasama-samang kalkulahin ang isang bagong set ng cryptographic shares.

Ang mga nakaraang bahagi ng susi ay pati na rin na ipinagbawal at na-overwrite.

Ang pangunahing master public key at ang on-chain wallet address ay nananatiling ganap na hindi nagbago.

Ibig sabihin nito na kahit manalo ang isang attacker sa isang hiwa ng key sa isang buwan, ang fragment na iyon ay magiging walang kwenta agad pagkatapos ng susunod na iskedyuladong pag-refresh ng hiwa—na nagpapahintulot sa mga institusyon na palitan ang kanilang pangunahing materyales sa seguridad nang regular nang walang kailangang ilipat ang mga pondo sa isang bagong blockchain address o magbayad ng on-chain gas fee.

Post-Quantum Agility at 2027 Commercial Readiness

Habang sinusuri ng mga finansyal na institusyon ang mga imprastruktura ng pag-aalaga na may paningin na maraming taon, ang pangmatagalang kriptograpikong agilitas, kabilang ang paghahanda para sa quantum computing, ay naging mahalagang pag-iisip sa arkitektura. Ang mga istandard na istruktura ng elliptic curve (secp256k1 at Ed25519) ay nakasalalay sa mga matematikal na problema na maaaring maging vulnerable sa sapat na makapangyarihan, fault-tolerant na quantum computers.

Habang ang unang paglalabas ng MPC ng Google Cloud ay nakatuon sa paglutas ng mga pansamantalang operasyonal na banta, tulad ng pagkakawala ng kredensyal, mga tanging punto ng pagkabigo, at pagsasamahan ng mga loob, ang platform ay disenyo na may pag-iisip sa kriptograpikong modularidad. Sa paghihiwalay ng mga patakaran sa orkestrasyon at mga API layer mula sa mga pangunahing pag-sign, ang arkitektura ay istruktura upang matugunan ang mga hinaharap na post-quantum cryptography (PQC) at mga pamantayan sa quantum-safe transport habang ang mga blockchain network at mga internasyonal na awtoridad sa pamantayan (tulad ng NIST) ay nagtatapos sa mga spesipikasyon ng post-quantum signature.

Kongklusyon

Ang pagpapalabas ng Google Cloud ng institusyonal na imprastruktura ng Multi-Party Compute ay nagpapakita ng patuloy na pagiging matatag ng seguridad ng enterprise sa mga digital na ari-arian. Sa pamamagitan ng pagkombinasyon ng DKLs23 threshold signature protocol kasama ang hardware-attested Confidential Space enclaves at heterogeneous 2-of-3 key distribution, ang platform ay tumutulong sa mga institusyong pinansyal na maiwasan ang mga vulnerable na punto sa susi nang hindi nagpapababa sa bilis ng pag-sign o multi-chain flexibility. Habang lumalago ang serbisyo patungo sa komersyal na pagkakaroon noong 2027, ang cloud-integrated MPC ay handa nang maglalaro ng mas malaking papel sa paraan kung paano pinoprotektahan ng mga banko at asset manager ang tokenized assets sa malaking iskala.

Madaling Tanong

Ano ang Google Cloud Multi-Party Compute?

Ang Google Cloud Multi-Party Compute (MPC) ay isang institusyonal na digital asset key-management at signing infrastructure platform na kasalukuyang nasa private preview bago ang plano na komersyal na paglunsad noong maagang 2027. Gumagamit ito ng threshold cryptography upang hatiin ang kontrol sa private key sa magkakaibang mga kapaligiran, na naglalayong tanggalin ang mga single points of failure sa pag-sign ng blockchain transaction.

Bakit tinutukoy ng Google ang commercial availability noong 2027?

Ang pagpapatakbo ng isang pribadong preview na may pagpapahintulot lamang sa huling bahagi ng 2026 ay nagbibigay-daan sa mga kasamang bangko at mga institusyonal na tagapamahala ng yaman upang isagawa ang mga pagsusuri sa kaligtasan, integrasyon ng patakaran, at pagsubok sa pagkakasunod. Ang target na pangkalahatang pagdisponibilidad noong unang bahagi ng 2027 ay nagsasabay sa paglago ng paggamit ng mga institusyonal sa ilalim ng mga matatag na regulasyon, tulad ng MiCA regime ng EU at ang umuunlad na mga pamantayan ng Basel Committee tungkol sa mga eksposur ng banko sa crypto-assets.

Paano nagkakaiba ang Google’s MPC mula sa on-chain multi-sig?

Ang mga multi-sig smart contract na nasa-chain ay nagpapatotoo ng maraming hiwalay na signature diretso sa blockchain, na nagpapataas ng gas costs, nagpapakita ng mga istruktura ng pag-apruba nang pampubliko, at nangangailangan ng suporta sa smart contract na specific sa chain. Ang MPC ni Google ay nagpapatotoo ng multi-party at naglalapat ng threshold math off-chain gamit ang hardened DKLs23 protocol, na naglalabas ng isang solong standard signature na gumagana sa iba’t ibang blockchain na may mas mababang bayarin at pribadong mga alituntunin sa pamamahala.

Nagtatanggal ba ang MPC technology sa lahat ng mga panganib sa pagpapanatili ng crypto?

Hindi makalilinang sa lahat ng panganib ang anumang arkitektura ng seguridad. Habang tinatanggal ng MPC ang iisang punto ng pagkabigo na kaakibat ng pag-iimbak ng kumpletong pribadong key sa isang lokasyon, kailangan pa rin ng mga institusyon na mag-ingat laban sa phishing, kompromiso ng endpoint, at di-maayos na panloob na pamamahala. Tumutulong ang disenyo ng Google na mabawasan ang mga operasyonal na panganib na ito sa pamamagitan ng pagkombina ng heterogeneously split na mga bahagi ng key kasama ang hardware-isolated na Confidential Space enclaves at mga pagsusuri sa patakaran bago ang pag-sign.

Pahiwatig

Ang pangkalahatang impormasyon sa merkado na ito, maaaring mula sa mga third-party, komersyal, o sinponsor na pinagkukunan, ay ibinibigay lamang para sa pagtutuon at edukasyonal na layunin at hindi nagtataglay ng abiso sa pondo o pag-invest, tawag, paghingi, o jamin. Nagtatanggi kami ng pananagutan para sa kawastuhan, kumpletong impormasyon, katiyakan, at anumang naging pagkawala. Ang pag-invest/trade ay may panganib; ang nakaraang performans ay hindi nagjamin ng mga resulta sa hinaharap. Dapat mag-aram, mag-isip nang mabuti, at tanggapin ang buong pananagutan ang mga gumagamit. Para sa karagdagang detalye, mangyaring bisitahin ang Mga Tuntunin ng Paggamit at Pagpapakilala sa Panganib ng KuCoin.

Disclaimer: AI technology ang ginamit sa pag-translate ng page na ito para sa convenience mo. Para sa pinaka-accurate na impormasyon, mag-refer sa original na English version.