LV.1 crypto zombies - 4 Zombie Battle System

dev/Solidity

LV.1 crypto zombies - 4 Zombie Battle System

_April 2021. 11. 28. 17:46

(1)Payable

visibility modifiers

when and where the function can be called from

private: it's only callable from other functions inside the contract;
internal: like private but can also be called by contracts that inherit from this one
external: can only be called outside the contract
public: can be called anywhere, both internally and externally.

state modifiers

how the function interacts with the BlockChain

view: running the function, no data will be saved/changed.
pure: the function not save any data to the blockchain, it also doesn't read any data from the blockchain.

Both of these don't cost any gas to call if they're called externally from outside the contract (but they do cost gas

if called internally by another function)

payable

a special type of function that can receive Ether.

contract OnlineStore {
  function buySomething() external payable {
    // Check to make sure 0.001 ether was sent to the function call:
    require(msg.value == 0.001 ether);
    // If so, some logic to transfer the digital item to the caller of the function:
    transferThing(msg.sender);
  }
}

msg.value is a way to see how much Ether was sent to the contract

돈전송할땐 무조건 payable 모디파이어를 사용해야함

안그럼reject됨

(2)Withdraws

contract GetPaid is Ownable {
  function withdraw() external onlyOwner {
    address payable _owner = address(uint160(owner()));
    _owner.transfer(address(this).balance);
  }
}

Or in a contract with a buyer and a seller, you could save the seller's address in storage, then when someone

purchases his item, transfer him the fee paid by the buyer: seller.transfer(msg.value).

These are some examples of what makes Ethereum programming really cool — you can have decentralized

marketplaces like this that aren't controlled by anyone.

1,2번 잘 이해잘안가서 다시해봐야할듯..

아님 다른예제를 좀더보거나..

코딩은 따라칠수있는데 뭘하는건지 잘모르겠음

(3)난수생성하기

Random number generation via keccak256 ->보안문제가있음.

이유: 컨트랙트상에서 펑션을 부르면 네트워크의 노드들에게 트렌젝션을 broadcast한다. POW에 따라 노드들은 이 브로드캐스트된 트젝들을 모아서 빨리 문제를 풀려고한다.

그래서 한노드가 문제를 풀면, 다풀었다고 네트워크의 다른 노드들에게 퍼블리시함. 그러면 다른 노드들은 문제풀기를 중단하고 다른 노드가 제출한 트랜젝션이 유효한지만 인증한다. 유효하다고 확인되면 인증하고 다같이 다음 블락의 문제풀기로 넘어감. 근데 이과정이 랜덤번호 만들기를 악용할수 있게되는데,

예를들면 동전뒤집기가 있음.
Let's say we had a coin flip contract — heads you double your money, tails you lose everything.

Let's say it used the above random function to determine heads or tails.

(random >= 50 is heads, random < 50 is tails).

노드를 돌리는 입장에선, 문제를 푼다음 다른노드에 결과를 공유할지 말지 정할수가 있다. 그래서 실패하면 공유하지않고 다시 계산할수있다. 그래서 성공하는값이나오면 다른 노드에 공유하는것이다. 그런다음 다음블록 문제풀기로 넘어갈수가 있다.

=>근데 이럴려면 해당노드가 다른 노드보다 빠르게 일을해야 가능한거아닌가?

내 노드가 재수가없어서 6번씩 false가 나오면 7번 연산해야하는데 그동안 딴노드는 1번만 계산해서 먼저 끝냈다고 퍼블리시할수도있잖아.

라고생각했더니 뒤에 이얘기가나옴ㅋㅋㅋㅋ

Of course, since tens of thousands of Ethereum nodes on the network are competing to solve the next block,

my odds of solving the next block are extremely low.

It would take me a lot of time or computing resources to exploit this profitably —

but if the reward were high enough (like if I could bet $100,000,000 on the coin flip function),

it would be worth it for me to attack.

역시 그럴 확률은 적지만, 보상이 클경우 분명 악용을 시도하는 사람이 있을거라는것.

어쨌거나! 해결법:

we may cover using oracles (a secure way to pull data in from outside of Ethereum) to generate secure random numbers from outside the blockchain.

하여튼 이더리움체인상에서 난수를 생성하지 말라고..

(4)refactory

require을 modifier로 바꾸기

이번챕터는 무난했음

저작자표시