Merhaba değerli takipçilerim,

enGrehber projesine Trinsic parolasız üyelik sistemini dahil etmeye çalışırken şunu farkettim: Kişisel verilerimi Trinsic platformuna gönderiyor olmam blockchain üyelik sistemindeki ana fikri zedeliyor.

BlockChain üyelik standardı neden çıktı?

1. Trust Is Broken. En önemli gerekçe bu. Kişisel verileri hackerlardan, yapay zekalardan koruyamıyoruz. Parolalı sistemler hacklenebiliyor, veritabanlarına sızılabiliyor.
2. Çözüm olarak kişisel verileri dağıtık bir şekilde telefonlarda tutalım denilmiş. Fakat telefonlar da güvenli değil. Telefon hacklemek çok kolay. O yüzden datayı telefonlarda şifreleyerek tutmak gerekiyor.
3. Kişisel verileri bulutta ya da kendi veritabanımızda merkezi olarak tutmak güvenli değil. Ancak tutmanız gerekirse yine şifreleyerek tutmanızı öneririm.

Ana fikri anladınız mı?

1. Kişisel veriyi veritabanımda tutmadığım taktirde sistemim hacklense bile sistemimde çalınacak kişisel veri olmayacak.
2. Herkesin kişisel verisi kendi telefonunda şifrelenerek saklanacak.
3. Böylece hackerların 1 milyon kişisel veri elde etmek için 1 milyon telefon hacklemeleri gerekecek, pratikte bu bir insan için çok zor bir görev. Sadece yapay zeka ile yapılabilir ama siz kişisel verileri telefonda şifrelerseniz ellerine sadece şifrelenmiş veri geçecektir.

Trinsic ile ilgili problem ne?

Trinsic kişisel verileri bulutta da depoluyor. Eğer Trinsic hacklenirse tüm kişisel veriler çalınmış oluyor. O yüzden blockchain üyelik sisteminde merkezi olan bulut cüzdanlarını sevmiyor ve istemiyoruz. Decentralized olarak herkes kendi datasını kendi telefonunda saklarsa hackleme işi çok zorlaşıyor ve hacklerın yapay zeka kullanmaktan başka çaresi kalmıyor.

Yapay zeka ile hackleme ise telefondaki datayı şifreleyerek daha da zorlaştırılabilir. Böylece 1 milyon telefon yapay zeka ile hacklense bile ellerine sadece şifrelenmiş veri geçecektir. Üstelik veriler farklı farklı cüzdanlarda depolanabiliyor olacak. Yani hacklenecek cihaz ve uygulama kombinasyonu çok fazla oluyor.

Hackerların işini ne kadar zorlaştırdığımızı anladınız mı?

Mutlu kodlamalar 🙂

Merhaba sevgili takipçilerim,

2022 yılı başlarından bu yana BlockChain üyelik standardı üzerinde çalışıyorum. DID (di-ay-di diye okuyabilirsiniz.) yani Decentralized Identifiers ve Verifiable Credentials standartlarının ilk sürümü W3C tarafından yayınlandı ve ISO sertifikasyon süreçleri başladı.

Artık BlockChain üyelik sistemine geçebiliriz. Peki BlockChain üyelik sistemine neden ihtiyaç var?

1. Trust-Is-Broken: Geleneksel Hackerlara Karşı Daha Dirençli
   Kişisel verileri korumak çok zor, şirket içinden ve dışından veri sızdırmalarını tespit etmek çok maliyetli. Her an her yerde sızdıran kişisel verilerle ilgili haberler duyuyoruz. Sitelere kişisel verilerimizi bırakmak istemiyoruz. Şifre cehenneminden kurtulmak istiyoruz. Kişisel verilere karşı en iyi önlem ise onları veritabanımıza kaydetmemektir. İşte BlockChain üyelik sisteminde kişisel veriler mobil cüzdanınızda yani telefonunuzda ve bulut cüzdanlarda (örneğin e-devlette) depolanır, sizin siteniz çok az bir bilgi ile kişiyi tanır ve işlemlerini yapar. Böylece sizin veritabanınızda kişisel veri olmadığı için hackerlara karşı fazla endişelenmeniz gerekmez.
2. Immutable (Değişmez) Insert-Only Kayıt Sistemi
   BlockChain defterleri değişmez insert-only kayıt sistemleridir, böylece manipülasyon çok zordur. Güvenlik algoritmanız sağlamsa manipülasyon yapılamaz ve veriler değişmez olarak depolanır. BlockChain üyelik sistemlerinde BlockChain üzerine kişisel veri kaydedilmez, üyeliğin tanımı (alanlar) kaydedilir. Kişisel veriler ise cüzdanlara kaydedilir.
3. Web 3.0’a Geçiş
   BlockChain üyelik sistemi, DID, VC tüm bu yeni standartlar aslında Web 3.0 standartlarıdır. Meta’nın Metaverse projelerinde hali hazırda QR kodlu üyelik sistemleri görmekteyiz, işte W3C ve ISO bu QR kodlu Web 3.0 üyelik sistemlerine bir güvenlik ve altyapı standardı getirmişlerdir. Standartlarla uyumlu cüzdanlar e-devlet siteleriyle birlikte kullanılabilir ve aynı standartları kullanan her web sitesi ile uyumlu çalışır.
4. Yapay Zeka Dostu
   BlockChain üyelik sistemi yapay zeka dostudur. Yani kişisel veriler yapay zekalarca daha kolay okunabilir ve kullanılabilir, ayrıca kuantum yapay zekalar blockchain defterlerindeki güvenlik algoritmaları üzerinde kafa yorabilir. Böylece Web 3.0 backendden frontende yapay zeka tarafından daha anlaşılabilir bir altyapı ve standart getirmiş olmaktadır.

Bazı BlockChain Üyelik Sistemi Kavramları

1. ACA-Py (Aries Cloud Agents – Python): Python ile yazılmış Aries Bulut Ajanlarıdır. Eğer kişisel verileri bulutunuzda depolamak istiyorsanız ACA-Py ile başlayın. Ancak Trinsic’in ya da Evernym’in hazır bulut ajanlarını da kullanabilirsiniz.
2. AFJ (Aries Framework JavaScript): NodeJS ve React Native uygulamaları içindir. React Native ile mobil cüzdan hazırlamak isterseniz kullanabilirsiniz.
3. HyperLedger Aries: Kendi DID networkünüzü kurarsanız iletişim için Aries gereklidir.
4. HyperLedger Indy: Kendi DID networkünüzü kurarsanız üyelik tanımlarını kaydetmek için Indy gereklidir.
5. HyperLedger Ursa: Kendi DID ve VC networkünüzü kurarsanız dijital belgeleri kaydetmek için Ursa gereklidir.
6. Indicio ve Sovrin: Kendi DID networkünüzü kurmak yerine hali hazırda profesyonel DID networkü hizmeti veren organizasyonlardır.

Güvenliğin, performansın, desteğin ve sağlamlığın kritik olduğu projelerde hangi teknolojiler tercih edilmelidir?

2019 yılından bu yana geliştirmekte olduğum enGrehber projesi sayesinde hangi teknolojileri kullanmam gerektiği konusunda bolca düşünme fırsatı yakladım. Engrehber projesini başlangıçta bildiğim teknolojilerle hazırladım.

.NET Core, Angular ve Ionic kullandım.

Ancak bazı sorunlarla karşılaştım:

1. Ionic çok yavaş
2. Angular’ın mobil karşılığı yok
3. .NET Core yerli yapay zeka için uygun değil
4. SQL Server big data için uygun değil

Zamanla Engrehber bir Big Data, WebRTC, WebSocket ve BlockChain projesine dönüştü. Araştırmalarım neticesinde tüm bunları karşılayabilen aşağıdaki teknolojileri kullanmam gerektiğine karar verdim.

1. Big Data veritabanları MongoDB, HBase ve Cassandra’dır
2. Yerli Yapay Zeka üretmek istiyorsanız Python veya Java kullanmalısınız
3. React ve React Native ile kod paylaşımlı ve blockchain uyumlu proje geliştirmek daha kolaydır.

O yüzden Engrehber’in 3. sürümü için aşağıdakilerden birini tercih etmek mantıklı oldu

1. Python, React, React Native
2. Java, React, React Native

Python çok avantajları olan bir dildi. Ama çok eski ve çok yavaştı ve Finance, E-Commerce projelerinde çok tercih edilmiyor ama yapay zeka, blockchain DID ve veri bilimi için çok tercih ediliyordu.

Kamu ile projelerinde ise tartışmasız Java tercih ediliyordu ve Engrehber bir kamu projesiydi.

Yaptığım araştırmalarda:

1. Java ile yazılmış yapay zeka: OpenNLP
2. Java ile yazılmış big data veritabanı: Cassandra
3. Java ile kurumsal blockchain: HyperLedger Besu

yazılımları benim Java’yı tercih etmeme neden oldu. Buna karşın Tensorflow ve ACA-Py olmak üzere iki proje Python kullan diye bastırmaya devam ediyordu. Çünkü bunların Java SDK’ları stabillik garanti etmiyor.

Ancak buna karşın Siber Güvenliğin ve sağlamlığın kritik olduğu kamu projelerde mutlaka Java tercih ediliyor, üstelik Java Python’dan daha hızlı.

Engrehber projesi için Tensorflow şu an o kadar önemli olmasa da Aries Cloud Agent Py (ACA-Py) çok önemli, o yüzden Java, Python, TypeScript dillerinin üçünü de kullanmaya karar verdim.

Mutlu kodlamalar 🙂

Giriş

Selfserve.indicio.tech Indicio Test Ağlarını kullanmaya başlamanızın bir bölümünde size yardımcı olmak için tasarlanmış bir web sitesidir. TestNet, ilk aracılarınızı, DID’lerinizi, Şemalarınızı vb. ayarlayarak ilk denemeleriniz içindir ve en yeni yükseltmeleri önce aldığı için ağlar arasında en güncel olanıdır. Uygulamanız hazır olduğunda DemoNet daha kararlıdır ve ilerlemeye hazır olduğunuzda son kullanıcı testleri ve demolar için güvenle kullanılabilir.

Sağlanan forma bir DID ve bir Verkey girebilmek için, forma sağlayacağınız bu öğeler için ortak anahtarların özel karşılıklarını saklayabilecek bir cüzdana sahip bir aracı yüklemeniz gerekecektir. Başka bir deyişle, SelfServe aracının bunları istenen Ağdaki deftere ekleyebilmesi için öğeleri kendi cüzdanınızda oluşturmanız gerekir. DID’yi oluşturmak için başka araçlar da kullanılabilirken, bu talimatlar size Ubuntu, Mac veya Windows’ta kendi cüzdanınıza erişim sağlayan bir komut satırı arabirimi olan indy-cli’yi yüklemek için adım adım bir kılavuz sağlayacaktır.

Bilgisayarınıza indy-cli’yi yükleyin
Bu makalenin kaynağındaki talimatları izleyerek bilgisayarınıza Indy CLI’yi yükleyebilirsiniz. Kaynak bağlantısı için makalenin sonuna bakın.

indy-cli’yi Başlatın
Platformunuz için aşağıdaki talimatları kullanarak indy-cli’nizi başlatın.

indy-cli --config cliconfig

Gerekirse TAA sözleşmelerini kabul etmek için ‘y’ yazın.

Havuzlar Oluşturun
“Havuz oluşturmak” gerçekten sadece mevcut bir ağa (veya havuza) adlandırılmış bir bağlantı eklemektir. Yalnızca ihtiyacınız olanı oluşturmanız gerekir, ancak her biri için talimatlar şunlardır:

pool create testnet gen_txn_file=pool_transactions_testnet_genesis
pool create demonet gen_txn_file=pool_transactions_demonet_genesis

Bir havuz oluşturma, indy-cli’yi kurduğunuz her makinede her havuz için yalnızca bir kez yapılması gerekir. Havuz bağlantısı (aşağıdaki komut), indy-cli’yi her yeniden çalıştırdığınızda yapılmalıdır.

pool connect <pool-name>
pool connect testnet

Cüzdan Oluşturun ve Açın
<wallet key> yalnızca sizin bilmeniz gereken güvenli bir anahtardır. Bu anahtar için tırnak işaretleri gerekli değildir. Daha sonra kullanmak üzere güvenli bir yerde saklayın. CLI’den komut çalıştırmanız gerektiğinde her zaman kullanacaksınız.

wallet create my_wallet key=<wallet key>

“wallet create”, makinenizdeki her cüzdan için yalnızca bir kez çalıştırılmalıdır. Aşağıdaki “wallet open” komutunun, indy-cli’yi her yeniden başlattığınızda ve bu cüzdandaki anahtarları kullanmak istediğinizde çalıştırılması gerekecektir.

wallet open my_wallet key=<wallet key> 

Not: Bu kılavuzda kalan komutlar için cüzdanınızı açık tutun.

DID Oluşturun

did new

Bu komutun dönüşü, self servis web sayfasında ihtiyaç duyulan DID ve Verkey’dir. Cüzdanınızdaki tüm DID’leri görmek için did list kullanın. DID’nizin bağlı olduğunuz ağda (havuzunuz) olduğunu doğrulamak için ledger get-nym did=<your DID> kullanın.
Lütfen “did new” komutuna bir seed=<32 character secret seed> ekleyebileceğinizi unutmayın. Tohum parametresi, gerekirse DID’nizi farklı bir cüzdanda yeniden oluşturmanıza olanak tanır. seed parametresi gerekli değildir ve test ağlarında gerekli olmayabilir, ancak üretim ağında kullanılan demolar veya DID’ler için gereken DID’ler için kullanılmalıdır.

Mutlu kodlamalar 🙂

Kaynak: https://docs.google.com/document/d/18-8MiRRuxVHn-FFWyd8LHukPNl_WNzo-tJtXK9bmZfY/edit

Bitcoin’in kaynak kodları https://github.com/bitcoin/bitcoin adresindedir. Bu repository altında src dizininde chainparams.cpp adında bir dosya vardır.

Öncelikle belirtelim Bitcoin C++ ile yazılmıştır. chainparams.cpp altında Genesis Block’u oluşturan iki adet statik fonksiyon tanımlanmıştır. Bunların kodları aşağıdadır:

static CBlock CreateGenesisBlock(const char* pszTimestamp, const CScript& genesisOutputScript, uint32_t nTime, uint32_t nNonce, uint32_t nBits, int32_t nVersion, const CAmount& genesisReward)
{
    CMutableTransaction txNew;
    txNew.nVersion = 1;
    txNew.vin.resize(1);
    txNew.vout.resize(1);
    txNew.vin[0].scriptSig = CScript() << 486604799 << CScriptNum(4) << std::vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
    txNew.vout[0].nValue = genesisReward;
    txNew.vout[0].scriptPubKey = genesisOutputScript;

    CBlock genesis;
    genesis.nTime    = nTime;
    genesis.nBits    = nBits;
    genesis.nNonce   = nNonce;
    genesis.nVersion = nVersion;
    genesis.vtx.push_back(MakeTransactionRef(std::move(txNew)));
    genesis.hashPrevBlock.SetNull();
    genesis.hashMerkleRoot = BlockMerkleRoot(genesis);
    return genesis;
}

/**
 * Build the genesis block. Note that the output of its generation
 * transaction cannot be spent since it did not originally exist in the
 * database.
 *
 * CBlock(hash=000000000019d6, ver=1, hashPrevBlock=00000000000000, hashMerkleRoot=4a5e1e, nTime=1231006505, nBits=1d00ffff, nNonce=2083236893, vtx=1)
 *   CTransaction(hash=4a5e1e, ver=1, vin.size=1, vout.size=1, nLockTime=0)
 *     CTxIn(COutPoint(000000, -1), coinbase 04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73)
 *     CTxOut(nValue=50.00000000, scriptPubKey=0x5F1DF16B2B704C8A578D0B)
 *   vMerkleTree: 4a5e1e
 */
static CBlock CreateGenesisBlock(uint32_t nTime, uint32_t nNonce, uint32_t nBits, int32_t nVersion, const CAmount& genesisReward)
{
    const char* pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
    const CScript genesisOutputScript = CScript() << ParseHex("04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f") << OP_CHECKSIG;
    return CreateGenesisBlock(pszTimestamp, genesisOutputScript, nTime, nNonce, nBits, nVersion, genesisReward);
}

Daha önceki yıllarda incelediğimde Unique Genesis Block’u oluşturan bir kod vardı, Unique Genesis Block’u oluşturmak için 6 elemanlı bir rastgele sayısı dizisi private hash olarak üretilip kullanılıyordu. Deploy edilmiş Bitcoin hala böyle olması gerekiyor, çünkü Blockchain’in değiştirilmemesi lazım. Ancak şimdi incelediğimde Genesis Block üretiminin değiştirildiğini ve PubKey’in CScript ile üretildiğini görüyorum. Bu kaynak kod geliştiricilere özel sunulmuş olabilir halen production’daki Bitcoin 6 elemanlı rastgele sayı dizisini Genesis block’un private key’i olarak kullanıyor olabilir. Bunu bilmiyoruz. Ancak eğer öyleyse productionda bir güvenlik zayıflığı var demektir.

Şu anki sürümde CScript’te Hexadecimal bir sayı gönderiliyor ve araştırma yaptığımızda bu CScript’ten PubKey’in extract edilmesinin mümkün olduğunu anlaşılıyor. CScript’ten PubKey’i extract etmek için şu adrese bakabilirsiniz. https://www.programcreek.com/cpp/?CodeExample=extract+pub+key

Ayrıca bu adreste coinbase’deki PubKey ortaya çıkartılmış durumda: https://ma.ttias.be/retrieving-the-genesis-block-in-bitcoin-with-bitcoin-cli/ Yani bitcoin merkezinin Coinbase olduğunu anlıyoruz.

Evet yukarıdaki fonksiyonlar haricinde Main fonksiyonu içerisinde aşağıdaki kodları görmek mümkün:

genesis = CreateGenesisBlock(1231006505, 2083236893, 0x1d00ffff, 1, 50 * COIN);
        consensus.hashGenesisBlock = genesis.GetHash();
        assert(consensus.hashGenesisBlock == uint256S("0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f"));
        assert(genesis.hashMerkleRoot == uint256S("0x4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b"));

Bu kodlardaki assert’lerden sanki Genesis Block’un ve Merkle Root’un Bitcoine özel sabit bir hashi olduğunu anlamak mümkün.

Bu durumda 0. block yani Genesis Block’u ile ilgili bilinmeyen bir şey yok gibi duruyor, bu durumda 1. block’a bakmamız lazım. 1. block’ta da muhtemelen cüzdandan alınan private key’i gizli parametre olarak kullanılıyor, bu durumda güvenlik maksimize edilmiş görünüyor.

Sonuç:

Bitcoin’in önceki sürümlerinde bir güvenlik zayıflığı vardı. Çünkü 6 elemanlı rastgele sayısı dizisi Genesis Block’un private key’i olarak kullanılıyordu. Şimdi ise Genesis block açıkça statik ve sabit bir hashe kavuşmuş. Cüzdanların private key’leri ile bir güvenlik sağlanmış. Bu durumda Satoshi Nakamoto’nun gizli bir cüzdanı olduğu sonucuna varabiliriz. Bu durumda Satoshi Nakamoto (minimum) ilk iki block’la ilgili tüm bilgilere sahip özel biri oluyor. Ve bitcoin ekibi, kurucuları ilk blocklardaki tüm detayları biliyorlar. Private key’leri de biliyorlar. Peki bu ona ve onlara ne avantaj sağlar?

Buradan yola çıkarak diğer block’lardaki private key’leri tespit edebilirler mi? Bunun için SHA256 hash algoritmasını decrypt etmeyi çözmeleri lazım. Olası bir teorimi paylaşmak istiyorum.

1. cüzdan private key’ini SHA256 ile şifreleyelim.
2. PreviousHash+Block+SHA256(PrivateKey) tekrar SHA256 ile şifreleyip Public Key hashini üretelim

Diğer kodları incelemediğim için teorik olarak Bitcoin’in güvenli olduğunu, SHA256 hashi kırılmadığı sürece bir sıkıntı olmadığını söyleyebilirim. Ancak aşağıdaki makalede 1500 qubitlik bir kuantum bilgisayar ile SHA256 güvenlik algoritmasının kırılabileceği tahmin edilmiş.

https://www.forbes.com/sites/billybambrough/2019/10/02/could-google-be-about-to-break-bitcoin/

Ve uzun zamandır 2000 qubitten fazla quantum bilgisayarlar çıkmış durumda. SHA256’nın kırılmak üzere olduğunu anlaşıldığı için SHA3 çıkartıldı.

Ve NIST kuantum bilgisayarlara dirençli güvenlik algoritmaları üzerinde bir taraftan çalışıyor: https://csrc.nist.gov/Projects/post-quantum-cryptography

SHA256 kırılmak üzere olduğundan post-kuantum güvenlik algoritmalarına geçmeye öncelik vermeliyiz.

Mutlu kodlamalar 🙂

Yazılım güvenliği için yapmadığımız şey yok; antivirüsler, güvenlik duvarları, internet güvenliği, yedekleme, blockchain derken.. güvenlik için sürekli yeni çözümler geliştiriyoruz.

Ancak gelişmelere bakacak olursak; GitHub’ta ve Devops’ta kodlar varsayılan olarak açıktır. SQL Server’da ve MongoDB’de veriler varsayılan olarak okunabilir kaydedilir.

Böylece kullanıcı adı ve şifremizi ele geçiren hackerler, ya da işletim sistemini ele geçiren hackler verileri ve kodları alabilir ve kullanabilir. Kişisel verileri kolaylıkla satışa çıkarabilir ve kodlarımızdaki güvenlik açıklarını tespit edebilir.

Madem ki güvenlikten bahsediyoruz, neden kodlar ve veriler varsayılan olarak şifreli kaydedilmiyor? SQL sorgularımız ve işletim sistemlerimiz neden Encrypt/Decrypt gömülü olarak çalışmıyorlar?

Sizce verilerin ve kodların kurumumuza özel algoritmalarla şifreli olarak kaydedilmesi, sızıntı durumlarında güvende olmamızı sağlamaz mı?

İsterseniz Şifreleyebiliyorsunuz

Encryption At Rest ve BitLocker gibi özellikler var. Evet. Ama bunlar by default pasif olarak geliyorlar. Ayrıca kullanıcı adı-şifre ele geçirilince sistem hala açık. Sistemin çalışırken de kapalı ve şifreli olarak çalışması gerekmez mi?

Yani SQL Server’da Encrytion At Rest yaptınız diyelim ama Management Studio ile SQL Server’a bağlandığınızda verilerin yine açık olduğunu göreceksiniz. SELECT * FROM TableName dediğinizde veriler açık olarak gelir.

Veya GitHub’ta kodlarınız açık olarak kaydedildiğinden GitHub’ın sahibi Microsoft’la tüm kodlarımızı paylaşmış oluruz. GitHub şifremiz ele geçirilirse bir hacker’ın (ya da yapay zekanın) sessiz sedasız yazılımımızdaki güvenlik açıkları tespit edip etmediğinden emin olamayız.

Halbuki by default herşey şifreli olarak kaydedilseydi ve sadece izin verdiğim kullanıcılar decrypt edebilseydi, ortam daha güvenli olacaktı. Şifreleme algoritmaları pluggable olsaydı ve ben kurumuma özel algoritma kullanabilseydim, kurumumun verileri ve kodları daha güvende olacaktı. Güveniyorum çünkü güvenlik algoritmam sağlam diyebilecektim.

İnternette güven kırıldı, bozuldu. Telefonlar ve bilgisayarlar kolaylıkla hacklenebiliyorlar. Blockchain’in ve kriptoparaların sıcak cüzdanları da bu yüzden güvenli değil. Ama işletim sistemleri, veritabanları, depolama cihazları ve kod depolama sistemleri varsayılan şifreli kaydetse ve sadece izin verdiğim kullanıcılar decrypt edilmiş veriye hatta o verinin de sadece bir kısmına ulaşabilseler daha güvenli bir dijital dünya geliştirebiliriz.

Standart blockchain tanımında da veri açık kaydedilir, açık veri sızıntılara davetiye çıkarır unutmayın. HyperLedger Fabric’te olduğu gibi pluggable güvenlik algoritmalarını kullanarak blockchain üzerindeki veriyi, ayrı olarak kaydettiğimiz big datayı, storageları, geliştirme kodlarını ve smart contractlarımızı kurumumuza özel şifreleme algoritmalarıyla şifrelemediğimiz sürece sızıntılara karşı güvende değiliz.

Mutlu kodlamalar 🙂

2021 yılında Decentralized Identifiers (DID) standardının çıkmasıyla birlikte BlockChain’e geçiş süreci hızlandı. HyperLedger yazılımları ile Web 3.0’a başlayabilirsiniz.

Web 3.0’da backend yazılımınızı Smart Contract’larla DApp hazırlayarak ve BlockChain SDK’larıyla yapıyorsunuz. Big Data için Hadoop ya da MongoDB entegrasyonu yapmanız mümkün.

BlockChain çok yavaş; en hızlısı PoA algoritmalı BlockChain’ler. HyperLedger ürünlerini Kubernetes üzerine yükleyin; SDK’ları kullanan backend yazılımlarını Kubernetes üzerine yükleyin ve Frontend için Angular, React, Flutter ya da React Native kullanın.

Ülkemizde Google’la yakınlaşma var; o yüzden ben backend’te de frontend’te de Google ürünlerini tercih ediyorum; derken NX ile tanıştım. NX sayesinde TypeScript projesinde Backend, Web ve Mobil bileşenlerini ve servislerini paylaşmanız mümkün. Ayrıca BlockChain dünyasında Google çözümleri henüz yok diyebiliriz, Web 3.0 dediğimizde aklımıza Meta firması geliyor.

Web 3.0 için şu teknolojileri öneriyorum:

1. HyperLedger Besu, Indy ve Aries
2. NodeJS
3. Truffle
4. React
5. React Native
6. Kubernetes
7. Pardus

Ama bilmenizi isterim ki BlockChain sanıldığı kadar güvenli değil; cüzdan güvenliğinde hala zayıflıklar var; cüzdandaki verifiable credential’ları korumak mesele. Sıcak cüzdanların güvenli olmadığını biliyorsunuz, çünkü telefon ve bilgisayar işletim sistemleri ve yazılımlarının yüzlerce açıkları var.

Ayrıca kriptoloji güvenlik algoritmaları eskidi. RSA ve SHA-1 çoktan kırıldı. SHA-2 de kırılmak üzere. Kuantum dirençli yeni güvenlik algoritmalarına geçmemiz gerekiyor.

Mutlu kodlamalar 🙂

Merhaba takipçilerim,

Big Data Blockchain projesi geliştirmek istiyorsunuz. Yapay zeka da olsun, WebRTC de olsun, Kubernetes te olsun, tüm güncel teknolojiler olsun istiyorsunuz. Nereden başlayacaksınız ne kullanacaksınız size anlatayım:

1. Üyelik sistemi için Hyperledger Indy, NodeJS ve Rest/gRPC-Web kullanın. HyperLedger Indy üyelik sistemleri için geliştirilmiş bir blockchain çözümüdür ve üyelik verilerinin manipüle edilmesini engeller. Güvenlidir. Daha güvenli olması için Kuantum dirençli yapabilirsiniz (NIST bu yıl post-kuantum güvenlik algoritmalarını çıkarmayı hedefliyor).
2. Logları kaydetmek için .NET 6 minimal api, gRPC/gRPC-Web ve Cassandra kullanın. Cassandra’yı blockchain veritabanı olarak kullanabiliyorsunuz. Insert işlemlerinde hızlı olan bir big data veritabanıdır.
3. Chat mikroservisi için .NET 6 minimal api, gRPC/gRPC-Web ve HBase ya da Cassandra kullanın. HBase okuma işlemlerinde hızlı bir big data veritabanıdır. Cassandra ekleme işlemlerinde hızlı bir big data veritabanıdır. Tercih sizin.
4. Toplantı mikroservisi .NET 6 minimal api, gRPC/gRPC-Web, SignalR, Redis ve HBase ya da Cassandra kullanın. Sunucu tarafında Periscope benzeri bir çözüm geliştirmek isterseniz, ya da Teams benzeri çok katılımcılı toplantı sistemi kurmak isterseniz Oven Media Engine ya da MediaSoup gibi yüksek performanslı WebRTC media sunucularını kullanabilirsiniz.
5. Mikroblogging mikroservisi .NET 6 minimal api, gRPC/gRPC-Web ve HBase kullanın. Twitter HBase kullanmaktadır. Cassandra’yı denemiş fakat stratejik nedenlerden dolayı HBase’i tercih etmiştir.
6. Yapay zeka mikroservisi için .NET 6 minimal api, gRPC/gRPC-Web, WebSocket kullanın. Ayrıca Azure Bot Servis, Bot Framework ve Dialogflow da kullanmanızı öneriyorum.
7. Mobil Frontend’ler Flutter kullanın, Flutter en hızlı çözümü geliştirmenizi sağlar, gRPC ve WebRTC destekler. Oven Media Engine WebRTC sunucusu kullanacaksınız Flutter’da hazır player desteği olmadığı için sorun yaşabilirsiniz, aman dikkat.
8. Web Frontend’ler React ya da Angular kullanın. React tarayıcıda hızlı çalışsa da kurumsal projelerde Angular tercih edilmektedir. Web ikinci planda ve önemsizse Flutter da kullanabilirsiniz.

Tüm servisleri Pardus üzerinde Kubernetes podları olarak çalıştırın. Load Balancer ve API Gateway için Envoy ya da NGINX kullanabilirsiniz. Kubernetes networkünüzü kurmak için minimum 5 adet sunucuya ihtiyacınız olacak. Tüm bu sistemi tek sunucuda çalıştırabilir miyiz henüz ben de bilmiyorum.

CI/CD sistemi kurun. Bunu Jenkins ile yapabilirsiniz. GitHub repolarınıza commit geldiğinde çekip build edip docker image’lerini ve podları güncelleyin.

Kubernetes networkünü güvenli hale getirmek için Istio service mesh kullanın.

.NET 6 backendlerini n-Tiered yapmalısınız. Katmanlarınız şöyle olabilir:
1. Minimal API
2. Service
3. Data (Repository’ler ve Generic-Repository’ler kullanın)
4. Model
5. Infrastructure
6. Test

Angular/React ve Flutter projelerinizde Unit Test ve E2E testleriniz olmalıdır. Testleriniz olmazsa bug karmaşasına düşebilirsiniz, ve projede değişiklik yapmak zamanla çok zorlaşır.

Mutlu kodlamalar 🙂