Starbridge is software that facilitates bridge builders who are connecting the Stellar network to other blockchains.
Starbridge is in early development.
Get involved
- Discussions
- More to come...
Starbridge is software that facilitates bridge builders who are connecting the Stellar network to other blockchains.
Starbridge is in early development.
This PR adds the ethereum bridge smart contract. We still need to add many more test cases and optimize the code to reduce ethereum transaction fees. Those two issues will be addressed in future PRs.
Add a diagram showing the flow of data with one possible design of how Stellar could integrate with blockchain bridges that run their own validators.
As a starting point for brainstorming, and to help identify gaps in understanding, and problems that need solving.
When a new validator starts (or existing one lost it's DB) it needs to process all withdrawal transactions to prevent double spend. This commit adds this mode that will run on the first call to ProcessNewLedgers
.
Close #74.
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
EpicConverting 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.
This PR implements getStellarDeposit() which is a helper function to extract and validate a deposit to the Stellar bridge account from an http request. getStellarDeposit() will be used by the HTTP handlers for the Stellar -> Ethereum withdrawal and refund endpoints.
A stellar deposit is valid if:
Note that we do not validate the Stellar asset or the ethereum address of the recipient (which is encoded in the transaction memo). Validation of those fields should only be implemented in the HTTP handler for the withdrawal endpoint. If a user does not set the memo correctly on their payment to the bridge then the withdrawal should fail, however, it should still be possible to refund the payment.
This commit implements changes connected to cancellation flow suggested by @nano-o specifically, expire transactions which are irrevocably invalid (ie. sequence number bumped) and use ledger close time to calculate timebounds of transactions generated by Starbridge. Additionally, it moves responsibility to set timebounds to the client because different Starbridge servers can process a signing request at different moments in time.
This commit adds initial versions of different services of Starbridge server. In general the server is currenly divided into two parts: frontend and backend. Frontend handles HTTP requests and allows users to create SignatureRequest
's (requests to sign an inverse transaction) and send it to a backend server via a queue (or a DB). Backend server is responsible for streaming blockchain data, handling SignatureRequest
's and finally creating and signing transactions. This separation was made to allow more secure architectures in which frontend server does not have access to signing part of the app.
In the backend server, transaction builder and transaction signer are separate entities. This is done to (maybe) support using secure enclaves (like AWS Nitro Enclaves) that will store the secret key and sign transactions.
List of services:
backend/Worker
- Main backend worker handling SignatureRequest
stellar/controllers/StellarGetInverseTransactionForEthereum
- Controller responsible for building inverse transactions, contains simple logic for checking if a new SignatureRequest
should be created or if the inverse transaction should be returned to the userstellar/signer/Signer
- Stellar transaction signerstellar/txbuilder/Builder
- Stellar transaction builder, currently ETH tx hardcodedstellar/txobserver/Observer
- Observer of Stellar transactions, currently using testnet.store/Memory
- Storage system implemented in memory, in the future: Postgres DB.The current version contains at least one race condition because UpsertOutgoingStellarTransaction
is called concurrently from two different services. This should be solved by SELECT ... FOR UPDATE
in Postgres but I wonder if we should allow just one DB transaction at a time for security reasons (to decrease number of synchronization issues).
Change license of contracts to Apache 2.0.
The code in this repository is intended to be licensed only with the Apache License 2.0, as is most software products produced by @stellar. Looks like we accidentally committed contracts with a combination of ISC and MIT licensing.
Enable mDNS always, not only when no peers are specified.
mDNS is only enabled when no peers are specified, but this is inconvenient when running local tests where I want the app to connect to a specific remote peer and serve up mDNS discoverability locally.
*** 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
duplicateThe objective of this project is to transfer assets between wallets from different networks. Currently, the available flows are from Stellar to Ethereum and vice versa, being able to send only ETH from one to the other. With some initial setup, you will be able to connect your wallets using Freighter for Stellar and Metamask for Ethereum and start the transfer flow.
⚠️ Remember that the refund flow was not implemented in both transfer flows!
Front: React, Typescript using the Atomic Design
You can check the project architecture here
The environment variables are in src/config
. You can use the .env.example
as a base to create your .env.local
config file
Install dependencies
npm install
Start the server
npm run start:dev
The project will be running at http://localhost:3000/
If you want you can run it on Docker too.
docker build -t starbridge-front .
docker run -dp 3000:3000 starbridge-front
To make transactions on your wallets, you must have a secure connection locally. With ngrok it is possible to create an SSL certificate to be able to continue in the flow without problems.
You need to register, to generate a token and then continue configuring ngrok.
ngrok config add-authtoken <token>
ngrok http 3000
You must disconnect from the page through your Wallet as well, so you can connect to another account again.
Confirmations are required to verify and legitimize information that will be recorded in the blockchain and cannot be changed afterward. If some information is assumed fraudulent, it will not get any confirmation. Without a single transaction confirmation Ethereum, the transaction won’t be considered valid by the network. Each confirmation takes less than one minute. Just wait a bit and try to perform the withdraw action again.
This PR implements fixes for "SBR-1 Replay attacks between chains" and "SBR-2 Deposited funds potentially locked in contract" from the security audit report:
https://drive.google.com/file/d/1f_IqUB3k3Q9XjLhG38zK5XWRF43tLZ_t/view
SBR1 is addressed by including adomainSeparator
in the hash which is signed by the validators. The domainSeparator
consists of the validator set version, the network chain id, and the bridge smart contract address. Including those components ensures that signatures cannot be replayed on bridge contracts deployed on multiple chains (e.g. testnet and mainnet).
SBR-2 is addressed by ~having a restricted list of all supported ERC20 tokens which can be deposited to the bridge contract. It is up to the validators to ensure that this allow list will contain only standard ERC20 tokens which do not subtract fees in tokens from the transferred value.~ [Edit: I removed the deposit token allow list and instead explicitly checked the amount of tokens transferred to the bridge as suggested by the security audit]
Note that "SBR-3 Possible name or symbol collisions for Stellar assets" is not addressed because I think the validators can agree to not reuse symbols or names when registering Stellar assets. I think this behavior can be enforced through validator behavior and I don't think it's necessary to enforce name collision prevention in the smart contract logic. If the validators were compromised then there would be attacks of greater impact than just registering stellar assets with duplicate names.
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 https://github.com/stellar/starbridge/pull/86#discussion_r915288407
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 https://github.com/stellar/starbridge/pull/68#discussion_r912921050
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.
Timestamp Virtual Machine Avalanche is a network composed of multiple blockchains. Each blockchain is an instance of a Virtual Machine (VM), much like
Subnet EVM Avalanche is a network composed of multiple blockchains. Each blockchain is an instance of a Virtual Machine (VM), much like an object in a
Thank you for your interest in ZASentinel ZASentinel helps organizations improve information security by providing a better and simpler way to protect
Hosts-BL Simple tool to handle hosts file black lists that can remove comments, remove duplicates, compress to 9 domains per line, add IPv6 entries, a
Node implementation for the Avalanche network - a blockchains platform with high
A Matrix-iMessage puppeting bridge. The bridge runs on a Mac or jailbroken iPhone (soon™). A websocket proxy is required to receive appservice events from the homeserver.
vks vks is a Vulkan bridge for Go. The header generator folder contains the code that is used to generate the vulkan bindings. It woks similar to c-fo
bridge between mattermost, IRC, gitter, xmpp, slack, discord, telegram, rocketchat, twitch, ssh-chat, zulip, whatsapp, keybase, matrix, microsoft teams, nextcloud, mumble, vk and more with REST API (mattermost not required!)
Matterbridge-Heroku An inline buildpack for hosting Matterbridge on Heroku. Heroku is a platform for easily deploying applications. A buildpack provid
fbridge fbridge bridges facebook messenger with any service supported by matterbridge trough the API interface. fbridge is using fbchat to connect to
fbridge-asyncio This repo is a fork of fbridge. If you log in to your facebook account from a browser, after you do, it's a good idea to restart fbrid
Mediabank bridge This internal tool enables authenticated gRPC based endpoint for securely communicating with systems like: Telestream Vantage Workflo
remov Inspiration Our aim is to expand the capabilities of blockchain and make a secure way for transferring NFT between RMRK and MOVR blockchain. The
Peggo Peggo is a Go implementation of the Peggy (Gravity Bridge) Orchestrator originally implemented by Injective Labs. Peggo itself is a fork of the
dn42regsrv A REST API for the DN42 registry, written in Go, to provide a bridge between interactive applications and registry data. A public instance
Gravity bridge is Cosmos <-> Ethereum bridge designed to run on the Cosmos SDK blockchains like the Cosmos Hub focused on maximum design simplicity an
RuuviBridge RuuviBridge is designed to act as a "data bridge" between various so
High-performance PHP-to-Golang IPC bridge Goridge is high performance PHP-to-Golang codec library which works over native PHP sockets and Golang net/r
socket Package socket provides a low-level network connection type which integrates with Go's runtime network poller to provide asynchronous I/O and d