1

I'm new to solidity. I want to know if there is anything like a protected function/variable in solidity. I want to use the function on the contract and other contracts as well. But it should not be publically available.

1
  • 1
    this will work only for function calls (i.e. with execution paths), but as for data visibility, everything is visible on public blockchain. and there is no way to hide something
    – Nulik
    Jul 25 at 22:51
3

"Visibility" is similar.

Let's have a context to explore the options.

Contract Toyota is Car { ...

Great. This is inheritance. Toyota will include the code for Car. Car's constructor will execute along with Toyota's when Toyota is deployed. Toyota will inherit Car's` methods (functions), so something like this works:

contract Car {

  function startEngine() ...

From elsewhere (simplified) ...

contract Driver

  function startCar(address car) ... {
     Toyota(car).start(); // call the inherited function

The storage layout is also inherited, so Car can organize itself and Toyota can add additional storage which is a superset of Car concerns.

Storage and variables have visibility. Visibility choices have internal and external impact.

private: No one can see this exists, read it or write it except this contract, not even inherited contracts. If Car has string private model then Toyota is unable to inspect it or change it.

internal: No one outside of the inheritance graph can see it, read it or write it but contracts that inherit this module are trusted to do so. If Car has string internal model then Toyota can inspect it or change it but it is not easily* visible from outside.

external: For functions, this makes the function accessible from outside the contract (builds the external interface and allows it) but it is not accessible from inside, except by interacting in the same fashion as an external actor would. This is useful in some contexts when you want the msg.sender to be address(this) if it's needed internally, and it's more efficient if there is no need to access it all from the inside. If Car has function onStarPing() external ... then the Car and the Toyota can call it internally but the call can come from an external source. A common use-case is inspector functions that the contract itself doesn't use.

public: This is a superset of external that adds internal accessibility. Now the function is available externally or internally. In the case of variables, the compiler will build an implied inspector function for you. If that aligns with the goal, then this can be a way to make the state discoverable without cluttering the code.

contract SetGet {

  address public foo;

  function setFoo(address f) public {

This will build a "free" getter:

function foo() external view returns(address) {
  return foo;

Since public is the most permissive it is also the most popular default choice for beginners. The other options subtract unneeded or unwanted functionality including guarding update access.

  • "Easily" inspectable is a reminder that private and internal do not imply an assurance of confidentiality since the contract state is on a transparent blockchain and the state of private variables is absolutely knowable to any interested party. Visibility is about intention and efficiency - prevent accidental overwrite/developer error, refrain from constructing (compiling) unneeded/unwanted code.

Hope it helps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.