Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blockchain Oriented Software (BOS) #10

Open
Mokita-J opened this issue Sep 9, 2024 · 0 comments
Open

Blockchain Oriented Software (BOS) #10

Mokita-J opened this issue Sep 9, 2024 · 0 comments

Comments

@Mokita-J
Copy link
Contributor

Mokita-J commented Sep 9, 2024

Blockchain-Oriented Software Engineering: Challenges and New Directions 2017, ICSE-C
First description of BOS:

all software working with an implementation of a blockchain

Smart contracts vulnerabilities: a call for blockchain software engineering? 2018 International Workshop on Blockchain-Oriented Software Engineering
Advocates for Blockchain oriented Software Engineering (BOSE):

we advocate the need for a discipline of Blockchain Software Engineering, addressing the issues posed by smart contract programming and other applications running on blockchains. Blockchain Software Engineering will specifically need to address the novel features introduced by decentralised programming on blockchains.

Parity Wallet Attack is used as a case study.
All parity wallet contracts would delegate-call one single library contract. This library contract was destroyed, which obliterated the functionality of ~500 wallet contracts, freezing ~$150M.
The software engineering problems present in this case were:

  • The usage of a library that required initialization. The state variables of the library were left initialized, which led to the attack.
  • The wallet contracts had the library contract address hardcoded. The library address was a constant, so once the library was destroyed all wallet contracts were rendered unusable.
  • The library contract had a functionality that allowed for its destruction.

Authors advocate for mutable library addresses, instead of hardcoded addresses present in deployed smart contracts.
This would allow for a new version of the library to be deployed and all contracts dependent on the previous version to use the newer version.

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

No branches or pull requests

1 participant