Sahip yoğunlaşması

EN ana kaynak · P07-L04 · tahmini 45 dakika · needs_review

Öğrenme hedefleri:

• Açık paydalarla ham ve düzeltilmiş yoğunlaşmayı hesaplamak.
• İnsan kimliği çıkarsamadan hesapları doğrulanmış bir sahip adresi altında birleştirmek.
• Operasyonel hariç tutmaları ve belirsiz saklama etiketlerine duyarlılığı açıklamak.

“En büyük sahipler 70% paya sahip” ifadesi kesin görünür; ancak kimin veya neyin sayıldığını, hangi paydanın kullanıldığını ve hangi hesapların hariç tutulduğunu açıklamadıkça eksiktir. Bir havuz kasası, bir borsanın saklama hesabı ve tek adresin kontrol ettiği birkaç hesap basit bir grafiği çarpıtabilir. Buradaki beceri, token hesaplarının bağımsız insanlara eşit olduğunu ileri sürmeden şeffaf yoğunlaşma ölçümleri hesaplamaktır.

Hesaplamadan önce ölçümü belirleyin

Bir varlık kimliği ve gözlem kapsamıyla başlayın. Toplam arz paydası, bakiyeler ve hesap rolüne ilişkin kanıtlar aynı ağı/mint'i ve uyumlu bir anlık görüntüyü tanımlamalıdır. Güncel arzı eski bir bakiye tablosuyla birleştirmek, etiketlenmemiş bir uyumsuzluk yaratır. Tam hizalama sağlanamıyorsa yaklaşımı belirtin ve yüzdelik oranı aynı zamana ait kesin bir ölçümmüş gibi sunmayın.

Solana'nın en büyük token hesapları RPC yöntemi, insan sahiplerin tam listesini değil en fazla 20 token hesabını döndürür [S-LARGEST]. Solana'nın hesap modeli, bir hesap sahibi altında aynı mint için birden fazla token hesabına izin verir [S-TOKENS]. Bu olgular iki ayrı birleştirme düzeyini gerektirir: hesap bakiyeleri ve adres düzeyindeki kontrol. Bunların hiçbiri tek başına nihai gerçek sahipliği kanıtlamaz.

En büyük hesap listesini inceleme adaylarını belirlemek için kullanın; eksiksiz bir dağılım uydurmak için kullanmayın. Yalnızca en büyük yirmiyi içeren veri kümesi bazı kısmi yoğunlaşma hesaplarını destekleyebilir, ancak uzun kuyruğun tam histogramını desteklemez. Çözümlenmemiş bir sahip alanı çözümlenmemiş kalmalıdır. Adresleri yalnızca aynı aracıdan fon aldıkları için birleştirmeyin.

Birkaç görünüm hesaplayın, her birini etiketleyin

Ham görünüm, sağlanan tüm bakiyeleri ve sağlanan toplam arzı kullanır. Adrese göre birleştirilmiş görünüm, aynı doğrulanmış kontrol adresine sahip hesapları birleştirir. Düzeltilmiş görünüm, belirtilmiş bir analitik amaç için tanımlanmış operasyonel bakiyeleri hariç tutar. Her görünüm farklı bir soruyu yanıtlar; hiçbiri otomatik olarak diğerlerinin yerini almaz.

1,000,000 birimin 300,000 birimini tutan bir havuz kasasını düşünün. Ham hesap dağılımının 30% oranını oluşturur. Kasanın havuz saklaması olduğu doğrulanmışsa, “tek bir balina kişisel olarak 30% paya sahip” demek desteklenmez. Ancak grafikten çıkarmak varlıklarını önemsiz yapmaz: havuzun LP hakları ve çekim kontrolleri piyasa kapasitesini hâlâ etkiler.

Borsa etiketi başka bir sorun yaratır. Bir saklama adresi birden fazla kullanıcıyı temsil edebilir, ancak bir sağlayıcı etiketi gerçek sahiplerin kesin dağılımını göstermez. Rol yalnızca beyan edilmişse, sessizce hariç tutmak yerine hem ham sonucu hem isteğe bağlı duyarlılık sonucunu gösterin. Hariç tutulan bakiye yöntemsel bir düzeltmedir; ekonomik maruziyetinin ortadan kalktığının kanıtı değildir.

Paydalar görünürdeki sonucu değiştirebilir

Veri kümesinde OWNER-A adresinin kontrol ettiği iki hesap 180,000 ve 120,000 tutar. Birleşik bakiyeleri 300,000 olur. Toplam arza göre bu 30% oranıdır. Doğrulanmış havuzdaki 300,000 birimi hariç tutmak 700,000 payda bırakır; OWNER-A böylece düzeltilmiş havuz dışı bakiyelerin 42.8571% oranını temsil eder. Pay değişmedi; payda değişti.

Beyan edilmiş saklama hesabındaki 100,000 birimi de hariç tutarsanız, düzeltilmiş payda 600,000 olur ve OWNER-A 50% oranını temsil eder. Bu üçüncü görünüm saklama hesabının hariç tutulmasına bağlıdır. “Tüm arzın 50% oranı” diye adlandırılamaz. Açık bir rapor alternatif sayıları yan yana koyar ve neden farklı olduklarını açıklar.

Yoğunlaşma niyet hakkında bir hüküm değildir. Yoğun bir dağılım tahsislerden, operasyonel saklamadan, hak ediş düzenlemelerinden veya bilinçli parçalamadan kaynaklanabilir. Dağınık görünen hesaplar ortak kontrolü gizleyebilir. Doğru yorum, “güvenli” veya “dolandırıcılık” etiketleri yerine ölçülen bakiyeleri ve kalan belirsizliği tanımlar.

Sınıflandırmaları ve duyarlılığı inceleyin

Hesap, tutar, rol, kaynak, güven düzeyi ve hariç tutma nedeni içeren bir hariç tutma kaydı tutun. Havuz saklaması rol kanıtı gerektirir; akılda kalan bir blokzincir gezgini simgesi yeterli değildir. Yakım iddiası da adres takma adı değil, uygun zincir/hesap/program kanıtı gerektirir. Arz ölçümünden zaten çıkarılmış arzı ikinci kez çıkarmayın.

Eğitim amaçlı karşılaştırmada anlık görüntüyü sabit tutun ve her seferinde bir sınıflandırmayı değiştirin. Böylece duyarlılık yeniden üretilebilir. Düzeltilmiş sonuç belirsiz bir borsa sınıflandırmasına çok duyarlıysa, belirsizlik önemlidir ve sonuçta yer almalıdır.

Yoğunlaşma ve likidite etkileşir, ancak farklı kalır. Büyük bir sahibin bakiyesi satıştan ne kadar kotasyon değeri elde edilebileceğini söylemez. Havuz derinliği birden fazla hesabın ortak kontrol altında olup olmadığını belirlemez. Önceki ders fiyat etkisi için model sağlar; bu ders sahiplik muhasebesinin sınırını belirler.

• Hesap yoğunlaşması: token hesabı kimliğine göre birleştirilen bakiyeler.
• Adres birleştirmesi: doğrulanmış kontrol adresine göre birleştirilen bakiyeler.
• Gerçek sahip: yalnızca adresle belirlenemeyen nihai kişi/kuruluş.
• Operasyonel hariç tutma: belirli bir görünümden açıklanmış analitik çıkarma.
• Payda: yüzdelik oran için kullanılan arz/bakiye evreni.
• Duyarlılık analizi: açık alternatif sınıflandırmalar altındaki sonuçlar.

ILLUSTRATIVE ÖRNEK — FIX-P07-04. Eksiksiz kurgusal veri kümesinin toplamı 1,000,000 temel birimdir. Her kimlik sentetik bir etikettir.

OTHER, toplamın uzlaştırılması için bir toplam gruptur; tek bir sahip veya sıralanmış token hesabı değildir. En büyük sahipler sıralamasına tek cüzdan olarak eklenmemelidir.

OBSERVED: Sağlanan A-TA1 ve A-TA2 hesapları bu veri kümesinde OWNER-A adresini paylaşır; toplamları 300,000 olur.

INFERRED: OWNER-A, belirtilen hariç tutmalar altında sağlanan toplam birimlerin 30% oranına ve düzeltilmiş havuz dışı evrenin 42.8571% oranına sahiptir.

UNKNOWN: OWNER-A adresini veya çözümlenmemiş/saklama bakiyelerini kaç insanın kontrol ettiği.

INSUFFICIENT EVIDENCE: Veri kümesi en büyük insan sahibini, dolandırıcılığı, güvenli dağılımı veya gerçekleşebilir satış gelirini belirleyemez. X-TA etiketi, gerçek sahipliğe dayalı koşulsuz hariç tutma için yetersizdir.

Token hesaplarını insan olarak saymak; OTHER grubunu tek cüzdan olarak sıralamak; ortak adres altında birleştirmeyi unutmak; arz anlık görüntülerini karıştırmak; iddia edilen yakımları iki kez çıkarmak; düzeltilmiş yüzdelik oranı tüm arzın yüzdesi olarak sunmak.

OWNER-A adresinin ham ve havuz hariç tutulmuş paylarını hesaplayın. OWNER-A ve OWNER-B adreslerinin birleşik payını toplam arza ve havuz hariç tutulmuş paydaya göre hesaplayın. Ardından ek X-TA hariç tutmasını bir duyarlılık durumu olarak değerlendirin.

• Tam varlığı ve uyumlu anlık görüntüyü doğrulayın.
• Sağlanan tüm tutarları belirtilen evrenle uzlaştırın.
• Doğrulanmış hesap sahiplerini birleştirin; insanları çıkarsamayın.
• Ham, düzeltilmiş ve duyarlılık görünümlerini ayrı tutun.
• Hariç tutma kaydını ve çözümlenmemiş kapsamı yayımlayın.

Yoğunlaşma yüzdesi, birleştirme biriminden, paydasından ve hariç tutmalarından ayrı düşünülemez. Şeffaf hesaplamalar araştırmayı destekler; belirsiz sahip sayıları yersiz güvene yol açar.

Farklı sorular için hesap ve adres görünümlerini kullanın. Saklama etiketiyle belirsizliği asla silmeyin. Payda değişiminin sonucu nasıl etkilediğini gösterin.

Bir milyon birim için uzlaştırma çubuğu, ayrı bir OWNER-A birleştirme parantezi ve ham/havuz dışı/koşullu saklama payda panelleri oluşturun. X-TA ve OTHER için taralı dolgu kullanın; bunları asla bilinen bağımsız insanlar olarak etiketlemeyin. Her yüzdelik oranın altına pay ve paydayı yazın.

Görsel teslim kuralları: koyu lacivert/siyah, camgöbeği/elektrik mavisi/mor vurgular; birimler ve belirsizlik açıkça etiketlenir. Uydurma ekran görüntüleri yerine deterministik grafikler veya SVG kullanın. 390 px genişlikte açıklamaları alt alta yerleştirin ve veri tablosunu metin alternatifi olarak sunun; 768 px ve masaüstünü daha sonra doğrulayın. Arapçada etiketleri ve düzeni yerel RTL ile uyarlayın; adresleri/hash değerlerini LTR olarak ayırırken transferlerin gerçek yönünü ve kronolojiyi koruyun. Marka öğeleri eklenirse yalnızca sağlanan resmi BlockAssay logosunu kullanın. Hiçbir görsel varlığın veya mobil/RTL gösterimin hazır olduğu ileri sürülmez.

RADAR aracını yalnızca tam ağ, varlık ve gerekli alanlar desteklendiğinde ve kökenleri görünür olduğunda kullanın. Bu, salt okunur bir eğitim incelemesidir; alım satım veya token lansmanı değildir. Erişim veya veri yoksa sağlanan çevrimdışı veri kümesini kullanın; eksik bilgi bilinmeyen olarak kalır. Gelecekteki bir BlockAssay’de Aç işlemi doğrulanmış çalışma zamanı yönlendirmesi ve kaynak kapsamı gerektirir. Örnek niteliğindeki tanımlayıcılar için çalıştırılabilir bir varlık CTA’sı sunulmaz. Academy katılımı ve ticari statü Radar gözlemlerini hiçbir zaman değiştirmez.

• Solana getTokenLargestAccounts — En büyük hesap yanıtı, tüm sahiplerle değil 20 token hesabıyla sınırlıdır. Kontrol tarihi: 2026-09-30.
• Solana getTokenAccountsByOwner — Hesap sahibine göre token hesaplarının listelenmesi; sahiplik alanı insan kimliği değildir. Kontrol tarihi: 2026-09-30.
• Solana varlıkları: mint ve token hesapları — Mint kimliği, token hesabı sahipliği ve ayrı mint/oluşturma rolleri. Kontrol tarihi: 2026-09-30.

Tablolar ve alıştırma veri kümeleri, açıkça HISTORICAL olarak belirtilmedikçe özgün eğitim materyalidir. Kurgusal tanımlayıcılar blokzincir adresi olarak bilerek geçersizdir. Belgeler mekanizma tanımlarını destekler; uydurulmuş alıştırma değerlerini desteklemez. Kaynak incelemesi editoryal araştırmadır, canlı zincir ölçümü değildir. Kaynaklar değişebilir; yayımlamadan önce yeniden inceleyin.

P07-L05; alıştırmayı tamamlayıp her quiz açıklamasını gözden geçirdikten sonra devam edin.