Paano pinapalakas ng Bitcoin Integration ng ICP ang seguridad ng Private Keys

ICP HUB Philippines
5 min readMar 2, 2024

Ang native na Bitcoin integration ng ICP ay nagbubukas ng mga kakayahan ng smart contract para sa Bitcoin habang tinatanggal ang pangangailangan para sa mga cross-chain bridges.

Ang direktang Bitcoin integration sa ICP ay nagpapahintulot sa mga canister, na mga advanced smart contract, na makipag-interact sa Bitcoin network sa protocol level. Ito ay nagbibigay-daan sa mga canister na direktang tumanggap, mag-hold, at magpadala ng BTC sa Bitcoin mainnet nang walang paggamit ng mga intermediaries at third-party blockchain bridges, na puno ng maraming mga isyu sa seguridad. Ayon sa Global Web3 Security Report, noong 2022, halos $1.89 bilyon ang nawala dahil lamang sa labindalawang insidente na nauugnay sa mga tulay na ito.

Sa Bitcoin integration, ang mga canister sa ICP ay maaaring ligtas na magbasa at magsulat sa Bitcoin ledger.

(1) Ang mga canister ay maaaring magbasa ng state ng Bitcoin blockchain sa pamamagitan ng Bitcoin light node na tumatakbo sa Internet Computer protocol. Sa ganitong paraan, ang mga nodes sa ICP network ay nakakakuha ng mga block nang direkta mula sa Bitcoin network at ine-exctract at pino-proseso and mga contained transactions. Ito ay nagpapanatili sa kanila na up to date sa current Unspent Transaction Output (UTXO) set ng kumpletong Bitcoin network. Ang impormasyong ito sa UTXO ay inaalok sa mga canister sa pamamagitan ng isang API, na sa gayon ay nagbibigay-daan sa mga canister na ma-access ang impormasyon tulad ng balanse at UTXOs ng mga Bitcoin address. Sa ibang salita, ang mga canister ay maaaring magtanong sa balanse at UTXOs ng anumang Bitcoin address, kabilang ang mga address na kanilang kontrol. Ito ay nagpapahintulot sa kanila na matukoy ang spendable balance (at UTXOs) ng isang Bitcoin address sa pamamagitan ng pagtingin sa estado ng blockchain.

(2) Upang magsulat sa Bitcoin network, ang mga canister ay maaaring ligtas na pumirma ng mga transaksyon sa Bitcoin at isumite ang mga ito sa Bitcoin network. Ang secure signing ay ginagawa sa pamamagitan ng novel na threshold ECDSA protocol na tinatawag na chain-key ECDSA. Ang mga pirmadong transaksyon ay isinusumite sa pamamagitan ng protocol-level integration. Ito ay nagreresulta sa mga ICP replicas na isumite ang transaksyon sa maraming konektadong Bitcoin nodes.

Saan nakatago ang mga Private Keys sa ICP?

Ngayong ang mga canister ay maaari na ring magsulat (pumirma at isumite) ng mga transaksyon, ibig sabihin ba nito na nagtatago rin sila ng mga private keys?

Ang paghawak ng mga private keys sa canister’s state ay maaaring magexpose sa kanila sa mga malicious nodes sa loob ng ICP network, na maaaring magbigay ng access sa mga digital assets ng user. Upang maiwasan ito, gumagamit ang ICP ng threshold cryptography upang ang mga private keys ay hindi lamang naka-store sa isang node o canister. Ang threshold cryptography ay nagpapahintulot sa isang secret (tulad ng isang private key) na hatiin sa maraming bahagi, kilala bilang secret shares o shares. Kailangan ang isang certain na bilang (at least the threshold) ng mga shares na ito upang buuin muli ang secret o gamitin ito upang pumirma ng isang mensahe.

Sa halip na itago ang buong private key sa isang location, ito ay hinati sa maraming bahagi, ang mga secret shares, na hawak ng lahat ng mga nodes sa loob ng isang high-replication subnet, ibig sabihin, isang subnet na may mas maraming bilang ng mga nodes kaysa sa isang regular na app subnet. Bukod dito, ang mga secret shares na ito ay periodically inirire-share sa mga nodes upang protektahan laban sa posibleng kompromiso ng mga shares. Ang resharing ay nangangahulugang ang mga bagong shares ay nilikha mula sa kasalukuyang mga shares gamit ang isang cryptographic protocol. Kapag na-re-share na, ang mga dating-valid shares ay nagiging hindi na mabisa, na nagiging walang silbi sa anumang malicious actor na maaaring kumuha sa kanila.

Sa pagsulat sa Bitcoin network, ang mga Bitcoin transactions ay pumipirma gamit ang threshold signing, na nangangahulugang kung sapat ang bilang ng mga nodes sa subnet na pumayag na pumirma, gagamitin ng bawat node ang kanilang kaukulang key share upang tulungan ang pagpipirmahan nang sabay-sabay ng transaksyon. Kinakailangan hindi bababa sa bilang ng key shares sa threshold upang mabilang ang pirma.

Ito ay nagtitiyak na ang key ay hindi magagamit sa anumang entity as a whole at sa isang attacker na kontrolado ang isang mas maliit na bilang ng mga nodes kaysa sa threshold. Sa kaso ng ICP, sa isang canister transaction request, ginagamit ng mga nodes ang kanilang mga shares upang pirmahan ang mga transaksyon sa Bitcoin nang sabay-sabay sa halip na pagbuuin muli ang orihinal na private key. Ang protocol na ito ng pagsisign ay nag-aassume na higit sa two thirds ng mga nodes ay honest, at mas mababa sa one third ang kompromiso.

Sa pamamagitan ng non-Custodial approach ng ICP para sa ckBTC at Bitcoin Integration

Karamihan sa mga protocol na idinisenyo para sa pakikipagtulungan sa pag-compute ng ECDSA signatures gamit ang key shares na ipinamahagi sa mga participants ay nag-aassume ng zero robustness o liveliness, isang synchronous network, o pareho. Kapag walang robustness, maaaring mawala ang kakayahan ng protocol na mag-generate ng digital signatures kapag ang isang node ay nag-crash o hindi sumali. Bilang resulta, ang pagsasabing synchronous network ay nagpapahiwatig na ang simpleng message delay ay maaaring magdulot sa pagkabigo ng pagsisign protocol at walang signature ang ma-produce, kaya’t ang protocol ay maaaring maging madaling magkaproblema sa attacks laban sa availability.

Ang ICP ay idinisenyo upang maging fault tolerant, na nagtitiyak na ang protocol ay gumagana sa isang asynchronous communication network, ibig sabihin, maaari nitong i-tolerate and mga message delays nang hindi nagkakaroon ng pagkaputol. Hangga’t mas mababa sa one third ng mga nodes ang comprised, faulty, o nag-crash, nananatiling effectively functional ang buong system, ibig sabihin, patuloy itong gumagana with a reduced throughput. At kung magkaroon ng fail ang isang node sa isang subnet, pipiliin ng ICP ang isang spare node upang palitan ang faulty node.

Maging bahagi ng aming lumalaking community.

--

--