stellar / starbridge Goto Github PK
View Code? Open in Web Editor NEWSoftware that facilitates bridge builders who are connecting the Stellar network to other blockchains.
License: Apache License 2.0
Software that facilitates bridge builders who are connecting the Stellar network to other blockchains.
License: Apache License 2.0
Starbridge should be able to interact with transactions on each connected blockchain (Stellar and Ethereum).
You can think of this as the piece that is responsible for doing the actual interactions with the connected blockchains. These can be expanded into separate components in the future as complexity increases, however they have been clubbed together at the early stage of this project for simplicity.
The Monitoring service will be run in the background constantly monitoring for transfer requests (payments) from each connected network. It will trigger a registered handler with the transaction data and hash when it receives a payment.
The Submission logic will submit a provided transaction to the destination network
We are skipping this step here since it is handled by the multisig component (#7) for now
The TxStatus logic will fetch the status of a given transaction hash on a network in a synchronous manner
Put this inside the orchestrator code and bloat that component.
Converting from Ethereum transactions to Stellar transactions
An equivalent Stellar tx for a given Ethereum tx
The main program that runs this conversion is primarily used to demonstrate this component.
We will be plugging this component into the rest of the system via it's exported methods so we need to ensure the exported methods returns the correct values or errors so it can be used directly by the calling code.
This will plug into our MVP starbridge solution
Stellar supports up to 7 decimals, whereas many assets on the Ethereum network are specified with 18 decimals. This can be a problem because it can result in a loss of precision and therefore a loss of funds. We need to handle this conversion correctly such that there is no loss of funds. We should also try and ensure there is no loss of precision however that may not be possible.
We can issue microassets on the Stellar network to make up the different in precision. A microasset is an issuance of a smaller denomination of a given asset. For example, 1 ETH = 10^3 milli ETH = 10^6 micro ETH = 10^9 nano ETH = 10^12 pico assets.
That is, when converting 1 ETH from Ethereum to Stellar we can convert it to 10^12 pETH, where 1 pETH represents 10^-12 ETH.
We can do something in-between where we check the precision of the asset value locked in the ETH transaction and if it makes uses of more than 7 decimals (i.e has a value like 1.12345678 ETH instead of 1.1234567 ETH) then we can issue pETH otherwise we can issue ETH to the destination account. Therefore, we will have two assets issued for each ETH asset, the asset code and one prefixed with "p" to represent a pico asset.
If a user initiates a bridge transfer from ethereum to stellar there should be an endpoint to refund the Ethereum deposit
The validator requires that all Stellar payments originating from the bridge multisig account are ingested into the validator database. When the validator starts up and detects the database is empty it should start ingesting payments from the moment the bridge multisig account was created.
If a user initiates a bridge transfer from stellar to ethereum there should be an endpoint to refund the Stellar deposit
We want to deploy a smart contract on the Ethereum test network (Ropsten). This will perform the functionalities of a multisig escrow account
We would ideally like to use an off-the-shelf smart contract from something like OpenZepplin, or it's primitives. We would ideally not like to write our own smart contract from scratch since an escrow account contract seems like it can be available in the open-source community
Other resources we can use:
The smart contract should support the following:
_wrapPay()
operation on the smart contract. This function will wrap an asset from a remote chain (relevant data passed in as arguments to the function call) and send it to the ethereum user (address sent to function as an argument). Note that this wraps an asset such as XLM
into a wrapped asset like WXLM
and these wrapped tokens are issued by the smart contract, similar to how it works on Stellar with escrow accounts._unwrapPay()
operation on the smart contract. This function will unwrap an asset sent from a remote chain where the underlying asset is locked in the smart contract itself (relevant data passed in as arguments to the function call). The smart contract will then send it to the ethereum user (address sent to function as an argument). Note that this unwraps an asset such as WETH
into the underlying asset ETH
asset from the locked balances in the smart contract.TBD
This connects the various components behind an API
TBD
None
Currently all error responses do not include any structured response which means that no details about the failure are included in the response besides the http status code
Scenarios which should be covered:
We should test both the happy path and error conditions
*** This issue is not up-to-date as it has been simplified ***
@nikhilsaraf to update
Validate transactions so that only those transactions that are eligible to be submitted to the Stellar network will be sent for signature collection (multisig) by the orchestrator
Given an Ethereum transaction, validate the following:
Given an unsigned Stellar transaction, validate the following:
Given a signed Stellar tx, validate the following:
three exposed endpoints (or functions):
Note: we will likely need a database or in-memory representation of the status of each Ethereum tx and corresponding Stellar transactions (foreign key reference). We will also need to sync up with the Stellar network to fill in the STELLAR_SUCCESS status in the case where a transaction has been successfully processed by the Stellar network so that we don't re-process it. The db will also need to maintain the list of "escrow" accounts and the associated signers. Anytime there is a tx that modifies the signers (currently out of scope) this db entry will also need to be updated. Lastly we will also need to maintain a mapping of crypto token to "escrow" accounts so we know which "bridge account" to work with when validating that the Stellar tx has been created correctly.
None
๐ญ I think the sequence number should be stored rather than pulled from Horizon. I'm a little worried we're relying on submission to have taken place for this seq num to be correct, since it will only be updated on Horizon if the last one was submitted.
I was thinking we could specify a starting sequence number as a parameter on boot and the service could work out, somehow, what sequence number it should be up to based on the next message it sees. Is there anything in the Ethereum message/event that we could use for that?
Originally posted by @leighmcculloch in #30 (comment)
Components that should be unit tested:
In ethereum 256 bits of precision are used to represent ether / erc20 token amounts. However, Stellar can only support 64 bits of precision. We will need to add restrictions on withdrawal amounts so that if someone deposits an amount of ether / erc20 tokens which is not representable in stellar the validator will reject Stellar withdrawal attempts for that deposit. The only action allowed for such deposits is ethereum refunds (after the withdrawal window). The restrictions on withdrawal amounts should be configured on a per token basis and these restrictions should be configured in the validator toml file.
An example of a restriction could be:
every ether deposit must be a multiple of 1 gwei (10^9 wei) and the maximum amount of eth that could be deposited is (2^64 / 10^9 )
horizon error: "Transaction Failed" (tx_failed, op_malformed) - check horizon.Error.Problem for more information pid=33006 tx=266fd1ab915aae2c24e7dd4d966f7a4bcbaa219b742beced0becb568f79121b6
the tx that is constructed should be correct. things to look out for: issues constructing claimable balance ops, sponsorship, 0 value asset payments
This will be a fairly involved issue (Epic) so I've not filled it out yet
Coordinating signatures for a Stellar tx from m-of-n signers
A server that connects to other servers given fixed hostnames or IP addresses.
The server initiates the signing of a Stellar tx from these n
servers. Note that the starting point is a Stellar tx.
Once fully signed it can return it using an API or to keep things simple it can just display it on-screen.
Additionally, there is an API we will need to develop such that the invoking caller can interface with this decentralized service. For example, when we /submit (POST) the stellar tx to be signed, we might get a HTTP 200 response and later need to GET the signed tx fully signed (or partially signed to get the /status).
This is a single-responsibility component. This will be invoked by a higher-level orchestrator. We don't need to worry about validation of the Stellar tx, or the question of whether this Stellar tx has been submitted previously or not since that is validated by the Validation component (see other issues in this milestone)
A lot of this is outlined in the multisig federation SEP protocol doc here that we can look at: https://docs.google.com/document/d/1mBxYsyuEj7j3fqMdvcJHZ5REZZpz3yjBe3OGjS13zoA/edit
We can look at satoshipay's reference implementation for this here: https://github.com/satoshipay/signature-coordinator
There's also Refactor from Stellar-Expert: https://github.com/stellar-expert/refractor
We will need a dApp web page for both Stellar and Ethereum. These will construct the transactions for both chains as needed. This does not need to be very fancy but just a way by which we can interact with the bridge and not have to manually trigger smart contract calls (or Stellar tx constructions).
single web page that has two sections: Stellar and Ethereum. These will trigger the Freighter/Stellarterm wallet on Stellar and the Metamask wallet for Ethereum
it has a form like so (Stellar):
stellar_asset_code
, stellar_asset_issuer
, amount_with_decimals
, destination_ethereum_address
ethereum_token_contract_address
, amount_with_decimals
, destination_ethereum_address
it has a form like so (Ethereum):
ethereum_token_contract_address
, amount_with_decimals
, destination_stellar_address
stellar_asset_code
, stellar_asset_issuer
, amount_with_decimals
, destination_stellar_address
v1.0 can be a more aesthetic version of this.
This will allow us to let the Ethereum user specify what their destination Stellar address is
Can be done later (after MVP) but we should probably add a config value for minimum deposit. Otherwise it's possible to add thousands of rows in Starbridge DB quite easily.
Originally posted by @bartekn in #86 (comment)
Currently we assume a singleton deployment of validator backend worker and validator http controller. We should determine if the validator can still run safely with multiple instances of a backend worker or http controller.
I realized that sourceAccount.LastModifiedLedger
is updated also when the account receives the deposit not only when the sequence is bumped. With the current single condition I think it's possible to block the withdrawal of any account by sending 1 stroop every ledger. I wonder how and if we can solve this.
EDIT: Looks like we could use CAP-21 and it's seqLedger
which equals to "ledger number at which seqNum
took on its present value". In Horizon it's Account.SequenceLedger
but can be empty if not set in extension.
Originally posted by @bartekn in #68 (comment)
If a user initiates a bridge transfer from stellar to ethereum there should be an endpoint to withdraw the wrapped assets from the ethereum bridge smart contract
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.