solidity ecrecovery und ethereumjs ecsign geben unterschiedliche Adressen zurück

Ich habe einen Code wie folgt mit web3 0.2und ethereumjs-utilum mit Smart Contract zu interagieren. Was genau mache ich falsch? ist es inkompatibel zwischen ecsign von ehtereumjs mit smart contract ecrecovery? Wie kann ich es reparieren?

Antworten (2)

Warum senden Sie sigzum Vertrag? Funktioniert es für Sie, alle Teile einzeln zu versenden?

function ecrecover(bytes32 msgHash, uint8 v, bytes32 r, bytes32 s) constant returns(address) {
    bytes memory prefix = "\x19Ethereum Signed Message:\n32";
    bytes32 prefixedHash = keccak256(prefix, msgHash);
    return ecrecover(prefixedHash, v, r, s);
}

Weitere Arbeitsbeispiele finden Sie unter: https://github.com/davidmichaelakers/ecrecover

AKTUALISIEREN:

Falls Sie eine Unterschrift zum Vertrag senden müssen, müssen Sie meiner Meinung nach prefixIhren Code hinzufügen. web3tut es für Sie, das kann ein Grund für unterschiedliche Ergebnisse sein

bytes memory prefix = "\x19Ethereum Signed Message:\n32";
bytes32 prefixedHash = keccak256(prefix, msgHash);

UPDATE 2: Arbeitslösung

Abhängigkeiten:

Truffle v4.1.8 (core: 4.1.8)
Solidity v0.4.23 (solc-js)

"chai": "^4.1.1",
"chai-as-promised": "^7.1.1",
"chai-bignumber": "^2.0.1",
"ethereumjs-util": "^5.2.0",
"mocha": "^3.5.0",
"truffle-contract": "^2.0.5"

Intelligenter Vertrag:

pragma solidity ^0.4.25;

contract Test {
    function ecrecover(bytes32 msgHash, uint8 v, bytes32 r, bytes32 s) constant returns (address) {
        return ecrecover(msgHash, v, r, s);
    }
}

Prüfen:

const EthUtil = require('ethereumjs-util')

const Test = artifacts.require("./Test.sol");
const BigNumber = web3.BigNumber
const should = require('chai')
    .use(require('chai-as-promised'))
    .use(require('chai-bignumber')(BigNumber))
    .should()

contract.only('Test', function (accounts) {
    beforeEach(async function () {
        this.contract = await Test.new();
    })

    it.only("ecrecover: should pass", async function () {
        const message = EthUtil.sha3('Message to sign here.')
        const signature = await EthUtil.ecsign(message, new Buffer('907570bfd5e48faa71b59fd6d48c9d12dfd639ff0c5f715e9211feb7abfa5edf', 'hex') )

        const recoveredAddress = await this.contract.ecrecover(
            '0x' + message.toString('hex'),
            signature.v,
            '0x' + signature.r.toString('hex'),
            '0x' + signature.s.toString('hex'));
        recoveredAddress.should.be.equal('0x5e54317f3599ea5d026baaca7d9857abeca9c01d', 'The recovered address should match the signing address')
    })
}
nein es hat nicht funktioniert. Ich bekomme immer noch eine falsche Adresse, wenn ich mich bei Ethereumjs anmelde und die obige Funktion im Soliditätsvertrag verwende
Leider habe ich es mit deinem Code nicht hinbekommen. Sie können sich auf das Bild (von Hash, v, r, s eingegeben) beziehen, das ich in Solidität ausführe. Die von ecrecover gefundene Adresse 0x26Bc...ist nicht dieselbe wie 0x5e5.... Ich verwende dieselbe ethereumjs-util-Version image.ibb.co/ms1fJe/Capture.png
Welches Netzwerk und welche Version des Compilers in Remix verwenden Sie?
Javascript-VM, Remix 0.4.23. ist es egal welches netz?
Es ist egal, weil es hilft zu verstehen, wo Ihr Code ausgeführt wird, sonst ist es nicht klar.
Ich habe ein Problem gefunden und den Vertrag oben aktualisiert
danke es funktioniert. Haben Sie eine Idee, warum der vorherige intelligente Vertragscode mit kecak256 oben für Sie in Trüffel funktioniert?

Ich arbeite seit einigen Wochen an dieser Lösung und konnte sie für die Onchain-Verifizierung (unter Verwendung von Solidity) zum Laufen bringen.

Ich hatte die gleiche Sorge, wo ich in der Lage war, die Kette mit web3 ethereumjs-util lib zu verifizieren, aber als ich es mit Solidität versuchte, gab es mir 0x000000000 zurück

Der Ansatz, den ich gewählt hatte, war wie folgt: Probieren Sie aus, ob das für Sie funktioniert

const data = warten tokenContractInstance.methods.transfer (hinterlegung, betragForERC20).encodeABI (); // eine neue Version von web3 1.x

    // https://github.com/ethereum/web3.js/issues/1609
    let txObj = {
        "chainId": chainId,
        "from": sender,
        "nonce": web3.utils.toHex(nonce),
        "to": tokenContractAddress,
        "value": '0x0',
        "gasPrice": web3.utils.toHex(gasPrice),
        "gasLimit": web3.utils.toHex(gasLimit), // also knows as gas
        "data": data
    };

    // version 2
    txObj = web3.utils.toHex(txObj);
    txObj = web3.utils.sha3(txObj);
    let messagetoSign = txObj;

    await web3.eth.personal.unlockAccount(sender, "poc@2018");
    let signature = await web3.eth.sign(messagetoSign, sender);
    let signatureData = ethUtil.fromRpcSig(signature);
    let v = ethUtil.bufferToHex(signatureData.v);
    let r = ethUtil.bufferToHex(signatureData.r);
    let s = ethUtil.bufferToHex(signatureData.s);
    verifyContractInstance.methods.ecrecover(messagetoSign, v, r, s).call();     
    console.log("Signed Address --> ", receivedAddress);

Soliditätscode --->

function ecrecover(bytes32 msgHash, uint8 v, bytes32 r, bytes32 s) public pure returns(address) {
    bytes memory prefix = "\x19Ethereum Signed Message:\n32";
    bytes32 prefixedHash = keccak256(abi.encodePacked(prefix, msgHash));
    return ecrecover(prefixedHash, v, r, s);
}

Lassen Sie mich wissen, ob dies für Sie funktioniert!

Grüße Dev

@stackdisplay .. Ich habe gerade zwei letzte Kommentare gelesen, in denen Sie erwähnt haben, dass Sie es mit Ihrem vorherigen Ansatz lösen und den Smart Contract aktualisieren konnten .. Könnten Sie bitte den Ansatz und die Details teilen .. Grüße
Sie können auf die aktualisierte Post-Nachricht von aquila oben über den aktualisierten Smart-Vertrag verweisen. nicht sicher mit web3.eth.sign, da ich mit ethereumutil ecsign arbeite
Ja, ich habe es verstanden, ich habe es schon einmal versucht, aber haben Sie versucht zu überprüfen, was passiert, wenn Sie versuchen, das TxObj anstelle einer Nachrichtenzeichenfolge zu überprüfen?
Sie können txObj wie hier gezeigt hashen. Es gibt eine sehr spezifische Implementierung dieser github.com/ethereum/EIPs/issues/865#issuecomment-362609538 hier