Add VIP: Private State Variable Visibility Exposure

This informational VIP aims to address a divergence from Ethereum’s state variable visibility in the VechainThor Blockchain, where the Prototype builtin contract allows unrestricted access to the private and internal storage of all contracts, potentially leading to contract vulnerabilities.

This has been documented by the community at the link below, however, this VIP would put it in a more official notice for vechain developers.

https://docs.vechain.energy/Vechain/Develop-with/Common-Pitfalls/BuiltIn-Storage-Access/

PR: https://github.com/vechain/VIPs/pull/55

3 Likes

Certainly something to look into.

3 Likes

Hey @tom, so I spoke with the devs on this one.

In summary no fields in a contract are really private. The term private just means that there is no setter or getter functions outside of the contract. Data is always visible on the blockchain unless it is encrypted.

A useful stackexchange source.

1 Like

@brettski, does this warning in the solidity docs hold true on vechain? Specifically the part about other contracts not being able to read private or internal information.

Making something private or internal only prevents other contracts from reading or modifying the information, but it will still be visible to the whole world outside of the blockchain.

If it does not, would this then not be something smart contract developers and auditors should be aware of?

https://docs.soliditylang.org/en/latest/contracts.html#index-3

2 Likes

I’ve been curious about whether the built-in contracts have undergone 3rd party audits. Currently, I’m aware of the audits for the Thor Node contract and the MaaS contracts.

If these haven’t been audited yet, is it possible for vechain to consider a 3rd party audit on the built-in contracts and their core integration? Without this I believe it could potentially prevent adoption from developers from other chains building on vechain.

1 Like

Hi @tom, if you take a look at the API GET /accounts/{address}/storage/{key}, storageFor brings the API ability to EVM which we consider it’s an extension or I would call a ‘feature’. Also, there is no secret on the blockchain(except for the blockchain with privacy as the feature) until it’s encrypted.

Solidity compiler does its job, private and internal variable won’t be accessed by other contracts since they won’t generate get function for the variables. storageFor kind of breaks this commitment.However, so-called ‘private’ variable can be accessed outside of EVM with the blockchain client’s API eth_getStorageAt(or GET /accounts/{address}/storage/{key} ). So I would suggest adding document for this feature and always give developer the hint that no secret on blockchain.

1 Like

Hey @tom any further thoughts on this given @libotony’s latest message?

2 Likes

So I would suggest adding document for this feature and always give developer the hint that no secret on blockchain.

I think this is a good move forward.