Skip to content

Conversation

@WilliamHawkingStephen
Copy link

No description provided.

@WilliamHawkingStephen
Copy link
Author

@kdeme @ogenev


> NOTE: Because CREATE2 opcode allows for redeployment of new code at an existing address_hash, we MUST randomly distribute contract code storage across the DHT keyspace to avoid hotspots developing in the network for any contract that has had many different code deployments. Were we to use the path based *high-bits* approach for computing the content-id, it would be possible for a single location in the network to accumulate a large number of contract code objects that all live in roughly the same space.
Problematic!
> NOTE: Because CREATE2 opcode allows for redeployment of new code at an existing address*hash, we MUST randomly distribute contract code storage across the DHT keyspace to avoid hotspots developing in the network for any contract that has had many different code deployments. Were we to use the path based \_high-bits* approach for computing the content-id, it would be possible for a single location in the network to accumulate a large number of contract code objects that all live in roughly the same space.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like a faulty change.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hey again yes you right my bad

@WilliamHawkingStephen
Copy link
Author

@kdeme

Copy link
Collaborator

@kdeme kdeme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great, thanks for fixing typos, removing trailing whitespaces, fixing notes.

But regarding list styles, indents, emphasis markers and so on (anything that does not break markdown specs), that seems like personal preference changes that are also difficult to maintain without having a linter applied in CI.

So in my opinion, these type of changes should get a linter added first for some consistent settings, else somebody else tomorrow might just set them all back to their liking.

@WilliamHawkingStephen
Copy link
Author

WilliamHawkingStephen commented Sep 9, 2024

Great, thanks for fixing typos, removing trailing whitespaces, fixing notes.

But regarding list styles, indents, emphasis markers and so on (anything that does not break markdown specs), that seems like personal preference changes that are also difficult to maintain without having a linter applied in CI.

So in my opinion, these type of changes should get a linter added first for some consistent settings, else somebody else tomorrow might just set them all back to their liking.

correct 👍

do we have a general linter for repo? if we dont have a proper linter for repo we can implement a structure for this one

@kdeme
Copy link
Collaborator

kdeme commented Sep 10, 2024

do we have a general linter for repo? if we dont have a proper linter for repo we can implement a structure for this one

No, we don't. I've created an issue for this some time back: #321

My suggestion would be to adjust this PR to only contain actual fixes.

Any additional PR that then introduces linting is highly welcomed of course :)

@WilliamHawkingStephen
Copy link
Author

WilliamHawkingStephen commented Sep 10, 2024

do we have a general linter for repo? if we dont have a proper linter for repo we can implement a structure for this one

No, we don't. I've created an issue for this some time back: #321

My suggestion would be to adjust this PR to only contain actual fixes.

Any additional PR that then introduces linting is highly welcomed of course :)

nice !

yeah of course , i will change necessary changes on this pull req 👍

and yeah i enjoy giving structural improve :)) i try my best for making another pull req for linting purpose 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants