ethereum/go-ethereum · error
not implemented
Error message
not implemented
What it means
BinaryTrie.Prove is a stub that panics with 'not implemented'. The binary (Verkle-style) trie in this codebase does not support Merkle-proof construction yet; calling Prove always panics regardless of arguments.
Source
Thrown at trie/bintrie/trie.go:396
return t.Hash(), nodeset
}
// NodeIterator returns an iterator that returns nodes of the trie. Iteration
// starts at the key after the given start key.
func (t *BinaryTrie) NodeIterator(startKey []byte) (trie.NodeIterator, error) {
return newBinaryNodeIterator(t, nil)
}
// Prove constructs a Merkle proof for key. The result contains all encoded nodes
// on the path to the value at key. The value itself is also included in the last
// node and can be retrieved by verifying the proof.
//
// If the trie does not contain a value for key, the returned proof contains all
// nodes of the longest existing prefix of the key (at least the root), ending
// with the node that proves the absence of the key.
func (t *BinaryTrie) Prove(key []byte, proofDb ethdb.KeyValueWriter) error {
panic("not implemented")
}
// Copy creates a deep copy of the trie.
func (t *BinaryTrie) Copy() *BinaryTrie {
return &BinaryTrie{
store: t.store.Copy(),
reader: t.reader,
tracer: t.tracer.Copy(),
groupDepth: t.groupDepth,
recorder: t.recorder,
}
}
// IsUBT returns true if the trie is a Verkle tree.
func (t *BinaryTrie) IsUBT() bool {
// TODO @gballet This is technically NOT a verkle tree, but it has the same
// behavior and basic structure, so for all intents and purposes, it can be
// treated as such. Rename this when verkle gets removed.View on GitHub (pinned to 6bb0588ad8)
Solutions
- Do not call Prove on BinaryTrie; use the trie package's proof APIs (trie.Prove on the Merkle Patricia trie) for keys in a Merkle trie.
- Use the supported witness/recorder APIs (trie.Recorder) if you need authenticated data from the binary trie.
- Track upstream: implement or wait for Prove support in bintrie before enabling proof paths for binary tries.
Example fix
// before
err := binaryTrie.Prove(key, proofDb) // panics: not implemented
// after
if _, isBin := t.(*bintrie.BinaryTrie); isBin {
return errors.New("proofs not supported for binary trie")
}
err := mptTrie.Prove(key, proofDb) Defensive patterns
Strategy: type-guard
Validate before calling
if _, isBinary := t.(*bintrie.BinaryTrie); isBinary {
return errors.New("proofs not supported for binary trie")
} Type guard
func supportsProve(t interface{ Prove([]byte, ethdb.KeyValueWriter) error }) bool {
if _, ok := t.(*bintrie.BinaryTrie); ok {
return false // Prove panics: not implemented
}
return true
} Prevention
- Feature-detect proof support by concrete trie type before calling Prove.
- Keep proof code paths separate per trie flavor instead of sharing one interface call.
- Watch upstream release notes for bintrie proof support before enabling it.
When it happens
Trigger: Calling trie.Prove(key, proofDb) on a *bintrie.BinaryTrie obtained from a binary trie instance; generic code that accepts a trie interface and calls Prove when the concrete type is the binary trie.
Common situations: Reusing proof-generation code written for the Merkle Patricia trie against the binary trie; witness/proof tooling migrated to a chain using binary tries; testing an API surface that is not yet available in this version.
Related errors
AI-assisted analysis of ethereum/go-ethereum@6bb0588ad8 (2026-08-15).
Data as JSON: /api/errors/7b636c25827b027a.
Report an issue: GitHub.