ខ្ញុំមិនឃើញការលុបចោល (revocation) នៅក្នុង Sign Protocol ជា add-on ប្រណីតអ្វីនោះទេ…
ខ្ញុំមើលវាជា “ឧបករណ៍សុវត្ថិភាព”
បើខ្ញុំដាក់ឈ្មោះខ្ញុំនៅលើអ្វីមួយនៅលើ on-chain ខ្ញុំត្រូវតែមានវិធីដកថយ ប្រសិនបើអ្វីៗប្រែទៅជាលំបាក។ វាមិនមែនជាជម្រើសទេ—វាគឺជាការរស់រានមានជីវិត។
ការលុបចោល តាមមូលដ្ឋានគឺសាមញ្ញ៖
ខ្ញុំបានចុះហត្ថលេខា → ខ្ញុំគួរតែអាចធ្វើឲ្យវាមិនមានសុពលភាពបាននៅពេលក្រោយ ប្រសិនបើចាំបាច់។
ព្រោះសូមនិយាយឲ្យត្រង់…
កូនសោ (keys) អាចត្រូវបានបំពាន (compromise)។
លក្ខខណ្ឌ (terms) អាចផ្លាស់ប្តូរ។
ហើយពេលខ្លះ អ្នកដឹងយឺតពេលទៅហើយ—អ្នកទើបតែចុះហត្ថលេខាលើអ្វីមួយដែលអ្នកមិនគួរ។
នោះហើយជាមូលហេតុដែលច្បាប់ជុំវិញការលុបចោលពិតជាមានសារៈសំខាន់ជាងមុខងារខ្លួនឯងទៅទៀត៖
តើអ្នកណាមានអំណាចក្នុងការលុបចោល? (កុំឲ្យវាជា contract ចៃដន្យ)
តើវាអាចកើតឡើងពេលណា? (គ្រប់ពេលទាំងអស់ vs លក្ខខណ្ឌគ្រប់គ្រង)
តើវាត្រូវបានកត់ត្រាយ៉ាងដូចម្តេច?
បើកំណត់ត្រានោះមិនច្បាស់លើ on-chain មើលឃើញ និងតាមដានបាន នោះតើមានន័យអ្វី? ខ្ញុំមិនចង់ទុកចិត្តប្រព័ន្ធមួយដែលការលុបចោល “រលាយ” ទៅក្នុងស្រមោលទេ។
ខ្ញុំចង់បានសញ្ញាដែលច្បាស់ថា៖
“ហត្ថលេខានេះបានធ្វើហើយ។ ចប់ហើយ។ គ្មានការជជែកទៀតទេ។”
ព្រោះបើគ្មាននោះ នរណាម្នាក់អាចធ្វើពុតបានថា វានៅតែមានទម្ងន់ដូចដើម។
ហើយអាតែនហ៍—ខ្ញុំយល់ពី tradeoff។
បើការលុបចោលងាយពេក មនុស្សនឹងយកវាទៅប្រើខុស។
បើតឹងពេក វានឹងក្លាយទៅជាគ្មានប្រយោជន៍។
បញ្ហាប្រឈមផ្នែករចនាពិតប្រាកដគឺ “តុល្យភាព”។
ប៉ុន្តែរឿងមួយច្បាស់សម្រាប់ខ្ញុំ៖
ការលុបចោល មិនមែនជាមុខងារដែលកម្រិតខ្ពស់នោះទេ។
វាជា “អនាម័យមូលដ្ឋាន”។
បើ protocol ដែលដោះស្រាយ attestations និង signatures មិនធ្វើវាឲ្យត្រូវ នោះអ្នកនឹងត្រូវប្រឈម—សាមញ្ញដូច្នោះ។
សម្រាប់ខ្ញុំផ្ទាល់ ខ្ញុំតែទៅប្រើប្រព័ន្ធដែលផ្លូវចេញ (exit path) ត្រូវបានកំណត់ហើយប៉ុណ្ណោះ។
បើខ្ញុំមិនយល់ពីរបៀបចេញ ខ្ញុំមិនចូលទេ។
គ្រប់គ្រង keys របស់អ្នក។
យល់ពីលំហូរ (flow)។
ធ្វើឲ្យច្បាស់ជាមួយយន្តការនៅលើ on-chain។
នោះហើយជារបៀបដែលអ្នកនៅតែមានសុវត្ថិភាព។
@SignOfficial #signdigitalsovereigninfra $SIGN
ខ្ញុំមើលវាជា “ឧបករណ៍សុវត្ថិភាព”
បើខ្ញុំដាក់ឈ្មោះខ្ញុំនៅលើអ្វីមួយនៅលើ on-chain ខ្ញុំត្រូវតែមានវិធីដកថយ ប្រសិនបើអ្វីៗប្រែទៅជាលំបាក។ វាមិនមែនជាជម្រើសទេ—វាគឺជាការរស់រានមានជីវិត។
ការលុបចោល តាមមូលដ្ឋានគឺសាមញ្ញ៖
ខ្ញុំបានចុះហត្ថលេខា → ខ្ញុំគួរតែអាចធ្វើឲ្យវាមិនមានសុពលភាពបាននៅពេលក្រោយ ប្រសិនបើចាំបាច់។
ព្រោះសូមនិយាយឲ្យត្រង់…
កូនសោ (keys) អាចត្រូវបានបំពាន (compromise)។
លក្ខខណ្ឌ (terms) អាចផ្លាស់ប្តូរ។
ហើយពេលខ្លះ អ្នកដឹងយឺតពេលទៅហើយ—អ្នកទើបតែចុះហត្ថលេខាលើអ្វីមួយដែលអ្នកមិនគួរ។
នោះហើយជាមូលហេតុដែលច្បាប់ជុំវិញការលុបចោលពិតជាមានសារៈសំខាន់ជាងមុខងារខ្លួនឯងទៅទៀត៖
តើអ្នកណាមានអំណាចក្នុងការលុបចោល? (កុំឲ្យវាជា contract ចៃដន្យ)
តើវាអាចកើតឡើងពេលណា? (គ្រប់ពេលទាំងអស់ vs លក្ខខណ្ឌគ្រប់គ្រង)
តើវាត្រូវបានកត់ត្រាយ៉ាងដូចម្តេច?
បើកំណត់ត្រានោះមិនច្បាស់លើ on-chain មើលឃើញ និងតាមដានបាន នោះតើមានន័យអ្វី? ខ្ញុំមិនចង់ទុកចិត្តប្រព័ន្ធមួយដែលការលុបចោល “រលាយ” ទៅក្នុងស្រមោលទេ។
ខ្ញុំចង់បានសញ្ញាដែលច្បាស់ថា៖
“ហត្ថលេខានេះបានធ្វើហើយ។ ចប់ហើយ។ គ្មានការជជែកទៀតទេ។”
ព្រោះបើគ្មាននោះ នរណាម្នាក់អាចធ្វើពុតបានថា វានៅតែមានទម្ងន់ដូចដើម។
ហើយអាតែនហ៍—ខ្ញុំយល់ពី tradeoff។
បើការលុបចោលងាយពេក មនុស្សនឹងយកវាទៅប្រើខុស។
បើតឹងពេក វានឹងក្លាយទៅជាគ្មានប្រយោជន៍។
បញ្ហាប្រឈមផ្នែករចនាពិតប្រាកដគឺ “តុល្យភាព”។
ប៉ុន្តែរឿងមួយច្បាស់សម្រាប់ខ្ញុំ៖
ការលុបចោល មិនមែនជាមុខងារដែលកម្រិតខ្ពស់នោះទេ។
វាជា “អនាម័យមូលដ្ឋាន”។
បើ protocol ដែលដោះស្រាយ attestations និង signatures មិនធ្វើវាឲ្យត្រូវ នោះអ្នកនឹងត្រូវប្រឈម—សាមញ្ញដូច្នោះ។
សម្រាប់ខ្ញុំផ្ទាល់ ខ្ញុំតែទៅប្រើប្រព័ន្ធដែលផ្លូវចេញ (exit path) ត្រូវបានកំណត់ហើយប៉ុណ្ណោះ។
បើខ្ញុំមិនយល់ពីរបៀបចេញ ខ្ញុំមិនចូលទេ។
គ្រប់គ្រង keys របស់អ្នក។
យល់ពីលំហូរ (flow)។
ធ្វើឲ្យច្បាស់ជាមួយយន្តការនៅលើ on-chain។
នោះហើយជារបៀបដែលអ្នកនៅតែមានសុវត្ថិភាព។
@SignOfficial #signdigitalsovereigninfra $SIGN