I heard that the total supply of Link tokens is constant on 2 chains, ethereum and binance smart chain. So what is its mechanism? for example we want to transfer 100 Links tokens from ethereum to binance smart chain. Its mechanism is like mint 100 tokens in ethereum chain and then burn 100 tokens in binance smart chain or we lock assets in smart contract of this chain and unlock assets in the smart contract of another chain.
After watching the video below, I am quite confused so is the binance smart chain a special chain when there is a special mechanism or is it still locking assets in the smart contract of this chain and unlocking assets in smart contract of another chain.
https://www.youtube.com/watch?v=WKvIGkBWRUA&ab_channel=Chainlink
I'd love to get a detailed answer on this mechanism.
Related
Understand that Interledger is an open protocol suite for sending payments across different ledgers -- supports and integrates with Bitcoin, Ethereum (IS 20022)
Does Interledger supports hyperledger and/or vice versa? i.e., any integration possibilities between Interledger and Hyperledger? i.e., hyperledger <-> interledger <-> ethereum and/or bitcoin?
Understand that Hyperledger does not have cryptocurrency but I might have digital assets within my hyperledger network that can be exchanged with ether or bitcoin.
Thus I wish to know if there are integration possibilities between Hyperledger and Interledger?
Interledger is a protocol, not a system so I would rephrase your question as:
I wish to know if there are integration possibilities between Hyperledger and other ledgers using Interledger?
The answer is yes but this depends also on the use case. What do you mean by "integration"?
Interledger defines some standards for distributed transaction execution according to a two-phase commit strategy. It is specifically well-suited to transfers of digital assets across multiple ledgers because it's resiliency is depends on the economic incentives of the intermediaries to claim the assets that have been transferred to them (and in so doing providing the key to the next intermediary to do the same).
The most important standard is the use of a SHA-256 hash in the prepare request and the pre-image of that hash as the commit trigger of the two phase asset transfer on each ledger. We call the hash a condition and the pre-image the fulfillment.
If you want to perform a transaction that transfers digital assets from a sender on one ledger to a receiver on another ledger then you will first establish a condition that can only be fulfilled by the receiver (i.e. only the receiver knows the pre-image).
This way you can involve an untrusted intermediary that will accept a transfer on the sender's ledger and make a corresponding transfer to the receiver on their ledger. Both transfers are prepared using the condition and when the receiver releases the fulfillment to their ledger the assets are transferred to them.
The intermediary will then have possession of the fulfillment (they observed the assets they transferred to the receiver being committed) and will use the same fulfillment to claim the assets transferred to them by the sender.
Any Hyperledger ledger that can be used to underwrite asset ownership and support this two-phase commit strategy can be used in an Interledger payment.
There are examples of writing smart contracts that do just this in Ethereum so I assume the same could be achieved using Fabric, Sawtooth or any other Hyperledger ledger.
I am not aware of any existing implementations of such a plugin that would allow the reference ILP connector to be run as an intermediary between a Hyperledger ledger and other ILP-compatible ledgers but I'd certainly welcome any efforts to build one and would be happy to assist.
Interledger looks to be a service that wants you to route financial transactions through them. There is some simple sample code for compatible wallets and transactions in JavaScript. Presumably you can do this in any language.
Which leads me to point out that Hyperledger supports smart contracts and applications written in Go, Java, Python, and JavaScript (through the Hyperledger Composer) and so there is a pretty good chance that you can implement an ISO 20022 / Interledger compatible data model and protocol.
HOWEVER
You need to follow best practices and smart contracts should never directly update external services as their is no way of rolling back external service changes if the smart contract sends successful external transactions but then fails for other reasons.
So, you need to design multi-stage transactions in your smart contracts and related applications. Applications will have to coordinate with smart contracts and post on their behalf to other services, recording results in the ledger and triggering next stage updates and transactions.
This allows the blockchain ledger to reflect the reality of external states from Interledger or whatever ISO 20022 compatible service you use.
This all presumes that the other financial institution refuses direct participation with the smart contract and hyperledger blockchain, which is always going to be more efficient, reliable, and secure.
It sounds like you want something like Hyperledger Quilt, which interoperates between different blockchain technologies.
So, let us consider a typical trade finance process flow. Exporter deploys a contract that has conditions of the shipment and a hash is generated once the deployment is finished.
Questions:
1) Where is the contract stored?
2) How other participants such as customs and importer can access this contract?
3) Can we activate participant level access to the contract on the blockchain?
There are several aspects to Ethereum and Hyperledger which make them quite different. Let me give a somewhat simplified answer to not get into too much details and a too long answer.
First of all, Ethereum is primarily a public blockchain that works in a certain intended way. Similarly, the Bitcoin blockchain works in a certain intended way. Hyperledger is not like that, rather it's an umbrella for distributed ledger technologies (in my terminology not the same as blockchain) which all aim to provide a very flexible architecture so that one can build all kinds of ledger-backed systems with pretty much any properties needed. One could compare this to an imaginary Bitcoin umbrella that provides technology to produce own altcoins with pluggable parts for e.g. consensus, blockchain storage, node composition etc. In short, all these aim to solve different problems and one should not think one will fit all.
Coming back to your questions.
1) Where is the contract stored?
Ethereum has contracts (called smart contracts) on the chain, i.e. code is compiled to byte code and the resulting bytes are sent within a transaction to be persisted onto the Ethereum blockchain. This is done once when you deploy the smart contract. After this one can interact with the smart contract with other transactions.
Hyperledger is in theory not defining this, it could be on a ledger or it might not. Take Fabric for instance, it deploys the code into a sandboxed Docker container which then can be interacted with using transactions.
2) How other participants such as customs and importer can access this contract?
Short answer is that they are given access via credentials.
This is in both Ethereum and Hyperledger open for you to decide yourself. We now assume the code in both cases has been deployed as code on the blockchain for Ethereum and as a Docker container in Fabric.
In Ethereum the code is, a bit simplified, publicly accessible/visible which means you need to employ some kind of check to only allow those who should be able to interact with the smart contract to do so. One way is to check the sender (of the transaction) and only allow certain ones. It's similar to traditional systems where one usually needs to authenticate/authorize to be allowed in and see/alter data.
In Hyperledger it would most likely be modelled in a similar manner and e.g. in Fabric there is also the Certificate Authority that hands out certificates that allow access to different parts of the system. E.g. transport, endorsement or transactions.
3) Can we activate participant level access to the contract on the blockchain?
Yes, so each participant in both systems has credentials and the designer of the smart contract can use this to control access.
Also, in Fabric there are channels that partition the ledger which is used for access control.
HTH.
1) The contract resides on the ledger. Whenever a transaction is invoked, the corresponding method in the contract gets executed on all the validating peers.
2) Other participants can access this contract using their pre-defined user credentials, which they can use to enroll themselves and invoke transactions on the contract.
3) Yes, we can activate participant level access to the contract by defining attributes for every user and allowing only those users who possess certain attributes to access specific parts of the contract.
I'm building an iOS app for a client that allows users to pay a subscription and unlock additional content within the app. Part of the additional content will be videos which need to be streamed from a server... but I'm not sure whether we should use a hosting service (like Amazon CloudFront or Wowza, perhaps?) or roll our own solution.
Have any of you had experience with either of these options? I looks like this is supported natively by nginx, which we're currently using as our rProxy, but I'd like to hear some thoughts about that. I would be somewhat concerned about saturating our server's 1Gb network connection too...
Whatever the solution, we must be able to verify a person's account before they can access the video content. Variable bitrate is also desirable, and the ability to support >500 concurrent users. This company is also a new startup, so subscription costs are an important factor.
It is usually best to deploy streaming-specific software or services instead of generic HTTP servers such as Nginx. For Wowza, as an example, here's a quick list of features for this type of workflow.
Performance and scalability. You can do a quick comparison on playing back concurrent streams (using load test tools) and see what kind of load can be handled by an HTTP server vs Wowza.
Monitoring. Statistics collection is also integrated with Wowza, which may prove beneficial for start-up companies that need to leverage this kind of data mining.
Security. Wowza also has several options that you can use, such as Secure Token. For example, you can configure your mobile app to query the user's IP address once you determine that they are authorized to receive the stream. You can then generate a hash token based on this IP address and the stream they are authorized for, and only allow playback with the valid token. You can also expire these tokens.
Manager UI. Not as attractive for developers/sys admins, but users can take advantage of a relatively intuitive UI.
Extensibility. Wowza has REST and Java API that can allow you to add custom modules or integrate third-party systems. For example, you can use a custom module that monitors stream connection time, and cuts off any connections that are longer than x number of hours.
I'm currently working on a project which has a large amount of IAM users, each of whom need limited access to particular SQS queues.
For instance, let's say I have an IAM user named 'Bob' and an SQS queue named 'BobsQueue'. What I'd like to do is grant Bob full permission to manage his queue (BobsQueue), but I'd like to restrict his usage such that:
Bob can make only 10 SQS requests per second to BobsQueue.
Bob cannot make more than 1,000,000 SQS requests per month.
I'd essentially like to apply arbitrary usage restrictions to this SQS queue.
Any ideas?
From the top of my head none of the available AWS services offers resource usage limits at all, except if built into the service's basic modus operandi (e.g. the Provisioned Throughput in Amazon DynamoDB) and Amazon SQS is no exception, insofar the Available Keys supported by all AWS services that adopt the access policy language for access control currently lack such resource limit constraints.
While I can see your use case, I think it's actually more likely to see something like this see the light as an accounting/billing feature, insofar it would make sense to allow cost control by setting (possibly fine grained) limits for AWS resource usage - this isn't available either yet though.
Please note that this feature is frequently requested (see e.g. How to limit AWS resource consumption?) and it's absence actually allows to launch what Christofer Hoff aptly termed an Economic Denial of Sustainability attack (see The Google attack: How I attacked myself using Google Spreadsheets and I ramped up a $1000 bandwidth bill for a somewhat ironic and actually non malicious example).
Workaround
You might be able to achieve an approximation of your specification by facilitating Shared Queues with an IAM policy granting access to user Bob as outlined in Example AWS IAM Policies for Amazon SQS and monitoring this queue with Amazon CloudWatch in turn by Creating Amazon CloudWatch Alarms for one or more of the Amazon SQS Dimensions and Metrics you want to limit, e.g. NumberOfMessagesSent. Once the limit is reached you could revoke the IAM grant for user Bob for this shared queue until he is in compliance again.
Obviously it is not necessarily trivial to implement the 'per second'/'per-month' specification based on this metric alone without some thorough bookkeeping, nor will you be able to 'pull the plug' precisely when the limit is reached, rather need to account for the processing time and API delays.
Good luck!
I'm about to embark on a website build where a company wants to reward new visitors with a gift. The gift has some monetary value, and I'm concerned about the site being gamed. I'm looking for ways to help reduce the chance that any one person can drain the entire gift inventory.
The plans call for an integration with Facebook, so authenticating with your FB credentials will provide at least a bit of confidence that a new visitor is actually a real person (assuming that scripting the creation of 100's of FB accounts and then authenticating with them is no simple task).
However, there is also a requirement to reward new visitors who do not have FB accounts, and this is where I'm looking for ideas. An email verification system by itself won't cut it, because it's extremely easy to obtain countless number of email address (me+1#gmail.com, me+2#gmail.com, etc). I've been told that asking for a credit card number is too much of a barrier.
Are there some fairly solid strategies or services for dealing with situations like this?
EDIT: The "gift" is virtual - like a coupon
Ultimately, this is an uphill, loosing battle. If there will be incentive to beat the system, someone will try and they will eventually succeed. (See for example: every DRM scheme ever implemented.)
That said, there are strategies to reduce the ease of gaming the system.
I wouldn't really consider FB accounts to be that secure. The barrier to creating a new FB account is probably negligibly higher than creating a new webmail account.
Filtering by IP address is bound to be a disaster. There may be thousands of users behind a proxy on a single IP address (cough, AOL), and a scammer could employ a botnet to distribute each account requests to a unique IP. It is likely to be more trouble than it is worth to preemptively block IPs, but you could analyze the requests later—for example, before actually sending the reward—to see if there's lots of suspicious behavior from an IP.
Requiring a credit card number is a good start, but you've already ruled that out. Also consider that one individual can have 10 or more card numbers between actual credit cards, debit cards, and one-time-use card numbers.
Consider sending a verification code via SMS to PSTN numbers. This will cost you some money (a few cents per message), but it also costs a scammer a decent amount of change to acquire a large number of phone numbers to receive those messages. (Depending on the value of your incentive, the cost a prepaid SIM may make it cost-prohibitive.) Of course, if a scammer already has many SMS-receiving PSTN numbers at his disposal, this won't work.
First thing I wonder is if these gifts need to be sent to a physical address. It's easy to spoof 100 email addresses or FB accounts but coming up with 100 clearly unique physical addresses is much harder, obviously.
Of course, You may be giving them an e-coupon or something so address might not be an option.
Once upon a time I wrote a pretty intense anti-gaming script for a contest judging utility. While this was many months of development and is far too complex to describe in great detail, I can outline the basic features of the script:
For one we logged every detail we could when a user applied for the contest. It was pretty easy to catch obvious similarities in accounts by factoring the average time between logins / submissions from a group of criteria (like IP, browser, etc - all things that can be spoofed so by themselves it is unreliable). In addition, I compared account credentials for obvious gaming - like acct1#yahoo.com, acct2#yahoo.com, etc. by using a combination of levenshtein distance which is not solely reliable - as well as a parsing script that broke apart the various details of the credentials and looked for patterns.
Depending on the scores of each test, we assigned a probability of gaming as well as a list of possible account matches. Then it was up to the admins to exclude them from the results.
You could go on for months refining your algorithm and never get it perfect. That's why my script only flagged accounts and did not take any automatic action.
Since you're talking about inventory, can we therefore assume your gift is an actual physical item?
If so, then delivery of the gift will require a physical address for delivery - requiring unique addresses (or, allowing duplicate addresses but flagging those users for manual review) should be a good restriction.
My premise is this: While you can theoretically run a script to create 100s of Facebook or Google accounts, exercising physical control over hundreds of distinct real world delivery locations is a whole different class of problem.
I would suggest a more 'real world' solution in stead of all the security: make it clear that it is one coupon per address. Fysical (delivery and/or payment) address. Then just do as you want, maybe limit it by email or something for the looks of it, but in the end, limit it per real end-user, not per person receiving the coupon.