Did you know? A Solidity smart contract can declare a variable private even though the underlying value may still be observable to people examining a public blockchain. The word *private* in that programming language mainly controls which other contract code can directly access the variable. It is not a magical password protecting the bytes from everybody in the world.
Imagine a fictional school science club preparing an online quiz. Alicia writes the correct answer inside a smart contract variable labelled private answer. Kai Kai assumes nobody can see it until the quiz ends. Tricia points out that a public network deliberately replicates data for verification. The answer might be hidden from the website’s ordinary display while remaining readable from the underlying chain or its historical records.
This is a surprisingly important security and privacy distinction. Blockchain rules make it possible for independent nodes to check certain computation and shared state. That verification can conflict with the expectation that sensitive data stored as ordinary public-chain state will remain confidential.
Quick answer: on a transparent public Ethereum-style blockchain, contract source code, deployed bytecode, transaction calldata, contract storage and logs can expose information in different ways. Solidity visibility modifiers such as private and internal do not provide confidentiality from external blockchain observers. Developers should not place recovery phrases, passwords, hidden quiz answers, private documents or API secrets into publicly accessible chain data and assume a source-code keyword will protect them.
This easy-to-read guide explains how blockchain technology works through public storage, hidden answers, hashes, encryption, commit-reveal schemes and zero-knowledge proofs. We use imaginary school examples instead of deploying secrets or asking readers to inspect live wallets. For the broad privacy lesson, read Why Public Blockchain Transactions Are Not Anonymous.
Choose your reading route
- Why public verification and secrecy can conflict
- What Solidity private actually means
- Why removing a public getter does not hide storage
- Transaction calldata can reveal submitted information
- A secret placed inside deployed code is not reliably hidden
- Why encryption changes the problem—but does not finish it
- A hash is not encryption
- Frequently asked questions
- Primary sources and further reading
Why public verification and secrecy can conflict
A blockchain network aims to let participants verify defined transactions and state according to agreed rules. On many public networks, those participants need access to transaction input and relevant state so they can check the result independently.
Think of a school record maintained in copies across numerous classrooms. Students can cross-check arithmetic because everyone sees the relevant numbers. If one classroom secretly changes a number, the other copies reveal the mismatch.
This openness can strengthen auditability. But it also means that putting an undisclosed exam answer inside the replicated register is not an effective way to protect the answer. Even if the normal website hides the field, somebody who reads the raw records may still discover it.
Not every blockchain publishes identical information. Permissioned systems, privacy-preserving protocols and applications using encryption can impose different access or visibility rules. The lesson here concerns ordinary public Ethereum-style contract state and transaction data, not an unsupported claim about all distributed systems.
A good design begins by naming which facts must be publicly verifiable and which data must remain secret. Only then can it select suitable cryptographic tools and storage architecture.
The crucial habit is to distinguish public consensus data from confidential application information. Putting everything in one public contract because it is convenient is not necessarily secure.
What Solidity private actually means
Solidity uses visibility specifiers for state variables and functions. A public state variable can have an automatically generated getter function. An internal state variable is accessible to the declaring contract and derived contracts under the language’s rules. A private state variable limits direct access by other Solidity contracts and derived contracts.
Those restrictions help developers structure software interfaces and inheritance. They are not encryption. The data still form part of the contract’s underlying storage model and can be inspected outside normal Solidity getter functions in a transparent public chain.
The official Solidity documentation on visibility and getters explicitly warns that making information private or internal only prevents other contracts from directly reading or modifying it; the information remains visible outside the blockchain execution context.
That warning surprises beginners because in everyday language *private* usually means secret. In Solidity, it is largely a software-access concept rather than a network-wide confidentiality guarantee.
Imagine the school locking a drawer while photocopying its contents onto a public noticeboard. A student outside the classroom cannot open the drawer, but the posted photocopy still exposes the answer. The analogy explains why restricting one programmatic access path is not enough.
The correct statement is: a private Solidity variable can be inaccessible through ordinary other-contract code while its value remains observable through blockchain inspection.
Why removing a public getter does not hide storage
A beginner may try to hide a value by using private instead of public, or by omitting a custom function that returns the data. That can stop casual queries through an ordinary contract interface, but it is not a confidentiality barrier against someone examining chain storage.
A public Ethereum contract has defined storage slots and can hold values that nodes need to use while executing transactions. Appropriate observers may inspect storage via node APIs or analysis tools, subject to how data are laid out and encoded.
The absence of an explorer’s convenient “Read Contract” field therefore does not prove that the bytes are inaccessible. A value could be represented in a mapping, encoded across slots or otherwise harder to interpret, but difficulty of interpretation should not be confused with cryptographic secrecy.
Our fictional quiz might have no public function called getAnswer. The website cannot simply call a friendly getter. Yet the quiz answer may still exist in public storage used by the contract’s execution logic.
The school needs a different design if students are not supposed to know the answer before the closing time. Hiding the source-level getter is not enough.
This is a useful digital-literacy rule beyond blockchain: the way an interface chooses to present information is not the same as where information exists or who can inspect it.
Transaction calldata can reveal submitted information
A transaction calling a smart contract can include input data, often called calldata, specifying which operation is being requested and the parameters supplied. On public networks, that data can be part of the accepted transaction record.
Suppose Alicia submits her quiz guess as an ordinary plaintext argument to a public contract. Even if the contract checks the guess without emitting a readable event, the submitted input may still expose her chosen answer or another sensitive field.
The risk begins before considering whether the contract variable was marked private. The user has already placed the information into a publicly observable transaction format.
Events and logs create an additional exposure route when the contract emits selected data during execution. A successful transaction can publish event arguments that a block explorer decodes into a readable table. Failing to display a field in the wallet does not remove it from the network record.
A sound privacy analysis identifies every data path: original request, calldata, persistent state, logs, emitted proofs, application backend and any indexed copies.
For a deeper explanation of traces and events, read Why an Internal Transaction Is Not Another Signed Payment. It shows why the public execution record can expose more detail than a single wallet headline.
A secret placed inside deployed code is not reliably hidden
Some beginners imagine storing a secret as a constant inside contract code rather than in an ordinary state variable. This can appear attractive because it avoids creating a named storage field.
However, deployed smart-contract bytecode is part of the execution environment and can be analysed. The source code may also be published, verified or reconstructed in part from bytecode behaviour. A secret embedded in transparent executable material should not be assumed confidential.
The school might write a classroom answer into the programme itself. Students who are technically skilled may be able to inspect the compiled representation or infer the answer from available logic. Merely replacing a readable word with hexadecimal bytes does not create a secure hiding place.
This is especially serious for API credentials, private signing keys or passwords. A hardcoded secret in publicly distributed software can expose systems beyond the smart contract itself.
The proper design usually keeps true credentials and sensitive keys in suitable controlled infrastructure rather than publishing them to a replicated ledger. The appropriate mechanism depends on the service and risk model.
The core message is direct: if every verifying participant needs the code or data to reproduce the calculation, assume those public inputs may be inspected.
Why encryption changes the problem—but does not finish it
Encryption can protect the readable contents of data under specified cryptographic assumptions. A public blockchain can potentially store or reference encrypted ciphertext without directly revealing the plaintext to every observer.
But that is a different arrangement from simply declaring a Solidity variable private. The information is transformed using a cryptographic scheme, and somebody needs the appropriate keys or authorised process to decrypt it.
If the decryption key is also published to the same transparent network, the confidentiality benefit may disappear. If the key is lost, the intended recipient may lose access to the original data. If the key is compromised, the encrypted information may become readable to an unwanted party.
Encryption also does not necessarily hide metadata. An observer may still see which account submitted the ciphertext, when it was published, how large it is and which contracts reference it.
For our fictional quiz, the school could encrypt a question bank outside the public contract and publish a carefully designed commitment or access policy. But it must still manage keys, fairness of participant access and how the correct answers are eventually revealed.
The reader’s question is therefore where are the secret plaintext and decryption authority kept, and who can access them? A secure architecture has to answer that explicitly.
A hash is not encryption
Hashing maps input bytes to a fixed-size output under a defined algorithm. It can help verify that a later supplied file or message matches an earlier commitment. It does not preserve a reversible secret copy of the input.
This can be useful for revealing information later. A school might publish a cryptographic commitment to a quiz answer before the contest and disclose the answer after the deadline. Observers can then verify that the published answer corresponds to the earlier commitment.
But weak or highly predictable inputs create an important risk. Suppose the quiz answer can only be YES or NO. If the public commitment is simply the unsalted hash of the answer, an observer can compute hashes of the two possibilities and determine which one matches.
An appropriate commitment scheme may include fresh unpredictable secret randomness as well as the value being committed. Even then, the final protocol must address publication timing, repeated use and the risk that the committer refuses to reveal.
This is why a plain hash is not a magical confidentiality tool. It is a compact integrity commitment whose secrecy properties depend on how much uncertainty remains about the input and on the surrounding scheme.
For a deeper guide, read Random Selection on a Blockchain: Commitments, Proofs and the Option to Withhold.
A safe commit-reveal classroom exercise
Imagine Alicia must commit to a fictional quiz answer before everyone takes the test. Instead of displaying the answer itself, the school produces a properly designed commitment to the answer and an unpredictable hidden salt.
The public record contains the commitment. Students can see that the school fixed some input without learning the answer, assuming the commitment scheme’s binding and hiding properties hold under the stated construction.
After the quiz, Alicia reveals the answer and salt. The class can verify that they match the earlier commitment. The system can therefore support later accountability without exposing the answer in advance.
Now add a complication: Alicia refuses to reveal after observing the students’ results. The commitment remains but the class cannot automatically determine the withheld answer. The school needs rules for non-revelation, deadlines and dispute handling.
Another complication arises if the answer belongs to a tiny predictable set and the salt is weak or reused. The commitment could leak more information than intended. The quality of randomness matters.
This exercise can be performed entirely on paper with made-up commitment labels to teach the concept. No student should publish real passwords, secret keys or exam answers to experiment with a public chain.
Zero-knowledge proofs can separate checking from revealing
Zero-knowledge proofs provide another powerful design idea. Under a suitable proof system, a prover can demonstrate that a precise mathematical statement is satisfied without revealing all private information used to establish it.
For example, an application might prove that a student belongs to an eligible membership set without publishing which member the student is, assuming the system is designed to protect that identity.
This is different from making every public contract variable secret. The system defines public inputs, a private witness and a verification relation. The public verifier checks a proof of the statement without learning the entire witness under the proof system’s assumptions.
However, the surrounding application can still expose information. A public address, reused identifier, disclosed output or third-party website may reveal details even when the core mathematical proof has a zero-knowledge property.
The Ethereum Zero-Knowledge Proofs overview describes what these schemes can establish and why they are useful. Their presence does not guarantee a website’s issuer identity or the truth of unrelated outside claims.
The reader’s lesson is that privacy requires an explicitly defined property with a suitable construction, not a wishful label such as private or secret on ordinary public data.
Encrypted files can still require off-chain storage
Some private documents are too large, sensitive or operationally complicated to store directly in public blockchain state, even in encrypted form. A system may instead keep them in access-controlled storage while anchoring a limited integrity commitment or proof on the chain.
Imagine the school needs to preserve confidential student feedback. Publishing the entire plaintext record on a public ledger would disclose information the programme should protect. Publishing encrypted copies everywhere can still expose metadata and create long-term key-management obligations.
A more proportionate design might keep the original records under suitable institutional controls and publish only what independent verifiers actually need. The architecture should support correction, retention limits and the school’s applicable obligations.
A hash or CID can help identify an original when the bytes are available. But a hash is not a backup, and an encrypted file is not useful to an authorised reader who has lost every valid decryption route.
The project therefore needs separate policies for confidentiality, file availability, key custody, access logging and legitimate deletion. Blockchain consensus does not automatically fulfil all those functions.
Our companion Where Blockchain Files Are Actually Stored explains why a public reference and the actual original bytes are distinct objects.
What goes wrong when a game reveals future outcomes
Consider an imaginary turn-based game. The developers store a secret prize location in a Solidity private variable, expecting players to explore the board fairly. A technologically skilled player examines public storage or transaction inputs and learns where the prize is located.
The game can still operate exactly as programmed. A verified network can accurately apply the rules. Yet the intended suspense disappears because the supposedly hidden outcome was not truly confidential.
A similar problem can affect sealed-bid auctions if bids are published before the closing time. If everyone can see competing bids while deciding whether to submit theirs, the result may differ from an auction designed for private offers.
Such applications need genuine commitment or privacy mechanisms where appropriate, or a trusted off-chain process with clearly understood responsibilities. Their chosen design determines which attack and fairness risks remain.
This is why a developer should start with a threat model: who needs to be prevented from learning the information, for how long, and what are they allowed to inspect?
A hidden website panel, renamed variable or closed-source interface is not a reliable substitute for an actual confidentiality mechanism in a transparent system.
Private data and private functions are different concerns
Solidity also allows functions to have visibility categories. A function marked private or internal restricts which Solidity code can call it directly under the language’s rules. This is helpful for organisation, reuse and reducing unintended contract-to-contract interfaces.
But the code implementing such a function can still influence public execution, and its instructions may appear in deployed bytecode. If the function processes secret inputs obtained from public calldata or storage, its visibility does not encrypt those inputs.
The distinction is between access control over code calls and confidentiality of information. A programme can prevent an external contract from invoking a helper function while leaving its implementation visible to observers.
The school analogy is a teacher-only procedure manual attached to a computer that processes a public list. Preventing students from calling one helper command does not automatically conceal the list the computer processes.
A security review should identify what data are public, which functions are callable, which keys or roles can authorise actions and which secrets remain off-chain. These are different safeguards that work together.
The official Solidity visibility documentation explicitly cautions readers not to interpret private and internal as hiding chain data from outside observers.
What a wallet or explorer may not show by default
A wallet’s ordinary home screen focuses on the information people most often need: balances, transfers and familiar token names. It may not show every raw contract storage word, signed transaction input or historical state change.
Similarly, one block explorer may offer decoded contract methods while another shows only hexadecimal data. A field missing from a friendly page is not proof that the underlying bytes are secret or inaccessible.
An observer with appropriate tooling might inspect lower-level data or use a node’s APIs to retrieve information beyond the basic summary. The details can require technical skill, but technical difficulty is not equivalent to strong cryptographic privacy.
This is especially relevant when somebody claims a public smart contract contains a “hidden owner password.” A readable interface might conceal the password, while the code or storage could still expose it. That would be a serious design error.
A cautious reader should avoid assuming any website’s user interface defines the total amount of public information available. Instead, ask how the actual data are represented and what the network makes retrievable.
See Why Two Block Explorers May Disagree for the broader distinction between network state, indexing and display.
Why public blockchain secrets can become permanent evidence
A public data disclosure can be particularly serious because many participants or services may retain copies, backups, historical state or transaction data. Removing one website page does not necessarily remove an earlier disclosure from other systems.
If a credential such as an API key has been published into public transaction data, changing a Solidity modifier will not make the old bytes disappear. A proper security response may require revoking or rotating the affected credential through the external system that accepts it.
Likewise, publishing a private student record on-chain and later declaring it deleted is not enough to establish that all copies have been removed. Appropriate retention and deletion policies should be designed before storing sensitive information.
The security lesson is broader than public blockchains. Data minimisation and careful access planning reduce the amount of information that could become irreversibly exposed.
For an educational exercise, imagine students photocopying a private note and posting copies in ten classrooms. Removing one copy does not guarantee every other copy is gone. That is the kind of problem replicated public information can create.
The responsible approach is to assume secrets belong in systems designed for confidentiality, with only necessary verification evidence exposed publicly.
A seven-check privacy worksheet
1. Name the secret. Is it a password, signing key, hidden game value, confidential document, trade input or personal identity detail?
2. Identify the public data path. Could the value appear in transaction calldata, storage, deployed code, logs, proof inputs or an explorer’s indexed copy?
3. Check the protection’s actual meaning. Does a keyword merely limit Solidity access, or does a cryptographic scheme protect confidentiality against relevant observers?
4. Examine predictability. A hash of a two-option answer may be guessable even though the hashing algorithm itself is sound.
5. Locate the keys and salts. A ciphertext’s protection depends on secret keys; a commitment’s hiding property can depend on sufficient randomness and construction.
6. Plan for time and copies. Which data become public after a reveal, and which earlier records may remain accessible? Can the organisation meet retention obligations?
7. State what the verifier needs. Consider whether a narrow signature, commitment or zero-knowledge proof can establish the required claim without publishing the original sensitive record.
This worksheet is for learning and responsible design. It does not call for extracting real secrets or inspecting strangers’ accounts. The safest outcome is a system that never publishes the private data in the first place.
Frequently asked questions
Are private Solidity variables actually secret?
No. The private modifier limits which Solidity code can access the variable directly. The value can still be observable from public blockchain data under the contract’s storage representation.
Can a smart contract store a password privately?
Ordinary transparent public state is not a suitable place for a secret password or signing key. A proper solution requires a different confidential storage and verification design.
Does removing a getter function hide the data?
Not reliably. A missing getter can make a value less convenient to query, but publicly replicated state can still be inspected through other methods.
Can transaction calldata reveal my secret?
Yes. A plaintext value submitted in ordinary public transaction input can become part of the visible transaction record.
Does encrypting information solve every privacy issue?
No. It can protect readable contents under its security assumptions, but key custody, metadata exposure, storage and future access still matter.
Can a hash protect a hidden quiz answer?
A properly designed commitment scheme can help. A simple unsalted hash of a predictable answer may allow observers to guess the answer by testing likely candidates.
What is commit-reveal?
It is a method that commits to information before later revealing it. Proper design must consider unpredictable salts, deadlines and selective non-revelation.
Can a zero-knowledge proof verify a private fact?
A suitable proof system can verify a defined statement without revealing the entire witness under its assumptions, though surrounding application metadata may still expose information.
Is a Solidity private function invisible in deployed code?
No. Function visibility concerns Solidity call access; executable bytecode and public execution may still be analysed.
Can a public explorer display information a wallet hides?
Yes. Wallets show a curated interface, while node and explorer tools may expose additional storage, calldata or trace information.
Can I delete a secret that was already published on-chain?
Removing one interface or changing later code does not guarantee removal from historical public records and other retained copies. The affected credential may need appropriate revocation elsewhere.
What should students remember?
Private code access is not private data. A public blockchain can faithfully preserve information that the application designer never should have made public.
Primary sources and further reading
The official Solidity visibility and getters documentation warns that private and internal do not conceal information from outside blockchain observers. Ethereum’s Zero-Knowledge Proofs guide explains how selected statements can be verified without revealing all underlying inputs. Ethereum’s Smart Contract Security guide provides broader context for protecting critical logic and permissions.
Within eduKateSG, continue to Why Public Blockchain Transactions Are Not Anonymous, Where Blockchain Files Are Actually Stored, Random Selection: Commitments, Proofs and the Option to Withhold and Why an Oracle Can Deliver Incorrect Data.
The lasting lesson is straightforward: a public smart contract is not a safe hiding place simply because the programmer used the word private. Confidentiality needs its own explicitly designed protection.