Kohen

Bir millet önce toprağını kaybetmez. Toprağıyla arasındaki bilgiyi kaybeder. Sonra ne ekeceğini, ne üreteceğini ve sonunda ne yiyeceğini başkaları belirler. Tarım yalnızca toprağa tohum atmak değildir. Ne yetiştirmeye değer? Bölgede gerçekten ne üretiliyor? İklim ne söylüyor? Su ve toprak ne durumda? Gelecek koşullar nasıl değişebilir? Piyasa nasıl hareket ediyor? Pazara erişim nasıl? Varsa doğrulanmış üretim maliyeti verileri ne gösteriyor? Bugün tarım yapmak isteyen biri bu soruların cevaplarını çoğu zaman farklı kaynaklarda, farklı biçimlerde ve birbirleriyle karşılaştırılması güç halde buluyor. Tarım Motoru'nu bunun için geliştirmeye başladım. Elinizde bir arazi varsa harita üzerinden seçip o bölgede hangi ürünlerin araştırmaya değer olduğunu ve bu sonucun arkasındaki verileri inceleyebiliyorsunuz. Aklınızda belirli bir ürün varsa bu kez Türkiye haritası üzerinden hangi bölgelerden araştırmaya başlamanın daha anlamlı olduğunu görebiliyorsunuz. Ama sistem size tek bir puan verip “bunu yetiştir” demiyor. İklimi, gerçek üretimi, suyu, toprağı, gelecek iklim koşullarını, piyasa bağlamını ve pazar erişimini mümkün olduğunca ayrı ayrı gösteriyor. Çünkü tarımda doğru karar, tek bir veriden çıkmaz. Bugün Tarım Motoru'nun Versiyon 1 olarak ilk çalışan prototipini yayınlıyorum. Bu henüz başlangıç. Üretim maliyetleri, ekonomik değerlendirme, daha güçlü piyasa verileri, üreticiyle alıcı arasındaki doğrudan bağlantılar ve karar sürecini geliştirecek daha birçok katmanın zamanla eklenmesini hedefliyorum. Ama hedefim yalnızca daha iyi bir yazılım yapmak değil. Üreticinin bilgiye daha kolay ulaşabildiği, alıcının üreticiye daha doğrudan erişebildiği, gereksiz aracı maliyetlerinin azalmasına katkı sağlayabilecek ve tarımsal fiyat oluşumunu daha şeffaf hale getirebilecek bir yapının oluşmasına katkı vermek istiyorum. Çünkü gıda enflasyonuyla mücadele yalnızca marketteki etikete bakarak yapılamaz. Üretimin nasıl planlandığına, bilginin kimde olduğuna, üreticiyle alıcının birbirine nasıl ulaştığına ve ürünün pazara hangi koşullarda çıktığına da bakmak gerekir. Ve bunun tek başına bir yazılımla çözülebileceğine inanmıyorum. Çiftçilerin, kooperatiflerin, alıcıların, lojistikçilerin, araştırmacıların, kamunun, geliştiricilerin ve bu alanda deneyimi olan herkesin katkısıyla Tarım Motoru'nun çok daha güçlü bir sisteme dönüşebileceğine inanıyorum. Bu Versiyon 1. İlk prototip yayında. Tarım Motoru size ne ekeceğinizi söylemek için değil, neye bakmadan karar vermemeniz gerektiğini göstermek için var. tarimmotoru.com.tr/

İngilizce detaylı makale olarak yazdım ama Türkçe özetleyeyim. @binance olayının özü EIP-7702 yetkilendirmesi. Ethereum işlemlerini, Etherscan, Blockscout API ve doğrudan EVM bytecode analiziyle inceledim. 15:59 UTC'de bir delegasyon sözleşmesi oluşturuluyor. 20:20 UTC'de Binance 14 adına EIP-7702 yetkilendirmesi gerçekleşiyor. İşlemdeki 50 yetkilendirme kaydından yalnızca biri kabul ediliyor. Tam 3 dakika 24 saniye sonra, aynı operatör sweep() fonksiyonunu çalıştırarak Binance 14'ten büyük miktarda ETH ve ERC-20 token transferini başlatıyor. Ardından Binance 16 ve 34 kaynaklı büyük fon hareketleri de aynı toplama adresinde birleşiyor. Asıl çarpıcı bulgu sözleşmenin çalışma kodunda. İncelediğim 1.674 byte'lık bytecode içerisinde işlem başlatıcısının adresi beş kez sabitlenmiş. Dört ayrı yürütme yolunda operatör kontrolü bulunuyor ve yetkisiz çağrılar REVERT ile reddediliyor. Ayrıca yaklaşık 975 milyon USDT ve 823 milyon USDC'nin bulunduğu toplama adresinin her iki stablecoin sözleşmesinde de kara listeye alındığını doğruladım. Zincir üstü veriler, fonların hangi yetkilendirme mekanizmasıyla hareket ettirildiğini gösteriyor. Ancak geçerli EIP-7702 imzasının nasıl elde edildiği henüz bilmiyorum, araştıracağım. Özel anahtarın ele geçirilmesi, imzalama altyapısının kötüye kullanılması veya önceden üretilmiş imzaların sızması birbirinden farklı ihtimaller. Hep sizlere yazdığım konular yani. Bu olayın bana göre en önemli kısmı şu: Bir cüzdanın güvenliği yalnızca özel anahtarını korumakla sınırlı değil. Hesabın hangi kodu, kimin yetkisiyle çalıştırabileceğini kontrol etmek de en az onun kadar kritik. Araştırmamda doğruladığım işlem kayıtlarını, sözleşme adreslerini ve teknik kanıtları makalede paylaştım ama önemli olanlar bu aşağıdakiler Delegasyon sözleşmesinin oluşturulması 29 Ekim, 15:59:11 UTC etherscan.io/tx/0x97408e7562… Binance 14 EIP-7702 yetkilendirmesi 20:20:59 UTC | 50 kayıt, 1 başarılı etherscan.io/tx/0xad99264d55… İlk büyük sweep işlemi 20:24:23 UTC etherscan.io/tx/0x53bd38b816… Binance 16, 28.005,6 ETH etherscan.io/tx/0x51f263fa50… 195.460 ETH çıkışı etherscan.io/tx/0x551d796165… Binance 34, 780 milyon USDC etherscan.io/tx/0xdc102dd89d… İkinci sweep işlemi etherscan.io/tx/0x31c4c9fe28… Delegasyon sözleşmesi etherscan.io/address/0x63e84… EIP-7702 teknik standardı eips.ethereum.org/EIPS/eip-7… Terminal çıktıları: Blockscout API ve EVM bytecode analizi. Bu kayıtlar yürütme mekanizmasını doğruluyor; ilk ihlal yöntemini kanıtlamıyor.

. @binance 14 accepted an EIP-7702 delegation. Just 3m 24s later, the same operator initiated sweep(). I verified the transactions and EVM access-control bytecode. How the authorization signature was obtained remains unknown.

Teknik detayları yazacağım DM'DEN SORANLAR! biraz sabır lütfen ama meselenin özü @binance için EIP-7702 5:59:11 UTC - Sözleşme oluşturuldu 0x7C8601...B5CA0, 0x63e842...6fae sözleşmesini oluşturdu. 20:20:59 UTC - EIP-7702 yetkilendirmesi Aynı hesap Binance 14'e Type 4 işlem gönderdi. İçindeki 50 kayıttan biri başarılı delegasyon oluşturdu. 20:24:23 UTC - İlk büyük fon hareketi Aynı başlatıcı Binance 14'e sweep() çağrısı yaptı. ETH ve tokenlar 0x5227...B2f8c adresine aktarıldı. 20:41:23 UTC - Binance 34'ten USDC transferi Aynı başlatıcı Binance 14 üzerinden 780 milyon USDC hareketini tetikledi. Yazacağım Az sabır ve sakin kalın

Eğer bu doğru ise 2.77 milyar dolarlık bir olay Binance için yönetilebilir görünüyor, içinize rahatlatmak için değil, biraz sonra göreceğiniz market etkisinden sizi korumak için yazıyorum, sakin olun. Toplam raporlanan rezervleri yaklaşık 165 milyar dolar civarında. İddia edilen miktarın 50 katından fazla. Major varlıklarda (BTC, USDT, ETH vb.) Proof of Reserves oranları %100’ün üzerinde. Yani kullanıcı bakiyeleri zaten 1:1’in üzerinde karşılanıyor. Asıl “acil durum” tamponu SAFU fonu. Şu an yaklaşık 15.000 BTC tutuyor ve şu an BTC 78 bin dolar olsa yaklaşık 1.2 milyar dolar. Binance, bu fon 800 milyon doların altına düşerse yeniden 1 milyar dolara tamamlamayı taahhüt etmiş durumda. Tarihsel olarak da büyük hack’lerde (örneğin 2019) SAFU’yu kullandılar.⁠ 2.77 milyar dolar SAFU’nun biraz üzerinde olsa bile, Binance’in kendi sermayesi ve diğer rezervleriyle karşılaması mümkün. Son dönemde (27 Ekim) Kuzey Kore bağlantılı saldırıları engellediklerini ve varlık kaybı olmadığını da açıklamışlardı. Yani hem teknik hem finansal kapasite açısından mevcut rakamlar oldukça yönetilebilir ama market buna çok ciddi tepki verecektir ki gerçekliği henüz doğrulanmadı ama velev ki doğrulandı sakin kalın...

Kötü niyetli biri hiç bir zaman olmadım ama geçmişte bir defiye açıklarını mail attım PR bile açmadan yaptım lakin cevap vermediler, burada da yazdım dikkatli olun bazılarını kullanırken diye, arkasından hacklendi (güya) Esas korkmanız gereken böyle kızgın bug hunterlar, sadece bulduklarını (doğru ya da yanlış) açığa dökmesi yeterli önemli zaafiyetleri harekete geçirmek için… daha önce de dedim kütüphaneleri, bağımlılıkları karşılık beklemeden yayınlayan, geliştiren, güncelleyen yazılımcılar var ama diğer bir güruh AI ile güçlendi ve onları kızdırmak sadece büyük şirketlere değil tüm sisteme zarar verecek, bu nedenle tüm gelişmelerden herkesten önce haberdar olmak ZORUNDASINIZ. Milyar dolarlık bir şirketin kullandığı ücretsiz ya da çok küçük yardımlarla işletilen naif bir yazılımcının önemli bir kütüphanesi, sistemin diğer yanında kızgın cyberpunk anarşisiyle yanan bir yazılımcının elinde ciddi bir zaafiyete dönebilir ki dönecektir. Sizlere anlatmaya çalıştığım bu dip dalgadır, ya sisteminde açık bırakmayacak kadar kontrollü olmayı yeni düzene göre sağlayacaksın ya da artık sırtından ciddi paralar kazandığın sistemlerin arkasındaki gizli kahramanları bulup, destekleyeceksin, kulak vereceksin. Esas sarsıntılar buralardan gelecek, alan yetkinliği ile mimari boşlukları bilenlerin daha güçlü olduğu bir kaç kişi yok artık, binler yok artık… E diyeceksiniz ki paraları var, imkanları var önlem alırlar 😊 o iş pek öyle değil. Zaafiyet bulmak 10 birim hızda ise yama üretmek şu an 2 birim hızda…

emudhra’nın 8 ara sertifikasının özel anahtarları o kadar zayıf üretilmiş ki biri tam olarak "4" 😳 En fazla 256 denemede bulunabiliyor. Ağ trafiğinin arasına girebilen biri, bu sertifikaları kabul eden bir araca karşı herhangi bir siteyi taklit edebilirdi. Apple 19 Ekim'den beri bunları otomatik engelliyor. Safari, mail ve normal uygulamalar korunuyor. Terminal araçları (git, curl, python3, openssl) ayrı bir dosya kullanıyor ve o dosya henüz güncellenmedi. Apple'ın kalıcı düzeltmesi için tarih yok. Benim elle yaptığım düzeltme de son güncellemeyle geri geldi. Terminal kullanmıyorsan: hiçbir şey yapma. 
Geliştiriciysen: Apple'ın sayfasında isteğe bağlı geçici bir çözüm var (support.apple.com/en-us/1495…). Ben güncellemeyi beklemedim. Ama güncellemelerden sonra tekrar kontrol etmen gerekiyor ve bazı siteleri doğrulayamayabilirsin.

Ritual Airdrop gerçekten yaptı mı?

Devrim kendi evlatlarını yine yiyor ya hu...

"Fakire ekmek yoksa zengine huzur yok" Artık toplumsal gerilimlerin yalnızca sokaklarda veya sandıklarda olmayacağını zaten anlamışsınızdır, finansal sistemlerin dijital altyapılarında da kendisini gösterecek, bir dip dalga gelecek, bastırılmış bir zümre AI ile yeteneklerini arttırdı ve bu gruplar yayılarak artıyor, her yerde izlerini görmüyordum ama artık bu mecrada bile görünüyorlar...

Ne node, ne de ajan badge fayda etmedi 😊 beni şaşırtmadı ama o kadar uğraşa acıdım, en azından github bağlantısı şarttı, sadece cüzdan ile "Not Eligible" bayadır görmemiştim... olsun bir gün yolumuz kesişir seninle @ritualfnd

One of the things I keep thinking about in blockchain is how we can trust information coming from outside the chain. Most of the information we use every day is on websites, in applications and Api's. But how can we actually prove that a piece of information came from a particular service? A screenshot or someone's word shouldn't be enough. I think we're getting closer to a time when being able to prove this, almost like having a document certified by a notary, will become a real necessity. This is exactly why @primus_labs caught my attention. Primus uses zkTLS to make data coming from HTTPS connections cryptographically verifiable. As a ZK developer, I find this really interesting. There is so much useful information outside blockchains, and I think finding ways to use that information without blindly trusting whoever provides it is an important problem to solve. That's why I didn't want to just read about Primus and move on. I started exploring Primus dev hub, generating and verifying real attestations with the chrome extension, and working on the core SDK integration. I've also submitted two PRs focused on security to the Primus open source ecosystem. At the same time, I'm building something called "Voice Rights Passport". The idea is to take account ownership claims about AI voice models, turn them into verifiable proofs, and connect those proofs to blockchain wallets. I think this is going to become a serious issue in the coming years. Especially when legal disputes start becoming part of the picture. People will need more than just saying "this voice model belongs to me." They'll need something they can actually prove. And I believe the developers who start thinking about these problems and building solutions today will have an advantage in the future. I want to be one of them. That's why I'm spending so much of my time on this. Of course, none of this happens in a day. And I don't think it should. For me, the real experience comes from trying things, making mistakes, understanding why something didn't work, and finding a better way to do it. I think all those experiences together are what eventually make a good developer. The video below is from one of my real Primus attestation experiments. I'll keep sharing what works, what doesn't, where I get stuck and what I learn along the way.

Çok güzel işler çıkarıyor, ilgiliyseniz takibinizde olmalı...

Web3 tarayıcı eklentilerini yüklerken dikkatli olun. Özellikle Wallet Provider üzerinden işlem isteklerine müdahale edebilenlere. Pocket Universe'ün swap işlemlerinden ücret aldığını zaten biliyorsunuz. Genellikle o açıkken küçük tutarlarla işlem yaptığım için önemsemiyordum. Ancak geliştirdiğim bir dApp üzerinde @arc mainnet işlemlerini test ederken, bu ücretin nasıl uygulandığını zincir üzerinde gözlemledim. Aldığı %1,60 ücret mesele değil, esas sıkıntı imzalayacağınız calldata'nın uygulama ile cüzdan arasında değiştirilebilmesi. 0.1 USDC → EURC takasında uygulamanın hazırladığı @Uniswap Universal Router komutları: V3_SWAP_EXACT_IN + SWEEP V3_SWAP_EXACT_IN takası gerçekleştiriyor, SWEEP ise çıktıyı cüzdana aktarıyor. Ancak gerçekleşen işlemin komutları: V3_SWAP_EXACT_IN + PAY_PORTION + SWEEP + SWEEP Araya PAY_PORTION eklenmiş ve EURC çıktısının %1,60'ı farklı bir adrese aktarılmıştı. Kesintinin gittiği adres, Pocket Universe'ün resmî belgelerinde listelenen ücret toplama adresiyle birebir aynı zaten. Pocket Universe'ü kapatarak aynı tutarda ikinci bir işlem yaptığımda kesinti ortadan kalktı ve gerçekleşen calldata, uygulamanın hazırladığı işlemle eşleşti. Buraya kadar her şey olağan ama işin bir de teknik işleyişteki kötü niyetli olan boyutu olursa ne olur? bu da var... Teknik olarak nasıl mümkün? Normal akış: Dapp 👉 Wallet Provider 👉 Wallet 👉 Blockchain Dapp, EIP-1193 üzerinden örneğin şu isteği oluşturur: provider.request({ method: 'eth_sendTransaction', params: [transaction] }) transaction nesnesi to, value ve data gibi alanlar taşır. Ancak Wallet Provider, tarayıcının JavaScript ortamında erişilebilen bir arayüzdür. Yeterli erişime sahip bir tarayıcı eklentisi, sayfaya kod enjekte ederek Provider'ın request() metodunu sarmalayabilir veya işlem isteğinin iletildiği araya başka bir katman yerleştirebilir. Böylece: Dapp doğru calldata'yı hazırlar. Eklenti, eth_sendTransaction isteğindeki data alanını değiştirebilir. Wallet, değiştirilmiş işlemi imzaya sunar. Kullanıcı onaylarsa blockchain bu işlemi çalıştırır. Private key'e erişilmesi gerekmez. Kullanıcının değiştirilmiş işlemi imzalaması yeterlidir. Pocket Universe'ün resmi kullanım koşulları hizmet ücretlerini ve ücret toplama adreslerini açıklıyor. Buradaki örnek bir hizmet ücreti; kötü amaçlı yazılım tespiti değil, yanlış anlaşılmasın. Fakat aynı müdahale yeteneği kötü niyetli bir eklenti tarafından kullanılırsa sonuç çok daha ciddi olabilir. Örneğin swap çıktısı başka bir adrese yönlendirilebilir veya işlem verisine beklenmeyen komutlar eklenebilir. Anlatmaya çalıştığım ise eklenti olarak eklediğiniz her şey güvenli olmayabilir. Eklendikten sonra bunu yapabilecek yetkiyle size zarar verebilir. Burada yalnızca bir eklentinin hangi sitelerde çalışabildiğine bakmak yeterli değil. Teknik incelemede asıl bakılması gereken, eklentinin Wallet Provider ile nasıl etkileşime girdiğidir. Özellikle: ⚒︎ window.ethereum veya EIP-6963 Provider nesnelerine müdahale edip etmediği, ⚒︎ request() ve eth_sendTransaction çağrılarını yakalayıp yakalamadığı, ⚒︎ İşlemdeki to, value, data alanlarını değiştirme kapasitesi, ⚒︎ Eklentinin content_scripts, scripting ve host_permissions kullanımı. Bunlar eklentinin kodu ve davranışı incelenerek araştırılabilir. Yalnızca chrome'un izin ekranına bakarak güvenli olduğu doğrulanamaz. Normal kullanıcılar açısından ise en uygulanabilir önlem, finansal işlemler için günlük tarayıcıdan ayrı bir profil kullanmak ve bu profilde yalnızca gerekli, güvenilir cüzdan eklentisini bulundurmaktır. İmza öncesinde cüzdanın gösterdiği net çıktı, hedef kontrat ve ücretler de kontrol edilmeli. Yine de bu kontroller her türlü calldata manipülasyonunu yakalayamayabilir. Özellikle yüksek tutarlı işlemlerde alışkanlıkla onay vermek ciddi risk oluşturabilir. Tarayıcı ortamındaki Wallet Provider bağlantısını kullanan farklı cüzdanlar kendi güvenlik önlemlerine bağlı olarak benzer risklerle karşılaşabilir. Hiç bir cüzdana sonsuz güven duymayın. Bir dapp'in doğru işlemi hazırlaması, cüzdanın aynı calldata'yı imzaladığını garanti etmez. Yani: Web3 güvenliğinde dapp ile wallet arasındaki bağlantı da ayrı bir güven sınırı olarak ele alınmalıdır ve belki yakında herkes kendi uygulamasını yapıp, kendi rotasındaki yolları güvenle döşeyerek "dışarıda içine ne koydukları belli değil" diyerek güvenle devam etmek zorunda kalacaktır... Ben öyleyim şu an, kendi araçlarımı kullanıyorum ve mecbur kalmadıkça dışarıda yemiyorum efendim...

“İş görüşmesi için verilen bir projeyi çalıştırdım, kripto cüzdanım boşaltıldı!” Web3 dünyasında buna benzer hikayeler duymuşsunuzdur. Peki bir iş görüşmesi, bilgisayarınızdaki cüzdanların ve kişisel verilerin çalınmasına nasıl yol açabilir? Bakın canlı örneği; SlowMist'in ortaya çıkardığı somut bir saldırı örneği. Saldırganlar, Solidity geliştiricileri için hazırlanmış bir iş görüşmesi veya kodlama alıştırması projesi gibi görünen Github deposuna zararlı komutlar gizlemiş. Projenin .vscode/settings.json dosyasına yerleştirilen komutlar, ilgili terminal profili başlatıldığında internetten zararlı kod indirip çalıştırabiliyor. Bu kodun tarayıcı verilerini, kripto cüzdan bilgilerini ve yerel dosyaları toplamaya yönelik yetenekleri tespit edilmiş. Üstelik mesele yalnızca VS Code da değil! Benzer saldırılar kurulum scriptlerine, bağımlılıklara, docker yapılandırmalarına ve otomatik çalışan görevlere de gizlenebilir. AI kodlama ajanları da güvenilmeyen projeleri çalıştırdıklarında aynı risklerle karşılaşabilir. Peki sen ne yapmalısın değil mi? 1. Tanımadığınız GitHub projelerinde .vscode/settings.json, .vscode/tasks.json, .devcontainer/devcontainer.json, package.json, Dockerfile, Makefile, .github/workflows/ dosyalarını inceleyin. 2. terminal.integrated.profiles, preinstall, postinstall, prepare gibi otomatik veya kurulum sırasında çalışan mekanizmaları kontrol edin. 3. curl, wget, eval, node -e, python -c, powershell -EncodedCommand ve base64 -d gibi komutların ne yaptığını sorgulayın. Bunlar tek başlarına zararlı değildir ancak uzaktan indirilen kodu doğrudan çalıştıran zincirlere özellikle dikkat edin. 4. Güvenmediğiniz projeleri kişisel cüzdan, SSH anahtarı veya API anahtarı barındırmayan izole ortamlarda çalıştırın. Peki AI kodlama ajanlarını nasıl koruyacağız? Önce inceleme: Ajan GitHub API üzerinden projeyi salt okunur biçimde analiz etmeli. Kurulum scriptlerini, otomatik görevleri ve bağımlılıkları kontrol etmeden çalıştırma aşamasına geçmemeli. Komut denetimi: Claude Code'da PreToolUse, diğer destekleyen ajanlarda benzer hook mekanizmaları kullanılmalı. npm install, pip install, bash script.sh ve curl | bash gibi işlemler bağımsız güvenlik kontrolünden geçmeli. Prompt injection koruması: AGENTS.md, CLAUDE.md, .cursor/rules ve README dosyalarındaki talimatlar güvenilir sistem komutları olarak kabul edilmemeli. Sandbox: Ajanın çalıştırdığı güvenilmeyen kod, ana sistemden izole edilmeli. Cüzdanlara, SSH anahtarlarına, API anahtarlarına ve gereksiz dış ağ bağlantılarına erişim engellenmeli. Sürekli kontrol: Yeni bağımlılık, değişen kurulum scripti veya yeni commit sonrasında güvenlik incelemesi tekrarlanmalı. Buradaki asıl problem şu: Bir AI ajanına “zararlı kodları çalıştırma” talimatı vermek güvenlik sağlamak için yeterli değil. Ajanın çalıştırmak istediği komutları denetleyen, tehlikeli işlemleri gerçekten engelleyebilen ve erişim yetkilerini sınırlandıran bağımsız bir güvenlik katmanı gerekiyor. Çünkü güvenlik, yalnızca saldırıyı fark etmek değil, fark edemediğimiz saldırıların da zarar vermesini engelleyebilmektir. AI kodlama ajanlarının güvenlik standardı da bu anlayış üzerine kurulmalı. Bu konuda kendi kullandığım Orbstack üzerinde çalıştırdığım safe-npm güvenlik katmanı ve ek güvenlik katmanlarını da uzun bir makale olarak fırsat bulunca yazacağım, güvende kalın efendim...

Özellikle ios optimasyonu için çok uğraşıyorum, telefonda kaliteli oynananma tecrübesi olan Tower Defence eksikliği var bende, kimse oynamasa bile ben oynarım diye yapıyorum ya hu 😊 her silah ve çevre objeleri ile tek tek uğraştım ama bitmedi... Testerlara ihtiyacım var, hem web sürümü hem de ios sürümü için, denemek isteyen olursa yazsın lütfen, görüşleriniz kıymetli... Bitirince süreci tek tek anlatacağım, yayınladıktan sonra.

Sizce robot çağının asıl fırsatı robot/humanoid üretmek mi? yoksa kaslarında mı fırsat? Bir çok kişisel proje geliştiren ve robotik sistemler üreten uçuk kişileri takip ediyor ve çalışmalarından ciddi feyz alıyorum 😊 öyle bir zamanın içindeyiz ki bu yeni çağın evrim şahitleriyiz ve yeni fırsatların tohumlarından ürün elde edecekler olacak, peki biz bunu sadece izleyecek miyiz? Son iki yıldır herkes yapay zekayı, humanoid robotları ve geleceğin kişisel asistanlarını konuşuyor. Ben ise bu dönüşümün biraz daha az konuşulan tarafıyla ilgileniyorum: Bu robotları kim hareket ettirecek? Yıllardır RC otomobillerle uğraşıyorum. Motor, ESC, servo, gyro ve şasi geometrisi üzerinde çalışmak, özellikle drift araçlarında hassas mekanik ayarlar yapmak benim için büyük bir tutku oldu. Bu süreçte öğrendiğim en önemli şeylerden biri şu: Bir sistemi hareket ettirmekle, o hareketi hassas ve güvenilir biçimde kontrol etmek birbirinden çok farklı şeyler. Önümüzdeki yıllarda kişisel küçük robotların ve humanoidlerin giderek yaygınlaşacağını düşünüyorum ki şu an baya bir proje var bununla ilgili. Ancak milyonlarca robotun üretildiği bir dünyada asıl fırsat yalnızca robotun kendisini üretmek olabilir mi? Her robotun hareket etmesi, dengede kalması, nesneleri kavraması ve çevresiyle fiziksel etkileşim kurması gerekecek. Bunun için de kompakt, yüksek torklu, hassas, enerji verimli ve uzun ömürlü hareket sistemlerine ihtiyaç duyulacak. RC dünyasından tanıdığım servolar, bu teknolojik gelişimin anlaşılması için güzel bir başlangıç noktası. Elbette humanoidlerde çok daha karmaşık motor, redüktör, sensör ve kontrol sistemlerinden oluşan aktüatörler kullanılıyor. Bence robotik çağının en stratejik üretim alanlarından biri tam da burası olacak. Robot markaları değişebilir. Tasarımlar farklılaşabilir. Yapay zeka modelleri gelişebilir. Ancak fiziksel hareketin temel mühendislik ihtiyaçları ortadan kalkmayacak. Bu yüzden geleceğin robotik endüstrisine bakarken yalnızca robot üreten şirketleri değil, o robotlara hareket kazandıran teknolojileri geliştiren ve üreten şirketleri de yakından izlemek gerektiğine inanıyorum. Örneğin "Savox" bu benim favori servomdur RC araçlarımda. Aklınızda olsun... Belki de robot çağının en büyük fırsatlarından biri, robotun tamamını üretmekte değil, binlerce farklı robotun ihtiyaç duyacağı ortak hareket teknolojilerini geliştirmekte yatıyor. Zekanın kendisinden çok kaslarında fırsat arıyorum? derseniz, bu size bir fikir sokması yapabilir efendim... En en önemli soru şu olmalı bence: NVDIA kaçan fırsattı, peki robotik endüstrisinin ortak donanım altyapısını kim sağlayacak? ben size ipucunu verdim efendim...