Payment IDs sa Monero: Bakit Itinigil

Ang Pag-akyat at Pagbagsak ng mga Payment ID

Ang mga payment ID ay dating isang laganap na feature sa ekosistema ng Monero. Kung gumamit ka ng Monero bago ang 2019, halos tiyak na nakatagpo mo ang mga ito kapag nagdedeposito sa mga exchange o nagbabayad sa mga merchant. Ang mga karagdagang identifier na ito ay idinadagdag sa mga transaksyon upang tulungan ang mga tatanggap na makilala ang mga iba't ibang papasok na bayad. Sa kabila ng kanilang pagiging kapaki-pakinabang, nagdala ang mga payment ID ng malalaking problema sa privacy at usability na sa huli ay humantong sa kanilang pagkatigil.

Mahalagang maunawaan ang kasaysayang ito para sa sinumang gumagamit ng Monero ngayon, lalo na kapag nakikipag-ugnayan sa mga lumang serbisyo na maaaring tumukoy pa rin sa mga payment ID. Nagpapalit ka man sa pamamagitan ng MoneroSwapper o namamahala ng sarili mong wallet, ang kaalaman kung ano ang pumalit sa mga payment ID at bakit ay tumutulong sa iyo na mag-transact nang mas ligtas.

Ano ang mga Payment ID?

Ang payment ID ay isang 64-character na hexadecimal string (32 bytes) na maaaring ilakip sa isang transaksyon ng Monero. Isipin ito bilang isang reference number o invoice ID na direktang naka-embed sa blockchain transaction. May dalawang uri:

Mahabang Payment ID (Hindi Naka-encrypt)

Ang orihinal na format ng payment ID ay isang 32-byte string na ipinadala bilang plaintext bilang bahagi ng extra field ng transaksyon. Kapag nagpadala ka ng transaksyon na may mahabang payment ID, sinumang tumitingin sa blockchain ay makikita ang halaga ng payment ID. Ito ang pinakamaagang paraan at malawakang ginamit ng mga exchange at payment processor.

Ang problema ay agad na halata mula sa perspektibo ng privacy: kung nag-publish ang isang exchange ng deposit address nito at nag-assign ng mga natatanging payment ID sa bawat user, maaaring matukoy ng isang observer ang lahat ng mga deposito sa exchange na iyon at posibleng i-link ang mga payment ID sa mga partikular na user sa pamamagitan ng timing o amount analysis.

Mga Naka-encrypt na Payment ID (Maikli)

Upang matugunan ang plaintext problem, ipinakilala ng Monero ang mga naka-encrypt na payment ID noong 2017. Ito ay mga 8-byte value na naka-encrypt gamit ang shared secret na nagmula sa one-time key ng transaksyon. Tanging ang tatanggap lamang ang makakapag-decrypt ng payment ID gamit ang kanilang private view key. Sa blockchain, ang naka-encrypt na payment ID ay lumilitaw bilang random data sa lahat ng iba pa.

Ang mga naka-encrypt na payment ID ay ibinundle sa mga integrated address, na pinagsama ang isang standard na Monero address na may 8-byte payment ID sa isang solong address string. Ginawa nitong mas madaling gamitin dahil hindi na kailangang manual na kopyahin at i-paste ng nagpadala ang hiwalay na payment ID field.

Bakit Gumamit ng Payment ID ang mga Exchange at Serbisyo

Ang praktikal na dahilan para sa mga payment ID ay simple: kailangan ng mga exchange at merchant na i-attribute ang mga papasok na bayad sa mga partikular na user o order. Dahil gumagamit ang Monero ng mga stealth address na ginagawang natatangi ang bawat transaction output, kailangan ng serbisyong tumatanggap ng libu-libong deposito araw-araw ng mekanismo para matukoy kung aling deposito ang sa aling customer.

Ang karaniwang workflow ay:

• Binibigyan ng exchange ang lahat ng user ng parehong deposit address ngunit nag-a-assign ng natatanging payment ID sa bawat user
• Nagpapadala ang user ng XMR sa exchange address na may assigned payment ID
• Ini-scan ng exchange ang mga papasok na transaksyon para sa payment ID upang ma-credit ang tamang account

Gumana ang sistemang ito ngunit marupok. Madalas makalimutan ng mga user na isama ang payment ID, na nagreresulta sa mga nawawalang deposito na nangangailangan ng manual na recovery ng mga exchange support team. Ito ang isa sa mga pinakakaraniwang isyu sa suporta para sa mga exchange na tumatanggap ng Monero at pangunahing pinagmulan ng pagkabigo ng user.

Mga Problema sa Privacy ng Payment ID

Kahit ang mga naka-encrypt na payment ID ay nagpakilala ng ilang vulnerability sa privacy na sumira sa mga pangunahing garantiya ng privacy ng Monero:

Pagkakalink sa pamamagitan ng Metadata

Kapag lahat ng user ng isang exchange ay nagpadala sa parehong address, nasira ang mekanismo ng stealth address. Matutukoy ng isang observer na ang transaksyon ay para sa isang partikular na exchange sa pamamagitan lamang ng pagkilala sa public address. Ang payment ID, kahit naka-encrypt, ay nagdagdag ng mapagkikilalang metadata sa transaksyon. Ang mga transaksyon na may payment ID ay mukhang iba sa mga walang payment ID, na lumikha ng dalawang klase ng mga transaksyon na nagpababa ng anonymity set.

Ang Problema ng Dalawang Pool

Ang mga transaksyon na may payment ID at mga transaksyon na walang payment ID ay bumuo ng dalawang visually distinct na pool sa blockchain. Ang pagkakaibang ito ay nagbigay ng impormasyon sa mga chain analyst. Kung ang isang transaksyon ay naglaman ng naka-encrypt na payment ID, malamang na ito ay papunta sa isang exchange o merchant, na makabuluhang nagpapaliit ng mga posibleng tatanggap.

Timing at Pattern Analysis

Karaniwang pinoproseso ng mga exchange ang mga deposito sa mga batch o sa predictable na timing. Kasama ng single deposit address model, lumikha ito ng mga pattern na maaaring pagsamantalahan ng mga sopistikadong analyst. Ang kumbinasyon ng kilalang address, timing pattern at presensya ng mga payment ID ay gumawa ng mga correlation attack na mas feasible kaysa sa dapat.

Error ng User bilang Privacy Leak

Kapag nakalimutan ng mga user ang payment ID, madalas nilang kailangang kontakin ang suporta at patunayan na sa kanila ang transaksyon. Karaniwang kasama nito ang pagbabahagi ng transaction private key o view key information, na lumilikha ng karagdagang privacy leakage at paper trail na nag-uugnay ng kanilang identity sa transaksyon.

Timeline ng Paghinto

Kinilala ng komunidad ng Monero ang mga problemang ito at kumilos sa pamamagitan ng ilang protocol upgrade:

• 2018 (v0.13, Beryllium Bullet) — Ang mga mahabang (hindi naka-encrypt) payment ID ay itinigil, at nagsimulang magpakita ng mga babala ang wallet software kapag sinubukang gamitin ng mga user
• 2019 (v0.15, Carbon Chamaeleon) — Ang mga mahabang payment ID ay ipinagbawal sa protocol level. Ang mga transaksyon na may hindi naka-encrypt na payment ID ay tinanggihan ng network
• Mga update sa wallet software — Ang mga GUI at CLI wallet ay unti-unting nag-alis ng mga payment ID field at hinimok ang paggamit ng subaddress
• Migration ng exchange — Ang mga pangunahing exchange ay lumipat mula sa payment ID patungo sa mga subaddress noong 2019 at 2020, na may ilang mas matagal

Ang mga naka-encrypt na (maikling) payment ID sa pamamagitan ng mga integrated address ay teknikal na gumagana pa rin sa protocol level, ngunit mahigpit na hindi hinihikayat. Ang modernong wallet software ay itinatago ang opsyon nang buo o nagpapakita ng malinaw na mga babala. Ang consensus ng komunidad ay ang mga subaddress ang tamang kapalit.

Mga Subaddress: Ang Mas Mahusay na Kapalit

Ang mga subaddress ay ipinakilala bilang inirerekomendang kapalit para sa mga payment ID. Ang subaddress ay isang natatanging address na nagmula sa iyong pangunahing wallet address gamit ang isang mathematical relationship na tanging ang iyong wallet lamang ang makakakompyut. Bawat subaddress ay cryptographically naka-link sa iyong pangunahing address, ngunit ang link ay hindi nakikita sa mga panlabas na observer.

Paano Gumagana ang mga Subaddress

Ang iyong Monero wallet ay maaaring mag-generate ng halos walang limitasyong bilang ng mga subaddress mula sa iyong pangunahing address. Bawat subaddress ay mukhang ganap na independiyenteng Monero address sa sinumang tumitingin sa blockchain. Kapag may nagpadala ng XMR sa iyong subaddress, ang transaction output ay gumagamit ng mga public key ng subaddress upang mag-generate ng stealth address, na tinitiyak na tanging ang iyong wallet lamang ang makakatukoy ng bayad.

Mga pangunahing bentahe ng mga subaddress kaysa sa mga payment ID:

• Walang shared address — Bawat customer o bayad ay nakakakuha ng natatanging address, na ganap na inaalis ang single-address problem
• Walang metadata leakage — Ang mga transaksyon sa mga subaddress ay kapareho ng hitsura sa mga transaksyon sa mga pangunahing address sa blockchain
• Walang error ng user — Nagpapadala lang ang mga user sa ibinigay na address nang hindi kailangang alalahanin ang karagdagang payment ID field
• Hindi maaaring i-link — Hindi matutukoy ng isang observer na dalawang subaddress ay kabilang sa parehong wallet
• Walang two-pool problem — Lahat ng mga transaksyon ay magkapareho ang hitsura kahit gumagamit ng mga pangunahing address o subaddress

Mga Subaddress para sa mga Exchange

Para sa mga exchange na dating gumamit ng mga payment ID, ang migration sa mga subaddress ay nagpabuti ng parehong seguridad at karanasan ng user. Sa halip na bigyan ang bawat user ng parehong address na may iba't ibang payment ID, ang mga exchange ngayon ay gumagawa ng natatanging subaddress para sa bawat user. Awtomatikong tinutukoy ng wallet ng exchange kung aling subaddress ang nakatanggap ng deposito at kine-credit ang tamang account.

Inalis ng approach na ito ang pinakakaraniwang isyu sa suporta (nakalimutang payment ID) habang sabay na pinapabuti ang privacy ng lahat ng user. Ito ay isang bihirang kaso kung saan ang mas pribadong solusyon ay mas user-friendly din.

Migration Guide para sa mga Serbisyong Gumagamit pa rin ng Payment ID

Kung nag-o-operate ka ng serbisyong gumagamit pa rin ng mga payment ID, ang paglipat sa mga subaddress ay simple:

• Mag-generate ng mga subaddress — Gamitin ang wallet RPC method na create_address upang mag-generate ng natatanging subaddress para sa bawat user account
• I-store ang mapping — Magpanatili ng database mapping sa pagitan ng mga user account at kanilang mga naka-assign na subaddress
• I-update ang mga deposit instruction — Alisin ang mga payment ID field mula sa iyong deposit interface at ipakita lang ang subaddress
• I-monitor ang mga papasok na transaksyon — Gamitin ang get_transfers RPC method, na awtomatikong nire-report ang subaddress index para sa bawat papasok na transaksyon
• Panatilihin ang backward compatibility — Para sa transition period, ituloy ang pag-scan para sa mga lumang payment ID transaction para hindi maapektuhan ang mga user na nag-cache ng lumang deposit instruction

Ano ang Gagawin Kung Makatagpo Ka ng Serbisyong Humihingi ng Payment ID

Sa kabila ng pagkatigil na ilang taon na, ang ilang mas maliliit na exchange at serbisyo ay hinihingi pa rin ang mga payment ID. Kung makatagpo ka ng ganitong sitwasyon, narito ang dapat mong malaman:

Mag-ingat sa pagpapatuloy. Ang isang serbisyong gumagamit pa rin ng mga payment ID sa 2026 ay maaaring hindi sumusunod sa mga pagbabago ng Monero protocol, na maaaring magpahiwatig ng mas malawak na alalahanin sa maintenance at seguridad. Isaalang-alang kung ang serbisyo ay mapagkakatiwalaan.

Gumamit ng integrated address kung inaalok. Kung nagbibigay ang serbisyo ng integrated address (na nag-e-embed ng payment ID), awtomatikong hahawakan ng iyong wallet ang payment ID. Mas mainam ito kaysa sa manual na pag-enter ng mahabang payment ID.

I-double check ang payment ID. Kung kailangan mong i-enter nang manual ang payment ID, kopyahin at i-paste nang maingat. I-verify ang bawat character. Ang maling payment ID ay nangangahulugang nawawalang pondo na maaaring mahirap i-recover.

Isaalang-alang ang mga alternatibo. Kung humihingi ang isang serbisyo ng mahabang (hindi naka-encrypt) payment ID, malamang na tatanggihan ng modernong Monero software ang transaksyon. Maaaring kailangan mong gumamit ng ibang serbisyo o hilingin na mag-update sila sa mga subaddress. Ang mga serbisyo tulad ng MoneroSwapper ay gumagamit ng modernong infrastructure na hindi nangangailangan ng mga payment ID.

Ang Mas Malawak na Aral

Ang pagkatigil ng mga payment ID ay naglalarawan ng isang pangunahing prinsipyo ng pilosopiya ng development ng Monero: ang privacy ay hindi lang tungkol sa mga cryptographic primitive kundi tungkol din sa protocol design at mga real-world usage pattern. Kahit na may malakas na encryption, ang metadata at behavioral pattern na nilikha ng mga payment ID ay sapat na upang magpahina ng mga garantiya sa privacy.

Sa pamamagitan ng pagpapalit ng mga payment ID ng mga subaddress, inalis ng Monero ang buong klase ng mga privacy leak habang pinapabuti ang usability. Ang ganitong uri ng iterative improvement, kung saan ang protocol ay umuunlad batay sa real-world privacy analysis, ang nagbubukod sa Monero mula sa mga proyektong tinatrato ang privacy bilang feature sa halip na fundamental requirement. Ginawa ng pag-alis ng mga payment ID ang bawat transaksyon ng Monero na mas pribado sa pamamagitan ng pag-aalis ng nagbubukod na metadata at paglikha ng mas uniform na transaction pool.

Para sa mga user ngayon, ang praktikal na mensahe ay simple: gumamit ng mga subaddress para sa lahat, iwasan ang mga serbisyong nangangailangan pa rin ng mga payment ID kung maaari, at pahalagahan na ang tila maliit na pagbabago sa protocol na ito ay kumakatawan sa mga taon ng pananaliksik at pagsisikap ng komunidad upang gawing mas malakas ang privacy ng Monero para sa lahat.