Technik & KryptografieTechnology & CryptographyTecnología & CriptografíaTecnologia & Criptografia技術 & 暗号学技术 & 密码学التقنية & التشفير
Merkle Trees und Bloom Filter: Die Datenbankstruktur hinter BitcoinMerkle Trees and Bloom Filters: The Database Architecture Behind BitcoinÁrboles de Merkle y filtros de Bloom: La arquitectura de base de datos detrás de BitcoinMerkle Trees e Bloom Filters: A Arquitetura de Banco de Dados por Trás do Bitcoinマークルツリーとブルームフィルター：Bitcoinを支えるデータベース構造Merkle 树与布隆过滤器：Bitcoin 背后的数据库架构أشجار ميركل ومرشحات بلوم: بنية قاعدة البيانات وراء Bitcoin
Alle Kernaussagen stützen sich auf das Bitcoin-Whitepaper (Abschnitt 8), die formalen BIPs 0037, 0157 und 0158 sowie die offizielle Bitcoin-Entwicklerdokumentation. Zahlenangaben (80-Byte-Header, 32-Byte-Merkle-Root, O(log₂ n)-Beweistiefe, Dateigrößen) sind in mehreren unabhängigen Quellen konsistent belegt. Authlevel 'verified' ist gerechtfertigt.Todas las afirmaciones principales se basan en el whitepaper de Bitcoin (sección 8), los BIPs formales 0037, 0157 y 0158, así como la documentación oficial para desarrolladores de Bitcoin. Los datos numéricos (cabecera de 80 bytes, Merkle Root de 32 bytes, profundidad de prueba O(log₂ n), tamaños de archivo) están documentados de forma consistente en múltiples fuentes independientes. El nivel de autenticación 'verified' está justificado.Todas as afirmações centrais baseiam-se no whitepaper do Bitcoin (secção 8), nos BIPs formais 0037, 0157 e 0158, bem como na documentação oficial para programadores do Bitcoin. Os valores numéricos (cabeçalho de 80 bytes, Merkle root de 32 bytes, profundidade de prova O(log₂ n), tamanhos de ficheiro) estão consistentemente documentados em várias fontes independentes. O nível de autenticação 'verified' é justificado.すべての主要な記述は、Bitcoin ホワイトペーパー（第 8 節）、正式な BIP 0037・0157・0158、および公式 Bitcoin 開発者ドキュメントに基づいています。数値データ（80 バイトのヘッダー、32 バイトの Merkle Root、O(log₂ n) の証明深度、ファイルサイズ）は複数の独立した情報源で一貫して裏付けられています。認証レベル「verified」は正当と判断されます。所有核心论述均基于 Bitcoin 白皮书（第 8 节）、正式 BIP 0037、BIP 0157 与 BIP 0158，以及官方 Bitcoin 开发者文档。所有数字（80 字节区块头、32 字节 Merkle 根、O(log₂ n) 证明深度、文件大小）均经多个独立来源一致核实。认证级别"verified"具有充分依据。تستند جميع الادعاءات الجوهرية إلى ورقة Bitcoin البيضاء (القسم 8)، ومقترحات BIPs الرسمية 0037 و0157 و0158، فضلاً عن وثائق مطوري Bitcoin الرسمية. الأرقام المذكورة (رأس البيانات بحجم 80 بايت، وجذر Merkle بحجم 32 بايت، وعمق الإثبات O(log₂ n)، وأحجام الملفات) موثقة بصورة متسقة في مصادر مستقلة متعددة. مستوى التحقق 'verified' مبرر.
Der Artikel vermittelt ein technisch solides, aber selektiv optimistisches Bild: SPV gilt seit Jahren als sicherheitskritisches Modell, das in der Praxis durch Angriffsvektoren wie Eclipse-Angriffe kompromittierbar ist – ein Umstand, den die Bitcoin-Entwicklercommunity selbst dokumentiert hat. BIP 0037 ist in Bitcoin Core seit Version 0.21 standardmäßig deaktiviert, was den Bloom-Filter-Abschnitt als veraltete Beschreibung eines de-facto-abgelösten Systems erscheinen lässt. Die präsentierten Dateigrößen für 2026 entbehren einer zitierbaren Primärquelle, und der erhebliche Widerspruch zwischen internem local_judge-Urteil ('weak') und dem hohen Authscore (0.91) ist ein redaktionelles Warnsignal, das vor Veröffentlichung aufgelöst werden muss.The article presents a technically solid but selectively optimistic picture: SPV has long been considered a security-sensitive model vulnerable to attack vectors such as Eclipse attacks – a fact documented by the Bitcoin developer community itself. BIP 0037 has been disabled by default in Bitcoin Core since version 0.21, making the Bloom Filter section read as an outdated description of a de-facto deprecated system. The 2026 file-size figures lack a citable primary source, and the significant contradiction between the internal local_judge rating ('weak') and the high authscore (0.91) is an editorial red flag that must be resolved before publication.El artículo ofrece una imagen técnicamente sólida pero selectivamente optimista: SPV ha sido considerado durante años un modelo sensible a la seguridad, vulnerable a vectores de ataque como los ataques Eclipse, un hecho documentado por la propia comunidad de desarrolladores de Bitcoin. BIP 0037 está desactivado por defecto en Bitcoin Core desde la versión 0.21, lo que hace que la sección sobre filtros Bloom parezca una descripción desactualizada de un sistema de facto obsoleto. Las cifras de tamaño de archivo para 2026 carecen de una fuente primaria citable, y la contradicción significativa entre la valoración interna de local_judge ('weak') y el elevado authscore (0.91) constituye una señal de alerta editorial que debe resolverse antes de la publicación.O artigo apresenta um quadro tecnicamente sólido, mas seletivamente otimista: o SPV é considerado há anos um modelo sensível à segurança, vulnerável a vetores de ataque como os ataques Eclipse — um fato documentado pela própria comunidade de desenvolvedores do Bitcoin. O BIP 0037 está desativado por padrão no Bitcoin Core desde a versão 0.21, o que faz com que a seção sobre filtros Bloom pareça uma descrição desatualizada de um sistema de facto descontinuado. Os valores de tamanho de arquivo para 2026 carecem de uma fonte primária citável, e a contradição significativa entre a avaliação interna do local_judge ('weak') e o alto authscore (0.91) é um sinal de alerta editorial que deve ser resolvido antes da publicação.この記事は技術的には堅実ながらも、選択的に楽観的な描写をしている。SPVはEclipse攻撃などの攻撃ベクトルに対して脆弱なセキュリティ上の重要モデルとして長年認識されており、これはBitcoin開発者コミュニティ自身が記録している事実である。BIP 0037はBitcoin Coreのバージョン0.21以降デフォルトで無効化されており、Bloomフィルターに関するセクションは事実上廃止されたシステムの時代遅れな説明に見える。2026年のファイルサイズの数値には引用可能な一次資料が存在せず、内部のlocal_judge評価（'weak'）と高いauthscore（0.91）の間の顕著な矛盾は、公開前に解消されなければならない編集上の警告サインである。该文章呈现出技术上扎实但选择性乐观的面貌：SPV长期以来被视为安全敏感模型，易受Eclipse攻击等攻击向量的威胁——这一事实已由Bitcoin开发者社区自行记录在案。BIP 0037自Bitcoin Core 0.21版本起已默认禁用，这使得Bloom过滤器相关章节读来像是对一个事实上已被废弃的系统的过时描述。2026年文件大小的数据缺乏可引用的一手来源，而内部local_judge评级（'weak'）与高authscore（0.91）之间的显著矛盾是一个编辑层面的警示信号，必须在发布前予以解决。تقدّم المقالة صورةً متينةً من الناحية التقنية لكنها متفائلة بشكل انتقائي: يُعدّ نموذج SPV منذ سنوات طويلة نموذجاً حساساً أمنياً قابلاً للاختراق عبر ناقلات هجوم كهجمات Eclipse، وهو أمر وثّقه مجتمع مطوري Bitcoin بنفسه. تم تعطيل BIP 0037 افتراضياً في Bitcoin Core منذ الإصدار 0.21، مما يجعل قسم Bloom Filter يبدو وصفاً متقادماً لنظام أُهمل فعلياً. تفتقر أرقام أحجام الملفات لعام 2026 إلى مصدر أولي يمكن الاستشهاد به، كما أن التناقض الجوهري بين تقييم local_judge الداخلي ('weak') والـ authscore المرتفع (0.91) يُمثّل إشارة تحريرية تحذيرية يجب معالجتها قبل النشر.
Video zum ArtikelVideo for this articleVídeo del artículoVídeo do artigo記事の動画本文视频فيديو المقال
Bitcoin speichert keine Daten in einer klassischen Datenbank – es gibt keinen zentralen Server, keine SQL-Tabellen. Stattdessen verankert das Protokoll die Gültigkeit aller Transaktionen in einer kryptografisch verketteten Struktur, die mit minimalstem Aufwand überprüfbar ist. Zwei Konstrukte stehen im Zentrum dieser Architektur: der Merkle Tree als kryptografischer Integritätswächter und der Bloom Filter als datenschutzbewusstes Abfragesystem für ressourcenschwache Clients.
Merkle Trees: Integrität durch rekursives Hashing
Jeder Bitcoin-Block enthält eine Liste von Transaktionen – je nach Block-Größe und Transaktionsgröße können es wenige Dutzend bis mehrere Tausend sein. Um ihre kollektive Integrität auf kleinstem Raum zu repräsentieren, erzeugt Bitcoin einen Merkle Tree (nach Ralph Merkle, 1979).
Das Verfahren ist rekursiv: Zunächst wird jede Transaktion doppelt mit SHA-256 gehasht (SHA-256d). Die resultierenden 32-Byte-Hashes bilden die Blattknoten des Baums. Anschließend werden jeweils zwei benachbarte Hashes paarweise konkateniert und erneut SHA-256d-gehasht, bis ein einziger Hash übrig bleibt: die Merkle Root. Sie ist 32 Bytes groß und wird im 80-Byte-Block-Header gespeichert.
Die Eleganz des Prinzips: Ein einzelnes verändertes Bit in irgendeiner Transaktion verändert deren Blatt-Hash, der Änderungseffekt „perkoliert" deterministisch durch alle übergeordneten Knoten bis zur Root. Die Manipulation ist sofort und mathematisch zweifelsfrei nachweisbar.
Ist die Anzahl der Transaktionen ungerade, wird der letzte Hash einfach mit sich selbst gehasht, um die Paarung vollständig zu machen. Das Ergebnis ist stets ein binärer Baum mit einer eindeutigen Root.
Merkle Proofs: Verifizieren ohne vollständigen Block
Der eigentliche Nutzen des Merkle Trees entfaltet sich bei der Simplified Payment Verification (SPV), die Satoshi Nakamoto bereits in Abschnitt 8 des Bitcoin-Whitepapers beschrieben hat. Ein SPV-Client – etwa eine Wallet-App auf dem Smartphone – muss nicht den gesamten Block herunterladen. Er benötigt nur:
- Die Kette der Block-Header (je 80 Bytes – Stand 2026 ca. 70 MB für alle ~880.000 Blöcke, gegenüber >600 GB für die vollständige Blockchain)
- Einen Merkle Proof (auch Merkle Branch): den Pfad von der zu verifizierenden Transaktion bis zur Root
Ein solcher Beweis hat die Tiefe O(log₂ n): Bei einem Block mit 2.048 Transaktionen genügen 11 Hashes statt 2.048. Der Client hasht die Zieltransaktion, kombiniert sie schrittweise mit den gelieferten Geschwister-Hashes und prüft, ob das Ergebnis mit der im Header verankerten Merkle Root übereinstimmt. SPV ist kein unsicherer Behelf, sondern ein von Satoshi vorgedachtes Sicherheitsmodell mit klar dokumentierten Trade-offs: Der SPV-Client vertraut der längsten Proof-of-Work-Kette, nicht einem einzelnen Server.
Bloom Filter: Datenschutzbewusstes Suchen auf fremden Nodes
Weiß ein SPV-Client, dass eine Transaktion existiert, muss er sie auch finden. Hier tritt der Bloom Filter in Aktion – eingeführt durch BIP 0037 (Mike Hearn & Matt Corallo, 2012, aktiv seit Bitcoin Core 0.8).
Ein Bloom Filter ist eine bitbasierte Datenstruktur mit k Hash-Funktionen. Wird ein Element eingefügt, setzen alle k Funktionen jeweils ein Bit in einem Bit-Array. Bei einer Abfrage gilt: Sind alle k zugehörigen Bits gesetzt, ist das Element möglicherweise enthalten; ist mindestens eines nicht gesetzt, ist es definitiv nicht enthalten. False Negatives sind ausgeschlossen; False Positives sind kalkuliert möglich – und gewollt.
Der SPV-Client konfiguriert seinen Filter (Parameter: Filtergröße in Bytes nFilterBytes, Anzahl Hash-Funktionen nHashFuncs, Nonce nTweak) und sendet ihn an einen Full Node. Dieser liefert alle Transaktionen, die den Filter treffen – also die echten Treffer plus zufälliges Rauschen aus False Positives. Der Client wertet lokal aus, welche Daten wirklich relevant sind. Das Rauschen ist kein Fehler, sondern Datenschutz durch Unschärfe: Der Node weiß nicht mit Sicherheit, welche Adressen den Client interessieren. Bloom Filter operieren dabei auf Script-Patterns und TXIDs, nicht auf Adressen im sozialen Sinne.
Vom Push zum Pull: BIP 0157/0158 und Compact Block Filters
BIP 0037 hat in der Praxis Schwächen gezeigt: unzureichender Datenschutz bei kleinen Filtern und DoS-Angriffsvektoren gegen Full Nodes. Der Paradigmenwechsel kam mit BIP 0157/0158 (Compact Block Filters, „Neutrino"), ab Bitcoin Core v0.21.0 verfügbar (Stand 2026 weiterentwickelt).
Die Logik kehrt sich um: Nicht mehr der Client schickt seinen Filter zum Node, sondern der Full Node berechnet für jeden Block einen kompakten Filter und stellt ihn bereit. Der Client lädt diesen Filter herunter und wertet ihn lokal aus. Nur wenn ein Treffer vorliegt, fragt er nach dem vollständigen Block. Das eliminiert die serverseitigen DoS-Risiken und verbessert den Datenschutz erheblich.
Merkle Trees und Bloom Filter lösen komplementäre Probleme: Der Merkle Tree beantwortet „Ist diese Transaktion in diesem Block und wurde sie nicht manipuliert?" – der Bloom Filter beantwortet „Welche Blöcke könnten für mich relevant sein, ohne dass ich meine Adressen preisgeben muss?"
Fazit: Kleine Strukturen, große Wirkung
Beide Konstrukte ermöglichen das, was Bitcoin von einem monolithischen, zentralisierten System unterscheidet: trustless Verifikation bei minimaler Datenmenge. Die ~70 MB der Header-Kette (Stand 2026) statt der >600 GB der vollständigen Blockchain – das ist kein Kompromiss, sondern ein durchdachtes Sicherheitsmodell, das Satoshi bereits 2008 skizziert hat und das durch BIPs bis heute präzisiert wird.
Weiterführend
Bitcoin does not store data in a conventional database – there is no central server, no SQL tables. Instead, the protocol anchors the validity of all transactions in a cryptographically chained structure that can be verified with minimal effort. Two constructs are at the heart of this architecture: the Merkle Tree as a cryptographic integrity guardian, and the Bloom Filter as a privacy-aware query system for resource-constrained clients.
Merkle Trees: Integrity Through Recursive Hashing
Every Bitcoin block contains a list of transactions – depending on block size and transaction size, this can range from a few dozen to several thousand. To represent their collective integrity in the smallest possible space, Bitcoin constructs a Merkle Tree (after Ralph Merkle, 1979).
The process is recursive: each transaction is first hashed twice with SHA-256 (SHA-256d). The resulting 32-byte hashes form the leaf nodes of the tree. Adjacent hashes are then concatenated in pairs and SHA-256d-hashed again, repeating until a single hash remains: the Merkle Root. It is 32 bytes in size and is stored in the 80-byte block header.
The elegance of the principle: a single flipped bit in any transaction changes its leaf hash, and that change deterministically "percolates" through all parent nodes up to the root. Any manipulation is immediately and mathematically provable.
If the number of transactions is odd, the last hash is simply hashed with itself to complete the pairing. The result is always a binary tree with a unique root.
Merkle Proofs: Verifying Without the Full Block
The real power of the Merkle Tree emerges in Simplified Payment Verification (SPV), described by Satoshi Nakamoto in Section 8 of the Bitcoin whitepaper. An SPV client – such as a smartphone wallet – does not need to download the entire block. It only requires:
- The chain of block headers (80 bytes each – as of 2026, approximately 70 MB for all ~880,000 blocks, compared to >600 GB for the full blockchain)
- A Merkle Proof (also called a Merkle Branch): the path from the transaction to be verified up to the root
Such a proof has depth O(log₂ n): for a block with 2,048 transactions, just 11 hashes suffice instead of 2,048. The client hashes the target transaction, combines it step by step with the provided sibling hashes, and checks whether the result matches the Merkle Root anchored in the header. SPV is not an insecure shortcut – it is a security model envisioned by Satoshi with clearly documented trade-offs: the SPV client trusts the longest proof-of-work chain, not a single server.
Bloom Filters: Privacy-Aware Querying on Remote Nodes
Once an SPV client knows a transaction exists, it must also find it. This is where the Bloom Filter comes in – introduced by BIP 0037 (Mike Hearn & Matt Corallo, 2012, active since Bitcoin Core 0.8).
A Bloom Filter is a bit-array data structure with k hash functions. When an element is inserted, all k functions each set a bit in the array. When querying: if all k corresponding bits are set, the element is possibly present; if at least one is not set, it is definitely not present. False negatives are impossible; false positives are deliberately possible – and intentional.
The SPV client configures its filter (parameters: filter size in bytes nFilterBytes, number of hash functions nHashFuncs, nonce nTweak) and sends it to a full node. The node returns all transactions that match the filter – the genuine hits plus random noise from false positives. The client evaluates locally which data is truly relevant. The noise is not a bug but privacy through ambiguity: the node cannot know with certainty which addresses the client is interested in. Bloom Filters operate on script patterns and TXIDs, not on addresses in a social sense.
From Push to Pull: BIP 0157/0158 and Compact Block Filters
BIP 0037 showed practical weaknesses: insufficient privacy with small filters and DoS attack vectors against full nodes. The paradigm shift came with BIP 0157/0158 (Compact Block Filters, "Neutrino"), available from Bitcoin Core v0.21.0 onwards (further developed as of 2026).
The logic is reversed: instead of the client sending its filter to the node, the full node computes a compact filter for each block and makes it available. The client downloads this filter and evaluates it locally. Only if a match is found does it request the full block. This eliminates server-side DoS risks and significantly improves privacy.
Merkle Trees and Bloom Filters solve complementary problems: the Merkle Tree answers "Is this transaction in this block and has it not been tampered with?" – the Bloom Filter answers "Which blocks might be relevant to me, without revealing my addresses?"
Conclusion: Small Structures, Large Impact
Both constructs enable what distinguishes Bitcoin from a monolithic, centralized system: trustless verification with minimal data. The ~70 MB of the header chain (as of 2026) versus >600 GB for the full blockchain – this is not a compromise but a well-considered security model that Satoshi sketched in 2008 and that BIPs continue to refine to this day.
Related
Bitcoin no almacena datos en una base de datos convencional: no existe un servidor central ni tablas SQL. En cambio, el protocolo ancla la validez de todas las transacciones en una estructura criptográficamente encadenada que puede verificarse con un esfuerzo mínimo. Dos construcciones son el núcleo de esta arquitectura: el Merkle Tree como guardián criptográfico de la integridad y el Bloom Filter como sistema de consulta orientado a la privacidad para clientes con recursos limitados.
Merkle Trees: Integridad mediante hashing recursivo
Cada bloque de Bitcoin contiene una lista de transacciones; según el tamaño del bloque y de las transacciones, puede haber desde unas pocas decenas hasta varios miles. Para representar su integridad colectiva en el menor espacio posible, Bitcoin construye un Merkle Tree (en honor a Ralph Merkle, 1979).
El proceso es recursivo: primero, cada transacción se hashea dos veces con SHA-256 (SHA-256d). Los hashes resultantes de 32 bytes forman los nodos hoja del árbol. A continuación, los hashes adyacentes se concatenan en pares y se vuelven a hashear con SHA-256d, repitiéndose el proceso hasta que queda un único hash: la Merkle Root. Ocupa 32 bytes y se almacena en el encabezado de bloque de 80 bytes.
La elegancia del principio: un solo bit modificado en cualquier transacción altera su hash hoja, y ese cambio «percola» de forma determinista por todos los nodos padre hasta la raíz. Cualquier manipulación es detectable de manera inmediata y matemáticamente irrefutable.
Si el número de transacciones es impar, el último hash simplemente se hashea consigo mismo para completar el emparejamiento. El resultado es siempre un árbol binario con una raíz única.
Merkle Proofs: verificación sin descargar el bloque completo
El verdadero poder del Merkle Tree se manifiesta en la Simplified Payment Verification (SPV), descrita por Satoshi Nakamoto en la sección 8 del whitepaper de Bitcoin. Un cliente SPV —como una wallet en el smartphone— no necesita descargar el bloque completo. Solo requiere:
- La cadena de encabezados de bloque (80 bytes cada uno; a partir de 2026, aproximadamente 70 MB para todos los ~880.000 bloques, frente a >600 GB de la blockchain completa)
- Una Merkle Proof (también llamada Merkle Branch): la ruta desde la transacción a verificar hasta la raíz
Dicha prueba tiene profundidad O(log₂ n): para un bloque con 2.048 transacciones bastan 11 hashes en lugar de 2.048. El cliente hashea la transacción objetivo, la combina paso a paso con los hashes hermanos proporcionados y comprueba si el resultado coincide con la Merkle Root anclada en el encabezado. SPV no es un atajo inseguro, sino un modelo de seguridad concebido por Satoshi con compromisos claramente documentados: el cliente SPV confía en la cadena de prueba de trabajo más larga, no en un servidor individual.
Bloom Filters: consultas orientadas a la privacidad en nodos remotos
Una vez que un cliente SPV sabe que una transacción existe, también debe encontrarla. Aquí entra en juego el Bloom Filter, introducido por BIP 0037 (Mike Hearn & Matt Corallo, 2012, activo desde Bitcoin Core 0.8).
Un Bloom Filter es una estructura de datos basada en un array de bits con k funciones hash. Al insertar un elemento, cada una de las k funciones activa un bit en el array. En una consulta: si todos los k bits correspondientes están activos, el elemento posiblemente está presente; si al menos uno no lo está, el elemento definitivamente no está presente. Los falsos negativos son imposibles; los falsos positivos son deliberadamente posibles —e intencionales.
El cliente SPV configura su filtro (parámetros: tamaño del filtro en bytes nFilterBytes, número de funciones hash nHashFuncs, nonce nTweak) y lo envía a un nodo completo. Este devuelve todas las transacciones que coinciden con el filtro: los resultados genuinos más el ruido aleatorio de los falsos positivos. El cliente evalúa localmente qué datos son realmente relevantes. El ruido no es un error, sino privacidad mediante ambigüedad: el nodo no puede saber con certeza qué direcciones interesan al cliente. Los Bloom Filters operan sobre patrones de script y TXIDs, no sobre direcciones en un sentido social.
Del push al pull: BIP 0157/0158 y los Compact Block Filters
BIP 0037 mostró debilidades en la práctica: privacidad insuficiente con filtros pequeños y vectores de ataque DoS contra los nodos completos. El cambio de paradigma llegó con BIP 0157/0158 (Compact Block Filters, «Neutrino»), disponible a partir de Bitcoin Core v0.21.0 (seguido en desarrollo a partir de 2026).
La lógica se invierte: en lugar de que el cliente envíe su filtro al nodo, es el nodo completo quien calcula un filtro compacto para cada bloque y lo pone a disposición. El cliente descarga este filtro y lo evalúa localmente. Solo si se detecta una coincidencia solicita el bloque completo. Esto elimina los riesgos de DoS en el lado del servidor y mejora considerablemente la privacidad.
Los Merkle Trees y los Bloom Filters resuelven problemas complementarios: el Merkle Tree responde a «¿Está esta transacción en este bloque y no ha sido manipulada?»; el Bloom Filter responde a «¿Qué bloques podrían ser relevantes para mí, sin revelar mis direcciones?»
Conclusión: estructuras pequeñas, gran impacto
Ambas construcciones hacen posible lo que distingue a Bitcoin de un sistema monolítico y centralizado: verificación sin confianza con una cantidad mínima de datos. Los ~70 MB de la cadena de encabezados (a partir de 2026) frente a los >600 GB de la blockchain completa no son un compromiso, sino un modelo de seguridad bien pensado que Satoshi esbozó en 2008 y que los BIPs continúan perfeccionando hasta hoy.
Más información
O Bitcoin não armazena dados numa base de dados convencional – não existe servidor central nem tabelas SQL. Em vez disso, o protocolo ancora a validade de todas as transações numa estrutura encadeada criptograficamente, verificável com esforço mínimo. Dois mecanismos estão no centro dessa arquitetura: a Merkle Tree como guardiã criptográfica da integridade e o Bloom Filter como sistema de consulta orientado à privacidade para clientes com recursos limitados.
Merkle Trees: Integridade por Hashing Recursivo
Cada bloco do Bitcoin contém uma lista de transações – dependendo do tamanho do bloco e das transações, pode ir de algumas dezenas a vários milhares. Para representar a integridade coletiva no menor espaço possível, o Bitcoin constrói uma Merkle Tree (em homenagem a Ralph Merkle, 1979).
O processo é recursivo: cada transação é primeiro submetida a um hash duplo com SHA-256 (SHA-256d). Os hashes de 32 bytes resultantes formam os nós folha da árvore. Em seguida, hashes adjacentes são concatenados aos pares e submetidos novamente ao SHA-256d, repetindo o processo até restar um único hash: a Merkle Root. Ela tem 32 bytes e é armazenada no cabeçalho de bloco de 80 bytes.
A elegância do princípio: um único bit alterado em qualquer transação muda o seu hash folha, e esse efeito "percola" deterministicamente por todos os nós ancestrais até à raiz. Qualquer manipulação é imediata e matematicamente comprovável.
Se o número de transações for ímpar, o último hash é simplesmente combinado consigo mesmo para completar o emparelhamento. O resultado é sempre uma árvore binária com uma raiz única.
Merkle Proofs: Verificar sem o Bloco Completo
O verdadeiro poder da Merkle Tree manifesta-se na Simplified Payment Verification (SPV), descrita por Satoshi Nakamoto na secção 8 do whitepaper do Bitcoin. Um cliente SPV – como uma carteira num smartphone – não precisa de descarregar o bloco inteiro. Necessita apenas de:
- A cadeia de cabeçalhos de bloco (80 bytes cada – em 2026, aproximadamente 70 MB para todos os ~880.000 blocos, contra >600 GB para a blockchain completa)
- Uma Merkle Proof (também chamada Merkle Branch): o caminho desde a transação a verificar até à raiz
Uma tal prova tem profundidade O(log₂ n): para um bloco com 2.048 transações, bastam 11 hashes em vez de 2.048. O cliente faz o hash da transação alvo, combina-o passo a passo com os hashes irmãos fornecidos e verifica se o resultado coincide com a Merkle Root ancorada no cabeçalho. A SPV não é um atalho inseguro – é um modelo de segurança concebido por Satoshi com trade-offs claramente documentados: o cliente SPV confia na cadeia de prova de trabalho mais longa, não num servidor único.
Bloom Filters: Consulta com Privacidade em Nodes Externos
Quando um cliente SPV sabe que uma transação existe, precisa também de a encontrar. É aqui que entra o Bloom Filter – introduzido pelo BIP 0037 (Mike Hearn & Matt Corallo, 2012, ativo desde o Bitcoin Core 0.8).
Um Bloom Filter é uma estrutura de dados baseada em bits com k funções de hash. Ao inserir um elemento, todas as k funções definem um bit num array de bits. Na consulta: se todos os k bits correspondentes estiverem definidos, o elemento está possivelmente presente; se pelo menos um não estiver definido, o elemento definitivamente não está presente. Falsos negativos são impossíveis; falsos positivos são deliberadamente possíveis – e intencionais.
O cliente SPV configura o seu filtro (parâmetros: tamanho do filtro em bytes nFilterBytes, número de funções de hash nHashFuncs, nonce nTweak) e envia-o a um full node. Este devolve todas as transações que correspondem ao filtro – os resultados genuínos mais ruído aleatório dos falsos positivos. O cliente avalia localmente quais os dados realmente relevantes. O ruído não é um erro, mas sim privacidade através da ambiguidade: o node não pode saber com certeza quais os endereços que interessam ao cliente. Os Bloom Filters operam sobre padrões de script e TXIDs, não sobre endereços no sentido social.
De Push para Pull: BIP 0157/0158 e Compact Block Filters
O BIP 0037 revelou fraquezas na prática: privacidade insuficiente com filtros pequenos e vetores de ataque DoS contra full nodes. A mudança de paradigma chegou com o BIP 0157/0158 (Compact Block Filters, "Neutrino"), disponível a partir do Bitcoin Core v0.21.0 (continuado em desenvolvimento em 2026).
A lógica inverte-se: em vez de o cliente enviar o seu filtro ao node, o full node calcula um filtro compacto para cada bloco e disponibiliza-o. O cliente descarrega esse filtro e avalia-o localmente. Só quando há uma correspondência é que solicita o bloco completo. Isto elimina os riscos de DoS do lado do servidor e melhora significativamente a privacidade.
As Merkle Trees e os Bloom Filters resolvem problemas complementares: a Merkle Tree responde a "Esta transação está neste bloco e não foi adulterada?" – o Bloom Filter responde a "Quais blocos podem ser relevantes para mim, sem revelar os meus endereços?"
Conclusão: Estruturas Pequenas, Grande Impacto
Ambos os mecanismos tornam possível aquilo que distingue o Bitcoin de um sistema monolítico e centralizado: verificação sem confiança com dados mínimos. Os ~70 MB da cadeia de cabeçalhos (em 2026) contra >600 GB da blockchain completa – não é um compromisso, mas um modelo de segurança criteriosamente concebido que Satoshi esboçou em 2008 e que os BIPs continuam a aperfeiçoar até hoje.
Mais informação
Bitcoinは従来のデータベースにデータを保存しない――中央サーバーもなく、SQLテーブルも存在しない。その代わりに、プロトコルはすべてのトランザクションの有効性を、最小限の労力で検証できる暗号学的に連鎖した構造に刻み込む。このアーキテクチャの中心にある2つの構成要素が、暗号的な完全性の番人としてのMerkle Treeと、リソースが限られたクライアント向けのプライバシーを考慮したクエリシステムとしてのBloom Filterだ。
Merkle Tree：再帰的ハッシュによる完全性保証
すべてのBitcoinブロックにはトランザクションのリストが含まれており、ブロックサイズやトランザクションサイズによって数十件から数千件に及ぶ。それらの集合的な完全性を最小限のスペースで表現するため、BitcoinはMerkle Tree（Ralph Merkle、1979年にちなむ）を構築する。
この処理は再帰的に行われる。まず各トランザクションがSHA-256で二重ハッシュ化される（SHA-256d）。得られた32バイトのハッシュがツリーの葉ノードを形成する。次に隣接するハッシュを2つずつペアで連結してSHA-256dハッシュを再適用する処理を、単一のハッシュが残るまで繰り返す。これがMerkle Rootだ。Merkle Rootは32バイトのサイズを持ち、80バイトのブロックヘッダーに格納される。
この原理の優雅さはここにある。あるトランザクションの1ビットでも変更されれば、その葉ノードのハッシュが変わり、その変化は決定論的にすべての親ノードを経てルートまで「浸透」する。いかなる改ざんも即座かつ数学的に疑いなく検出できる。
トランザクション数が奇数の場合、最後のハッシュは自身とハッシュ化されてペアを完成させる。結果は常に一意のルートを持つ二分木となる。
Merkle Proof：ブロック全体なしでの検証
Merkle Treeの真の威力が発揮されるのが、Satoshi NakamotoがBitcoinホワイトペーパーのセクション8で既に説明したSimplified Payment Verification（SPV）だ。SPVクライアント――スマートフォンのウォレットアプリなど――はブロック全体をダウンロードする必要がない。必要なのは以下の2点だけだ。
- ブロックヘッダーのチェーン（各80バイト――2026年時点で約~880,000ブロック全体で約70 MB、完全なブロックチェーンの>600 GBと比較して）
- Merkle Proof（Merkle Branchとも呼ばれる）：検証対象のトランザクションからルートまでのパス
このような証明の深さはO(log₂ n)となる。2,048件のトランザクションを含むブロックであれば、2,048個の代わりに11個のハッシュがあれば十分だ。クライアントは対象トランザクションをハッシュ化し、提供された兄弟ハッシュと順次組み合わせ、その結果がヘッダーに刻まれたMerkle Rootと一致するかを確認する。SPVは安全性の劣る便法ではなく、Satoshiが設計した明確にトレードオフが文書化されたセキュリティモデルだ。SPVクライアントが信頼するのは単一のサーバーではなく、最長のProof-of-Workチェーンである。
Bloom Filter：外部ノード上でのプライバシーを考慮した検索
SPVクライアントがトランザクションの存在を知った後は、それを見つけなければならない。ここでBloom Filterが登場する――BIP 0037（Mike Hearn & Matt Corallo、2012年、Bitcoin Core 0.8以降で有効）によって導入された。
Bloom Filterはk個のハッシュ関数を持つビット配列ベースのデータ構造だ。要素が挿入されると、k個の関数がそれぞれビット配列の1ビットをセットする。クエリ時には、k個の対応するビットがすべてセットされていれば要素はおそらく含まれており、1つでもセットされていなければ確実に含まれていない。偽陰性は発生しない。偽陽性は意図的に許容される――そして、それは設計上の意図だ。
SPVクライアントはフィルターを設定し（パラメーター：フィルターサイズ（バイト単位）nFilterBytes、ハッシュ関数の数nHashFuncs、ノンスnTweak）、フルノードに送信する。フルノードはフィルターに一致するすべてのトランザクション――真の一致結果と偽陽性によるランダムノイズ――を返す。クライアントはどのデータが本当に関連しているかをローカルで判断する。このノイズはバグではなく、曖昧さによるプライバシー保護だ。ノードはクライアントがどのアドレスに関心を持っているか確実には知ることができない。Bloom FilterはスクリプトパターンとTXIDに対して動作し、社会的な意味でのアドレスに対してではない。
プッシュからプルへ：BIP 0157/0158とCompact Block Filter
BIP 0037は実用上の弱点を露呈した。小さなフィルターでは不十分なプライバシー保護と、フルノードへのDoS攻撃ベクターがその問題だ。パラダイムシフトをもたらしたのがBIP 0157/0158（Compact Block Filters、「Neutrino」）で、Bitcoin Core v0.21.0以降で利用可能となった（2026年時点でも継続開発中）。
ロジックが逆転する。クライアントがフィルターをノードに送るのではなく、フルノードが各ブロックのコンパクトフィルターを計算して提供する。クライアントはそのフィルターをダウンロードし、ローカルで評価する。一致が見つかった場合にのみ、完全なブロックをリクエストする。これによりサーバー側のDoSリスクが排除され、プライバシーも大幅に向上する。
Merkle TreeとBloom Filterは補完的な問題を解決する。Merkle Treeは「このトランザクションはこのブロックに含まれており、改ざんされていないか？」に答え、Bloom Filterは「自分のアドレスを明かすことなく、どのブロックが自分に関連しているか？」に答える。
まとめ：小さな構造、大きな効果
この2つの構成要素が実現するのは、Bitcoinをモノリシックな中央集権型システムと区別するもの――最小限のデータによるトラストレス検証だ。完全なブロックチェーンの>600 GBではなく、ヘッダーチェーンの約70 MB（2026年時点）――これは妥協ではなく、Satoshiが2008年に設計し、BIPsによって今日まで精緻化され続けている、綿密に考え抜かれたセキュリティモデルだ。
関連情報
Bitcoin 并不将数据存储于传统数据库中——没有中央服务器，也没有 SQL 表。取而代之，该协议将所有交易的有效性锚定在一种以密码学方式链接的结构中，可以以极低的代价进行验证。这一架构的核心由两种构造组成：作为密码学完整性守护者的 Merkle Tree，以及作为资源受限客户端隐私感知查询系统的 Bloom Filter。
Merkle Trees：通过递归哈希保障完整性
每个 Bitcoin 区块都包含一份交易列表——根据区块大小和交易大小的不同，数量从数十笔到数千笔不等。为了在最小的空间内表示这些交易的集体完整性，Bitcoin 构建了一棵 Merkle Tree（以 Ralph Merkle 命名，1979年）。
该过程是递归的：首先对每笔交易进行两次 SHA-256 哈希运算（SHA-256d），所得的 32 字节哈希值构成树的叶节点。随后，相邻的哈希值两两拼接并再次进行 SHA-256d 哈希，如此重复，直到仅剩一个哈希值：即 Merkle Root。它的大小为 32 字节，存储于 80 字节的区块头中。
这一原理的精妙之处在于：任意一笔交易中哪怕一个比特被改动，都会改变其叶节点哈希，该变化会确定性地"渗透"至所有父节点直达根节点。任何篡改都能立即以数学方式无可置疑地被证明。
若交易数量为奇数，最后一个哈希值会与自身拼接以完成配对。最终结果始终是一棵具有唯一根节点的二叉树。
Merkle Proofs：无需完整区块即可验证
Merkle Tree 的真正价值体现在 简单支付验证（SPV） 中——Satoshi Nakamoto 在 Bitcoin 白皮书第 8 节中已对此进行了描述。SPV 客户端（例如智能手机上的钱包应用）无需下载完整区块，只需：
- 区块头链（每个 80 字节——截至 2026 年，约 880,000 个区块共约 70 MB，而完整区块链则超过 >600 GB）
- 一个 Merkle Proof（也称 Merkle Branch）：从待验证交易到根节点的路径
此类证明的深度为 O(log₂ n)：对于包含 2,048 笔交易的区块，仅需 11 个哈希值而非 2,048 个。客户端对目标交易进行哈希，逐步将其与提供的兄弟节点哈希值合并，并检验结果是否与区块头中锚定的 Merkle Root 一致。SPV 并非不安全的权宜之计，而是 Satoshi 预先设计、具有明确权衡取舍的安全模型：SPV 客户端信任最长的工作量证明链，而非某一台服务器。
Bloom Filter：在远程节点上进行隐私感知查询
当 SPV 客户端得知某笔交易存在后，还需要找到它。这正是 Bloom Filter 发挥作用之处——由 BIP 0037（Mike Hearn & Matt Corallo，2012 年，自 Bitcoin Core 0.8 起生效）引入。
Bloom Filter 是一种基于位数组的数据结构，使用 k 个哈希函数。插入一个元素时，所有 k 个函数各自在位数组中设置一个比特位。查询时：若所有 k 个对应比特位均已置位，则该元素可能存在；若至少有一个未置位，则该元素绝对不存在。假阴性不可能发生；假阳性是经过设计、可被预期的——且是有意为之。
SPV 客户端配置其过滤器（参数：过滤器字节大小 nFilterBytes、哈希函数数量 nHashFuncs、随机数 nTweak），并将其发送给全节点。全节点返回所有匹配该过滤器的交易——即真实命中项加上由假阳性带来的随机噪声。客户端在本地判断哪些数据真正相关。噪声并非缺陷，而是通过模糊性实现隐私保护：节点无法确切知晓客户端关注哪些地址。Bloom Filter 作用于脚本模式和 TXID，而非社会意义上的地址。
从推送到拉取：BIP 0157/0158 与 Compact Block Filters
BIP 0037 在实践中暴露出若干弱点：小型过滤器下隐私保护不足，以及针对全节点的 DoS 攻击向量。范式转变随 BIP 0157/0158（Compact Block Filters，"Neutrino"）而来，自 Bitcoin Core v0.21.0 起可用（截至 2026 年仍在持续完善）。
逻辑由此逆转：不再由客户端将过滤器发送给节点，而是由全节点为每个区块计算一个紧凑过滤器并对外提供。客户端下载该过滤器并在本地进行评估。只有在找到匹配项时，才向节点请求完整区块。这消除了服务器端的 DoS 风险，并显著提升了隐私保护水平。
Merkle Tree 与 Bloom Filter 解决的是互补的问题：Merkle Tree 回答"这笔交易是否在此区块中，且未遭篡改？"——Bloom Filter 回答"哪些区块可能与我相关，而无需暴露我的地址？"
结语：小结构，大影响
这两种构造共同实现了 Bitcoin 区别于中心化单体系统的根本特质：以最少的数据实现无需信任的验证。截至 2026 年，区块头链仅约 70 MB，而完整区块链则超过 >600 GB——这并非妥协，而是 Satoshi 早在 2008 年便已勾勒、并由各 BIP 持续精化至今的深思熟虑的安全模型。
延伸阅读
لا يخزّن Bitcoin البيانات في قاعدة بيانات تقليدية — فلا يوجد خادم مركزي ولا جداول SQL. بدلاً من ذلك، يُرسّخ البروتوكول صحة جميع المعاملات في بنية مترابطة تشفيرياً يمكن التحقق منها بأدنى جهد ممكن. يقوم على قلب هذه البنية بناءان أساسيان: Merkle Tree بوصفه حارسَ النزاهة التشفيرية، وBloom Filter بوصفه نظامَ استعلام يراعي الخصوصية للعملاء ذوي الموارد المحدودة.
Merkle Trees: النزاهة عبر التجزئة التكرارية
يحتوي كل كتلة Bitcoin على قائمة من المعاملات — قد تتراوح بين بضعة عشرات وعدة آلاف بحسب حجم الكتلة وحجم المعاملات. ولتمثيل نزاهتها الإجمالية في أصغر مساحة ممكنة، ينشئ Bitcoin شجرةَ Merkle Tree (نسبةً إلى Ralph Merkle، 1979).
العملية تكرارية: تُجزَّأ كل معاملة أولاً مرتين باستخدام SHA-256 (SHA-256d)، وتُشكّل قيم التجزئة البالغة 32 بايت العقدَ الورقية للشجرة. ثم تُتسلسَل قيم التجزئة المتجاورة زوجاً زوجاً وتُجزَّأ مجدداً بـ SHA-256d، وتتكرر العملية حتى تبقى قيمة تجزئة واحدة: هي Merkle Root، حجمها 32 بايت، وتُخزَّن في رأس الكتلة البالغ 80 بايت.
جمال هذا المبدأ يكمن في أن تغيير بتٍّ واحد في أي معاملة يُغيّر قيمة تجزئتها الورقية، وينتشر هذا التغيير بصورة حتمية عبر جميع العقد الأصلية حتى الجذر. وبذلك يمكن الكشف عن أي تلاعب فوراً وإثباته رياضياً بلا شك.
إذا كان عدد المعاملات فردياً، تُجزَّأ آخر قيمة تجزئة مع نفسها لإكمال التزاوج. والنتيجة دائماً شجرة ثنائية ذات جذر وحيد.
Merkle Proofs: التحقق دون الحاجة إلى الكتلة كاملة
تتجلى القوة الحقيقية لـ Merkle Tree في Simplified Payment Verification (SPV)، التي وصفها Satoshi Nakamoto في القسم الثامن من الورقة البيضاء لـ Bitcoin. لا يحتاج عميل SPV — كتطبيق المحفظة على الهاتف الذكي — إلى تحميل الكتلة بأكملها، بل يكتفي بـ:
- سلسلة رؤوس الكتل (80 بايت لكل رأس — وفق بيانات 2026 نحو 70 ميغابايت لجميع ~880,000 كتلة، مقارنةً بـ >600 غيغابايت للبلوكشين الكاملة)
- Merkle Proof (ويُسمى أيضاً Merkle Branch): المسار من المعاملة المراد التحقق منها وصولاً إلى الجذر
عمق هذا الإثبات هو O(log₂ n): فبالنسبة لكتلة تحتوي على 2,048 معاملة، تكفي 11 قيمة تجزئة بدلاً من 2,048. يُجزّئ العميل المعاملةَ المستهدفة ويجمعها تدريجياً مع قيم تجزئة الأشقاء المقدَّمة، ثم يتحقق مما إذا كانت النتيجة تطابق Merkle Root المُثبَّتة في رأس الكتلة. ليس SPV حلاً هشاً مؤقتاً، بل هو نموذج أمني تصوّره Satoshi مع مقايضات موثقة بوضوح: يثق عميل SPV بأطول سلسلة إثبات عمل، لا بخادم بعينه.
Bloom Filters: الاستعلام بخصوصية على العقد البعيدة
حين يعلم عميل SPV بوجود معاملة ما، عليه أيضاً إيجادها. هنا يبرز دور Bloom Filter — الذي جاء به BIP 0037 (Mike Hearn & Matt Corallo، 2012، فعّال منذ Bitcoin Core 0.8).
Bloom Filter هو بنية بيانات قائمة على مصفوفة بتات مع k دالة تجزئة. عند إدراج عنصر، تضع كل دالة من الدوال الـ k بتاً في المصفوفة. وعند الاستعلام: إن كانت جميع البتات الـ k المقابلة مضبوطةً، فالعنصر محتمل الوجود؛ وإن لم يكن بتٌّ واحد مضبوطاً على الأقل، فهو غائب قطعاً. النتائج السلبية الزائفة مستحيلة؛ أما النتائج الإيجابية الزائفة فهي ممكنة ومحسوبة — بل مقصودة.
يضبط عميل SPV مرشّحه (المعاملات: حجم المرشّح بالبايت nFilterBytes، عدد دوال التجزئة nHashFuncs، القيمة العشوائية nTweak) ويرسله إلى عقدة كاملة. تعيد هذه العقدة جميع المعاملات التي يطابقها المرشّح — أي النتائج الحقيقية مضافاً إليها ضوضاء عشوائية من النتائج الإيجابية الزائفة. يُقيّم العميل محلياً أيَّ البيانات ذات صلة فعلاً. هذه الضوضاء ليست خطأً، بل هي خصوصية من خلال الغموض: لا تستطيع العقدة أن تعرف على وجه اليقين أي العناوين يهتم بها العميل. يعمل Bloom Filter على أنماط السكريبت وTXIDs، لا على العناوين بمعناها الاجتماعي.
من الدفع إلى السحب: BIP 0157/0158 ومرشحات الكتل المضغوطة
كشف BIP 0037 عن نقاط ضعف عملية: خصوصية غير كافية مع المرشحات الصغيرة، وثغرات هجمات DoS ضد العقد الكاملة. جاء التحول الجذري مع BIP 0157/0158 (Compact Block Filters، "Neutrino")، المتاح اعتباراً من Bitcoin Core v0.21.0 (لا يزال قيد التطوير وفق بيانات 2026).
تنعكس المنطق تماماً: بدلاً من أن يرسل العميل مرشّحه إلى العقدة، تحسب العقدة الكاملة مرشحاً مضغوطاً لكل كتلة وتجعله متاحاً. يُحمِّل العميل هذا المرشّح ويُقيّمه محلياً. ولا يطلب الكتلة كاملةً إلا إذا وُجد تطابق. هذا يُلغي مخاطر DoS من جانب الخادم ويُحسّن الخصوصية تحسيناً ملحوظاً.
يحل Merkle Tree وBloom Filter مشكلتين متكاملتين: يجيب Merkle Tree على سؤال "هل هذه المعاملة موجودة في هذه الكتلة وهل لم تُعبث بها؟" — ويجيب Bloom Filter على سؤال "أي الكتل قد تكون ذات صلة بي، دون أن أكشف عن عناويني؟"
خاتمة: بنى صغيرة، أثر كبير
يُتيح البناءان معاً ما يُميّز Bitcoin عن الأنظمة المتجانسة المركزية: التحقق دون ثقة بأدنى قدر من البيانات. نحو 70 ميغابايت لسلسلة الرؤوس (وفق بيانات 2026) في مقابل >600 غيغابايت للبلوكشين الكاملة — هذا ليس تنازلاً، بل نموذج أمني مدروس رسم ملامحه Satoshi عام 2008، وتواصل BIPs تدقيقه وتطويره حتى اليوم.
مزيد من المعلومات
⚖️ Die stärksten GegenargumenteThe Strongest CounterargumentsLos contraargumentos más fuertesOs contra-argumentos mais fortes最も強力な反論最有力的反方观点أقوى الحجج المضادة
Jedes Gegenargument in seiner stärksten Form – geprüft und nach Datenlage entschieden, kein Wunschdenken.Each counterargument in its strongest form – scrutinized and adjudicated per the data, no wishful thinking.Cada contraargumento en su forma más fuerte: examinado y juzgado según los datos, sin ilusiones.Cada contra-argumento na sua forma mais forte – examinado e julgado segundo os dados, sem ilusões.各反論を最も強い形で提示し、データに基づいて検証・判定しています。希望的観測はありません。每个反方观点均以其最强形式呈现——依据数据审视并判定，绝不一厢情愿。كل حجة مضادة في أقوى صورها — مفحوصة ومحسومة وفق البيانات، لا وفق التمني.
„SPV ist kein unsicherer Behelf" steht gegen den Entwickler-Konsens: SPV-Clients validieren keine Konsensregeln (Inflation, ungültige Skripte), vertrauen der Miner-Mehrheit und sind gegenüber Eclipse-Angriffen exponiert – ein deutlich schwächeres Sicherheitsmodell, als der Artikel suggeriert.The framing that SPV is no insecure stopgap clashes with developer consensus: SPV clients validate no consensus rules (inflation, invalid scripts), trust the miner majority, and are exposed to eclipse attacks — a markedly weaker security model than the article suggests.El encuadre de que SPV no es un recurso inseguro choca con el consenso de los desarrolladores: los clientes SPV no validan reglas de consenso (inflación, scripts inválidos), confían en la mayoría de los mineros y están expuestos a ataques eclipse; un modelo de seguridad notablemente más débil de lo que sugiere el artículo.O enquadramento de que SPV não é um recurso inseguro colide com o consenso dos desenvolvedores: clientes SPV não validam regras de consenso (inflação, scripts inválidos), confiam na maioria dos mineradores e estão expostos a ataques eclipse — um modelo de segurança bem mais fraco do que o artigo sugere.「SPVは危うい間に合わせではない」という位置づけは開発者の共通認識と衝突する。SPVクライアントはコンセンサスルール(インフレーション、無効なスクリプト)を検証せず、マイナーの多数派を信頼し、Eclipse攻撃にさらされている——記事が示唆するよりも明確に弱いセキュリティモデルである。「SPV不是不安全的权宜之计」的定位与开发者共识相悖:SPV客户端不验证共识规则(通胀、无效脚本),信任矿工多数,并暴露于Eclipse攻击之下——其安全模型明显弱于文章所暗示的程度。الطرح القائل إن SPV ليس حلا مؤقتا غير آمن يصطدم بإجماع المطورين: فعملاء SPV لا يتحققون من قواعد الإجماع (التضخم، النصوص غير الصالحة)، ويثقون بأغلبية المعدنين، وهم معرضون لهجمات الكسوف — وهو نموذج أمان أضعف بوضوح مما يوحي به المقال.
Belegt: Die Grenzen des SPV-Modells sind in Entwickler-Dokumentation und Forschung ausführlich beschrieben – genau deshalb rät die Community für nennenswerte Beträge zu Full Nodes. Schon Abschnitt 8 des Whitepapers benennt die Verwundbarkeit gegenüber einem übermächtigen Angreifer selbst.Substantiated: the limits of the SPV model are described at length in developer documentation and research — which is exactly why the community recommends full nodes for meaningful amounts. Section 8 of the whitepaper itself names the vulnerability to an overpowering attacker.Confirmado: los límites del modelo SPV están descritos con detalle en la documentación de desarrolladores y en la investigación; exactamente por eso la comunidad recomienda full nodes para importes relevantes. La propia sección 8 del whitepaper menciona la vulnerabilidad frente a un atacante con poder mayoritario.Confirmado: os limites do modelo SPV estão descritos em detalhe na documentação de desenvolvedores e na pesquisa — exatamente por isso a comunidade recomenda full nodes para quantias relevantes. A própria seção 8 do whitepaper cita a vulnerabilidade diante de um atacante com poder majoritário.立証済み:SPVモデルの限界は開発者向けドキュメントと研究で詳細に記述されており、まさにそれゆえコミュニティは相応の金額にはフルノードを推奨している。ホワイトペーパー第8節自体が、圧倒的な攻撃者に対する脆弱性を明記している。成立:SPV模型的局限在开发者文档和研究中有详尽描述——正因如此,社区建议对较大金额使用全节点。白皮书第8节本身就点明了面对算力占优攻击者时的脆弱性。مثبت: حدود نموذج SPV موصوفة باستفاضة في وثائق المطورين والأبحاث — ولهذا بالضبط توصي المجتمعات التقنية بالعقد الكاملة للمبالغ المعتبرة. بل إن القسم 8 من الورقة البيضاء نفسه يسمي الثغرة أمام مهاجم متفوق القوة.
„Datenschutz durch Unschärfe" beschönigt BIP 37: Forschung zeigte bereits 2014, dass Bloom Filter die Adressen der Clients weitgehend offenlegen, und Bitcoin Core liefert BIP-37-Filter seit Version 0.19 standardmäßig nicht mehr aus – das Kapitel beschreibt ein de facto abgelöstes System als Privacy-Design.Privacy through noise whitewashes BIP 37: research showed as early as 2014 that bloom filters largely expose clients' addresses, and Bitcoin Core has stopped serving BIP 37 filters by default since version 0.19 — the chapter describes a de facto retired system as privacy design.La privacidad mediante ruido embellece el BIP 37: la investigación mostró ya en 2014 que los filtros Bloom exponen en gran medida las direcciones de los clientes, y Bitcoin Core dejó de servir filtros BIP 37 por defecto desde la versión 0.19; el capítulo describe como diseño de privacidad un sistema de facto retirado.A privacidade por ruído embeleza o BIP 37: a pesquisa mostrou já em 2014 que filtros Bloom expõem em grande medida os endereços dos clientes, e o Bitcoin Core deixou de servir filtros BIP 37 por padrão desde a versão 0.19 — o capítulo descreve como design de privacidade um sistema de fato aposentado.「ノイズによるプライバシー」はBIP 37を美化している。2014年の時点で、ブルームフィルターがクライアントのアドレスを大幅に露出させることが研究で示されており、Bitcoin Coreはバージョン0.19以降、BIP 37フィルターの提供をデフォルトで停止している——この章は事実上引退したシステムをプライバシー設計として描いている。「以噪声保护隐私」是对BIP 37的粉饰:早在2014年研究就表明布隆过滤器会大量暴露客户端地址,而Bitcoin Core自0.19版起默认不再提供BIP 37过滤服务——该章节把一个事实上已退役的系统描述成隐私设计。مقولة الخصوصية عبر الضوضاء تجمل BIP 37: فقد أظهرت الأبحاث منذ 2014 أن مرشحات Bloom تكشف عناوين العملاء إلى حد كبير، وتوقف Bitcoin Core عن تقديم مرشحات BIP 37 افتراضيا منذ الإصدار 0.19 — فالفصل يصف نظاما متقاعدا فعليا على أنه تصميم للخصوصية.
Belegt: Gervais et al. demonstrierten 2014 die Deanonymisierung von BIP-37-Clients, und die Default-Deaktivierung in Bitcoin Core ist dokumentiert. Der Artikel nennt die Schwächen zwar im Folgeabschnitt, rahmt den Mechanismus zuvor aber unkritisch als gewolltes Privacy-Prinzip.Substantiated: Gervais et al. demonstrated the deanonymization of BIP 37 clients in 2014, and the default deactivation in Bitcoin Core is documented. The article does list the weaknesses in the following section, but first frames the mechanism uncritically as an intended privacy principle.Confirmado: Gervais et al. demostraron en 2014 la desanonimización de clientes BIP 37, y la desactivación por defecto en Bitcoin Core está documentada. El artículo sí enumera las debilidades en la sección siguiente, pero antes encuadra el mecanismo, sin crítica, como un principio de privacidad deliberado.Confirmado: Gervais et al. demonstraram em 2014 a desanonimização de clientes BIP 37, e a desativação por padrão no Bitcoin Core está documentada. O artigo até lista as fraquezas na seção seguinte, mas antes enquadra o mecanismo, sem crítica, como um princípio de privacidade deliberado.立証済み:Gervaisらは2014年にBIP 37クライアントの非匿名化を実証しており、Bitcoin Coreでのデフォルト無効化も記録されている。記事は続く節で弱点を挙げてはいるが、その前にこのメカニズムを意図されたプライバシー原理として無批判に描いている。成立:Gervais等人在2014年就演示了对BIP 37客户端的去匿名化,Bitcoin Core的默认停用也有记录。文章虽在后续段落列出弱点,但此前却不加批判地把该机制描绘成有意为之的隐私原则。مثبت: أثبت Gervais وزملاؤه عام 2014 إمكانية كشف هوية عملاء BIP 37، والتعطيل الافتراضي في Bitcoin Core موثق. يذكر المقال نقاط الضعف في القسم اللاحق، لكنه يؤطر الآلية قبل ذلك دون نقد كمبدأ خصوصية مقصود.
Die elegante Trustless-Erzählung beschreibt nicht die eingesetzte Realität: Die meisten Mobile Wallets fragen vertrauensbasierte Server (Electrum-Protokoll, Anbieter-APIs) ab und geben dabei ihre Adressen preis; BIP-157/158-Clients blieben eine Nische, und nur ein Teil der Nodes serviert Compact Filters.The elegant trustless narrative does not describe deployed reality: most mobile wallets query trust-based servers (Electrum protocol, vendor APIs) and reveal their addresses in doing so; BIP 157/158 clients remained a niche, and only a fraction of nodes serve compact filters.La elegante narrativa trustless no describe la realidad desplegada: la mayoría de las carteras móviles consultan servidores basados en confianza (protocolo Electrum, API de proveedores) y revelan así sus direcciones; los clientes BIP 157/158 siguieron siendo un nicho, y solo una parte de los nodos sirve compact filters.A elegante narrativa trustless não descreve a realidade implantada: a maioria das carteiras móveis consulta servidores baseados em confiança (protocolo Electrum, APIs de fornecedores) e revela seus endereços ao fazê-lo; clientes BIP 157/158 permaneceram um nicho, e apenas uma parte dos nodes serve compact filters.エレガントなトラストレスの物語は、実際に使われている現実を描いていない。大半のモバイルウォレットは信頼ベースのサーバー(Electrumプロトコル、事業者API)に問い合わせ、その際に自分のアドレスをさらしている。BIP 157/158クライアントはニッチにとどまり、Compact Filtersを提供するノードは一部にすぎない。优雅的免信任叙事并未描述实际部署的现实:大多数移动钱包查询的是基于信任的服务器(Electrum协议、厂商API),并因此暴露自己的地址;BIP 157/158客户端始终是小众,提供Compact Filters的节点也只占一部分。السردية الأنيقة لانعدام الثقة لا تصف الواقع المنشور: فمعظم محافظ الهواتف تستعلم من خوادم قائمة على الثقة (بروتوكول Electrum وواجهات المزودين) وتكشف عناوينها بذلك؛ وبقي عملاء BIP 157/158 هامشيين، وجزء فقط من العقد يقدم المرشحات المدمجة.
Belegt: Verbreitete Wallets nutzen Electrum-artige Server oder Anbieter-Backends und legen dort ihre Adressen offen – Merkle-Proofs werden zwar teils geprüft, die Datenschutz-Pointe des Artikels beschreibt aber ein technisch verfügbares, praktisch wenig genutztes Modell. Neutrino-basierte Clients blieben bis 2026 die Ausnahme.Substantiated: widespread wallets use Electrum-style servers or vendor backends and expose their addresses there — Merkle proofs are partly verified, but the article's privacy punchline describes a model that is technically available yet little used in practice. Neutrino-based clients remained the exception through 2026.Confirmado: las carteras extendidas usan servidores tipo Electrum o backends de proveedores y exponen allí sus direcciones; los merkle proofs se verifican en parte, pero el remate de privacidad del artículo describe un modelo técnicamente disponible y poco usado en la práctica. Los clientes basados en Neutrino siguieron siendo la excepción hasta 2026.Confirmado: carteiras difundidas usam servidores tipo Electrum ou backends de fornecedores e expõem ali seus endereços — merkle proofs são verificados em parte, mas o desfecho de privacidade do artigo descreve um modelo tecnicamente disponível e pouco usado na prática. Clientes baseados em Neutrino continuaram a exceção até 2026.立証済み:普及しているウォレットはElectrum系サーバーや事業者バックエンドを使い、そこでアドレスをさらしている。マークルプルーフは部分的に検証されるものの、記事のプライバシーの決め台詞は、技術的には利用可能でも実際にはほとんど使われていないモデルを描いている。Neutrino系クライアントは2026年まで例外にとどまった。成立:主流钱包使用Electrum式服务器或厂商后端,并在那里暴露地址——Merkle证明虽有部分验证,但文章的隐私点睛之笔描述的是一个技术上可用、实践中却少有人用的模型。基于Neutrino的客户端直到2026年仍是例外。مثبت: تستخدم المحافظ الشائعة خوادم على نمط Electrum أو خلفيات المزودين وتكشف عناوينها هناك — تتحقق جزئيا من براهين Merkle، لكن خلاصة الخصوصية في المقال تصف نموذجا متاحا تقنيا وقليل الاستخدام عمليا. وظل العملاء المعتمدون على Neutrino الاستثناء حتى 2026.
QuellenSourcesFuentesFontes出典来源المصادر
- Bitcoin Whitepaper – Satoshi Nakamoto (bitcoin.org) (bitcoin.org)
- BIP 0037: Connection Bloom Filtering (GitHub) (github.com)
- BIP 0157: Client Side Block Filtering (GitHub) (github.com)
- BIP 0158: Compact Block Filters for Light Clients (GitHub) (github.com)
- Bitcoin Developer Documentation – bitcoin.org (developer.bitcoin.org)