fix: implement proper authorization checks

Motivation

This PR addresses a critical security vulnerability in the claim_unbond_public method of the credits.aleo contract. The issue potentially allows unauthorized addresses to claim unbonded funds. and incomplete transaction records, potentially affecting the accuracy of explorer statistics and the ability to track fund movements effectively. For a comprehensive explanation of the vulnerability, including its potential impact and suggested fixes, please refer to the detailed issue description. Your careful review and prompt attention to this matter are greatly appreciated.

Test Plan

Test Plan for changes in synthesizer/process/src/tests/test_credits.rs:

Execute the existing tests that include claim_unbond_public. These tests are expected to fail due to insufficient permissions. Log specific error messages or assertion failures related to permission checks.
Replace each occurrence of private_key with the private_key of the withdrawal address corresponding to the staker parameter of claim_unbond_public that needs to execute.
Re-run the tests with this change. The tests are expected to pass successfully. Verify that no new errors were introduced and that all assertions related to claim_unbond_public are satisfied.

Related PRs

(Link your related PRs here)

Thank you for reporting!!! In the future, please use Hackerone: https://hackerone.com/aleo or the noted email address: https://github.com/AleoNet/snarkVM/blob/mainnet-staging/SECURITY.md

I assume the design (unauthorized calls) was made on purpose, because it allows for withdrawing without having to make the cold withdrawal address warm.

The risk of an adversary timing well enough and executing this function is low, given that claim_unbond_public can only be called after the properly authorized unbond_public. However, stakers should indeed be aware that they should not rely on themselves generating the transaction.

CC issue created by the author: https://github.com/AleoNet/snarkVM/issues/2556 CC @evanmarshall please advise if this PR and issue can be closed.

Thank you for your prompt response and for providing the proper channels for reporting security issues.

While I understand and agree with the convenience of allowing cold withdrawal addresses to operate without becoming warm, I'd like to respectfully highlight some concerns regarding transaction traceability and blockchain explorer functionality:

Transaction Visibility: In the test case I presented, the triggering contract address (an unrelated address: aleo1yvx2sl4p85lj83lk27x856grunzeusk3wvqnych9p3tx0w6gtqqq5t7u6s) and the withdrawal address (aleo10knhj6n6pe769gnu3vuuq2x7pxqlkc38trkj2u3ezhc08u84yyrq5u9u47) were used. After executing claim_unbond_public, the staked funds were returned to the withdrawal address. However, We couldn't find any related records in the transitions of either the withdrawal address or the unrelated address in the Aleo blockchain explorer.
Fund Traceability: From the perspective of the blockchain explorer, the funds in the withdrawal address appear to have been generated out of thin air. this lack of traceability could pose challenges for users, auditors, and analysts trying to follow the money trail.
Data Analysis and Statistics: Based on my experience with data analysis and blockchain explorer implementations, I know how crucial accurate transaction records are. The current design might make it difficult for blockchain explorers to display correct data and perform accurate data statistics and analysis. I understand that these design choices may have been intentional, but I believe it's important to consider the broader implications on system transparency, auditability, and user trust. Perhaps there might be a way to maintain the convenience of cold withdrawal addresses while also ensuring complete transaction visibility?

Yes agree the UX should be good!

Which explorer did you use? Maybe you can file an issue there, adding specific URLs to explain which data you think you'd be helpful if it would be showcased.

I used several influential explorers, but none of them could track the transition of the withdrawal address. I once studied the code of aleo open source explorer. The transition data is obtained from the block data. If the blockchain metadata does not provide the functions I mentioned above, then this data will not be tracked.

Explorers: https://testnet.aleo123.io/address/aleo10knhj6n6pe769gnu3vuuq2x7pxqlkc38trkj2u3ezhc08u84yyrq5u9u47 https://testnet.aleoscan.io/address?a=aleo10knhj6n6pe769gnu3vuuq2x7pxqlkc38trkj2u3ezhc08u84yyrq5u9u47 https://testnet.aleo.info/address/aleo10knhj6n6pe769gnu3vuuq2x7pxqlkc38trkj2u3ezhc08u84yyrq5u9u47

Reference code: https://github.com/HarukaMa/aleo-explorer/blob/mainnet/db/insert.py#L250 https://github.com/HarukaMa/aleo-explorer/blob/mainnet/webui/templates/htmx/address.jinja2#L213 https://github.com/HarukaMa/aleo-explorer/blob/mainnet/db/address.py#L91

This seems like a UI issue and not related to snarkVM. To address your points specifically:

Transaction Visibility: The address input is public and the finalize input is also public. It can be parsed from there. In fact, the signer of the transaction doesn't show up anywhere in the inputs to claim_unbond_public.
Fund traceability: The funds are traceable, even if current UIs are not tracing them properly. Everything related to staking is entirely public. No records are used. All of the data is public.
Data analysis: Again, all of the data is public.

To verify my claims, try to curl a claim_unbond_public transaction: curl --location 'https://api.explorer.aleo.org/v1/mainnet/transaction/at1wwv8a2xyd0l5p05xev3k3mflp63qprdn3rvxh0e9ephvgrjvmupqs59p4j'

It will return the following. Notice the first input has the address of the staker's address:

{
  "type": "execute",
  "id": "at1wwv8a2xyd0l5p05xev3k3mflp63qprdn3rvxh0e9ephvgrjvmupqs59p4j",
  "execution": {
    "transitions": [
      {
        "id": "au1p0dca2zlasc5zc5lqxgh0skz6ecmy2dxuv4g5fvthkhclpp9puqsyevx2c",
        "program": "credits.aleo",
        "function": "claim_unbond_public",
        "inputs": [
          {
            "type": "public",
            "id": "2780985715073871968655233862394571013903062712105595109876432324256499760036field",
            "value": "aleo19t9f8nla683mzeaz5q2gv5u90zkx9v6azwvya7fswgfkfddaucxqxr0scu"
          }
        ],
        "outputs": [
          {
            "type": "future",
            "id": "2382386710437903874930629561583649942396184697405115522827437642929446829221field",
            "value": "{\n  program_id: credits.aleo,\n  function_name: claim_unbond_public,\n  arguments: [\n    aleo19t9f8nla683mzeaz5q2gv5u90zkx9v6azwvya7fswgfkfddaucxqxr0scu\n  ]\n}"
          }
        ],
        "tpk": "8241939938060683569999027280949983828296442992488449731485067131834522048679group",
        "tcm": "4796336301706165396575904824580673513775839650786198119544944086968299257586field",
        "scm": "1950164752495050815222498550560326895673521608348683324927101079157808024527field"
      }
    ],
    "global_state_root": "sr1vkme2aqpw0p2q2ed9qcvpfhxpjr386p2gal3q24evk6ah6z39uzqjft7ke",
    "proof": "proof1qyqsqqqqqqqqqqqpqqqqqqqqqqqr2man8t6kyqpjrrzggk2wxudlpun7zgcfzewx3mpuwvrkj5wsyjd8j98eh7vllkdkxkljnhz52tcqqx9hqfff2y2z0384r8uwv2hez0pdp7z972q93w2pyjdm08j3fsqajtla0d222l8t06mpryj4jw4d0q97lzns9qj8p03ka43ykv8g8fqpc9adj9psazmakh3ghy4yypwspraadjfh40xw8p0dd6udc09mc5q96xj5yqrka5g30ea9k6dj8nguv8s7s0a5vp859atnlgw7fzxv3udd0laq9k0wjev5shg6wnzss0yqwtv9jfah5pd6x46utnt9ccd5hf9n473k36xmr732kwzc98zsnmh9mpqxmp39vjd3qs088xx9430gr0c30h2zreekn0vggl8j3f57aefq3ez9tyhtemqzscgqafgzheg4jgxll9javqd3pytcl6gyw3f3syf8n39he2e2skpkqv0x8w2qk5h67gqu77cyc3edkje3uhsctmgkgv2643l9m7y9vj3egxq8jlrywqvzvmx2h6nec377etaec3w9a36g02eu9e2x6luwsx8rj2qmgf0chtz37y56supknew4fgsmcfaqwxqejytvmcj6p88792dk4ve3qylhvan0janxns06v62mhx8pfn0h25t66hg9fpvalup0grwklprl0vgqx7k4edlpylnp9dl22dcnwf4h9805sezw0tu2esd4tgne3c73fyp06jr3qkujjqysa09yawn8m7e4jv9taztgcgjzcgdch5nhx3p66zd3zzm3r5rad2gyvrefslw2wzslnadszl3tc90eks3wpt84quddpe0ljjx8aen73jathn6p8c2nlddag4kv5zd7c9snlhaa4qhmwsvsyy80r6ekeue0a08ed2gp80xxgte2w56pm24fny00y698wzjsstqy0zx95twlw99vemt3ylqxxzuyx882v4llvprjppcrpw0xc3p4jqyjycy6g9hqllrw6grjn4n0hpxm76fh70ra9zmelstwt7aw5egqwqat74t2kql90e3xspqqw0zd9czkgzuac5y3hyahvyrxxc8ushhppnyklskmnn268q6yzef8q5ekzpcx2qzv87550gjz76n9zpeh0ajsv7f7rnxwavtyzzmg94gjqqmw7lzzhdkcnnqvdnqxw58wqr4hngcvqvqqqqqqqqqqqy33798kvy0fhhgdpkhw49gk5t78hvy7r2k2gy4u8fw3jgq4lj5n5x3hgu66t6ytkev0k8huxqfrsyqzc9k8uwgt3dzkjc6p5t7ua8n3t9k54hz0e9s2ena00p6zvsrwv2gnvuunpsdqz4y3gfwpxnmyyhqqq9pa65xv7p34vauurldnw00t4kvzklf3lg7csh026st4a8utf963pryae5mprcjpyppv73hxq5kwgn40l7z5xr4k3qjkngj793u7fv90dng2e5eefcv9galvvyjmg2yfsqqqgxc9vs"
  },
  "fee": {
    "transition": {
      "id": "au1x9gupn6mj5cnu4xldukxc7tdkqsjfk24faskvcczv7y7cnwxyurq68cxfp",
      "program": "credits.aleo",
      "function": "fee_public",
      "inputs": [
        {
          "type": "public",
          "id": "1912089133641595899719153040581086043287570646697567566893119091810384347113field",
          "value": "78711u64"
        },
        {
          "type": "public",
          "id": "1158984641199080991186441003838681952844728835793260381138755990500469556659field",
          "value": "0u64"
        },
        {
          "type": "public",
          "id": "2347092008137166748762381080634672540238769533225201845276171294961417594772field",
          "value": "4098517721536365848791150421077942317892076309170679904301812224363429788139field"
        }
      ],
      "outputs": [
        {
          "type": "future",
          "id": "2086308163558300869765270452956253791382176345057356409665646313945716541279field",
          "value": "{\n  program_id: credits.aleo,\n  function_name: fee_public,\n  arguments: [\n    aleo1t0tjdmwfz89s6d50xrzapp8f6aks5pqm0lf46xvz2y200s9rasps9g0scu,\n    78711u64\n  ]\n}"
        }
      ],
      "tpk": "3799202099460863987911231386703926704329397926211089430168803209478056655197group",
      "tcm": "1076036631642166257041418229345059425459008135839128960260839985492787236502field",
      "scm": "2556910311865472670440269320531596392191128418106551278505752909119112251766field"
    },
    "global_state_root": "sr1vkme2aqpw0p2q2ed9qcvpfhxpjr386p2gal3q24evk6ah6z39uzqjft7ke",
    "proof": "proof1qyqsqqqqqqqqqqqpqqqqqqqqqqqrtvg0gfzma4fvfc2wh2fykjmr06e5nswnqd7jt2tu5d5lxcvqp4pd4c2yaes7lrescpt2gnefvpcpqx523zvn6q4ypt4shaqsz4ymc2czl6tzklsqe0xrr2q82e64vs9vrk56z99metd2gpyksxa73la48qgvf4sh995m8m83vfqu4aw7ggrhnx0xpdr07d5af99sm29ps6qv5xd26n2qhn4zk3jav5mqjq3gtuqr7pnlmten2xztqj4t4yw3l4tajustmvnsxze9dwkc6npgy2ptf8qyru2v7l4t7vp6zqkukul8mrqq4atltvr4ggg3322q5zpfphnakr3gsvlyqk8ldw8n6v943mf2vut47u8a9zfjhs9tjz8ee4lsqvxsr72ymlcg4dwmz7rgf6v59tfh5egm6x5tkk2qh37xmpx62dutxvnpj6a3yng7466ncrak8m0kwl4nsrmn4txw8p5g96mflfcc3cz0cwm4dapsyggcsqdwd03m0qset5qzs74zg3tjph5vf95skh3646ceyqf7rtdhklu995ufjv3yu32h9kch6tz5f26c47vgw0vmkur982cvupf22j9wmd982jqs0laxhezhskqmcr43hyrnty8t7qq2gyyms54jvqxwezykeu5nywwtkhhnwsl0z40ya4yhrzpdmtjtagez82jthngq7nl0776cc3q48dnyj6jqkpt3hlwzgpy38pese86hvdu9dxvaus98yg3azan22p234umknw9ac8strpmt9numqnl4n44awltnhag7zrne33t6u9sadufyn74w737n3s3c47msnvyer8gplhpvw8vkapwlp6wz8vzhj0uka63a5tjr0nwrysqdhwrrhpkg6qkjefrqkpu2r7hqefh0zxws980xz7qah6d4n3w42htvw66ujdjedjxugk6ujz6mgnsq92h77z0mr45828kf8qulhnp7ckaj7lq4629uxv2yepx5rxcwncrjkslkw5rqtz54dmsfrhke0dm3uayxxslelxrn7s0483xguc84qzh0mflcne2um5ch7hrtsmvpt860jcr64fqfmt8e2rynegdy0yn6q5hhwnfklu2h8e99ncent2msvjs0g0wp40rs4l3fud4mz2uwwgeshucrvqwa5vyvuaw3c4x5yg42rj5s5ms69xskey0ueh3kt5gcegcjqvqqqqqqqqqqqwag43y858fwf6jhvh3exxs92q3d9e7g0thwwf7qyvvsy955355g2r43qc06yhafgxncaslw68pdqyqpks7zswvjgfl6gp62h9f92fenrrqpjrtrvmncx65myhyhjufse9p3u2khycly53y4e5dt5dh3wwvpq9mrjvqry7e7lszx2dmtjflpjy7d8j26h63qs4lncc3cdcwqktuqje6jzw40sq4ddd3ysy4jnak6jjj93ueq25xsl5pe8zf8f2urva0qnxfglk5muvv80se744nm828psqqqft40xa"
  }
}

I've conducted a similar test using the method you mentioned. Upon examining the results of the claim_unbond_public transaction you've cited, it appears that while the staker's address is indeed visible, the addresses of the initiator and the withdrawer are not explicitly disclosed in the inputs.

Here's the breakdown of the transaction I've referenced:

Transaction ID: at18g44t5eerdwxh8chzd3ydvuxpqfqlvlmsgqsg7m98h3z6craqgyqan553l
Initiator Address: aleo1yvx2sl4p85lj83lk27x856grunzeusk3wvqnych9p3tx0w6gtqqq5t7u6s
Staker Address: aleo1uqv7a3gggcs4ktc5q7m65628mje9vha0qdya49ktudxj5qkjdsyq9dqrnv
Withdrawal Address: aleo10knhj6n6pe769gnu3vuuq2x7pxqlkc38trkj2u3ezhc08u84yyrq5u9u47

I try to curl a claim_unbond_public transaction: curl --location 'https://api.explorer.aleo.org/v1/testnet/transaction/at18g44t5eerdwxh8chzd3ydvuxpqfqlvlmsgqsg7m98h3z6craqgyqan553l'

{
  "type": "execute",
  "id": "at18g44t5eerdwxh8chzd3ydvuxpqfqlvlmsgqsg7m98h3z6craqgyqan553l",
  "execution": {
    "transitions": [
      {
        "id": "au16pkcz9jrs4l8zdakh2485hkq97j3rmhc4n68lm3hynffs8lp7yqqwaa0k3",
        "program": "credits.aleo",
        "function": "claim_unbond_public",
        "inputs": [
          {
            "type": "public",
            "id": "7911790948947102874788470291414021897473990795927215408473014487529299708569field",
            "value": "aleo1uqv7a3gggcs4ktc5q7m65628mje9vha0qdya49ktudxj5qkjdsyq9dqrnv"
          }
        ],
        "outputs": [
          {
            "type": "future",
            "id": "10958893541095640937593763384941797203533676111062975760664073286707298459field",
            "value": "{\n  program_id: credits.aleo,\n  function_name: claim_unbond_public,\n  arguments: [\n    aleo1uqv7a3gggcs4ktc5q7m65628mje9vha0qdya49ktudxj5qkjdsyq9dqrnv\n  ]\n}"
          }
        ],
        "tpk": "4347947369769403584169140279780898538085258085389029689567224558708758493047group",
        "tcm": "1077206343933004225842580787580817989650794550259336506470175558714786116474field",
        "scm": "130453252457029888720825731375584837550205716859385557560390483484391455042field"
      }
    ],
    "global_state_root": "sr1a8guxrypra4nskw7e9vqk20t6nc9a28paaujecrv8mtu6vznhqgst2l2s8",
    "proof": "proof1qyqsqqqqqqqqqqqpqqqqqqqqqqqxr3jn3xc80n3lcnmwzsp2edux9uj0sggk447wcuv9q68rgn8yl2zp4wu0wc97g562y2nv0064ckyqq86knsx5pwgle3w303dezzqdmgrvr3u2s3mc6l5dzs6rc7nxqndvef8ws0n2qksuseqth2e4p58hyq8hac3wh32ea5fjd86yns4hgsqg2ckfvayfx3x7tkx7375qd0aj272ax5f7gt4x27nwn5sylqgc5jqeyglu3svefcgh28t7hqyullcqpxqnsswquma83ejhwryss8p06mcuvmzhjwxx36yqz7q36wwk4ucqzrcmsqy3hptrhrw9vuyzvf4mxupltcav7q38zgh7py2nwq0kz3e7r2rkgql3akr82nvyh3rvwehsq38pw2upyg50d8ejt3f94p3ghjecw3xd8kwrsw2dq04eag87mg0e675ljdmks2j6jl78ne5jcevzsydqa293h4cdgf3nvltdtuyvgep2wqyw7rx85zwlvgcnlc5jx4d9fp4gfjuyp0sqf60t2027w6zytqdmz7gc0djm0e26yy8st5y5geh3vkjeqmyg2l50ju5fyg76fw4utq5r4qqfj46kedx93fh3ul84cuqrt835l7wpedk2s2p3dfhc29ygcunqdu5yakrvt2r6ht5asj8rmlzwjkqm3xslam0ax63pawt7rpcqg05mh4re6xzsf9kxzfz5kl8yz2k7wtduk9qxyfpmzh8dv497ggzjmgzrwt0zfl6ssld57p4l8ge8qz5g3pja2ydle0k28gwgtf0hxrjj5cx7ely4w5ctdxlwffsgspq5ptag2rthzvgjxcmjgq0cxp79qhd0g0d3rtp3j3nngukxvxyey6kew65qyhh6vf4m5278ydczklmsjqhz6c5nd67l5mcqxvlrx3zwmn9kvs3jy8n3ay3hny6cxhwfznqqlzygnx9uyqxgrf7zwqalaxgx4y5nvrvqxr3pemdvddugkvpzccrmegpwpqzj2c2z0fr89w83a835dl49742uxcv2x86gygm7cu4rzzkzuv4pczn6ny7fhtr6pav3x8aske4k5c50wugrk9d50vmy6hqeqmy4erarvska9talr28rlnejhrvh54t8s6xercr0jtqqzxw06wfs2d6jzsmsqwka5axlxpphj27ck8m2ngjkk022duez62uy3vjxpdqdqvqqqqqqqqqqps8cy3dkq3gg9jk6gcu5s8tjdfyd3lv86fr9llu0ss5umymyf9rejkzk9l2g9lsvwq0lh99axtqgqyqfqkh502kvhrs9hnclasjnsmmc3dnxwa5qmz4r72guwu5p93qxu4vy5p6zyyj5zc4cfpepqd3gxguqq89vkh53awcua56lmvdqdwyr6jh6j0phv3qs99eylr9l5477s6sqjd2qe5l0wp9fh04vu88473jksk64z0guf9nkxpu2yxjy5m9rtqzuwl6cs84exnx9l4rlu0xl533usyqq4rc586"
  },
  "fee": {
    "transition": {
      "id": "au18y7zkgjm7crsf0ltjm6kyr79q27y9eh253t0juyd96dl8epkcsysk8wzms",
      "program": "credits.aleo",
      "function": "fee_public",
      "inputs": [
        {
          "type": "public",
          "id": "2445897880493913616012507179463626803142429246449477730066697496531543149127field",
          "value": "78711u64"
        },
        {
          "type": "public",
          "id": "2494395539289354607878927803311817721326833377203295294903451862824092222259field",
          "value": "0u64"
        },
        {
          "type": "public",
          "id": "7484458942358367125758705413518265492504265718771729300427852528500291941766field",
          "value": "7140153635699205494716678182162488306912904216021773634251549209316646830050field"
        }
      ],
      "outputs": [
        {
          "type": "future",
          "id": "8054258193364384905625263271450188849638490671330650924073636112555096703401field",
          "value": "{\n  program_id: credits.aleo,\n  function_name: fee_public,\n  arguments: [\n    aleo1yvx2sl4p85lj83lk27x856grunzeusk3wvqnych9p3tx0w6gtqqq5t7u6s,\n    78711u64\n  ]\n}"
        }
      ],
      "tpk": "6162364225431730611065260948728605448790456145889548075924527330803257794212group",
      "tcm": "4231774712212840649914057351897801157517127437600253814110577250452788397497field",
      "scm": "1953903735688632257953262759769939095371520011020021218053993655559176345111field"
    },
    "global_state_root": "sr1wtrnkyjrraufrgfjz8c4k5l0h9u0wahmmwf5sz02lh85qg5ndv8s2wldz3",
    "proof": "proof1qyqsqqqqqqqqqqqpqqqqqqqqqqqtm64jy5mt27fsh4x8sd2yquxfr5fh7grrpy34nr3kyqjncea4n7qq4ap8camef300wqjgx2tqjgvpqx0jt74juy6d2yvhwh3qj5qt0y40r2yf44z35aher0teahqxqq8u9970vmmpqmcakxc4kzpqv8rfuqwlx00r3n32u5nfxzcx8yskcz6xfv6lp0lkgd22rp8eu442v8n2gfn80zjgmy3x6py9ysuwqkyr25qqnrad4ptwdma6egftyu7ts0k4g40r9klhuwne7zmtnwayz5ee0w3a9edld45qvp45zrjjyvy3dxcptqdgtjq3mdndfe5rnrpryf7rnehgynnnnqsed6xeszuvn0kaadzygl9p943pdjwzg2ehhpen5pwgz3j0m5v2qqcymp7e9xmdrjdtsvfvep4qszwhphn4955cvsj3hjfh3wg9hc7ye0zeg25gvafw5ljkqz4srdyzrz5em2q9mgrzanmj2jl4cur6luvfha33yk0wf264xacgzjag6s4y3ga2wt7lghftmmugjqtt6zfmrzlrzm8fn3j4kq28xffu0v39awzkzv6dlvxmw32mpkt95mzd7325n6mnag4nmuzqr76rsyqxuygatwz22ylfakc7u5gp5wxh6eryslg5r6s8cvfdh792aufu6yh94palw48l8zvxfmywyff3sjsqfdnpumyxzvde09vr8e8dqkntn7mwmdqegwkyaf0kxa9rq539cv9cxvvh7h5q2cfhra75ktaxsm3sfc7h8fxkug95mkwn0xt60sk7xzm4vsnc0g63wx3n522sp06pdcwl7szyl8thdnsdksgspymsrkujztzj2gavrw0acjq95cml5j9gu2yvq09cua4krtq02ucv25s7ljms30xk090k78qwl7vrgdcunszvkfkzyj0fxvk2qrlv6fxaka3ej9s2kku5zt4wydzhychfpnp6z72zxg3lj9fa5leusvh7qcjde4e7g59qu9hxcxqcpkwpqqr4suqxl3z7qmn6j8p7wq5v0z6fa5736yga2zvg5tamwwzllmx2utyha5sd4ph8rzucsxm78ned8l0xf7g4c5hdpkvpdgazh7dn9u9pjfg2g3dv4vqpc07g9n8awf232rhsmnalnjwqmrfekd7dd9kgsczzqjd9mw5ellte25y5ahkzuc8zgg033eu5qzspqvqqqqqqqqqqp72zn4a5pn57k40tuva4ldx6y24nwerxesnv55ztfaxlha99xv2qvz7n62zy0vplwj5fefw8v3uasyqd58lfsf6a8j57y85w6r6ptpf9d4yenqrh7kk3c5m2ae98c87k5a38tevejdtcgvmj6jmn30hzqjypqy47up76qy58uc6m9f8w5qhx926jvwf5e577hchl5zr322jw5al39ew494m9m65da8f9av95jjsvymmsyqlzhn8mwj6k3ke526qgnmxp0wnh0n89smymj6e7zf0lpgygsqqqts03vt"
  }
}

However, the returned data from the API call does not include the initiator's or the withdrawal address aleo10knhj6n6pe769gnu3vuuq2x7pxqlkc38trkj2u3ezhc08u84yyrq5u9u47 , which are crucial for full transaction traceability.

It seems that it is understandable that the transaction signer will not appear. If I am the recipient of the withdrawn funds, my record will not be found in the entire blockchain.

I don't believe the address of the initiator of the transaction is important. This is a permissionless call & the identity of the initiator is not important as it is already possible to pay fees in Aleo privately.

Restricting the initiator to a particular address, in this case the withdrawal address would force validators to use a very sensitive key more often. Given that the only purpose of this is to made make indexing easier, it does not seem wise to compromise security in this way.

In Aleo in particular, because you can pay fees privately, the initiator is hidden in many cases. Also even if the fee is public, there are fee paying services one can use to have someone else generate the fee.

As for the concern about being about to see the withdraw address, you can already index this from bond_public or bond_validator.

Explorers in Aleo are already indexing all mapping changes.

Here's an example from AleoScan: https://testnet.aleoscan.io/transaction?id=at18g44t5eerdwxh8chzd3ydvuxpqfqlvlmsgqsg7m98h3z6craqgyqan553l

If you click on the mapping operations tab near the bottom you will see:

I believe that will give you the data you want. This explorer is also open-source: https://github.com/HarukaMa/aleo-explorer

Yes, we can parse FinalizeOperation from the specific transaction, such as RemoveKeyValue and UpdateKeyValue. However, if the tag information is missing in the contract, the transition will not be able to fully track the change of funds. From the perspective of account funds, if the explorer wants to obtain the correct fund data of a certain user, it needs to track all the records of the user's Address changing in the mapping, because all fund change information cannot be fully represented by transition, and the essence of each amount change is to operate the account mapping in mappings.

This is actually a tracking issue that is relatively hard for explorers.

we can parse FinalizeOperation from the specific transaction, such as RemoveKeyValue and UpdateKeyValue.

Detailed mapping value changes in Aleo network are not really visible unless you are able to directly tap into the finalize block execution during block advances; the FinalizeOperations in block only contains the key / value IDs without the actual values.

if the tag information is missing in the contract, the transition will not be able to fully track the change of funds.

As Aleo credits operations can only happen in credits.aleo program, with knowledge of how the program works internally, explorers could still track the change of funds.

In your example, the withdraw address is aleo10knhj6n6pe769gnu3vuuq2x7pxqlkc38trkj2u3ezhc08u84yyrq5u9u47. In the explorer, you can see following stats (edit: at time of writing):

Public credits: 7.130660 Aleo credits
Public credits received: 10010.185530 Aleo credits
Public credits sent: 10002 Aleo credits
Total fee spent: 0.699514 Aleo credits
(Tracking bug adjust - fee for one unbond_public call: 0.355356 Aleo credits) [^1]

We can see that 10010.185530 - 10002 - 0.699514 - 0.355356 = 7.130660, which means the explorer actually tracked the claim operation [^2].

The transition didn't appear in the "Recent transitions" tab, and it's indeed because the withdraw address is not immediately visible in inputs and outputs of the transition. However, as shown above, this is just a design quirk of the current UI. There is a plan to add a new token flow tracking tab specifically for Aleo credits and tokens that adheres to ARC-21 standard in the next iteration of AleoScan UI.

... all fund change information cannot be fully represented by transition

Also see the point above; as the credits.aleo program includes all logic related to Aleo credits operations, there are ways to fully reconstruct all fund change information.

Explorers in Aleo are already indexing all mapping changes.

This is almost true for AleoScan. Unfortunately, due to how post ratify works, currently AleoScan is not tracking full per-operation history of bonded, committee and delegated mapping of credits.aleo (example), as those three mappings are changed every block during post ratify process. This might be improved in the future when I add separate logic to deal with those values.

Edit: (TL;DR: claim_unbond_public could be tracked and is being tracked; it's just not being properly displayed in explorers.)

[^1]: AleoScan had a bug that ignored all public fee spent in unbond_public calls. There was an attempt to fix the missing data, but apparently one call has been missed here during migration (possibly related to mixing migration and rollback operations). A plan has been added to check all data again for discrepancies, and possibly manually fixing them to avoid a full resync. [^2]: https://github.com/HarukaMa/aleo-explorer/blob/mainnet/db/insert.py#L197-L213. This function actually contains all basic credits tracking logic.

Regarding the PR itself, directly changing the credits.aleo won't work as this will cause severe consensus issue. Any updates to the core protocol will need proper hardfork logic accompanying the intended changes (switch logic at height n, etc.)

@HarukaMa Hey there! thanks for getting back to me. I've gone through the code, and sure enough, it was tracking the changes in the Mapping. I'm really excited about your upcoming Aleoscan UI design.

AleoNet / snarkVM