crowetic/protocol
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Closes https://github.com/0xProject/protocol/issues/485 (#635)

Browse Source
This commit is contained in:
Elena 2022-12-26 10:34:18 +02:00 committed by GitHub
parent 3164d7882c
commit 2e157cc307
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 7 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/architecture/proxy.rst
View File

@ -54,7 +54,7 @@ Call ``rollback()`` to revert a function implementation to a prior version in it
Ownership
=========
Another Feature, ``InitialMigration``, bootstraps into the proxy is the Ownable feature. This exposes ownership management functions: ``transferOwnership()`` and ``getOwner()``. This feature also enables ubiquitous modifiers such as onlyOwner, so it is an implicit dependency of nearly every other feature.
Another Feature, ``InitialMigration``, bootstraps into the proxy is the Ownable feature. This exposes ownership management functions: ``transferOwnership()`` and ``owner()``. This feature also enables ubiquitous modifiers such as onlyOwner, so it is an implicit dependency of nearly every other feature.
.. code-block:: solidity
@ -63,8 +63,9 @@ Another Feature, ``InitialMigration``, bootstraps into the proxy is the Ownable
external
onlyOwner;
// Get the owner of this contract.
function getOwner()
/// @dev Get the owner of this contract.
/// @return owner_ The owner of this contract.
function owner()
external
view
returns (address owner_);
@ -189,7 +190,7 @@ These involve meaningful behavioral changes, such as new settlement logic, chang
**Features used by Features**
Not all features are designed to be exclusively consumed by the public. We can have internal features by applying an onlySelf modifier to the function. We need to be mindful of another class of user: the contract itself. Avoiding missteps on this will require a combination of diligence and good regression test suites.
Not all features are designed to be exclusively consumed by the public. We can have internal features by applying an onlySelf modifier to the function. We need to be mindful of another class of user: the contract itself. Avoiding missteps on this will require a combination of diligence and good regression test suites.
Known Risks
===========
@ -213,7 +214,7 @@ Every time we develop a new feature, an entry is appended to the ``LibStorage.St
function getStorageSlot(StorageId id) internal pure returns (uint256) {
return (uint256(id) + 1) << 128;
}
Given Solidity’s `storage layout rules <https://solidity.readthedocs.io/en/v0.6.6/miscellaneous.html)>`_, subsequent storage buckets should always be 2^128 slots apart, which means buckets can have 2^128 flattened inline fields before overlapping. While it’s not impossible for buckets to overlap with this pattern, it should be extremely unlikely if we follow it closely. Maps and arrays are not stored sequentially but should also be affected by their base slot value to make collisions unlikely.
@ -254,4 +255,4 @@ Functions can be re-entered by default; those secured by the ``nonReentrant`` mo
**Colliding Function Selectors**
We manually ensure that function selectors do not collide during PR's. See the `Feature Checklist <./features.html#best-practices>`_ for a complete list of our best practices on Feature Development.
We manually ensure that function selectors do not collide during PR's. See the `Feature Checklist <./features.html#best-practices>`_ for a complete list of our best practices on Feature Development.