#dusk $DUSK @Dusk
ངါထင်ခဲ့တာက Dusk Network ပေါ်မှာ staking လုပ်တာဟာ ဝှဲလ်เล็ต (wallets) နဲ့ node လုပ်ပိုင်ခွင့်ရှိသူတွေ (node operators) ဆီကပဲ သက်ဆိုင်တယ်လို့။
Stake Abstraction က ရပ်တည်တဲ့ (position) ပိုင်ရှင်ကို ပြောင်းလဲပေးတယ်။
Dusk smart contract တစ်ခုက deposit ကို လက်ခံနိုင်တယ်၊ stake ကို ဖန်တီးနိုင်တယ်၊ reward တွေကို ရနိုင်ပြီး သူ့ရဲ့ ကိုယ်ပိုင် စည်းမျဉ်းတွေအောက်မှာ ပြန်လည်ခွဲဝေပေးနိုင်သလို reinvest လည်း လုပ်နိုင်တယ်။ ဒါက staking pools၊ delegated services၊ reward splits နဲ့ derivatives တွေကို ဖန်တီးနိုင်စေပြီး အဆုံးမှာ offchain operator account တစ်ခုထဲမှာ ဆုံးဖြတ်ချက်တိုင်းကို ထားမထားပဲ ဖြစ်နိုင်စေတယ်။
stake က programmable ဖြစ်လာတယ်။ အန္တရာယ်လည်း အတူတူ programmable ဖြစ်လာတယ်။
အသုံးပြုသူတွေက provisioner ရဲ့ consensus performance ကိုပဲ အကဲဖြတ်မနေတော့ဘူး။ စာချုပ်ရဲ့ accounting၊ withdrawal logic၊ reward allocation၊ upgrade controls နဲ့ recovery path တွေကိုလည်း ထည့်စဉ်းစားရတယ်။ အလုပ်ကောင်းကောင်းလုပ်နေတဲ့ validator တောင် pool contract က shares ကို မှားတွက်မိရင် depositor ကို ကာကွယ်ပေးနိုင်မှာ မဟုတ်ဘူး။
Dusk က protocol boundary အချို့ကို ရှင်းလင်းစွာ ထားထားတယ်။ စာချုပ်တွေက 1,000 DUSK minimum stake ကိုတော့ မဖြစ်မနေ ရင်ဆိုင်ရတုန်းပဲ ဖြစ်တယ်။ Activation က နောက်တစ်ကြိမ်ပြီးနောက် epoch boundary မှာ ဖြစ်တတ်ပြီး၊ များအားဖြင့် submission ပြီးနောက် 1 နဲ့ 2 epochs ကြားမှာပါ။ စာချုပ်တစ်ခုက staking function ကို wallet တစ်ခုပဲ လုပ်သလို ခေါ်လို့ မရဘူး။ Funds တွေက Transfer Contract ကနေတဆင့် ရွေ့သွားပြီး contract-to-contract transfer နဲ့ Stake Contract ကို စတင်ပေးတယ်။
နောက်ဆုံးဒီအချက်က ကျွန်မအတွက် အရေးကြီးတယ်။ ဒါက staking action ကို ကိုယ်တိုင်တန်ဖိုးရွေ့ပြောင်းမှုနဲ့ ချိတ်ဆက်ပေးတာဖြစ်ပြီး၊ သက်ဆိုင်ရာ funds မပါဘဲ contract logic က stake လုပ်ကြောင်း ကြေညာခိုင်းခွင့် မပေးတော့ဘူး။
deposit နဲ့ active stake အကြား delay ကို application တွေက ဘယ်လိုဖော်ထုတ်လဲဆိုတာကိုတော့ ကျွန်မ စောင့်ကြည့်မယ်။ ချက်ချင်းထုတ်ပေးတဲ့ pool token က အလုပ်ဖြစ်သလို မြင်ရနိုင်ပေမယ့် အခြေခံ DUSK က activation အတွက် မစောင့်သေးဘဲ ဖြစ်နေနိုင်တယ်။ Reward claims နဲ့ unstaking callbacks တွေလည်း user balance တွေနဲ့ တစ်ပြိုင်တည်း (synchronized) ရှိနေရမယ်။
Stake Abstraction က DUSK အသုံးချမှုကို direct staking ထက် ကျယ်ပြန့်စေတယ်။ convenience က diversification ထက်သာလွန်လာခဲ့ရင် deposit တွေကို contract အရေအတွက် အနည်းငယ်ထဲမှာ ပိုစုစည်းသွားနိုင်တယ်။
Dusk က consensus position ကို composable ဖြစ်အောင် လုပ်ထားပြီးပါပြီ။ နောက်ထပ် သက်သေကတော့ pool contracts တွေက staking state တစ်ခုချင်းစီမှာ solvency ကို ဆက်လက်ထိန်းသိမ်းနိုင်တယ်၊ ownership ကို ရှင်းလင်းတယ်၊ exit တွေလည်း တရားမျှတစွာ ဖြစ်စေတယ် ဆိုတာပါ။
Programmability က manual distribution ကို ဖယ်ရှားနိုင်တယ်။ ဒါပေမယ့် program ကို ဘယ်သူက ထိန်းချုပ်ထားလဲဆိုတာ စစ်ဆေး (audit) လိုအပ်မှုကို ဖယ်ရှားမပေးနိုင်ဘူး။
ངါထင်ခဲ့တာက Dusk Network ပေါ်မှာ staking လုပ်တာဟာ ဝှဲလ်เล็ต (wallets) နဲ့ node လုပ်ပိုင်ခွင့်ရှိသူတွေ (node operators) ဆီကပဲ သက်ဆိုင်တယ်လို့။
Stake Abstraction က ရပ်တည်တဲ့ (position) ပိုင်ရှင်ကို ပြောင်းလဲပေးတယ်။
Dusk smart contract တစ်ခုက deposit ကို လက်ခံနိုင်တယ်၊ stake ကို ဖန်တီးနိုင်တယ်၊ reward တွေကို ရနိုင်ပြီး သူ့ရဲ့ ကိုယ်ပိုင် စည်းမျဉ်းတွေအောက်မှာ ပြန်လည်ခွဲဝေပေးနိုင်သလို reinvest လည်း လုပ်နိုင်တယ်။ ဒါက staking pools၊ delegated services၊ reward splits နဲ့ derivatives တွေကို ဖန်တီးနိုင်စေပြီး အဆုံးမှာ offchain operator account တစ်ခုထဲမှာ ဆုံးဖြတ်ချက်တိုင်းကို ထားမထားပဲ ဖြစ်နိုင်စေတယ်။
stake က programmable ဖြစ်လာတယ်။ အန္တရာယ်လည်း အတူတူ programmable ဖြစ်လာတယ်။
အသုံးပြုသူတွေက provisioner ရဲ့ consensus performance ကိုပဲ အကဲဖြတ်မနေတော့ဘူး။ စာချုပ်ရဲ့ accounting၊ withdrawal logic၊ reward allocation၊ upgrade controls နဲ့ recovery path တွေကိုလည်း ထည့်စဉ်းစားရတယ်။ အလုပ်ကောင်းကောင်းလုပ်နေတဲ့ validator တောင် pool contract က shares ကို မှားတွက်မိရင် depositor ကို ကာကွယ်ပေးနိုင်မှာ မဟုတ်ဘူး။
Dusk က protocol boundary အချို့ကို ရှင်းလင်းစွာ ထားထားတယ်။ စာချုပ်တွေက 1,000 DUSK minimum stake ကိုတော့ မဖြစ်မနေ ရင်ဆိုင်ရတုန်းပဲ ဖြစ်တယ်။ Activation က နောက်တစ်ကြိမ်ပြီးနောက် epoch boundary မှာ ဖြစ်တတ်ပြီး၊ များအားဖြင့် submission ပြီးနောက် 1 နဲ့ 2 epochs ကြားမှာပါ။ စာချုပ်တစ်ခုက staking function ကို wallet တစ်ခုပဲ လုပ်သလို ခေါ်လို့ မရဘူး။ Funds တွေက Transfer Contract ကနေတဆင့် ရွေ့သွားပြီး contract-to-contract transfer နဲ့ Stake Contract ကို စတင်ပေးတယ်။
နောက်ဆုံးဒီအချက်က ကျွန်မအတွက် အရေးကြီးတယ်။ ဒါက staking action ကို ကိုယ်တိုင်တန်ဖိုးရွေ့ပြောင်းမှုနဲ့ ချိတ်ဆက်ပေးတာဖြစ်ပြီး၊ သက်ဆိုင်ရာ funds မပါဘဲ contract logic က stake လုပ်ကြောင်း ကြေညာခိုင်းခွင့် မပေးတော့ဘူး။
deposit နဲ့ active stake အကြား delay ကို application တွေက ဘယ်လိုဖော်ထုတ်လဲဆိုတာကိုတော့ ကျွန်မ စောင့်ကြည့်မယ်။ ချက်ချင်းထုတ်ပေးတဲ့ pool token က အလုပ်ဖြစ်သလို မြင်ရနိုင်ပေမယ့် အခြေခံ DUSK က activation အတွက် မစောင့်သေးဘဲ ဖြစ်နေနိုင်တယ်။ Reward claims နဲ့ unstaking callbacks တွေလည်း user balance တွေနဲ့ တစ်ပြိုင်တည်း (synchronized) ရှိနေရမယ်။
Stake Abstraction က DUSK အသုံးချမှုကို direct staking ထက် ကျယ်ပြန့်စေတယ်။ convenience က diversification ထက်သာလွန်လာခဲ့ရင် deposit တွေကို contract အရေအတွက် အနည်းငယ်ထဲမှာ ပိုစုစည်းသွားနိုင်တယ်။
Dusk က consensus position ကို composable ဖြစ်အောင် လုပ်ထားပြီးပါပြီ။ နောက်ထပ် သက်သေကတော့ pool contracts တွေက staking state တစ်ခုချင်းစီမှာ solvency ကို ဆက်လက်ထိန်းသိမ်းနိုင်တယ်၊ ownership ကို ရှင်းလင်းတယ်၊ exit တွေလည်း တရားမျှတစွာ ဖြစ်စေတယ် ဆိုတာပါ။
Programmability က manual distribution ကို ဖယ်ရှားနိုင်တယ်။ ဒါပေမယ့် program ကို ဘယ်သူက ထိန်းချုပ်ထားလဲဆိုတာ စစ်ဆေး (audit) လိုအပ်မှုကို ဖယ်ရှားမပေးနိုင်ဘူး။
