Story Protocol-Sıkça Sorulan Sorular (SSS)

Aşağıda bulunan yazıda zincir içi (on-chain) ve zincir dışı(off-chain) kavramlarına sıkça değineceğiz. Buna değinmeden önce bu kavramların ne anlama geldiklerine bakalım:

Zincir İçi — Zincir Dışı İşlemler İçin Temel Çıkarımlar:

• Zincir içi işlemler doğrudan blok zinciri üzerinde gerçekleşirken, zincir dışı işlemler ana blok zinciri ağının dışında, ikincil katmanlara veya ağlara bağlı olarak gerçekleşir.
• Zincir içi işlemler, Proof of Work ya da Proof of Stake gibi mutabakat mekanizmaları aracılığıyla blok zincirinde kaydedilir ve doğrulanır, güvenilir transferler sunar ancak ölçeklenebilirlik sorunlarıyla karşı karşıyadır.
• Zincir dışı işlemler ana blok zincirinin dışında gerçekleşir ve daha fazla ölçeklenebilirlik ve verimlilik için Katman-2’lerden yararlanır.
• Zincir içi işlemler güvenlik ve değişmezlik sağlar, ancak işlem süreleri ve maliyetlerinde sınırlamalarla karşılaşır, bu da onları yüksek değerli işlemler için ideal hale getirir.
• Zincir dışı işlemler ölçeklenebilirlik sorunlarını ele alarak mikro işlemler ve anlık ödemeler için uygun hale getirir, ancak karmaşıklıklar ve güvenlik açıkları ortaya çıkarabilir.

Zincir içi ve zincir dışı işlemler hakkında detaylar için bu yazıya göz atabilirsiniz: https://crypto.com/university/tr/on-chain-vs-off-chain-cryptocurrency-transactions-what-is-the-difference

Şimdi gelin Story Protocol için Sıkça Sorulan Sorular (SSS) kısmına geçelim.

SSS (FAQ)

“On-chain IP Gerçek Mi?”

Story, hukuki sisteminin yerini almıyor; yaratıcı fikri mülkiyet (IP) için hukuk sistemini daha verimli hale getirmek amacıyla on-chain raylar sağlıyor.

Programlanabilir Fikri Mülkiyet Lisansı (PIL💊) adı verilen gerçek, off-chain bir yasal sözleşme hazırlamak için dünya standartlarında hukuk ekipleriyle çalıştı. Bu sözleşme, yaratıcıların fikri mülkiyetlerini kimin yeniden düzenleyebileceğini, paraya çevirebileceğini ve türevlerini oluşturabileceğini ve bunun maliyetinin ne olacağını belirlemelerine olanak tanıyan basit şartlara sahip.

Daha sonra bu şartları otomatikleştirmek ve uygulamak için zincir üzerinde (akıllı sözleşmeler biçiminde) iş mantığı oluşturduk. Bu, yasal dünya ile zincir üzerindeki şartlarımız arasında sıkı bir eşleme yaratır.

“Varlığım Zincir Dışı(Off-Chain). Bunu Story Protocol’de IP Olarak Nasıl Kaydederim?”

Zincir dışı (off-chain) varlığınızı temsil eden bir NFT basabilir ve bu NFT’yi Story’de kaydedebilirsiniz.

“Zincir Dışı Bir Varlık Satıyorum (Örneğin Ürün). Otomatik Telif Akışının Uygulandığından Nasıl Emin Olabilirim?”

Otomatik telif akışı zincir dışında uygulanabilir. Telif altyapısı zincir üzerinde olsa da, ilişkili lisans zincirin ötesinde geçerlidir. Lisansa yasal olarak uymak için herhangi bir türev çalışmanın, IP Varlığınıza bağlı IP Hesabına zincir üzerinde telif ödemesi veya lisans tarafından belirlenen şartlara göre gerçek dünyadaki gibi sonuçlarla (örneğin bir lisansı kötüye kullanmaktan dolayı mahkemeye çıkarılmak) karşılaşması gerekecektir.

Ayrıca, Programlanabilir IP Lisansı’nın (PIL💊) şartlarından biri, lisans sahiplerinin, gelir paylaşımı söz konusuysa, lisans verenlere zincir dışı işlemler (örneğin ürün) için gelir verileri sağlamakla yükümlü olmasıdır.

“Buna Yönelik Basit Bir Örnek Nedir?”

Story’den önce, başka birinin Azuki NFT’si ve sizin Pudgy NFT’nizle bir çizgi roman yaratmak isterseniz, önce Azuki’nin bir lisansı olmasını ummanız ve ardından sahibini bulup iletişime geçmeniz gerekir. Ayrıca Pudgy’niz için lisans şartlarınızı araştırmanız gerekir. Hukuk uzmanı olmadığınız için, iki IP arasında yeni bir sözleşme oluşturmak için muhtemelen bir avukata ihtiyacınız olacaktır. Bu, yasal olarak yaratılan herhangi bir şey için bir yük oluşturur, çünkü büyük stüdyolar dışında çok az kişinin bunun için zamanı, uzmanlığı veya parası vardır. Bu nedenle IP kolayca oluşturulamaz.

Story ile Azuki ve Pudgy sahipleri IP’lerini IP Varlıkları olarak kaydedebilir ve ardından insanların IP’lerini nasıl lisanslayabileceklerini ve yeniden karıştırabileceklerini(remiksleyebileceklerini) ana hatlarıyla belirten şartları — PIL’i kullanarak — belirleyebilir. Pudgy’niz Story’de kayıtlıysa, herkes bu şartları zincir üzerinde görebilir ve gerçek bir lisans anlaşması oluşturan lisanslama modülünü kullanarak Pudgy’nizi otomatik olarak lisanslayabilir. Daha sonra ortaya çıkan çizgi romanı bir türev olarak kaydedebilir ve gelen herhangi bir gelir otomatik olarak sizinle IP sahipleri arasında dağıtılabilir.

“Zorluklar Nelerdir?”

Doğal olarak şu soru akla geliyor: “ Ya ben kötü bir oyuncuysam ve bunların hepsini görmezden gelip, sadece ‘Sağ Tık’ ve ardından ‘Farklı Kaydet’e tıklarsam? “

Öncelikle, insanların yasayı takip etmek istemelerinin derecesi hafife alınıyor. Bu yüzden PIL çok önemli — tüm IP sadece zincir üzerinde değil, gerçek bir yasal sözleşmeye bağlı! İnsanlar IP’nizi çalarsa, mahkemede dava edilebilirler. Ancak bu “mutlu yol” her zaman gerçekleşmez. İşler ters gittiğinde, zincir dışı tahkime başvurmadan önce mümkün olduğunca çok sayıda tırmanma katmanı sağlamak istiyoruz.

Bu nedenle, herkesin zincir üzerindeki ihlal eden içeriği işaretlemesine izin veren Dispute Module’ü oluşturduk. Anlaşmazlık başarılı olursa, söz konusu IP işaretlenecek ve artık para kazanamayacak veya lisans üretemeyecek.

Story’deki yaşanan en kötü durum senaryosu, başka herhangi bir yerde yaşanana göre en iyi durum senaryosudur:

Yasal Tahkim (Tahkim, taraflar arasında çıkan uyuşmazlıkların devletin resmi yargı organları yerine, kendileri tarafından belirlenen hakemlerce çözümlendiği bir uyuşmazlık çözüm yöntemidir). Bizi kullanan yaratıcılar her zaman geleneksel hukuk sistemini bir destek olarak kullanabilirler. Bu, kaçınmak istediğimiz bir durumdur, ancak yaratıcıların sisteme güvenmesi için gereklidir.

“Story, Neden Diğer Zincir Ağlarında da Bir Protokol Olmasın?”

Polygon, Ethereum ve daha fazlasındaki projeleri destekleyen bir protokol olarak başladık. Ancak bu, IP’yi yaşadığı zincire böldü ve IP’yi zincirler arasında bağlayamadı. Bu durum, Story’nin küresel bir IP deposu olarak vizyonunu gerçekleştirmez.

IP yerleşim katmanı olmak istiyoruz veya başka bir deyişle, zincirler arasında birleştirilebilirlik sağlamak istiyoruz. Tüm kayıtlı IP’ler için tek bir merkez blok zincirine ihtiyacımız var. Bu IP, Story’de, diğer zincirlerde veya zincir dışında olabilir, ancak tüm lisansların, telif haklarının ve IP meta verilerinin tek bir birleşik yürütme ortamında yaşadığı bir merkeze ihtiyacımız var.

“Tamam, Yani Tekil Bir Blok Zincirine İhtiyacınız Var. Neden Mevcut Bir Blok Zincirini Kullanmıyorsunuz?”

İlk ve en belirgin olanı, kendi 1. Katmanımızı (Layer 1) inşa etmek, tüm teknik yığında yenilik yapmamızı sağlar. Bu, mevcut L1 yol haritalarını beklemeden zincir üstü anlaşmazlık çözümü veya zincir üstü IP grafikleri gibi temel özellikleri uygulamamızı sağlar.

Tüm yığını kendimiz yenilememiz gerektiği, birkaç mevcut zincire inşa etmeye çalıştığımızda ve bu zincirlerin teknik sınırlamaları nedeniyle işe yaramayacağını hemen fark ettiğimizde kanıtlandı. İşte bir L1 inşa etmeye karar vermemizin -ya da daha doğrusu buna zorlanmamızın- birkaç nedeni:

1. Mevcut L1'ler, her biri kendi karmaşık lisanslama ayrıntılarına sahip 1000'lerce ebeveynin IP kaydını tek bir işlemde verimli bir şekilde idare edemiyor. Aşağıda görebileceğiniz gibi, Geth EVM’deki gaz kullanımı ata(ancestor) IP’leriyle hızla artıyor ve blok gaz limitleri nedeniyle 670 atadan(ancestor) sonra pratik olmuyor. Bu nedenle, doğrudan yürütme istemcisinde yazılmış yeni bir durum bilgisi ön derleme yaklaşımından yararlanarak IP grafiğimiz için grafik geçişi ve depolama verimliliğini artırdık. Bu, PoC protokolünün kısıtlamaları altında grafiklerimiz için kullandığımız blok zincirinde belirli değerleri yazmak ve okumak için EVM etrafında bir “kısayol” oluşturur.
2. Benzer şekilde, mevcut L1'ler 1000'lerce IP Varlığı arasındaki telif belirteci akışını idare edemiyor. Yine, bu doğrudan yürütme istemcisinde iyileştirmeler yapılarak çözüldü.
3. Lisans verilerinin zincir üzerinde tutulmasıyla maksimum düzeyde birleştirilebilirlik sağlanır, yüzlerce IP’nin aynı anda yeniden karıştırılmasına olanak tanınır.
4. Milyonlarca işlemin toplama gerektirdiği Web2 uygulamaları için özel X-CHAIN ​​verileriyle (örneğin **Initia’nın** modeli) potansiyel toplama desteğidir. Ayrıca, maksimum teşvik uyumu için kendi doğrulayıcılarını çalıştıran Web2 uygulamalarını da destekler.
5. Story Network’teki IP’lerin tokenleştirilmesine ilişkin gelecekteki yol haritası (daha fazla bilgi yakında).
6. NFT’ler ve zincir dışı RWA IP’leri için yerel oracle’lar (Cosmos SDK oylama uzantıları) gibi geleceğin doğrulayıcı-kutsal L1 teknolojisi.

Son olarak, bir L1 oluşturarak, çeşitli IP’ye özgü L2 çözümlerini destekleyen esnek bir temel sağlıyoruz. Böylece, örneğin, her IP potansiyel olarak kendi L2'sini başlatabilir ve bu da küresel IP’nin geleceği için büyük vizyonumuzu yönlendirir.

“Neden Sadece Bir L2 İle Yetinmiyorsunuz?”

Aslında bir L1 oluşturmaya karar vermeden önce bir L2 oluşturmaya çalıştık. Ancak, yalnızca yürütme katmanını yenilemek (L2'de de mümkün) istemedik, aynı zamanda bir fikir birliği mekanizması eklemek, doğrulayıcı düğüm depolamasında iyileştirmeler yapmak ve yeni doğrulayıcı özellikleri eklemek istedik.

Örneğin, sonunda Netflix, TikTok vb.’nin IP verilerini doğrudan zincir üzerinde yayınlamak için doğrulayıcılar çalıştırmasına izin vermek ve ayrıca bu düğümlerin IP grafikleri için optimize edilmiş grafik veritabanlarına sahip olmasına izin vermek istiyoruz. Anlaşmazlık konusu bir IP Varlığını içeren herhangi bir işlemin derhal reddedildiğini düşünün.

“Story, Neden Doğrulayıcı (Validator) Düzeyinde İyileştirmeler Yapıyor?”

Alternatif, bu özellikleri sağlamak için L1'in dışında bitişik bir sistem çalıştırmaktır, bu kesinlikle L1'in kendisinden daha az merkeziyetsiz olacaktır. Bu özellikleri L1'e özgü hale getirerek (doğrulayıcılar), yeterli merkeziyetsizliğe, garantili yürütmeye ve bakımı yapılacak daha az sisteme sahip olabiliriz.

Yani, bitişik sistem çökerse (bu yüzden dispute’lar ve oracle’lar durur) ancak L1 iyi çalışırsa, bu büyük bir sorun olur. Bu, AVS gibi restake ile çözülebilir ancak teknoloji savaşta test (battle-tested) edilmemiştir ve restake kullanarak başarıya ulaşma önceliği yoktur (EIGEN token’ı hala üzerinde çalışılmaktadır).

Büyük bir teşvik uyum hikayesi şunları içerebilir: IP şirketlerinin doğrulayıcıları çalıştırması ve doğrulayıcı tarafından desteklenen özellikler aracılığıyla yerel olarak ağa özel zincir dışı IP verileri sağlaması.

Veya anlaşmazlıkları otomatikleştiren ve bunları diğer doğrulayıcılara yayınlayan bir hukuk firması. Anlaşmazlıklar konusunda bir anlaşmaya varıldıktan sonra, doğrulayıcılar anlaşmazlıklı IP’leri içeren işlemleri hemen engelleyebilirler, bu da bitişik bir sistemin sağlamasıyla mümkün değildir (Ethereum diyarında tartışılan bir konu olan preconf’umuz olmadığı sürece).

“Bir IP Grafiğinin Verimliliğini Artırmak İçin Bir L1'e İhtiyaç Duyduğunuzdan Bahsediyorsunuz. Neden Zincir Dışı Grafik İndekslemesi Olan Bir L2 Oluşturmuyorsunuz?”

IP grafiği zincir üzerinde olmalıdır çünkü belirli zincir üstü özellikler IP grafiğini geçme ve toplama becerisini gerektirir. Örneğin, telif hakkı ve gelir dağıtımının IP grafiği aracılığıyla zincir üzerinde gerçekleşmesi gerekir. Zincir dışı grafik dizinlemesi kullanmak, bir oracle’ı dahil etmeyi gerektireceğinden bu zincir üstü özellikleri ya uygulanamaz ya da aşırı karmaşık hale getirir.

Benzer şekilde, anlaşmazlık modülü, bir IP’nin, doğrudan zincir üzerinde IP grafiğini geçerek atasının işaretlenmesi nedeniyle işaretlenip işaretlenmediğini kontrol edebilir ve ardından bir oracle’a ihtiyaç duymadan, anlaşmazlık konusu bir IP’yi lisanslayacak bir işlemi iptal etmek gibi anında bir eylemde bulunabilir.

“Story, Kullanıcıların Kendilerine Ait Olmayan Zincir Dışı IP’leri Kaydetmesini Nasıl Önleyecek?”

IP ihlalini engellemek için **Dispute Module** dahil olmak üzere birkaç yolu destekleyeceğiz . Örneğin, birisi başka birinin IP’sini kaydederse, bu zincir üzerinde itiraz konusu olabilir. Ve en kötü durumda, tıpkı bugün geleneksel hukuk sisteminde olduğu gibi mahkemeye götürülebilir.

Buna daha ayrıntılı bir yanıt (sürekli olarak araştırdığımız/geliştirdiğimiz bir yanıt), IP ihlalini caydırmak için ek yollar olabileceğidir. Örneğin, kullanıcıların geçerli bir IP parçasına token yatırabileceği ve itiraz edilirse ve telif hakkı olarak işaretlenirse, tokenların kesilip zarar gören yaratıcıya dağıtılacağı bir stake doğrulama mekanizması. Ayrıca, IP’yi kaydedildiği anda potansiyel ihlal olarak işaretleyebilecek veya otomatik olarak işaretleyebilecek en düşük seviyede doğrudan L1'imize harici IP ihlali tespit hizmetleri sunmayı düşündük.

Sonuç olarak Story, kötü aktörleri engellemek için oluşturulmuş bir sistem değil, dürüst aktörlerin IP’lerini daha kolay kaydetmelerini, başkalarından remiks yapmalarını ve çalışmaları için uygun şartlar belirlemelerini kolaylaştırmak için tasarlanmıştır. Protokol izinsizdir ve kötü aktörleri tamamen durdurmak neredeyse imkansızdır, ancak onları elimizden geldiğince caydırmaya çalışabiliriz. Apple Music, Spotify ve Netflix’in “en az dirençli yol” oluşturarak bu tür medyayı daha erişilebilir hale getirmesiyle medya korsanlığının nasıl düştüğüne benzer şekilde, Story ve IP ile de benzer bir gelecek görüyoruz.

— Bu yazı (Story Foundation üzerinde bulunan metinden) Türkçeye çevrilmiştir.

— — — — —

Okuduğunuz için teşekkürler. Bana ufakta olsa destek sağladığınız için teşekkür ederim. Sağladığınız en ufak destek ile beraber içerik üretmeye yönelik motivasyonum artacaktır. Böylece kendi gelişimime de yardımcı olacağım. Kendinize iyi bakın.

Benimle Twitter üzerinden iletişime geçmek isterseniz: https://twitter.com/TraderOzy

Lens Protocol üzerinden iletişime geçmek isterseniz: https://hey.xyz/u/ozymandias

Discord topluluğumuza katılmak isterseniz: https://discord.gg/vFdauQ45

— — — — — — — —

Projeye Ait;

Twitter: https://x.com/StoryProtocol

Docs: https://docs.story.foundation/

Discord: https://discord.gg/storyprotocol

Orijinal Metin: https://docs.story.foundation/docs/faq