hvis du har fulgt med @SpaceandTimeDB, har du sikkert hørt om bevis på SQL (vårt nye zk-bevis). så i dag skal jeg lede deg gjennom virkelige brukstilfeller for bevis på SQL med eksempler som går på tvers av DeFi, orakler, infrastruktur på tvers av kjeder, likviditetsklargjøring og til og med institusjoner. Først - la oss si at du vil lansere et token: $XYZ. Så du nærmer deg en hval og inngår en avtale ... "Hei, hvis du legger til 1 million dollar i USDT til likviditetspoolen min på Uniswap, gir jeg deg 1 % av $XYZ forsyning." Denne avtalen er skrevet inn i en smart kontrakt, ikke sant? Men utfordringen nå er at denne kontrakten må spørre og verifisere at denne hvalen faktisk deponerte det de lovet, slik at de kan bli belønnet. Så du trenger en smart kontrakt som: - bekrefter at denne hvalen virkelig la til $1M USDT. - Sporer lommeboken + tidsstempel. - Håndhever den symbolske belønningen på 1 %. men den $1Million USDT lever faktisk utenfor kjeden. Prolly på en DEX Subgraph eller Uniswap API. Det er her vi ønsker å bringe inn beviset på SQL. Så hvalens likviditetsinnskudd blir spurt via SQL, deretter blir det kryptografisk verifisert og til slutt matet inn i den smarte kontrakten med null tillitsforutsetninger. For det andre er nodeoperatøransvar (slashing/belønning). I nettverk som @chainlink eller en hvilken som helst depin, gjør flere noder jobber (henter priser, verifiserer identiteter, kjører databehandling osv.) Hver node må belønnes rettferdig og deretter. Hvis de jukser eller går offline, må de kuttes. Men det er et problem. Hvordan vet den smarte kontrakten hvilken node som gjorde hvilken jobb? Merk at operatøraktiviteten er utenfor kjeden (ofte lagret i logger eller databaser), så vil du som nodeoperatør ikke at dataene skal være nøyaktige? Hvis du er i ferd med å bli kuttet, vil du være jævla sikker på at du blir kuttet av en reell grunn. igjen, her kommer bevis på SQL til unnsetning. med Proof of SQL kan nettverket: - Spør etter logger for fullføring av jobber. - generere et verifiserbart bevis på nodeytelse. - Mat den på kjeden for å automatisere belønnings- eller slashing-logikk. Så til slutt, hvis du blir kuttet, vet du hvorfor fordi du kan se en kryptografisk kvittering som beviser at det var av en reell grunn. når det gjelder verifisering av sikkerhetsstillelse på tvers av kjeder, trenger vi fortsatt beviset på SQL. La oss anta at du bygger en utlånsprotokoll på Base og Ethereum der brukere setter inn sikkerhet på begge kjedene. Hvordan beviser du total TVL? Hvordan overvåker du brukermateriell på tvers av begge kjedene? Dessuten, hvordan forhindrer du dobbelttelling eller svindel? uten bevis på SQL, må du: - stole på tilpassede APIer. - Stol på å bygge bro over data. - Sentraliser backend. :/ men med bevis på SQL kan du: - Spør etter krysskjedetilstand fra begge kjedenes data. - Bevis det kryptografisk. - Bruk en enkelt visning for å drive utlån, likvidasjon og renter. til slutt. La oss si at du er en stor Tradfi-bank som ønsker å tokenisere eiendelene dine. Du bør gjøre følgende: - lansere RWA-er. - låne ut mot eiendeler. - bevise soliditet eller sikkerhet overfor kunder. Men aktivadataene dine ligger i en offchain-database. i stedet for å dumpe sensitiv informasjon på kjeden, kan du bruke bevis på SQL til å spørre den interne databasen, generere et kryptografisk bevis på saldoer og bevise eierskap eller støtte for eiendeler uten å avsløre faktiske data. i hovedsak ZK + SQL = institusjonelt personvern + åpenhet. hvis du bygger et token med likviditetsavtaler eller kjører et DePIN- eller orakelnettverk, eller til og med distribuerer utlån med flere kjeder, trenger du verifiserbare data utenfor kjeden. og det er det Proof of SQL fra @SpaceandTimeDB gir deg.