Smart Contract

1️⃣ Kripto hesabının gizli anahtarı hackerların eline geçmiş, cüzdanına bot kurulmuş bir hesaptaki stake de 90.000 USD’lik #AVAX ve 1 haftalık süremiz var ! Bu hafta #Avalanche ağında büyük bir mücadele ile en tehlikeli botlardan biri ile savaşarak , stake’teki AVAX ları kurtarmak için blockchainin karanlık ormanına daldım Avalanche P-Chain’de geçen bu 1 haftalık mücadelemizin detayları ve 90.000 USD’lik AVAX’ı nasıl kurtardığımın hikayesi aşağıda 👇👇

Blokzincirini bu kadar güvenli kılan asıl güç nedir? ​🤔 Bu haftaki yazımızda, blokzinciri ekosisteminin temel taşlarını ve güvenliğin anatomisini mercek altına aldık. ​Keyifli okumalar: [@firatblockchain/blockchain-ve-kriptografi-i%CC%87li%C5%9Fkisi-d45d7d2bed89?postPublishedType=initial" target="_blank" rel="nofollow noopener">medium.com/@firatblockcha…] 🔗

@ibrahimgantep Yöntem ilk. Fonlar Ethereum da @TornadoCash de aklanmaya başlandı, Tornado süreci uzun sürecektir

@0xSmartContract Yöntem ilk sanırım .Lazarus tarzı bir grup mu yapmış .Fonlar eth ağında aklandı mı ?

Drift hack ini özetlersek ; Bu, klasik anlamda “kontratta bir bug buldum, tek tx ile tokenları çaldım” tipi bir hack gibi görünmüyor. Daha çok aylar süren hedefli bir sızma + güven kazanma + yetkili erişimi ele geçirme operasyonu gibi duruyor. Adım adım anlatayım: 1) Saldırganlar önce teknik açık değil, insan hedefledi. Projeye çok hakimler ve aylar hatta 1 yıl önceden çalışmaya başlıyorlar, bu projeyi neden seçtiler hacklemek için bunu bilmiyoruz ama bu bile tesadüf olamaz 2025 sonbaharı civarında bazı kişiler kendilerini quant trading firm gibi tanıtarak Drift katkıcılarıyla tanışıyor. Bu tanışma tek seferlik değil; birden fazla ülkede, birden fazla büyük kripto konferansında yüz yüze ilişki kuruyorlar. Teknik konuşabiliyorlar, geçmişleri inandırıcı görünüyor, Drift’in nasıl çalıştığını biliyorlar. Sonra Telegram grubu açılıyor ve aylarca normal iş ilişkisi gibi görünen konuşmalar devam ediyor. 2) Güven inşa etmek için gerçek para da koyuyorlar Aralık 2025–Ocak 2026 arasında bu grup Drift üzerinde bir Ecosystem Vault onboard ediyor, strateji detayları veriyor, toplantılar yapıyor ve 1 milyon doların üzerinde gerçek sermaye yatırıyor. Yani dışarıdan bakan biri için bunlar “şüpheli yabancılar” değil, gerçekten entegre olan ciddi bir karşı taraf gibi görünüyor. Bu kısmın çarpıcı tarafı bu: saldırı, güveni satın alacak kadar sabırlı ve kaynaklı yürütülmüş.Bu belkide bir ilk 3) Sonra contributor cihazlarına temas eden tuzaklar devreye giriyor Drift’in ön incelemesine göre en az iki muhtemel vektör var: Bir contributor’a, sanki vault frontend’i dağıtılacakmış gibi bir repo klonlatılıyor. Başka bir contributor ise bu grubun cüzdan ürünü gibi sunduğu bir TestFlight uygulamasını indiriyor. Repo tarafında özellikle önemli iddia şu: Aralık 2025–Şubat 2026 döneminde güvenlik topluluğunun uyardığı bir VSCode/Cursor zafiyeti kullanılmış olabilir. İddiaya göre sadece klasörü/repo’yu editörde açmak bile sessizce zararlı kod çalıştırmaya yetebiliyordu; kullanıcıdan tıklama, izin, uyarı gerekmiyordu. Bu çok kritik, çünkü “ben bir şey install etmedim, sadece açtım” savunmasını da boşa çıkarıyor. Drift bunu kesin hükümle değil, “olası mekanik” olarak paylaşıyor. 4) Amaç kontratı hacklemek değil, yönetim yüzeyini ele geçirmekti Bu bir admin capture. Yani saldırgan önce protokolün neye güveneceğini belirleyen yönetim/izin mekanizmasını ele geçiriyor. Burada “durable nonce” tabanlı yetki kötüye kullanımı öne çıkıyor. Durable nonce niye önemli? Normal Solana işlemleri hızlı expire olur. Ama durable nonce ile bir işlem daha erken imzalanıp daha sonra saldırganın seçtiği anda yürürlüğe sokulabilir. Bu da “onay anı” ile “icra anı”nı ayırır. Sosyal mühendislikle veya cihaz ele geçirmeyle alınmış imzalar, daha sonra çok uygun bir zamanda ateşlenebilir. Yani hacker lar bu hacki tek kalemde yapabilmek için bu mimariyi kullandı 5) Bir kez admin kontrolü alınınca, protokolün güven modeli bükülüyor Bu noktadan sonra saldırganın mantığı şu oluyor: Önce admin veya Security Council düzeyinde yetkiyi ele geçir. Sonra protokolün hangi oracle’a, hangi collateral’a, hangi withdrawal guard’ına güveneceğini değiştir. Yani sistemin savunmalarını “aşmak” yerine, savunmaların ayarını değiştir.Buda yine rastlantı değil tamamen oyun teorisi yapısıyla tasarlanan üst düzey bir bakış açısı Bu yüzden olay “sadece oracle exploit” ya da “sadece collateral manipülasyonu” diye okunmamalı. Asıl kök neden, bu ayarları değiştirebilecek otoritenin ele geçirilmesi. 6) Sonra sahte/değersiz varlık meşru collateral gibi kullanılabiliyor Teknik anlatımda bir teori olarak CVT adı geçen değersiz bir tokenın collateral gibi kullanıldığı senaryo var. Hacker direkt protodoldeki tüm tokenları çekemez, böyle bir yapı yok , bu nedenle böyle bir mimari ile tüm projeyi hackliyor 7) Ana boşaltmadan önce küçük bir prova işlemi de görülüyor En net erken kanıtlardan biri, Drift Vault’tan saldırgan cüzdanına giden çok küçük bir 0.03000003 WSOL transferi. Bu miktar küçük olduğu için önemsiz değil; tam tersine muhtemelen “çekiş hattı çalışıyor mu” diye yapılmış testi gibi duruyor. 8) Sonra gerçek varlıklar hızla çekilip köprüleniyor Yetki ve güven modeli ele geçirildikten sonra gerçek fonlar çıkıyor. Yani boşaltma yalnızca “protokolden çalmak” değil, aynı zamanda çok hızlı bir kaçış rotası tasarlamak demek. Bunun bir kısmı da önceden hazırlanmış gibi görünüyor. Hacker da Solanadan Ethereum ağına hızla fonları taşıyor 9) Neden bu olay farklı? Çünkü burada saldırı zinciri şöyle: Konferans ➡️ tanışma ➡️Güven ➡️ Entegrasyon ➡️ Gerçek para yatırma ➡️ Contributor cihazına temas ➡️ Yönetim erişimi ➡️ Protokol güven modelini değiştirme ➡️ Fonları boşaltma ➡️ İzleri silme Bu klasik bir saldırıdan çok daha sofistike. Drift protokolü ayrıca exploit anında Telegram sohbetlerinin ve zararlı yazılımların temizlenmiş olduğunu söylüyor. Bu da operasyonun doğaçlama değil, önceden prova edilmiş ve disiplinli olduğunu düşündürüyor. Özetle ; Drift’te olan şey büyük ihtimalle bir kod bug’ından ziyade, aylarca süren sosyal mühendislik ve cihaz ele geçirme ile admin/yönetim katmanının ele geçirilmesi; ardından protokolün neye güveneceğinin saldırgan lehine yeniden ayarlanıp gerçek fonların hızla dışarı çıkarılmasıdır. Bu yapıda ve kaydın büyüklüğünde bir saldırı türü tarihte bir ilk

Siber Güvenlikde artık kapsam değişiyor Drift hack’i klasik bir exploit değil, modern çağın hibrit operasyonu gibi duruyor.Böyle bir hack daha önce görmedim Aylarca güven inşa et, gerçek sermaye koy, insanlarla fiziksel dünyada bağ kur, geliştirici cihazına temas et, sonra bir anda yönetişimi ele geçir ve zincir üstünde boşalt. Eskiden saldırgan kontratı inceliyordu. Bugün saldırgan, kişileri inceliyor. Bu yüzden artık denetim kapsamı şuraya kadar uzanıyor: ➡️ Multisig imza akışı ➡️ Contributor cihaz güvenliği ➡️ VSCode/Cursor/repo açma yüzeyi ➡️ Mobil test uygulamaları ➡️ Konferans/network ilişkileri ➡️ Yönetici ve geliştirici çevresi ➡️ Olay anı koordinasyon ve olay sonrası hızlı sonuç alma refleksi Kodlamada güvenlik artık kod incelemesinden ibaret değil; Kurumsal davranış bilimi, opsec , oyun teorisi ve insan istihbaratı savaşına doğru gidiyor

Artık en büyük güvenlik açığı kod değil, insanın “inanma isteği”. Son dönemde yaşanan Axios npm package saldırısı bize sadece teknik bir zafiyeti değil, çok daha derin bir gerçeği gösteriyor: Artık saldırılar koddan değil, insandan başlıyor. Bu makaleye göre saldırganlar: Tek tek geliştiricileri hedef alıyor (özellikle yüksek etkiye sahip olanları) Sahte LinkedIn, Slack ve toplantılarla güven oluşturuyor Son aşamada zararlı yazılım yükletiyor Ardından .npmrc, tokenlar ve oturum bilgilerini ele geçiriyor Ve npm’e doğrudan kötü kod publish edebiliyor Claude ın son haftada ki kod sızıntısı da bir hack olabilir mi? socket.dev/blog/attackers…

@dorukismen in Polymarket kullanım klavuzu videosu gayet güzel bir özet, merak edenlerin izlemesini tavsiye ederim Polymarket i öğrenmek ; Finansal okuryazarlık açısından sana üç şey kazandırır. Birincisi, olasılık düşünmeyi öğretir: “olur mu olmaz mı” yerine “yüzde kaç ihtimalle olur” diye bakarsın. İkincisi, beklenti ile fiyat arasındaki ilişkiyi görürsün; doğru olmak yetmez, piyasanın neyi ne kadar fiyatladığı önemlidir. Üçüncüsü, haber akışının fiyatlara anında nasıl işlendiğini izlersin.

@yapayzekahocasi Aslında problem teknoloji değil. Problem, sistemin teknolojiye bakışı: “Kontrol edemiyorsak, gelişmesin.”

Daha önce Türk hukukuna göre halka açık bir siteden scraping yapmanın TCK kapsamında suç olmadığına dair bir Yargıtay kararı paylaşmıştım (Yargıtay 8. Ceza Dairesi, 2022/526 E., 2024/2623 K.). Ancak bunun TTK'ya göre haksız rekabet sayılabileceğini de eklemiştim. Hukukçu takipçilerim de bu konuda örnek karar istedi. İşte çok güncel bir örnek: Bakırköy 2. Asliye Ticaret Mahkemesi, 2023/940 E., 2025/971 K. Bir şirket, büyük bir emlak ilan sitesinden web scraping yöntemiyle ilan verilerini (emlak tipi, metrekare, rayiç, konum, oda sayısı, bina yaşı vb.) çekiyor. Bu verilere kendi yapay zeka ve teknik analizlerini ekleyerek kullanıcılara "gayrimenkul risk raporu" hizmeti sunuyor. Emlak sitesi noterden iki ihtarname çekiyor, IP adreslerini engelliyor. Ama davalı şirket her seferinde farklı IP adresleri kullanarak veri çekmeye devam ediyor. Davalının savunması: "Bu veriler halka açık. İlan sitesi sadece yer sağlayıcı, içeriği kullanıcılar giriyor. Bu veriler üzerinde hak iddia edemezler. Üstelik biz tamamen farklı bir hizmet sunuyoruz." Mahkeme bu savunmayı kabul etmiyor. Gerekçesi çok önemli: İlanları bireyler girse bile, platformun bu verileri işleme biçimi, sınıflandırması, filtreleme sistemi ve kullanıcı deneyimine yaptığı yatırım, bu içeriği TTK kapsamında "iş ürünü" haline getiriyor. Veriler sui generis veri tabanı niteliğinde. Emek doğrudan veride olmasa bile, verinin sunumunda olması da korumayı gerektiriyor. Sonuç: Davalının eylemleri TTK 55/(1)-c kapsamında haksız rekabet sayılıyor. Haksız rekabetin tespitine ve menine karar veriliyor. 50.000 TL manevi tazminata hükmediliyor. Maddi tazminat ise davacının somut gelir kaybını ispatlayamaması nedeniyle reddediliyor. Yani halka açık veriden scraping yapmanız tek başına ceza gerektirmeyebilir, ama elde ettiğiniz verileri ticari faaliyette kullanırsanız haksız rekabet tazminatıyla karşılaşabilirsiniz. Ne çektiğiniz değil, ne için kullandığınız belirleyici. Tabii önemli bir not: Bu karar henüz bir ilk derece mahkemesi kararı, Yargıtay'dan geçmiş değil. İstinaf ve temyiz aşamalarında farklı bir sonuç çıkması mümkün. Bu kararı da Yargı CLI + Antigravity ile buldum bu arada. Yorumlamasını da avukatım ile yaptık. Sen hukukçu musun demeyin:) mevzuat.adalet.gov.tr/ictihat/117842…

@arsen_bt Sir, defonder.xyz ; "DNS_PROBE_FINISHED_NXDOMAIN"

Along the journey I built Defendor - my project to help auditors level up faster. • real experience • real alpha • weekly newsletter • practical lessons from real audits If you want to level up in Web3 Security, you’re welcome to join. defendor.xyz

I’m Arsen Web3 Security Engineer 2 years ago, I was noob in coding Today, I secure top crypto projects Here’s how I started from 0 🧵

@zacodil If these 18 audits had been conducted with this level of rigor, this problem would have been resolved. A high-level audit rating for centralization risks; github.com/code-423n4/202…

Resolv was audited 18 times. The exploited contract was reviewed. The vulnerability was never flagged. In December 2024, auditors reviewed this exact contract and found 5 issues, including a High severity bug in the fee function. One finding was literally called "Missing upper limit validation." But it was about price bounds in a different contract. The function that lets a single key mint unlimited tokens with no ceiling? Not mentioned. That's how audits work: a function restricted to a trusted role is "privileged, out of scope." Auditors verify code correctness, not whether trusting one key with unlimited power is a good idea. 18 audits couldn't prevent this. The flaw wasn't in the code - it was in the architecture.

İmzayı Kim Atıyor Değil, Kararı Kim Veriyor? Ethereum’da PoS + MEV-Boost Sonrası Gerçek Güç Dağılımı ; Blockchain dünyasında yıllarca merkeziyetsizliğin ölçüsü basitti: “Ağda kaç bağımsız node var?” Proof of Work döneminde bu sorunun karşılığı açıktı. Madenciler hem işlemleri seçiyor hem sıralıyor hem de blokları oluşturuyordu. Yani güç tek bir noktada toplanıyordu: Madenci = Block proposer + Block builder Bu nedenle analiz de basitti: Hash gücü kimdeyse, güç ondadır. Ancak Ethereum’un The Merge sonrası mimarisi bu denklemi kökten değiştirdi. PoS Dünyasına geçilince roller ayrıldı Ve Ethereum’da süreç ikiye bölünmüş durumda: Validator (Proposer) → Bloğu yayınlayan taraf Builder → Bloğun içeriğini oluşturan taraf Bu ayrımın temelinde MEV-Boost yer alır. Yeni model şu şekilde işler: 1️⃣ Builder, mempool’daki işlemleri analiz eder 2️⃣ Maksimum kâr getiren block’u oluşturur 3️⃣ Validator’a teklif (bid) sunar 4️⃣ Validator, en yüksek teklifi seçer ve bloğu yayınlar Bu sistem teknik olarak bir açık artırmadır > Validator karar vermez, en çok ödeyeni seçer. ⚠️ Güç Kimin Elinde? Bu noktada en önemli fark ortaya çıkar: Validator → Pasif seçici Builder → Aktif karar verici Builder şunları belirler: =》Hangi işlemler block’a girecek =》Hangi sırayla işlenecek =》Kim kâr edecek, kim zarar edecek Dolayısıyla: > Gerçek güç, bloğu önerende değil; bloğu inşa edendedir. Güncel veriler şunu gösteriyor: Top builder’lar → çoğu zaman %70–90 block üretimi Günlük MEV hacmi → $1M – $5M+ Tek blokta MEV → $100K+ seviyesine çıkabiliyor Bu tablo şu sonucu doğurur: Validator sayısı milyonlara ulaşsa bile,eğer blokların çoğunu birkaç builder hazırlıyorsa, güç fiilen bu builder’larda dır. Bu modelin en tehlikeli yönü şudur: Merkeziyet vardır ama görünmezdir. PoW döneminde:Hashrate ölçülürdü, güç açıkça analiz edilirdi Bugün ise: =》Builder algoritmaları kapalı =》Orderflow özel (private) =》Karar mekanizması off-chain Yani: Güç var, ama şeffaf değil. Yeni Riskler Nelerdir ? 1) Builder Oligopolü En iyi veri, en düşük latency ve en gelişmiş algoritmaya sahip builder’lar sürekli kazanır.Bu da “winner-takes-most” dinamiği yaratır. 2) Sansür RiskiBuilder, belirli işlemleri: Dahil etmeyebilir, geciktirebilir Bu özellikle regülasyon uyumlu (OFAC vb.) sistemlerde fiili sansüre dönüşebilir. Validator Sayısı Neden Yeterli Değil? Bugün sık duyulan argüman: > “1 milyon validator var, sistem güvenli” 1 milyon validator ama 5 builder → %80 block üretimi uapar ve sistem görünürde dağıtık, gerçekte ise yoğunlaşmıştır. ☢ Ethereum Bu Riski Biliyor mu? Ve Ne Yapıyor? Ethereum’da PoS + MEV-Boost sonrası ortaya çıkan en büyük sorunlardan biri, gücün validator’lardan builder’lara kaymasıdır. Bu durum yalnızca teorik değil, geliştirici ekibin aktif olarak çözmeye çalıştığı bir problemdir. Ethereum çekirdek geliştiricileri bu riski açıkça kabul ediyor ve birkaç kritik çözüm üzerinde çalışıyor: 🏷 PBS (Proposer-Builder Separation): Block üretimini protokol seviyesinde düzenleyerek relay ve builder gücünü daha şeffaf hale getirmek 🏷Encrypted Mempool: İşlemleri gizleyerek front-running ve MEV sömürüsünü azaltmak 🏷Inclusion Lists: Validator’lara bazı işlemleri ekleme zorunluluğu getirerek sansürü sınırlamak 🏷SUAVE ve benzeri yapılar: MEV piyasasını ayrı ve daha rekabetçi bir katmana taşımak Ancak burada kritik bir gerçek var: > Sorun teknik değil, ekonomiktir. MEV, sistemin hatası değil; doğal bir sonucu. Bu yüzden tamamen ortadan kaldırılamaz, sadece yönlendirilebilir. Ethereum ekibi problemi görüyor ve çözmeye çalışıyor. > Ethereum’un geleceği, validator sayısından değil; MEV’in nasıl kontrol edildiğinden belirlenecek.

@0xRajeev x.com/i/status/20317…

What are the best tutorials on writing skills for detecting smart contract vulnerabilities? Looking for deep-dives like this one from Claude Code.

My AI Agent works perfectly on my laptop! Awesome. Now, what happens when 100,000 people try to use it at the same time?🧐For Session #6, we are officially leaving the tinkering phase. I'm sitting down with @boredabdel to break down exactly how to deploy AI Agents on (K8s)!🤩👇

Kesin olarak “para aklama operasyonuydu” diyemeyiz. Şu an kamuya açık veriler, bunun çok kötü execution + MEV extraction vakası olduğunu güçlü biçimde gösteriyor; ama “önceden planlanmış laundering” iddiasını tek başına kanıtlamıyor. Böyle bir işlemin gerçekleşeceğini önceden bilmek, diğer MEV botlarına karşı garanti sağlar mı? Hayır, tek başına sağlamaz. Sadece “büyük bir kötü trade geliyor” bilgisini bilmek, parayı kimin kapacağını garanti etmez. Çünkü Ethereum’da bu tür değeri realize etmek için sadece bilgiden fazlası gerekir

geçen bir yazı gördüm bu iş için para aklama operasyonu olabilir diyordu. para kime geçti acaba ? bir de bu tarz bir işlemin gerçekleşeceğini bilmek diğer MEV botlarına karşı garanti sağlar mı ? yani para aklama operasyonuysa hangi MEV botunun işlemi gerçekleştireceğinden emin olmaları gerekir, bu mümkün mü ?

Ekranda %99,9 kayma olacağını gösteren böyle bir işlemi kim onaylar? Evet biri onayladı 🧐

@aave If Aave Shield now blocks >25% price impact by default, doesn’t that implicitly admit the previous warning-only design was insufficient?

50 milyon USD lik bir takas %99 slipaja kurban gidiyor ve Aave ceo suda :"Kullanıcı uyarıyı kabul etti" diyor Bu açıklama aslında ciddi bir sorumluluktan kaçma örneği. “Kullanıcı checkbox ile onayladı” demek, $50 milyonluk bir işlemin %99,9 değer kaybıyla sonuçlanmasını normalleştirmez. Teknik olarak protokol çalışmış olabilir, ancak böyle bir işlemin arayüz tarafından gerçekleşmesine izin verilmesi başlı başına bir tasarım problemi DeFi’nin permissionless olması, kullanıcıyı açıkça finansal bir felakete sürükleyen işlemleri sorgusuz gerçekleştirmek anlamına gelmemelidir. Özellikle bu büyüklükteki bir trade’in price impact’i açıkça simüle edilip kullanıcıya net bir şekilde gösterilmeliydi. “Bazen DeFi’de böyle şeyler olur” demek ise sorumluluğu küçümsemektir; bu ölçekte bir kayıp sıradan bir olay değil ki. Ayrıca $50 milyonluk zararın yanında $600 bin fee iadesi yapmak neredeyse sembolik bir jesttir ve sorunun özünü çözmez. Gerçek mesele protokolün değil, kullanıcıyı korumayan arayüz ve risk yönetimi anlayışının yetersizliğidir. Eğer DeFi gerçekten küresel finansın alternatifi olacaksa, bu tür sistemik tasarım hataları “kullanıcı kabul etti” ile geçilmez

@feyzullah Evet, işlem masrafı olabilir ama doğru mimari kurulursa çok düşük olur. Hatta çoğu durumda kullanıcı hiç ödeme yapmaz

@0xSmartContract Bu işlemler sırasında işlem masrafı olur mu? Kullanıcıya, üreticiye veya herhangi bir kişiye fazladan masrafa çıkar mı?

Yakında internette en önemli soru şu olacak: “Bu video gerçek mi?” Deepfake teknolojisi hızla ilerliyor ama ilginç bir şekilde çözümün anahtarı blockchain olabilir. Akademik çalışmalar yeni yeni başlıyor. Çünkü blockchain sahte videoyu tespit etmeye çalışmaz.Onun yerine şunu yapar: Gerçek videoyu kanıtlar. Bu çok daha güçlü ama nazik bir yaklaşım ➡️ Mantık basit: Bir video çekildiği anda kamera ➡️ Dosyanın kriptografik hash’ini üretir ➡️ Bunu özel anahtarıyla imzalar ➡️ Sonra bu hash değeri blockchain’e yazılır. ➡️Yani zincire video yüklenmez. Sadece şu yazılır: SHA256(video_file) Bu dosyanın dijital parmak izi gibidir. Eğer video üzerinde: • Tek bir piksel • Tek bir frame • Tek bir edit bile yapılırsa hash tamamen değişir. Bu yüzden manipülasyon anında tespit edilir. Sonra doğrulama şu kadar basit olur: hash(video) = blockchain kaydı mı? Evet → Orijinal video ✅ Hayır → Değiştirilmiş💥 Bu yaklaşıma akademik literatürde Content Provenance deniyor. Yani ; “Bu içeriğin kaynağı doğrulanabiliyor mu?” Sistem şöyle çalışabilir: ➡️ Kamera çekim yapar ➡️ Cihaz kriptografik imza atar ➡️ Hash blockchain’e kaydedilir ➡️ Platformlar doğrulama yapar Yani bir videoya bakıp şunu görebileceğiz: • Hangi kamera çekti • Ne zaman çekildi • Sonradan değiştirilip değiştirilmedi Deepfake çağında en değerli şey şu olacak: "Gerçeklik." Ve internet muhtemelen yeni bir kavramla tanışacak: "Proof of Reality" Gerçekliğin kriptografik kanıtı. ✅ Deepfake çağında blockchain kullanarak %100 güvenilir video doğrulama mimarisi nasıl kurulur fikri aslında çok ciddi bir startup fikride aynı zamanda

AI içerik doğrulama ve deepfake ile mücadelede blockchain kullanımı üzerine önemli akademik çalışmalardan biri ; Authentication of Media via Provenance (AMP) Microsoft Research t.co/SDN1NDm62c Bu çalışma dijital medyanın üretildiği andan itibaren kripto imza ve provenance kayıtlarıyla doğrulanmasını öneriryor

Hey AI enthusiasts! Are you ready for the next Ritual Academy broadcast? 💫 On Sunday, March 8th, for Ritual Academy #5, I'm sitting down with @Keleesssss from the University of Maryland to tackle the ultimate dev headache:🤕how to stop AI from confidently writing buggy code!👇🏻