// SPDX-License-Identifier: MIT

pragma solidity ^0.8.18;

import {priceConverter} from './priceConverter.sol';


error dontaskme;

contract fundMe{
    using priceConverter for uint;

    uint public myValue = 5e18; 
    address[] public funders;
    mapping (address funder => uint256 funded) public fundingOf;

    address public owner;

    constructor(){
        owner = msg.sender;
    }

    function fund()public payable{
        require (msg.value.getConversionRate() > myValue, "Not enough fund");
        funders.push(msg.sender);
        fundingOf[msg.sender] += msg.value;
    }



    function withdraw()public onlyowner{
        for(uint funderIndex = 0; funderIndex < funders.length; funderIndex++){
        address funder = funders[funderIndex];
        fundingOf[funder] = 0;
        }
        funders = new address[](0);
        //payable(msg.sender).transfer(address(this).balance);

        //bool sendsuccess = payable(msg.sender).send(address(this).balance);
       // require(sendsuccess, "send failes");

        (bool callsuccess,) = payable(msg.sender).call{value: address(this).balance}("");
        require(callsuccess, "send failes");



    }

    modifier onlyowner(){
        require(msg.sender == owner, "must be owner");
        _;
    }


}

In my learning time on cyfrin updraft, I came across the different types of payment, and it was quite interesting as I took more time to understand how payment works. I understood from under the hood why these three call(), send(), and transfer() are used to receive tokens.

Moving Ether between contracts and addresses is fundamental when building real-world decentralized applications (dApps).

The Solidity programming language offers three primary methods: transfer(), send(), and call(). Each comes with its own quirks, security implications, and gas considerations.

The Evolution of Value Transfers

Back in the early days of Ethereum, transfer() was the go-to method for sending Ether. However, as the ecosystem matured and more complex smart contracts emerged, developers discovered limitations that led to the adoption of call() as the recommended approach.

Breaking Down Each Method

transfer()

payable(msg.sender).transfer(address(this).balance);

Characteristics:

• Fixed gas stipend of 2300 gas
• Automatically reverts on failure if the gas fee for that transaction is more than the allocated gas.
• Throws an exception if execution fails
• Cannot be adjusted for gas limits

Real-world Implications

In 2021, developers used transfer() to send rewards to users. When recipient contracts implemented a more complex receive function, transfers began failing because the 2300 gas wasn't enough. Developers migrated to call() through an upgrade, causing development delays.

send()

bool sendSuccess = payable(msg.sender).send(address(this).balance);
require(sendSuccess, "Send failed");

Characteristics:

• Also limited to 2300 gas
• Returns boolean instead of reverting
• Requires manual checking of return value
• More control over failure handling

call()

(bool callSuccess,) = payable(msg.sender).call{value: address(this).balance}("");
require(callSuccess, "Call failed");

Characteristics:

• Adjustable gas limit
• Returns success boolean and data bytes
• More flexible and future-proof
• Requires reentrancy protection
• Currently recommended approach

Conclusion

While transfer() and send() served their purpose in Ethereum's earlier days, call() has emerged as the most flexible and future-proof method for value transfers. However, this flexibility comes with responsibility - developers must implement proper security measures and follow best practices to ensure safe and efficient value transfers in their smart contracts.

Remember: Ethereum's ecosystem continues to evolve, and today's best practices might need adaptation as the platform grows. Stay updated with the latest Solidity documentation and community standards.

Tomorrow, I will be talking about zksync and how zero knowledge is becoming the center phase for the web3 innovation.