#dusk $DUSK
Bu iki gün @Dusk -in son Developer Update-ına baxanda, məncə “bir də ZK funksiyası əlavə olundu” ifadəsindən daha diqqətəlayiq bir yenilik gördüm.
zk-tools indi Groth16 Solidity verifier yaratma və yoxlama alətlərini dəstəkləməyə başlayır.
İlk baxışda xırda görünür.
Amma əgər həqiqətən ZK tətbiqləri yazmısansa, bilirsən ki, proof yaratmaq sadəcə ilk yarıdır.
Sonra çox real bir problem qalır:
Solidity müqaviləsi bu proof-u necə qəbul etməlidir?
Circuit qaydaları müəyyən edir, prover proof yaradır, amma EVM tərəfində hələ də verifier contract lazım olur ki, proof və public inputs-un ilkin məhdudiyyətlərə uyğun olub-olmadığını yoxlasın.
Bu qatdakı interfeys yaxşı qurulmasa, altındakı kriptoqrafiya nə qədər güclü olsa da, adi Solidity tərtibatçısı üçün bu hələ də uzaq qalır.
Ona görə də bu dəfə Dusk-un yeniləməsinə baxanda əsas diqqətim Groth16 adının özü deyil.
Daha çox bu boşluğu doldurmasına yönəlir:
proof → verifier → Solidity application
Aradakı bu mühəndislik zənciri.
Təbii ki, verifier də hər şeyi həll etmir.
O, bir proof-un əvvəlcədən yazılmış circuit-ə uyğun olub-olmadığını təsdiqləyə bilər, amma məlumatın haradan gəldiyini, bu qaydanın biznes baxımından məna daşıyıb-daşımadığını, uyğunluğun hələ də qüvvədə olub-olmadığını tətbiqin özü müəyyən etməlidir.
Məncə bu, əslində normaldır.
Kriptoqrafiya “sübutu” yoxlayır, məhsul isə bu sübutla nə edəcəyinə qərar verir.
DuskEVM hələ də Testnet-dədir, ona görə bir verifier tooling əlavə olundu deyə dərhal bütün ZK workflow-un yetkinləşdiyini demərəm.
Amma belə bir yenilik ən azı sadəcə “ZK dəstəyi var” deməkdən daha realdır.
Tərtibatçının həqiqətən istifadə edə bilməsi üçün çox vaxt elə bu qədər də cazibəsiz görünən interfeyslər lazım olur.
Bu iki gün @Dusk -in son Developer Update-ına baxanda, məncə “bir də ZK funksiyası əlavə olundu” ifadəsindən daha diqqətəlayiq bir yenilik gördüm.
zk-tools indi Groth16 Solidity verifier yaratma və yoxlama alətlərini dəstəkləməyə başlayır.
İlk baxışda xırda görünür.
Amma əgər həqiqətən ZK tətbiqləri yazmısansa, bilirsən ki, proof yaratmaq sadəcə ilk yarıdır.
Sonra çox real bir problem qalır:
Solidity müqaviləsi bu proof-u necə qəbul etməlidir?
Circuit qaydaları müəyyən edir, prover proof yaradır, amma EVM tərəfində hələ də verifier contract lazım olur ki, proof və public inputs-un ilkin məhdudiyyətlərə uyğun olub-olmadığını yoxlasın.
Bu qatdakı interfeys yaxşı qurulmasa, altındakı kriptoqrafiya nə qədər güclü olsa da, adi Solidity tərtibatçısı üçün bu hələ də uzaq qalır.
Ona görə də bu dəfə Dusk-un yeniləməsinə baxanda əsas diqqətim Groth16 adının özü deyil.
Daha çox bu boşluğu doldurmasına yönəlir:
proof → verifier → Solidity application
Aradakı bu mühəndislik zənciri.
Təbii ki, verifier də hər şeyi həll etmir.
O, bir proof-un əvvəlcədən yazılmış circuit-ə uyğun olub-olmadığını təsdiqləyə bilər, amma məlumatın haradan gəldiyini, bu qaydanın biznes baxımından məna daşıyıb-daşımadığını, uyğunluğun hələ də qüvvədə olub-olmadığını tətbiqin özü müəyyən etməlidir.
Məncə bu, əslində normaldır.
Kriptoqrafiya “sübutu” yoxlayır, məhsul isə bu sübutla nə edəcəyinə qərar verir.
DuskEVM hələ də Testnet-dədir, ona görə bir verifier tooling əlavə olundu deyə dərhal bütün ZK workflow-un yetkinləşdiyini demərəm.
Amma belə bir yenilik ən azı sadəcə “ZK dəstəyi var” deməkdən daha realdır.
Tərtibatçının həqiqətən istifadə edə bilməsi üçün çox vaxt elə bu qədər də cazibəsiz görünən interfeyslər lazım olur.